fix(commercial) : conserver le RIB au changement de type de règlement hors-LCR (ERP-121) #86

2026-06-11T10:01:13Z

tristan commented

2026-06-11 10:01:13 +00:00

Contexte — ERP-121

Le passage d'un tiers de LCR vers virement (ou autre) supprimait ses RIB en base : au changement de type de règlement, le front marquait les ClientRib / SupplierRib existants pour suppression puis envoyait des DELETE. Le métier veut conserver le RIB (coordonnée bancaire du tiers, découplée du mode de règlement) pour un éventuel retour en LCR.

Décisions métier (validées)

Affichage hors-LCR : RIB totalement masqué, ré-affiché au retour LCR — jamais supprimé en base.
RGPD / IBAN : conservation telle quelle, hors-scope de ce ticket.
Données déjà perdues : acceptable, le fix ne vaut que pour l'avenir.

Modifications (100% frontend — clients et fournisseurs)

new.vue / [id]/edit.vue : onPaymentTypeChange ne marque plus les RIB pour suppression et ne jette plus la saisie ; ils sont seulement masqués (visibleRibs) et réapparaissent au retour LCR.
submitAccounting ne (re)soumet les RIB que sous LCR ; seules les suppressions explicites (corbeille d'un bloc) restent en DELETE.
Consultation [id]/index.vue : RIB dormants masqués hors-LCR via le helper pur type-safe paymentTypeCodeOf (+ tests Vitest).

Back

Aucune modification : la seule règle est LCR → ≥1 RIB (RG-1.13 / RG-2.08) ; rien n'interdit un RIB sur un tiers non-LCR. Le guard Client/SupplierRibProcessor (refus de supprimer le dernier RIB sous LCR) reste inchangé. Pas de migration.

Vérifications

✅ Vitest : 384/384 (make nuxt-test)
✅ ESLint : clean sur les 10 fichiers
⏭️ PHPUnit non lancé : aucun fichier back modifié

## Contexte — ERP-121 Le passage d'un tiers de **LCR** vers **virement** (ou autre) supprimait ses RIB en base : au changement de type de règlement, le front marquait les `ClientRib` / `SupplierRib` existants pour suppression puis envoyait des `DELETE`. Le métier veut **conserver** le RIB (coordonnée bancaire du tiers, découplée du mode de règlement) pour un éventuel retour en LCR. ## Décisions métier (validées) 1. **Affichage hors-LCR** : RIB **totalement masqué**, ré-affiché au retour LCR — jamais supprimé en base. 2. **RGPD / IBAN** : conservation telle quelle, hors-scope de ce ticket. 3. **Données déjà perdues** : acceptable, le fix ne vaut que pour l'avenir. ## Modifications (100% frontend — clients **et** fournisseurs) - `new.vue` / `[id]/edit.vue` : `onPaymentTypeChange` ne marque plus les RIB pour suppression et ne jette plus la saisie ; ils sont seulement masqués (`visibleRibs`) et réapparaissent au retour LCR. - `submitAccounting` ne (re)soumet les RIB que **sous LCR** ; seules les suppressions **explicites** (corbeille d'un bloc) restent en `DELETE`. - Consultation `[id]/index.vue` : RIB dormants masqués hors-LCR via le helper pur type-safe `paymentTypeCodeOf` (+ tests Vitest). ## Back **Aucune modification** : la seule règle est `LCR → ≥1 RIB` (RG-1.13 / RG-2.08) ; rien n'interdit un RIB sur un tiers non-LCR. Le guard `Client/SupplierRibProcessor` (refus de supprimer le dernier RIB sous LCR) reste inchangé. **Pas de migration.** ## Vérifications - ✅ Vitest : **384/384** (`make nuxt-test`) - ✅ ESLint : clean sur les 10 fichiers - ⏭️ PHPUnit non lancé : aucun fichier back modifié

tristan added the type/fix front M1-Client M2-Fournisseur labels 2026-06-11 10:01:13 +00:00

tristan added 1 commit 2026-06-11 10:01:14 +00:00

fix(commercial) : conserver le RIB au changement de type de reglement hors-LCR (ERP-121)

Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m14s

Details

Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m38s

Details

4d20583e1b

Le passage d'un tiers de LCR vers virement (ou autre) supprimait ses RIB en base
via le front (DELETE differe). Le RIB est une coordonnee bancaire du tiers,
decouplee du mode de reglement : on le conserve desormais pour un eventuel retour
en LCR.

Clients ET fournisseurs (new.vue / [id]/edit.vue) :
- onPaymentTypeChange ne marque plus les RIB existants pour suppression et ne vide
  plus la saisie ; les RIB sont seulement masques (visibleRibs) et reapparaissent
  tels quels au retour LCR.
- submitAccounting ne (re)soumet les RIB que sous LCR ; seules les suppressions
  EXPLICITES (corbeille d'un bloc) restent en DELETE.

Consultation ([id]/index.vue) : RIB dormants totalement masques hors-LCR, via le
helper pur type-safe paymentTypeCodeOf (clientConsultation / supplierConsultation)
+ tests Vitest.

Aucune modification back (RG LCR -> >=1 RIB deja correcte, rien n'interdit un RIB
sur un tiers non-LCR) ni migration.

tristan merged commit a442d124a3 into develop

2026-06-11 10:05:42 +00:00

tristan deleted branch feature/ERP-121-conserver-rib-changement-type-reglement

2026-06-11 10:05:44 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MALIO-DEV/Starseed#86