← Geri

2026-06-24

Transfer-In Problemi: Bir Katılımcının Geçmişini Başka Bir Emeklilik Şirketinden Getirmek Neden BES'teki En Zor Veri Operasyonudur

Bir emeklilik şirketinin içinde çalışmamış pek çok mühendis, BES'teki en zor operasyonun günlük NAV hesaplaması ya da belki devlet katkısı mutabakatı olduğunu varsayar. Yanılıyorlar. En zor operasyon, rakip bir şirketten ayrılıp size yıllarca birikmiş bakiye, katkı geçmişi, hak ediş süreleri ve sizin oluşturmadığınız, gerçek zamanlı olarak doğrulayamayacağınız vergi pozisyonlarıyla gelen bir katılımcıyı kabul etmektir.

Bir transfer-in dosyası pipeline'ınıza düştüğünde, bir kayıt almıyorsunuz. Bir iddia alıyorsunuz. Önceki şirket şunu öne sürüyor: bu kişi Y ay boyunca X lira ödedi, Z lira devlet katkısı kazandı, şu tarihten beri sistemde ve şu kadarı hak edilmiş durumda. EGM nihayetinde bu rakamları doğrulayacak ya da çürütecek — ama "nihayetinde", pipeline'ınızın karar vermek zorunda olduğu an değildir.

Kör Uçtuğunuz Pencere

Transfer dosyasının geldiği an ile EGM mutabakatının tamamlandığı an arasında, sisteminiz birkaç geri alınamaz karar vermek zorundadır:

Bunların hiçbiri müzakere edilebilir değil. Katılımcı ertesi sabah giriş yapıp bir bakiye görmeyi bekliyor. Operasyon sözleşmenin aktif olmasını bekliyor. Mevzuat her kuruşun hesabının verilmiş olmasını bekliyor. Ve siz tüm bunları, yazarı sizinkinden tamamen farklı şema varsayımlarına sahip bir payload üzerinde gerçekleştiriyorsunuz.

Gelen Dosyanın Sessizce Varsaydıkları

Arızalar asıl burada yaşıyor. Transfer dosya formatı kağıt üzerinde standartlaştırılmıştır. Pratikte her şirket kendi operasyonel geçmişini alanlara kodlar.

Prodüksiyonu bozarken bizzat şahit olduğum birkaç örnek:

Bunların hiçbiri transfer dosyasındaki bug'lar değil. Bunlar, ikisi de EGM şartnamelerine tam uyumlu iki emeklilik şirketinin aynı yasal gerçekliği aynı şekilde kodladığı varsayımındaki bug'lar.

EGM Mutabakatı Sizin Güvenlik Ağınız Değildir

İçgüdü şöyle demektir: rahat olun, EGM mutabakat yapacak ve her tutarsızlık yüzeye çıkacak. Bu doğru ama işe yaramaz. EGM mutabakatı size rakamların eşleşmediğini söyler. Hangi tarafın haklı olduğunu söylemez ve siz çözmeye çalışırken katılımcının deneyimini dondurmaz.

EGM bir devlet katkısı uyumsuzluğunu işaretlediğinde, siz çoktan pay ihraç etmiş, çoktan ücret kesmiş, katılımcıya çoktan bir bakiye göstermiş ve muhtemelen çoktan kısmi bir çıkış talebini işlemiş olursunuz. Bunlardan herhangi birini geri sarmak manuel operasyon işi, katılımcıya yazılı açıklama ve bazı durumlarda kendi aşağı akış mutabakat problemini yaratan bir düzeltme bildirimi gerektirir.

Doğru zihinsel model şudur: EGM nihai gerçek kaynağıdır ve sizin pipeline'ınız bu boşluktan sağ çıkacak kadar savunmacı olmak zorundadır.

Gerçekten İşe Yarayan Şeyler

Bu ingestion yüzeyinin sorumluluğunu birden fazla prodüksiyon döngüsünde üstlendikten sonra, ayakta kalan kalıplar göz alıcı değil:

Altta Yatan Ders

Transfer-in problemi, bildiğim en net örnektir: emeklilik veri işinin neden bir CRUD problemi olmadığı. Siz kayıt tutmuyorsunuz. Farklı operasyonel geçmişlere sahip taraflarca öne sürülen iddialardan derlenen ve nihayetinde doğruyu hükme bağlayacak bir düzenleyiciye karşı, bir kişinin emekliliği hakkında yasal bir pozisyon koruyorsunuz.

Ayakta kalan pipeline'lar, yazarlarının ingestion kodunun ilk satırından itibaren bir gerçekler sistemi değil, tartışmalı iddialar sistemi yazdıklarını anlamış olduğu pipeline'lardır. Bozulanlar ise bir CSV görüp sütunların dokümantasyonda söylendiği anlama geldiğini varsayan mühendisler tarafından yazılanlardır.

Neredeyse hiçbir zaman öyle değildirler.