B2B E Ticaret Sağlayıcısı Seçerken Bayi Onayı ve Kredi Limiti Akışları Nasıl Test Edilir?

B2B E Ticaret Sağlayıcısı Seçimi Neden Senaryoyla Test Edilmeli?

B2B e ticaret sağlayıcısı seçimi senaryoyla test edilmelidir çünkü bir özelliğin menüde bulunması, şirketinizin onay, yetki ve finans kurallarını doğru uyguladığını kanıtlamaz. İş akışı testi, başlangıç verisinden beklenen sonuca kadar kullanıcı rolleri, karar noktaları, entegrasyonlar ve hata durumlarının birlikte doğrulanmasıdır. Bu yaklaşım, hazırlanmış sunum ekranları yerine sistemin gerçek operasyon koşullarındaki davranışını görünür hale getirir.

Özellik listesinden kabul senaryosuna geçmek

Genel firma yeterliliğini incelerken B2B e-ticaret firması seçim kriterleri temel çerçeveyi oluşturabilir; ancak nihai karşılaştırma için her kriter bir test adımına dönüştürülmelidir. Örneğin “bayi onayı var” ifadesi yerine başvurunun kim tarafından görüldüğü, hangi belgeler olmadan ilerlemediği, hangi durumda reddedildiği ve onay sonrası hangi ticari koşulların hesaba işlendiği gösterilmelidir. Böylece sağlayıcının hazır özelliği ile özel geliştirme gerektiren alanlar ayrışır.

• Başlangıç verisini ve beklenen sonucu önceden yazılı hale getirin.
• Her senaryoda işlemi yapacak kullanıcı rolünü tanımlayın.
• Normal akış kadar ret ve hata durumlarını da çalıştırın.
• Manuel müdahale gereken adımları ayrıca kaydedin.
• Test bulgularını teklif kapsamındaki maddelerle eşleştirin.

“Kalite, gereksinimlere uygunluktur.” - Philip B. Crosby

Bayi Başvurusu ve Hesap Onayı Uçtan Uca Nasıl Sınanır?

Bayi başvurusu, formun gönderilmesinden hesabın sipariş verebilir duruma gelmesine kadar bütün onay adımlarıyla sınanmalıdır. Sağlayıcı yalnızca bir başvuru formu göstermemeli; eksik belge, hatalı bilgi, mükerrer kayıt, reddedilen başvuru ve yeniden değerlendirme gibi durumlarda sistemin ne yaptığını da göstermelidir. Onay zincirinin satış, finans ve operasyon gibi farklı ekipleri kapsaması halinde görevlerin doğru kişilere yönlendiği ayrıca doğrulanmalıdır.

Rol ve durum değişikliklerini birlikte kontrol etmek

Test sırasında başvurunun hangi statülerden geçtiği, hangi kullanıcıya atandığı ve onay sonrasında fiyat grubu, ödeme koşulu veya kullanıcı yetkisinin nasıl tanımlandığı izlenmelidir. Bildirimlerin yalnızca ekranda görünmesi yeterli değildir; hangi olayın hangi kullanıcıya bildirim ürettiği de açıklanmalıdır. Satın alma ekibi, sağlayıcının standart akışını kendi süreçlerine benzetmek için kaç ayar gerektiğini ve hangi noktaların ek geliştirme istediğini bu aşamada not etmelidir.

• Eksiksiz ve eksik belgeli iki ayrı bayi başvurusu çalıştırın.
• Birinci ve ikinci onayın farklı rollere atanabildiğini doğrulayın.
• Ret nedeninin kaydedilip doğru kişilere iletildiğini kontrol edin.
• Onay sonrası ticari koşulların hesaba otomatik işlenmesini sınayın.
• Mükerrer başvuruda sistemin uyarı ve birleştirme davranışını gözlemleyin.

Kredi Limiti Kaynağı ve Veri Güncelliği Nasıl Test Edilir?

Kredi limiti testi, limitin hangi sistemde ana kayıt olarak tutulduğunu ve B2B portalına hangi kuralla aktarıldığını açıkça göstermelidir. Limit ERP, muhasebe yazılımı veya başka bir finans servisinden geliyorsa tek doğru veri kaynağı belirlenmeli; portalın cari bakiye, açık sipariş, tahsilat ve kullanılabilir limit hesabında hangi alanları kullandığı açıklanmalıdır. Aynı bayi için farklı sistemlerde farklı değer görünmesi, sipariş kararını doğrudan etkileyen kritik bir uyumsuzluktur.

Kaynak sistemi senkronizasyon hızından ayırmak

ERP entegrasyonlu B2B e-ticaret yapısı değerlendirilirken kredi limitinin yalnızca okunup okunmadığına değil, ne zaman güncellendiğine ve hangi hata politikasının uygulandığına bakılmalıdır. Kaynak sistemde limit değiştirildikten sonra portalın eski değeri ne kadar süre gösterebildiği, entegrasyon geciktiğinde siparişin durup durmadığı ve veri geri geldiğinde hesaplamanın nasıl yenilendiği test edilmelidir. Bu ayrım entegrasyonun teknik olarak çalışması ile ticari olarak güvenilir olması arasındaki farkı gösterir.

• Kredi limitinin ana kaynağını ve kullanılan alanları tanımlayın.
• Açık sipariş ve tahsilatın kullanılabilir limite etkisini test edin.
• Kaynak sistemde limit değiştirip portal güncellemesini izleyin.
• Eski, boş ve çelişkili veri durumlarını ayrı ayrı çalıştırın.
• Bağlantı kesildiğinde uygulanacak varsayılan sipariş politikasını doğrulayın.

Limit Aşıldığında B2B Sipariş Akışı Nasıl Davranmalı?

Limit aşıldığında sipariş davranışı şirketin finans ve risk politikasına göre açık biçimde tanımlanmalı ve test edilmelidir. Sistem siparişi tamamen engelleyebilir, taslakta tutabilir, finans onayına gönderebilir veya belirli koşullarda istisna talebi oluşturabilir. Hangi yöntem seçilirse seçilsin bayi ekranındaki mesaj, arka ofisteki sipariş statüsü ve ERP’ye aktarılacak kayıt birbiriyle tutarlı olmalıdır; aksi halde ekipler aynı siparişi farklı durumlarda görebilir.

Sınır değerlerini ve istisnaları aynı testte görmek

Yalnızca limiti belirgin biçimde aşan bir sipariş kullanmak yeterli değildir. Limitin hemen altında, tam eşit ve hemen üzerinde kalan sepetler denenerek vergi, iskonto, para birimi, bekleyen sipariş ve yuvarlama etkileri kontrol edilmelidir. Ayrıca tek siparişlik yönetici onayı verildiğinde bu kararın bayi hesabının kalıcı limitini değiştirip değiştirmediği görülmelidir. Böylece finans ekibi ile satış ekibinin beklediği davranış teklif aşamasında aynı tanıma bağlanır.

• Limit altı, limite eşit ve limit üstü siparişleri karşılaştırın.
• Sepet değiştikçe kullanılabilir limitin yeniden hesaplandığını kontrol edin.
• Bloke siparişin tüm kullanıcı ekranlarında aynı statüde görünmesini doğrulayın.
• İstisna onayı sonrası siparişin nasıl ilerlediğini kaydedin.
• İptal veya tahsilat sonrası limitin ne zaman serbest kaldığını test edin.

Satış Temsilcisinin Bayi Adına Yetkisi Nasıl Sınanır?

Satış temsilcisinin bayi adına işlem yetkisi varsa bu fonksiyon rol sınırları, işlem kapsamı ve kayıt izi açısından test edilmelidir. Temsilcinin hangi bayileri görebildiği, bayi adına sepete ürün ekleyip ekleyemediği, taslak hazırlayıp hazırlayamadığı ve siparişi doğrudan tamamlayıp tamamlayamadığı ayrı izinler olarak ele alınmalıdır. Vekâleten işlem satış ekibine hız kazandırabilir; ancak fiyat, iskonto veya ödeme koşulu üzerinde gereğinden geniş yetki verilmesi ticari kontrolü zayıflatabilir.

Bayi deneyimini iç kullanıcı yetkisinden ayırmak

Rol testinde portalın daha geniş işlev setini görmek için üretici ve toptancılar için B2B e-ticaret özellikleri de referans alınabilir. Temsilci bayi hesabı bağlamına geçtiğinde sistem bunun gerçek bayi oturumu olmadığını kaydetmeli ve yapılan işlemleri temsilcinin kullanıcı kimliğiyle ilişkilendirmelidir. Yetki kaldırıldığında açık oturumların, taslak sepetlerin ve devam eden siparişlerin nasıl davrandığı da test edilerek kullanıcı yaşam döngüsü tamamlanmalıdır.

• Temsilciyi yalnızca kendisine atanmış bayilerle sınırlandırın.
• Taslak oluşturma ve sipariş tamamlama izinlerini ayrı test edin.
• Fiyat, iskonto ve ödeme koşulu değiştirme yetkilerini doğrulayın.
• Vekâleten yapılan işlemde gerçek kullanıcı kimliğinin kaydedildiğini kontrol edin.
• Yetki kaldırıldıktan sonra açık oturumların davranışını sınayın.

Yönetici İstisna Onayı ve Denetim İzi Nasıl Doğrulanır?

Yönetici istisna onayı, standart kuralın dışına çıkılan her durumda yetki seviyesi, gerekçe ve denetim iziyle doğrulanmalıdır. Kredi limiti aşımı, özel iskonto, bekleyen belge veya riskli hesap gibi koşullarda kimin ne kadar yetkili olduğu tanımlanmalı; eşik aşıldığında talebin başka bir yöneticiye yönlenip yönlenmediği gösterilmelidir. Onayın sonucu kadar, kararın kim tarafından ve hangi koşul üzerinden verildiğinin sonradan izlenebilmesi de önemlidir.

Tek seferlik kararı kalıcı hesap değişikliğinden ayırmak

Demo sırasında aynı istisna iki farklı biçimde denenmelidir. Birincisinde yalnızca ilgili sipariş onaylanmalı, ikincisinde bayi hesabının kredi koşulu kalıcı olarak değiştirilmelidir. Sistem bu iki kararı ayrı izinlerle yönetebiliyor ve geçmiş değerleri saklayabiliyorsa denetim daha sağlıklı yapılabilir. Ayrıca reddedilen talebin hangi statüde kaldığı, yeniden başvuruya izin verilip verilmediği ve gerekçenin raporlara nasıl yansıdığı da satın alma ekibi tarafından kaydedilmelidir.

• Tek siparişlik istisna ile kalıcı limit değişikliğini ayrı test edin.
• Onay gerekçesinin zorunlu alan olarak tutulduğunu kontrol edin.
• Yetki eşiği aşılınca ikinci yöneticiye yönlendirmeyi sınayın.
• Reddedilen talebin sipariş statüsüne etkisini doğrulayın.
• Karar geçmişinde kullanıcı, zaman ve önceki değerlerin bulunduğunu inceleyin.

ERP Bağlantı Hataları ve Gecikmeler Nasıl Simüle Edilir?

ERP veya muhasebe bağlantısı yalnızca başarılı veri alışverişiyle değil, gecikme ve hata koşullarıyla da test edilmelidir. Sağlayıcıdan bağlantının geç yanıt verdiği, hiç yanıt vermediği, kısmi veri döndürdüğü veya aynı işlemin ikinci kez gönderildiği durumları göstermesi istenmelidir. Bu testler portalın kullanıcıya ne söylediğini, siparişi hangi statüde koruduğunu ve bağlantı geri geldiğinde veriyi nasıl uzlaştırdığını ortaya çıkarır.

Bağlantı kesildiğinde güvenli varsayılanı belirlemek

Her entegrasyon için “veri alınamazsa ne olur?” sorusunun iş birimleri tarafından önceden cevaplanması gerekir. Bazı şirketler son bilinen limit üzerinden geçici işlem yapmak isteyebilirken bazıları finans verisi doğrulanmadan sipariş kabul etmek istemeyebilir. Sağlayıcı bu politikayı yapılandırabiliyor mu, başarısız işlemleri kuyruğa alıyor mu, mükerrer kayıtları engelliyor mu ve manuel yeniden gönderime izin veriyor mu soruları pilot senaryosunda birlikte sınanmalıdır.

• Bağlantıyı zaman aşımına düşürerek kullanıcı mesajını kontrol edin.
• Kısmi veri döndüğünde eksik alanların nasıl ele alındığını test edin.
• Aynı sipariş tekrar gönderildiğinde mükerrer kayıt oluşmadığını doğrulayın.
• Otomatik tekrar deneme ve manuel yeniden gönderim seçeneklerini inceleyin.
• Uzlaştırma sonrası portal ve ERP kayıtlarının eşleştiğini kontrol edin.

Aday Sağlayıcılar Aynı Demo Senaryosuyla Nasıl Karşılaştırılır?

Aday sağlayıcılar aynı örnek veri, aynı kullanıcı rolleri ve aynı kabul kriterleriyle çalıştırılan standart bir demo senaryosuyla karşılaştırılmalıdır. Her firmaya farklı sorular yöneltildiğinde sonuç sunum becerisinden etkilenebilir; aynı senaryo ise operasyonel uyumu görünür hale getirir. Satın alma ekibi her adım için özelliğin hazır mı, konfigürasyonla mı, entegrasyonla mı yoksa özel geliştirmeyle mi karşılandığını ayrı bir değerlendirme alanında kaydetmelidir.

Sunum kalitesini değil çözüm kapsamını karşılaştırmak

e-ticaret yazılımı tekliflerini karşılaştırma yaklaşımı, demo bulguları test sonuçlarıyla desteklendiğinde daha anlamlı hale gelir. “Var”, “uyarlanabilir” ve “geliştirilebilir” ifadeleri uygulama kapsamı açısından aynı değildir. Her başarısız veya kısmen başarılı senaryoda sağlayıcının önerdiği çözüm, sorumlu taraf, olası entegrasyon ihtiyacı ve kabul kriteri yazılı hale getirilmelidir. Böylece adaylar yalnızca fiyat veya arayüz üzerinden değil, gerçek iş akışını ne ölçüde karşılayabildikleri üzerinden kıyaslanır.

• Tüm adaylara aynı bayi, ürün, limit ve sipariş verisini verin.
• Her adımın beklenen sonucunu demo öncesinde tanımlayın.
• Hazır özellik, konfigürasyon ve özel geliştirme ayrımını kaydedin.
• Geçici çözüm ile kalıcı çözümü birbirinden ayırın.
• Açık kalan konular için yazılı teknik yanıt talep edin.

Test Sonuçları Teklif ve Pilot Kapsamına Nasıl Taşınır?

Test sonuçları teklif ve pilot kapsamına, her kritik akışın beklenen davranışı ve kabul kriteriyle birlikte yazılı olarak taşınmalıdır. Sağlayıcı gerçek veya üretime yakın veriyle pilot gösterebiliyorsa bu önemli bir doğrulama fırsatıdır; ancak müşteri verisi kullanılacaksa erişim, maskeleme ve kullanıcı yetkileri önceden sınırlandırılmalıdır. Pilot kabul kaydı, özelliğin yalnızca vaat edildiğini değil, tanımlı koşullar altında nasıl çalıştığını gösteren ortak referans olmalıdır.

Demo bulgusunu teklif maddesine dönüştürmek

portal yazılımı teklifinde teknik şartname yaklaşımı, test bulgularını teklif kapsamına taşımak için kullanılabilir. Her senaryoda sorumlu taraf, veri kaynağı, entegrasyon ihtiyacı, yapılandırma gereksinimi, kabul ölçütü ve canlıya geçiş ön koşulu belirtilmelidir. Böylece bayi onayı, kredi limiti, satış temsilcisi yetkisi ve yönetici istisnası gibi kritik işlevler genel bir “B2B modülü” ifadesinin altında kaybolmaz. Satın alma ekibi de adayların gerçek uygulama kapsamını aynı temel üzerinden karşılaştırabilir.

• Pilot için kontrollü veya anonimleştirilmiş örnek veri hazırlayın.
• Başarılı ve başarısız koşulları ayrı kabul maddelerine dönüştürün.
• Ek geliştirme gerektiren noktaları teklifte ayrıca belirtin.
• Entegrasyon sorumluluğunu ve hata politikasını yazılı hale getirin.
• Canlıya geçmeden önce aynı senaryoları kullanıcı kabul testinde tekrarlayın.