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.
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 :
- Identity — champs d'identification Sender (PA) et Issuer (Déclarant) émis dans le bundle.
- Reporting — Business Process (B2BINT) et choix de la cadence et des flux.
- 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.
- 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 templatese-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
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)
| Champ | Défaut | Description |
|---|---|---|
| Matricule | — | Matricule PA (4 caractères), émis comme <Sender><Id schemeId="0238">. |
| Name | — | Optionnel. Émis comme <Sender><Name>. |
| Role Code | WK | Défaut WK (PA). Émis comme <Sender><RoleCode>. |
Issuer (Déclarant)
| Champ | Défaut | Description |
|---|---|---|
| Identifier (SIREN) | — | Identifiant du déclarant émis comme <Issuer><Id schemeId="0002">. |
| Name | — | Optionnel. Émis comme <Issuer><Name>. |
| Scheme ID | 0002 | Schéma ICD ISO 6523. Défaut 0002 (SIREN France). |
| Role Code | SE | SE 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.
| Champ | Description |
|---|---|
| Business Process ID | Optionnel. TT-28 cadre de facturation (par exemple B1, P1). |
| Business Process Type ID | Optionnel. Identifiant de spécification TT-29. |
| Flow Name | Optionnel. TT-2 émis comme <ReportDocument><Name>. |
Schedule & Flux
| Champ | Défaut | Description |
|---|---|---|
| Frequency | MONTHLY | Pilote la période auto-calculée par le scheduler et le défaut de la modale Generate. |
| Flux | 10.1,10.3 | Codes 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 Code | IN | Code 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.
| Champ | Description |
|---|---|
| Connector | Liste 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
| Champ | Défaut | Description |
|---|---|---|
| Report import | report-import | Nom d'endpoint sur le connecteur choisi pour la soumission du rapport. Vide = utilise le défaut. |
Connection
| Champ | Défaut | Description |
|---|---|---|
| Timeout (ms) | 30000 | Timeout des requêtes HTTP en millisecondes. Les soumissions trop longues sont annulées au-delà. |
| SSL Verify | true | Validation 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
| Champ | Valeurs | Description |
|---|---|---|
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 Mode ≠ FTP — ces champs ne s'appliquent qu'au transport SFTP.
| Champ | Description |
|---|---|
| Host | Hôte SFTP (par exemple ftp.plateformeagree.fr). |
| Port | Port SFTP. Défaut 22. |
| User | Utilisateur SFTP. |
| Password | Mot de passe SFTP. |
| Outbound Dir | Répertoire distant où NomaUBL dépose les bundles de rapport pour la PA (par exemple /out/reports/). |
| Inbound Dir | Ré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=APIsansconnectorest signalé comme erreur (le transport API n'a rien à appeler).paMode=FTPsanspaFtpHostest signalé comme erreur (le transport SFTP n'a pas de serveur).paMode=(vide) avec unconnectorest valide — les rapports sont générés localement et ne sont pas soumis.issuerSiren,frequencyetfluxsont validés dès quepaModeest 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 surAPIune 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 templatee-reportingplatform-wide sous le nouveau nom depuis Paramètres et ne modifier que les champs qui diffèrent — typiquementissuerSiren, la référenceconnectorou les identifiants SFTP quand la société00070déclare via une autre plateforme. - La cadence pilote la période auto-calculée. La régler sur
MONTHLYfait é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).