Bayi risk yönetimi: B2B sipariş onayında limit, vade ve risk kontrolü

Açık hesap çalışılan bir bayi ağında en pahalı hata, riskli cariye açılan siparişin sevkiyattan sonra fark edilmesidir. B2B sipariş onayında limit, vade ve risk kontrolü tam bu noktada devreye girer: bayinin sepeti onayladığı anda açık bakiyesi, vadesi geçmiş borcu ve tanımlı kuralları otomatik kontrol edilir; sorunlu sipariş depoya düşmeden yakalanır. Bu yazıda bayi risk yönetimi açısından bu kontrollerin nasıl kurgulandığını, aşım durumunda onay akışının nasıl işlediğini ve ERP cari senkronunun neden belirleyici olduğunu bir senaryo üzerinden anlatıyoruz.

Risk neden sipariş anında yakalanmalı?

Telefonla veya e-postayla sipariş alan bir düzende kontrol noktası fiilen yoktur. Siparişi alan çalışanın o anda ERP'yi açıp bayinin bakiyesine, vade durumuna ve teminatına bakması pratikte mümkün olmaz; baksa bile bu kişiye bağlı, atlanabilir bir adımdır. Sonuç şu zincirdir: sipariş girilir, depo hazırlar, araç yola çıkar ve muhasebe aşımı ancak fatura keserken görür. O noktada mal sahadadır, geri çağırmak hem maliyetli hem ticari ilişkiyi yıpratan bir hamledir.

Sipariş anında çalışan otomatik kontrol bu zinciri en baştan keser. Kural her siparişte istisnasız uygulanır; yoğun günde de, mesai dışında gelen siparişte de, yeni işe başlamış temsilcinin aldığı siparişte de aynı disiplin geçerlidir. Kurulum projelerinde sık gördüğümüz tablo, işletmelerin bu sistemi kurana kadar riski kişilerin hafızasıyla yönettiğidir: "O bayiye dikkat et" bilgisi satış müdürünün aklındadır ve o izindeyken devre dışı kalır.

Üç kontrol katmanı: limit, vade, risk kuralları

Sipariş onayında çalışan kontrolleri üç katman olarak düşünmek kurguyu netleştirir:

• Kredi limiti: Bayinin açık bakiyesi ile yeni sipariş tutarının toplamı tanımlı limiti geçiyor mu? Limit bayi bazında tanımlanır; teminat mektubu, ipotek veya DBS gibi güvencelere göre farklılaştırılabilir.
• Vade aşımı: Bayinin vadesi geçmiş faturası var mı, varsa kaç gündür ödenmemiş? Limitin altında olan bir bayi, yaşlanmış borcu yüzünden yine de beklemeye düşebilir.
• Risk kuralları: İşletmenin kendi tanımladığı ek koşullar: çek karşılığı çalışan bayide karşılıksız çek kaydı, belirli bir tutarın üzerindeki ilk sipariş, uzun süredir hareketsiz carinin aniden büyük sipariş açması gibi durumlar.

Bu üç katmanın her biri için ayrı bir sonuç tanımlanabilir: siparişi doğrudan engelle, onaya düşür veya yalnızca uyarı göster. Doğru kurgu sektöre ve bayi yapısına göre değişir; lastik, yapı malzemesi gibi sezonluk stok yığılan sektörlerde katı engelleme yerine onaya düşürme daha sık tercih edilir.

Senaryo: limiti aşan sipariş ne yaşar?

Kurguyu somutlaştıralım. Bir yapı kimyasalları distribütörünün Antalya bayisinin kredi limiti 500 bin TL, mevcut açık bakiyesi 420 bin TL olsun. Bayi salı akşamı portala girip 130 bin TL'lik bir sipariş oluşturuyor. Sepeti onayladığı anda sistem hesabı yapar: 420 artı 130, 550 bin TL eder ve limiti 50 bin TL aşar.

Bu noktada sipariş kaybolmaz, reddedilmez; "onay bekliyor" durumuna geçer ve tanımlı akış başlar:

1. Bayi ekranında siparişinin alındığını ve onay sürecinde olduğunu görür; kullanılabilir limitini ve aşım tutarını da görebilir.
2. Bölge satış temsilcisine bildirim düşer. Temsilcinin onay yetkisi 100 bin TL'ye kadar aşımları kapsıyorsa karar onundur; sipariş geçmişi düzgün, vadesi temiz bir bayi için onayı verir.
3. Aşım temsilcinin yetkisini aşsaydı sipariş bir üst kademeye, satış müdürüne veya finans yöneticisine yönlenecekti.
4. Onay verildiği anda sipariş ERP'ye aktarılır, depo süreci başlar. Onay kaydı, gerekçesiyle birlikte sipariş geçmişinde saklanır.

Aynı bayinin 30 gündür ödenmemiş bir faturası da olsaydı vade kuralı ayrıca tetiklenir, sipariş iki koşul birden onaylanmadan ilerlemezdi. Bayi açısından deneyim yine de düzgündür: durumu portalda görür, gerekirse açık bakiyesine online ödeme yapıp süreci kendisi açar.

Rol bazlı onay yetkisi nasıl kademelenir?

Her aşımın aynı kişiye düşmesi iki soruna yol açar: küçük aşımlar yöneticiyi meşgul eder, yönetici müsait değilse sipariş bekler. Bunun yerine onay yetkisi rollere ve tutar eşiklerine göre kademelenir:

| Aşım büyüklüğü | Onay yetkisi | |---|---| | Küçük tutarlı aşım | Bölge satış temsilcisi | | Orta kademe aşım | Satış müdürü | | Yüksek tutar veya vade aşımıyla birleşen durum | Finans yöneticisi |

Eşik değerleri işletmenin ciro yapısına göre belirlenir; önemli olan ilkedir. İyi kurgulanmış bir akışta ayrıca şunlar bulunur:

• Vekalet tanımı: Onaycı izindeyken yetki otomatik olarak vekiline geçer, sipariş askıda kalmaz.
• Süre kuralı: Belirlenen süre içinde karar verilmeyen sipariş bir üst kademeye taşınır.
• İz kaydı: Kim, hangi siparişi, ne zaman, hangi gerekçeyle onayladı veya reddetti; tamamı raporlanabilir durumdadır.

Bu iz kaydı denetimin yanında bayi risk yönetimi politikasının zamanla iyileştirilmesine de hizmet eder: hangi bayilerde aşım sıklaşıyor, hangi onaylar sonradan tahsilat sorununa dönüşüyor, limitler gerçekçi mi gibi sorular ancak veriyle cevaplanır.

ERP cari senkronu: kontrolün güvenilirlik şartı

Limit ve vade kontrolü, beslendiği veri kadar güvenilirdir. Açık bakiye, vade bilgisi ve teminat kayıtları ERP'de yaşar; portal bu veriyi taze tutamazsa iki yönlü hata üretir. Bakiye güncel değilse sabah ödeme yapmış bayi öğleden sonra haksız yere bloke olur; tersi durumda gün içinde kesilen faturalar görünmediği için aşım gözden kaçar.

Bu yüzden kurulumda senkron tasarımı en az kural tasarımı kadar önemlidir:

• Cari bakiye ve vade bilgisi ERP'den portala düzenli aralıklarla, kritik kontrol anlarında ise anlık sorguyla taşınır.
• Onaylanan sipariş ERP'ye otomatik yazılır; böylece bir sonraki siparişin limit hesabı bekleyen siparişleri de hesaba katar.
• Portal üzerinden yapılan online tahsilat cari hesaba işlenir ve kullanılabilir limit anında açılır.

ERP tarafıyla portal arasındaki bu döngünün ayrıntılarını B2B platformu entegrasyonlar sayfasında anlatıyoruz. Cari verinin iki sistem arasında tutarlı kalması ay sonu mutabakatını da kökten hafifletir; bu konuyu cari mutabakat otomasyonu yazısında ayrıca ele almıştık.

Tahsilatla kapanan döngü

Risk kontrolünün asıl amacı alacağı güvenceye almaktır; bu yüzden kontrol mekanizması tahsilat kanalıyla birlikte düşünülmelidir. Limiti dolan bayinin önüne ödeme seçeneği konursa bekleyen sipariş bir hızlandırıcıya dönüşür: bayi portalda açık bakiyesini görür, sanal pos ile ödemesini yapar, limit açılır ve sipariş kendiliğinden ilerler.

Sahadaki karşılığı küçümsenmeyecek ölçüde: 600'den fazla bayisi olan bir lastik markası, sipariş ve tahsilat süreçlerini bu kurguyla portala taşıdıktan sonra muhasebe ekibinin manuel iş yükünde yüzde 70 azalma ölçtü. Ayrıntıları vaka çalışmasında okuyabilirsiniz. Tahsilat tarafının kurgusu için Tahsilet sayfasına da göz atabilirsiniz.

Kuralları kurarken sık yapılan hatalar

Kurulum projelerinde sık karşılaştığımız birkaç tuzağı baştan bilmekte fayda var:

• Tüm bayilere tek limit politikası: Beş yıllık güçlü bayi ile üç aylık yeni bayi aynı kurala bağlanırsa kural ya çok gevşek ya çok sıkı olur. Bayi gruplarına göre farklılaştırın.
• Her aşımı engelleme: Katı blokaj, satış ekibinin kuralı sistem dışından delmesine yol açar; telefonla araya girilen her sipariş kontrolün dışına çıkar. Onaya düşürme çoğu durumda daha sağlıklıdır.
• Senkronu sonraya bırakmak: Kurallar hazır ama cari veri bayat olunca sistem güven kaybeder; bir kez "bakiye yanlıştı" yaşandığında ekip kontrollere şüpheyle yaklaşmaya başlar.
• Bayiden saklamak: Bayi kendi limit ve bakiye durumunu göremezse her bekleyen sipariş bir telefon trafiği doğurur.

Kurulum aşamasındaki diğer yaygın tuzakları bayi yönetim sistemi kurarken yapılan hatalar yazısında topladık.

Sonraki adım

Limit, vade ve risk kontrolleri tek başına bir modül olmaktan çok, bayi yönetim sisteminin sipariş, cari ve tahsilat katmanlarını birbirine bağlayan omurgadır. Bu omurganın B2B platformu içinde nasıl konumlandığını ürün sayfalarında ayrıntılı anlatıyoruz. Kendi bayi yapınız, limit politikanız ve ERP'nizle bu kurgunun nasıl çalışacağını görmek isterseniz demo talep edin; keşif görüşmesinde mevcut onay sürecinizi birlikte inceleyip size uygun kural setini netleştirelim.