B2B bayi portalı, bayilerin ürün görüp sipariş verdiği bir ekranın ötesinde, işletmenizin ticari kurallarını çalıştıran bir sistemdir. Hangi bayinin hangi fiyatı göreceği, kimlerin sipariş vereceği ve hangi işlemlerin onay bekleyeceği yazılım başlamadan belirlenmelidir. Aksi halde proje ilerledikçe her istisna yeni bir geliştirme talebine dönüşür.
İhtiyaç dosyasına “Bayi girişi olsun” yazmak yerine gerçek bir siparişin bugün nasıl ilerlediğini anlatın. Satış temsilcisinin yaptığı kontroller, muhasebenin verdiği onaylar ve depodaki işlemler portal kapsamını ortaya çıkarır.
Bayi hesabı ile kullanıcı hesabını ayırın
Bir bayi işletmesinde birden fazla çalışan olabilir. Satın alma personeli sipariş hazırlarken yönetici onay verebilir; muhasebe kullanıcısı yalnız hesap bilgilerini inceleyebilir. Bu nedenle firma, şube ve kullanıcı ilişkilerini baştan tanımlamak gerekir.
Dikkat: Yetkiyi yalnız menüleri gizleyerek yönetmeyin. Kullanıcının başka bayiye ait siparişe veya belgeye erişemediği sistem düzeyinde doğrulanmalıdır. OWASP'ın yetkilendirme rehberi, en az gerekli izin yaklaşımını ve her istekte yetki kontrolünü vurgular. [2]
Örnek olarak iki şubeli bir distribütörü düşünün. Şubeler ayrı teslimat adresi ve satın alma limiti kullanıyorsa tek bir genel kullanıcı bu ihtiyacı karşılamayabilir. Firma yöneticisi bütün şubeleri görebilirken şube çalışanının erişimi kendi kapsamıyla sınırlanabilir. Bu bir tasarım örneğidir; gerçek roller işletmenin işleyişinden çıkarılmalıdır.
Fiyat kuralları hangi sırayla uygulanacak?
Liste fiyatı, bayi indirimi, özel anlaşma, adet indirimi ve kampanya aynı siparişte karşılaşabilir. Öncelik sırası tanımlanmadığında portalın gösterdiği fiyatla satış ekibinin verdiği fiyat farklılaşır. “En yüksek indirim geçerli” gibi bir kural dahi yazılı ve test edilebilir olmalıdır.
| Kural alanı | Netleştirilecek soru |
|---|---|
| Fiyat kaynağı | ERP, portal veya ayrı fiyat listesi mi esas alınacak? |
| Bayi grubu | Hangi müşteriler hangi fiyatları görecek? |
| Adet koşulu | Alt sınır, koli içi adet ve fiyat kademesi nasıl uygulanacak? |
| Kampanya | Özel fiyatla birlikte kullanılabilecek mi? |
| Para birimi | Hangi kur ve tarih esas alınacak? |
| Vergi gösterimi | Fiyatın kapsamı müşteriye nasıl açıklanacak? |
Shopify'ın B2B katalog belgeleri de ürün erişimi ve fiyatların müşteri gruplarına göre düzenlenebildiği bir uygulama örneği sunar. Özelliklerin kapsamı kullanılan plana ve kurulum modeline bağlıdır. [1] Aynı iş kuralının her altyapıda aynı biçimde hazır bulunduğunu varsaymayın.
Sipariş, teklif ve onay akışını birbirinden ayırın
Her bayi talebi doğrudan kesin siparişe dönüşmeyebilir. Özel üretim, yüksek tutar veya stok belirsizliği gibi durumlarda teklif ve onay aşaması gerekebilir. Portalda müşterinin hangi işlemi tamamladığını açıkça gösterin.
İpucu: Örneğin “Siparişiniz alındı” mesajıyla “Talebiniz onay için gönderildi” mesajı aynı anlamı taşımaz. Bayi üretimin başladığını düşünürken içeride fiyat onayı bekleniyorsa iletişim sorunu oluşur. Sipariş durumları, bildirim metinleri ve ekip sorumlulukları aynı akışa göre hazırlanmalıdır.
Kullanılabilir limit ve cari bakiye de ayrı kavramlardır. Limit hesabında açık siparişlerin, tahsilatların veya bekleyen belgelerin nasıl ele alınacağı işletmeye göre değişebilir. ERP sistemlerinin işleyişi hakkındaki içerik, portalda görünen rakamların hangi operasyonel kayıtlara dayandığını değerlendirmek için başlangıç sağlar.
ERP bağlantısında hangi verinin sahibi kim?
Ürün, stok, fiyat ve müşteri bilgilerinin hangi sistemde değiştirileceği belirlenmelidir. Aynı alanın iki sistemde serbestçe düzenlenmesi, son güncellemenin diğerini silmesine yol açabilir. Entegrasyonun yönü ve güncelleme koşulları her veri türü için ayrı yazılmalıdır.
Bağlantının varlığı kadar hata durumundaki davranışı da sorun. ERP erişilemiyorsa sipariş alınacak mı, fiyat eskiyse ne gösterilecek, bekleyen kayıtları kim görecek? RESTful API rehberi, sistemler arasında veri alışverişinin temel mantığını açıklar; iş kurallarının ayrıca tanımlanması gerektiğini unutmayın.
İlk sürüm hangi işleri tamamlamalı?
İlk sürümü bütün isteklerin biriktiği bir listeye dönüştürmeyin. Bayinin oturum açması, doğru kataloğu görmesi, geçerli fiyatla sipariş hazırlaması ve süreci takip etmesi temel akışı oluşturabilir. Teklif gerektiren sektörlerde bu akış farklı kurulabilir.
Geliştirme yöntemini seçerken hazır paket ve özel yazılım karşılaştırmasını gerçek ihtiyaçlarla birlikte değerlendirin. Hazır özelliklerin kullanılması bakım yükünü azaltabilir; özel kurallar ise ek geliştirme gerektirebilir. Karar yalnız başlangıç ücretine değil, değişiklik ve işletim ihtiyacına dayanmalıdır.
Proje tesliminde hangi senaryolar denenmeli?
Farklı fiyat grubundaki iki bayi, yetkisi sınırlı kullanıcı, limit aşan sipariş, kısmi stok ve iptal senaryolarını test edin. Testin beklenen sonucu önceden yazılı olmalıdır. “Ekran açılıyor” kontrolü ticari kuralların çalıştığını göstermez.
Teslimde denenecek senaryolar
- Farklı fiyat gruplarındaki iki bayi kendi fiyatını görüyor.
- Yetkisi sınırlı kullanıcı başka şubenin siparişini ve belgesini açamıyor.
- Limiti aşan sipariş onay aşamasına düşüyor.
- Kısmi stok ve iptal senaryoları ERP'ye doğru yansıyor.
- Her testin beklenen sonucu önceden yazıya geçirildi.
WebAction'ın B2B yazılım hizmeti için mevcut sipariş akışınızı, bayi gruplarınızı ve kullandığınız ERP'yi paylaşabilirsiniz. Bu bilgiler, portal teklifinin ekran sayısından önce iş kapsamına göre hazırlanmasını sağlar.
Sık sorulan sorular
B2B portalında her bayiye farklı fiyat verilebilir mi?
Uygun altyapı ve iş kurallarıyla mümkündür. Fiyatın kaynağı, müşteri grubu ve indirim öncelikleri proje başında belirlenmelidir.
Bir bayinin birden fazla kullanıcısı olabilir mi?
Evet. Firma ve kullanıcı ilişkileri buna göre tasarlanabilir. Her kullanıcının görme, sipariş verme ve onaylama yetkisi ayrı tanımlanmalıdır.
Portalın ERP olmadan kurulması mümkün mü?
Mümkündür; ancak ürün, stok, fiyat ve hesap bilgilerinin nerede yönetileceği net olmalıdır. Sonradan kurulacak entegrasyonun ihtiyaçları da baştan değerlendirilmelidir.
Proje için önce ekran tasarımı mı yapılmalı?
Önce temel roller ve iş akışları netleşmelidir. Tasarım bu kuralları anlaşılır biçimde kullandıracak şekilde hazırlanır; aksi halde ekranlar sonradan sık sık değişebilir.
Kaynaklar
- Shopify — B2B katalog ve fiyatlandırma örneği (17.10.2026)
- OWASP — Yetkilendirme ilkeleri (17.10.2026)
