E-Fatura Durum Kodları Nasıl Okunur? Operasyon Ekibi İçin İzleme Rehberi
Bir kod, bütün faturanın sonucu değildir
E-fatura entegrasyonunda kullanıcı “durum 12xx’te kaldı” dediğinde önce hangi nesnenin durumundan söz edildiği anlaşılmalıdır. Kod zarfın GİB merkezindeki teknik işlenmesini, alıcı posta kutusuna iletimini veya sistem yanıtını anlatabilir. Ticari faturaya ilişkin kabul-ret kararı ise ayrı uygulama yanıtıdır. Bu katmanları tek satırda birleştirmek hatalı yeniden gönderime ve mükerrer faturaya yol açar.
GİB entegrasyon kılavuzu gönderici birim, merkez ve posta kutusu arasındaki zarf ve yanıt akışını tanımlar. Operasyon ekibi kodları ezberlemek yerine güncel kılavuz sürümü, sağlayıcının ham açıklaması ve olay sırasını birlikte okumalıdır. Kod anlamı veya önerilen aksiyon doküman değiştikçe gözden geçirilmelidir.
İzlenecek nesneleri ayırmak
Bir gönderimde en az dört kayıt vardır: fatura XML’i, faturayı taşıyan zarf, zarf için oluşan sistem yanıtları ve varsa ticari uygulama yanıtı. Sağlayıcı ayrıca kendi iş kimliğini üretir. Kullanıcı ekranında bunların hepsi “fatura durumu” diye gösterilirse hangi katmanın beklediği anlaşılamaz.
Teknik izleme tablosu şu alanları ayrı tutabilir:
Fatura ETTN’si ve belge numarası
Zarf kimliği ve zarf oluşturma zamanı
Ham GİB durum kodu ve açıklaması
Kodun alındığı kaynak ve sorgu zamanı
Önceki kod, geçiş zamanı ve deneme sayısı
Sistem yanıtı kimliği
Sağlayıcı işlem referansı
İç sınıflandırma ve sorumlu ekip
Sonraki izinli aksiyon
Kılavuz veya eşleme tablosu sürümü
Ham kod saklanmadan yalnız “başarılı” etiketi tutmak, daha sonra olayın nedenini araştırmayı engeller.
Geçici, kesin ve belirsiz sınıflar
İç eşleme, kodları “işlem sürüyor”, “başarı doğrulandı”, “teknik hata”, “alıcı kaynaklı hata” ve “inceleme gerekli” gibi operasyon sınıflarına ayırabilir. Ancak bu sınıflar GİB’in resmî anlamının yerine geçmez. Her sınıfın hangi ham kodlardan üretildiği ve ne zaman güncellendiği görülebilmelidir.
Geçici durum için hemen yeni zarf hazırlamak doğru olmayabilir. Kesin hata için de aynı faturayı değişiklik yapmadan tekrar göndermek her zaman uygun değildir. Aksiyon; hatanın türü, zarfın ulaştığı aşama ve güncel teknik yönlendirme doğrulandıktan sonra seçilir.
Örnek senaryo: bakım sırasında bekleyen zarf
Şirket cuma akşamı on e-fatura gönderir. Sağlayıcı ilk isteklere işlem kimliği verir, fakat GİB durum sorgusu uzun süre ara kod döndürür. Bir çalışan faturaları başarısız sanıp yeni ETTN’lerle tekrar göndermek ister.
İzleme kaydı, ilk zarfların merkez tarafından alınmış olabileceğini gösterdiği için yeniden gönderimi durdurur. Sağlayıcının resmî olay bildirimi ve GİB duyuruları kontrol edilir. Aynı zarf kimlikleriyle sorgu sürdürülür; yanıt geldikçe durum geçmişine eklenir. Başarı kesinleşenler yeniden üretilmez. Hata alanların ise ham yanıtı teknik ekipçe incelenir. Böylece geçici görünürlük problemi mali belge çoğalmasına dönüşmez.
Geçişlerin doğrulanması
Durum kodu tek başına değil, izinli geçişle birlikte kontrol edilir. Örneğin “oluşturuldu” kaydından doğrudan “alıcıda işlendi” durumuna atlayan olayda aradaki mesajlar eksik olabilir. Bu her zaman usulsüzlük değildir; sağlayıcı toplu sonuç bildirmiş olabilir. Yine de kaynak ve zaman damgası doğrulanır.
Aynı kodun saatlerce tekrarlanması yeni olay sayılmaz; son görülme zamanı güncellenebilir. Kod geriye gidiyorsa veya daha önce kesin sayılan durum farklılaşıyorsa kayıt üzerine yazılmaz. Düzeltme olayı açılır ve sağlayıcıdan açıklama istenir.
Yeniden gönderim kapısı
Yeniden gönderme, finansal etkisi olan bir karardır. Sistem şu sorular yanıtlanmadan düğmeyi etkinleştirmeyebilir: İlk zarf merkezde mi? Aynı ETTN yeniden kullanılabilir mi? Hata belge içeriğinde mi, pakette mi, alıcı etiketinde mi? Güncel kılavuz hangi aksiyonu öngörüyor? Yeni belge gerekiyorsa önceki kayıtla bağlantı nasıl kurulacak?
Otomatik retry yalnız teknik olarak güvenli ve idempotent çağrılarda sınırlandırılır. Her deneme aynı iş kimliğiyle izlenir. Yeni fatura üretmek retry olarak adlandırılmaz.
Alarm tasarımı
Bütün bekleyen kayıtları kırmızı göstermek ekipte alarm yorgunluğu yaratır. Uyarı; durumun beklenen süresini aşması, kritik vade, yüksek tutar, kodun kesin hata sınıfına girmesi veya izin verilmeyen geçiş gibi ölçütlerle önceliklendirilebilir. Süre eşikleri sağlayıcının gerçek hizmet davranışıyla test edilir; hukuki süre yerine geçmez.
Bakım duyurusu varsa alarm kapatılmamalı, “bilinen olayla ilişkili” etiketi almalıdır. Duyuru bittiğinde açık kayıtların toplu mutabakatı yapılır.
Hata ve istisna noktaları
Kod sözlüğünün farklı entegratörlerde aynı olduğu varsayılmamalıdır; sağlayıcı kendi ara durumlarını ekleyebilir. Açıklama metninden sayısal kod türetmek, dil veya yazım değişikliğinde bozulur. Zarf içindeki belgelerden biri sorunlu olduğunda bütün faturaları aynı ticari sonuçta göstermek de yanıltıcıdır.
Gelen faturada teknik başarı, satın alma onayı değildir. Giden faturada teknik hata görülmesi satışın hiç oluşmadığını kanıtlamaz. Muhasebe ve vergi sonucu mali müşavir tarafından somut kayıtlarla değerlendirilir.
Operasyon kontrol listesi
İzlenen kimlik fatura mı, zarf mı, yanıt mı?
Ham kod ve ham açıklama değişmeden saklandı mı?
Kodun kaynağı ve sorgu zamanı belli mi?
İç durum eşlemesinin sürümü kayıtlı mı?
Önceki durumlar görünür mü?
Ara durum için yanlış yeniden gönderim engelleniyor mu?
Kesin hata aksiyonu güncel kılavuza dayanıyor mu?
Sağlayıcı bakım duyurusu olayla bağlandı mı?
Mükerrer ETTN ve belge numarası tarandı mı?
Teknik sonuç ile ticari kabul ayrı gösteriliyor mu?
Kısa SSS
Tek bir “başarılı” durumu yeterli mi?
Hayır. En azından zarfın teknik sonucu ile faturanın ticari ve muhasebesel durumu ayrılmalıdır.
Kod uzun süre değişmezse fatura yeniden gönderilmeli mi?
Önce aynı zarf ve işlem kimliği sorgulanmalıdır. Sonuç belirsizken yeni belge üretmek mükerrerlik riski taşır.
Sağlayıcının açıklaması GİB kodundan farklıysa hangisi saklanır?
İkisi de kaynaklarıyla saklanabilir. İç aksiyon, güncel resmî anlam ve sağlayıcının teknik sözleşmesi doğrulanarak seçilir.
Sonuç
Durum kodu izleme, renkli etiket üretme işi değildir. Nesne kimliği, ham mesaj, geçiş geçmişi ve izinli aksiyon birlikte tutulduğunda ekip yeniden gönderim riskini yönetebilir. Sistem belirsizliği gizlememeli; mali sonuç yalnız teknik kanıtlar tamamlandıktan ve yetkili kişi inceledikten sonra güncellenmelidir.
Kaynaklar
Mehmet Hakkı Yuvanç
FiscusAI ekibi
