İşletmeden işletmeye satış yapan mağazanızda (B2B) bazı alıcılar sipariş verirken her defasında kartla ödeme yapmayabilir. İşletmeniz, kendi ticari değerlendirmesiyle belirli firmalara cari hesap üzerinden sipariş verme koşulu tanımlamış olabilir. Bu durumda site yalnızca fiyat ve sepeti göstermekle yetinmez; hangi şirket hesabıyla işlem yapıldığını, bakiyenin hangi kayda dayandığını ve yeni siparişin bu hesaba nasıl işleneceğini anlaşılır kılmalıdır. Bu, bölgede belirli bir işletme veya ticari koşul iddiası değildir. Konu, önceden yetkililerce kararlaştırılmış ticari bilgiyi e-ticaret akışında doğru göstermektir. Vade, limit veya kredi kararı vermek bu yazının amacı değildir.

Bu ihtiyaç, ödeme ekranına “fatura” seçeneği eklemekten daha geniştir. Müşteri yanlış şirket ya da şube adına sipariş verirse işlem doğru hesaba bağlanmayabilir. Ekranda eski bakiye görünürse satın alma sorumlusu kararını hatalı bilgiyle verebilir. Sipariş gönderildiği hâlde cari hareketin oluşup oluşmadığı belirsiz kalırsa müşteri, satış ekibi ve muhasebe farklı kayıtları izleyebilir. Sayfa tasarımı, yazılım kapsamı ve işletmenin yetkili süreçleri birlikte düşünülmelidir.

Cari hesaplı siparişi normal ödeme akışından ayırın

Kartla ödeme veya havale, sipariş sırasında bir ödeme işlemi başlatır. Cari hesaplı sipariş ise işletmenin daha önce onayladığı ticari koşul altında, bedelin ilgili müşteri hesabına kaydedilmesiyle ilerleyebilir. Her mağazada bu seçenek bulunmaz; her müşteriye veya her ürüne de aynı koşul tanınacağı varsayılamaz. Site gerçek iş kuralını kendi başına üretmemeli, karar yetkisini teknik ekibe bırakmamalıdır.

İlk çalışma, hangi hesapların bu akışa uygun olduğunu ve bilginin yetkili kaynağını yazılı olarak belirlemektir. Şirket kaydı, şube, müşteri numarası, fiyat listesi, vergi bilgisi ve sipariş yetkisi birbirinden farklı alanlardır.

İşletmenin bayi hesapları, şube rolleri ve fiyat atamaları için B2B e-ticaret yazılımında bayi fiyatı ve onay kuralları rehberindeki çerçeveyi inceleyebilirsiniz. Bu makalenin odağı rol tanımı veya fiyat listesi kurmak değil; onaylı cari hesap bilgisinin sipariş sırasında doğru ve güncel görünmesidir.

Bakiyenin hangi kaynaktan geldiğini belirtin

“Güncel bakiye” ifadesi tek başına yeterli değildir. Hesap hareketleri muhasebe yazılımında, bayi portalında veya başka bir işletme kaydında tutulabilir. E-ticaret sitesi bu bilgiyi nereden alır? Son güncelleme zamanı görülebilir mi? Bir sipariş cari hesaba kaydedildikten sonra bakiye hangi işlemle değişir? Bu soruların yanıtı belirsizken arayüzde kesin tutar göstermek yerine süreç netleştirilmelidir.

Ürün gereksiniminde veri kaynağının sahibi, güncelleme sıklığı, başarısız aktarımda uygulanacak davranış ve sorumlu rol yazılabilir. Bu bilgiler gerçek sistem kurulumu incelenerek doğrulanır. Bağlantı anlık değilse, ekranın son güncelleme zamanını göstermesi veya sipariş öncesi yeniden doğrulama yapması değerlendirilebilir. Altyapı buna izin vermiyorsa kullanıcıya kesin ve güncelmiş gibi görünen bir değer sunmak yerine, hangi bilginin ne zaman teyit edileceği açıklanmalıdır.

Eski bir bakiye ile sipariş kararının nasıl ayrılacağı işletmenin iş kuralına bağlıdır. Bir hareket aktarımda bekliyorsa ilgili kullanıcıya “sorun yok” gibi kesin bir sonuç gösterilmemelidir. İşletme, işlemi durdurmayı, yetkili incelemesine göndermeyi veya alternatif ödeme yöntemini sunmayı kendi onaylı sürecine göre seçebilir. Belirsizliğin müşteriden saklanması, daha sonra siparişin neden farklı kayda bağlandığını açıklamayı güçleştirir.

Hesap bakiyesiyle sipariş hareketini birbirine karıştırmayın

Hesap özeti, önceki siparişlerden, ödemelerden, iadelerden veya başka onaylı hareketlerden oluşabilir. Yeni sipariş ise bu özetin yanında ayrı bir işlem kaydıdır. Site, sipariş onayını cari hareketin muhasebe sisteminde kesinleştiği gibi göstermemelidir; bu iki olay farklı zamanlarda gerçekleşebilir. Ekran metinleri “sipariş alındı”, “hesap kaydına gönderiliyor” ve “kayıt doğrulandı” gibi gerçek aşamaları birbirinden ayırmalıdır. Kullanılan durum adları işletmenin gerçek bağlantı ve onay akışına göre belirlenir.

Bir sipariş hesaba işlendiğinde hangi kimliklerin saklanacağı da kararlaştırılmalıdır: sipariş numarası, müşteri hesabı, ilgili şube, sipariş tarihi, toplam tutar ve aktarım sonucu bunlardan bazıları olabilir. Gerekli alanları operasyon ve muhasebe sorumluları belirler. Aynı sipariş ikinci kez gönderilirse yeni bir cari hareket yaratılmasını önleyecek kontrol, mevcut entegrasyon ve veri modeline göre tasarlanır; belirli bir platform özelliğinin var olduğu varsayılmaz.

Alışveriş akışında müşterinin gördüğü sipariş ile ekiplerin takip ettiği kayıt arasında tutarlılık kurmak için e-ticaret yazılımı seçiminde operasyonu tanımlama rehberini de kullanabilirsiniz. Buradaki amaç, her işletmenin aynı muhasebe aracını kullanmasını önermek değil; gerçek sipariş, ödeme ve kayıt adımlarının proje kararından önce görünür olmasını sağlamaktır.

Müşteriye sipariş öncesinde yeterli bilgi verin

Sepette veya ödeme adımında cari hesap seçeneği varsa, hangi firma adına işlem yapıldığı açıkça görünmelidir. Müşteri birden fazla şubeye bağlıysa varsayılan şube sessizce kullanılmamalı; gerekiyorsa değiştirme ve yetki sınırı anlaşılır olmalıdır. Fiyat, ürün miktarı veya teslimat adresi değiştiğinde sipariş özetinin güncelliği yeniden kontrol edilebilir. Bir ekran, sadece hesabın adını gösterip hangi koşulun uygulandığını saklıyorsa kullanıcının doğru kararı vermesi zorlaşır.

Bakiyeyi gösterme kararı varsa tutarın ne anlama geldiği açıklanmalıdır: toplam borç mu, kullanılabilir tutar mı, yoksa belirli tarihe kadar kaydedilen hareketlerin özeti mi? “Kalan limit” gibi bir alanı ancak işletme bu kavramı kullanıyor, doğru kaynaktan hesaplıyor ve müşteriye gösterilmesine izin veriyorsa ekleyin. Bu yazı limit hesaplama yöntemi, vade süresi veya müşteriye kredi tanımlama tavsiyesi vermez.

Gösterilen bakiye güncel değilse kullanıcı siparişi göndermeden önce uyarılmalıdır. Bu uyarı siparişi kesin olarak reddetmek zorunda değildir; işletmenin seçtiği doğrulama adımını ve kiminle iletişime geçileceğini anlatabilir. Siparişin kayda alındığı, onay beklediği veya tamamlandığı farklı ifadelerle belirtilmelidir. Müşteriye otomatik e-posta gönderiliyorsa mesaj, yönetim ekranındaki son durumla aynı olmalıdır.

Yetki, şube ve veri görünürlüğünü sınırlandırın

Bir şirket hesabının çalışanları aynı siparişleri görmeyebilir veya aynı işlemleri yapamayabilir. Siparişi hazırlayan, onaylayan ve muhasebe hareketini doğrulayan rollerin hangileri olduğu işletmenin yetki tablosunda belirlenebilir. Kullanıcının başka bir şirkete ait hesap bakiyesini, siparişini ya da belge bağlantısını görmediği uygun test hesaplarıyla denenmelidir. Bir arayüz alanını gizlemek tek başına erişim kontrolü sayılmaz; kullanılan altyapının veri yetkileri ayrıca incelenmelidir.

Hesap bilgisi ve sipariş özeti yalnızca işi için gerekli kullanıcılara açılmalıdır. Gereksiz kişisel veri veya hassas not toplamak, cari hesabı yönetmek için kendiliğinden gerekli hâle gelmez. Testlerde gerçek müşteri kayıtları yerine izinli örnek veriler kullanın. Şirket ya da şube yetkisi değiştiğinde eski oturum ve açık sepetin ne olacağı da kontrol edilmelidir.

İstisnaları ve kayıt geçmişini görünür kılın

Gerçek hayatta kaynak sistem bakımda olabilir, hesap bilgisi eksik kalabilir veya sipariş gönderiminden sonra dış kayıt sistemi yanıt vermeyebilir. Ekip, bu durumların her birinde hangi kaydı inceleyeceğini ve müşteriye ne söyleyeceğini bilmelidir. “Teknik hata” mesajı yeterli değildir; sipariş numarası, beklenen işlem ve sıradaki sorumlu rol açıklanabilir. İç kayıt ekranında hata ayrıntısı bulunabilir ama müşteriye gösterilen metinde gereksiz teknik veri yer almamalıdır.

Hareket geçmişi, yalnızca son bakiyeyi değil, bakiye ve sipariş ilişkisindeki önemli değişiklikleri de açıklayabilmelidir. Bir siparişin hangi kaynaktan geldiği, ne zaman gönderildiği, onay veya ret kararını hangi yetkili rolün verdiği ve aktarımın ne zaman doğrulandığı kayıt edilebilir. Her düzeltmenin eski değerini sessizce silmek yerine, işletmenin kayıt politikasıyla uyumlu iz bırakıp bırakmadığı değerlendirilmelidir. Bu, belirli bir muhasebe standardı veya saklama süresi önerisi değildir; uygulanacak kuralı yetkili kişiler belirler.

Kabul testini gerçek iş senaryolarıyla yapın

Yayından önce yalnızca bir başarılı sipariş denemek yeterli olmayabilir. Test setine yetkili bir şirket hesabı, sipariş onayı gereken kullanıcı, bakiyesi güncellenemeyen kayıt, yanlış şube seçimi, sepet tutarının değişmesi ve aynı siparişin yeniden gönderilmesi gibi durumlar ekleyin. Her senaryoda beklenen müşteri mesajı, sipariş durumu, cari hareket ve takip edecek rol yazılı olsun. Sonuç, ekran görüntüsü veya işlem numarası gibi uygun kanıtla kaydedilebilir; test verisinde gerçek müşteri bilgisi kullanmayın.

Bir denemeyi hem müşteri tarafında hem yönetim ekranında izleyin. Siparişin kimin adına oluştuğu, doğru fiyatın uygulanıp uygulanmadığı, hesabın hangi koşulunun gösterildiği ve işlem kaydının kaynak sistemde nasıl göründüğü karşılaştırılmalıdır. Sonradan düzeltme gerekiyorsa düzeltmeyi yapan kişi, gerekçe ve değişen alanlar anlaşılır olmalıdır.

Raporlama sırasında sipariş toplamı, cari hesaba gönderilen tutar ve kaynak sistemde doğrulanmış hareket aynı ölçü gibi sunulmamalıdır. Farklı aşamalar, farklı zamanlarda güncellenebilir. Kullanılan alanların anlamını ve raporun veri kesim zamanını belirtmek ekiplerin aynı sayıyı farklı yorumlamasını azaltır. E-ticaret raporlarında ciro, sipariş ve katkıyı ayırma rehberi, rapor göstergelerinin neyi temsil ettiğini açıklamaya yardımcı olur.

Bu akışın web mağazası, müşteri hesabı, sipariş ve işletme kayıtlarıyla birlikte ele alınması gerekiyorsa E-Ticaret Yazılımı hizmetini inceleyebilirsiniz. Proje kapsamı; gerçek hesap kaynağı, yetki tablosu, sipariş örnekleri ve işletmenin onayladığı ticari koşullar doğrulandıktan sonra belirlenmelidir.

Sık Sorulan Sorular

Cari hesapla ödeme, kart veya havale seçeneğiyle aynı mıdır?

Her zaman aynı işlem değildir. Cari hesap, işletmenin daha önce belirlediği koşul altında sipariş tutarının ilgili şirket hesabına kaydedilmesini içerebilir. Kartla ödeme veya havalede ise sipariş sırasında ayrı bir ödeme işlemi yürütülür. Sitenin hangi seçeneği sunduğu, işletmenin gerçek ticari düzenine göre açıklanmalıdır.

Her şirket müşterisine cari hesap seçeneği açılmalı mı?

Bu bir tasarım kararı olarak tahmin edilmemelidir. Hangi şirketlerin hangi koşullarda bu yolu kullanabileceğini işletmenin yetkili kişileri belirler. Site yalnızca bu onaylı bilgiyi doğru hesap, kullanıcı ve şube ile eşleştirmelidir. Başvuru yapılması tek başına hesabın aktif olduğu anlamına gelmez.

Bakiyeyi sipariş ekranında göstermek hangi durumda yararlıdır?

Alıcı, sipariş kararını mevcut hesabındaki borç veya kullanılabilir tutarı anlamaya dayandıracaksa bakiye görünümü yararlı olabilir. Gösterilecek değerin tanımı, kaynağı ve son güncelleme zamanı açıklanmalıdır. Güvenilir biçimde doğrulanamayan bir tutar kesin ve güncelmiş gibi sunulmamalı; görünüm ve teyit yolu işletmenin kayıt düzenine göre tasarlanmalıdır.

Kaynak sistem geç yanıt verirse site ne yapmalıdır?

Davranış önceden tanımlanmalıdır. Sipariş beklemeye alınabilir, yetkili kontrolüne yönlendirilebilir veya başka onaylı yöntem sunulabilir. Hangi seçeneğin uygun olduğu kullanılan sistem ve işletme kuralına bağlıdır. Müşteriye belirsizliği saklayan kesin bir onay mesajı gösterilmemelidir.

Sipariş onayı ile cari hareketin doğrulanması neden ayrılır?

İşletmenin web siparişi kaydetmesi ve bu siparişin dış hesap kaydında görünmesi farklı adımlar olabilir. Arada entegrasyon veya yetkili kontrolü bulunuyorsa her aşamanın durumu ayrı izlenmelidir. Sitenin kesin olarak neyi doğruladığı, gerçek sistem akışında denenerek belirlenir.

Şube hesabı bakiyeyi ve siparişleri görebilir mi?

Bu, şirketin yetki yapısına göre değişir. Kullanıcının şirketi, şubesi ve rolü açıkça ilişkilendirilmeli; başka bir şubeye veya şirkete ait kayıtların görünmediği sınanmalıdır. Ekranda bilgi gizlemek tek başına veri erişimini sınırlandırmaz; teknik yetkiler ayrıca doğrulanmalıdır.

Aynı sipariş iki kez gönderilirse ne kontrol edilmelidir?

İşletme ve yazılım ekibi, aynı siparişin yeniden gönderilmesinin ikinci bir cari hareket yaratıp yaratmadığını test etmelidir. Kontrol, sipariş kimliği ve kullanılan bağlantı davranışına göre tasarlanır. Belirli bir platformun bunu otomatik sağladığı varsayılmamalı; sonuç kayıt ekranı ve kaynak hareketle doğrulanmalıdır.

Bu yazı vade veya kredi limiti belirlemeyi öneriyor mu?

Hayır. Vade, limit, uygun müşteri ve diğer ticari koşullar işletmenin yetkili kişilerince belirlenmelidir. Yazı yalnızca önceden onaylanan koşulun site, müşteri hesabı, sipariş ve kayıt ekranında tutarlı gösterilmesi için tasarım sorularını anlatır; finansal ya da hukuki tavsiye sunmaz.