3 Termes et définitions

Pour les besoins du présent document, les termes et définitions suivants s’appliquent.

Interface de programmation applicative, un ensemble normalisé de classes, méthodes, fonctions et constantes permettant à un logiciel d’offrir des services à d’autres logiciels;

L’API standardisé du présent document est une API qui respecte le protocole REST. Une API REST (Representational State Transfer) ou RESTful est un type d’API, ou interface de programme d’application, qui aide les applications de services web à communiquer entre elles. Bien qu’elle soit théoriquement compatible avec n’importe quel protocole ou format de données, l’architecture REST utilise le plus souvent le protocole HTTP et transfère les données en utilisant majoritairement le JSON (JavaScript Object Notation). Une API REST liste un ensemble de « Routes » qui permettent au Client API d’agir;

L’ensemble des API mises à dispositions du Fournisseur API qui sont dans le domaine d’application du présent document.

L'authentification via un ‘bearer’ est un schéma d'authentification HTTP qui faisait à l'origine partie de la RFC 6750 : « The OAuth 2.0 Authorization Framework-Bearer Token Usage »; Le terme ‘bearer’ peut s’interpréter comme « donner accès au porteur de ce jeton ». Le jeton du porteur est une chaîne cryptée, généralement générée par le serveur du Fournisseur API en réponse à une requête de connexion. Le Client API doit l’envoyer dans l’en-tête d’autorisation lorsqu’il adresse des requêtes à des ressources protégées.

L’Organisation qui consomme l’API mis à disposition par le Fournisseur API via un Compte API.

Note 1 au 3.6 : Le Client API sera le plus souvent une Entreprise ou une SC.

Compte avec un identifiant et un mot de passe (ou équivalent) permettant au Client API de se connecter à l’API publiée par le Fournisseur API.

Une facture constituée dans les formats du socle est un seul fichier :

Un flux facture dans ce document est donc constitué d’une et une seule facture telle que décrite ci-dessus.

Les Flux nomment les différents types de messages échangés dans le cadre de la réforme :

Dans le cadre de l’API standardisée, un flux correspond à un et un seul ‘flowId’.

Les formats et profils du socle sont les formats de données structurées ou mixtes qui doivent être supportés dans le cadre de la Réforme Facture Électronique, qui implémentent la Norme EN 16931.

D’une part, trois formats constituent ce socle pour le message Facture, et implémentent chacun 2 profils de données :

Ces 2 profils sont implémentés dans 2 syntaxes (UBL et UN/CEFACT CII) et dans le format mixte Factur-X, plus précisément :

D’autre part le format de statuts de cycle de vie est implémenté dans la syntaxe UN/CEFACT CDAR (Cross Domain Acknowledgement and Response), et fait aussi partie des formats et profils du socle minimum.

L’organisation qui met à disposition l’API standardisée;

Note 1 au 3.11 : Le fournisseur API sera le plus souvent une PA mais pourra également être une SC.

Fichier XML décrivant un flux 10 de E-reporting. Le Format XML est celui décrit par la DGFIP dans les spécifications externes

Les opérateurs offrant des services de dématérialisation des factures mais qui ne sont pas immatriculés par l’administration; Ces opérateurs ne peuvent pas transmettre directement les factures électroniques relevant du périmètre « e-invoicing » à leurs destinataires ni transmettre de données au portail public de facturation, mais peuvent agir au nom et pour le compte de l’entreprise auprès des plateformes de leur choix (y compris ChorusPro).

Note 1 au 3.13 : Les SC sont par exemple des solutions de gestion, des ERP, des plateformes de Purchase to Pay ou d’Order to Cash, des solutions EDI, des solutions bancaires, de refinancement de factures, de carte d’achat < Ayant à intervenir sur le périmètre facture (soit en création, soit en intégration, validation, paiement, ...).

Plateforme Agréée (PA) : Plateforme de facturation électronique au travers de laquelle les factures électroniques entre assujettis à la TVA et relevant du périmètre « e-invoicing » de la Réforme Facture Électronique doivent être échangées, ainsi que les données de « e-reporting » de factures B2B internationales hors import de biens, de transaction et de paiement.

Note 1 au 3.14 : Les Plateformes Agréées peuvent aussi proposer des services qui relèvent d’une SC.

Plateforme Agréée en position d’émission de factures électroniques;

Plateforme Agréée en position de réception de factures électroniques.

Plateforme publique qui administre l’Annuaire des assujettis soumis à la réforme d’une part et le Concentrateur des Données (CdD) d’autre part, qui concentre les données de facturation, de transaction et de paiement ainsi que des informations relatives aux statuts de traitement des factures (cycle de vie) exigées par l’Administration fiscale, et les transmet à l’administration fiscale.

Un webhook, aussi appelé lien de rappel HTTP ou point d’ancrage Web, est en programmation Web une méthode permettant d’accroître ou de modifier le comportement d’une page Web ou d’une application Web avec des fonctions de rappels personnalisées. Ces fonctions peuvent être modifiées et gérées par des utilisateurs et développeurs tiers qui ne sont pas nécessairement affiliés au site Web ou à l’application d’origine. Le terme « webhook » a été inventé par Jeff Lindsay en 2007 à partir du terme de programmation informatique hook[2].

Le format est généralement le JSON. La requête est effectuée comme une requête HTTP POST.

XML Schema, publié comme recommandation par le W3C en mai 2001, est un langage de description de format de document XML permettant de définir la structure et le type de contenu d’un document XML. Cette définition permet notamment de vérifier la validité de ce document.

Une définition se compose d’un ou plusieurs documents XML, usuellement nommée (XML Schema Definition en anglais, ou fichier XSD).