Facturation électronique française dans D365 Finance : architecture d'implémentation

Contexte réglementaire et calendrier

Préparez l'implémentation bien avant la date de mandation. La chaîne de configuration, l'assainissement de la qualité des données et l'onboarding PDP nécessitent un délai significatif.

Distinguer les flux réglementaires

La documentation Microsoft distingue la facturation électronique B2B domestique, les factures fournisseurs entrantes et l'e-reporting pour les transactions hors échange obligatoire. L'approche D365 utilise une Plateforme de Dématérialisation Partenaire (PDP) et le service cloud de Facturation Électronique.

Composants techniques et flux de données

• D365 Finance : documents, tiers, taxes, établissements, identifiants et gestion du statut métier.
• Globalization Studio : importer, configurer et publier les fonctionnalités de globalisation (dont la fonctionnalité France).
• Reporting Électronique (ER) : transformer les données métier en formats requis (Factur-X, UBL, EN16931).
• Service de Facturation Électronique : exécuter des scénarios de traitement configurables hors du runtime Finance.
• Azure Key Vault : protéger les certificats, clés API et matériaux de connexion PDP.
• PDP : assurer la connectivité réglementaire de dernier kilomètre, la propagation des statuts et le reporting DGFiP.

Hiérarchie de configuration du Reporting Électronique

Le framework ER délivre le format de facture via un modèle strict d'héritage parent-enfant. La personnalisation des formats standards requiert de comprendre cette hiérarchie pour ne pas casser le chemin de mise à jour Microsoft :

Hiérarchie de configuration ER (exemple pour la France) :
Modèle de facture (abstrait)
└── Mapping du modèle de facture (transformation de données)
    └── Facture électronique française (FR) [fonctionnalité de globalisation]
        ├── Format Factur-X / UBL 2.1
        │   └── [Format dérivé client — étendre ici, jamais au parent]
        └── Format e-reporting

• Créez toujours un format dérivé pour toute personnalisation. Ne modifiez jamais directement la configuration fournie par Microsoft.
• Définissez la base du format dérivé sur la version Microsoft que vous avez testée. Quand Microsoft publie une mise à jour, comparez le delta avant de rebaser.
• Stockez les configurations ER dans un stockage Azure Blob dédié ou le dépôt connecté Dataverse, pas sur la machine du développeur.
• Versionnez les fichiers XML ER exportés avec le code source X++ dans Git.

La qualité des données est le chemin critique

• SIREN/SIRET, identifiant TVA (TVAIFR) et catégories d'enregistrement pour chaque tiers.
• Adresse de facturation électronique et identifiant de routage PDP.
• Établissement émetteur, adresse et identifiants d'enregistrement applicables.
• Pays client/fournisseur, type de relation (B2B, B2C, secteur public) et code de routage PDP.
• Codes taxe, motifs d'exonération, unités de mesure et conditions de paiement.
• Références obligatoires : bon de commande, contrat, prestation, référence acheteur (BT-10).

Réalisez une évaluation de la qualité des données sur tous les clients et fournisseurs actifs avant la configuration. Un SIRET manquant ou un identifiant de routage incorrect provoquera le rejet de la facture par la PDP avec une erreur de non-conformité réglementaire nécessitant correction et re-soumission.

Chaîne de configuration

1. Installer et activer la Facturation Électronique pour un environnement cloud éligible (Niveau 2+).
2. Configurer Key Vault et les identifiants PDP (certificat de signature numérique, clé API de connectivité PDP).
3. Importer la fonctionnalité de globalisation Facture électronique française (FR) depuis le référentiel global.
4. Associer les configurations ER, scénarios de traitement, canaux de communication et mappings de types de réponse.
5. Configurer les établissements, les ID d'enregistrement et les conditions d'applicabilité.
6. Planifier les batchs de soumission et d'interrogation de statuts ; configurer les alertes de monitoring.
7. Tester chaque type de document et chaque transition de statut attendue avant la mise en production.

Concevoir une machine d'état opérable

BROUILLON
  → COMPTABILISÉ (comptabilisation D365)
    → PRÊT_À_SOUMETTRE (batch prend en charge)
      → SOUMIS (envoyé au service FE)
        → SOUMIS_À_LA_PDP (transmis à la Plateforme)
          → LIVRÉ (PDP confirme la livraison à l'acheteur)
            → ACCEPTÉ (acheteur a accepté)
            → REJETÉ → CORRECTION_REQUISE → RE-SOUMIS
          → ERREUR_PDP (transitoire — file de relance)
        → ERREUR_SERVICE_FE (erreur config ou format — action manuelle)

Chaque transition de statut nécessite : un horodatage, la source (D365, service FE, PDP ou acheteur), l'identifiant externe (ID document PDP, référence DGFiP) et un message actionnable pour les utilisateurs métier.

• Ne confondez pas la comptabilisation D365 avec le statut de soumission réglementaire.
• Corrèlez le numéro de document D365, l'ID de message du service FE et l'identifiant PDP dans une table de lookup unique.
• Séparez les défaillances techniques transitoires (réseau, secret expiré) des rejets métier (données invalides, doublon).
• Définissez qui peut relancer, corriger et annuler : utilisateur métier, comptable ou IT uniquement.

Résilience et sécurité

• Utilisez une clé de corrélation stable et unique par document (numéro + entité légale + séquence) et concevez pour la re-soumission idempotente.
• Relance exponentielle avec plafond et file de lettres mortes pour les seules défaillances transitoires.
• File de reprise manuelle avec affectation de propriétaire claire pour les rejets métier.
• Rotation planifiée des secrets et certificats PDP (avant expiration, pas à expiration).
• Journalisation de l'ID de corrélation et du statut sans exposer le contenu de la facture dans les logs applicatifs.
• Alertes pour les documents bloqués au-delà d'un seuil configurable (ex. : 48 h en état SOUMIS).

Matrice de tests

Runbook opérationnel

1. Tableau de bord quotidien : documents par statut, ancienneté et entité légale.
2. Flux de diagnostic par identifiant de corrélation (numéro D365 → ID service FE → référence PDP).
3. Propriétaire métier et IT nommé pour chaque catégorie de type de rejet.
4. Calendrier de rotation des certificats et secrets PDP (clé API PDP, certificat de signature).
5. Processus de reprise en cas de panne PDP : file d'attente, suspension de batch, communication aux parties prenantes.
6. Réconciliation quotidienne volume et comptabilité (montant facturé vs comptabilisé vs transmis).
7. Surveillance des mises à jour des fonctionnalités réglementaires Microsoft et des changements de spécification DGFiP.

Voir aussi

• Déployer un package D365 F&O via LCS — déployer les mises à jour de configuration ER et de fonctionnalité de globalisation
• Structurer un backlog Azure DevOps pour un programme D365 — gérer les stories de facturation électronique, cas de test et spikes réglementaires

Références Microsoft Learn

• Facturation électronique pour la France
• E-reporting France
• Vue d'ensemble du service de facturation électronique
• Composants de facturation électronique
• Établissements et ID d'enregistrement sur les factures