Bayi Portalında Fiyat, Yetki ve Sipariş Tasarımı

Bir bayi birden fazla şubeye ve kullanıcıya sahip olabilir. Fiyat grubunun bayiye mi şubeye mi atandığını, sipariş limitinin hangi seviyede uygulandığını yazın. Kullanıcının şirket değiştirmesi veya birden fazla şubede çalışması için üyelik modelini belirleyin.

Kurgusal örneğimizde bayi ana hesabı fiyat grubunu taşır; şube teslimat adresini belirler; kullanıcı ise hazırlayan veya onaylayan rolündedir. Bu tercih her işletmeye uygulanacak kural değildir. Gerçek organizasyonunuzdaki istisnaları ilk kapsam görüşmesinde ortaya çıkarın.

Liste fiyatı, bayi grubu indirimi, kampanya ve müşteriye özel fiyat aynı anda mevcut olabilir. Hangi kuralın öncelikli olduğunu ve indirimlerin birlikte uygulanıp uygulanmayacağını açıklayın. Kullanıcıya gösterilen para birimi, vergi ve geçerlilik tarihi anlaşılır olsun.

Ürün sepete eklendikten sonra fiyat veya stok değişebilir. Sipariş onayında hangi bilgilerin yeniden kontrol edileceğini belirleyin. Tutar değişmişse kullanıcıya sessizce farklı toplam göstermek yerine değişikliği açıklayıp onay alın.

Siparişin oluştuğu anda kabul edilen satır fiyatı, miktar, para birimi ve uygulanan kural bilgisi kayıt altında tutulmalıdır. Daha sonra liste fiyatı değiştiğinde geçmiş siparişin toplamı yeniden hesaplanarak değişmemelidir. Teklifin belirli süre geçerli olması gerekiyorsa bu ayrı bir süreç olarak modellenebilir.

Bayi çalışanı siparişi hazırlayabilir, yetkili kişi onaylayabilir. Onay limiti, teslimat adresi değişikliği ve sipariş iptali için ayrı kurallar gerekebilir. Kullanıcı rolünü değiştiren işlemden sonra açık oturumun yeni yetkileri nasıl uygulayacağını test edin.

Cari limit veya vade kontrolü varsa bilginin hangi sistemden geldiğini ve güncellik sınırını yazın. ERP erişilemediğinde işlem bekletilecek mi yoksa yetkili incelemesine mi gidecek? Bu davranış teknik ekibin tahminine bırakılmamalıdır. Portal iş sahibinin belirlediği politikayı tutarlı uygulamalıdır.

Onaylanmış bir sipariş henüz ERP’ye ulaşmamış olabilir. Bayiye ve operasyon ekibine gösterilecek durumları ayırın. Aktarım zaman aşımına uğradığında aynı siparişin tekrar gönderilmesi ikinci kayıt oluşturmamalı; sabit dış referansla sonuç doğrulanmalıdır.

ERP’de reddedilen sipariş için açıklanabilir bir süreç bulunmalıdır. Ürün eşlemesi yok, teslimat adresi eksik veya fiyat bilgisi uyuşmuyor gibi durumlarda kaydı kimin düzelteceği belirli olsun. İptalin aktarımı da başlangıçtaki sipariş kadar izlenebilir olmalıdır.

İki farklı bayi grubu, bir hazırlayan ve bir onaylayan kullanıcıyla kurgu test verisi hazırlayın. Aynı ürüne uygulanan kuralları ve sunucu tarafındaki kontrolleri karşılaştırın. Sadece ekran görüntüsü üzerinden fiyat ve yetki doğrulaması yapmayın.

İlk sürümde ürün görme, doğru fiyatı alma, sipariş hazırlama, gerekli onay ve operasyon takibi uçtan uca çalışsın. Gelişmiş rapor veya puan sistemi bu döngü için zorunlu değilse sonraki aşamada değerlendirilebilir.

Müşteri portalı yetki rehberi erişim matrisini; ERP stok ve sipariş rehberi veri akışını tamamlar. Kararlarınızı brief oluşturucuyla yazılı kapsama dönüştürün.