Barkod Etiket Güncellemesiyle Oluşan Stok Uyumsuzluğunu Çözme: Teknik Rehber

Giriş — Hangi somut problemi ele alıyoruz?

Birçok üretim ve dağıtım işletmesinde ortaya çıkan tekrarlayan problem şudur: depo personeli veya üretim hattı barkod etiketini güncelliyor (örneğin parti/lot/seri numarası düzeltmesi veya yeniden etiketleme), fakat bu değişiklik ERP veya stok takip sistemine doğru ve zamanında yansımıyor. Sonuç; yanlış stok kayıtları, sevkiyat hataları, kalite takibinde boşluklar ve müşteri kaçırma riski. Bu yazıda bu tek, somut uzun kuyruklu soruna odaklanıyoruz: barkod etiket güncellemelerinin neden olduğu stok uyumsuzlukları nasıl önlenir ve varsa nasıl düzeltilir?

Kısa çözüm özeti (kontrol listesi)

• Tarayıcı cihazların çalışma modunu belirleyin: online vs offline.
• Her etiket güncellemesini idempotent bir API çağrısı ile kaydedin.
• Veritabanında değişiklik geçmişi (audit) ve lot/seri ilişkilendirme tablosu tutun.
• Store-and-forward (cached writes) & reconciliation mekanizması uygulayın.
• Çakışma çözümü için kullanıcı arayüzü ve iş akışı tasarlayın.
• Olay tabanlı replikasyon veya message queue ile ERP entegrasyonunu sağlayın.

Neden bu problem sık tekrar eder?

Birkaç teknik ve operasyonel sebep sıktır:

• Mobil barkod okuyucuların offline çalışması ve merkezi sisteme geç bildirilen değişiklikler.
• Barkod formatlarında yapılan değişikliklerin (ör. GS1 alan ekleme) sistemlerde aynı şekilde yorumlanmaması.
• API çağrılarının idempotent olmaması; yeniden gönderimlerin duplicate veya inconsistent kayıtlara yol açması.
• ERP ve WMS arasındaki senkronizasyonun anlık değil de dönemsel yapılması.

Teknik tasarım: yüksek seviyede yaklaşım

Aşağıda önerilen mimari bileşenleri ve rolünü göreceksiniz. Bu tasarım, özel yazılım geliştirme pratikleri ve entegrasyon tecrübelerine dayalı uygulanabilir adımları içerir.

1) Cihaz katmanı (barkod okuyucular / IoT)

• Cihazlar iki modda çalışabilmeli: online (anında API çağrısı) ve offline (lokal cache, zaman damgası, idempotency anahtarı ile yerel saklama).
• Tarayıcının SDK'sı kullanılıyorsa, tarama verisini paket halinde JSON olarak hazırlayıp yerel store'a yazın; tekrar gönderimlerde aynı idempotency key kullanılmalı.
• Donanım seçeneklerini değerlendirirken keyboard wedge yaklaşımdan kaçının; doğrudan SDK/HTTP tabanlı entegrasyon daha güvenilirdir.

2) API katmanı (ASP.NET Core)

• Her barkod güncellemesi için RESTful API veya gRPC endpoint oluşturun: /api/depo/etiket-guncelle (POST).
• Gelen payload içinde: deviceId, scanId (idempotency key), barcodeBefore, barcodeAfter, userId, timestamp, location bilgileri bulunmalı.
• API, SQL Server üzerinde transaction açıp önce validation yapmalı: mevcut stok, lot/seri ilişkisi, eşleşen kayıtlar.
• Idempotency: aynı scanId tekrar gelirse ikinci kez işlenmemeli, ancak durum sorgusu döndürülmeli.
• İşlem ağır veya ERP entegrasyonuna bağlı ise API hemen accept (202) dönebilir ve değişiklikleri arka planda kuyruğa bırakabilir (message queue).

3) Mesajlaşma ve background processing

• Kuyruk sistemi (RabbitMQ, Azure Service Bus vb.) ile ERP'ye gönderilecek değişiklikleri sıraya alın.
• Arka plan işçisi (ASP.NET Core Hosted Service veya ayrı mikroservis) kuyruğu tüketip işlem tamamlandığında veritabanını günceller ve audit kaydı bırakır.
• Bu yapı, zaman aşımı, tekrar deneme (retry) ve poison message yönetimine izin verir.

4) Veri modeli ve SQL Server tasarımı

Örnek tablolar ve önemli alanlar:

• Items: itemId, sku, description
• Lots: lotId, itemId, lotNumber, expiryDate
• StockUnits: stockUnitId, locationId, lotId, quantity
• Scans: scanId (idempotency), deviceId, userId, barcodeBefore, barcodeAfter, status, createdAt
• StockTransactions: txId, scanId, type (label_update, move, adjust), qty, resultingBalance

Ek öneriler:

• Değişikliklerin izlenmesi için audit ve trigger yerine uygulama tarafında yazma tercih edin; trigger'lar karmaşıklığı artırabilir.
• SQL Server'da temporal tables veya change tracking ile geçmişe dönüş ve reconciliation kolaylaşır.

İş akışı örneği: Etiket değişimi gerçekleştiğinde adım adım

1. Kullanıcı tarayıcı ile ürünün eski barkodunu okur ve yeni barkodu uygular; cihaz yeni giriş oluşturur ve bir scanId üretir.
2. Cihaz online ise API'ye POST; offline ise lokal queue'ya kaydeder. Her iki durumda scanId benzersizdir.
3. API gelen isteği doğrular: eski barkod eşleşiyor mu? stok yeterli mi? Eğer belirsizlik varsa isteği 'pending' olarak işaretler ve insan onayı tetikler.
4. İşlem kabul edilirse bir StockTransaction oluşturulur, Scans tablosunda kayıt güncellenir ve ERP entegrasyon kuyruğa gönderilir.
5. Arka plan işçisi kuyruğu tükettiğinde ERP'ye gönderim yapar; başarılıysa kaydın status'u 'completed' olur, aksi halde hata ile 'failed' olarak loglanır ve retry planlanır.

Çakışma ve hata yönetimi

Çakışma örneği: aynı lot üzerinde iki farklı kullanıcı aynı anda farklı etiket değişikliği yapmaya çalışır. Öneriler:

• Optimistic concurrency kontrolü: StockUnits tablosunda rowversion/timestamp alanı kullanın.
• API kabul etmeden önce mevcut lot durumunu yeniden sorgulayın; mismatch tespit edilirse kullanıcıya gerçek zamanlı uyarı gösterin.
• Manuel düzeltme arayüzü: depoda reconciliation gerektiren kayıtları listeleyen bir ekran sağlayın; burada kullanıcılar hangi kayıtın doğru olduğunu seçer ve sistem buna göre düzeltir.

Operasyonel öneriler ve hata önleme

• Barkod formatı standartlaştırma: GS1 veya benzeri tek bir şablon kullanın; değişiklikleri sürüm kontrolü ile yönetin.
• Periyodik reconciliation: her gece veya vardiya sonunda SAP/ERP ile otomatik karşılaştırma çalıştırın ve anomali raporu üretin.
• Telemetri ve izleme: API çağrıları, kuyruk tamamlama süreleri, başarısız scan oranları için metrik toplayın.
• Eğitim ve prosedür: etiket yeniden basma süreçlerini ve acil durumda izlenecek adımları yazılı hale getirin.

Uygulama örnekleri ve pratik ipuçları

Gerçek uygulamada dikkat etmeniz gereken bazı pratik noktalar:

• İdempotency key olarak deviceId + localSeq + timestamp kombinasyonunu veya GUID kullanın.
• API tarafında tüm kritik alanlar için açık validasyon yazın: barcodePattern, length, checksum.
• Offline cihazlarda hem queue hem de küçük SQLite/leveldb tarzı lokal DB kullanmak veri bütünlüğünü artırır.
• Test senaryoları: network partition, duplicate scan, delayed replay, concurrent updates gibi durumları otomasyon testlerine ekleyin.

ERP entegrasyonu — dikkat edilmesi gerekenler

ERP tarafında genellikle stok kayıtları ana kaynak kabul edilir. Bu yüzden:

• Değişiklik gönderiminde change request mantığı kullanın: ERP kendi iş kurallarına göre kabul/red edebilir; sonucu sistemi bilgilendirin.
• İki taraflı senkronizasyon gerekiyorsa delta-only paketler gönderin; tam snapshot'lar gereksiz yük yaratır.
• Entegrasyonda idempotency ve işlem numarası kullanın; işlem birden fazla kez uygulansa bile netice tek olacak şekilde tasarlayın.

İç bağlantılar ve bir sonraki adım

Eğer depo etiketleme, barkod bazlı depo süreçleri ve bu tür özel entegrasyonlar için uygulama geliştirmek istiyorsanız, teknik altyapı ve saha cihazları seçimiyle ilgili detayları içeren hizmetimizi inceleyebilirsiniz: Barkod & depo çözümlerimiz. Daha spesifik bir keşif veya teklif almak isterseniz doğrudan bizimle iletişime geçin: İletişim.

Sonuç — Yatırımın somut getirileri

Barkod etiket güncellemelerinden kaynaklanan stok uyumsuzluklarını önlemek, sadece teknik bir uygulama değildir; operasyonel güvenilirliği, müşteri memnuniyetini ve takip edilebilirliği artırır. Yukarıda özetlenen mimari ve uygulama desenleri, mevcut depo takip sisteminiz (depo stok takip yazılımı veya depo takip programı) ile entegrasyonu kolaylaştıracak ve tekrarlayan hataları minimize edecektir. Uygulamaya geçmeden önce küçük pilotlar ile test edip reconciliation süreçlerini işletme kullanıcıları ile birlikte iyileştirmeniz önerilir.

Ek kaynaklar ve bir sonraki adım

Bu rehbere dayanarak teknik bir PoC (proof of concept) hazırlamak isterseniz, veri modeli örnekleri, API şemaları ve cihaz entegrasyonu checklist'i içeren bir çalışma paketini paylaşabiliriz. Başlamak için iletişim sayfamızdan taleplerinizi iletin; teknik ön inceleme sonrası uygulanabilir bir yol haritası çıkarılabilir.