Aller au contenu

ADR-0026 — Dérogation temporaire : Comptoir consommateur FISCAL /supplier-payments (phase 2)

  • Statut : Acceptée (dérogation accordée par le décideur produit/architecte, 2026-07-03). Temporaire — révision au prochain gate de phase FISCAL.
  • Contexte règle : .cursor/rules/fiscal-transformation-2026-priorite.mdc §2.2 (gel des nouveaux consommateurs FISCAL en phase 2) et §4 (escalade tracée). Cet ADR est la trace de dérogation exigée par §2.4.
  • Liens : ADR-0025 (Comptoir app distincte), ADR-0023 (intégration FISCAL/BOOKS API partagée), docs/projet-nouveau/RelationsExternes/SPEC_TECHNIQUE_COMPTOIR_MVP.md §11.

Contexte

Le MVP de COMPTOIR inclut le cycle achats P2P (devis → BC → réception → facture reçue → règlement). Au règlement d'une facture fournisseur, le besoin est de déclarer le paiement fournisseur à FISCAL (traçabilité fiscale, référence DGI, éventuelle orchestration payout).

FISCAL expose déjà POST /api/v1/fiscal/supplier-payments (recordSupplierPayment, idempotent), aujourd'hui consommé par TRACIUM. Or fiscal-transformation-2026 §2.2 interdit d'ajouter un nouveau consommateur FISCAL pendant la phase 2 (M+2→M+5, ~juil.→oct. 2026) sans dérogation explicite.

Décision

Dérogation accordée : Comptoir est autorisé à consommer l'endpoint existant /api/v1/fiscal/supplier-payments (via SLY /fiscal/**) pour déclarer le règlement fournisseur, pendant la phase 2.

Garde-fous (conditions de la dérogation)

  1. Endpoint existant uniquement. Aucun nouvel endpoint FISCAL, aucune modification du contrat /supplier-payments, aucune nouvelle juridiction, aucun appel direct à une autorité fiscale (respect §2.1 : on passe par FISCAL, jamais par la DGI en direct).
  2. Idempotence obligatoire : idempotencyKey stable dérivé de la pièce (comptoir-regl-{pieceAchatId}).
  3. RAS exclue : le calcul de retenue à la source n'existe pas (roadmap WithholdingTaxCalculator). La RAS reste saisie manuelle dans Comptoir (ras_montant). La dérogation ne crée pas cet endpoint.
  4. Réversibilité : si la phase 2 FISCAL impose un nouveau contrat (Customer/Product/Price…), Comptoir migre. La dérogation est révisée à chaque gate FISCAL.
  5. Périmètre : déclaration de paiement fournisseur uniquement — pas de certification (les achats ne sont pas certifiés, FISCAL est sell-side).

Caveat contractuel (à traiter en phase 2)

SupplierPaymentRequest exige lotId et agreementId (@NotBlank) — des concepts TRACIUM (lot de paiement, accord), absents de Comptoir.

  • MVP (option A, retenue) : mapping documenté — lotId = {pieceAchatId}, agreementId = {contratRef ou "COMPTOIR"}, supplierId = {NINEA ou tiersId}, referenceDgi = {référence facture reçue}. Fonctionne, mais sémantiquement imparfait.
  • Cible (option B, recommandée, Phase 2) : généraliser le contrat FISCAL (rendre lotId/agreementId optionnels ou ajouter un sourceRef générique {app, entityId}). ⚠️ Cela modifie le contrat FISCAL → nécessite un ADR FISCAL séparé et l'accord architecte — hors périmètre de cette dérogation.

Conséquences

  • Positif : le MVP achats de Comptoir couvre le règlement tracé sans attendre la fin de la phase 2.
  • Dette temporaire : le mapping option A est à remplacer par le contrat généralisé (option B) en phase 2.
  • Gouvernance : cette dérogation est révocable ; toute extension au-delà de /supplier-payments (RAS, certification, nouveau contrat) repart en escalade #archi @lead-archi.

Conformité règle FISCAL

§2.1 ✅ (pas d'appel autorité directe) · §2.2 ⚠️ dérogation tracée ici · §2.3 ✅ · §2.4 ✅ (cet ADR) · §4 ✅ (tracé). À revoir au prochain gate de phase FISCAL.