Intégration

SAP ECC6 / S/4 → UBL EN16931 : mapping et preflight avant PA

Mis à jour le 5 min de lecture Par FacturX API

Transformer les pièces SAP SD/FI en UBL EN16931 : nœuds utiles, écarts ECC6 vs S/4, PDF joint, contrôles avant remise. Preflight documentaire, pas un connecteur PA.

Votre ERP SAP sait déjà facturer. Le trou n’est pas « comment créer une facture » : c’est produire un UBL EN16931 que votre chaîne aval peut valider avant la remise à une plateforme. Les données sont dans SD/FI ; la syntaxe UBL et les Business Terms sont ailleurs.

Cet article décrit un mapping documentaire et un preflight fichier. Ce n’est pas un connecteur Plateforme Agréée, pas un add-on d’émission Chorus, pas un jugement réglementaire. Les versions d’artefacts côté runtime FacturX API se lisent sur GET /meta — ne pas inventer un numéro de pack non exposé.

En bref

  • UBL EN16931 est un binding syntaxique du même modèle sémantique que CII ; SAP ne « parle » ni l’un ni l’autre nativement.
  • Les nœuds utiles viennent surtout de la pièce de facturation SD/FI (entête, partenaires, lignes, taxes, conditions).
  • ECC6 et S/4HANA ne cassent pas au même endroit : partenaires, unités, références externes.
  • Le PDF lisible et le XML UBL sont deux livrables ; les confondre crée des rejets « fichier » alors que le métier est correct.
  • Un preflight documentaire (XSD + Schematron + totaux) avant remise évite de découvrir le BR-* chez le destinataire.

Quels nœuds SAP alimentent un UBL EN16931

Pensez en Business Terms, pas en tables. Une facture UBL a besoin au minimum de :

Besoin EN16931 (idée)Sources SAP typiquesRisque fréquent
Identifiant + date + type docVBRK / facture SD, type de factureType UNTDID 1001 mal mappé (380 vs 381)
Vendeur / acheteurPartenaires AG, RE, RG, WESIRET/TVA absents ou schemeID incorrect
LignesVBRP + conditionsQuantité / unité UNECE manquante
Totaux et TVAVentilation fiscaleÉcart ligne ↔ totaux (BR-CO-*)
RéférencesCommande, contrat, BLChamps présents en FI mais absents du XML

Le mapping n’est pas « exporter IDoc → fichier ». C’est une projection déterministe : chaque BT a une règle, un format (dates ISO, décimaux point), une cardinalité.

Pour un autre chemin (JSON ERP → CII Factur-X), voir Données ERP → Factur-X CII. Ici la cible est UBL, pas le conteneur PDF/A-3 Factur-X.

ECC6 vs S/4 : où le mapping casse

Trois familles de divergences reviennent en intégration :

  1. Partenaires et BP — S/4 unifie davantage les Business Partners ; ECC6 laisse des trous (adresse incomplète, identifiant fiscal sur un partenaire « fantôme »).
  2. Unités et matériaux — codes unités internes ≠ codes UNECE attendus en UBL (C62, HUR…). Un convertisseur d’unités doit être explicite dans le mapping, pas « magique ».
  3. Références croisées — numéros de commande acheteur, comptes analytiques : utiles métier, parfois hors modèle EN16931. Les garder en extensions non standard casse l’interopérabilité.

Si votre flux SAP → Chorus ou SAP → UBL existe déjà via un add-on historique, ne le confondez pas avec ce guide : l’add-on résout un canal ; ce texte résout la qualité du fichier UBL avant n’importe quel canal.

Pièces jointes et lisible vs XML

Deux objets distincts :

  • XML UBL — la vérité machine (totaux, parties, lignes).
  • PDF lisible — la vérité humaine pour archivage / litige.

Les coller dans le même message sans politique claire produit des tickets du type « le PDF dit 1200 €, l’XML dit 1199,98 € ». Décidez une source de vérité pour les montants (en pratique : le XML validé) et générez le PDF depuis les mêmes totaux — ou acceptez un écart documenté, mais ne le laissez pas implicite.

Factur-X (PDF/A-3 + CII) est un autre conteneur. Voir Factur-X vs UBL vs CII.

Contrôles documentaires avant remise

Avant de pousser le fichier vers une PA, un EDI ou un partenaire :

  1. XSD UBL — le document parse.
  2. Schematron EN16931 — les BR-* métier (totaux, TVA, parties).
  3. Cohérence arithmétique — somme des lignes = totaux document.
  4. Identifiants — schemeID SIRET / TVA / GLN cohérents avec le pays.
  5. Jeu de fixtures — au moins une facture standard, un avoir, une multi-taux.

Le détail des contrôles type « avant PA » côté Factur-X est dans Scanner avant envoi PA. Pour UBL pur, le même réflexe s’applique : preflight fichier.

Diff UBL vs Factur-X CII pour un flux déjà Chorus

Si votre historique est « SAP → Factur-X / Chorus », vous avez peut-être déjà un CII correct. Passer à UBL n’est pas recopier les balises : c’est re-binder les mêmes BT vers cbc: / cac:. Pièges classiques : namespaces, structure des parties, codes unités et schemeID.

Jeu de fixtures à figer pour un Sprint

  1. Facture mono-taux EUR, deux lignes, SIRET vendeur + acheteur.
  2. Facture multi-taux (ex. 5,5 % + 20 %).
  3. Avoir (type 381) qui référence la facture d’origine.
  4. Cas partenaire incomplet (doit échouer le preflight).
  5. Cas unité interne non mappée UNECE (doit échouer).

Versionnez les XML attendus. Ajoutez un job CI qui reste rouge sur les mutants. Voir Valider en CI GitHub Actions.

Limites assumées

  • Pas de conseil sur quelle PA choisir, ni sur un calendrier d’obligation.
  • Pas de connecteur SAP certifié décrit ici.
  • Les packs réellement exécutés par FacturX API : preuve /meta.

Équipe FacturX API

Continuer la lecture

Étape suivante recommandée

Vous avez un export SAP et vous voulez un UBL contrôlé avant remise.

Voici ce que vous allez obtenir :

  • Figer 5 fixtures (dont 2 mutants)
  • Mapper parties + unités UNECE en priorité
  • Ajouter un job CI sur les XML UBL
  • Lire le comparatif Factur-X / UBL / CII
#SAP #UBL #EN16931 #mapping #ECC6 #S/4HANA #preflight