Aller au contenu principal

E-Reporting

L'éditeur E-Reporting configure la production et la soumission des bundles e-Reporting périodiques exigés par la réforme française de la facturation électronique. Chaque société dépose un rapport réglementaire couvrant ses flux B2BINT, B2C et hors champ à une cadence fixe (mensuelle par défaut) ; cette page contrôle l'identité sender / issuer émise dans le bundle, la cadence et le choix des flux, et le transport PA utilisé pour téléverser le bundle une fois généré.

La page fonctionne quel que soit le système source — JD Edwards, SAP, NetSuite ou ERP personnalisé — une fois la source mappée vers UBL.

Refonte en 2026.05.8

L'E-Reporting est désormais entièrement désolidarisé de l'E-Invoicing. Il choisit son propre api-connecteur, son propre endpoint.report-import et son propre paMode — le reporting peut donc cibler une plateforme différente, ou utiliser des identifiants différents sur la même plateforme, par rapport à l'import des factures. Un nouveau transport SFTP permet de téléverser le bundle en dépôt fichier au lieu d'un POST REST. L'ancien drapeau sendToPA Y/N est remplacé par paMode (API / FTP / vide) pour cohérence avec l'E-Invoicing. La vérification de configuration signale désormais paMode=API sans connector et paMode=FTP sans paFtpHost comme erreurs.

L'éditeur comporte quatre onglets :

  1. Identity — champs d'identification Sender (PA) et Issuer (Déclarant) émis dans le bundle.
  2. Reporting — Business Process (B2BINT) et choix de la cadence et des flux.
  3. PA Connection — choix de l'api-connecteur qui porte le transport HTTP de la PA, plus la surcharge du nom d'endpoint et les paramètres de connexion.
  4. FTP/SFTP — sélecteur Send Mode et identifiants du serveur SFTP utilisés quand le sélecteur est positionné sur FTP.

Accès à l'éditeur

  • Paramètres → modèle e-reporting (la ressource au niveau système).
  • La portée par défaut est le template platform-wide e-reporting. Les surcharges par société se trouvent sur les templates e-reporting-{kco} et suivent la même forme ; le résolveur côté runtime regarde d'abord le template par société puis retombe sur le template platform-wide.

Vue d'ensemble

IdentityReportingPA ConnectionFTP/SFTPSender (PA)MATRICULEPA01ROLE CODEWKIssuer (Déclarant)SIREN123456789SCHEME0002 ▾RÔLESE ▾Onglet Reporting — aperçuFREQUENCYMONTHLY ▾FLUX10.1,10.3Onglet PA Connection — aperçuCONNECTEURpa-default ▾indépendant d'e-invoicingREPORT IMPORT ENDPOINTreport-importOnglet FTP/SFTP — aperçuSEND MODEAPI ▾vide = génère sans soumettreSFTP SERVERutilisé quand Send Mode = FTPHost | ftp.plateformeagree.frPort | 22Outbound | /out/reports/Inbound | /in/reports/Identité Sender + Issuerémise dans chaque bundleCadence + fluxpilote la période du schedulerapi-connecteur propreindépendant d'e-invoicingpaMode = API/FTP/videremplace sendToPA Y/N

Onglet 1 — Identity

L'onglet Identity porte les acteurs émis sur chaque bundle de rapport. Les deux blocs sont rendus comme éléments XML à l'intérieur de l'enveloppe AFNOR XP Z12-014 (<Sender> et <Issuer>).

Sender (PA)

ChampDéfautDescription
MatriculeMatricule PA (4 caractères), émis comme <Sender><Id schemeId="0238">.
NameOptionnel. Émis comme <Sender><Name>.
Role CodeWKDéfaut WK (PA). Émis comme <Sender><RoleCode>.

Issuer (Déclarant)

ChampDéfautDescription
Identifier (SIREN)Identifiant du déclarant émis comme <Issuer><Id schemeId="0002">.
NameOptionnel. Émis comme <Issuer><Name>.
Scheme ID0002Schéma ICD ISO 6523. Défaut 0002 (SIREN France).
Role CodeSESE pour la déclaration des ventes (défaut), BY pour la déclaration des achats.
Companies (kco) override(vide)Liste de sociétés à traiter, séparées par virgule. Vide = détection auto à partir des factures et des templates de surcharge par société.

Onglet 2 — Reporting

Business Process (B2BINT uniquement)

Ces champs sont émis sur les éléments <BusinessProcess> par facture, uniquement pour les factures B2BINT.

ChampDescription
Business Process IDOptionnel. TT-28 cadre de facturation (par exemple B1, P1).
Business Process Type IDOptionnel. Identifiant de spécification TT-29.
Flow NameOptionnel. TT-2 émis comme <ReportDocument><Name>.

Schedule & Flux

ChampDéfautDescription
FrequencyMONTHLYPilote la période auto-calculée par le scheduler et le défaut de la modale Generate.
Flux10.1,10.3Codes flux séparés par virgule. Défaut couvre Flux 10.1 (détail B2BINT) et Flux 10.3 (B2C / OUTOFSCOPE agrégé).
Default Type CodeINCode de type de rapport par défaut.

Onglet 3 — PA Connection

api-connecteur

Le transport HTTP de la PA — flux d'authentification, base URL, endpoints — vit dans un api-connecteur réutilisable. L'E-Reporting choisit son propre connecteur au lieu de partager celui réglé sur l'E-Invoicing, ce qui permet de cibler une plateforme différente — ou des identifiants différents sur la même plateforme — par rapport à l'import de factures.

ChampDescription
ConnectorListe déroulante des templates api-connector. Choisir un connecteur différent d'e-invoicing quand le flux de reporting passe par une plateforme distincte ou utilise des identifiants distincts. Modifier le connecteur lui-même sous Connecteurs API.

Surcharge d'endpoint par tâche

ChampDéfautDescription
Report importreport-importNom d'endpoint sur le connecteur choisi pour la soumission du rapport. Vide = utilise le défaut.

Connection

ChampDéfautDescription
Timeout (ms)30000Timeout des requêtes HTTP en millisecondes. Les soumissions trop longues sont annulées au-delà.
SSL VerifytrueValidation du certificat TLS de la PA. À positionner sur false uniquement en environnement de non-production avec des certificats auto-signés.

Onglet 4 — FTP/SFTP

Send Mode

ChampValeursDescription
Send Mode (paMode)API (défaut) / FTP / (vide)Transport utilisé pour soumettre les rapports générés à la PA. API route le bundle via l'api-connecteur choisi sur l'onglet précédent ; FTP écrit le XML dans un fichier temporaire et le pousse en SFTP via le serveur ci-dessous ; (vide) permet à NomaUBL de générer les rapports sans les soumettre — utile pour valider l'identité et le choix des flux avant d'impliquer la PA.

Le champ paMode remplace l'ancien drapeau sendToPA Y/N en 2026.05.8. Mêmes sémantiques, un seul champ, cohérent avec l'E-Invoicing.

SFTP Server

La carte entière est atténuée quand Send ModeFTP — ces champs ne s'appliquent qu'au transport SFTP.

ChampDescription
HostHôte SFTP (par exemple ftp.plateformeagree.fr).
PortPort SFTP. Défaut 22.
UserUtilisateur SFTP.
PasswordMot de passe SFTP.
Outbound DirRépertoire distant où NomaUBL dépose les bundles de rapport pour la PA (par exemple /out/reports/).
Inbound DirRépertoire distant où la PA écrit les accusés (par exemple /in/reports/).

Vérification de configuration

La vérification de configuration sur le Tableau de bord IT valide le template selon la nouvelle forme :

  • paMode=API sans connector est signalé comme erreur (le transport API n'a rien à appeler).
  • paMode=FTP sans paFtpHost est signalé comme erreur (le transport SFTP n'a pas de serveur).
  • paMode= (vide) avec un connector est valide — les rapports sont générés localement et ne sont pas soumis.
  • issuerSiren, frequency et flux sont validés dès que paMode est non vide (le bundle sera effectivement soumis).

L'ancien contrôle sendToPA=Y / issuerSiren est retiré — remplacé par les règles par paMode ci-dessus.


Conseils & bonnes pratiques

  • Choisir un api-connecteur distinct quand la plateforme de reporting diffère. Les installations multi-plateforme ont souvent l'e-invoicing sur une PA et l'e-reporting sur une autre — c'est précisément pour cela que chaque template système porte sa propre référence de connecteur. Choisir le même nom des deux côtés quand ils partagent la même plateforme.
  • Démarrer en paMode= (vide) lors du câblage d'une nouvelle société. NomaUBL génère le rapport localement, ce qui permet de valider l'identité et le choix des flux contre un échantillon sans toucher la PA. Basculer sur API une fois le bundle correct.
  • N'utiliser SFTP que quand la PA impose un dépôt fichier. La soumission REST est plus simple à diagnostiquer et fonctionne avec le panneau de test de l'api-connecteur ; SFTP convient pour des soumissions à fort volume ou quand la PA n'expose pas d'endpoint REST report-import.
  • Les surcharges par société se trouvent sur e-reporting-{kco}. Copier le template e-reporting platform-wide sous le nouveau nom depuis Paramètres et ne modifier que les champs qui diffèrent — typiquement issuerSiren, la référence connector ou les identifiants SFTP quand la société 00070 déclare via une autre plateforme.
  • La cadence pilote la période auto-calculée. La régler sur MONTHLY fait émettre par le scheduler un bundle par mois couvrant le mois précédent ; QUARTERLY étend la fenêtre. La modale Generate permet toujours à l'utilisateur de surcharger la période à l'exécution.
  • Le champ Companies (kco) override est rarement nécessaire. NomaUBL détecte automatiquement les sociétés à partir des factures qu'il traite et de l'existence des templates e-reporting-{kco}. Renseigner le champ manuellement uniquement quand la déclaration doit être limitée à un sous-ensemble (par exemple une division pendant un déploiement progressif).