B2B e-ticaret yazılımı: Bayi fiyatı ve onay kuralları

Bayi sisteme giriş yapıyor, kendi fiyatını görüyor ve sepet hazırlıyor. Siparişi gönderdiğinde ise hangi şube adına işlem yaptığı belli değil; merkez onayı gereken tutar doğrudan depoya düşüyor. Başka bir kullanıcı aynı şirketin bütün geçmiş siparişlerini görebiliyor. B2B e-ticaret yazılımında “bayi girişi” başlığı bu ayrıntıları açıklamaz. Şirket, kullanıcı, şube, fiyat ve onay ilişkileri açıkça kurulmalıdır.

Toptan satış deneyimi, perakende mağazasına giriş ekranı eklemekten daha geniştir. İşletmelerin kendi ticari kuralları olabilir ve bu kurallar günlük sipariş yolunda doğru uygulanmalıdır. Bu rehber kurgusal bir temizlik malzemesi tedarikçisinin iki şubeli müşterisi üzerinden ilerliyor. Fiyat ve ödeme koşulları örnek iş ihtiyaçlarıdır; finansal veya hukuki politika önerisi değildir. Gerçek kurallar ilgili yetkililerce onaylanıp yazılıma doğru aktarılmalıdır.

Şirket hesabı ile giriş yapan kişiyi ayırın

Bir şirketin birden fazla çalışanı olabilir. Her çalışanın aynı yetkiye ve aynı kayıt kapsamına sahip olması gerekmez. Kullanıcı kimliği, bağlı şirket ve işlem yapılan şube ayrı ilişkiler olarak düşünülmelidir. Bir e-posta adresinin varlığı tek başına hangi şirket adına sipariş verilebileceğini belirlemez.

Örneğimizde şube satın alma sorumlusu kendi talebini hazırlıyor, merkezdeki yetkili daha geniş onay yetkisi taşıyor. Yeni kullanıcı davet edildiğinde kimliğin hangi şirket ve şubeye bağlanacağı açık olmalıdır. Çalışan ayrıldığında erişimin kapatılması da süreç ister. Hesap sahipliği ve rol değişikliği yalnızca destek ekibinin serbest notuyla yönetilmemelidir. Hangi kayıtların görüleceği ve hangi işlemlerin yapılacağı anlaşılır bir yetki tablosunda tanımlanabilir. Gerçek hesaplarla test bu tabloyu doğrular.

Şube bağlamını alışverişin başında belirleyin

Aynı şirketin şubeleri farklı teslimat adresi veya ticari koşul kullanabilir. Kullanıcının hangi bağlamda alışveriş yaptığı belli değilse doğru fiyat ve sevkiyat üretmek zorlaşır. Seçim gerekiyorsa görünür olmalı, varsayılan bağlam varsa nedeni ve değiştirilebilirliği anlaşılmalıdır. Şirket adı tek başına yeterli bilgi olmayabilir.

Şube değiştiğinde açık sepetin ne olacağı düşünülmelidir. Fiyat listesi ve uygun ürünler farklıysa eski seçimleri sessizce yeni koşula taşımak yanlış beklenti yaratabilir. Miktar veya fiyat değişimi açıkça anlatılabilir. Ayrıca teslimat adresinin hangi yetkiyle değiştirileceği tanımlanır. Onaylanan tek seferlik adres ile kalıcı şirket adresi farklı kayıt ihtiyaçları taşıyabilir. İşletmenin gerçek modeli tasarım kararını yönlendirmelidir; panelin hazır alanları iş kuralını belirlememelidir.

Bayi kabulünü yetki ve fiyat atamasına bağlayın

Başvuru alınması, hesabın bütün ürünleri ve fiyatları görmeye hazır olduğunu söylemez. İnceleme, onay, eksik bilgi ve reddetme gibi durumlar bulunabilir. Kullanıcının hangi aşamada ne göreceği açık olmalıdır. Bekleyen başvuruyu aktif bayi gibi işlemek hem ticari hem erişim hatası yaratabilir.

Onaydan sonra hangi işlem tetikleniyor?

Şirket ve şube kaydı oluşturma, kullanıcı bağlama ve fiyat listesi atama ayrı adımlar olabilir. Bunlardan biri eksik kalırsa hesabın giriş yapması yeterli olmaz. Testte başvuru formuyla başlayıp ilk doğru fiyatlı sepete kadar ilerleyin. Bildirim metni gerçek durumu anlatsın. “Hesabınız açıldı” mesajı, fiyat ve izinler henüz tamamlanmamışken yanlış beklenti oluşturabilir. Kimin onay verdiği ve neyin değiştiği işlem geçmişinde anlaşılır biçimde görülebilir. Yetki ataması önemli bir iş sonucudur.

Fiyat kuralını açık bir öncelik düzeniyle kurun

Müşteriye özel fiyat, bayi grubu, ürün miktarı veya dönemsel koşul bir arada bulunabilir. Hangisinin hangi durumda uygulanacağı belirlenmelidir. “En uygun fiyatı ver” gibi geniş bir ifade bazı ticari kuralları açıklamaz. Aynı ürün birden fazla listede bulunursa sonuç nasıl seçilecek? Bu karar onaylı iş politikasına dayanmalıdır.

Fiyatın kaynağı ve değişiklik sahibi belli olmalıdır. Dış sistem güncel fiyatı belirliyorsa panelde elle değiştirilen değerle çelişki çıkabilir. Katalog, fiyat ve kampanya farklı veri katmanlarıdır. Müşterinin gördüğü tutarla siparişe kaydedilen tutar aynı koşulu yansıtmalıdır. B2B e-ticaret geliştirmede örnek şirket ve ürünlerle fiyat tablosu hazırlamak, belirsiz kuralı canlıda çözmeye çalışmaktan daha somut yöntemdir. Tutarlar ve hesaplama gerçek ticari yetkililer tarafından doğrulanır.

Miktar ve paket kurallarını veriyle ilişkilendirin

Toptan siparişte adet, koli veya farklı satış birimi kullanılabilir. Müşterinin girdiği sayının neyi temsil ettiği açık olmalıdır. Minimum miktar veya artış adımı varsa seçilen ürünle ilişkili gösterilebilir. Birimi küçük yazıyla saklamak yanlış siparişe neden olabilir. Veri ve arayüz aynı anlamı taşımalıdır.

Koli içeriği değiştiğinde fiyat ve stok ilişkisinin nasıl güncellendiğini inceleyin. Bir koli ile içindeki adetleri aynı stok kalemi gibi düşünmek her modelde doğru olmayabilir. Sipariş çıktısında depo ne hazırlayacağını net görmelidir. Hızlı sipariş tablosu veya dosya yükleme varsa satır doğrulama ve yanlış ürün kodu senaryoları denenir. Hatalı birkaç satırın bütün siparişi nasıl etkilediği de belirlenmelidir. Toplu giriş kolaylığı, kontrol ihtiyacını ortadan kaldırmaz.

Sipariş onayını gerçek karar noktası olarak tasarlayın

Bazı müşteri veya tutarlarda sipariş önce yetkili incelemesine gidebilir. Bunun hangi kuralla tetiklendiği ve kimlerin karar verebildiği tanımlanmalıdır. Onay bekleyen kayıtla hazırlanacak kesin sipariş aynı şey değildir. Depo ve müşteri ekranı bu farkı görmelidir.

Onaylayan kişi ürün veya miktar değiştirirse ne olur? Yeni fiyat müşteriye gösterilecek mi, tekrar onay gerekecek mi? İşletmenin çalışma biçimine göre belirlenir. Onay reddi, geri gönderme ve bekleyen durumlar açıklanmalıdır. Tek bir onay düğmesi bütün kararları temsil etmeyebilir. Bekleyen işin kimde olduğunun görülmesi operasyonu kolaylaştırır. Bildirim gönderilmesi kararın verildiği anlamına gelmez; süreç gerçek onay olayıyla ilerlemelidir. Süre baskısı sorumluluk sınırlarını belirsizleştirmemelidir.

Sepet ile onay anı arasındaki değişiklikleri ele alın

Fiyat veya stok, talep hazırlanırken ve onaylanırken değişebilir. Hangi aşamada hangi koşulun bağlayıcı kayda dönüştüğü onaylı ticari düzenle belirlenir. Yazılım bunun sonucunu açıkça uygulamalıdır. Müşterinin eski gördüğü fiyatı açıklamasız yenisiyle değiştirmek anlaşmazlık yaratabilir.

Kurgusal tedarikçimizde merkez incelemesi sırasında ürünün kullanılabilir miktarı azalırsa bekleyen talebin ne olacağı düşünülür. Rezervasyon, yeniden değerlendirme veya ilgili başka yöntem ihtiyaca göre seçilebilir. Her yaklaşımın sonucu görünür olmalıdır. İşlem geçmişi, müşterinin ne gönderdiğini ve hangi sonucun onaylandığını ayırt edebilir. Güncel ürün kaydıyla satın alma anındaki bilgi aynı ihtiyaç değildir. Geçmişi araştıran ekip doğru ilişkiyi bulabilmelidir; yalnızca son değerleri görmek yeterli kalmayabilir.

Ödeme koşulunu sipariş durumundan ayrı yönetin

B2B ilişkide farklı ödeme düzenleri bulunabilir. Bunların ticari ve finansal uygunluğu ilgili yetkililere aittir. Yazılım tarafında hangi koşulun hangi şirkete veya şubeye uygulandığı ve müşterinin ne gördüğü net olmalıdır. Sipariş onayı, ödeme doğrulaması ve sevkiyat izni farklı olaylar olabilir.

Bir hesap için yetkili kontrol gerekiyorsa otomatik akış bunu atlamamalıdır. Dış sistemde tutulan ilgili bilgi güncellenemiyorsa kesinti davranışı belirlenir. Bu yazı vadeli satış veya limit belirleme önerisi sunmaz. Amaç, onaylanmış koşulların belirsiz panel etiketleriyle kaybolmamasıdır. Müşteri mesajları ve ekip ekranları aynı gerçeği anlatmalıdır. Değişikliğin kim tarafından yapıldığı ve sonraki işlemleri nasıl etkilediği kayıtlı olabilir. İş kuralı teknik varsayım olarak gizlenmemelidir.

Özel fiyatı yalnızca görünümle korumayın

Bir alanı arayüzde gizlemek gerçek erişim kuralının tamamı değildir. Kullanıcıya hangi şirketin fiyatı ve siparişi verilebileceği sunucu tarafında da doğru denetlenmelidir. Aynı hesabın şube değiştirmesi veya yetkisinin kaldırılması durumları test edilmelidir. Fiyatın kamuya açık olması mı özel kalması mı gerektiği baştan belirlenir.

Denemede yetkili ve yetkisiz uygun hesaplar kullanılabilir. Bir şirketin kaydına erişim başka şirketin verisini açmamalıdır. Önbellek ve oturum bağlamı da kullanılan yapıya göre incelenir. Teknik ekibin kapsamlı güvenlik çalışması ayrı olabilir; günlük kabul testi en azından onaylı yetki tablosunu doğrulamalıdır. Bayi portalı tasarımında kolay giriş kadar doğru veri sınırı da önemli gereksinimdir. İşlev ve koruma birlikte değerlendirilmelidir.

Entegrasyonları şirket ve sipariş kimliğiyle eşleyin

Muhasebe, stok veya başka sistem bağlantısında hangi şirket ve şubenin hangi dış kayda karşılık geldiği bilinmelidir. İsim benzerliği tek başına güvenilir eşleştirme değildir. Kararlı kimlik ve onaylı ilişki veri aktarımını destekler. Kullanıcı hesabının şirket hesabıyla aynı dış varlık sayılması hataya yol açabilir.

Sipariş aktarımında tekrar, eksik bilgi ve kısmi hata durumları denenebilir. Onay bekleyen kayıt dışarıya kesin işlem gibi gönderilmemelidir; gerçek iş kuralı neyse uygulanır. Fiyat kaynağı veya müşteri koşulu güncellendiğinde hangi alanın yetkili olduğu belli kalmalıdır. Sorun çıktığında çalışan hangi kaydın araştırılacağını görebilmelidir. Entegrasyonun bağlı görünmesi şirket, fiyat ve sipariş ilişkilerinin doğru olduğu anlamına gelmez. Temsil edici işlemle uçtan uca kontrol gerekir.

Pilot çalışmayı farklı yetkilerle tamamlayın

Bir şirket, iki şube, farklı rol ve birkaç ürünle küçük bir pilot oluşturulabilir. Başvuru, onay, fiyat görüntüleme, şube değiştirme, miktar kuralı ve sipariş incelemesi denenir. Başarılı örneğin yanında reddedilen veya eksik işlem de bulunmalıdır. Her senaryoda beklenen durum ve sorumlu yazılabilir.

Pilotun çıktısı onaylanmış kurallar, görülen sınırlamalar ve açık sorulardır. Büyük müşteri listesi aktarılmadan yanlış ilişkiyi düzeltmek daha yönetilebilir olur. B2B e-ticaret yazılımı, bir mağazaya bayi etiketi eklemekle tamamlanmaz. Doğru kişinin doğru şirket bağlamında doğru fiyat ve onay yoluyla işlem yapabilmesi gerekir. Bu ilişki açık olduğunda müşteri deneyimi, finans ve depo aynı siparişin hangi aşamada olduğunu daha tutarlı biçimde anlayabilir.

Sık Sorulan Sorular

Bayi girişi eklemek B2B için yeterli mi?

Giriş yalnızca başlangıçtır. Şirket, kullanıcı, şube, fiyat ve onay ilişkileri gerekir. Günlük sipariş akışı bu kuralları doğru uygulamalıdır. Bir ekranın varlığı bütün ticari ve erişim ihtiyaçlarının karşılandığını göstermez.

Aynı şirkette farklı kullanıcı yetkileri olabilir mi?

Gerçek ihtiyaç varsa farklı roller tanımlanabilir. Kimin sipariş hazırladığı, kimlerin geniş geçmişi gördüğü ve kimin onay verdiği açık olmalıdır. Yetki tablosu uygun test hesaplarıyla doğrulanmalıdır; bütün kullanıcıların aynı hesabı paylaşması çözüm sayılmamalıdır.

Bayi fiyatı hangi listeden seçilmeli?

İşletmenin onaylı öncelik kuralına bağlıdır. Şirket, grup, miktar veya dönemsel koşul bir arada olabilir. Yazılım bu kuralı tutarlı uygulamalı ve kullanılan fiyat kaynağı anlaşılmalıdır. Genel bir “en iyi fiyat” ifadesi yeterli tanım değildir.

Onay beklerken fiyat değişirse ne olur?

Hangi aşamada hangi fiyatın geçerli olduğu ticari düzenle belirlenmelidir. Değişiklik ve gerekirse yeniden onay kullanıcıya açık anlatılır. Eski talep ile son onaylı koşulun kaydı ayırt edilebilmelidir; sessiz değişiklik yanlış beklenti yaratabilir.

Özel fiyatı sadece ekranda gizlemek yeterli mi?

Gerçek erişim kuralı ilgili sunucu isteklerinde de uygulanmalıdır. Yanlış şirket veya şube verisine ulaşılmadığı test edilir. Arayüz görünümü, yetkilendirmenin tamamı olarak kabul edilmemelidir.

İlk B2B testinde hangi senaryolar olmalı?

Başvuru ve onaydan doğru fiyatlı siparişe uzanan yol denenebilir. Farklı şube, rol, miktar ve bekleyen onay örnekleri eklenir. Entegrasyon ve yetki sınırı da kontrol edilerek yalnızca en kolay satış senaryosuyla yetinilmez.