Défis mettant en œuvre la norme EN16931
Maintenant, la norme EN16931 est complètement publiée: Le modèle de données sémantiques est fixe, les syntaxes pour l’implémentation sont définies. La correspondance entre les termes métier (sémantique) et la technologie (syntaxe) est définie.
Grâce à la publication au journal officiel de la Commission européenne, les dates de l’opération en direct sont également claires. Ainsi, la mise en œuvre devrait être facile maintenant, penserait-on. Mais malheureusement ce n’est pas le cas. Les documents techniques laissent quelques questions ouvertes, en particulier pour les listes de codes. Et cela peut conduire à des défis non négligeables lors de la mise en œuvre.
Liste de codes peu claire
Cela commence par l’un des éléments les plus importants: le code pour identifier le type de document. Dans le modèle de données sémantiques, toutes les valeurs de la liste de codes UNTDID 1001 sont autorisées, ce qui représente les factures, les corrections de facture ou les notes de crédit. Cependant, ils ne sont pas mentionnés dans le modèle de données sémantiques, ni dans les documents cartographiques. Pour le moment, il est seulement possible de spéculer quels codes sont réellement valides. Si l’on regarde dans la liste de codes UNTDID 1001, un grand nombre de valeurs de code possibles sont prises en compte. Certains d’entre eux sont incontestables: 380 pour l’incoive régulière, 381 pour une note de crédit. Au moins, si ce dernier n’est pas présenté comme une facture négative. C’est le cas de ZUGFeRD 1.0, ainsi que de certains États membres européens (par exemple les Pays-Bas).
Pour les autres codes, la mise en œuvre est plus difficile. Ils impliquent souvent des processus différents. Le système de réception doit le supporter lorsque, par exemple, il reçoit la facture pro forma ou une facture qui ne contient que de la TVA.
Les artefacts de validation aident-ils ici?
Les artefacts de validation mentionnés dans les documents techniques pourraient fournir une indication de la mise en œuvre. Ceci est un paquet de fichiers schematron. Avec leur aide, les instances XML peuvent être vérifiées par rapport à un ensemble de règles métier. Outre les tests de la structure et des règles métier définis dans le modèle de données sémantiques, ces tests incluent également l’application correcte des codes techniques. La source de ces artefacts de validation est référencée sur le serveur FTP du CEN, mais il n’y a pas de fichiers à ce jour.
Liste de codes non définie
Un autre défi dans la mise en œuvre est que le modèle de données sémantique se réfère à deux listes de codes, qui n’existent pas encore. Une liste de codes pour qualifier une adresse électronique (par exemple, une adresse e-mail, une page Web, etc.) et une liste de codes pour définir les raisons des exceptions à la TVA. Bien qu’il existe déjà des organisations individuelles ou des groupes d’utilisateurs, qui ont développé leurs propres définitions. Pour les deux listes de codes, ce n’est pas le cas, car la norme renvoie à une définition du projet européen «Connecting Europe Facility», qui n’existe pas. Il est donc déjà prévisible que les documents nécessitent une mise à jour ou au moins une clarification.
Cependant, un tel processus de mise à jour dans le cadre de la normalisation est long. En règle générale, il nécessite des phases de commentaire et d’assurance qualité, pour lesquelles une durée minimale est prévue. Ainsi, la publication à court terme est à peine à prévoir.
Approche pragmatique de la mise en œuvre
Comment devrait-on procéder le mieux? L’attente est en fait hors de question, car les délais d’exécution sont déjà en cours. Le vrai défi pour la mise en œuvre n’est pas la mise en œuvre technique, mais les processus des pouvoirs adjudicateurs publics doivent être adaptés efficacement. Ce n’est qu’alors que les factures électroniques peuvent être reçues et traitées efficacement et sans rupture de support.
En ce qui concerne les codes, nous devrions commencer par des cas simples: pour le type de document, par exemple avec les types standard 380 et 381, ainsi que 389, si un avoir doit être mis en œuvre selon la méthode du crédit facture émise). L’absence de liste de codes pour les exonérations de TVA est peu attrayante, mais dans la plupart des cas, elle n’est pas indispensable car les quelques systèmes peuvent désormais traiter tous les cas envisagés par la législation européenne et leur mise en œuvre nationale. L’énoncé de la raison de l’exception sous une forme lisible par l’homme appuie le comptable, qui doit ensuite corriger manuellement le cas d’imposition correct.
Seul l’absence de liste de codes pour la qualification des adresses électroniques peut conduire à des défis dans la pratique. Cela est particulièrement vrai lorsqu’un système est utilisé pour transférer les factures électroniques qui utilisent exactement ce champ pour identifier les systèmes techniques d’expédition et de réception. En règle générale, ces systèmes ont leur propre liste de codes à cet effet, mais l’aspect de la normalisation ne s’applique pas. Dans le pire des cas, l’expéditeur devra maintenir plusieurs codes à cet effet. Cependant, les systèmes de comptabilité doivent également soutenir cela, selon le destinataire. On espère donc que des précisions seront apportées dès que possible.
