Bayi Sipariş Yönetimi E-Ticaret Çözümü ile Cari Limit ve Onay Akışı Nasıl Kurulur?

Bayi sipariş yönetimi neden satış kurallarıyla başlamalı?

Bayi sipariş yönetimi, şirketin mevcut ticari kurallarını görünür ve uygulanabilir bir akışa dönüştürerek başlamalıdır. Portalın ilk işi ürün göstermek değil; hangi bayinin hangi ürünü, hangi fiyatla, hangi ödeme ve onay koşuluyla sipariş edebileceğini doğru biçimde belirlemektir. Bu nedenle iş kuralları yazılı hale gelmeden geliştirilen ekranlar, sonradan çok sayıda istisna ve manuel müdahale üretir.

Portalın temel karar modeli

İlk analizde bayi segmentleri, temsilci sorumlulukları, fiyat listeleri, iskonto sınırları, vade ve kredi kuralları aynı senaryo üzerinde test edilmelidir. Bayi, distribütör ve kurumsal müşteri operasyonlarını tek yapıda toplamanın kapsamını görmek için kurumsal B2B operasyonlarının tek platformda yönetimi yaklaşımı da yararlı bir referans noktasıdır. Amaç, mevcut süreci kopyalamak değil; karar noktalarını netleştirip otomasyona uygun hale getirmektir.

• Bayi tipi ve müşteri segmenti
• Ürün ve marka erişim yetkisi
• Fiyat listesi ve iskonto sınırı
• Ödeme ve vade koşulları
• Cari limit ve risk kontrolü
• Sipariş onay senaryosu

Kötü bir sistem, iyi bir insanı her seferinde yener. - W. Edwards Deming

Bayiye özel fiyat ve iskonto kuralları nasıl modellenir?

Bayiye özel fiyatlandırma, tek bir indirim yüzdesi tanımlamak yerine öncelik sırası belli kurallarla modellenmelidir. Sistem; ana fiyat listesi, bayi grubu, ürün grubu, kampanya, sözleşme fiyatı ve kullanıcıya tanımlı iskonto yetkisi çakıştığında hangi kuralın kazanacağını bilmelidir. Fiyatın kaynağı ve hesaplama sırası belirsizse portal ile ERP arasında tutarsızlık oluşur.

Fiyat motorunda tanımlanması gerekenler

Teklif aşamasında yalnızca “bayiye özel fiyat” maddesi yazmak yeterli değildir. Fiyatın ERP’den hazır mı geleceği, portalda mı hesaplanacağı, kur ve vergi etkilerinin nerede uygulanacağı ve manuel iskonto talebinin kim tarafından onaylanacağı açıkça yazılmalıdır. Bu konuyu kapsamlandırırken B2B projelerinde müşteriye özel fiyatlandırma teklifinin kapsamı üzerinden gereksinimleri karşılaştırmak, eksik modülleri erken görmeyi kolaylaştırır.

• Ana ve alternatif fiyat listeleri
• Bayi veya müşteri grubu kuralları
• Ürün bazlı sözleşme fiyatları
• İskonto alt ve üst sınırları
• Kampanya öncelik sırası
• Vergi, para birimi ve yuvarlama kuralları

Cari limit kontrolü ERP ile hangi aşamada çalışmalı?

Cari limit kontrolü, siparişin yalnızca sonunda değil, kritik karar noktalarında ERP ile çalışmalıdır. Kullanıcı sepeti onaya gönderirken güncel risk görülebilmeli; sipariş kesinleşirken limit yeniden doğrulanmalıdır. Böylece uzun açık oturumlarda veya eş zamanlı siparişlerde değişen bakiye nedeniyle yanlış onay verilmesi azaltılır. Son onay öncesi tekrar kontrol, finansal veri için temel güvenlik adımıdır.

ERP bağlantısında kontrol anları

ERP bağlantılı bayi portalı tasarlanırken cari bakiye, açık sipariş, açık fatura, risk limiti ve kullanılabilir limit gibi alanların hangi sistemde ana kayıt olduğu belirlenmelidir. ERP entegrasyonlu B2B e-ticaret yapısının özellik ve süreçleri, senkronizasyon sınırlarını tanımlarken yararlı bir çerçeve sunar. ERP gerçek kaynak ise portal bu veriyi değiştirmemeli; yalnızca kontrollü biçimde okumalı ve sipariş kararında kullanmalıdır.

• Sepet onaya gönderilirken ön kontrol
• Kesin sipariş öncesi güncel limit sorgusu
• Açık siparişlerin riske dahil edilmesi
• Limit aşımında otomatik bloke
• Yetkili kullanıcı için istisna talebi
• ERP yanıtının kayıt altına alınması

Sipariş onayında kullanıcı rolleri nasıl tasarlanmalı?

Sipariş onayında roller, organizasyon şemasına göre değil karar yetkisine göre tasarlanmalıdır. Bayi kullanıcısı sipariş oluşturabilirken bayi yöneticisi şirket içi onay verebilir; bölge temsilcisi ticari istisnayı inceleyebilir; finans ekibi cari risk kararını verebilir. Rol sayısını artırmak yerine yetki matrisi ve eşik değerleri açık biçimde tanımlanmalıdır.

Çok rollü onay zinciri

B2B müşteri yetkilendirme yapısında görüntüleme, sipariş verme, fiyat görme, iskonto isteme, fatura erişimi ve onay yetkileri ayrı ayrı ele alınmalıdır. Çok şirketli yapılarda bunun nasıl ayrıştırılabileceğini görmek için sipariş ve fatura yetkilerinin çok şirketli B2B yapılarda yönetimi yaklaşımı dikkate alınabilir. Her onay adımının kim tarafından, hangi gerekçeyle ve hangi süre içinde sonuçlandırıldığı kayıt altında olmalıdır.

• Bayi standart kullanıcısı
• Bayi yönetici veya satın alma yetkilisi
• Bölge satış temsilcisi
• Satış yöneticisi
• Finans veya kredi kontrol kullanıcısı
• Sistem yöneticisi ve denetçi

ERP senkronizasyonunda hangi veriler anlık tutulmalı?

ERP senkronizasyonunda her veriyi anlık taşımak yerine sipariş kararını etkileyen bilgiler gerçek zamanlı, daha az kritik içerikler ise planlı aralıklarla eşitlenmelidir. Cari limit, kritik stok, sipariş kabul durumu ve gerektiğinde fiyat gibi veriler düşük gecikmeyle doğrulanırken ürün açıklamaları veya bazı katalog alanları toplu senkronizasyonla yönetilebilir. Senkronizasyon seviyesi iş etkisine göre belirlenmelidir.

Veri sahipliği ve güncelleme frekansı

Her alan için “ana sistem hangisi?” sorusu cevaplanmadan entegrasyon geliştirmesine başlanmamalıdır. Ürün kodu ERP’de, zengin ürün içeriği portalda, müşteri cari bilgisi ERP’de tutulabilir; ancak iki sistemin aynı alanı bağımsız biçimde değiştirmesi veri çakışmasına yol açar. Bu nedenle API, webhook, kuyruk veya zamanlanmış görev gibi yöntemler teknik tercihten önce veri sahipliği tablosuna bağlanmalıdır.

• Cari limit ve risk verisi için gerçek zamanlı kontrol
• Kritik stok için kısa aralıklı veya anlık güncelleme
• Fiyat için belirlenen ana sistemden doğrulama
• Katalog içeriği için planlı senkronizasyon
• Sipariş durumunda çift yönlü güncelleme
• Başarısız kayıtlar için yeniden deneme kuyruğu

Entegrasyon kesilirse siparişler nasıl güvenle korunmalı?

Entegrasyon kesildiğinde sipariş kaybolmamalı, sessizce ERP’ye işlendi kabul edilmemeli ve kullanıcıya yanlış başarı mesajı verilmemelidir. Portal siparişi kendi tarafında benzersiz kimlikle saklamalı, entegrasyon durumunu ayrı bir statüyle izlemeli ve bağlantı geri geldiğinde kontrollü biçimde yeniden işlemelidir. Başarılı kayıt ile başarılı ERP aktarımı iki ayrı olay olarak tasarlanmalıdır.

Hata ve yeniden deneme senaryosu

Kesinti yönetimi yalnızca teknik log tutmak değildir; satış ve finans ekiplerinin hangi siparişlerin beklediğini görebileceği operasyon ekranları gerekir. Aynı siparişin iki kez oluşmasını engelleyen idempotency yaklaşımı, yeniden deneme sayısı, hata kodu, manuel müdahale yetkisi ve müşteriye gösterilecek durum metni kapsamda tanımlanmalıdır. Kritik hata halinde portal yeni sipariş kabulüne devam edecekse bunun ticari risk sınırı da ayrıca belirlenmelidir.

• Portal tarafında kalıcı sipariş kaydı
• Benzersiz sipariş ve aktarım kimliği
• Bekliyor, başarılı ve hatalı entegrasyon statüleri
• Kontrollü otomatik yeniden deneme
• Tekrarlı ERP kaydını önleyen koruma
• Operasyon ekibi için manuel müdahale ekranı

Güvenlik ve kayıt geçmişi bayi portalında nasıl yönetilmeli?

Bayi portalında güvenlik, yalnızca parola politikasıyla sınırlı olmamalı; kullanıcı, şirket, rol, veri erişimi ve kritik işlem kayıtları birlikte yönetilmelidir. Özellikle fiyat değişikliği, iskonto talebi, limit istisnası ve sipariş onayı gibi ticari kararların kim tarafından yapıldığı sonradan izlenebilmelidir. Denetlenebilir işlem geçmişi, destek ve uyuşmazlık çözümünde teknik logdan daha işlevseldir.

Yetki ve denetim katmanı

Bayi çalışanı işten ayrıldığında erişimin kapatılması, yeni kullanıcının doğru şirkete bağlanması, yönetici yetkisinin kontrollü verilmesi ve hassas ekranların role göre sınırlandırılması operasyon prosedürüne bağlanmalıdır. Oturum güvenliği, çok faktörlü doğrulama ihtiyacı, API erişim anahtarları, kişisel ve ticari verilerin saklama politikaları da teknik teklifte açıkça ele alınmalıdır. Gerekli güvenlik seviyesi, şirketin risk profiline ve bağlı sistemlerin niteliğine göre belirlenir.

• Rol tabanlı erişim kontrolü
• Şirket ve hesap bazlı veri izolasyonu
• Kritik işlemler için denetim kaydı
• Oturum ve kimlik doğrulama politikaları
• API anahtarı ve servis hesabı yönetimi
• Kullanıcı açma, kapatma ve devir prosedürü

Yüksek sipariş hacminde performans nasıl planlanmalı?

Yüksek sipariş hacminde performans, yalnızca hızlı sayfa açılışı değil; fiyat hesaplama, stok sorgusu, ERP yanıtı, sepet işlemleri ve onay kuyruklarının birlikte kapasite testinden geçirilmesiyle planlanmalıdır. Ortalama trafik yerine kampanya, sezon, ay sonu veya toplu bayi siparişi gibi yoğun senaryolar esas alınmalıdır. Kapasite hedefi ölçülebilir işlem senaryolarına bağlanmalıdır.

Performans ve ölçeklenebilirlik kapsamı

Teklifte hedef eş zamanlı kullanıcı sayısı, beklenen sipariş hacmi, ürün ve fiyat kayıt büyüklüğü, entegrasyon çağrı sıklığı gibi girdiler belirtilmelidir. Önbellek, kuyruk, veri tabanı indeksleri ve yatay ölçekleme gibi teknik kararlar bu girdilere göre şekillenir. Ayrıca ERP yavaşladığında portalın tamamen kilitlenmesini önleyecek zaman aşımı, devre kesici ve kontrollü bekleme mekanizmaları tasarlanmalıdır.

• Yoğun dönem eş zamanlı kullanıcı senaryosu
• Sipariş oluşturma ve onay yük testi
• Fiyat ve stok sorgusu performansı
• ERP gecikmesi altında davranış testi
• Kuyruk ve yeniden deneme kapasitesi
• İzleme, alarm ve hata oranı takibi

Teklif öncesi hangi bilgi ve dokümanlar hazırlanmalı?

Teklif öncesinde en değerli hazırlık, ekran çizmekten çok iş kurallarını ve entegrasyon gerçeklerini belgelemektir. Rol matrisi, örnek sipariş senaryoları, fiyat ve iskonto kuralları, cari limit mantığı ve mevcut ERP bağlantı seçenekleri hazır olduğunda geliştirme firmaları aynı kapsam üzerinden teklif verebilir. Karşılaştırılabilir teklif için ortak gereksinim seti gerekir.

Teknik kapsam görüşmesine hazırlık

Bayi portalı geliştirme teklifi istenirken mevcut kullanıcı sayıları, bayi grupları, ürün hacmi, sipariş yoğunluğu, ERP ürünü ve erişilebilen API dokümanları paylaşılmalıdır. Sağlayıcı değerlendirmesinde yalnızca özellik listesine değil; yetkilendirme, entegrasyon, hata yönetimi ve destek modeline de bakılmalıdır. Bu açıdan B2B yazılım firmalarında yetkilendirme, entegrasyon ve destek modelini karşılaştırma yaklaşımı teklifleri aynı eksende incelemeye yardımcı olur.

• Rol ve yetki matrisi
• En az üç uçtan uca sipariş senaryosu
• Fiyat, iskonto ve kampanya kuralları
• Cari limit ve istisna politikası
• ERP API veya entegrasyon dokümanları
• Kullanıcı, ürün ve sipariş hacmi tahminleri

Eğitim, kabul testi ve destek teklife nasıl dahil edilmeli?

Eğitim, kabul testi ve destek, yazılım açıldıktan sonra konuşulacak ek işler değil, ana teklifin teslimat kalemleri olmalıdır. Teklif; hangi kullanıcı gruplarının eğitileceğini, kabul kriterlerini, test ortamını, hata sınıflarını, canlıya geçiş sorumluluklarını ve destek modelini tanımlamalıdır. Teslimatın bitiş noktası çalışan bir sistem değil, kurum tarafından kabul edilmiş ve işletilebilir bir süreçtir.

Canlıya geçiş ve devir teslim kapsamı

Kullanıcı kabul testi için gerçek sipariş senaryoları hazırlanmalı; normal sipariş, limit aşımı, fiyat istisnası, onay reddi ve ERP kesintisi gibi durumlar birlikte sınanmalıdır. Eğitim materyalleri, yönetici kılavuzu, yetki devir prosedürü ve destek iletişim modeli teslim paketine bağlanmalıdır. Böylece toptan satış sipariş yazılımı yalnızca teknik olarak devreye alınmaz; satış, finans ve bayi kullanıcılarının günlük operasyonuna kontrollü biçimde aktarılır.

• Rol bazlı kullanıcı eğitimi
• Kullanıcı kabul testi senaryoları
• Canlıya geçiş kontrol listesi
• Hata öncelik ve müdahale tanımları
• Dokümantasyon ve yönetici kılavuzu
• Bakım, destek ve değişiklik yönetimi modeli