tristan
a442d124a3
Auto Tag Develop / tag (push) Successful in 11s
## 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é Reviewed-on: #86 Co-authored-by: tristan <tristan@yuno.malio.fr> Co-committed-by: tristan <tristan@yuno.malio.fr>