STOK VE FİYAT SENKRONİZASYONUNU PLANLAMAK VE OTOMATİKLEŞTİRMEK
Bir ürün “stokta var” görünürken depoda bitmişse, sonuç genellikle iptal ve memnuniyetsizlik olur. Tersi de mümkün: stok var ama sitede “tükendi” yazdığı için satış kaçırırsınız. Fiyat tarafında ise daha riskli bir tablo çıkar; yanlış etiket, kampanya çakışması veya kanal bazlı tutarsızlık, kârı hızla eritebilir.
Bu yüzden stok ve fiyat senkronizasyonu sadece teknik bir entegrasyon konusu değildir; iş kuralı, veri modeli ve operasyon birlikte düşünülmelidir. Hangi sistem “ana kaynak” olacak, güncellemeler ne sıklıkla akacak, hatalar nasıl yakalanacak, geri alma (rollback) nasıl yapılacak?
Bu yazıda, senkronizasyonu planlarken izlenecek adımları, sık yapılan hataları ve otomasyonu sürdürülebilir kılmanın yöntemlerini ele alacağız. Amaç, tek seferlik kurulum değil; büyüdükçe bozulmayan bir düzen kurmaktır.
Tek veri kaynağı belirleyerek tutarlılık sağlamak
Senkronizasyonun ilk kararı şudur: Stok ve fiyatın “gerçeği” hangi sistemde tutulacak? ERP, depo yönetimi, e-ticaret altyapısı, PIM veya marketplace paneli aynı anda ana kaynak olamaz. Birden fazla kaynağın yazdığı yapıda, “son yazan kazanır” kuralı sessizce veri bozar.
Stok ve fiyat sahipliğini netleştirerek ilerlemek
Stok için genellikle depo/ERP; fiyat için ise fiyat motoru, ERP veya kampanya yöneten sistem ana kaynak olur. “Kim yazar, kim okur?” sorusunu yazılı hale getirmek, tartışmayı bitirir. Böylece güncellemeler tek yönde akar, istisnalar ayrı kuralla yönetilir.
Kanal bazlı fiyat kurallarını tanımlayarak uygulamak
Her kanalda aynı fiyat zorunlu değildir; komisyon, kargo ve rekabet farklıdır. Ancak kanal fiyatı yönetilecekse, bu karar kural seti olarak tanımlanmalı; “manuel düzeltme”ye bırakılmamalıdır. Örnek: “Marketplace A fiyatı, liste fiyatının %3 üstü” gibi.
Ürün kimliğini standartlaştırarak eşleştirme kurmak
Senkronizasyonun kırıldığı yerlerin başında ürün eşleştirme gelir. SKU, barkod, varyant kodu ve kanal ürün ID’si birbirine karıştığında; doğru ürüne yanlış stok, doğru varyanta yanlış fiyat gidebilir.
SKU ve varyant modelini ortaklaştırarak yönetmek
Renk/beden gibi varyantlar, tek ürün altında farklı satılan kalemlerdir. Varyant kodları tutarsızsa, stok bir varyanttan diğerine “kaymış” görünür. En pratik yaklaşım, her varyantın tekil SKU’sunu zorunlu kılmak ve tüm kanallarda aynı mantıkla taşımaktır.
Kanal ürün ID haritasını güncel tutarak ilerlemek
Marketplace’ler ürün ID’sini değiştirir, birleşme/ayrışma olur, ilan kapanır/açılır. Bu yüzden “ID mapping” tablosu canlı tutulmalıdır. Yeni ürün açıldığında eşleştirme otomatik oluşmalı; kapanan ürünlerde mapping pasife alınmalıdır.
{
"event": "stock_price_update",
"source": "erp",
"timestamp": "2026-02-14T10:15:30Z",
"items": [
{
"sku": "TSHIRT-BLK-M",
"stock_on_hand": 42,
"stock_reserved": 5,
"sellable_stock": 37,
"currency": "TRY",
"list_price": 699.90,
"sale_price": 599.90,
"channel_rules": {
"web": { "sale_price": 599.90 },
"marketplace_a": { "sale_price": 619.90 }
}
}
]
}Akış tipini seçerek güncelleme ritmi kurmak
Stok ve fiyat değişimleri aynı hızda akmak zorunda değildir. Stok daha sık değişir; fiyat ise kampanya dönemlerinde “anlık” hale gelebilir. Burada kritik olan, akış tipini ve gecikme toleransını belirlemektir.
Batch ve gerçek zamanlı yaklaşımı dengelemek
Batch (toplu) akış, belirli aralıklarla güncelleme yapar; yönetmesi kolaydır. Gerçek zamanlı akış (webhook, event stream), hızlıdır ama izleme ve hata yönetimi daha zorlayıcı olabilir. Yaygın ve dengeli model: stok için daha sık batch + kritik ürünlerde gerçek zamanlı tetikleyici kullanmaktır.
Stok rezervasyon mantığını kurgulayarak önlemek
“Stok var” deyip ödemeden sonra iptal yaşanmaması için rezervasyon mantığı şarttır. Sepete ekleyince değil; ödeme adımına gelince rezervasyon yapmak çoğu zaman daha sağlıklıdır. Ayrıca belirli kanallara “buffer stok” bırakmak, oversell riskini azaltır.
- Güncelleme sıklığını kategori ve hacme göre belirlemek
- Buffer stok yüzdesini kanal bazında tanımlamak
- Kampanya fiyatını başlangıç/bitiş saatleriyle kilitlemek
- Hata durumunda geri alma adımını planlamak
- Log ve raporu herkesin okuyacağı şekilde standartlaştırmak
Hata yönetimini tasarlayarak güvenilirlik artırmak
Senkronizasyon “çalışıyor” görünürken bile sessiz hatalar birikebilir: bazı SKU’lar güncellenmez, bazı kanallar limit nedeniyle update’i reddeder, fiyat formatı yanlış gelir. Bu yüzden hata yönetimi en baştan tasarlanmalıdır.
Idempotency ve retry kurgusunu uygulayarak toparlamak
Aynı güncellemeyi iki kez göndermek bazen kaçınılmazdır. Idempotency anahtarıyla “aynı mesaj tekrar geldiyse geç” diyebilmek gerekir. Retry (yeniden deneme) ise kontrollü olmalı; sonsuz deneme yerine artan gecikmeli deneme (backoff) uygulanmalıdır.
Uyarı ve eşik değerlerini belirleyerek izlemek
“Bugün 5.000 SKU güncellendi” normal olabilir; ama “bugün sadece 50 SKU güncellendi” alarmdır. Günlük güncellenen SKU sayısı, başarısız istek oranı, kanal bazlı gecikme süresi gibi metrikler için eşik belirlemek, sorunu müşteriden önce yakalatır.
// Örnek: Basit bir senkronizasyon işleyicisi (pseudo-code)
function processUpdate(message) {
const key = message.source + ":" + message.timestamp + ":" + message.items.length;
if (idempotencyStore.has(key)) return { status: "skipped_duplicate" };
for (const item of message.items) {
validate(item); // fiyat formatı, para birimi, stok alanları
applyBusinessRules(item); // buffer stok, kanal fiyat farkı, kampanya önceliği
// kanal güncellemesi
updateWeb(item);
updateMarketplaces(item);
}
idempotencyStore.put(key, { ttlHours: 48 });
return { status: "ok" };
}
function retryWithBackoff(fn, maxAttempts = 5) {
let attempt = 0;
while (attempt < maxAttempts) {
try { return fn(); } catch (e) {
attempt++;
sleep(Math.pow(2, attempt) * 1000); // 2s, 4s, 8s...
}
}
throw new Error("max_attempts_reached");
}Operasyonel akışı kurarak sürdürülebilir yapmak
En iyi entegrasyon bile operasyonla desteklenmezse bozulur. Yeni ürün açılışı, sezon fiyat güncellemesi, kampanya başlangıcı, iade/iptal kaynaklı stok düzeltmesi gibi süreçler; “kim, ne zaman, hangi kontrolle” sorularına cevap ister.
Sorumluluk matrisi oluşturarak hız kazanmak
Stok farkını kim inceler, fiyat tutarsızlığını kim düzeltir, kanal reddini kim takip eder? Bu roller net değilse, küçük bir hata günlerce sürer. Basit bir sorumluluk matrisi, olay akışını hızlandırır ve tekrar eden problemleri azaltır.
Değişiklik yönetimi planlayarak risk azaltmak
Kampanya, sezon indirimi veya yeni kanal açılışı gibi değişikliklerde “önce test, sonra yayın” akışı gerekir. Küçük bir SKU grubuyla pilot yapmak, yanlış kuralı tüm kataloğa uygulama riskini düşürür. Bu yaklaşımı ekibe yerleştirmek için pratik örneklerle e-ticaret eğitimi içinde standart senaryolar üzerinden ilerlemek mümkündür.
Sonuç: Stok ve fiyat senkronizasyonu; tek kaynak seçimi, doğru ürün kimliği, uygun akış ritmi, güçlü hata yönetimi ve net operasyonel sahiplikle güvenilir hale gelir. Doğru kurgu, satış kaybını önlerken ekiplerin “manuel düzeltme” yükünü de ciddi biçimde azaltır.
