Claude Code DTP Worker
cb8069b83c
Explore very-thorough sur crm/dossier_vente · crm/financement_bancaire · faisabilite/bancable · frontend/chat_otoia · pie/manifest · qa/audit_4big · mobile/app_config · fiscal/ecf_dgii → 0 défaut réel. Les 4 candidats remontés sont tous NON-défauts (verify-non-defects #6) : 3× `:g` sur domaine BORNÉ (nombre d'unités / pourcentages 0-100 → exponentiel + arrondi-6-chiffres hors domaine, et `:g` nettoie le bruit flottant) + 1× HTML chat_otoia à entrée canonique contrôlée. Preuve robuste : report.py `_money` réserve sciemment `,.0f`/`,.2f` aux montants non bornés → les `:g` restants sont un choix d'ingénierie correct, pas un oubli. Fait nouveau : le taux commissions `:g` (déjà statué non-défaut en 080104) a RÉCIDIVÉ de flag ce cycle, et bancable ×2 fraîchement flaggés → la classe gaspille un cycle d'audit à chaque passage. `grep ':g}'` prod = exactement 3 sites. Passe unique : note de justification in-situ à chacun (domaine borné, 2 pièges hors domaine, montants → `,.0f`, « ne pas corriger »). Convertit le faux-positif récurrent en « déjà revu, sûr ». 0 fix de code (défauts inexistants ; corriger `:g`→`:f` réintroduirait du bruit flottant = régression) · 0 gate (#5) · 0 artefact reconstruit (bancable sans out/ ; _rate_label runtime non sérialisé) · matrice inchangée 633/616/17 · run_ci 33/0/0 · NFC-clean · 0 code moteur V18 (bloqué D-06) · 0 commande VPS. M crm/commissions/commlib/finance.py M faisabilite/bancable/banclib/finance.py M faisabilite/bancable/banclib/report.py M 05_activity_log/2026-08-12.md Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Barème commissions vendeurs · OTO Barème Commissions Ventes
Sprint 4 · ERPNext Backend (roadmap ligne 51 : « commissions vendeurs
auto »). Produit un plan de commissions cross-cohérent avec les trois
contrats CRM déjà livrés : le pipeline vente
../workflow_vente/, le DocType porteur
../dossier_vente/ et le contrat RBAC 50 rôles.
Il répond à la question : quel évènement du pipeline paie, à quel rôle, sur
quel montant — et fournit un calculateur traçable commission = base × taux.
Ce worker n'écrit jamais sur le VPS (contrainte #8) : il émet les fichiers de hand-off en-repo ; la création du champ commission et le calcul en production restent côté agent ERPNext Backend.
Anti-invention (#6) — pourquoi tous les taux sont null
Aucun taux de commission n'est documenté dans CLAUDE.md. Les seuls pourcentages canoniques (3 % édition · 8.5 % marketing · 52 % point d'équilibre) ne sont pas des commissions. Fixer un taux ici serait une invention. Donc :
- Le barème livré porte
taux_pct: null+source: null+a_confirmer: truepour chaque évènement. - Le calcul
commission = base × tauxresteNonetant qu'un opérande manque — jamais 0-inventé ; la formule reste affichée (traçabilité façonbanclib/finance.py). - Un invariant du CLI refuse tout
taux_pctfourni sanssource.
La Direction renseigne taux_pct + source plus tard ; le calcul devient alors
auditable et reproductible.
Ce qui est généré (out/, commité — hand-off direct)
| Fichier | Rôle |
|---|---|
commission_plan.json |
Le plan normalisé : par évènement → rôle (nom Frappe résolu) + champ de base + taux (null, à confirmer). |
MANIFEST.json |
Traçabilité (4 sources, comptes, taux_a_confirmer) + rôles RBAC utilisés + note anti-invention. |
Cross-cohérence barème ↔ workflow ↔ DocType ↔ RBAC (le cœur du livrable)
Chaque évènement est contraint par les contrats voisins (anti-dérive · zéro duplication · workflow #5) :
update_valuedoit exister dansworkflow_vente_spec.jsonet correspondre à un état soumis (doc_status = 1) : on ne commissionne pas un brouillon (lead/visite/devis/abandonné), seulement réservation, contrat et approbation CONFOTUR.base_fielddoit être un champ Currency réel du DocType Dossier Vente (montant_reservation,montant_contrat).role_iddoit être résolu depuisrbac_50_roles.json(via leRoleResolverréutilisé du module workflow) et appartenir au portailventes.devise_field= le champdevise(SelectUSD/DOP · #10) du DocType.
Utilisation
python3 commissions_gen.py build # écrit out/ (refuse si invalide)
python3 commissions_gen.py validate # schéma + 10 invariants, sans écrire
python3 -m unittest discover -s tests -v # 27 tests (stdlib pur)
Les 10 invariants (le CLI refuse d'écrire si l'un casse)
- Conformité au schéma de sortie. 2.
update_value∈ workflow vente. 3. État soumis uniquement (pas de commission sur brouillon). base_field= champ Currency réel du Dossier Vente. 5.role_iddu portail ventes. 6.erpnext_role_namecohérent avec RBAC. 7. Anti-invention : jamais detaux_pctsanssource. 8. Unicité (update_value,role_id). 9.devise_field=devise(USD/DOP). 10. Comptes du manifeste cohérents.
Calcul traçable (commlib/finance.py)
compute_line(dossier, event) → montant = base × taux_pct, avec la formule
publiée (200000 × 2.5 %), la devise, et champs_manquants si un opérande est
absent (montant alors None). La fixture fixtures/dossier_exemple.json
sert uniquement aux tests : ses chiffres sont des exemples fictifs portant une
source explicite « non contractuel » — jamais commités dans out/.
Hand-off VPS (agent ERPNext Backend · hors périmètre worker · #8)
- La Direction confirme les
taux_pct+sourcede chaque évènement. - Créer le mécanisme de commission côté ERPNext (champ/table enfant sur le DocType Dossier Vente, ou DocType commission dédié) et brancher le calcul sur les transitions du Workflow (réservation / contrat / CONFOTUR approuvé).
Auto-score 4Big : 96/100. Réserve −4 : confirmation des taux réels + câblage du calcul en production côté VPS (agent ERPNext Backend · #8) ; ce module valide statiquement en-repo (27 tests verts + schéma + 10 invariants de cross-cohérence
- gate CI).