Çoğu bayi mükerrer kod sorununu "bize olmaz" diye geçiştirir. Mantık basit görünür: kod satıldığında sistem onu satıldı olarak işaretler, bir daha kimseye gitmez. Gerçekte ise mükerrer kod, satış anında değil stok girişinde doğar. Aynı listeyi iki kez yüklediğinde, aynı kodu iki farklı tedarikçiden aldığında ya da iptal olan bir siparişin kodunu tekrar stoğa attığında sistemde iki ayrı kayıt oluşur ve ikisi de "satılmadı" der.
Bu hatanın en can sıkıcı yanı sessiz olmasıdır. Panelde uyarı çıkmaz, rapor kızarmaz. Fark ettiğin an, ikinci müşterinin "bu kod kullanılmış" mesajını attığı andır. O noktada elinde hem iade, hem güven kaybı, hem de nereden kaynaklandığını bulmak için saatler süren bir kayıt taraması vardır. Oysa sağlam kurulmuş bir e-pin scripti aynı kodun ikinci kez sisteme girmesine daha ilk saniyede izin vermez.
Mükerrer kod nereden geliyor?
Kaynakları saymak sorunu yarı yarıya çözer. En yaygın olanı tekrar yüklemedir: dosya yüklenirken bağlantı koptuğunu sanıp aynı dosyayı ikinci kez gönderirsin, oysa ilk yükleme arka planda tamamlanmıştır. İkincisi tedarikçi çakışmasıdır; iki farklı bayiden aldığın partiler aynı üst kaynaktan geliyorsa kesişme olabilir.
Üçüncüsü iade ve iptal akışıdır. Müşteri ödemeyi iptal eder, personel kodu "tekrar satılabilir" yapar ama aynı kodu ayrıca elle de girer. Dördüncüsü test kayıtlarıdır; kurulum sırasında denemek için eklenen örnek kodlar temizlenmeyip canlı stoğa karışır. Beşincisi ise dosya içi tekrardır: tedarikçinin gönderdiği listenin kendi içinde aynı satır iki kez bulunur.
Bu beş kaynağın hepsi farklı noktada oluşur ama tek bir savunmayla durur: koda benzersizlik zorunluluğu getirmek. Bu zorunluluk uygulama katmanında değil, veritabanı katmanında olmalıdır; çünkü uygulama kodu hata yapar, veritabanı kısıtı yapmaz.
| Kaynak | Oluşma anı | Fark edilme süresi | Önleyici kontrol |
|---|---|---|---|
| Aynı dosyanın tekrar yüklenmesi | Stok girişi | Günler | Dosya parmak izi kaydı |
| Farklı tedarikçi kesişmesi | Stok girişi | Haftalar | Global benzersiz indeks |
| İptal sonrası elle ekleme | Sipariş akışı | Günler | Otomatik iade kuyruğu |
| Temizlenmemiş test kaydı | Kurulum | Aylar | Kurulum sonrası temizlik |
| Dosya içi tekrar satır | Stok girişi | Anında | Yükleme öncesi tekilleştirme |
Neden uygulama kontrolü tek başına yetmez?
Uygulama katmanındaki kontrol şöyle çalışır: kod yazılmadan önce "bu kod var mı" diye sorulur, yoksa eklenir. Tek kullanıcı, tek işlem varken kusursuz görünür. Ama iki yükleme aynı anda çalıştığında ikisi de "yok" cevabını alır ve ikisi de yazar. Buna yarış durumu denir ve tam da yoğun kampanya gecelerinde, yani en kötü zamanda ortaya çıkar.
Veritabanı seviyesindeki benzersiz indeks ise bu yarışı kazanamaz hale getirir; ikinci yazma denemesi fiziksel olarak reddedilir. Uygulama bu reddi yakalar, satırı karantinaya alır ve akış bozulmadan devam eder. Bu yüzden bir dijital ürün satış scripti değerlendirirken "mükerrer kontrolü var mı" diye sormak yetmez; "kontrol hangi katmanda" diye sorman gerekir.
İndeksin kapsamı da önemlidir. Kod sadece ürün içinde mi benzersiz, yoksa tüm sistemde mi? Doğrusu genellikle tüm sistemdir, çünkü aynı kodun iki farklı ürüne atanmış olması da bir hatadır ve yakalanmalıdır.
Mükerrer kayıtların oluşum kaynağı
- Tekrar yüklenen dosya 50%
- Tedarikçi kesişmesi 20%
- İptal/iade akışı 20%
- Test ve artık kayıtlar 10%
Var olan stoktaki mükerrerleri nasıl temizlersin?
Önce ölçersin. Satılmamış kodları gruplayıp birden fazla kez geçenleri listelersin. Çıkan sayı sıfırsa rahatla; değilse panik yapma, çünkü satılmamış mükerrerler henüz zarar üretmemiştir. Her gruptan en eski kaydı tut, diğerlerini pasifleştir. Silmek yerine pasifleştirmek önemlidir; ileride bir inceleme gerekirse izin kalmasını istersin.
Asıl dikkat gereken kısım satılmış mükerrerlerdir. Aynı kodun iki farklı siparişte göründüğü durumlar varsa bunları ayrı bir liste olarak çıkar ve ilgili müşterilere proaktif dön. Sorunu müşteri sana söylemeden önce senin bulman, olayı şikâyetten memnuniyete çevirir. Temizlik bittikten sonra benzersiz kısıtı devreye al; önce temizlik, sonra kısıt, sırası budur. Ters sırada denersen kısıt kurulamaz.
Her yüklenen dosyanın özetini kaydet. Aynı dosya ikinci kez geldiğinde panel "bu dosya daha önce işlendi" uyarısı verir ve tekrar yükleme kaynaklı mükerrerlerin yarısından fazlası kapıda durur.
Tekilleştirme yüklemeyi yavaşlatır mı?
Pratikte hayır. Benzersiz indeks üzerinden yapılan kontrol milisaniyeler sürer ve zaten indeksli bir sütunda arama yapıldığı için satır sayısı arttıkça maliyet doğrusal büyümez. Asıl yavaşlık, indeks olmadan her satır için tam tablo taraması yapan kurgularda görülür; işte o zaman 10 bin satırlık bir yükleme dakikalarca sürer.
Performansı korumanın ikinci yolu dosya içi tekilleştirmedir. Veritabanına hiç sormadan, dosyayı okurken tekrar eden satırları bellek içinde eleyebilirsin. Böylece veritabanına giden sorgu sayısı düşer. Üçüncü yol toplu yazma kullanmaktır: satırları tek tek değil bloklar halinde yazıp reddedilenleri toplayarak raporlamak. Bu üç tekniği birlikte uygulayan bir e-pin satış yazılımı hem hızlı hem güvenli çalışır.
| Denetim maddesi | Sıklık | Beklenen sonuç | Aksiyon |
|---|---|---|---|
| Satılmamış mükerrer taraması | Haftalık | Sıfır kayıt | Pasifleştir |
| Satılmış mükerrer taraması | Aylık | Sıfır kayıt | Müşteriye proaktif dönüş |
| Benzersiz indeks doğrulaması | Sürüm sonrası | Kısıt aktif | Yeniden kur |
| Dosya parmak izi kaydı | Her yükleme | Tekrar dosya reddedilir | Uyarı göster |
| İade kuyruğu kontrolü | Haftalık | Elle ekleme yok | Süreci otomatikleştir |
| Test kaydı temizliği | Kurulumda | Örnek kod kalmaz | Toplu sil |
Mükerrer tespiti raporlamanı nasıl etkiler?
Çoğu işletme mükerrer kodu yalnızca müşteri sorunu olarak görür; oysa mali tabloyu da bozar. İki kez yüklenen bir parti, stok değerini olduğundan yüksek gösterir. Buna bakarak "elimde yeterli kod var" dersin ve yeni alım yapmazsın, sonra kampanya ortasında stok biter. Aynı şekilde maliyet hesabın da şişer, kâr marjını yanlış okursun.
Düzgün tekillik kurgusu bu yüzden bir muhasebe önlemidir de. Panelde gördüğün sayının gerçekte satılabilir kod sayısı olduğuna güvenebilmek, satın alma kararlarını doğru vermeni sağlar. Hangi paketin hangi denetim araçlarını içerdiğini fiyat bölümünde, teknik başlıkların tamamını ise özellikler listesinde bulabilirsin.
Aynı kod bir daha iki kere satılmasın
Veritabanı seviyesinde tekillik, dosya parmak izi ve otomatik mükerrer raporu hazır gelsin.
Bugün uygulayabileceğin üç adımlık plan
Birinci adım ölçüm: mevcut stoğunda kaç mükerrer var, öğren. İkinci adım temizlik: satılmamışları pasifleştir, satılmışları listele ve gerekiyorsa müşteriyle temasa geç. Üçüncü adım kalıcı önlem: benzersiz kısıtı devreye al, dosya parmak izi kaydını aç ve iade akışını elle eklemeye ihtiyaç bırakmayacak biçimde otomatikleştir.
Bu üç adımı bir kez yaptıktan sonra mükerrer kod artık senin gündemin olmaz; sistemin sessizce hallettiği bir arka plan işine dönüşür. Zaten iyi bir altyapının tanımı da budur: dikkat etmen gereken şeylerin listesini kısaltması.
Mükerrer kod gerçekten sık karşılaşılan bir sorun mu?
Düşündüğünden sık. Özellikle birden fazla tedarikçiyle çalışan ve haftada birkaç kez toplu yükleme yapan işletmelerde kaçınılmaz hale gelir. Kontrol yoksa oran zamanla artar çünkü hatalar birikir.
Aynı kod iki müşteriye gittiyse ne yapmalıyım?
Önce ikinci müşteriye yeni ve doğrulanmış bir kod gönder, sonra olayı açıkla. Ardından o partinin tamamını tara; tek bir mükerrer varsa genellikle yalnız değildir, aynı kaynaktan başkaları da vardır.
Kodları silmek yerine neden pasifleştirmeliyim?
Silinen kaydın izi kalmaz ve ileride bir anlaşmazlıkta neyin ne zaman olduğunu kanıtlayamazsın. Pasif kayıt satışa çıkmaz ama geçmişi korur; denetim açısından her zaman daha güvenlidir.
API ile çalışan ürünlerde mükerrer riski var mı?
Stok sende durmadığı için klasik anlamda yoktur. Ancak API çekimi başarısız sayılıp tekrar denendiğinde çift çekim olabilir. Bunu önlemek için her sipariş için tek seferlik işlem kimliği kullanılmalıdır.
Mükerrer kod, dijital ürün satışında görünmez ama pahalı bir sızıntıdır; stok değerini şişirir, müşteri güvenini aşındırır ve destek ekibini yorar. Kontrolü doğru katmana koyduğunda ise tek satır bile kaçmaz. Bu kontrollerin bir panelde nasıl kurulduğunu ve mükerrer raporunun neye benzediğini görmek istersen canlı demo üzerinden aynı kodu bilerek iki kez yükleyip sistemin tepkisini kendin test edebilirsin.