ERP ve Üretim Hattı Arasında Barkod/Seri Numarası Senkronizasyonu: Uygulanabilir Teknik Rehber

Giriş: Neden bu problem kritik?

Üretim hattında basılan veya atanan barkod/seri numarası ile ERP ve depo yönetim sistemi (WMS) arasındaki uyumsuzluk, yanlış sevkiyat, stok hataları ve üretim takip kaybına doğrudan yol açar. Bu sorunun kökü genellikle ağ kesintileri, eşzamanlı güncellemeler, idempotens eksikliği, veya farklı sistemlerin farklı tekil anahtarlar kullanmasından kaynaklanır. Bu rehber, gerçek işletme senaryolarında uygulanabilecek teknik adımları ve mimari kararları açıklar. Eğer kurumsal barkod ve depo akışınızı entegre etmek istiyorsanız, başlangıç noktası olarak barkod ve depo çözümlerimiz sayfasına bakabilirsiniz.

Problem tanımı: Tipik semptomlar

• Üretim hattında basılmış etiketle ERP'deki stok kaydının farklı olması
• Barkod üzerinde güncelleme sonrası önceki etiketin hala WMS'de görünmesi
• Aynı seri numarasının birden fazla partiye atanması
• El terminali veya IoT gateway çevrimdışıyken oluşturulan etiketlerin kaybolması
• Senkronizasyon gecikmesi nedeniyle siparişin yanlış ürünü rezervlemesi

Mimari yaklaşım: Temel prensipler

Çözümü kurgularken şu prensiplere öncelik verin:

• Tekil kimlik ve kaynağın net tanımı: Hangi sistem hangi alanı sahibidir? (ör. üretim hattı seri atama, ERP stok kaydı)
• Olay tabanlı (event-driven) senkronizasyon: Değer değişikliklerini olaylarla (event) yayınlayın; push yerine push+durum doğrulama mantığı kullanın.
• İdempotens: Aynı olay/istek tekrar gelirse sistem durumu tekrar bozmamalı. İstemciden gelen idempotency-key kullanılmalı.
• Gecikmeye tolerans: Asenkron işleyiş ve zamanla uzlaşma (eventual consistency) kabul edilerek tasarım yapılmalı.
• Denetlenebilirlik ve reconciliation: Audit logları ve otomatik uzlaşma işleri olmalı.

Veri modeli ve SQL Server önerileri

SQL Server üzerinde seri/barkod takibi için basit ama genişletilebilir bir tablo tasarımı şöyle düşünülmeli:

• SerialRegistry tablosu: uniqueidentifier Id, nvarchar(100) SerialNumber (unique), datetime2 CreatedAt, datetime2 LastSeenAt, nvarchar(50) SourceSystem (MES, PLC, Mobile), nvarchar(20) Status (Printed, Assigned, Consumed), rowversion Version. SerialNumber için unique constraint koyun; duplicate oluşumunu uygulama seviyesinde de engelleyin.
• SerialEvents tablosu: eventId, serialId, eventType (Assigned, Printed, Shipped, Updated), payload (json), occurredAt, processed flag. Bu tablo event sourcing veya en azından tam bir audit trail sağlar.
• Index: SerialNumber üzerinde sık sorgu olacak; SourceSystem+Status kombinasyonu da indexlenmeli.

Tekil referans olarak GUID kullanmak genelde faydalıdır; ama insan tarafından okunabilir etiketler için ayrı SerialNumber alanı saklanmalı. Rowversion kullanımı, eşzamanlı güncellemeleri tespit etmek ve optimistic concurrency sağlamak için yararlıdır.

API tasarımı ve ASP.NET Core uygulama notları

API tarafında aşağıdaki pratikleri uygulayın:

• Her yazma işlemi için istemci tarafından bir Idempotency-Key header gönderilmesini isteyin; aynı anahtar tekrar gelirse önceki sonucu döndürün.
• POST /api/serials/assign gibi uç noktalar tek bir işlemde hem event oluşturmalı hem de SerialRegistry'e yazmalıdır. Ancak bu işlemi tek veritabanı içinde yapmıyorsanız (ör. ERP dışında bir WMS de varsa) dağıtık transaction yerine saga pattern veya iki aşamalı onay (acknowledge) kullanın.
• Hatalarda ayrıntılı, yapılandırılmış hata kodu dönün; uygulama tarafı retry mantığını buna göre kurmalı.
• ASP.NET Core içinde IHostedService tabanlı arka plan işçisi (background worker) ile kuyruğu tüketip reconciliation işlemlerini çalıştırın.

Pratik uygulama örnekleri

• İstemci (üretim terminali) bir seri atadığında: API'ye Idempotency-Key ile POST. API, SerialRegistry ve SerialEvents'e yazıp hemen 202 Accepted ve eventId dönebilir. Ardından event bus'a publish edilir.
• Eğer ERP'ye aynı anda kayıt gönderilecekse, bir durum makinesi (state machine) kullanın: Assigned -> ConfirmedInERP -> Consumable gibi state'ler. Her state transition event ile kaydedilir.

Mesajlaşma, kuyruğa alma ve tutarlı entegrasyon

IoT cihazları ve üretim terminali verilerini anlık iletmek için mesajlaşma altyapısı kullanın. Teknik öneriler:

• Azure Service Bus, RabbitMQ veya Kafka tercih edin; ama dead-letter queue ve retry politikasını kesinlikle konfigüre edin.
• Her mesajın içinde correlationId olsun; loglar ve izleme için bu id kullanılmalı.
• Event publish edilince consumer başarılı işleyinceye kadar mesaj kuyruğunda kalmalı; tüketici işleyemediğinde mesaj DLQ'ya düşmeli ve otomatik alarm tetiklenmeli.
• Erken acknowledgement (ack) ile veri kaybı riski artar; önce veri DB'ye başarılı yazıldıktan sonra acknowledge edin.

IoT ve edge cihazları için pratik senaryolar

Üretim hattı cihazları veya el terminalleri için dikkate alınması gerekenler:

• Çevrimdışı çalışma: Cihaz lokal queue (FIFO) tutmalı; bağlantı geri geldiğinde sırayla API'ye gönderim yapmalı. Her kayda lokal unique Id atayın ve Idempotency-Key olarak kullanın.
• Baskı onayı: Etiket yazıcıdan çıktı alınırken uygulama hem yazıcı hem de sistem tarafında bir print confirmed eventi üretmeli. Sadece print edilmiş olan seri ERP'ye gönderilsin.
• Zaman senkronizasyonu: Cihazlarda saat uyumsuzluğu sorun yaratır; cihazlar NTP ile senkronize olmalı veya tüm timestamp'ler sunucu saatine göre atanmalı.

Reconciliation (uzlaşma) süreci: otomatik ve manuel adımlar

Mutlaka otomasyon tabanlı reconciler (uzlaşma işi) kurun. Özellikler:

• Günlük veya saatlik batch job: Seri kayıtları ERP/WMS kayıtlarıyla karşılaştırır; mismatch olanları raporlar.
• Heuristic karşılaştırma: Seri numarası, üretim zamanı, kaynak makina, part no ve miktar eşleştirmeleri yapılır; otomatik eşleşme için eşik kuralları belirlenir.
• Manuel çözüm UI'sı: Operatörlerin karışık durumları elle düzeltmesi için basit bir arayüz (çakışma listesi, önerilen eşleşme, yorum alanı, çözüm onayı) sunun.
• Otomatik ceza/kompanzasyon: Yanlış atanmış bir seri için ters hareket (compensating action) üretin; örneğin yanlış sevkiyatsa sevkiyat iptali ve yeniden rezervasyon gibi.

Operasyonel izleme, loglama ve test senaryoları

Canlı ortamda hatayı hızlı görüp müdahale edebilmek için:

• Her API isteğinde correlationId oluşturun ve bu id'yi cihazların, mesajların ve veri tabanı kayıtlarının hepsinde taşıyın.
• Logları yapılandırılmış (JSON) formatta saklayın; hatalar için alert kuralları oluşturun (ör. 5 dakikada X adet DLQ mesajı).
• Unit/integration testlerine ek olarak network partition senaryolarını, duplicate message scenario'larını ve yüksek concurrency durumlarını test edin.
• Canary/Phased rollout: Yeni etiket formatı veya backend değişikliği önce bir üretim hattında test edilsin; sonra kademeli yaygınlaştırma yapılmalı.

Örnek iş akışı: Sorunlu bir senaryonun adım adım çözümü

Aşağıda, etiket güncellemesi sonrası uyumsuzluk yaşandığında izlenecek adımların örneği vardır:

• 1) Üretim cihazı yeni seri üretti ve yerel queue'ya yazdı; Idempotency-Key atandı.
• 2) Ağ bağlı olduğunda cihaz API'ye POST gönderdi; API SerialRegistry'e yazdı, SerialEvents tablosuna event ekledi ve event bus'a publish etti.
• 3) ERP tüketici servisi olayı alıp kendi kaydını güncelledi. Eğer ERP tarafında hata olursa event DLQ'ya düşer ve retry başlatılır.
• 4) Eğer ERP güncellemesi başarısızsa reconciliation job bu kaydı tespit eder; operatör UI'sinde 'ERP güncellemesi bekleniyor' olarak görünür ve manuel onay veya re-send seçenekleri sunulur.
• 5) Eğer duplicate seri tespit edilirse sistem otomatik önerilen çözümü üretir: yeni seri reassign veya eski kaydı konsolide et. Operatör son karar verir.

Uygulamaya başlarken kontrol listesi (checklist)

• SerialRegistry ve SerialEvents tabloları oluşturuldu mu?
• API için Idempotency-Key ve correlationId uygulanıyor mu?
• Event bus ve DLQ politikanız konfigüre edildi mi?
• Edge cihazlar için offline queue ve print confirmation mekanizması var mı?
• Reconciliation job, manual çözüm UI'sı ve alerting kurulmuş mu?
• Rollout planı, canary testi ve geri alma (rollback) prosedürü hazır mı?

Sonuç ve iletişim

ERP ve üretim hattı arasında güvenilir barkod/seri numarası senkronizasyonu, doğru veri modellemeyi, idempotent API tasarımını, olay tabanlı entegrasyonu ve güçlü bir reconciliation sürecini gerektirir. Yukarıdaki adımlar uygulandığında, birçok yaygın uyumsuzluk ve operasyonel hatanın önüne geçilebilir. Uygulama adımlarında detaylı mimari veya geliştirme desteğine ihtiyaç duyarsanız, teknik tartışma ve proje planlaması için iletişim sayfamızdan bize ulaşabilirsiniz.