fix(commercial) : validation onglet compta LCR + controle croise BIC/IBAN (ERP-118) #78

2026-06-09T08:31:08Z

tristan commented

2026-06-09 08:31:08 +00:00

ERP-118 — Validation onglet Comptabilité (LCR / RIB)

1. Fix — 422 « Au moins un RIB est obligatoire pour le type de règlement LCR »

L'onglet Comptabilité envoyait le PATCH /clients/{id} des scalaires (paymentType=LCR) avant le POST /clients/{id}/ribs. Or le back valide RG-1.13 (LCR ⟹ ≥1 RIB persisté) sur ce PATCH, en lisant les RIB en base — vides à ce stade. Résultat : 422, et le return empêchait la création des RIB. Premier passage en LCR impossible (deadlock).

Correctif : inverser l'ordre — RIB d'abord, puis PATCH des scalaires.

new.vue : POST/PATCH RIB → PATCH scalaires.
[id]/edit.vue : ordre universel CREATE/UPDATE RIB → PATCH scalaires → DELETE RIB retirés (suppressions après le PATCH : le guard back n'autorise la suppression du dernier RIB qu'une fois quitté LCR). Corrige au passage un 409 latent sur le swap du dernier RIB en LCR.

2. Feat — contrôle croisé pays BIC/IBAN

Assert\Bic(ibanPropertyPath: 'iban') sur ClientRib et SupplierRib : le pays du BIC (positions 5-6) doit correspondre au pays de l'IBAN (positions 1-2). Un BIC et un IBAN valides isolément mais de pays différents → 422, violation portée par le champ bic avec message FR (ibanMessage), mappée inline côté front. Aucune modif front nécessaire.

Tests

Tests fonctionnels du mismatch (BIC DE + IBAN FR → 422 sur propertyPath=bic, message FR) côté client et fournisseur.
Suite back complète au vert (garde-fou EntityConstraintsHaveFrenchMessageTest inclus), suite front Vitest au vert.

Points d'attention

Durcissement de RG (cross-check BIC/IBAN) hors spec initiale : des RIB existants avec BIC/IBAN de pays différents deviendraient non modifiables sans correction.
L'orchestration de submit n'est pas couverte par un test unitaire (pas d'infra de test composant sur ces écrans) — vérification golden path recommandée.

## ERP-118 — Validation onglet Comptabilité (LCR / RIB) ### 1. Fix — 422 « Au moins un RIB est obligatoire pour le type de règlement LCR » L'onglet Comptabilité envoyait le `PATCH /clients/{id}` des scalaires (`paymentType=LCR`) **avant** le `POST /clients/{id}/ribs`. Or le back valide RG-1.13 (LCR ⟹ ≥1 RIB persisté) sur ce PATCH, en lisant les RIB en base — vides à ce stade. Résultat : 422, et le `return` empêchait la création des RIB. Premier passage en LCR impossible (deadlock). **Correctif :** inverser l'ordre — RIB d'abord, puis PATCH des scalaires. - `new.vue` : `POST/PATCH RIB` → `PATCH scalaires`. - `[id]/edit.vue` : ordre universel `CREATE/UPDATE RIB` → `PATCH scalaires` → `DELETE RIB retirés` (suppressions après le PATCH : le guard back n'autorise la suppression du dernier RIB qu'une fois quitté LCR). Corrige au passage un 409 latent sur le swap du dernier RIB en LCR. ### 2. Feat — contrôle croisé pays BIC/IBAN `Assert\Bic(ibanPropertyPath: 'iban')` sur `ClientRib` et `SupplierRib` : le pays du BIC (positions 5-6) doit correspondre au pays de l'IBAN (positions 1-2). Un BIC et un IBAN valides isolément mais de pays différents → 422, violation portée par le champ `bic` avec message FR (`ibanMessage`), mappée inline côté front. Aucune modif front nécessaire. ### Tests - Tests fonctionnels du mismatch (BIC DE + IBAN FR → 422 sur `propertyPath=bic`, message FR) côté client et fournisseur. - Suite back complète au vert (garde-fou `EntityConstraintsHaveFrenchMessageTest` inclus), suite front Vitest au vert. ### Points d'attention - **Durcissement de RG** (cross-check BIC/IBAN) hors spec initiale : des RIB existants avec BIC/IBAN de pays différents deviendraient non modifiables sans correction. - L'orchestration de submit n'est pas couverte par un test unitaire (pas d'infra de test composant sur ces écrans) — vérification golden path recommandée.

tristan added the type/feat type/fix back front M1-Client M2-Fournisseur labels 2026-06-09 08:31:08 +00:00

tristan added 2 commits 2026-06-09 08:31:09 +00:00

fix(commercial) : creer les RIB avant le PATCH scalaires compta (LCR) c73111121f

L'onglet Comptabilite envoyait le PATCH des scalaires (paymentType=LCR) AVANT
le POST des RIB. Le back valide RG-1.13 (LCR => au moins un RIB persiste) sur ce
PATCH en lisant les RIB en base : vides a ce stade -> 422 « Au moins un RIB est
obligatoire pour le type de reglement LCR », et le return empechait la creation
des RIB. Premier passage en LCR impossible.

Ordre inverse : POST/PATCH des RIB d'abord, puis PATCH des scalaires. Sur l'ecran
edition, ordre universel sur CREATE/UPDATE RIB -> PATCH scalaires -> DELETE RIB
retires (les suppressions restent apres le PATCH : le guard back n'autorise la
suppression du dernier RIB qu'une fois quitte LCR). Corrige au passage un 409
latent sur le swap du dernier RIB en LCR.

feat(commercial) : controle croise pays BIC/IBAN sur les RIB

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

Details

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

Details

36b5e84053

Assert\Bic avec ibanPropertyPath sur ClientRib et SupplierRib : le pays du BIC
(positions 5-6) doit correspondre au pays de l'IBAN (positions 1-2). Un BIC et un
IBAN valides isolement mais de pays differents -> 422, violation portee par le
champ bic avec message FR (ibanMessage), mappee inline cote front.

Tests fonctionnels du mismatch (BIC DE + IBAN FR -> 422 sur propertyPath=bic)
cote client et fournisseur.

tristan merged commit 222338e5a4 into develop

2026-06-09 08:44:12 +00:00

tristan deleted branch feature/ERP-118-fix-validation-onglet-compta-lcr

2026-06-09 08:44:12 +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#78