Çoğu mühendis veri düzeltmeyi aynı şekilde öğrenir: hatalı satırı bul, UPDATE yaz, logla, devam et. Bir e-ticaret sipariş tablosunda, CRM iletişim listesinde, hatta core dışındaki çoğu bankacılık defterinde bu kabul edilebilir bir uygulamadır. Audit izi neyin olduğunu yakalar, düzeltilmiş değer aşağı akar, iş devam eder.
Bu refleks sizi bireysel emeklilikte yok eder.
Türk BES (Bireysel Emeklilik Sistemi) fonundaki bir katılımcı kaydı satır değildir. Hukuki bir enstrümandır. Katılımcının kimlik alanları, katkı planı, fon dağılım tercihleri, giriş tarihi ve sözleşme statüsü; devletin, düzenleyicinin (EGM) ve katılımcının kendisinin yasal hak talebinde bulunduğu hesaplamaların girdileridir. Bir düzeltme önceki durumu silmez — orijinaliyle birlikte yaşaması gereken, kaynaklı ve zaman damgalı yeni bir olay yaratır, çünkü orijinali zaten aşağı akışta hukuki sonuçlar doğurmuştur.
Bir Düzeltme Gerçekte Neyi Tetikler
Rutin bir durumu düşünün: bir katılımcının giriş tarihi 5 Mart yerine 15 Mart olarak kaydedilmiş. On gün. Bir CRM'de bu gürültüdür. BES'te bu tek düzeltme şu zincirleme etkileri yaratabilir:
- Geriye dönük devlet katkısı yeniden hesaplaması. %25'lik devlet katkısı belirli pencereler içinde yapılan katkılar üzerinden hesaplanır. Giriş tarihini kaydırmak, sözleşme başlangıcına kadar geriye giderek hangi katkıların ve hangi oranda hak kazandığını değiştirebilir.
- Hak ediş saati ayarlaması. Devlet katkısı hak edişi, sistemdeki yıl sayısına dayalı kademeli bir plana göre işler. On günlük bir kayma, katılımcıyı üç yıl önce gerçekleşmiş bir hak ediş sınırının ötesine taşıyabilir.
- EGM mutabakat farkı. EGM günlük katılımcı dosyaları alır. Düzeltilmiş kaydınız artık önceki her EGM snapshot'ı ile çelişiyor. Bu farkın açıklanması gerekir, sessizce yutulamaz.
- Fon payı yeniden hesaplaması. Katkı tarihleri kayarsa, katkıların dönüştürüldüğü birim fiyatları da kayar. Şimdi birim bakiyelerini geriye dönük olarak yeniden hesaplıyorsunuz, bu da yeniden işleme tamamlanana kadar katılımcının mevcut bakiyesinin yanlış olduğu anlamına geliyor.
- Vergi raporlama etkileri. Çıkış vergilendirmesi sistemde geçirilen süreye bağlıdır. Giriş tarihini düzeltmek, geçmişte yapılan kısmi çıkışlara uygulanan vergi dilimini değiştirir.
Tek alan. On gün. Yanlış ele alınırsa aylarca süren aşağı akış işi.
Üzerine Yazmak Neden Yanlış Modeldir
Alanı UPDATE edip pipeline'ı yeniden çalıştırma içgüdüsü, önceki durumun hiç gerçek olmadığını varsayar. Emeklilikte önceki durum son derece gerçekti. Devlet ona dayanarak sübvansiyon ödedi. EGM onu kabul etti. Katılımcı ona atıfta bulunan ekstreler almış olabilir. Vergi onun üzerinden hesaplanmış olabilir.
Üzerine yazarsanız, bir düzenleyicinin sorusuna cevap veremeyen bir sistem yaratmış olursunuz: 12 Haziran 2022'de neye inanıyordunuz ve bu sübvansiyonu hangi temele dayanarak ödediniz? "Şimdi inandığımıza inanıyorduk" cevabı kabul edilebilir değildir. Aynı zamanda doğru da değildir.
Doğru model en azından bitemporal olmalıdır:
- Geçerlilik zamanı (Valid time): olgunun gerçek dünyada doğru olduğu zaman (katılımcı gerçekten 5 Mart'ta girdi).
- Sistem zamanı (System time): sisteminizin buna inanmaya başladığı zaman (düzeltme 18 Kasım'da uygulandı).
Aşağı akıştaki her hesaplama, hesaplamanın orijinal olarak gerçekleştirildiği andaki inanç durumuna karşı yeniden üretilebilir olmalıdır. Nisan'daki sübvansiyon ödemeniz, o zaman bildiklerinize göre doğruydu. Kasım'daki düzeltmeniz, yeni bir hesaplamayı tetikleyen yeni bir olaydır ve ikisi arasındaki fark mutabakat kalemidir — sessiz bir yeniden yazma değil.
Kaynaklı Bir Olay Olarak Düzeltme
Kurduğum ve bakımını yaptığım sistemlerde her düzeltme şunları taşır:
- Kaynak belge referansı. Giriş tarihinin yanlış olduğunu bize kim söyledi? İmzalı form aracılığıyla katılımcı mı? Audit'te yakalanan bir şube giriş hatası mı? Sözleşmeli işverenle bir mutabakat farkı mı? Her kaynağın farklı hukuki ağırlığı ve farklı aşağı akış bildirim yükümlülüğü vardır.
- Yetkilendirme izi. Hukuki bağlayıcılığı olan alanlardaki düzeltmeler, script çalıştıran bir geliştirici tarafından yapılamaz. Operasyonel yetkilendirme, çoğunlukla çift kontrol ve bazı durumlarda düzenleyiciye dönük gerekçelendirme gerektirir.
- Yürürlük tarihi ve bilgi tarihi. Bunlar aynı şey değildir. Sözleşme başlangıcından yürürlüğe giren, bugün itibarıyla bilinen bir düzeltme; bugünden ileriye yürürlüğe giren bir düzeltmeden farklı aşağı akış dosyaları üretir.
- Aşağı akış etki manifestosu. Düzeltme commit edilmeden önce sistem, hangi yeniden hesaplamaları tetiklediğini sıralamalıdır: sübvansiyon farkları, EGM dosya yeniden üretimleri, ekstre yeniden basımları, vergi düzeltmeleri. Etki sıralanamıyorsa, düzeltme commit edilmeye hazır değildir.
Bunun Pipeline Tasarımı İçin Anlamı
Genel veri geçmişinden gelen mühendisler katılımcıyı yavaşça değişen bir boyut (slowly changing dimension) olarak modellemek ve işin bittiğini söylemek isterler. SCD Type 2 geçmişi yakalar ama niyeti yakalamaz. Size satırın değiştiğini söyler; neden, kimin yetkisiyle, hangi kanıta karşı, hangi hukuki etkiyle değiştiğini söylemez.
BES'teki katılımcı kaydının event-sourced bir omurgaya ihtiyacı var. Mevcut durum bir projeksiyondur. Gerçek olaylar dizisidir — sözleşme başlangıcı, alınan katkı, değişen dağılım, güncellenen iletişim, düzeltilen giriş tarihi, eklenen lehtar — her biri değişmez, her biri kaynaklı, her biri yeniden oynatılabilir. EGM Nisan 2022 sübvansiyonunun neden 851 değil 847 lira olduğunu sorduğunda, Nisan 2022'yi o zaman var olduğu haliyle olay logu üzerinde yeniden oynatırsınız. Bu sayı birebir yeniden üretilir. Kasım düzeltmesi, kendi sübvansiyon farkı olan, kendi işlemi olarak ödenen ya da geri alınan ayrı bir olaydır.
Bunu inşa etmek daha pahalıdır. Aynı zamanda bir düzenleyici ziyaretinden, bir denetimden ya da bir katılımcı davasından sağ çıkan tek modeldir.
Pratik Test
Emeklilik veri platformunuzun doğru kurulup kurulmadığını bilmek istiyorsanız tek bir soru sorun: katılımcının tam kaydını geçmişteki herhangi bir tarihte inanıldığı haliyle üretebilir ve ondan üretilen her sübvansiyonu, fon payı hesaplamasını ve EGM dosyasını yeniden üretebilir misiniz?
Cevap backup restore'larını, manuel yeniden yapılandırmayı ya da "muhtemelen yaklaşabiliriz"i gerektiriyorsa, platform düzeltmeleri tamir sanan biri tarafından kurulmuştur. Onlar tamir değildir. Olaydırlar. Ve emeklilikte olayların sessiz kalma hakkı yoktur.