Çoklu Depo Stok Yönetimi: Fazla Satışı Önleyen Tasarım

Tek stok sayısı neden yetersiz kalır?

Bir ürün fiziksel olarak rafta olsa bile başka sipariş için ayrılmış olabilir. Yolda olan transfer ise hedef depoda henüz teslim alınmamıştır. Shopify stok modelinde fiziksel miktar, satılabilir miktar ve farklı ayrılmış durumlar ayrı kavramlar olarak ele alınır. [1] Kendi entegrasyonunuzun da bu kavramları tek bir “stok” alanında eritmemesi gerekir.

Önce her deponun hangi durumları kullandığını çıkarın. Kalite kontrol bekleyen iade, hasarlı ürün ve güvenlik stoğu için sorumlular farklı olabilir. Muhasebe, depo ve satış ekibinin aynı kelimeye farklı anlam vermesi, teknik eşitleme doğru çalışsa bile ticari hataya yol açar.

Kaynağı ürün bazında değil alan bazında belirleyin

Depo sistemi fiziksel sayım için esas kaynak olabilir; satış kanalı ise henüz sevk edilmemiş siparişleri tutuyor olabilir. Hangi miktarın hangi sistemde hesaplandığını yazın. “ERP her zaman doğrudur” veya “mağaza her zaman doğrudur” gibi genel bir kural, bu ayrımları açıklamıyorsa yetersizdir.

Düzeltme işlemlerinde geçmiş değeri kaybetmeyin. Kim, hangi gerekçeyle ve hangi depo için stok ayarı yaptı? Sayım farkı ile müşteri iptalini aynı işlem türü olarak kaydetmeyin. Böylece günlük uzlaştırmada farkın kökenini araştırmak mümkün olur.

Örnek: son ürünü iki müşteri satın alıyor

Varsayımsal depoda satılabilir miktar birdir. İki ödeme akışı aynı anda bu değeri okursa ikisi de satışa devam edebilir. Çözüm, yalnızca ödeme düğmesini kapatmak değil, rezervasyonun tutarlı bir yazma işlemiyle yapılmasını sağlamaktır. Veri tabanı işlemleri ve izolasyon davranışı bu tasarımın parçasıdır; kullanılan düzeyin eşzamanlılık etkisi test edilmelidir. [2]

Önerilen senaryoda rezervasyon benzersiz sipariş referansına bağlanır. İşlem sonucu belirsizse aynı referansla tekrar sorgulanır. İkinci müşteriye alternatif depo veya stok bulunamadı mesajı gösterilir. Kesin davranış ticari kurala bağlıdır; sistem sessizce eksi stok oluşturmamalı veya müşteriye doğrulanmamış teslim sözü vermemelidir.

Rezervasyonun ömrünü açıkça tanımlayın

Ödemesi tamamlanmayan rezervasyonun ne zaman bırakılacağı belirlenmelidir. Süre dolumu ile ödeme onayının aynı anda gelmesi için bir çakışma kuralı gerekir. Yalnızca zamanlayıcı çalıştırmak yeterli değildir; rezervasyonun mevcut durumu geçiş anında yeniden kontrol edilmelidir.

Depolar arası transferi iki hareket olarak izleyin

Kaynak depodan çıkış ve hedef depoda teslim alma aynı an olmak zorunda değildir. Transfer yoldayken her iki depoda satılabilir görünmemelidir. Kaynak çıkışı, yol durumu, kısmi teslim ve hasar kaydı ayrı izlenebilir. Böylece transferin bir bölümünün ulaşması bütün miktarı yanlışlıkla açmaz.

Birden fazla satış kanalı varsa güncelleme gecikmesini de göz önünde bulundurun. Kanal kapasitesi ve iş modeli için kabul edilen güvenlik payı operasyon ekibiyle belirlenebilir. Bu pay gerçek veriden türetilmeli; evrensel bir yüzde olarak sunulmamalıdır.

Teslimde rakam değil senaryo isteyin

Test seti son ürün yarışı, geciken ödeme, yinelenen iptal, kısmi sevk ve kısmi transferi kapsasın. Her senaryoda kaynak ve hedef sistemin başlangıç ve bitiş değerlerini kaydedin. Sadece ekran görüntüsü yerine işlem referanslarıyla doğrulanabilir bir iz oluşturun.

Günlük raporda negatif miktar, uzun süre açık rezervasyon, eşleşmeyen transfer ve kaynak-hedef farklarını ayrı sınıflandırın. Bütün uyarıları aynı önem düzeyinde göstermek operatörü yorabilir. Önceliklendirme, müşteriye verilen teslim sözü ve satışa açılan miktar üzerindeki etkiye göre yapılmalıdır.

Sık sorulan sorular

### Anlık entegrasyon fazla satış riskini tamamen kaldırır mı? Hayır. Gecikme dışında eşzamanlı işlemler, yanlış kaynak seçimi ve hatalı durum geçişleri de risk oluşturur. Tasarım ve test bu senaryoları birlikte ele almalıdır.

İade gelen ürün hemen stoğa eklenmeli mi?

İşletmenin kontrol sürecine göre karar verin. Fiziksel teslim alınma ile yeniden satılabilir olma farklı aşamalardır; inceleme tamamlanmadan satılabilir miktara eklenmesi yanlış olabilir.