Çoğu kişi toplu kod yüklemeyi basit bir dosya aktarımı sanır. Elindeki Excel'i açarsın, kodları kopyalarsın, panele yapıştırırsın, stok görünür. Tedarikçinden 10 bin satırlık bir liste geldiğinde bu masalın nerede çatırdadığını ise ancak ilk iade talebi geldiğinde fark edersin. Çünkü sorun kodun yüklenmesi değil, yüklenen kodun gerçekten satılabilir olduğunun kanıtlanmasıdır. Bu ikisi arasındaki fark, bir gecede yüzlerce müşteriye geçersiz kod göndermekle sorunsuz teslimat arasındaki farktır.
Sektörde uzun süre ayakta kalan bayilerin ortak özelliği, kodu stoğa almadan önce bir doğrulama zincirinden geçirmeleridir. Bu zincir görünmezdir, panelde kimseye gösterilmez, ama her satırın arkasında çalışır. İyi kurgulanmış bir e-pin scripti bu zinciri sana hazır verir; kötü kurgulanmış olanı ise "dosya yüklendi" yazıp sorumluluğu senin omzuna bırakır. Aşağıda bu zincirin her halkasını, hangi noktada neyin patladığını ve kendi panelinde nasıl test edeceğini anlatıyorum.
Toplu yükleme neden "kopyala-yapıştır" değildir?
Tedarikçiden gelen dosya asla temiz gelmez. Bir bayiden CSV, diğerinden noktalı virgülle ayrılmış TXT, üçüncüsünden içinde birleştirilmiş hücreler olan bir XLSX alırsın. Her birinin satır sonu karakteri, tırnak kullanımı ve sütun sırası farklıdır. Panel bunları tek bir iç formata çevirmeden veritabanına dokunmamalıdır. Aksi halde kodun sonuna yapışmış görünmez bir boşluk karakteri, müşteri kodu oyuna girdiğinde "geçersiz" hatası olarak geri döner ve suçlu sen olursun.
İkinci mesele hacim. Web sunucusu bir HTTP isteğini sonsuza kadar açık tutmaz. 10 bin satırı tek döngüde işlemeye kalkarsan zaman aşımına düşersin ve daha kötüsü, yarısı yüklenmiş bir stok ile kalırsın. Doğru kurgu, dosyayı önce geçici bir alana alıp parçalara bölmek ve arka planda kuyrukla işlemektir. Böylece tarayıcını kapatsan bile işlem devam eder.
Üçüncüsü geri alınabilirlik. Yanlış ürüne 3.000 kod bastıysan bunu tek tek silmek istemezsin. Her toplu yükleme kendi parti numarasıyla kaydedilmeli, tek tuşla geri alınabilmelidir. Bu özelliği olmayan bir dijital ürün satış yazılımı seni her hatada saatlerce SQL ekranında tutar.
| Yükleme yöntemi | Uygun hacim | Zaman aşımı riski | Geri alma | Tipik kullanım |
|---|---|---|---|---|
| Manuel tek kod | 1-20 satır | Yok | Kolay | Acil stok yaması |
| Metin kutusu (satır satır) | 20-500 satır | Düşük | Parti bazlı | Günlük küçük alımlar |
| CSV / XLSX dosya | 500-5.000 satır | Orta | Parti bazlı | Standart tedarik |
| Kuyruklu arka plan işleme | 5.000+ satır | Yok | Parti bazlı | Toplu kampanya stoğu |
| Tedarikçi API çekimi | Sınırsız | Yok | Otomatik senkron | Anlık teslimat modeli |
Doğrulama zinciri tam olarak hangi halkalardan oluşur?
Zincir beş halkalıdır ve sırası önemlidir. Birinci halka yapısal doğrulama: dosya gerçekten beklenen sütunlara sahip mi, satır sayısı makul mü, karakter kodlaması UTF-8 mi? Türkçe karakter içeren ürün adlarında bu adım atlanırsa veritabanına soru işaretleri düşer.
İkinci halka biçim doğrulaması: her kod, o ürün için tanımlanmış desene uyuyor mu? Üçüncüsü tekillik kontrolü: bu kod daha önce sisteme girmiş mi, hatta başka bir ürünün altında duruyor mu? Dördüncüsü ürün eşleşmesi: dosyadaki ürün kimliği panelde gerçekten var mı, fiyatı ve para birimi tanımlı mı? Beşincisi işlem bütünlüğü: parti ya tamamen yazılır ya hiç yazılmaz.
Bu beş halkanın hepsini geçmeyen satır stoğa girmez, karantina listesine düşer. İyi bir e-pin satış yazılımı sana bu karantinayı indirilebilir bir rapor olarak verir; sen de tedarikçine "şu 47 satır hatalı, yenile" diyebilirsin. Böylece sorumluluk zinciri de netleşir.
Toplu yüklemede reddedilen satırların nedeni
- Biçim/desen uyuşmazlığı 45%
- Mükerrer kod 25%
- Ürün eşleşmemesi 20%
- Karakter kodlaması 10%
Kuyruk mantığı olmayan panel neden gece yarısı seni uyandırır?
Senaryo şu: saat 23.40, kampanya sabah 09.00'da başlıyor, tedarikçi 12 bin kodu yeni gönderdi. Yüklemeye basıyorsun, sayfa dönüyor, dönüyor, sonra beyaz ekran. Panele girip bakıyorsun, stok 4.318 görünüyor. Kalan 7.682 kod nerede? Dosyada mı, veritabanında mı, ikisinde de mi? İşte kuyruksuz mimarinin bedeli budur.
Kuyruklu yapıda ise dosya sunucuya alınır, parti kaydı açılır, satırlar 500'lük bloklar halinde işlenir ve her blok sonunda ilerleme yüzdesi güncellenir. Tarayıcıyı kapatsan da süreç sürer, ertesi sabah parti detayında "12.000 okundu, 11.942 yazıldı, 58 karantinada" raporunu görürsün. Bu şeffaflık, panelin sana verdiği en değerli şeydir.
Her yeni tedarikçi dosyasını önce "sadece doğrula, yazma" modunda geçir. Rapor temizse asıl yüklemeyi başlat. Bu tek alışkanlık, hatalı stok girişlerinin büyük bölümünü daha stoğa dokunmadan eler.
Yükleme sonrası hangi kontrolleri yapmalısın?
Yükleme bittiğinde iş bitmez. Önce parti özetini oku: okunan satır, yazılan satır ve karantina sayısı toplamı birbirini tutuyor mu? Tutmuyorsa kayıp var demektir ve bunu ürün satışa açılmadan çözmelisin. Sonra rastgele beş kodu seç, ürün sayfasından test siparişi ver ve teslimat metninin doğru göründüğünü gör.
Ardından stok uyarı eşiklerini güncelle. Yeni parti geldiği için eşik seviyesi anlamsızlaşmış olabilir; kampanya hacmine göre yeniden ayarla. Son olarak parti notuna tedarikçi adını, fatura numarasını ve alış maliyetini yaz. Altı ay sonra bir iade geldiğinde hangi partiden çıktığını saniyeler içinde bulman bunu gerektirir. Dijital ürün satış scripti seçerken parti notu alanı olup olmadığına bakmanın nedeni budur.
| Kontrol adımı | Ne zaman | Başarı ölçütü | Durum |
|---|---|---|---|
| Dosya kodlaması UTF-8 mi | Yükleme öncesi | Türkçe karakterler bozulmuyor | Zorunlu |
| Kuru çalıştırma raporu | Yükleme öncesi | Karantina oranı %1 altında | Zorunlu |
| Ürün-parti eşleşmesi | Yükleme anında | Tek ürün kimliği, tek para birimi | Zorunlu |
| Okunan = yazılan + karantina | Yükleme sonrası | Fark sıfır | Zorunlu |
| Rastgele 5 kod test siparişi | Yükleme sonrası | Teslimat metni doğru | Önerilir |
| Stok eşiği güncelleme | Yükleme sonrası | Uyarı seviyesi hacme uygun | Önerilir |
| Parti notu ve maliyet girişi | Yükleme sonrası | Tedarikçi ve fatura kayıtlı | Önerilir |
Tedarikçi API'si varken hâlâ dosya yüklemeli misin?
API bağlantısı olan ürünlerde kod senin sunucunda beklemez; sipariş anında çekilir ve müşteriye iletilir. Bu yöntem stok yönetimini neredeyse sıfırlar ama tamamen tedarikçinin ayakta kalmasına bağımlıdır. Servis yanıt vermediğinde satış durur. Bu yüzden deneyimli bayiler karma model kurar: yüksek hacimli ürünlerde API, kampanya ve nadir ürünlerde ise elinde fiziksel stok tutan toplu yükleme.
Karma modelin çalışabilmesi için panelin her iki kaynağı tek stok görünümünde birleştirmesi gerekir. Müşteri "stokta var" yazısını görüyorsa bu ister depodan ister API'den gelsin fark etmemeli. Panelin arka planında ise kaynak ayrımı net tutulmalı ki maliyet raporun doğru çıksın. Bu ayrımı yapabilen bir epin yazılım altyapısı sana hem esneklik hem doğru kâr tablosu verir.
Toplu yüklemeyi tek ekrandan yönet
Kuru çalıştırma, parti takibi, karantina raporu ve tek tuşla geri alma; hepsi hazır bir altyapıyla gelsin.
Kendi panelini bugün nasıl sınarsın?
Basit bir test hazırla: 200 satırlık bir dosya oluştur, içine bilinçli olarak üç tane bozuk satır, iki tane de zaten sistemde olan kod koy. Bu dosyayı yükle. Panel sana beş hatayı ayrı ayrı gösteriyor, 195 satırı stoğa alıyor ve partiyi geri alabiliyorsan altyapın sağlamdır. Eğer "yükleme başarılı" deyip 200 satırı da içeri alıyorsa ciddi bir risk taşıyorsun demektir.
Bu testi her sürüm güncellemesinden sonra tekrarla. Panel yazılımları geliştikçe doğrulama kuralları değişebilir; senin görevin kuralın hâlâ çalıştığını doğrulamak. Detaylı özellik listesi için özellikler bölümüne, paket karşılaştırması için fiyat tablosuna göz atabilirsin.
Toplu yüklemede en fazla kaç kod yükleyebilirim?
Kuyruklu işleme destekleyen bir panelde teknik bir üst sınır yoktur; 50 bin satırlık dosyalar bile parçalanarak işlenir. Sınır sunucu disk alanı ve veritabanı kapasitesidir. Kuyruksuz yapıda ise pratik sınır 3-5 bin satırdır.
Yanlış ürüne yüklediğim kodları nasıl geri alırım?
Parti bazlı kayıt tutan panellerde yükleme kimliğini seçip "partiyi geri al" dersin; satılmamış tüm kodlar silinir. Satılmış olanlar korunur çünkü müşteri teslimat kaydı bozulmamalıdır.
Excel yerine CSV kullanmam şart mı?
Şart değil ama CSV daha güvenlidir. Excel dosyaları gizli biçimlendirme, birleşik hücre ve otomatik sayı dönüşümü taşır; uzun kodları bilimsel gösterime çevirebilir. CSV'yi UTF-8 olarak kaydetmen yeterlidir.
Karantinaya düşen kodlarla ne yapmalıyım?
Raporu indir, tedarikçine ilet ve yenisini iste. Kendi elinle düzeltmeye çalışma; bozuk bir kodu tahminle tamamlamak müşteriye geçersiz ürün göndermenin en yaygın nedenidir.
Toplu kod yükleme, dışarıdan bakıldığında bir dosya seçme ekranıdır; içeriden bakıldığında ise işletmenin en kritik veri giriş noktasıdır. Bu noktayı doğrulama zinciriyle korursan ne iade yığını görürsün ne de gece yarısı stok sayarsın. Anlattığım akışın gerçek bir panelde nasıl göründüğünü kendi gözünle denemek istersen canlı demo üzerinden parti oluşturup örnek bir dosyayı baştan sona işleyebilirsin.