feat(technique) : validations RG comptables server-side (RG-3.07/3.08) (ERP-136) #95

2026-06-12T09:52:26Z

matthieu commented

2026-06-12 09:52:26 +00:00

Contexte

Ticket ERP-136 (M3 — Répertoire prestataires, position 1.6). Valide les RG métier server-side (couche autoritaire, mode strict). Empilé sur ERP-135 (cible la branche feature/ERP-135-sous-ressources-provider, pas develop).

Constat

L'essentiel des RG du périmètre étaient déjà portées par les contraintes d'entité / gardes des processors posées en ERP-133/134/135 (RG-3.03/3.05 Assert\Count, RG-3.09 validateCategoryType, écriture cloisonnée § 2.13 guardSiteScope, RG-3.08 DELETE dernier RIB → 409). Le périmètre neuf de ce ticket = RG-3.07 et RG-3.08 (volet écriture du formulaire).

Changements

Provider::validatePaymentTypeConsistency (nouveau Assert\Callback, miroir Supplier, décision ERP-89) :
- RG-3.07 : paymentType=VIREMENT + bank null → 422 (violation sur bank).
- RG-3.08 : paymentType=LCR + 0 RIB → 422 (violation sur paymentType).
ProviderProcessor : docblock réaligné (RG-3.07/3.08 portées par l'entité, comme RG-3.09).
AbstractProviderApiTestCase::bank() : helper référentiel banque (miroir M2).
ProviderAccountingValidationTest : 4 cas (négatif 422 / positif 200) par RG.

Pourquoi sur l'entité et non le processor

La spec suggérait ProviderProcessor, mais on aligne sur la décision figée ERP-89 du jumeau M2 : RG inter-champs via Assert\Callback + ->atPath() pour que chaque 422 porte un propertyPath exploitable inline côté front (ERP-101).

Vérifications

ProviderAccountingValidationTest → 4 tests OK
Garde-fou EntityConstraintsHaveFrenchMessageTest + suite Technique → 51 tests OK
make php-cs-fixer-allow-risky → 0 fix
make test → 635 tests OK

## Contexte Ticket ERP-136 (M3 — Répertoire prestataires, position 1.6). Valide les RG métier server-side (couche autoritaire, mode strict). **Empilé sur ERP-135** (cible la branche `feature/ERP-135-sous-ressources-provider`, pas `develop`). ## Constat L'essentiel des RG du périmètre étaient déjà portées par les contraintes d'entité / gardes des processors posées en ERP-133/134/135 (RG-3.03/3.05 `Assert\Count`, RG-3.09 `validateCategoryType`, écriture cloisonnée § 2.13 `guardSiteScope`, RG-3.08 DELETE dernier RIB → 409). Le **périmètre neuf** de ce ticket = RG-3.07 et RG-3.08 (volet écriture du formulaire). ## Changements - **`Provider::validatePaymentTypeConsistency`** (nouveau `Assert\Callback`, miroir `Supplier`, décision ERP-89) : - RG-3.07 : `paymentType=VIREMENT` + `bank` null → 422 (violation sur `bank`). - RG-3.08 : `paymentType=LCR` + 0 RIB → 422 (violation sur `paymentType`). - **`ProviderProcessor`** : docblock réaligné (RG-3.07/3.08 portées par l'entité, comme RG-3.09). - **`AbstractProviderApiTestCase::bank()`** : helper référentiel banque (miroir M2). - **`ProviderAccountingValidationTest`** : 4 cas (négatif 422 / positif 200) par RG. ### Pourquoi sur l'entité et non le processor La spec suggérait `ProviderProcessor`, mais on aligne sur la décision figée ERP-89 du jumeau M2 : RG inter-champs via `Assert\Callback` + `->atPath()` pour que chaque 422 porte un `propertyPath` exploitable inline côté front (ERP-101). ## Vérifications - `ProviderAccountingValidationTest` → 4 tests OK - Garde-fou `EntityConstraintsHaveFrenchMessageTest` + suite Technique → 51 tests OK - `make php-cs-fixer-allow-risky` → 0 fix - `make test` → 635 tests OK

matthieu added 1 commit 2026-06-12 09:52:27 +00:00

feat(technique) : validations RG comptables server-side (RG-3.07 Virement/banque, RG-3.08 LCR/RIB) (ERP-136) 9a6ec71981

- Provider::validatePaymentTypeConsistency (Assert\Callback, miroir Supplier ERP-89) :
  RG-3.07 VIREMENT impose une banque (violation sur bank),
  RG-3.08 LCR impose au moins un RIB (violation sur paymentType).
- ProviderProcessor : docblock realigne (RG-3.07/3.08 portees par l'entite).
- AbstractProviderApiTestCase::bank() helper referentiel.
- ProviderAccountingValidationTest : 4 cas (negatif 422 / positif 200) par RG.

Les RG-3.03/3.05/3.09 (contraintes d'entite) et l'ecriture cloisonnee (gardes
processors, RG-3.17/2.13) etaient deja posees en ERP-133/134/135 et restent couvertes.

matthieu added the back M3-Prestataire type/feat labels 2026-06-12 09:53:04 +00:00

matthieu commented

2026-06-12 14:37:11 +00:00

Consolidée dans #100 : toute la pile M3-Prestataire (ERP-134 à ERP-139) a été rebasée sur develop et regroupée dans la MR #100 (mergeable, tests verts). Cette MR intermédiaire est fermée pour ne garder qu'une seule MR ouverte. Les commits de ce ticket restent présents dans #100.

matthieu closed this pull request

2026-06-12 14:37:11 +00:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MALIO-DEV/Starseed#95