Meilleure interopérabilité et pas d’extensions purement nationales. Ainsi, l’eFacture doit conduire son triomphe de l’administration publique en Europe à l’économie. Ainsi l’idée des pères de l’EN16931 avant. Après la publication, la question se pose de savoir pourquoi il était non seulement possible de convenir d’une syntaxe pour la mise en œuvre, car cela aurait été plus facile à mettre en œuvre. Ce raisonnement initialement très logique est toutefois trop bref. L’échange électronique de factures n’est pas un problème nouveau. Du moins pas pour tous les acteurs du marché en Europe. Pendant des décennies, divers processus ont été mis en place dans l’économie, en particulier l’EDI, en particulier sur la base de l’UN/EDIFACT. Cette norme mondiale est la norme la plus largement utilisée dans le monde des affaires.
Cependant, pas par les pouvoirs adjudicateurs. De nombreux pays européens ont utilisé une norme basée sur XML dans le domaine B2G avec UBL. En particulier en France et en Allemagne, le CrossIndustryInvoice a pris de l’ampleur ces dernières années, notamment grâce au format ZUGFeRD. Aux Pays-Bas, les fleurs et les produits agricoles sont également échangés principalement sur la base du CrossIndustryInvoice. A cet égard, l’économie est encore très en avance sur l’administration au niveau européen.
Cependant, l’EN16931 et la directive associée s’adressent en particulier aux pouvoirs adjudicateurs en tant que destinataires des factures. Par conséquent, lorsqu’on discute du nombre de syntaxes, le coût global de la combinaison de la norme et de la législation doit également être pris en compte. Le mélange et l’avantage de l’économie, qui existe encore dans de nombreux pays, ont donc une influence décisive sur la décision: puisque l’EDIFACT / ONU n’a guère été utilisé dans l’administration, l’économie est une norme importante d’échange de données, la norme prend également en compte cette syntaxe. Le document CEN / TS 16931-3-4 définit donc l’illustration technique du modèle de données sémantiques dans UN / EDIFACT. Cependant, cette syntaxe n’est pas obligatoire, mais peut être maintenue ou ré-implémentée sur une base volontaire.
Si j’envoie seulement les éléments obligatoires, j’ai moins à faire!?
Avec la définition de la norme maintenant tout est clair, d’autant plus que ce ne sont que les éléments de base d’une eFacture. Tout simplement, ce n’est pas si facile. Selon le modèle de données sémantiques, seuls quelques éléments sont obligatoires. Si l’on laisse de côté les aspects légaux et les règles commerciales, voir une facture électronique, qui ne contient que les données obligatoires, très légère.
Version corrigée incluant la date d’émission.
Ces données sont loin d’être suffisantes pour l’objectif du traitement automatisé, et en particulier de l’audit, sans parler de l’obscurité. Cependant, d’un autre côté, tous les destinataires n’ont pas besoin de toutes les fonctionnalités disponibles fournies par le modèle de données sémantiques. Pour résoudre ce dilemme, la norme fournit l’idée de la spécification d’utilisation de base de la facture. Il est destiné à permettre au récepteur eFacture de définir lequel des éléments facultatifs dont il a besoin pour le traitement automatisé de la facturation.
Et ce n’est pas nouveau en soi. Seul le terme CIUS est nouveau. Dans le cas de la normalisation, le concept d’application est généralement utilisé à cette fin. Il est destiné à aider le payeur quelles sont les informations dont le destinataire de la facture a besoin au-delà des données obligatoires (modèle de données et taxe). De telles recommandations d’application existent à ce jour pour certains groupes d’utilisateurs, ainsi que pour les grands destinataires de factures. Le noyau de ces recommandations consiste, dans la plupart des cas, à établir un lien technique entre le fichier de facturation et le système du destinataire. Des éléments typiques pour cela sont, par exemple, le numéro de commande, le numéro de contrat, une référence de caisse ou un autre numéro de transaction. Sur une facture papier, un tel champ est souvent étiqueté « Votre référence ».
Un autre aspect d’une recommandation d’application est généralement de définir quelles valeurs des listes de codes peuvent être traitées côté récepteur. Par exemple, la liste des unités de quantité possibles contient plus de 2000 valeurs différentes. En outre, la norme prend en charge plus de 40 types de documents différents, qui peuvent représenter des variantes de la facture ou de la note de crédit.
Plus ou moins d’interopérabilité de l’eFacture grâce au CIUS
Mais c’est précisément là que le défi commence avec l’interopérabilité. En quoi cela signifie-t-il en pratique si un destinataire de facture rejette une facture parce qu’il ne peut pas traiter un type de document particulier? Ensuite, l’expéditeur de la facture devra probablement le déposer dans son système. L’interopérabilité vient de décliner, car les systèmes doivent soudainement différer entre différents destinataires de facturation. Un exemple de ceci est la discussion sur l’envoi ou non d’une correction de facturation avec le type de document 381 – Credit note ou 380 – Invoice avec des totaux négatifs. La norme autorise explicitement les deux possibilités. Par exemple, les Pays-Bas n’envoient aujourd’hui que des factures négatives à cette fin. Dans d’autres pays, cependant, les notes de crédit sont courantes.
Maintenant, si les Pays-Bas doivent créer un CIUS qui limite la liste de codes correspondante afin qu’aucune instance de note de crédit ne soit autorisée, mais qu’un autre État membre n’autorise pas l’utilisation du compte négatif, il n’y a plus d’interopérabilité. Lors de l’échange de factures entre ces deux pays, une conversion est obligatoire.
Dans la définition du CIUS, la norme prévoit également une autre restriction possible qui réduit l’interopérabilité. L’interdiction explicite d’envoyer des éléments optionnels. L’utilisation de cette option signifie qu’un nouveau canal pour l’envoi des factures est obligatoirement créé pour ce groupe de destinataires et que le coût de la mise en œuvre augmente.
Recommandation sur l’utilisation de CIUS
L’idée de base de CIUS est exceptionnelle. En pratique, seul un CIUS permet réellement le traitement automatisé des factures lors de la mise en œuvre de la norme EN16931. Un CIUS offre la possibilité de définir, à un emplacement central, les informations dont un groupe de récepteurs a besoin pour un traitement automatisé. En particulier, l’utilisation d’éléments génériques pour la transmission technique de ces valeurs d’affectation augmente considérablement l’interopérabilité. Dans ce cas, l’implémentation technique est séparée des exigences techniques. Par exemple, si un groupe de destinataires nécessite un centre de coûts, le second un ID de routage et le troisième un numéro de transaction, il n’est pas nécessaire de définir trois implémentations techniques différentes. Par exemple, les trois informations peuvent être soumises dans le champ BuyerReference. L’interprétation de la valeur définit le destinataire. Dans des circonstances normales, le destinataire transmet les informations à donner au fournisseur de facture au moment de la commande.
En principe, le CIUS offre également une possibilité supplémentaire de traiter des informations inutiles. Il existe une alternative à l’interdiction des éléments facultatifs inutiles. Si un CIUS clarifie clairement et de manière transparente que ces informations sont ignorées pendant l’audit et le traitement, cela ne limite pas l’interopérabilité. L’expéditeur n’a pas besoin de reconfigurer son logiciel, mais peut envoyer la même structure à tous les destinataires de facturation.
Perspectives pour les traducteurs et les facturiers
Si autant de prescripteurs d’un CIUS approchent ces recommandations, la complexité de la mise en œuvre est considérablement réduite. Cependant, un défi demeure. En règle générale, un destinataire de facture n’a besoin que de 20 à 25 informations pour traiter une facture automatiquement: environ 15 informations pour les données obligatoires (taxables) et le reste en fonction des processus comptables respectifs. Et précisément, ces exigences changent du groupe de destinataires au groupe de destinataires. Pour une mise en œuvre plus simple, cependant, ils ne devraient pas être définis individuellement, si possible dans une association, ou au niveau du pays. Cependant, il est déjà clair aujourd’hui que le nombre de CIUS en Europe augmentera fortement. Un accès central à une telle information est donc particulièrement souhaitable.