1.9 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| feedback_adjustsimul | Règles complètes pour adjustSimulForActuals — capital effectif, capital soldé, reprocess |
|
adjustSimulForActuals dans backend/src/utils/schedule.js est le point central déclenché après chaque remboursement. Trois règles à toujours respecter :
1. Capital effectif = initial + réinvestissements
Why: Après l'ajout des réinvestissements (mai 2026), la projection s'affichait correctement après un réinvestissement, mais dès qu'un remboursement était saisi, adjustSimulForActuals recalculait sur montant_investi seul, effaçant l'impact.
How to apply: À chaque nouvelle fonctionnalité modifiant le capital réel (réinvestissement, abondement…), vérifier et adapter :
adjustSimulForActualsdansschedule.jssyncInvestissementStatutdansremboursements.js- Le bouton ↺ (recalcul manuel) dans
simul.js
2. Capital soldé (remainingCapital <= 0)
Why: Sans correction, l'échéance courante gardait capital_prevu = 0 pour les prêts in fine, et des lignes à 0,00 € restaient dans le tableau au lieu d'être supprimées.
How to apply: Quand remainingCapital <= 0 :
- L'échéance courante (date_prevue <= last_date) reçoit
capital_prevu = capitalAtLastDate - Les échéances futures (date_prevue > last_date) sont supprimées (DELETE), pas mises à zéro
3. Route /reprocess doit appeler adjustSimulForActuals
Why: Sans cet appel, recalculer les champs fiscaux en masse ne mettait pas à jour les échéanciers.
How to apply: La route POST /api/remboursements/reprocess doit sélectionner r.investissement_id, collecter les IDs dans un Set pendant la transaction, puis itérer avec adjustSimulForActuals(db, invId) après le transaction()().