Bayi ürünleri sepete ekliyor, fakat satış ekibi siparişi yeniden telefonla doğruluyor. Çünkü ekranda görünen fiyat bayinin özel anlaşmasını içermiyor; vade ve limit kontrolü de başka dosyada tutuluyor. Bu durumda sipariş ekranı açılmış olsa bile operasyonun büyük bölümü aynı kalır.
B2B bayi sipariş sistemi, katalogdan daha fazlasıdır. Bayinin hangi ürünü hangi koşullarla alabileceğini, siparişin ne zaman kesinleşeceğini ve hangi durumda insan onayı gerekeceğini yönetir. Başlangıçta ticari kuralları açıklamak, sonradan sepete çok sayıda istisna eklemekten daha sağlıklı bir yol sunar.
Liste fiyatı, bayi grubu iskontosu, ürün kampanyası ve özel anlaşma aynı siparişte karşılaşabilir. Bu kuralların birlikte mi yoksa alternatif olarak mı uygulanacağı açık değilse iki ekip aynı sepet için farklı sonuç hesaplayabilir.
Örnek bir tasarımda ürünün özel anlaşma fiyatı varsa o değer seçilir; yoksa bayi grubuna ait liste kullanılır. Kampanyanın bu fiyatla birleşip birleşmeyeceği ayrıca tanımlanır. Bu, her işletmeye uygun hazır formül değildir. Ticari sözleşmelerinizle uyumlu karar ağacını belirlemek için bir örnektir.
Sipariş üzerinde fiyatın hangi kurala göre hesaplandığını saklayın. Güncel liste sonradan değiştiğinde geçmiş siparişin hesabı değişmemelidir. Taslak siparişin ne kadar süreyle aynı fiyatı koruyacağı ise ayrı bir ticari karardır.
Bayinin hesabındaki borç, henüz faturalanmamış siparişler ve bekleyen ödemeler limit değerlendirmesini etkileyebilir. Bu verilerin hangi sistemden geldiği ve ne kadar güncel olduğu bilinmelidir. Eski bakiye üzerinden yapılan kontrol, olduğundan fazla kullanılabilir limit gösterebilir.
Sipariş onayında limit rezervasyonu uygulanıyorsa iptal ve süre aşımı kuralları da gerekir. İki farklı kullanıcı aynı bayi hesabından eşzamanlı sipariş verdiğinde toplam etki kontrol edilmelidir. Yalnızca sayfa açılırken limit okumak yeterli olmayabilir.
Ürün birimlerinin anlaşılmaması sevkiyat hatasına dönüşebilir. Bayi “3” yazdığında üç ürün mü, üç koli mi istiyor? Bir kolideki miktar zamanla değişirse eski sipariş nasıl yorumlanacak? Arayüz, birim bilgisini miktarın yanında göstermelidir.
Minimum sipariş; ürün adedi, koli katı, sepet tutarı veya teslimat bölgesine bağlı olabilir. Ön yüzdeki uyarı yararlıdır fakat kurallar sunucuda da doğrulanmalıdır. Farklı bir istemciden gönderilen talep aynı kontrolleri geçmelidir.
Katalogda bulunmayan veya satışı durdurulan ürünleri eski siparişten yeniden ekleme senaryosunu da değerlendirin. “Tekrar sipariş ver” işlemi geçmiş miktarları kopyalayabilir; güncel satış uygunluğu ve ticari koşullar yine kontrol edilmelidir.
“Onaylandı” tek başına siparişin sevk edildiği anlamına gelmez. Ticari onay, stok ayırma, hazırlama ve teslimat farklı durumlar olabilir. Bayiye hangi bilginin gösterileceğini açık durum isimleriyle belirleyin.
Taslak → Gönderildi → Ticari inceleme → Onaylandı
Onaylandı → Hazırlanıyor → Kısmi sevk / Tam sevk
Reddedildi → Gerekçe göster → Düzeltilmiş yeni sürüm
Akış örneğindeki geçişlerin hepsi her projede gerekli değildir. Önemli olan her durumun sahibini ve izin verilen işlemlerini belirlemektir. Bayinin sonradan değiştirdiği teslimat adresi, onaylanmış siparişi etkiliyorsa yeniden kontrol gerekip gerekmediği yazılmalıdır.
Bayi portalının ERP’deki her bilgiyi göstermesi gerekmez. İç maliyet, diğer bayilerin koşulları ve operasyon notları müşteriye açık veri değildir. Entegrasyonda paylaşılacak alanları açık bir listeyle sınırlayın.
Müşteri portalı rehberi belge ve hesap erişimini genel olarak ele alır. Bayi siparişinde buna ek olarak ticari fiyat anı, limit rezervasyonu ve kısmi sevkiyat hesabı gerekir. API entegrasyonu örnekleri de bağlantının hangi sistemler arasında kurulacağını netleştirmeye yardımcı olur.
Bir denemede aynı bayinin iki kullanıcısıyla aynı anda sipariş gönderin. Limitin birlikte değerlendirilmesini, fiyat değişikliğinin taslak siparişe etkisini ve reddedilen siparişin gerekçesini kontrol edin. Sadece tek kullanıcının sorunsuz alışveriş yapması ticari kuralların doğru olduğunu kanıtlamaz.
B2B sistemlerde müşteriye özel ticari kurallar daha belirgin olabilir. Bayi grubu fiyatı, özel anlaşma, vade, kredi limiti ve sipariş onayı aynı süreçte değerlendirilir. Standart bir satış ekranı bu ihtiyaçları kendiliğinden karşılamayabilir. Projede ürün kataloğuyla birlikte hesap yetkileri, birim yapısı ve finansal kontrol noktaları ele alınmalıdır. Her işletmenin bu kuralların tamamına ihtiyacı olduğu varsayılmamalıdır.
Aktarım zamanı ticari sürece göre belirlenir. Bazı işletmelerde ön talep önce portalda incelenir; bazılarında sipariş ERP’ye bekleyen kayıt olarak yazılır. İki modelde de hangi kaydın bağlayıcı olduğu ve değişikliklerin nereden yönetileceği açık olmalıdır. Tekrar gönderim, iptal ve bağlantı kesintisi senaryoları test edilmeden aktarımı yalnızca başarılı bağlantı üzerinden değerlendirmeyin. Aktarım durumunu bayiye anlaşılır bir ifadeyle gösterin.
Kesinleşmiş siparişin geçmişte kabul edilen fiyatı korunacak şekilde tasarlanması gerekir. Taslak ve süresi dolmuş teklifler için ise işletmenin açık fiyat politikası uygulanmalıdır. Sipariş anındaki liste sürümünü ve kullanılan kuralı kaydetmek hesabın izlenmesini sağlar. Güncel fiyatı geçmiş siparişe doğrudan uygulamak, müşterinin gördüğü tutarla kayıtlı ticari anlaşmanın ayrışmasına neden olabilir. Fiyat hesabını geçmiş sürümüyle birlikte saklayın.
Bütün katalogla başlamadan önce özel fiyatı, koli katı ve onay ihtiyacı bulunan bir ürünü seçin. Satış, finans ve depo ekiplerinin aynı örneğe verdiği cevapları karşılaştırın. Uyuşmayan yorumlar yazılım geliştirilmeden çözülmelidir.
ARKTECH özel yazılım çözümleri için talep hazırlarken yalnızca ürün listesini göndermeyin. Bir normal sipariş, bir limit aşımı ve bir kısmi sevkiyat örneğiyle beklediğiniz kararları açıklayın.
