Barkod ve stok kodu eşleştirme: çoklu kanalda stok neden tutmaz?

Çoklu kanalda stok tutmamasının sebebi genellikle senkronizasyon gecikmesi değil, kimlik karmaşasıdır. Her pazaryeri ürünü farklı bir alanla tanıyor ve eşleştirme tablonuz bozulduğunda hata sessizce yayılıyor.

“Stok senkronizasyonu çalışmıyor” şikâyetiyle gelen sorunların çoğu aslında senkronizasyon sorunu değil. İstek gidiyor, yanıt 200 dönüyor, kayıt güncelleniyor — ama yanlış ürünün stoğu güncelleniyor ya da hiçbir ürün eşleşmiyor.

Kök sebep neredeyse her zaman aynı: ürünün kimliği her kanalda farklı bir alanda tutuluyor ve bu alanları birbirine bağlayan tablo tek doğruluk kaynağı değil.

Her pazaryeri farklı bir alanla konuşuyor

Kanal	Güncellemede kullanılan alan
Trendyol	barcode
N11	stockCode — tedarikçinin ürüne verdiği tekil kod
Kendi sisteminiz	Genellikle kendi ürün kimliğiniz veya SKU

Bunlar aynı şey değil. Trendyol’un beklediği barcode genelde ürünün fiziksel barkodudur (EAN/GTIN); N11’in beklediği stockCode ise sizin verdiğiniz koddur. Aynı değeri ikisine birden yazabilirsiniz — ama yazmak zorunda değilsiniz ve çoğu satıcıda yazılmamıştır.

Sonuç: elinizde en az üç kimlik var ve bunları birbirine bağlayan bir haritaya ihtiyacınız var.

Eşleştirme tablosunu nerede tutmalı

En sık yapılan hata, haritayı pazaryerinin kendisinde tutmaya çalışmak — yani “Trendyol’daki barkodu okurum, ona göre bulurum” demek. Bu, kimliği dış sisteme emanet etmek demektir ve iki şekilde kırılır: pazaryerinde biri ürünü panelden düzenler, ya da aynı barkod iki farklı ürüne atanmış olur.

Doğrusu, eşleştirmenin sizin sisteminizde, açık bir tablo olarak durmasıdır:

urun_id | kanal      | kanal_kimligi   | durum
--------+------------+-----------------+--------
1042    | trendyol   | 8690000000017   | aktif
1042    | n11        | TSH-KRM-M       | aktif
1042    | hepsiburada| TSH-KRM-M       | pasif

Bu tablonun üç faydası var: hangi ürünün hangi kanalda olduğunu tek bakışta görürsünüz, bir kanalda satıştan kaldırdığınızda kaydı silmeden pasife alırsınız, ve bir güncelleme başarısız olduğunda hangi satırın sorumlu olduğunu bilirsiniz.

Varyantlar: asıl karışıklık burada

Tek bedenli bir ürün için eşleştirme kolaydır. Beden ve renk varyantı olan bir üründe ise her varyant ayrı bir stok birimidir ve ayrı bir kimliği olmalıdır.

Burada iki tipik hata görülüyor:

• Aynı barkodu tüm varyantlara vermek. Bir bedenin stoğunu güncellediğinizde hepsi değişir; M beden tükendiğinde L beden de sıfırlanır ya da tam tersi, tükenen beden satılmaya devam eder.
• Varyant kodunu üretirken okunabilirliği kaybetmek. 1042-1, 1042-2 gibi kodlar bir hafta sonra hangisinin hangi beden olduğunu söylemez. TSH-KRM-M biçimi hata ayıklarken hayat kurtarır.

Kural basit: fiziksel olarak ayrı rafta duran her şey ayrı bir stok birimidir. Rengi farklıysa, bedeni farklıysa, ayrı kimliği olmalı.

Stoğun tek kaynağı olmalı

Çoklu kanalda stok tutarsızlığının ikinci büyük sebebi, stoğun nerede “doğru” olduğunun belirsiz olmasıdır.

Pazaryerleri stoğu kendi tarafında da değiştirir — sipariş geldiğinde düşer, iade geldiğinde artar. Siz de kendi sisteminizden gönderirsiniz. İki taraf da yazıyorsa çakışma kaçınılmazdır.

Çalışan model tek yönlüdür:

• Stoğun doğrusu sizin sisteminizdedir. Depo sayımı, üretim, iade kabulü — hepsi orada işlenir.
• Pazaryerine yalnızca yazarsınız. Oradan stok okuyup kendi kaydınızı güncellemezsiniz.
• Siparişi okursunuz, stoğu siparişe göre kendi tarafınızda düşersiniz, sonra yeni değeri tüm kanallara yazarsınız.

Bu sırayı bozan her kurgu er geç fazla satışa yol açar.

Emniyet payı

Senkronizasyon anlık değildir. Trendyol ve N11’de güncelleme isteği kuyruğa alınır, sonuç sonra belli olur — bu gecikme içinde satış olabilir.

Hızlı tükenen ürünlerde gerçek stoğun tamamını pazaryerine yazmamak yaygın bir korunma yöntemidir. 50 adediniz varsa 45 yazarsınız; aradaki fark, senkronizasyon penceresinde gelen siparişleri karşılar. Payın büyüklüğü satış hızınıza ve güncelleme sıklığınıza bağlıdır — yavaş satan üründe gereksiz, saatte onlarca satanda zorunludur.

Güncelleme başarısız olduğunda

Eşleştirme hatalarının çoğu toplu güncellemenin kalem bazındaki sonucunda görünür: barkod bulunamadı, stok kodu eşleşmedi, ürün pasif. Ama bu bilgiyi görmek için sonucu sorgulamanız gerekir.

Trendyol batchRequestId, N11 taskId döndürüyor ve ikisinde de HTTP 200 almak güncellemenin yapıldığı anlamına gelmiyor. Trendyol tarafındaki akışı ve N11’in kurallarını ayrı yazılarda ele aldık.

Pratik tavsiye: başarısız kalemleri yalnızca loglamayın, eşleştirme tablosundaki ilgili satırı işaretleyin. Üst üste başarısız olan bir satır, düzeltilmesi gereken bir eşleştirme demektir — her çalışmada aynı hatayı tekrar denemek kotanızı yer ve hiçbir şeyi çözmez.

Kontrol listesi

• Eşleştirme tablosu kendi sisteminizde mi, yoksa pazaryerinden mi okunuyor?
• Her varyantın ayrı kimliği var mı?
• Kodlar insan tarafından okunabilir mi?
• Aynı kimlik iki farklı ürüne atanmış olabilir mi — bunu kontrol eden bir kısıt var mı?
• Stok tek yönlü mü akıyor?
• Hızlı satan ürünlerde emniyet payı var mı?
• Başarısız eşleştirmeler işaretlenip tekrar denenmekten çıkarılıyor mu?

Eşleştirmeyi kendiniz mi yöneteceksiniz yoksa hazır bir araca mı bırakacaksınız — bu kararın çerçevesini yazılım seçimi yazısında ele aldık. Stok eşleştirmesi, hazır araçların en sık yetersiz kaldığı yerlerden biridir; depo yapınız standart değilse bu katmanı kendinizde tutmak genellikle daha az acı verir.

Kaynak

Alan adları ve zorunlulukları ilgili pazaryerlerinin resmî dokümanlarından alınmıştır: Trendyol’un barcode alanı Stok ve Fiyat Güncelleme; N11’in stockCode alanı ve “tedarikçinin ürüne belirlediği tekil kod” tanımı Ürün Fiyat-Stok Güncelleme sayfasındadır.

Son güncelleme: 12 Ekim 2026. Kanal sayısı arttıkça aynı mantık diğer pazaryerlerine de uygulanır.