SEDDK'nın Yayımladığı ile EGM'nin Doğruladığı Arasındaki Regülasyon Boşluğu

Türkiye'de BES veri pipeline'ı kurmuş herkes bu düzeni bilir: SEDDK regülasyonu yayımlar, EGM gönderimi denetler. Kağıt üzerinde bu, temiz bir sorumluluk ayrımıdır. Pratikte ise bu sektörde gördüğüm en büyük sessiz veri kalitesi hatalarının kaynağıdır.

Çoğu ekibin başlangıçtaki varsayımı şudur: SEDDK genelgesine uyarsanız, EGM dosyanızı kabul eder. Bu varsayım yanlıştır ve bunu keşfetmenin bedeli reddedilen batch'ler, manuel düzeltmeler ve kimsenin imzalamak istemediği mutabakat raporlarıyla ölçülür.

İki Çerçevenin Ayrıştığı Noktalar

SEDDK kuralları yayımlar — alan tanımları, hesaplama metodolojileri, katkı eşikleri, devlet katkısı hak kazanma kriterleri, aktarım prosedürleri. EGM ise XML gönderimlerinizi fiilen kabul veya reddeden doğrulama katmanını uygular. Bu iki katman arasında tekrar eden üç boşluk yer alır:

• Yürürlük tarihi uyuşmazlıkları. Bir SEDDK genelgesi belirtilen tarihte yürürlüğe girer. EGM'nin doğrulayıcısı ise yeni kuralı günler, haftalar, hatta bazen aylar sonra uygulamaya alabilir. Bu pencere boyunca, yeni regülasyona teknik olarak uygun dosyalar reddedilir; eski kurala göre hazırlananlar geçer.
• Yorum farklılıkları. SEDDK metin yazar. EGM şema yazar. Metin belirsiz olduğunda — ki kısmi yıl devlet katkısı hesaplamaları veya dönem ortası plan değişiklikleri gibi sınır durumlarda çoğu zaman öyledir — EGM bir yorumu seçer ve kodlar. O yorum, her zaman hukuk ekibinizin okuduğu yorum olmaz.
• Belgelenmemiş toleranslar. EGM doğrulayıcısının hiçbir yerde yazılmayan sessiz toleransları vardır: kesinti hesaplamalarındaki yuvarlama davranışları, toplu mutabakattaki kabul edilebilir delta eşikleri, yayımlanmış spesifikasyondan farklı alan uzunluğu tuhaflıkları.

Somut Bir Örnek

Birkaç yıl önce devlet katkısı hak kazanma kurallarında bir değişiklik geldi. SEDDK genelgesi yeni hesaplama konusunda netti. Pipeline'ı güncelledik, kendi mantığımıza karşı regresyon testleri çalıştırdık, her şey tutuyordu.

EGM batch'i reddetti. Sebep: doğrulayıcıları belirli bir katılımcı segmentine hâlâ önceki ayın hak kazanma penceresini uyguluyordu — muhtemelen kendi taraflarında kademeli bir devreye alma vardı. İki seçeneğimiz vardı: mantığımızı geri alıp SEDDK ile uyumsuz olmak ya da batch'i tutup gönderim son tarihini kaçırmak.

Sonunda üçüncü bir seçenekte karar kıldık ve bu seçenek zamanla mimariye dönüştü: bugün EGM'nin uyguladığı yoruma göre gönder, sapmayı logla ve SEDDK'ya göre doğru değeri daha sonra mutabakat için bir gölge alanda taşı.

Regülasyon Otoritesini Versiyonlanmış Bir Girdi Olarak Ele Almak

Bu tür olayların yeterince yaşanmasından sonra, kanamayı durduran tek mimari, "regülasyonu" tek bir kaynak olarak ele almayı bırakan mimaridir. İki otoriteyi, her birinin kendi yürürlük zaman çizelgesiyle modellemeniz gerekir:

• seddk_rule_version — regülasyonun ne dediği, X tarihinden itibaren yürürlükte
• egm_validator_version — doğrulayıcının fiilen ne uyguladığı, Y tarihinden itibaren yürürlükte (genellikle belgelenmiş değil, ampirik olarak gözlemlenir)

Pipeline'daki her hesaplanmış alan her ikisiyle de etiketlenir. Ayrıştıklarında pipeline iki değer üretir: gönderim değeri (EGM tarafından kabul edilen) ve uyum değeri (SEDDK'ya göre doğru olan). Mutabakat uyum değerine karşı yapılır. Gönderim ise kabul edilen değerle olur.

Bu, SEDDK'nın gönderdiğiniz rakamların neden mevcut regülasyonla eşleşmediğini sorduğu ilk denetime kadar aşırı mühendislik gibi görünür; o denetimde doğrulayıcının o tarihte doğru değeri reddettiğini kanıtlayan zaman damgalı bir kaydı gösterebilirsiniz.

Pratikte Bu Nasıl Görünür

Hak ettiği yeri kazanmış birkaç mimari kural:

• Regülasyon tarihini asla hardcode etmeyin. Her eşik, her oran, her hak kazanma penceresi; yürürlük tarihi ve otoriteye göre anahtarlanmış bir tabloda tutulur. İki otorite, iki sütun.
• Her doğrulayıcı reddini tam payload ile loglayın. Özet değil — payload'ın kendisi. Altı ay sonra EGM bir kuralın her zaman öyle uygulandığını iddia ettiğinde, elinizde makbuz olması gerekir.
• Bir sapma dashboard'u kurun. Her gönderim döngüsü için, kaç kaydın EGM için bir şekilde ve SEDDK uyum raporlaması için başka bir şekilde hesaplandığını gösterin. Bu sayı zamanla sıfıra yaklaşmalıdır. Sıçradığında, upstream'de bir şey değişmiştir ve kimse size söylememiştir.
• XSD varsayımlarınızı versiyonlayın. EGM'nin şemaları evrilir. Eskilerini saklayın. Bir denetim için iki yıl önceki bir gönderimi yeniden üretmek opsiyonel değildir ve mevcut şema geçmiş dosyayı doğrulamaz.
• Uyum modelini gönderim modelinden ayırın. Bunlar iki farklı şeydir. Bunları karıştırmak, regülasyon her değiştiğinde pipeline'ın baştan yazılmasına yol açan şeydir.

Rahatsız Edici Kısım

Rahatsız edici gerçek şu: iki otoriteli bir rejimde "doğru" tek bir değer değildir. Çoğu zaman birbiriyle uyuşan bir değer çiftidir. Tek bir gerçek varsayımı üzerine kurulmuş pipeline'lar kırılmaya devam eder ve bu kırılma, aslında mimari bir sorun olduğu halde her seferinde bir veri kalitesi sorunu gibi görünür.

Yangın söndürmeyi bırakan ekipler, bunu kabul edip buna göre tasarım yapanlardır. Regülasyon otoritesi bir sabit değildir. Zamana bağlı, versiyonlanmış bir girdidir — ve bir kez böyle ele aldığınızda, BES pipeline'larındaki tekrar eden acıların çoğu tekrar etmeyi bırakır.