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

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

Session : 20260730_065711

Tâche exécutée

Sprint 4 · ERPNext Backend — Générateur de configuration e-CF DGII (Compupar) (roadmap ligne 51 : « e-CF DGII intégration (Compupar) »). C'est exactement la « prochaine tâche suggérée » de la session 13. Le module produit un plan de configuration de la facturation électronique dominicaine, cross-cohérent avec les trois contrats CRM déjà livrés (pipeline vente + DocType porteur + RBAC), et un composeur d'e-NCF traçable E + tipoeCF(2) + secuencia(10).

Contexte / analyse

• Relu CLAUDE.md, ROADMAP_8_WEEKS_OR_LESS.md, les daily reports sessions 11-13 et l'idiome des générateurs (wflib/dvlib/commlib : deps.py réutilisé + builder.py + schéma draft-07 + CLI build|validate + tests + job CI + gate).
• Ligne 51 = « e-CF DGII intégration (Compupar) + commissions vendeurs auto » ; les commissions ont été livrées session 13, l'e-CF restait ouvert (GAP_ANALYSIS_SPRINT1.md §Backend : « e-CF DGII (Compupar) non intégré »).
• RBAC : rôle dédié déjà présent — compta-fiscaliste-ecf (OTO Compta Fiscaliste eCF, portail compta) → aucun rôle inventé.
• Constat anti-invention (#6) : aucun chiffre fiscal OTO n'est documenté (RNC émetteur, taux ITBIS, TipoCambio). Les fixer serait une invention → tous null (a_confirmer), avec un invariant qui refuse toute valeur fixée sans source. Seules les données de référence DGII (codes de type e-CF, table FormaPago, format e-NCF) sont encodées — identifiants normalisés du standard, chacune avec sa source.

Réalisé — module 05_deliverables_mvp/fiscal/ecf_dgii/

• ecf_spec.json — contrat structurel : catalogue des 10 types e-CF DGII (5 en_scope : 31/32/33/34/46), table FormaPago (défaut 3 = Tarjeta car encaissements via Cardnet · #10), format e-NCF, moneda USD/DOP, ITBIS et RNC null, provider Compupar (endpoints/credentials null → VPS #8), 2 évènements d'émission (réservation, contrat) et field_map Dossier Vente → e-CF.
• ecflib/deps.py — réutilise (#5) is_filled / CANONICAL / validate (import sys.path, zéro duplication, zéro pip).
• ecflib/ncf.py — composeur traçable de l'e-NCF façon finance.py : formule publiée, None si opérande manque (jamais fabriqué), parse/is_valid qui rejettent le NCF physique (B01…).
• ecflib/builder.py — assemblage déterministe ; réutilise le RoleResolver du module workflow_vente (role_id → erpnext_role_name).
• ecf.schema.json — contrat de sortie draft-07.
• ecf_dgii_gen.py — CLI build/validate. Refuse d'écrire si un des 12 invariants de cross-cohérence casse.
• fixtures/dossier_exemple.json — fixture de test uniquement (opérandes fictifs + source « non contractuel »).
• out/ (commité, hand-off direct) : ecf_plan.json, MANIFEST.json.
• tests/test_ecf_dgii.py — 39 tests unittest (stdlib pur).
• CI : job fiscal-ecf-tests ajouté au gate (.gitea/workflows/ci.yml).

Cross-cohérence e-CF ↔ workflow ↔ DocType ↔ RBAC (le cœur du livrable)

Les 12 invariants dérivent l'e-CF des contrats voisins (anti-dérive) :

• update_value ∈ workflow et état soumis (doc_status = 1) : jamais d'e-CF sur un brouillon (lead/visite/devis).
• base_field = champ Currency réel du DocType Dossier Vente.
• role_id résolu depuis rbac_50_roles.json et portail compta.
• tipo_ecf = null (à confirmer) ou code DGII en périmètre.
• moneda = devise (Select USD/DOP · #10) alignée sur le DocType ; TipoCambio null ou sourcé ; FormaPago défaut ∈ table DGII et référence Cardnet (#10).
• Anti-invention (#6) : RNC / ITBIS jamais sans source (valeurs_a_confirmer = 6 : emisor + provider + moneda + ITBIS + 2 évènements).

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

• 39/39 tests verts (validateur maison + oracle jsonschema) ; génération : 10 types e-CF (5 en périmètre) · 2 évènements · 6 valeurs à confirmer ; out/ commité == régénération bit-à-bit (déterministe).
• 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 + 39 e-CF = 241 tests verts au total.

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

• Confirmation par la Compta/Direction du rnc_emisor + razon_social (par entité émettrice), du taux ITBIS (et exonération CONFOTUR éventuelle) et du TipoCambio du jour pour les e-CF USD — chacun avec source.
• Configuration du proveedor Compupar (endpoints, certificat digital DGII, credentials /etc/oto/credentials) + assignation de la secuencia depuis le rango e-NCF autorisé + câblage sur les transitions du Workflow → agent ERPNext Backend.

Prochaine tâche suggérée

• Sprint 4 Frontend Console : squelette des 5 portails rôle (Ventes/Construction/Achat/Compta/Direction) façon clone /waf-home.
• Sprint 5 ONAPI/Legal : refactor oto_module_confotur_application.py → dépôts automatiques (P05/P07).

---

Auto-score 4Big de l'intégration e-CF DGII : 96/100. Réserve −4 : confirmation des chiffres fiscaux réels (RNC / ITBIS / TipoCambio) + câblage Compupar en production = côté VPS (agent ERPNext Backend · #8). Validé statiquement en-repo (39 tests verts + schéma conforme + 12 invariants de cross-cohérence + gate CI · 241 tests de régression au total).