E-Ticaret Stok Senkronizasyonu: Stok Neden Tutmuyor? ERP ile 5 Karar

E-ticaret stok senkronizasyonu neden tutmuyor?

E-ticaret stok senkronizasyonu, ERP'deki stok bilgisinin satış kanallarına doğru zamanda ve doğru tanımla taşınmasıdır; tutmamasının en yaygın sebebi tanım farkıdır. ERP'de görünen sayı genellikle depodaki fiziksel bakiyedir. Satış kanalına ise "bu ürün şu an kaç adet satılabilir" sorusunun cevabı gönderilmelidir. İkisinin arasındaki fark, onaylanmış ama henüz sevk edilmemiş siparişler, kalite kontrolde bekleyen mallar ve başka bir işe ayrılmış stoklardır.

Trendyol'un geliştirici belgesi bunu açıkça ayırır: stok ve fiyat güncelleme servisinde gönderilen miktar "satılabilir stok" bilgisidir ve sipariş geldiğinde ya da satıcı stok eklediğinde güncellenir. Yani pazaryeri, kendi kanalında gelen siparişi kendi sayısından düşer; ama sitenizden ya da başka bir pazaryerinden gelen siparişi bilmez. Bu bilgiyi diğer kanallara taşımak sizin senkronunuzun işidir.

Aşırı satış: varsayımsal bir gün

Örnek senaryo: bir ürünün depoda 5 adedi var. ERP'den kanallara stok her 30 dakikada bir gönderiliyor ve gönderilen değer ERP'deki eldeki bakiye.

Saat 10.40 itibarıyla 8 adet satılmış, depoda 5 adet var. Hata iki yerde: 10.30'daki senkron sevk edilmemiş siparişleri düşmeden eldeki bakiyeyi gönderdi ve iki kanalın siparişleri birbirine ulaşmadı. Senkron sıklığını artırmak bu sorunu yalnızca daraltır, çözmez. Çözüm aşağıdaki beş karardadır.

Karar 1 ve 2: Satılabilir stok tanımı ve güvenlik stoğu

Satılabilir stok, eldeki bakiyeden satışa hazır olmayan ve başkasına söz verilmiş miktarların düşülmesiyle bulunan sayıdır. Bu formül her işletmede biraz farklıdır; önemli olan, yazılı olması ve tek bir yerde hesaplanmasıdır.

Onaylı siparişlerin düşülmesi, ERP'nin rezervasyon özelliğine bağlıdır. Bazı ERP'lerde sipariş fişinde stok ayırma seçeneği bulunur; örneğin ETA:V.11'in API belgesinde sipariş fişi için bir rezerv ayırma alanı tanımlıdır; kurulumunuzda nasıl kullanıldığı keşifte teyit edilir. ERP rezervasyonu tutmuyorsa, sevk edilmemiş siparişler entegrasyon katmanında ayrı bir tabloda tutulur ve formülde oradan düşülür.

Güvenlik stoğu: kaç adet tampon?

Güvenlik stoğu, satılabilir stoktan bilerek düşülen ve kanallarda hiç gösterilmeyen tampondur. İki amacı vardır: sayım farkını karşılamak ve iki senkron arasında birden fazla kanaldan gelen eşzamanlı satışı karşılamak.

Güvenlik stoğu tek bir sayı olmak zorunda değildir. Çok satan ve az adetli ürünlerde tampon daha anlamlıdır; nadiren satılan ürünlerde sıfır olabilir. Pratik bir kural şudur: satılabilir stok belirlenen eşiğin altına indiğinde kanala sıfır gönderilir. Örneğin eşik 2 ise ve satılabilir stok 2 ya da altındaysa ürün kanallarda tükendi görünür, son adetler mağaza ya da telefon siparişi için kalır. Eşik ürün ya da kategori bazında, işletme tarafından yönetilen bir tabloda tutulur.

Karar 3: Senkron sıklığı ve tetikleyici

Senkron sıklığı, stok değişikliğinin kanallara ne kadar gecikmeyle ulaşacağını belirler ve üç yöntemden biriyle kurulur: zamanlanmış, olay tetiklemeli ya da ikisinin birlikte kullanıldığı karma yöntem.

Her ERP, stok değiştiğinde dış sisteme haber veren bir bildirim mekanizması sunmaz; sizin kurulumunuzda olup olmadığı keşifte teyit edilir. Örneğin ETA:V.11 API belgesinde böyle bir bildirim mekanizması bulamadık. Bu durumda değişiklikler zamanlanmış okumalarla yakalanır. Olay tetiklemeli kısım ise entegrasyon katmanının kendi gördüğü olaylarla sınırlıdır: kanaldan gelen sipariş, depo ekranından yapılan mal kabulü gibi.

Zamanlanmış turda yalnızca değişen ürünler gönderilmelidir. Bunun iki sebebi var. Birincisi, pazaryeri servislerinin sınırları vardır: Trendyol'un 2026 itibarıyla geçerli belgesine göre stok ve fiyat güncellemesinde tek istekte en fazla 1.000 ürün gönderilebilir ve değişmemiş aynı istek tekrar gönderilirse 15 dakika boyunca hata döner. İkincisi, ERP tarafındaki okuma da kaynak tüketir; tüm kartları her seferinde okumak canlı sistemi gereksiz yorar.

Kanala gönderilen değer her zaman mutlak sayıdır, değişim farkı değildir. "3 adet azalt" yerine "satılabilir stok 7" gönderilir. Böylece bir güncelleme kaçsa bile bir sonraki tur doğru sayıyı yazar ve hata birikmez.

Karar 4: Çok kanal rezervasyonu

Çok kanal rezervasyonu, bir kanaldan gelen siparişin diğer kanallardaki satılabilir stoğu da hemen düşürmesini sağlayan düzendir. İki yaklaşım vardır: ortak havuz ve kanal kotası.

• Ortak havuz: Tüm kanallar aynı satılabilir stoğu görür. Bir kanaldan sipariş geldiğinde entegrasyon katmanı siparişi rezerve eder ve yeni satılabilir stoğu diğer tüm kanallara gönderir. Stok verimli kullanılır ama hız önemlidir; senkron gecikirse aşırı satış riski geri döner.
• Kanal kotası: Satılabilir stok kanallara paylaştırılır: örneğin 10 adedin 6'sı siteye, 4'ü pazaryerine. Her kanal yalnızca kendi kotasını satabilir. Aşırı satış riski düşer ama bir kanalda stok tükenirken diğerinde mal bekleyebilir.

Az adetli ve çok satan ürünlerde kanal kotası, bol stoklu ürünlerde ortak havuz daha uygun olabilir; ikisi ürün grubuna göre birlikte kullanılabilir. Hangi yaklaşım seçilirse seçilsin, siparişi ilk gören katmanın rezervasyonu hemen yapması ve bunu ERP'ye siparişin aktarılmasını beklemeden diğer kanallara yansıtması gerekir. Varsayımsal senaryodaki 10.12 satışı, pazaryeri siparişi 10.05'te rezerve edilip site stoğu 2'ye düşürülseydi gerçekleşmezdi.

Karar 5: Hata durumunda ne olur?

Hata durumu kararı, senkron çalışmadığında kanallarda hangi stok bilgisinin görüneceğini önceden belirlemektir. Bağlantı koptuğunda kanallar son gönderilen değeri göstermeye devam eder; kimse müdahale etmezse saatlerce eski stokla satış yapılır.

Üç seçenek vardır:

1. Son değeri korumak: Kısa kesintilerde makul bir seçimdir. Risk, kesinti uzadıkça büyür.
2. Düşük stoklu ürünleri kapatmak: Senkron belirli bir süredir başarısızsa, satılabilir stoğu eşiğin altındaki ürünler kanallarda sıfıra çekilir. Bol stoklu ürünler satışa devam eder.
3. Tümünü durdurmak: Uzun kesintilerde ya da ERP verisinin güvenilmez olduğu durumlarda tüm kanallarda stok sıfırlanır. Satış kaybı büyüktür; yalnızca son çare olarak kullanılır.

Hangi sürenin "uzun" sayılacağı ve hangi seçeneğin devreye gireceği işletme tarafından belirlenir ve yazılı olur. Bir başka hata türü kısmi başarısızlıktır. Trendyol'da stok ve fiyat güncellemesi kuyruğa alınır, istek bir toplu işlem kimliği döndürür ve sonuç ayrı bir servisten sorgulanır; sonuçta her ürün için başarılı ya da başarısız durumu ile hata nedeni yer alır. Senkronun "istek gönderildi" ile yetinmemesi, bu sonucu okuyup başarısız ürünleri listelemesi gerekir.

İzleme ve uyarı

İzleme, senkronun çalışıp çalışmadığını ve gönderilen sayıların doğru olup olmadığını düzenli olarak ölçmektir. Senkron hataları çoğu zaman sessizdir: istek gider, kanal kabul eder, ama sayı yanlıştır. Bu yüzden yalnızca teknik başarıyı değil, sonucu da izlemek gerekir.

En az şu göstergeler izlenmelidir:

• Son başarılı senkron zamanı: Belirlenen süreyi aştığında sorumluya uyarı gider; Karar 5'teki hata kuralı bu göstergeye bağlanır.
• Reddedilen ve başarısız kalemler: Kanalın reddettiği ürünler sebebiyle listelenir; aynı ürün art arda reddediliyorsa eşleştirme ya da ürün kartı incelenir.
• Eşleşmeyen ürünler: ERP'de olup kanalda karşılığı olmayan ya da tersi durumdaki ürünler.
• Günlük fark raporu: Her gün belirli bir saatte ERP'deki satılabilir stok ile kanalların gösterdiği stok karşılaştırılır; farkı eşiği aşan ürünler listelenir.
• İptal nedeni stok yetersizliği olan siparişler: Bu sayının artması, senkronun ya da formülün gözden geçirilmesi gerektiğinin en açık işaretidir.

Fark raporunun bir yan faydası da vardır: kanalda doğru görünen ama depoda tutmayan ürünler, sayım sorununa işaret eder. Depoda barkodlu stok takip programı kullanılıyorsa sayım farkı bu raporla birlikte incelenebilir. Stok farkının kaynağı depoysa, senkronu hızlandırmak sorunu çözmez.

Sıkça Sorulan Sorular

ERP stok entegrasyonunda anlık senkron şart mı?

Şart değil, ama gecikme ne kadar uzunsa güvenlik stoğu ve çok kanal rezervasyonu o kadar önemli hâle gelir. Çoğu durumda dengeli çözüm karma yöntemdir: kanaldan gelen sipariş hemen rezerve edilip diğer kanallara yansıtılır, düzenli bir zamanlanmış tur da ERP'deki diğer değişiklikleri taşır.

Stok kanallara neden fark olarak değil, mutlak değer olarak gönderilmeli?

Fark olarak gönderilen bir güncelleme kaçarsa hata kalıcı hâle gelir ve birikir. Mutlak değer gönderildiğinde bir sonraki başarılı tur doğru sayıyı yazar. Trendyol'un stok servisi de gönderilen miktarı satılabilir stok bilgisi olarak alır.

Güvenlik stoğu satış kaybettirmez mi?

Az da olsa kaybettirebilir, bu yüzden her ürüne aynı tampon verilmez. Az adetli ve çok satan ürünlerde tampon aşırı satışı önler; bol stoklu ya da yavaş satan ürünlerde sıfır olabilir. Eşikler ürün ya da kategori bazında yönetilir ve fark raporuna göre ayarlanır.

Pazaryeri kendi stoğunu düşüyorsa neden ayrıca rezervasyon gerekir?

Pazaryeri yalnızca kendi kanalındaki siparişi düşer. Sitenizden ya da başka bir pazaryerinden gelen siparişi bilmez. O siparişi diğer kanallara yansıtmak entegrasyon katmanının işidir.

Senkron durursa satış durur mu?

Bu, önceden verdiğiniz karara bağlıdır. Kısa kesintide son değer korunabilir; kesinti uzarsa düşük stoklu ürünler kanallarda kapatılabilir. Kararın yazılı olması ve son başarılı senkron zamanına bağlı bir uyarıyla tetiklenmesi gerekir.

Sonraki adım: beş kararı sizin verinizle yazalım

Sitenizde ya da pazaryerinde stok tutmuyorsa, önce beş kararın sizde nasıl verildiğine bakmak gerekir; çoğu zaman sorun bağlantıda değil, tanımdadır. Hiçbir ERP üreticisinin bayisi değiliz; ERP'niz yerinde kalır, ERP entegrasyonu katmanını üreticinin resmî arayüzü üzerinden kurarız. Kapsam ve fiyat sözleşmede yazılıdır, teslim sonrası 15 gün ücretsiz hata düzeltme standardımızdır. İlk keşif görüşmesi online ve ücretsizdir; iletişime geçin ya da isterseniz WhatsApp'tan yazın.