oto-enterprise-os-dtp/05_deliverables_mvp/daily_reports/2026-07-30-session13.md

Daily Report · 2026-07-30 · Claude Code DTP Worker (session 13)

Session : 20260730_062706

Tâche exécutée

Sprint 4 · ERPNext Backend — Générateur du barème de commissions vendeurs (roadmap ligne 51 : « commissions vendeurs auto »). C'est la « prochaine tâche suggérée » de la session 12. Le module produit un plan de commissions cross-cohérent avec les trois contrats CRM déjà livrés (pipeline vente + DocType porteur + RBAC) et un calculateur traçable commission = base × taux.

Contexte / analyse

• Relu CLAUDE.md, ROADMAP_8_WEEKS_OR_LESS.md, les daily reports sessions 11-12 et l'idiome des générateurs (wflib/dvlib/banclib : deps.py réutilisé + builder.py + schéma draft-07 + CLI build|validate + tests + job CI + gate).
• Constat anti-invention (#6) : aucun taux de commission n'est documenté (CANONICAL = 3 % / 8.5 % / 52 %, aucune commission). Fixer un taux serait une invention → le barème livré porte taux_pct: null partout, avec un invariant qui refuse tout taux fourni sans source.

Réalisé — module 05_deliverables_mvp/crm/commissions/

• bareme_spec.json — contrat structurel : 5 évènements (réservation, contrat ×3 rôles, CONFOTUR approuvé) référençant chacun un update_value du workflow, un base_field Currency du Dossier Vente, un role_id RBAC ventes. Tous les taux_pct à null (a_confirmer: true).
• commlib/deps.py — réutilise (#5) is_filled / CANONICAL / validate (import sys.path, zéro duplication, zéro pip).
• commlib/finance.py — calcul traçable commission = base × taux façon banclib/finance.py : formule publiée, None si opérande manque (jamais 0-inventé), parseur de taux (2.5 ou « 2.5 % »).
• commlib/builder.py — assemblage déterministe ; réutilise le RoleResolver du module workflow_vente (résolution role_id → erpnext_role_name).
• bareme.schema.json — contrat de sortie draft-07.
• commissions_gen.py — CLI build/validate. Refuse d'écrire si un des 10 invariants de cross-cohérence casse.
• fixtures/dossier_exemple.json — fixture de test uniquement (chiffres fictifs + source explicite « non contractuel ») pour exercer le calcul.
• out/ (commité, hand-off direct) : commission_plan.json, MANIFEST.json.
• tests/test_commissions.py — 25 tests unittest (stdlib pur).
• CI : job crm-commissions-tests ajouté au gate (.gitea/workflows/ci.yml).

Cross-cohérence barème ↔ workflow ↔ DocType ↔ RBAC (le cœur du livrable)

Les 10 invariants dérivent le barème des contrats voisins (anti-dérive) :

• update_value ∈ workflow et état soumis (doc_status = 1) : jamais de commission sur un brouillon (lead/visite/devis/abandonné).
• base_field = champ Currency réel du DocType Dossier Vente.
• role_id résolu depuis rbac_50_roles.json et portail ventes.
• devise_field = champ devise (Select USD/DOP · #10).
• Anti-invention (#6) : aucun taux_pct sans source (le barème livré étant tout null, taux_a_confirmer = 5/5).

Vérifications effectuées (en-repo, sans toucher au VPS)

• 25/25 tests verts (validateur maison + oracle jsonschema) ; génération : 5 évènements · 4 rôles · 5 taux à confirmer ; out/ commité == régénération bit-à-bit.
• Gate CI local vert (exit 0) : guard_constraints.sh, validate_json.sh, check_docs.sh (score présent, 0 lien cassé), YAML ci.yml valide.
• Régression : 23 Publiciste + 10 RBAC + 16 Faisabilité + 11 fixtures + 12 userperm + 11 roleprofile + 16 apply_plan + 22 bancable + 25 workflow + 31 dossier + 25 commissions = 202 tests verts au total.

Non fait (hors périmètre worker · VPS · #8)

• Confirmation des taux_pct réels + source par la Direction.
• Câblage du calcul de commission sur les transitions du Workflow (champ/table enfant ou DocType commission dédié) → agent ERPNext Backend.

Prochaine tâche suggérée

• Sprint 4 ERPNext Backend : plan e-CF DGII (Compupar) — structure de la facturation électronique fiscale (hand-off, zéro chiffre).
• Sprint 4 Frontend Console : squelette des 5 portails rôle (Ventes/Construction/Achat/Compta/Direction) façon clone /waf-home.

---

Auto-score 4Big du barème commissions : 96/100. Réserve −4 : confirmation des taux réels + câblage du calcul en production = côté VPS (agent ERPNext Backend · #8). Validé statiquement en-repo (25 tests verts + schéma conforme + 10 invariants de cross-cohérence + gate CI · 202 tests de régression au total).