Muayene Verisi ERP ve Muhasebeye Çift Kayıt Olmadan Nasıl Aktarılır?

Kısa cevap: çift kayıt nasıl önlenir?

Her muayene işine değişmeyen bir kaynak kimliği verin; ERP aktarımını bu kimlikle idempotent çalıştırın, veritabanında tekilliği zorlayın ve yalnız doğrulanmış hedef belgeyi muhasebeye bağlayın.

Bir entegrasyonun yalnız normal akışta çalışması yeterli değildir. Ağ yanıtı kaybolduğunda, kuyruk mesajı tekrar geldiğinde veya iki worker aynı işi aldığında da sonuç tek müşteri, tek sipariş ve tek faturalama bağlantısı olmalıdır.

Çift kayıt neden oluşur?

Kısa cevap: çoğu çift kayıt, kullanıcı iki kez düğmeye bastığı için değil; ilk isteğin başarılı olup yanıtının kaybolduğu belirsiz anda yapılan kontrolsüz retry nedeniyle oluşur.

Muayene sistemi ERP'ye sipariş açma isteği gönderir. ERP kaydı oluşturur, fakat bağlantı kapanır ve entegrasyon yanıtı alamaz. Worker aynı isteği yeni bir işlem gibi tekrar gönderirse ikinci sipariş açılabilir. Benzer risk kuyrukta en az bir kez teslim, paralel worker, zaman aşımı sonrası manuel tekrar ve toplu senkronizasyonda görülür.

IETF RFC 9110, idempotent işlemi aynı isteğin birden çok uygulanmasının amaçlanan etkisinin tek uygulamayla aynı olması olarak tanımlar. PUT bu niteliğe sahiptir; POST ile yeni kaynak oluşturma ise ayrıca korunmalıdır. Teknik tasarım, ağın tam olarak bir kez teslim yapacağını varsaymamalıdır.

Hangi kimlik kaydın sahibi olmalı?

Muayene işi, ERP siparişi, muhasebe fişi ve e-belge aynı kimlik değildir. Zincirin başlangıcında değişmeyen bir kaynak iş UUID'si bulunmalı; diğer sistemlerin ürettiği kimlikler bunun karşılığı olarak ayrı alanlarda saklanmalıdır.

OASIS UBL 2.4 Invoice, fatura ile sipariş ve diğer belgeler arasında referans alanları tanımlar. GİB e-Fatura Portalı kılavuzu da aynı UUID ve fatura numarasına sahip faturaların tekrar yüklenemeyeceğini belirtir. Buradan çıkan uygulama sonucu, kaynak muayene kimliğini e-belge numarasıyla değiştirmek değil; kimlikleri çift yönlü bir bağ tablosunda ayrı tutmaktır.

Idempotency key nasıl üretilmeli?

Anahtar rastgele her retry'da yeniden üretilmemeli; aynı ticari etkinin bütün denemelerinde aynı kalmalıdır. Örnek kapsam şu parçaların kanonik birleşiminden türetilebilir:

tenant + hedef_sistem + işlem_türü + kaynak_iş_uuid + kaynak_sürümü

Kaynak sürümü önemlidir. Aynı rapor sürümünü tekrar göndermek mevcut sonucu döndürmelidir; yetkili revizyon yeni bir ticari etki yaratacaksa bunun ayrı olay ve açık iş kuralı olması gerekir. İdempotency kaydı anahtarın yanında payload özetini, ilk görülme zamanını, durumu ve hedef yanıt kimliğini tutmalıdır.

Stripe'ın güncel API referansı, bağlantı hatasından sonra create/update isteğinin aynı idempotency key ile güvenle tekrarlanmasını ve anahtar aynıyken parametreler değişmişse isteğin reddedilmesini belgeler. Bu sağlayıcıya özgü davranış, kurum içi ERP adaptörü için de yararlı bir sözleşme örneğidir: aynı anahtar farklı müşteri, tutar veya vergi eşlemesiyle gelirse sessizce üzerine yazmayın; çakışmayı incelemeye alın.

Uygulama kontrolü neden tek başına yetmez?

“Önce var mı diye sorgula, yoksa ekle” yaklaşımında iki worker aynı anda yok sonucunu görebilir. Tekillik veritabanında da zorlanmalıdır.

Entegrasyon bağlantı tablosunda tenant_id + target_system + document_type + source_job_uuid üzerinde bileşik unique constraint kurun. PostgreSQL'in güncel INSERT dokümantasyonu, unique constraint ile ON CONFLICT kullanımının yarış altında atomik insert/update sonucu sağlayabildiğini açıklar. İş kuralınız güncellemeye izin vermiyorsa çatışmada mevcut hedef ID'sini döndürün; veri farklıysa fail-closed inceleme kaydı açın.

UNIQUE (tenant_id, target_system, document_type, source_job_uuid)

aynı anahtar + aynı payload özeti  -> mevcut sonucu döndür
aynı anahtar + farklı payload       -> çakışma, otomatik belge açma

Outbox ve kuyruk akışı nasıl kurulmalı?

Muayene raporunu “faturalamaya hazır” yapmak ile ERP mesajını ayrı ayrı yazmak yarım durum üretebilir. İş durumu ve entegrasyon olayı aynı yerel transaction içinde commit edilmelidir.

1. Yetkili kullanıcı rapor sürümünü ve faturalama kapsamını onaylar.
2. Uygulama aynı transaction içinde iş durumunu günceller ve olay UUID'siyle outbox satırı ekler.
3. Worker outbox olayını hedef adaptöre sabit idempotency key ile gönderir.
4. Başarılı yanıtta ERP hedef ID'si ve yanıt özeti bağ tablosuna kaydedilir.
5. ACK kaybolursa aynı olay yeniden gelir; tüketici olay UUID'sini ve iş bağını görüp mevcut sonucu döndürür.
6. Kalıcı veri hatası retry döngüsüne sokulmaz; inceleme/dead-letter kuyruğuna alınır.

Microsoft'un Transactional Outbox rehberi, business object ile olayın aynı transaction içinde saklanmasını; Service Bus rehberi ise kayıp ACK ve yeniden teslim nedeniyle tüketicinin MessageId veya ticari kimlikle idempotent olmasını önerir. Gönderici tarafındaki duplicate detection, alıcıdaki tekillik kontrolünün yerine geçmez.

Müşteri, hizmet ve vergi eşlemesi nasıl güvenli yapılır?

Çift kaydı önlemek yalnız teknik retry sorunu değildir. Aynı müşteriyi unvan yazımıyla yeniden açmak veya aynı hizmeti farklı kodla faturalamak da operasyonel çoğalma üretir.

• Müşteri: tenant kapsamında doğrulanmış VKN/TCKN veya kurum ana anahtarıyla eşleyin; unvanı tek başına anahtar yapmayın.
• Hizmet: muayene yöntemini onaylı ERP stok/hizmet kodu tablosuna bağlayın; eşleşmeyen kodu serbest metinle otomatik açmayın.
• Vergi ve para birimi: hedef sistemin kod listesine sürümlü eşleme uygulayın; eksik veya geçersiz eşlemede belge üretimini durdurun.
• Tutar: hesaplanan satırları, indirimleri ve vergiyi kaynak sürüm özetiyle kilitleyin; onay sonrası değişikliği yeni revizyon akışına alın.
• Yetki: müşteri oluşturma, eşleme değiştirme ve finansal belge üretme rollerini ayrı denetim izleriyle yönetin.

Belirsiz eşleşme “en yakın sonucu” seçmemelidir. İnsan incelemesi tamamlanana kadar aktarım beklemeli; verilen kararın kim, zaman, önceki/yeni değer ve gerekçesi kaydedilmelidir.

Aktarım durumu nasıl izlenmeli?

Tek bir “başarılı/başarısız” alanı belirsizliği saklar. Durum makinesi, hangi adımın tekrar edilebilir olduğunu göstermelidir.

Başarılı aktarım kaydını silip yeniden göndermek düzeltme yöntemi değildir. Finansal belge oluşmuşsa iptal, iade veya ters kayıt kendi kimliği ve onay akışıyla yürütülmelidir.

Mutabakat hangi kontrolleri yapmalı?

Günlük mutabakat, yalnız hata logunu saymak yerine kaynak ve hedef kayıtlarını kimlik düzeyinde karşılaştırmalıdır.

• Faturalamaya hazır olup hedef bağlantısı bulunmayan işler.
• Aynı kaynak iş UUID'sine bağlanmış birden fazla hedef belge.
• Hedefte bulunan fakat kaynak bağ tablosunda karşılığı olmayan belgeler.
• Kaynak sürümü ile gönderilen payload özeti uyuşmayan kayıtlar.
• Belirsiz durumda tanımlı süreden uzun kalan denemeler.
• Manuel eşleme, iptal ve ters kayıtların onay/kanıt eksikleri.

Mutabakat sonucu otomatik silme veya toplu birleştirme yapmamalıdır. Şüpheli kayıtları, iki sistemdeki kimlikleri ve önerilen güvenli işlemi yetkili kullanıcıya göstermelidir.

VizyonTech entegrasyonu nasıl pilotlanmalı?

Vizyon Periyodik gibi muayene akışlarından ERP'ye geçişte normal senaryodan önce hata senaryolarını deneyin. Aynı iş için çift tıklama, ERP'nin kaydı oluşturup yanıt vermemesi, aynı kuyruk mesajının iki worker'a ulaşması, farklı payload ile aynı anahtar, geçersiz müşteri eşlemesi ve rapor revizyonu test edilmelidir.

Pilotun başarı ölçütü “entegrasyon çalıştı” değildir. Her senaryoda hedefte kaç kayıt oluştuğu, kaynak-hedef bağının kurulup kurulmadığı, retry'ın aynı sonucu döndürdüğü, belirsizliğin görünür kaldığı ve yetkisiz finansal işlemin engellendiği kanıtlanmalıdır. Muayene raporunun karar zincirini korumak için e-imza iş akışı rehberi de birlikte değerlendirilebilir.