Turkpin Bakiye ve Stok Senkronizasyonunun Perde Arkası: Bayilerin Gece Yarısı Satış Kaybettiği Sessiz Ayar ve Doğru e-pin Scripti Kurgusu

Bakiye ve stok senkronizasyonu duyunca çoğu işletme sahibinin aklına tek bir şey gelir: "her sayfa açılışında tedarikçiden güncel veriyi çekelim, en doğrusu bu." Kulağa mantıklı geliyor ama sahada tam tersi olur. En sık satış kaybeden kurulumlar, senkronizasyonu en sık yapan kurulumlardır. Çünkü her açılışta canlı sorgu atan sistem, ilk yavaşlamada ürün listesini boş gösterir ve müşteri sepetini terk eder.

İşin gerçeği şu: senkronizasyon bir hız yarışı değil, bir karar mimarisi. Hangi veriyi ne sıklıkla tazeleyeceğin, hangi durumda eski veriye güvenip satışa devam edeceğin, hangi eşikte satışı kendi kendine kısacağın önceden yazılmış olmalı. Bu yazıda bakiyeyi, stoğu ve fiyatı ayrı ayrı ele alıp bir e-pin satış yazılımı içinde nasıl kurgulanmaları gerektiğini adım adım açıyoruz.

Bakiye, stok ve fiyat aynı şey değil — neden ayrı kurgulanmalı?

Bu üç veri farklı hızlarda değişir ve farklı riskler taşır. Bakiye senin cüzdanındır; yanlış bilinirse satış kabul edip teslim edemezsin. Stok tedarikçinin envanteridir; yanlış bilinirse olmayan ürünü satarsın. Fiyat ise kâr marjındır; yanlış bilinirse satarsın ama zararına satarsın. Aynı tazeleme kuralını üçüne birden uygulamak, en hassas olanı en gevşek olanın hızına mahkûm eder.

Doğru kurgu şudur: bakiye kısa aralıkla ve mutlaka sipariş öncesinde kontrol edilir; stok makul bir önbellek penceresiyle taşınır ve teslimat anında kesin doğrulanır; fiyat ise zamanlanmış toplu güncellemeyle çekilip kendi marj kuralından geçirilir. Bu ayrımı yapan bir dijital ürün satış scripti, hem hızlı hem de dürüst bir vitrin kurar.

Her sayfa açılışında canlı sorgu atmak niye kendi ayağına sıkmak?

Kategori sayfanda otuz ürün varsa ve her ürün için tek tek canlı stok sorgusu atıyorsan, tek bir ziyaretçi otuz istek üretir. On ziyaretçi üç yüz istek eder. Tedarikçi tarafındaki istek limitine çarpmanız an meselesidir ve limite çarptığın anda ürünler "stokta yok" görünmeye başlar. Yani senkronizasyon aşırılığı, birebir satış kaybına dönüşür.

Bunun yerine tek bir toplu çağrıyla tüm envanteri çek, kendi tarafında sakla ve vitrini bu yerel kopyadan besle. Kritik doğrulamayı sadece ödeme onaylandıktan sonra, yani gerçekten kod üretilecek anda yap. Böylece binlerce gereksiz istek yerine yalnızca satış sayısı kadar kritik sorgu atarsın.

Bakiye bittiğinde sistemin ne yapması gerekir?

En sinir bozucu senaryo şudur: bakiye gece yarısı tükenir, hiç kimse fark etmez, sipariş akmaya devam eder ve sabah elinde yirmi tane teslim edilmemiş sipariş olur. Bunu engellemek için tek bir sayı yeterli değil; kademeli bir eşik sistemi gerekir. Birinci kademede uyarı gönderilir, ikinci kademede yüksek tutarlı ürünler satıştan çekilir, üçüncü kademede otomatik teslimat durdurulup siparişler kuyruğa alınır.

Kuyruğa alma kısmı kritik. Satışı tamamen kapatmak yerine siparişi "bakiye bekleniyor" durumunda tutmak, sen yükleme yaptığın anda kuyruğun otomatik boşalmasını sağlar. Müşteri iptal görmez, birkaç dakika bekler ve kodunu alır. Olgun bir epin yazılım altyapısında bu davranış varsayılan olarak bulunur.

Fiyat senkronizasyonunda marjı kim koruyor?

Alış fiyatını otomatik çekip satış fiyatını elle yönetmek, birkaç yüz ürünü geçtiğinde sürdürülemez hâle gelir. Buradaki doğru yapı, satış fiyatının hiçbir zaman elle girilmemesi; her ürün için bir marj kuralı tanımlanması ve satış fiyatının alış fiyatı ile bu kuraldan otomatik hesaplanmasıdır. Kural yüzdesel olabilir, sabit tutar olabilir, kategori bazlı olabilir.

İkinci koruma katmanı ise taban fiyattır. Tedarikçi tarafında bir veri hatası olur ve alış fiyatı absürt biçimde düşük gelirse, taban fiyat kuralı ürünü zararına satılmaktan kurtarır. Aynı şekilde üst sınır kuralı da anormal yükselmede ürünü satıştan çeker ve sana bildirim gönderir. Hangi kuralların hangi pakette hazır geldiğini fiyat bölümünde görebilirsin.

Senkronizasyon sağlığını nasıl ölçeceksin?

Çalıştığını varsaymak yerine ölçmek gerekir. Bir senkronizasyon katmanının sağlıklı olup olmadığını anlatan dört rakam vardır: son başarılı güncelleme zamanı, başarısız çağrı oranı, ortalama yanıt süresi ve stok uyuşmazlığı sayısı. Bu dördü panelde tek ekranda görünmüyorsa, bir gün sistemin sessizce durduğunu müşteri şikâyetinden öğrenirsin.

Özellikle "son başarılı güncelleme" değerini ciddiye al. Zamanlanmış görev sessizce durduğunda hiçbir hata mesajı almazsın; vitrin sadece eskimeye başlar. Bu yüzden belirlenen süreden uzun süredir güncellenmeyen bir katman için otomatik uyarı kurulmalı. Ölçüm ekranlarının nasıl çalıştığını özellikler bölümündeki yönetim paneli anlatımında inceleyebilirsin.

Aynı görevin iki kez çalışması niye sessiz bir bela?

Zamanlanmış görevler uzun sürdüğünde bir sonraki tetikleme, öncekisi bitmeden başlar. İki kopya aynı anda çalıştığında fiyatlar yarı yolda karışır, stok sayıları birbirine girer, en kötüsü aynı sipariş iki kez işlenir. Çözüm basit ama çoğu kurulumda yok: görev başlarken bir kilit alır, bitince bırakır; kilit doluysa yeni kopya hiç başlamaz.

Aynı mantığı sipariş işleyicisi için de kurmalısın. Tek bir siparişi tek bir işleyici alsın, aldığı anda o satırı kilitlesin. Bu küçük disiplin, "bir müşteriye iki kod gitti" vakalarının neredeyse tamamını ortadan kaldırır ve bir e-pin scripti için olgunluk göstergesidir.

Senkronizasyon, ne kadar sık sorgu attığınla değil, ne kadar doğru karar verdiğinle ölçülür. Bakiyeyi eşiklerle, stoğu önbellek artı kesin doğrulamayla, fiyatı marj kuralıyla yönettiğinde sistem gece yarısı da senin yerine düşünmeye başlar. Bu kurgunun gerçek bir panelde nasıl hissettirdiğini görmek istersen canlı demo üzerinden ürün listesini, bakiye kartını ve zamanlanmış görev ekranını inceleyebilir, kendi kataloğunla nasıl çalışacağını rahatça test edebilirsin.