3 Termes et définitions

3 Termes et définitions

3 Termes et définitions Pour les besoins du présent document, les termes et définitions suivants s’appliquent. 3.1 API Interface de programmation applicative, un ensemble normalisé de classes, méthodes, fonctions et constantes permettantàun logiciel d’offrir desservicesàd’autres logiciels; 3.2 API REST 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; 3.3 API publiée par le Fournisseur API L’ensemble desAPI mises à dispositions du Fournisseur API qui sont dans le domaine d’application du présent document. 3.4 Bearer L`authentification via un ‘bearer’ estun schéma d`authentification HTTPquifaisaitàl`origine partie de laRFC 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. 3.5 BT ‘Business Term’au sens de la norme EN 16931 3.6 Client API L’Organisation quiconsomme l’API misàdisposition par le Fournisseur APIvia un Compte API. Note 1 au 3.6 : Le Client API sera le plus souvent une Entreprise ou un OD. 3.7 Compte API Compte avec un identifiant et un mot de passe (ou équivalent) permettantau ClientAPI de se connecteràl’API publiée par le Fournisseur API. 3.8 Facture constituée dans un format du socle Une facture constituée dans les formats du socle est un seul fichier : ⎯ Un fichier Factur-X ⎯ Ou un fichier XML (CII ou UBL) contenant en option : Le lisible et des pièces jointes encodées en base64. Un flux facture dans ce document estdonc constituéd’une et une seule facture telle que décrite ci-dessus. 3.9 Flux Les Flux nomment les différents types de messages échangés dans le cadre de la réforme : ⎯ Flux 2 : correspond au message facture échangé entre les entités soumises à la réforme et devant êtretransmis par l’intermédiaire de PA, et conforme aux dispositions du présent document. ⎯ Flux 3 : correspond au message facture échangé entre les entités soumises à la réforme et devant êtretransmispar l’intermédiaire de PA, MAIS qui est dans un format tiers convenu entre l’émetteur et ledestinataire et contient toutes les informations requises par l’Administration fiscale sous forme structurée et permet une extraction conforme des données pour la constitution du Flux 1 ou du Flux 10. ⎯ Flux 6 : correspond au message de statuts de cycle de vie relatif aux échanges de factures électroniques, implémenté en UN/CFACT CII. ⎯ Flux 8 : correspond au message facture échangé entre une entité soumise à la réforme et une entité internationale conforme aux dispositions du présent document. ⎯ Flux 9 : correspond au message facture échangé entre une entité soumise à la réforme un non assujetti établi en France (principalement un Particulier), conforme aux dispositions du présent document. ⎯ Flux 10 : correspond au message de « e-reporting » que les entités soumises à la Réforme Facture Électronique doivent transmettre au Concentrateur de Données par le biais de leur PA. ⎯ Flux 11 :correspond à laconsultation de l’annuaire desassujettis et de leursadressesde facturation électroniques. ⎯ Flux 12: correspondàla demande de misàjour de l’annuaireàsa PA pour ses adresses de facturation électroniques (identifiant d‘adressage) et sesCodes Routages/ Dans le cadre de l’API standardisée,un flux correspond à un et un seul‘flowId’. PA Formats et profils du socle minimum 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, troisformatsconstituentce socle pour le message Facture, et implémentent chacun 2 profils de données : ⎯ Profil EN 16931, qui une CIUS pour la France de l’implémentation de la Norme EN16931 ⎯ Profil EXTENDED-CTC-FR, quiestune EXTENSIONpour la France de l’implémentation de la Norme EN 16931 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 : ⎯ Syntaxe XML ISO/IEC 19845 (UBL 2.1) : le format UBL (Universal Business Language) est conforme à la norme OASIS U.B.L. 2.1. ⎯ Syntaxe UN/CEFACT CII. Le format CII (Cross Industry Invoice) est conforme à la norme UN/CEFACT SCRDM CII (Supply Chain Reference Data Model –Cross Industry Invoice). La version de langage retenue dans le cadre de la réforme est UN/CEFACT CII D22B. ⎯ Factur-X. Factur-X est un format de facture électronique hybride (ou mixte), combinant un fichier PDF conforme à la Norme ISO-19005-3 PDF/A-3 constituant la représentation LISIBLE de la facture dans lequel est attaché une représentation de données structurée factur-x.xml dans la syntaxe UN/CEFACT CII. Factur-X dispose de profils additionnels (MINIMUM, BASIC WL, BASIC et EXTENDED). D’autre part le format destatutsdecycle de vie estimplémentédansla syntaxe UN/CEFACTCDAR(Cross Domain Acknowledgement and Response), et fait aussi partie des formats et profils du socle minimum. 3.11 Fournisseur API L’organisation quimet à disposition l’API standardisée; Note 1 au 3.11 : Le fournisseur API sera le plus souvent une PA mais pourra également être un OD. 3.12 FRR Syntaxe FRR pour FRench Reporting 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 OD (Opérateurs de Dématérialisation) Les opérateurs offrant des services de dématérialisation des factures mais qui ne sont pas immatriculés par l’administration; Cesopérateursne peuventpastransmettre directementlesfacturesélectroniquesrelevant du périmètre « e-invoicing » à leurs destinataires ni transmettre de données au portail public de facturation, maispeuventagir au nomet pour le comptede l’entreprise auprèsdesplateformesde leur choix(ycompris ChorusPro). Note 1 au 3.13 : Les OD sont par exemple des solutions de gestion, des ERP, des plateformes de Purchase to Pay oud’Orderto Cash,dessolutionsEDI, dessolutionsbancaires,derefinancementdefactures,decarted’achat< Ayant à intervenirsurlepérimètrefacture(soitencréation,soit enintégration,validation,paiement, ...); Plateforme Agréée (ou PA), ex PDP (Plateforme de Dématérialisation Partenaire) 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 peuventaussiproposerdesservicesd’OD; 3.15 PAe (Plateforme Agréée Émettrice) Plateforme Agréée en position d’émission de factures électroniques; 3.16 PAr (Plateforme Agréée Réceptrice) Plateforme Agréée en position de réception de factures électroniques. 3.17 PPF (Portail Public de Facturation) Plateforme publique qui administre l’Annuaire des assujettis soumis à la réforme d’une part et leConcentrateur des Données(CdD) d’autre part, quiconcentre 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’Administrationfiscale,et lestransmet à l’administration fiscale. 3.18 Webhook 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. Source : Wikipedia 3.19 XML Schema / XSD 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). Source : Wikipedia PA