Son on yılda devraldığım veya denetlediğim her BES pipeline'ında bir yerlerde saklı olan aynı mimari kusur vardır: prim tatilleri hiçbir şey olarak modellenir. Satır yok. Katkı olayı yok. Son başarılı tahsilat ile bir sonraki arasında bir boşluk. Kibana dashboard'unda temiz görünür. Ay sonu mutabakat raporunda ise fon pay bakiyenizin EGM ile tutmamasının sebebidir.
Bu, tüm katkı yaşam döngüsündeki en yanlış anlaşılan tek durumdur ve hakkında kimsenin yazmadığı durumdur.
Prim Tatili Aslında Nedir
BES mevzuatı gereği, katkıları askıya alan bir katılımcı — ister gönüllü olarak, ister işveren tarafındaki bordro duraklatması yoluyla, ister direkt borçlandırma N ardışık döngü boyunca başarısız olduğu için — sözleşmeden çıkmaz. Poliçe hukuken aktif kalır. Bu da şu anlama gelir:
- Fon payları tahsisli kalmaya ve piyasa hareketine maruz kalmaya devam eder
- Devlet katkısı hak ediş saati, vesting eşiklerine (3, 6, 10 yıl) doğru işlemeye devam eder
- Sistemde kalış süresi, emeklilik hakkı için birikmeye devam eder
- Fon işletim gider kesintisi katılımcının bakiyesinden düşülmeye devam eder
- EGM günlük raporlaması hâlâ poliçenin aktif portföy anlık görüntüsünde görünmesini gerektirir
- İşveren destekli varyant (İşveren Grup BES) çalışmaya devam eden kendi vesting takvimine sahiptir
Prim tatili, katkının yokluğu değildir. Belirli bir alt durumdaki bir sözleşmenin varlığıdır. Bunlar mimari olarak farklı şeylerdir.
Pipeline'lar Bunu Neden Yanlış Yapar
Çoğu katkı pipeline'ı, birincil olgunun tahsilat olayı olduğu bir event-sourced model üzerine kuruludur: hesaba bir borçlandırma düştü, fonlar tahsis edildi, o günkü pay fiyatıyla paylar satın alındı. Olay olmadığında satır olmaz. Pipeline, katılımcı hakkında en son olaya bakarak ve durumu çıkararak akıl yürütür.
Bu, mutlu-yol tahsilatları için gayet iyi çalışır. Şu tür sorular sorduğunuz anda dağılır:
- Dünkü kapanış itibarıyla kaç katılımcı prim tatilinde?
- Askıya alınmış ancak aktif poliçelerin toplam AUM maruziyeti nedir?
- Bu hafta hangi askıya alınmış poliçeler bir devlet katkısı vesting eşiğini geçti?
- EGM günlük dosyası için, bu döngüde sıfır katkıyla aktif olarak raporlanması gereken hangi poliçelerdir?
Tek gerçek kaynağınız tahsilat olay akışıysa, bu soruların hiçbirinin temiz bir cevabı yoktur. Sonunda, pipeline'da first-class bir olgu olması gereken durumu yeniden inşa etmek için poliçe master'ına karşı giderek daha barok LEFT JOIN'ler yazan aşağı akış ekiplerine sahip olursunuz.
Kimsenin Konuşmadığı Mutabakat Hataları
Birden fazla kez şahsen debug ettiğim hata modları şunlardır:
Fon payı sapması. Askıya alınmış poliçelerin hâlâ payları vardır. Bu paylar günlük olarak yeniden değerlenir. Pipeline, askıya alınmış bir poliçeyi "pasif" olarak muamele edip günlük değerleme işinden düşürürse, portföy yönetim şirketine karşı fon NAV mutabakatı tam olarak askıya alınmış bakiyelerin toplamı kadar sapar. Bu sonunda yakalanır — genellikle sizin tarafınızdan değil, fon tarafından — ve düzeltme her zaman geriye dönüktür.
Devlet katkısı hesaplama hatası. Sekiz ay prim tatilinde olan, ardından tekrar katkı yapan bir katılımcı, katkı yaptığı aylara değil toplam sistemde kalış süresine göre bir vesting eşiğini geçer. Pipeline'ınız hak edişi katkı olaylarının toplamından hesaplıyorsa, hak edişi eksik raporlarsınız. Hazine mutabakatı bunu işaretleyecektir. Düzeltmek aylarca durumun backfill edilmesini gerektirir.
EGM günlük dosya boşlukları. EGM, günlük anlık görüntüde her aktif poliçeyi bekler. Yalnızca yakın zamanda aktivitesi olan poliçeleri yayan bir pipeline, askıya alınanları sessizce düşürecektir. EGM eşleşmeme raporunu gönderene kadar fark etmezsiniz ve o zamana kadar bir veri konuşması değil, bir uyum konuşması yaparsınız.
Kesinti birikimi. Fon işletim gider kesintisi askıya alınmış bakiyelerde devam eder. Kesinti işi aktif poliçe durumu yerine yakın katkıları anahtar olarak kullanıyorsa, askıya alınmış katılımcılardan kesinti alınmaz. Sonunda biri fark ettiğinde, binlerce poliçede toplu geriye dönük bir düzeltme borçlusunuz demektir ve bu düzeltmelerin her birinin katılımcıya açıklanması gerekir.
Doğru Mimari
Düzeltme kavramsal olarak karmaşık değildir. Sadece prim tatili, olana kadar bir edge case gibi hissettirdiği için nadiren uygulanır.
Katılımcının katkı durumunu, olay varlığından türettiğiniz bir şey olarak değil — first-class, sürekli değerli bir boyut olarak modelleyin. Somut olarak:
- Bir katkı olayı gerçekleşip gerçekleşmediğine bakılmaksızın, her aktif poliçe için günlük (veya en azından değişimde) bir durum kaydı yayınlayın
- Durum kaydı alt statüyü taşır:
contributing,premium_holiday_voluntary,premium_holiday_failed_debit,employer_suspended, vb. - Fon maruziyeti, vesting saatleri ve raporlama yükümlülükleri, katkı olay akışından değil, durum kaydından anahtar alır
- Katkı olay akışı olduğu gibi kalır: finansal olarak gerçekten olan şeylerin bir kaydı
Bu esasen bir olay günlüğü ile yavaş değişen bir boyut arasındaki farktır. Her ikisinin de var olması gerekir. Yalnızca birincisini koruyan pipeline'lar, aynı bug sınıfını sonsuza kadar keşfetmeye devam edecektir.
Neden Tartışılmadan Kalıyor
Prim tatili hataları gürültülü kesintiler olarak ortaya çıkmaz. Ay sonu mutabakat farkları olarak birinin manuel olarak yamaladığı, altı ay sonra bir Hazine sorgusu olarak veya olmayana kadar bir yuvarlama toleransına absorbe edilen bir fon NAV varyansı olarak ortaya çıkarlar. Her bireysel hata küçüktür ve açıklanabilir. Pattern yalnızca aynı ticket şeklini üç veya dört kez görecek kadar pipeline'ı yeterince uzun süre sahiplendiyseniz görünür hale gelir.
Bu yüzden açıkça söyleyeceğim: Bir BES katkı pipeline'ı inşa ediyor veya denetliyorsanız ve tek bir sorguda şu anda hangi poliçelerin prim tatilinde olduğunu ve toplam fon maruziyetlerinin ne olduğunu cevaplayamıyorsanız, pipeline'ınızda bu bug var. Sadece henüz kimsenin düzeltmeyi önceliklendirmesine yetecek kadar size pahalıya patlamadı.