Mais ils sont obligatoires!

Cette information est définie comme obligatoire dans la documentation. Il doit apparaître dans la facture! Ou pas? Cette question m’a paru plus souvent ces derniers temps. Souvent, la plupart des documents de factures électroniques ne sont pas simplement une liste d’informations, mais des données structurées.

Structures de données hiérarchiques

Dans les structures de données hiérarchiques, les informations sont généralement groupées en unités logiques. Par exemple, une adresse peut être une rue, un code postal, une ville et un pays. Tous ces éléments sont ensuite combinés en une « adresse » d’unité. Cependant, les adresses ne sont pas seules sur les factures, mais appartiennent généralement à un partenaire commercial qui peut être trouvé à cette adresse. Un partenaire est généralement décrit par son nom et son adresse. D’autres informations possibles sont, par exemple, son numéro de TVA. La combinaison de ces trois informations forme alors le partenaire commercial. Une facture contient généralement au moins deux partenaires commerciaux, l’acheteur et le vendeur. C’est exactement ainsi qu’une structure d’information arborescente apparaît: une structure de données hiérarchique.

Cardinalités

La documentation technique et les modèles de données définissent souvent la répétition de l’information individuelle, la cardinalité dite. Il est souvent spécifié au format x..y. Où x est la fréquence minimale et y est la fréquence maximale. Cette information se réfère à la documentation technique. Par exemple, un modèle de données ou une syntaxe basée sur XML. Des règles métier clairement définies fournissent généralement la base pour définir des cardinalités. Cependant, chaque cardinalité n’a pas forcément de règle métier. Les valeurs typiques pour les cardinalités sont

• 0..1 L’information est facultative. Il peut être omis. S’il est spécifié, il peut être spécifié au maximum 1 fois. Un exemple de cette cardinalité est la spécification du numéro de l’ordre associé. Si ce n’est pas le cas, le champ d’information n’a pas besoin d’être transmis.
• 1..1 L’information est obligatoire. Cela ne doit pas être oublié. S’il est spécifié, il peut être spécifié au maximum 1 fois. Un exemple de ceci est le numéro de facture.
• 0..n ou 0..unbounded L’information est facultative. Il peut être omis. Si spécifié, il peut être spécifié aussi souvent que vous le souhaitez. Le texte libre d’une facture est généralement intégré de cette manière. Il n’y a pas de contrainte pour spécifier du texte libre. Cependant, n’importe quelle quantité de texte peut être transmise.
• 1..n ou 1..unbounded L’information est obligatoire. Cela ne doit pas être oublié. Si spécifié, il peut être spécifié aussi souvent que vous le souhaitez. La partie article d’une facture a généralement cette cardinalité. Une facture nécessite la spécification d’au moins un service ou produit à facturer.

Déclaration d’état

Contrairement aux cardinalités techniques, des informations d’état supplémentaires sont souvent ajoutées aux documentations. Ceci est notamment utilisé dans les recommandations d’application. Ceci définit l’application d’une norme technique pour un groupe spécifique de destinataires. Pour un traitement optimal des factures électroniques, certaines informations peuvent être requises, ce qui n’est qu’optionnel dans la norme technique. En pratique, ces informations sont souvent définies comme une indication obligatoire permettant l’attribution unique d’une facture dans le système destinataire. Ce peut être, par exemple, le numéro de commande, un numéro de transaction ou une caisse enregistreuse. Les informations typiques d’un statut dans une documentation sont

O Facultatif. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) La recommandation d’utilisation ne fait aucune déclaration à propos de cette information. La cardinalité est préservée.
N Non utilisé. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) La recommandation d’utilisation interdit la transmission de cette information. Techniquement, cela correspondrait à la cardinalité 0..0. Dans ce statut, il convient de noter que cela limite l’interopérabilité d’une norme. Voir aussi ici.

 

• R Required. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) L’information est requise pour le traitement dans le système récepteur. Techniquement, cela correspond à une cardinalité de 1..y.
• A Adviced. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) L’information est nécessaire pour certains destinataires du groupe. Pour faciliter la mise en œuvre, cette valeur doit être incluse dans la mesure du possible.
• D Dependent. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) Si l’information est nécessaire dans le système récepteur dépend d’une condition. Cette condition doit être clairement définie dans la recommandation d’application. Un exemple est la possibilité d’entrer un numéro de taxe national au lieu d’un numéro de TVA. L’information dépend du type et du lieu de livraison et de service.
• O Optional. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) La recommandation d’utilisation ne fait aucune déclaration à propos de cette information. La cardinalité est préservée.
• N Not used. La norme technique a une cardinalité optionnelle. (par exemple, 0..1) La recommandation d’utilisation interdit la transmission de cette information. Techniquement, cela correspondrait à la cardinalité 0..0. Dans ce statut, il convient de noter que cela limite l’interopérabilité d’une norme. Voir aussi ici.

Eléments obligatoires dans les structures hiérarchiques

Uff. C’était beaucoup d’informations. Par conséquent, abordons maintenant la question de savoir pourquoi certaines informations peuvent être omises, même si elles sont définies comme champ obligatoire 1..1.

Dans l’image pour ce poste, un arbre est visible. Cet arbre a des branches et des feuilles sur chaque branche. Par souci de simplicité, je suppose que les feuilles ne poussent que directement sur les branches. L’arbre a besoin des feuilles pour vivre. Les feuilles de l’arbre sont donc nécessaires à sa pérennité. J’ai donc défini une règle selon laquelle chaque branche doit avoir au moins une feuille. Cependant, je peux aussi couper toutes les branches. Ensuite, la règle ne fonctionne plus.

 

 

Un exemple dans la facture pour cela est la spécification d’une adresse de livraison différente. Toutes les factures n’ont pas une adresse de livraison différente. Cependant, chaque adresse nécessite un minimum d’informations (par exemple, pays, ville et code postal si nécessaire) pour s’assurer que les marchandises arrivent effectivement. De même, l’EN16931 spécifie les conditions de paiement. Dans le groupe BG-16 (Instructions de paiement), l’indication des moyens de paiement (carte de crédit, virement bancaire, etc …) est obligatoire. Cependant, le groupe entier peut être omis:

• BG-16 0..1 PAYMENTINSTRUCTIONS
  • BT-81 1..1 Payment means type code

De telles situations se produisent souvent dans des structures de données hiérarchiques. Dans le dernier exemple (méthode de paiement), il existe d’autres connexions dans la pratique. Ainsi, le choix d’un terme de paiement particulier peut entraîner la fourniture d’informations supplémentaires. Ainsi, la spécification de la méthode de paiement par prélèvement automatique SEPA n’a de sens que si les données requises telles que la référence du mandat et l’identifiant du créancier sont également transmises. C’est là qu’interviennent les règles commerciales supplémentaires, mais qui peuvent être discutées ailleurs.

J’attends d’autres questions, suggestions ou articles pour ce site!