Depoda Sayım Sonrası ERP ile Depo Sistemi Arasındaki Stok Uyuşmazlıklarını Teşhis ve Düzeltme

Giriş: Somut bir problem tanımı

Depo sayımı sonrası birçok işletme, ERP sistemi ile depo/barkod tabanlı stok takip sistemi arasında sayılar farklı olduğu için operasyonel problemlere yol açar. Bu durum sipariş gecikmeleri, yanlış sevkiyat veya hatalı maliyetleme gibi sonuçlar doğurur. Bu rehber, depoda yapılan sayımda tespit edilen farkların nedenlerini teşhis etmek ve bunları teknik olarak düzeltmek için uygulanabilir adımlar sunar. Teknik öneriler ASP.NET Core, C# ve SQL Server ile uyumludur ve barkod ve depo otomasyonu çözümlerimiz ile entegrasyon senaryolarını esas alır.

1. İlk adım: Problemi sınıflandırma ve kapsam belirleme

Her uyuşmazlık aynı değildir. Önce problemi kategorize edin:

• Tek pozisyon/tek SKU uyuşmazlığı: Belirli bir lokasyon veya ürün için miktar farklılığı.
• Toplam stok farkı: Depo genelinde toplam stok ERP ile farklı.
• Geçici senkronizasyon açığı: Gerçek zamanlı replike edilmeyen hareketler sonucunda gecikme.
• Etiket veya barkod sorunları: Yanlış veya güncellenmiş etiketler nedeniyle yanlış SKU eşleşmesi.

Bu sınıflandırma, hangi veri setlerini toplayacağınızı ve hangi sistem bileşenlerini inceleyeceğinizi belirler.

2. Veri toplama: Delilleri sağlam toplayın

Uyuşmazlığı çözmek için loglar ve veri kanıtları gereklidir. Aşağıdaki veri setlerini toplayın ve saklayın:

• Depo uygulaması (barkod) işlem günlükleri: okutulan barkod, kullanıcı, cihaz ID, zaman damgası, işlem türü (giriş/çıkış/sayım).
• ERP stok hareket kayıtları: hareket tipi, belge numarası, zaman damgası, referans.
• Sayım raporu ve kullanıcı notları: sayım zamanı, sayımı yapan kişi, özel notlar.
• Entegrasyon API logları: gelen/giden payload, HTTP durum kodu, idempotency anahtarı varsa.

SQL Server tarafında sorgu örnekleriyle hızlıca bakış atın: örneğin belirli bir SKU için son 7 günlük hareketleri görmek için:

Örnek SQL: SELECT MovementDate, MovementType, Quantity, SourceSystem, Reference FROM StockMovements WHERE SKU = 'SKU123' AND MovementDate >= DATEADD(day, -7, GETDATE()) ORDER BY MovementDate;

3. En sık karşılaşılan teknik nedenler ve tespit yöntemleri

• Zaman damgası tutarsızlığı (clock skew): Depo el terminalleri veya barkod okuyucular ile ERP sunucusu arasındaki saat farkları, olay sıralamasını bozabilir. Cihazların NTP ile senkronize olup olmadığını kontrol edin.
• Çift okuma veya atlanan okuma: Barkod okuyucu bazen aynı öğeyi iki kez kaydedebilir veya okuma başarısızlığı nedeniyle işlem atlanabilir. Cihaz loglarını ve okuyucu firmware versiyonlarını kontrol edin.
• API idempotency eksikliği: Ağ sorunları nedeniyle aynı talep birden fazla kez gönderilmiş ve ERP'de birden çok hareket oluşturulmuş olabilir. API tarafında idempotency key ve benzersiz transaction ID kullanın.
• Manuel müdahale ve ara işlemler: Çalışanların manuel stok düzeltmeleri veya yazılımsal geri alma işlemleri belgeyle kayıt altına alınmamış olabilir. Tüm manuel değişikliklerin gerekçesi ve kullanıcı kimliği ile kaydedilmesi gerekir.
• Barkod/etiket güncelleme hatası: SKU eşlemesi değişmiş ancak eski etiketler depoda kalmış olabilir. Etiket versiyonlama stratejisi uygulayın.

4. Teknik çözüm adımları (önceliklendirilmiş)

Aşağıdaki adımlar, kısa ve orta vadede uygulanabilirlik önceliğiyle sıralanmıştır.

4.1. Okuma ve hareket audit kaydı oluşturma

• El terminallerinde her okuma için device_id, user_id, raw_barcode, timestamp kaydedin.
• En az 30 gün tutulan tam audit tablosu oluşturun. SQL Server tarafında bu tablo için uygun indeksleme yapın (SKU, timestamp, device_id).

4.2. Idempotent entegrasyon

API isteklerine bir idempotency_key ekleyin. Bu, aynı hareketin tekrar işlenmesini önler. ASP.NET Core tarafında şöyle bir akış önerilir:

• API isteği alındığında idempotency_key kontrol edilir. Daha önce işlenmişse aynı cevap döndürülür, yeni ise işlem başlatılır.
• Transaction başladığında SQL Server'da işlem kaydı StockMovement tablosuna yazılır ve idempotency kaydı ile ilişkilendirilir.

4.3. Veri rekonsiliasyonu (reconciliation) servisi

Haftalık veya günlük olarak çalışacak otomatik bir rekonsiliasyon servisi kurun. Bu servis şu işi yapar:

• ERP stok miktarlarını çek (API/DB).
• Depo uygulamasının sayım sonuçlarını ve hareket özetlerini çek.
• SKU bazında farkları hesapla ve farkın kaynağına göre sınıflandır (ör: bekleyen sevkiyat, iptal edilen sipariş, hatalı okunmuş işlem).

Fark raporuna göre otomatik düzeltme (ör: açık transferleri tamamla) veya insan onayı gerektiren düzeltme (adjustment) arasındaki iş akışını belirleyin.

4.4. Geçici kilitleme ve sıra garantisi

Yoğun işlemlerde aynı SKU üzerinde eşzamanlı güncellemeler olabilir. SQL Server'da uygun izolasyon seviyesi (ör. snapshot isolation) ve/veya uygulama düzeyinde optimistic concurrency kontrolü (rowversion/timestamp) kullanın.

4.5. Barkod etiket yönetimi

• Etiket versiyonlama: Yeni SKU mapleri veya parti değişiklikleri için etiketin versiyon numarası olsun. Okuyucu bunu yakalayıp uyumsuzluk durumunda uyarı versin.
• Yazılımda etiket geçerlilik süresi, parti/lot ilişkilendirme ve son güncelleme bilgisi tutun.

5. Uygulama örnekleri: ASP.NET Core ve SQL Server'da pratik adımlar

Burada C# ve SQL Server kullanarak yapılabilecek somut adımlar özetlenmiştir:

• Transaction model: Her stok hareketi için bir API endpoint (POST /api/stock/move) tasarlayın. Endpoint isteği aldığında idempotency_key kontrol edilir, ardından EF Core ile transaction başlatılır ve StockMovement kaydı yapılır.
• Concurrency kontrolü: Stok miktarlarını tutan tabloda rowversion sütunu ekleyin. Güncelleme yaparken client'ın gönderdiği rowversion ile eşleşmeyorsa 409 Conflict döndürün ve istemci yeniden okuyup işlemi tekrar denesin.
• Batch reconciliation: SQL Server Agent job ile günlük reconciliation stored procedure çalıştırın. Bu procedure SKU bazında ERP ve depo verilerini karşılaştırıp fark tablolarına yazsın.

Örnek SQL karşılaştırma satırı: SELECT d.SKU, d.Quantity AS DepotQty, e.Quantity AS ERPQty, (d.Quantity - e.Quantity) AS Diff FROM DepotStock d JOIN ERPStock e ON d.SKU = e.SKU WHERE d.Quantity <> e.Quantity;

6. Kullanıcı arayüzü ve iş akışı

Teknik çözümler kadar kullanıcı iş akışı da önemlidir. Bircıkaç öneri:

• Reconciliation dashboard: Fark gözükecek bir dashboard; farkın büyüklüğü, neden adayı (bekleyen transfer, okunmamış hareket vb.) ve önerilen aksiyon (otomatik düzeltme, manuel onay) gösterilsin.
• Manuel düzeltme formu: Kullanıcı düzeltme yaparken neden seçmeli, belge numarası eklemeli ve değişiklikleri audit kaydıyla saklanmalı.
• Mobil uyarılar: El terminallerine kritik farklarda anlık uyarı gönderilmesi, etiket güncellemesi gerektiğinde yönlendirme.

7. Kontrol listesi: Hızlı adım adım

• 1) Tüm cihazların saatlerinin NTP ile senkronize olduğundan emin olun.
• 2) Barkod okuyucu ve ERP hareket loglarını toplayın ve analiz edin.
• 3) API isteklerine idempotency key ekleyin.
• 4) SQL tarafında rowversion ve uygun izolasyon kullanın.
• 5) Otomatik reconciliation servisi kurun; farkları sınıflandırın.
• 6) Kullanıcı onayı gerektiren düzeltme adımları için audit kaydı oluşturun.
• 7) Etiket versiyonlama ve yeniden etiketleme prosedürü belirleyin.

8. İzleme ve sürekli iyileştirme

Uyuşmazlıkların tekrarlanmaması için ölçülebilir metrikler belirleyin: günlük reconciliation mismatch sayısı, idempotency hatası oranı, manuel düzeltme adedi. Bu metrikleri zamanla düşürmeyi hedefleyin ve değişiklik yaptıkça A/B biçiminde etkiyi ölçün.

9. Ne zaman özel yazılım gerekir?

Eğer var olan sistemlerinizde sürekli manuel düzeltme, yüksek frekanslı idempotency hataları veya heterojen el cihazı altyapısı varsa, özel yazılım ile:

• Entegrasyon katmanınızı merkezi bir API geçidiyle standardize edebilir,
• İş kurallarını tek yerde toplayıp audit ve reconciliation otomasyonunu yerleştirebilir,
• Depo uygulamanız ile ERP arasındaki eşleştirme mantığını (mapping) dinamik hale getirebilirsiniz.

Bu tür ihtiyaçlar için detaylı teknik değerlendirme ve yol haritası oluşturmak isterseniz iletişime geçebilirsiniz.

Sonuç

Depo sayımı sonrası ERP ile depo sistemi arasındaki stok uyuşmazlıkları, doğru veri toplama, idempotent entegrasyon, uygun SQL izolasyonları ve düzenli reconciliation ile büyük ölçüde azaltılabilir. Hem yazılım hem operasyonel süreçlerde yapılacak küçük ama sistematik iyileştirmeler, tekrar eden düzeltme iş yükünü düşürür ve sevkiyat/hizmet kalitesini artırır. Bu rehberde verilen adımlar, ASP.NET Core, C# ve SQL Server ortamlarında doğrudan uygulanabilecek teknik ve pratik çözümler sunar.

Not: Her depo ve ERP kombinasyonu farklılık gösterir; yukarıdaki adımlar genel bir yol haritasıdır. Uygulamaya özel tasarım ve testler için profesyonel destek almak operasyonel riski azaltır.