Aydınlatma metni yükleniyor…
B2B toplu sipariş sistemi; alıcının ürün kodu ve miktar listesini hızlı giriş tablosu, Excel/CSV dosyası, kayıtlı liste veya geçmiş sipariş üzerinden hazırlamasını; her satırı ürün, paket, fiyat, stok ve yetki kurallarıyla doğrulamasını; sonucu inceleyip tek bir kontrollü siparişe dönüştürmesini sağlayan akıştır. İyi bir çözüm yalnız “dosyayı sepete eklemez”; hangi satırın neden kabul edildiğini, düzeltildiğini, dışarıda bırakıldığını veya incelemeye gönderildiğini açıklar.
Bu rehber bayi kanalı, toptan satış, e-ticaret, operasyon ve bilgi teknolojileri yöneticileri için hazırlanmıştır. “Kumsal altı aşamalı toplu sipariş sözleşmesi” ve satır karar matrisi bu makale için geliştirilen özgün kapsam araçlarıdır. Belirli bir işlem süresi, dönüşüm artışı, hatasızlık veya ERP uyumu garanti edilmez; gerçek davranış katalog, fiyatlandırma, stok, kredi, onay ve entegrasyon kurallarına göre test edilmelidir.
Toplu sipariş tek bir ekran değil, dört farklı alıcı görevidir
B2B alıcı her zaman aynı yöntemle sipariş vermez. Ürünleri bilen ve birkaç kod girecek kullanıcı hızlı giriş satırlarını; çok sayıda ürünü kurum içi sisteminden çıkaran kullanıcı dosya yüklemeyi; renk–beden gibi varyantları birlikte alan kullanıcı matrisi; düzenli alıcı ise kayıtlı liste veya yeniden siparişi tercih edebilir.
Microsoft'un B2B hızlı ve toplu sipariş belgeleri de madde numarasıyla toplu giriş, varyant görünümü, sipariş şablonu ve sipariş geçmişinden yeniden siparişi ayrı yetenekler olarak ele alır. Buradaki tasarım ilkesi ürün bağımsızdır: farklı giriş yolları aynı ticari doğrulama ve sipariş oluşturma çekirdeğine bağlanmalıdır.
| Giriş yolu | Uygun kullanıcı görevi | Temel risk |
|---|---|---|
| Hızlı satır girişi | Bilinen ürün kodlarını ve miktarları klavyeyle girmek | Yanlış kod, tekrar satır, birim belirsizliği |
| Varyant matrisi | Renk, beden veya ölçü kombinasyonlarını birlikte seçmek | Yanlış varyant ve toplam miktar |
| Excel/CSV yükleme | Başka sistemden çıkarılan uzun listeyi aktarmak | Şema, karakter, formül, eski fiyat ve dosya güvenliği |
| Liste/yeniden sipariş | Sık alınan ürünleri veya eski siparişi başlangıç kabul etmek | Artık satılmayan ürün ve güncelliğini yitirmiş ticari koşul |
Kumsal altı aşamalı toplu sipariş sözleşmesi
Toplu siparişe bir dosya özelliği değil, kanıt üreten bir veri sözleşmesi olarak yaklaşın. Her yükleme veya hızlı giriş oturumu aşağıdaki altı aşamadan geçmelidir:
- Girdi kimliği: Oturum/dosya parmak izi, yükleyen hesap, zaman, kanal ve şablon sürümü.
- Şema eşleme: Ürün kodu, miktar, birim, istenen tarih, proje veya sevk adresi gibi alanların doğru sütunlarla eşlenmesi.
- Ürün kimliği çözümü: Müşteri kodu, kurum içi SKU, barkod, üretici kodu veya izinli alternatifin tek ürün/varyanta bağlanması.
- Ticari doğrulama: Satışa açıklık, minimum miktar, paket katı, stok davranışı, müşteri fiyatı, para birimi, kredi veya başka sipariş kuralları.
- Satır karar önizlemesi: Kabul, düzeltme, hariç tutma veya inceleme sonucu; eski ve yeni değerin kullanıcıya gösterilmesi.
- Değişmez gönderim: Kullanıcının onayladığı satır kümesinin sürümlü bir özetle tek sipariş komutuna dönüşmesi ve tekrar gönderimde çoğalmaması.
Bu sözleşme aynı çekirdeği Excel, yapıştırma, satır matrisi ve yeniden sipariş için kullanır. Böylece kanal değişse bile ürün ve ticari kural davranışı değişmez.
Dosya ve şablon sözleşmesini açıkça tanımlayın
“Excel destekleniyor” ifadesi tek başına gereksinim değildir. Desteklenen dosya türleri, azami boyut ve satır sayısı, şablon sürümü, karakter kodlaması, ondalık/binlik ayırıcı, tarih biçimi, başlık satırı, boş satır ve hücre davranışı belgelenmelidir.
RFC 4180, CSV kullanımında başlık satırının isteğe bağlı olabileceğini, kayıtların satırlara ayrıldığını ve virgül, satır sonu veya çift tırnak içeren alanların özel biçimde ele alınması gerektiğini belgeler. Ancak gerçek dosyalar farklı ayraç ve karakter kodlamaları içerebilir. Sistem biçimi tahmin ettiğinde sonucu kullanıcıya göstermeli; belirsizliği sessizce kabul etmemelidir.
İndirilebilir örnek şablonun sürümü dosyada görünür veya makinece okunur biçimde bulunmalıdır. Eski şablon yüklenirse sistem sütunları yanlış varsaymak yerine sürüm farkını açıklamalı ve yeniden eşleme sunmalıdır.
Dosya yükleme güvenliğini sipariş doğrulamasından ayırmayın
Toplu sipariş dosyası yetkili müşteri tarafından gönderilse bile güvenilir kabul edilmemelidir. Uzantı, içerik türü ve dosya imzası birlikte kontrol edilmeli; izinli tür listesi uygulanmalı; dosya adı sistem tarafından üretilmeli; boyut ve satır limitleri konmalı; ayrıştırma izole edilmelidir. Makro içeren veya gereksiz zengin özellik taşıyan dosyalar ayrıca değerlendirilmelidir.
OWASP File Upload Cheat Sheet, uzantıya tek başına güvenmemeyi, içerik türünü ve imzayı doğrulamayı, dosya adını değiştirmeyi, boyut sınırı koymayı ve dosyaları kontrollü depolamayı önerir. Sipariş projesinde amaç dosyayı yayınlamak değil ayrıştırmak olsa da, yükleme yüzeyi aynı güvenlik disiplinini gerektirir.
Sütun eşleme tahmin olabilir; karar kullanıcıya ait olmalı
Bir bayi “Ürün Kodu”, diğeri “Stok No”, bir başkası “Malzeme” başlığını kullanabilir. Sistem olası eşleşmeyi önerebilir; fakat ürün kodu ile açıklama veya adet ile koli sayısı gibi kritik alanları onaysız eşlememelidir.
| Alan | Doğrulama | Belirsizlikte davranış |
|---|---|---|
| Ürün kodu | Tek bir satışa açık ürün/varyant bulmalı | Adayları göster, kullanıcı seçsin |
| Miktar | Pozitif sayı, izinli hassasiyet | Satırı durdur; sıfır veya metni kabul etme |
| Birim | Ürün için izinli adet/koli/palet | Varsayılanı görünür göster veya sor |
| Sevk adresi/proje | Hesabın erişebildiği kayıt | Yetkisiz değeri reddet |
| İstenen tarih | Biçim ve iş kuralı | Ham değeri ve beklenen biçimi göster |
Sütun eşleme profilleri müşteri veya kaynak sistem bazında kaydedilebilir; ancak değişiklik geçmişi ve son doğrulama tarihi tutulmalıdır.
Ürün kimliğini çözmeden fiyat ve stok hesaplamayın
Bir kodun birden fazla ürüne, varyanta veya eski ürüne bağlanması sessiz seçime yol açmamalıdır. Kimlik çözüm sırasını tanımlayın: müşteri ürün kodu, kurum SKU'su, barkod, üretici kodu ve onaylı eşdeğer. Her eşleşmenin kaynağı ve güven düzeyi görünür olmalıdır.
Artık satılmayan ürün için otomatik muadil eklemek ticari açıdan risklidir. Muadil önerisi verilebilir; fakat teknik özellik, fiyat ve müşteri onayı gerektiren sektörlerde kullanıcı seçmeden sipariş satırına dönüştürülmemelidir.
Ticari doğrulama satır bazında ve zaman damgalı olmalı
Dosyadaki fiyat, stok veya iskonto değerlerini otorite kabul etmeyin. Bunlar açıklama ya da karşılaştırma girdisi olabilir; geçerli sonuç sunucudaki müşteri, tüzel kişilik, teslimat adresi, para birimi, tarih, sözleşme ve ürün kurallarıyla hesaplanmalıdır.
Minimum sipariş miktarı ile paket katı aynı kural değildir. “En az 12” ve “6'nın katı” birlikte uygulanabilir. Sistem miktarı otomatik yuvarlayacaksa eski değer, yeni değer, kural ve mali etki önizlemede açıkça gösterilmelidir; sessiz yuvarlama yapılmamalıdır. Müşteriye özel fiyat ve iskonto kuralının nasıl belirlendiğini ayrıca planlamak için canlıya alındığında ilgili fiyatlandırma rehberiyle bağlantı kurulabilir; N‑12 ise bu kararın toplu satırdaki uygulanmasına odaklanır.
Satır karar matrisi kullanıcıya kontrol vermeli
| Satır sonucu | Örnek | Kullanıcı eylemi | Siparişe etkisi |
|---|---|---|---|
| Kabul | Ürün ve miktar geçerli | Gerekmez | Onay kapsamına girer |
| Düzeltme önerisi | Koli katına uyarlama | Eski/yeni değeri kabul veya reddet | Onaylanan değer girer |
| Hariç tut | Artık satılmayan ürün | Satırı listeden çıkar | Diğer satırlar politika izin verirse ilerler |
| İnceleme | Belirsiz kod veya yetki/kredi istisnası | Düzelt, açıklama ekle veya satış ekibine gönder | Karar verilmeden gönderilmez |
“Hatalı satır varsa hiçbir şey ilerlemesin” ile “geçerli satırlar siparişe dönüşsün” seçeneklerinden hangisinin uygulanacağı kurum politikasıdır. Kullanıcı, hangi satırların dışarıda kaldığını siparişi göndermeden önce görmelidir. Yükleme geçmişi yalnız dosya adını değil satır sonuç özetini de saklamalıdır.
Önizleme ile sipariş oluşturmayı iki ayrı karar yapın
Önizleme, belirli bir fiyat/stok anındaki hesaplamadır; sipariş oluşturma ise yeni bir ticari karardır. Kullanıcı önizlemeyi açtıktan sonra fiyat, stok, kampanya veya kredi durumu değişebilir. Gönderim anında kritik kurallar yeniden doğrulanmalı ve fark varsa kullanıcıya geri dönülmelidir.
Microsoft'un toplu yükleme belgeleri de şablon hazırlama, yükleme, gözden geçirme, gönderme, geçersiz kayıtlarla çalışma ve toplu işlem geçmişini ayrı aşamalar olarak gösterir. Bu ayrım, “dosya kabul edildi” ile “sipariş oluşturuldu” durumlarının neden aynı olmaması gerektiğini destekler.
Hızlı sipariş matrisi klavye ve yardımcı teknolojiyle kullanılmalı
Çok satırlı giriş ekranında fare zorunluluğu verimliliği ve erişilebilirliği düşürür. Satır ekleme, hücre düzenleme, hata bulma, kopyala/yapıştır, seçme ve önizleme eylemleri tutarlı klavye davranışına sahip olmalıdır.
W3C WAI-ARIA grid örüntüsü, etkileşimli veri ızgaralarında odak yönetiminin uygulama tarafından sağlanması gerektiğini ve ok, Home/End, Page Up/Down gibi tuşların hücreler arasında gezinmede kullanılabildiğini açıklar. ARIA rolü eklemek tek başına yeterli değildir; gerçek klavye, ekran okuyucu, yakınlaştırma ve mobil kullanım testleri gerekir.
Mükerrer siparişi işlem anahtarıyla önleyin
Kullanıcı gönder düğmesine iki kez basabilir, bağlantı yanıt gelmeden kesilebilir veya entegrasyon aynı komutu tekrar deneyebilir. Her sipariş oluşturma isteği; hesap, onaylanan satır özetinin parmak izi ve istemci işlem kimliğiyle benzersiz olmalıdır. Aynı anahtar yeniden geldiğinde yeni sipariş oluşturmak yerine önceki sonuç dönmelidir.
Dosyayı iki kez yüklemek her zaman mükerrer sipariş anlamına gelmez; kullanıcı gerçekten tekrar sipariş vermek isteyebilir. Bu nedenle dosya parmak izi uyarı üretmeli, asıl tekrar koruması onaylanmış gönderim komutunda uygulanmalıdır.
ERP aktarımı, toplu sipariş ekranının son aşamasıdır
Portalın kabul ettiği satırlar ERP'de tek veya birden fazla satış siparişine dönüşebilir. Tüzel kişilik, depo, teslimat adresi, para birimi, vergi veya proje ayrımı siparişi bölebilir. Bu bölünme kuralı kullanıcıdan gizlenmemeli; portal sipariş kimliği ile oluşan ERP belgeleri bağlanmalıdır.
e-ticaret–ERP entegrasyonu rehberindeki veri sahipliği, tekrar koruması, hata kuyruğu ve yeniden işleme yaklaşımı toplu sipariş için de geçerlidir. Entegrasyon başarısızsa kullanıcıya “sipariş alınmadı” ya da “durumu belirsiz” denmemeli; doğrulanabilir bir bekleme veya inceleme durumu gösterilmelidir.
Toplu sipariş onay akışından önce neyi kilitlemeli?
Kurum içi onay gerekiyorsa önce alıcının onayladığı satır kümesi ve ticari bağlam değişmez bir sürüm hâline getirilmelidir. Sonradan ürün veya miktar değişirse ilgili onaylar geçersizleşebilir. Hızlı giriş modülü sipariş taslağını üretir; yetki ve bütçe onayı başka bir yaşam döngüsüdür. Bu ayrım N‑12'nin N‑09 ile çakışmasını önler.
Kabul testlerini örnek dosyalarla değil, sınır durumlarıyla yazın
| Test | Beklenen davranış | Kanıt |
|---|---|---|
| Aynı ürün iki satırda bulunur | Politikaya göre birleştirir veya ayrı tutar; toplamı gösterir | Ham satırlar ve karar |
| Ürün kodunun başında sıfır vardır | Sayısal dönüşümle sıfırı kaybetmez | Ham ve normalize değer |
| Koli katına uymayan miktar | Sessiz yuvarlamaz; düzeltme önerir | Eski/yeni miktar ve kural |
| Dosyada formül veya beklenmeyen içerik | Güvenli ayrıştırma veya ret uygulanır | Dosya kontrol sonucu |
| Önizleme sonrası fiyat değişir | Gönderimde yeniden doğrular ve farkı gösterir | İki fiyat sürümü ve zaman |
| Gönderim yanıtı zaman aşımına uğrar | Aynı işlem anahtarı yeni sipariş üretmez | İstek anahtarı ve nihai belge |
| Yetkisiz sevk adresi yüklenir | Satır veya sipariş reddedilir | Hesap–adres yetki kontrolü |
| Bir satır hatalı, diğerleri geçerli | Kurumun kısmi gönderim politikası açıkça uygulanır | Dahil/hariç satır özeti |
Başarıyı hangi göstergelerle izlemelisiniz?
Önce mevcut süreç için başlangıç değeri oluşturun. Sipariş taslağı hazırlama süresi, ilk seferde geçerli satır oranı, düzeltme türleri, dosya şablonu sürümleri, kullanıcı tarafından iptal edilen öneriler, mükerrer gönderim girişimleri, ERP hata kuyruğu yaşı ve sipariş sonrası düzeltme sayısı izlenebilir. Sadece “yükleme hızlıydı” ölçümü, yanlış ticari kararları saklayabilir.
Teklif kapsamına hangi teslimatlar girmeli?
- Alıcı rolleri, giriş yöntemleri ve sipariş senaryoları;
- Dosya/şablon sözleşmesi, sütun eşleme ve güvenlik kuralları;
- Ürün kodu, varyant, birim ve müşteri kodu çözümleme tablosu;
- Minimum miktar, paket katı, fiyat, stok, kredi ve tarih kuralları;
- Satır kararları, kısmi gönderim ve kullanıcı önizlemesi;
- Klavye, ekran okuyucu, mobil ve yüksek satır sayısı testleri;
- İşlem anahtarı, ERP/WMS API sözleşmesi ve hata kuyruğu;
- Kabul testleri, pilot müşteri grubu, eğitim ve devir belgeleri.
Entegrasyon kapsamını daha geniş değerlendirmek için web yazılım entegrasyonları rehberini kullanabilirsiniz. Ancak toplu sipariş projesinde başarı, API bağlantısından önce satır kararlarının ve kullanıcı kontrolünün doğru tanımlanmasına bağlıdır.
Sonuç
B2B toplu sipariş, Excel dosyasındaki satırları sorgusuz sepete atan bir kısayol değildir. Alıcının tercih ettiği giriş yolunu güvenli dosya/alan sözleşmesi, ürün kimliği, ticari doğrulama, anlaşılır satır sonuçları ve tekrarsız sipariş komutuyla birleştiren kontrollü süreçtir. İlk sürümde tek müşteri grubu, sınırlı şablon ve gerçek hata örnekleriyle pilot yapın.
Kendi bayi veya toptan satış kanalınız için hızlı sipariş, Excel/CSV aktarımı ve ERP bağlantısı kapsamı çıkarmak istiyorsanız Kumsal Ajans e-ticaret çözümlerini inceleyebilir; görüşme öncesinde örnek dosyaları, ürün kimliklerini, paket kurallarını, fiyat/stok kaynaklarını ve onay sürecini listeleyebilirsiniz.