[#SIRH-32] Ajouter l'exercice 2026/2027 dans les congés/RTT (#20)
Auto Tag Develop / tag (push) Successful in 9s
Auto Tag Develop / tag (push) Successful in 9s
| Numéro du ticket | Titre du ticket | |------------------|-----------------| | | | ## Description de la PR ## Modification du .env ## Check list - [x] Pas de régression - [x] TU/TI/TF rédigée - [x] TU/TI/TF OK - [ ] CHANGELOG modifié Reviewed-on: #20 Co-authored-by: tristan <tristan@yuno.malio.fr> Co-committed-by: tristan <tristan@yuno.malio.fr>
This commit was merged in pull request #20.
This commit is contained in:
+13
-5
@@ -68,7 +68,8 @@ Etat implementation:
|
||||
- la table est creee
|
||||
- le calcul de synthese conges lit en priorite `opening_days/opening_saturdays` de cette table quand une ligne existe pour `(employee, rule_code, year)`
|
||||
- si aucune ligne n'existe, le calcul reste base sur le report dynamique N-1
|
||||
- la commande `app:leave:rollover` calcule aussi le report dynamique N-1 si la ligne N-1 n'est pas encore persistée (pas de reset a 0 par defaut)
|
||||
- **le report dynamique (`LeaveBalanceComputationService::computeDynamicClosingForYear`, qui alimente le solde d'ouverture de l'exercice suivant) ancre lui aussi sur cette table** : pour chaque exercice de sa boucle, si une ligne bootstrap existe il part de `opening_days/opening_saturdays` (et ajoute l'offset `taken_days/taken_saturdays`) au lieu de recalculer depuis l'embauche. Sans cet ancrage, la clôture d'un exercice consulté en avance (ex. exercice suivant) cumulerait une année pleine d'acquisition par exercice antérieur à la mise en service — aucune absence historique n'étant saisie (cas Aurore : 88 jours au lieu de 31).
|
||||
- la commande `app:leave:rollover` recalcule **toujours** le report via `computeDynamicClosingForYear(N-1)` (et ne se fie plus au `closing_days` stocké, qui n'est qu'un placeholder = `opening`), puis fige ce résultat dans le `closing_days` de l'exercice qui se termine ; voir § 6
|
||||
|
||||
### Definition des colonnes
|
||||
|
||||
@@ -120,12 +121,19 @@ Date d'effet:
|
||||
- non forfait: au `1er juin`
|
||||
|
||||
Traitement par employe:
|
||||
1. lire l'exercice precedent
|
||||
2. determiner le report:
|
||||
1. determiner le report de l'exercice precedent:
|
||||
- si cloture `paidLeaveSettled=true` sur la periode precedente => report `0`
|
||||
- sinon report = `closing` exercice precedent
|
||||
- sinon report = **cloture reelle recalculee** via `computeDynamicClosingForYear(exercicePrecedent)` (acquisition + samedis + fractionnes − pris, ancree sur l'`opening_days` bootstrap de chaque exercice). On **ne se fie PAS** au `closing_days` stocke : il n'est jamais recalcule apres creation (toujours egal a l'`opening`), donc s'y fier propagerait l'ouverture sans jamais crediter l'acquisition de l'annee (cas Aurore : report 0 au lieu de 31).
|
||||
2. **figer** ce report dans `closing_days/closing_saturdays` de la ligne de l'exercice qui se termine (la colonne contient enfin un vrai solde de cloture, auditable).
|
||||
3. creer la ligne du nouvel exercice avec ce report en `opening_*`
|
||||
4. initialiser `accrued/taken/closing` pour le nouvel exercice
|
||||
4. initialiser `accrued/taken/closing` pour le nouvel exercice (= `opening` a la creation)
|
||||
|
||||
### Correction manuelle d'un solde (RH / comptable)
|
||||
|
||||
Le verrouillage (`is_locked`) n'est pas utilise ; les corrections se font directement en BDD. Deux garde-fous rendent cela sur :
|
||||
|
||||
- **Idempotence** : le cron ne cree la ligne d'un exercice que si elle n'existe pas (les lignes existantes sont ignorees). Une ligne corrigee a la main n'est donc **jamais** ecrasee par un passage ulterieur du cron (meme avec `--force`).
|
||||
- **Le bon levier est `opening_days`, pas `closing_days`** : `computeDynamicClosingForYear` part de l'`opening_days` de chaque exercice comme ancre. Corriger l'`opening_days` d'un exercice (ou la donnee de fond : absence, fractionne, paye) se propage automatiquement aux reports des exercices suivants. Editer un `closing_days` d'un exercice **pas encore bascule** est inutile (il sera recalcule a la bascule) ; une fois la ligne suivante creee, plus rien n'y touche.
|
||||
|
||||
## 7) Donnees a fournir au go-live
|
||||
|
||||
|
||||
+16
-5
@@ -24,12 +24,12 @@ Cette règle suit `EmployeeLeaveSummaryProvider::resolveYear()` côté backend :
|
||||
Position : **en bas du calendrier**, à gauche, à l'intérieur de la zone scrollable. Il scrolle donc avec les mois et apparaît sous la grille.
|
||||
|
||||
Plage proposée :
|
||||
- du plus récent (= année courante) au plus ancien ;
|
||||
- du plus récent au plus ancien. La borne haute est l'exercice **suivant** (exercice courant + 1) lorsque la phase de contrat est ouverte, afin de consulter en avance les congés posés sur l'exercice à venir ; pour une phase clôturée, la borne haute reste l'exercice de fin de phase ;
|
||||
- **double plancher** : l'année minimum est `max(floor_historique_contrat, floor_data_start_date)`
|
||||
- **floor_historique_contrat** : dérivé de `employee.contractHistory[].startDate` — premier exercice où l'employé avait un contrat ouvert
|
||||
- **floor_data_start_date** : dérivé de l'env `RTT_START_DATE` (date de mise en service du logiciel, ex. `2026-02-23` → exercice 2026 / année forfait 2026). Aucune donnée historique n'existe avant cette date, donc on ne propose pas d'années antérieures même si le contrat de l'employé est plus ancien.
|
||||
- la valeur est exposée par l'API `GET /employees/{id}/leave-summary` via le champ `dataStartDate` (peuplé depuis l'env serveur).
|
||||
- en cas d'historique manquant **et** d'env absente, la plage se réduit à l'année courante.
|
||||
- en cas d'historique manquant **et** d'env absente, la plage se réduit à l'exercice courant et à l'exercice suivant.
|
||||
|
||||
Format des libellés :
|
||||
- FORFAIT : `2026`, `2025`, `2024`…
|
||||
@@ -39,13 +39,24 @@ Comportement :
|
||||
- changer d'année recharge l'intégralité de l'onglet (`getEmployeeLeaveSummary?year=YYYY` + `listAbsences` + `listPublicHolidays`) ;
|
||||
- les compteurs du bandeau reflètent l'année sélectionnée.
|
||||
|
||||
## Verrouillage des éditions sur années passées
|
||||
## Compteurs du bandeau
|
||||
|
||||
Quand `selectedYear !== currentYear` (consultation d'une année antérieure) :
|
||||
- **Acquis** : jours de report N-1 + jours acquis sur l'exercice courant.
|
||||
- **Pris** : jours de congés posés et validés sur l'exercice.
|
||||
- **Reste** : acquis − pris.
|
||||
- **En cours d'acquisition** (non-forfait) : affiché au format `net / brut`.
|
||||
- `net` (`accruingDays`) : généré de l'exercice restant, déduit des congés posés en anticipé (au-delà du report acquis).
|
||||
- `brut` (`accruingDaysTotal` = `generatedDays + generatedSaturdays`) : total généré sur l'exercice à ce jour, avant cette déduction.
|
||||
- La RH voit ainsi le total réellement acquis même si une partie a déjà été consommée en anticipé. Forfait : pas d'en-cours (affiche `0`, sans fraction).
|
||||
- **N-1** (non-forfait) ou **Samedis** (FORFAIT) : solde de l'exercice précédent / jours de repos samedis.
|
||||
|
||||
## Verrouillage des éditions hors exercice courant
|
||||
|
||||
Quand `selectedYear !== currentYear` (consultation d'une année **différente de l'exercice courant**, passée ou future) :
|
||||
- le bouton crayon **Jours fractionnés** (non-FORFAIT) est désactivé ;
|
||||
- le bouton crayon **Année N-1 payés** (FORFAIT) est désactivé.
|
||||
|
||||
Justification : modifier rétroactivement les stocks de report ou les jours fractionnés d'un exercice clos décalerait silencieusement les soldes de toutes les années postérieures. La consultation reste possible, l'édition non.
|
||||
Justification : modifier les stocks de report ou les jours fractionnés d'un exercice clos décalerait silencieusement les soldes des années postérieures ; les éditer sur un exercice futur (pas encore démarré) n'aurait pas de sens. La consultation reste possible, l'édition non.
|
||||
|
||||
## Sélecteur de phase de contrat
|
||||
|
||||
|
||||
+2
-2
@@ -21,7 +21,7 @@ Toujours **Juin (Y-1) → Mai (Y)**. Le champ `EmployeeRttSummary.year` correspo
|
||||
Position : sous la table, à l'intérieur de la zone scrollable, à gauche.
|
||||
|
||||
Plage proposée :
|
||||
- du plus récent (= exercice courant) au plus ancien ;
|
||||
- du plus récent (= exercice courant) au plus ancien. Contrairement à l'onglet Congés, le RTT **ne propose pas** l'exercice suivant (consulter un exercice RTT à venir n'a pas de sens) ; pour une phase clôturée, la borne haute reste l'exercice de fin de phase ;
|
||||
- **double plancher** : `max(floor_historique_contrat, floor_data_start_date)`
|
||||
- **floor_historique_contrat** : dérivé de `employee.contractHistory[].startDate` — premier exercice où l'employé avait un contrat ouvert
|
||||
- **floor_data_start_date** : exercice contenant `RTT_START_DATE` (env, ex. `2026-02-23` → exercice 2026)
|
||||
@@ -32,7 +32,7 @@ Comportement :
|
||||
- changer d'exercice recharge `getEmployeeRttSummary?year=YYYY` (le backend valide 2000–2100) ;
|
||||
- la table redéploie les semaines de l'exercice sélectionné, navigation par mois conservée.
|
||||
|
||||
## Verrouillage des édition sur exercices passés
|
||||
## 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é.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user