Bayi Sipariş Yazılımı: Limit ve Onay Akışı Nasıl Tasarlanır?

Limiti tek bir tutardan ibaret görmeyin

Bayi limiti hesabında açık siparişler, tahsilatı bekleyen işlemler veya farklı şubeler dikkate alınabilir. Hangi kalemlerin hesaba dahil olduğu işletmenin ticari kararıdır. Yazılım bu kararı açık bir formüle dönüştürmeli; hesapta kullanılan kaynakları ve son güncelleme zamanını göstermelidir.

Bu rehber kredi veya finansal risk tavsiyesi değildir. Amaç, işletmenin belirlediği limit politikasının tutarlı uygulanmasını sağlamaktır. Aynı bayinin farklı kullanıcılarının hangi limiti paylaştığını ve alt hesapların nasıl ilişkilendiğini baştan tanımlayın.

Sipariş ve onay durumlarını ayrı tutun

Taslak, gönderildi, onay bekliyor, onaylandı ve sevke açıldı gibi durumların her biri farklı koşulları temsil edebilir. Bir siparişin onaylanması stok rezervasyonu yapıyor mu, yoksa stok daha sonra mı ayrılıyor? Bu karar belirsizse portal müşteriye gerçekte hazır olmayan bir siparişi kabul edilmiş gösterebilir.

Microsoft onay araçları ilk yanıtlayan, herkesin yanıtı ve sıralı onay gibi farklı örüntüler sunar. [1] Birden fazla kişinin onay vermesinin ne anlama geldiği de aynı açıklıkla tasarlanmalıdır. “Onaya gitti” bilgisi, kimin hangi kararı beklediğini göstermelidir.

Örnek: iki bayi kullanıcısı aynı limiti harcıyor

Varsayımsal bayinin kullanılabilir limiti 50 birimdir. İki çalışan aynı anda 40 birimlik sipariş gönderiyor. İkisi de eski kullanılabilir değeri okursa toplam 80 birimlik işlem kabul edilebilir. Burada sorun ekrandaki uyarı değil, onay anındaki eşzamanlı kontrol ve rezervasyondur.

Veri tabanı işlemleri ve izolasyon davranışı, aynı kaynağı tüketen işlemlerin nasıl etkileştiğini belirler. [2] Limit kontrolü, rezervasyon ve sipariş durumu birlikte tutarlı ele alınmalıdır. Örnek sayılar ticari limit önerisi değil, yarış durumunu açıklayan basit bir senaryodur.

İstisnayı sistem dışına taşımayın

Yetkili kişi belirli siparişte limite veya fiyat kuralına istisna tanıyabilir. Bu karar WhatsApp yazışmasında kalırsa daha sonra neden farklı davranıldığını araştırmak zorlaşır. İstisna tutarı, kapsamı, geçerlilik süresi ve gerekçesi sistemde kaydedilmelidir.

Sınırsız “yönetici onayı” düğmesi yerine hangi sınırın aşıldığı görünür olsun. Onaylayan kişi kendi oluşturduğu istisnayı onaylayabiliyor mu? Görev ayrılığı gerekiyorsa bu kontrol uygulanmalıdır. Onay bağlantıları da ilgili kullanıcı ve işlemle sınırlı erişim gerektirir.

Limit değişikliği açık siparişleri nasıl etkiler?

Bayi limiti sonradan düşürüldüğünde önceden kabul edilen siparişlerin otomatik iptal edilip edilmeyeceği açıkça kararlaştırılmalıdır. Eski kararları yeni değerle sessizce yeniden hesaplamayın. Hangi siparişlerin yeniden incelemeye alınacağı ve müşteriye hangi bilgi verileceği süreçte yer alsın.

Kısmi sevkiyat veya sipariş bölme durumunda ayrılmış limitin dağıtımı da izlenmelidir. Tek sipariş üç parçaya ayrıldığında toplam yükümlülüğün üç kez sayılmadığını kontrol edin. Kaynak-hedef uzlaştırması yalnızca sipariş adedini değil, ilgili tutar ve durumları da kapsamalıdır.

Demo yerine istisna provasını değerlendirin

Teklif alırken normal siparişin yanında aynı anda iki sipariş, sonradan değişen limit, kısmi iptal ve reddedilen fiyat istisnasını gösterin. Portalın bayi kullanıcısına açıklayıcı mesaj üretip üretmediğine bakın. Ticari kural, geliştiricinin kodunda gizli kalmamalıdır.

Teslim paketi limit sözlüğünü, onay matrisini ve değişiklik geçmişini içersin. Operasyon ekibi hangi siparişin neden beklediğini kendi başına görebiliyorsa sistem daha yönetilebilir hale gelir; her sorun için veri tabanına müdahale gerekmesi iyi bir kabul ölçütü değildir.

Sık sorulan sorular

### Limit kontrolünü sadece ERP’ye bırakabilir miyim? ERP esas kaynak olabilir. Ancak portalın kabul anında ne gösterdiği, yanıt gecikmesinde nasıl davrandığı ve bekleyen işlemleri nasıl tuttuğu yine tasarlanmalıdır.

Onay sayısını artırmak daha güvenli mi?

Her zaman değil. Gereksiz onaylar süreci kilitleyebilir. Her adım gerçek bir yetki veya risk kararını temsil etmelidir.