# Rapport v1.6.2 — Avril n'était pas payé L'exploitant a corrigé le modèle du prêt Forsa sur trois points, et il avait raison sur les trois. Le fait qui commande tout : l'échéance d'avril 2026 n'était pas remboursée — l'appariement chronologique automatique l'avait marquée réglée en y affectant un versement qui appartenait à un autre mois. La leçon, gravée dans le code : **l'affectation d'un versement à une échéance est une décision de l'exploitant, pas une déduction du logiciel.** **Recette** : 829 tests, 4 159 assertions, tout au vert (823 avant le lot). `./vendor/bin/pint` passé, `npm run build` relancé. Deux migrations (schéma + rattrapage), une commande de reprise remplacée, aucune dépendance ajoutée. --- ## 1. La logique des 950 DH a disparu Le modèle portait `mensualite_totale = 950`, `part_capital = 938`, `part_frais = 12`, comme si chaque échéance était un « 938 + 12 » par construction. C'était faux : **l'échéance du prêt est 938 DH, point.** Les frais bancaires existent mais varient — ce ne sont pas 12 DH par construction, et ils ne font pas partie de l'échéance. Ce sont des opérations ordinaires de « Frais & commissions bancaires », saisies pour leur montant réel quand elles se présentent. - La mensualité et la part de frais sont retirées du modèle, des colonnes en base (`loan_schedules` ne porte plus qu'une colonne `echeance`, `loan_installments` un seul `montant_prevu`) et de tous les écrans. - L'échéancier affiche 96 × 938 DH — la dernière échéance au reliquat de 890 DH, 90 000 n'étant pas un multiple de 938. - Plus jamais l'application ne découpe un montant en « 938 + frais ». Les lignes de frais de 12 DH déjà au journal restent : elles correspondent à la grille de l'époque et ont été validées. - Le formulaire de remboursement propose 938 par défaut, modifiable ; un montant différent s'enregistre tel quel et la ligne de l'échéancier affiche l'écart — « 950,00 DH (écart +12,00 DH) » — sans le corriger d'office. - Un test parcourt tout `app/` et `resources/views/`, commentaires exclus : aucun code ne référence plus 950 ni une part de frais fixe. ## 2. L'affectation se choisit à la saisie — jamais en silence C'est le cœur du lot. Partout où un remboursement Forsa se saisit, un sélecteur « Échéance réglée » liste les échéances impayées — « n° 15 — avril 2026, en retard de 4 mois » — et l'enregistrement l'exige : - dans **« Nouvelle opération »** (le formulaire du journal comme l'action rapide), le champ se révèle dès que la catégorie « Remboursement Forsa » est choisie, obligatoire ; - sur la **page du prêt** (point 3). Le pré-choix est intelligent mais jamais silencieux : l'échéance du même mois que la date de l'opération si elle est impayée, sinon la plus ancienne impayée — et le choix reste entièrement libre, car il arrive qu'on règle un vieux mois longtemps après. Les règles d'intégrité sont en base, pas seulement à l'écran : une opération ne règle qu'une seule échéance (contrainte d'unicité sur `loan_installments.transaction_id`), une échéance n'est réglée que par une opération. Supprimer l'opération — corbeille comme effacement — rouvre l'échéance à l'instant ; la requalifier en une autre catégorie aussi. ## 3. La page du prêt est un poste de travail Elle ne faisait qu'afficher. Désormais : - **« Enregistrer un remboursement »** en tête de page : une fenêtre — date, compte de trésorerie, montant pré-rempli à 938, échéance réglée — qui crée l'opération au journal et solde l'échéance choisie, en un geste. C'est le pendant de « Encaisser une échéance » côté clients. - Sur chaque ligne de l'échéancier, l'état dit tout : **réglée** (date de règlement cliquable vers l'opération au journal, écart affiché s'il y en a un), **en retard** (à J+1, comme partout), **à venir**. Et deux actions : « Régler cette échéance » (la même fenêtre, échéance pré-choisie) et, sur une ligne réglée, « Détacher » — qui rouvre l'échéance et libère l'opération, pour corriger une affectation fausse sans toucher au journal. - Les indicateurs de tête ne comptent que les échéances réellement réglées : n réglées / 96, capital restant = 90 000 − 938 × n, prochaine échéance impayée — la plus ancienne, avec son retard. - Les versements qui ne règlent aucune échéance restent listés en tête, jamais absorbés : c'est là que l'exploitant arbitre. ## 4. L'existant remis en face de la réalité `reprise:reapparier-forsa-par-mois --simulation` ré-affecte chaque versement existant à l'échéance de son propre mois quand elle existe, n'est pas déjà prise et que le montant la couvre — et laisse non affecté, donc échéance rouverte, tout ce qui ne tombe pas juste. La migration de rattrapage applique la même logique ; l'ancienne commande chronologique `reprise:apparier-forsa` est supprimée, et sa migration de juillet neutralisée — rejouer sa logique écraserait des affectations arbitrées à la main. **Le avant/après sur les données réelles** (simulation du 02/08/2026, puis appliqué) : | N° | Mois | Avant | Après | |----|------|-------|-------| | 8 | septembre 2025 | 950,00 DH du 04/08/2025 | — rouverte | | 11 | décembre 2025 | 950,00 DH du 23/11/2025 | 950,00 DH du 13/12/2025 | | 12 | janvier 2026 | 950,00 DH du 13/12/2025 | 950,00 DH du 23/01/2026 | | 13 | février 2026 | 950,00 DH du 23/01/2026 | 950,00 DH du 18/02/2026 | | 14 | mars 2026 | 950,00 DH du 18/02/2026 | 938,00 DH du 28/03/2026 | | 15 | avril 2026 | 938,00 DH du 28/03/2026 | — rouverte | Exactement ce que l'exploitant avait énoncé : **l'échéance d'avril 2026 ressort impayée** — et septembre 2025 avec elle, l'autre trou que le remplissage chronologique bouchait en décalant tous les versements d'un mois. Les indicateurs suivent : 16 réglées (18 avant), capital restant 74 992,00 DH, prochaine impayée n° 8 du 01/09/2025. Le second passage de la commande répond « Rien à corriger ». Neuf versements restent non affectés, listés pour arbitrage manuel : les sept opérations qui ne sont pas des remboursements (1 500, 150, 3 802, 3 000, 3 400, 33 et 30 DH), et les deux 950 DH « en trop » du 04/08/2025 et du 23/11/2025, dont les mois étaient déjà réglés — c'est à l'exploitant de dire quels mois ils règlent, depuis la page du prêt. Le tableau de bord suit : la carte « Prochaine échéance Forsa » montre la plus ancienne impayée — avec son retard en toutes lettres — et non le mois courant. --- ## Ce qu'il fallait vérifier, et qui est vérifié - l'échéancier fait 96 × 938 DH, dernière à 890, sans part de frais, et aucun code ne référence plus 950 ni une part de frais fixe ; - la saisie depuis la page du prêt crée l'opération au journal, solde l'échéance choisie et recalcule le capital ; - le sélecteur de « Nouvelle opération » est là et obligatoire quand la catégorie Forsa est choisie, inopérant sinon ; - le pré-choix : même mois impayé d'abord, sinon plus ancienne impayée, et le choix libre d'un vieux mois est respecté ; - deux opérations ne peuvent pas régler la même échéance — le service le refuse en français, la base le refuse en SQL ; - le détachement rouvre l'échéance et laisse l'opération au journal ; la mise à la corbeille de l'opération rouvre l'échéance ; - la commande de ré-appariement reproduit le cas d'avril : le versement de mai va à mai, avril rouvre — y compris depuis l'état chronologique stocké, où un versement doit reculer d'une échéance ; - la carte du tableau de bord montre avril, en retard de 4 mois, quand avril est le trou.