MALIO-DEV/SIRH
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 67 Wiki Activity

feat(rtt) : autoriser le paiement RTT rétroactif sur l'exercice précédent

Browse Source 
La RH peut désormais saisir un paiement RTT sur l'exercice immédiatement
précédent (ex. RTT de mai réglés après la bascule du 1er juin), sans casser
le report.

- gate back (assertYearAllowedForPayment) : accepte courant, N-1, ou dernier
  exercice d'une phase clôturée
- après saisie sur N-1, recalcul automatique du report d'ouverture de
  l'exercice courant (computeClosingBalance) dans une transaction → pas de
  double comptage
- refus si le report de l'exercice courant est verrouillé (assertReportNotLocked)
- fallback EmployeeRttSummaryProvider::resolveCarry passe sur
  computeClosingBalance : disponible correct même sans ligne stockée
- front : bouton + Payer les RTT actif sur l'exercice précédent
- docs : CLAUDE.md, doc/rtt-tab.md, documentation-content.ts

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Autin
2026-06-08 13:39:11 +02:00
parent c01e1f89a7
commit cf492f40a4
7 changed files with 139 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/rtt-tab.md
+11 -2
View File
@@ -34,9 +34,18 @@ Comportement :
## Verrouillage des éditions sur exercices passés
Quand `selectedYear !== currentYear` (consultation d'un exercice antérieur), le bouton **+ Payer les RTT** est désactivé. Justification : un paiement rétroactif sur un exercice clos décalerait les soldes courants et le report N-1 calculé.
Quand `selectedYear !== currentYear` (consultation d'un exercice antérieur), le bouton **+ Payer les RTT** est désactivé — **sauf sur l'exercice immédiatement précédent** (`selectedYear === currentYear - 1`), où le paiement rétroactif est autorisé (Option B).
La consultation reste possible, l'édition non.
La consultation des exercices plus anciens reste possible, l'édition non.
### Paiement rétroactif sur l'exercice précédent (Option B)
Un paiement enregistré sur l'exercice N-1 modifie sa clôture, donc le **report d'ouverture de l'exercice courant N**. Pour éviter tout décalage / double comptage :
- garde back `EmployeeRttPaymentProcessor::assertYearAllowedForPayment` : accepte courant, **N-1**, ou dernier exercice d'une phase clôturée ;
- après enregistrement, le processor **recalcule automatiquement** la ligne `employee_rtt_balances` de l'exercice courant via `RttClosingBalanceService::computeClosingBalance(N-1)`, dans une **transaction** (le `flush` du paiement le rend visible au recalcul) ;
- si le report de l'exercice courant est **verrouillé** (`is_locked`), le paiement est **refusé** (`assertReportNotLocked`) : la RH doit déverrouiller d'abord ;
- portée volontairement limitée à N-1 (chaîne de recalcul = 1 étape). Si la ligne courante n'existe pas encore, l'affichage reste correct grâce au fallback de `EmployeeRttSummaryProvider::resolveCarry` (calcul dynamique de la clôture N-1).
## Sélecteur de phase de contrat