← Geri

2026-09-06

Askıya Alınmış Hesap Sorunu: Neden Yasal Tedbir Altındaki BES Katılımcıları, Pipeline'ınızın Taşımak Üzere Hiç Tasarlanmadığı Bir Raporlama Durumu Yaratır

Türkiye'deki her emeklilik operasyon ekibi bu talebi en az bir kez görmüştür: bir mahkeme, bir katılımcının BES hesabına bloke koyar, hukuktan biri tebligatı operasyona iletir ve katılımcı ana kaydına bir bayrak konur. İki hafta sonra HAYMER doğrulaması başarısız olur, devlet katkısı dosyası EGM tarafından reddedilir veya daha kötüsü — katılımcının NAV'ı bir ay boyunca sessizce yanlış hesaplanır ve bir mutabakat sorumlusu nokta kontrolü yapana kadar kimse fark etmez.

Nedeni neredeyse her zaman aynıdır. Tedbir, hesabın dahil olduğu her aşağı akış sürecine yayılması gereken zamansal olarak kapsamlı bir kısıt olarak değil, hesap üzerinde bir boolean olarak modellenmiştir.

Hukuki durum ve operasyonel durum birinci günde ayrışır

Bir BES hesabındaki haciz veya ihtiyati tedbir, emeklilik mekanizmasını durdurmaz. Bordro sistemleri katkı göndermeye devam eder. Fon günlük olarak değerlenmeye devam eder. Devlet katkısı tahakkuku, uygun katkı tutarlarına göre hesaplanmaya devam eder. EGM hâlâ günlük katılımcı anlık görüntüsünün ve aylık HAYMER gönderiminin mutabık kalmasını bekler.

Tedbirin gerçekte yaptığı şey dardır: katılımcının belirli hakları kullanmasını engeller — tipik olarak çıkış, aktarım, kısmi çekim ve bazen fon dağılım değişiklikleri. Katkı girişini engellemez. NAV dağıtımını duraklatmaz. Hesabı emeklilik evreninden çıkarmaz.

Dolayısıyla birinci günden itibaren paralel çalışan iki durumunuz olur:

Çoğu pipeline bunları karıştırır. Katılımcı kaydındaki tek bir is_suspended bayrağı, altı farklı iş tarafından okunur ve her biri onu biraz farklı yorumlar.

Bayrak tabanlı model nerede kırılır

Somut bir vakayı ele alalım. Katılımcı X'in ayın 12'sinde açılmış aktif bir tedbiri var. Ayın katkıları 15'inde geliyor (bordro döngüsü). Devlet katkısı uygunluğu ay sonunda hesaplanıyor. HAYMER dosyası izleyen ayın 5'inde çıkıyor.

Eğer NAV dağıtım işiniz is_suspended = true okuyup katılımcıyı atlarsa, yasal olarak dağıtılması gereken bir katkı için pay dağıtmamış olursunuz. Para, pay karşılığı olmadan bir askı hesabında durur. Ertesi günün NAV toplamı tutmaz.

Eğer devlet katkısı işiniz aynı bayrağı okuyup katılımcıyı hariç tutarsa, katılımcının hak ettiği bir devlet katkısını alıkoymuş olursunuz — tedbir çekimi kısıtlar, tahakkuku değil.

Eğer HAYMER extract'iniz bayrağı okuyup hesabı pasif veya hariç olarak işaretlerse, EGM dosyayı reddeder çünkü dün aktifken ve bakiyeli iken bugün geçerli bir durum geçiş kodu olmadan ortadan kaybolmuştur.

Her iş kendi başına makul davranıyor. Birlikte tutarsız bir katılımcı kaydı üretiyorlar.

Zamansal kapsamlama, eksik olan ilkel yapıdır

Tedbir, hesabın bir özelliği değildir. Şu bileşenlere sahip bir olaydır:

Bunu bir olay tablosu olarak modellemek — tedbir başına bir satır, başlangıç, bitiş ve kapsam ile — ve doğru zamansal filtre ile her pipeline aşamasına join etmek egzotik değildir. Bu, fon dağılım geçmişi veya katkı oranı değişiklikleri için zaten kullandığınız kalıbın aynısıdır. Sorun şudur ki yasal kısıtlamalar neredeyse her zaman sisteme manuel bir operasyonel kanaldan girer, onlara ilk dokunan kişi tarafından bir bayrağa düzleştirilir ve herhangi bir kod onları görmeden önce zamansal ve kapsam boyutlarını kaybederler.

Pipeline'ın aslında yapması gereken

Her pipeline aşaması için soru "bu hesap askıya alınmış mı?" değildir. "Bu operasyonun yürürlük tarihinde, aktif tedbir kapsamı bu spesifik eylemi yasaklıyor mu?" sorusudur.

Somut olarak:

Mutabakat tuzağı

Bu sorunun en kötü versiyonu aylar sonra mutabakat sırasında ortaya çıkar. Tedbir altındaki bir hesap katkıları ve payları doğru şekilde biriktirir, ancak aşağı akış bir rapor — genellikle bir iş kullanıcısı tarafından ad hoc bir araçta oluşturulmuş — "askıya alınmış" hesapları filtreler. Yönetim panosu AUM'u eksik hesaplar. Aktüeryal extract yükümlülükleri kaçırır. Yıl sonuna kadar kimse fark etmez.

Çözüm her filtreyi avlamak değildir. Çözüm, tek bir askıya alınmış boolean'ı hiç dışa açmamaktır. Kapsamıyla birlikte tedbir olay tablosunu dışa açın ve her tüketiciyi gerçekten önemsediği spesifik soruyu sormaya zorlayın. Bir rapor yazarı where not exists (select 1 from account_restriction where scope includes 'reporting_exclusion') yazmak zorunda kalırsa, hariç tutmaması gereken hesapları hariç tutmadan önce iki kez düşünecektir.

Sınırı nereye koymalı

Uygulamada bunu dayatmanın en temiz yeri, bireysel işlerde değil, operasyon yetkilendirme katmanındadır. Her katılımcı kaynaklı operasyon, doğru kapsam filtresi ile aktif tedbirlere danışan tek bir kontrolden geçer. NAV, katkı ve raporlama işleri tedbir verisine hiç bakmaz — tam aktif katılımcı kümesi üzerinde çalışırlar ve tedbir yalnızca birileri mahkemenin yasakladığı bir şeyi yapmaya çalıştığında yüzeye çıkar.

Bu, yaygın tasarımı tersine çevirir. Her işin "bu hesabı atlayayım mı?" diye sorması yerine, yalnızca gerçekten engellenebilecek operasyonlar "devam etmeye izinli miyim?" diye sorar. Diğer her şey, tedbir yokmuş gibi çalışır — çünkü operasyonel olarak, o süreçler için, yoktur.

Askıya alınmış hesap filtrelenmesi gereken özel bir durum değildir. Dar bir yasaklı eylemler kümesine sahip normal bir hesaptır. Pipeline'ı bu şekilde kurun; HAYMER redleri durur, NAV tutar ve mutabakat sorumlusu Mart ayında sürprizler bulmayı bırakır.