Billing Application
Transformer des règles devis-facture en comportements persistés et testables.
Application réalisée comme preuve de livraison Full Stack autour d’un flux devis → facture. F05 limite les revendications aux comportements inspectés et exécutés.
État de preuve
- Source
- 0c701288473518cb9201685c69ecd217fd43ae8d
- Execution
- Build backend + frontend + harness métier F05
- Vérifié
- 2026-09-23
01 · Domaine
Le point intéressant n’est pas le CRUD. Ce sont les invariants de facturation.
Flux principal
Client → devis → lignes de devis → calcul HT/TVA/TTC → transformation en facture persistée.
Valeur d’ingénierie
Cohérence de domaine, historique de prix, transitions d’état, persistance et contrat frontend/backend.
02 · Architecture
Un flux Full Stack lisible de l’UI à la base.
Angular 17
Formulaires, listes, validation client et appels HTTP.
Spring REST
Controllers / DTO exposent les opérations devis et factures.
Services métier
Création du devis, calculs et transition vers facture.
JPA / MySQL
Entités persistées ; H2 disponible pour le profil de test.
03 · Règles métier vérifiées
Les affirmations pointent vers le code et un scénario exécuté.
BILLING-PRICE-SNAPSHOT
Prix du devis figé à la création
Chaque LigneDevis copie le prix courant du Produit dans prixUnitaire lors de la création du devis.
f05-billing-domain-tests · price snapshot / totals
backend/src/main/java/com/abarbach/gestionFactures/service/DevisService.javaBILLING-DRAFT-GUARD
Un brouillon n’est pas facturable
transformerEnFacture rejette explicitement le statut BROUILLON avec une erreur BAD_REQUEST.
f05-billing-domain-tests · draft rejection
backend/src/main/java/com/abarbach/gestionFactures/service/DevisService.javaBILLING-DUPLICATE-GUARD
Facturation répétée détectée
Le numéro FACT-<numeroDevis> est testé avant insertion ; une facture existante provoque CONFLICT.
f05-billing-domain-tests · duplicate conflict
backend/src/main/java/com/abarbach/gestionFactures/service/DevisService.javaHappy path exécuté
Prix 100 × quantité 2 → HT 200 · TVA 40 · TTC 240.
Le harness F05 crée le devis via le vrai DevisService, vérifie la copie de prixUnitaire et les totaux calculés. Il ne remplace ni les tests du projet ni une preuve production.
04 · Non-happy path & limites
Une garde réelle, mais plus étroite que la règle métier idéale.
Chemins observés
- BROUILLON → rejet BAD_REQUEST.
- Facture déjà présente → rejet CONFLICT.
- REFUSE → la garde actuelle ne le rejette pas.
Conclusion : F05 ne revendique pas « facturation uniquement après devis accepté ». Corriger cela serait une évolution du projet présenté, donc hors périmètre de cette slice.
Limites publiées
- Les montants persistés utilisent double. BigDecimal intervient pour l’arrondi TVA/TTC, mais le modèle monétaire n’est pas décimal de bout en bout.
- La détection de doublon est une protection par conflit, pas une garantie d’idempotence ni une preuve de sûreté concurrente.
- Les tests présents dans le dépôt source se limitent au chargement du contexte Spring ; F05 ajoute un harness externe sans modifier le projet présenté.
- Aucun client, revenu, volume production ou déploiement public n’est revendiqué.
05 · Continuer
Comparer les deux preuves profondes.
Billing démontre la livraison de règles applicatives. Le flagship de modernisation reste la preuve principale de gouvernance et de validation technique.