Özel Entegratör Kesintisinde E-Belge İş Sürekliliği Planı Nasıl Kurulur?

Zaman aşımı “gönderilmedi” demek değildir
Özel entegratör veya ağ bağlantısı kesildiğinde en riskli refleks aynı belgeyi yeniden üretmektir. İstek zaman aşımına uğramış olsa bile dosya entegratöre ya da GİB akışına ulaşmış olabilir. Sonuç belirsizliği, kesin hata veya kesin başarıdan ayrı durum olarak yönetilmelidir.
İş sürekliliği planı; kesintinin fark edilmesi, kuyruğun korunması, tekil belge kimliklerinin sabitlenmesi, sağlayıcıyla iletişim, alternatif işlemin yetkili onayı ve dönüş sonrası mutabakatı kapsar. Resmî kesinti duyuruları ile belge düzenleme yöntemleri olay anında güncel kaynaktan kontrol edilir.
Olay: sabah toplu faturaları
Bir dağıtım şirketi sabah yüzlerce faturayı kuyruklar. Entegratör ilk bölümden sonra cevap vermeyi bırakır. Uygulama istekleri otomatik tekrarlar; kullanıcı da başarısız görünenleri elle yeniden gönderir. Hizmet döndüğünde bazı faturalar üç farklı zarf kaydıyla görünür.
Kontrollü sistem tekrar denemesini aynı idempotency/korelasyon kimliğiyle sınırlar. Her faturanın UUID’si ve ilk istek zamanı saklanır. Belirsiz kayıtlar yeni belge üretimine kapatılır. Sağlayıcıdan kesin durum sorgulanır. Dönüşte kaynak belge sayısı, benzersiz UUID, gönderim zarfı ve nihai sonuç birlikte uzlaştırılır.
Kesinti sınıflandırması
Önce sorunun kapsamı anlaşılır:
Yalnız tek kullanıcının cihazı mı etkileniyor?
Şirket ağı veya DNS erişiminde sorun var mı?
Entegratör API’si genel olarak mı cevap vermiyor?
GİB tarafında duyurulmuş çalışma var mı?
İmza/mali mühür hatası bağlantı kesintisi gibi mi görünüyor?
Kuyruk işliyor fakat durum sorgusu mu aksıyor?
Belgelerin bir kısmında veri hatası mı var?
Yanlış sınıflandırma, gereksiz sağlayıcı değişikliği veya toplu yeniden gönderim doğurabilir. Ham hata kodu, zaman ve korelasyon kimliği korunur.
Olay komuta planı
Teknik sorumlu bağlantı ve kuyruk durumunu, finans sorumlusu etkilenen belgelerin ticari riskini, operasyon birimi teslim veya hizmet akışını izler. Olay yöneticisi kararları kaydeder. Mali müşavir, kesintide uygulanabilecek belge yöntemini ve süre etkisini güncel düzenlemeyle değerlendirir.
Müşteri iletişiminde “faturanız kesin gönderildi” ya da “hiç oluşmadı” gibi doğrulanmamış ifadeler kullanılmaz. Durum belirsizse açıkça belirtilir ve sonraki kontrol zamanı paylaşılır.
Yeniden deneme politikası
Teknik tekrarlar artan aralık, üst sınır ve tekil işlem korumasıyla yapılır. Aynı çağrının cevabı kaybolduğunda yeni UUID veya fatura numarası üretilmez. Tekrar sonucu da ham olay olarak kaydedilir.
Üst sınır aşıldığında kayıt insan incelemesine gider. Kullanıcı “zorla başarılı” yapamaz. Manuel gönderim gerekiyorsa ilk kuyruğun devre dışı kaldığı ve mükerrerlik kontrolünün yapıldığı onaylanır.
Alternatif yöntem
Alternatif portal veya başka süreç, her kesintide otomatik devreye sokulmaz. İşletmenin yetkisi, belge türü, seri yönetimi, arşiv ve mükerrerlik riski incelenir. Alternatifte oluşturulan her kayıt ana işlem envanterine geri bağlanır. Kesinti bittiğinde iki sistemin kuyrukları aynı anda çalıştırılmaz.
Önceden hazırlanmış prosedür masa başı tatbikatla sınanır. Portal erişimi, sertifika, yedek kullanıcı ve dışa aktarılacak veri gerçekten kullanılabilir mi görülür.
Normale dönüş
Sağlayıcı hizmeti “çalışıyor” dediğinde olay hemen kapanmaz. Kesinti aralığındaki bütün belgeler şu kümelere ayrılır: nihai başarılı, nihai hatalı, hâlâ belirsiz, mükerrer aday ve alternatif yolla işlenen. Adet ve tutar toplamları kaynak satış listesiyle karşılaştırılır.
Mükerrer adaylar otomatik silinmez. Belge durumları ve güncel düzeltme yolu mali müşavirle incelenir. Kök neden, etki, çözüm ve önleyici aksiyon olay raporuna yazılır.
Timeout olunca belge gönderilmemiş midir?
Hayır. Kesin sonuç UUID ve sağlayıcı/GİB kaydıyla sorgulanmalıdır.
Başka entegratöre hemen geçilebilir mi?
Yetki, yöntem, seri ve arşiv koşulları planlanmadan geçiş yeni mükerrerlik riski yaratır.
Kesinti planı ne sıklıkla test edilmeli?
İşlem hacmi ve risk düzeyine göre düzenli tatbikat yapılmalı; bulunan eksikler kapanana kadar izlenmelidir.
Veri bütünlüğü ve güvenlik olayı ayrımı
Kesinti her zaman kapasite sorunu değildir. Kimlik doğrulama hatası, süresi dolmuş sertifika, değiştirilmiş API anahtarı veya yetkisiz erişim de benzer belirti gösterebilir. Ekip, hizmeti hızla açmak için güvenlik kontrolünü devre dışı bırakmamalıdır. Beklenmeyen anahtar veya sertifika değişikliği güvenlik olayına yönlendirilir.
Ham loglar kişisel veya mali veri içerebilir. Destek talebine yalnız gerekli teknik alanlar eklenir; üretim anahtarı, tam belge içeriği veya müşteri listesi güvensiz kanalda paylaşılmaz.
Sağlayıcı sözleşmesi ve taşınabilirlik
Hizmet seviyesi, olay bildirimi, veri dışa aktarma, arşiv erişimi ve sözleşme sonu koşulları önceden okunmalıdır. Alternatif sağlayıcı fikri ancak gerçek veri taşıma ve yetki testiyle anlam kazanır. Yılda belirlenen aralıkta örnek XML, görüntü, durum ve yanıt dosyalarının indirilebildiği sınanır.
Kesinti raporu sağlayıcının açıklamasıyla kapanmaz. Şirket kuyruğu, müşteri etkisi, mükerrer adaylar ve muhasebe sonuçları kendi kaynaklarında doğrulanır. Önleyici aksiyon tamamlandığında yeni tatbikatla etkinliği ölçülür.
Açık aksiyonlar kapanana kadar olay yönetim gündeminde kalmalıdır.
Müşteri destek talepleri aynı olay numarası altında toplanır; birbirinden kopuk manuel yanıtlar yerine doğrulanmış durum, sonraki kontrol zamanı ve sorumlu ekip paylaşılır.
Bu içerik genel iş sürekliliği rehberidir. Kesinti anındaki resmî yöntem ve süreleri GİB kaynaklarıyla kontrol edin; mali müşavir ve sağlayıcınızla koordineli hareket edin.
Kaynaklar
Mehmet Hakkı Yuvanç
FiscusAI ekibi


