Préparer, intégrer ou exporter un message enveloppe (Accounting Message)
Le but de l’intégration est de préparer un message enveloppe XML pour qualifier une transmission depuis votre applicatif comptable et de permettre la réception des ce même message enveloppe produit par un partenaire d'échange.
Sommaire
Analyse des modèles de données
De façon plus générale, il est plus simple de préparer la transmission d'un message enveloppe que de gérer la lecture d'un message produit par ailleurs. Il vaut donc mieux commencer par l'écriture, l'export de données.
Après vous être familiarisé avec la syntaxe XML et les composants disponibles, la deuxième étape est d’analyser le modèle de données normalisé. Concentrez-vous, dans un premier temps, sur les données essentielles : une enveloppe réduite à sa plus simple expression (numéro de dossier, statut de test et au moins les caractéristique d'un message comptable).
Notez qu'une particularité du message enveloppe, par rapport aux autres messages normalisés, est qu'il est destiné à faciliter l'échange en fournissant des paramètres techniques ou organisationnels. Le message enveloppe ne véhicule pas de données strictement comptable mais plutôt le contexte d'expoitation des données comptables qui sont véhiculées dans les autres messages comptables. Par exemple, il reprends les périodes concernées, les totaux de contrôles ainsi que la description du logiciel émetteur (pratique pour le débogage). Aussi si on transmet un grand livre (Message Ledger), le message enveloppe l'accompagnant donnera la période concernée par le grand livre.
Le message enveloppe est particulièrement utile lorsqu'on transmet plusieurs messages comptables, par exemple les écritures (Message Accounting Entry) et le plan de compte (Message Chart of Accounts) puisqu'il permet d'établir les relations entre ces messages.
En pratique, on distingue trois types de champs :
- les champs pour lesquels la correspondance est évidente (par exemple, le numéro de compte posera peu de problèmes) ;
- les champs sur lesquels vous hésitez, il faut les vérifier avec plusieurs jeux de données de tests. Je vous invite à hésiter autant que possible et à vérifier le maximum de données. L'imagination a des limites que les services informatiques aiment à repousser… ;
- les champs pour lesquels la correspondance n'est pas évidente. Il faut alors se renseigner auprès d’un spécialiste métier et vérifier l’analyse avec plusieurs jeux de données de tests.
Défis lors de l'analyse
L'analyse des données requiert un dialogue constant avec l’analyste ou une personne qualifiée sur le modèle de données. Prévoyez au minimum une demi-journée de disponibilité d'un interlocuteur qualifié.
Veillez également à vous aider d’une sélection représentative de bases de données de tests. Préférez des bases réelles, avec des données terrains : en pratique il y a souvent un écart entre la vision théorique des données et les informations réellement saisies par les utilisateurs. Il ou elle risque donc parfois de vous induire en erreur. D’où l’intérêt de disposer d’un certain nombre de bases de référence. Le dialogue suivant n'est pas rare :
- "La date de passage de l’écriture se trouve toujours dans le champ FNBCD4."
- "Tiens dans cette base de données exemple, le champ est vide."
- "Ah bon ? Laissez-moi voir… effectivement. Je vais me renseigner." (plus tard) "Après vérification, effectivement, nous avons prévu un traitement particulier pour les opérations de reprise. Dans ce cas-là, on n'encode pas la date du bon de l’écriture si c'est la date du jour. Il faudrait alors consulter le champs FNDSD4."
- "D'accord, la date est toujours dans un de ces deux champs ?"
- "Oui."
Je vous laisse imaginer la suite du dialogue quand vous découvrirez le champs FNDSD4 vide…
Résultats de l'analyse
Au terme de l'analyse, vous disposez d'une table de conversion. Pour la plupart des champs, la mise en commun est évidente. Pour quelques champs, des règles plus compliquées s'appliquent. Quatre cas sont possibles :
- la donnée est présente directement dans la base (dans l'exemple, c'est le cas du numéro de compte). Ce sera le cas pour la plupart des données ;
- la donnée n'est pas présente dans la base mais il s'agit d'une constante. Dans l'exemple, c'est le cas de l’heure pour la date/heure de valeur. Si le logiciel utilisé n’enregistre que la date, il faudra fixer l’heure à une valeur conventionnelle ;
- la donnée n'est pas directement dans la base mais il est possible de la calculer. Par exemple, le numéro de ligne ;
- la donnée n'est pas dans la base, n'est pas une donnée fixe et il n'est pas possible de la calculer. Dans ce cas-ci, trois cas de figure sont envisageables :
- dans la plupart des cas, la donnée est facultative en ebXML, ne la renseignez pas
- sinon il faut prévoir un écran de saisie pour permettre à l’utilisateur de saisir la donnée lors de la préparation du fichier d’export ;
- s’il n’est pas possible de la faire saisir la donnée (par exemple, parce qu’elle est d’une nature telle qu’elle ne doit pas être modifiée par un utilisateur). Dans ce cas, il n'est pas possible d’exporter en ebXML sans une lourde modification du logiciel. Ce cas est très rare.
Note : il est parfois possible de se ramener à un des cas précédents. Par exemple, en établissant une liste de valeurs fixes, comme une liste de produits.
Pour être complet, notons qu'il est parfois nécessaire de reformater des données, même si elles sont présentes dans la base. Par exemple, les dates ont rarement le bon format.
Relation entre le message enveloppe et les autres messages
En réalisant l'analyse des données, notez la relation directe entre ces classes, ce sont elles qui assurent la liaison entre le message enveloppe et les autres messages comptables qui feront partie de la même transmission :
Exemple de table d'analyse
A titre d'exemple, voici un extrait d’une table de conversion fictive (les noms des champs dans la base de données ont été inventés pour les besoins de l'exemple). Pour des raisons de place, la table de conversion complète n'est pas reproduite mais cette table illustre les cas les plus intéressants. Pour les besoins de l'exemple on a également fait l'hypothèque que ce message enveloppe accompagne une transmission d'écriture (([Message Accounting Entry])) :
| XML | Base de données | Commentaires | |
|---|---|---|---|
| ram:ID | dossier_numero | ||
| ram:TestConditionIndicator | dépends des paramètres de l'échange | ||
| ram:SenderAAAWrapSoftware/ram:Name | constant : notre nom de produit | ||
| ram:SpecifiedAAAWrapAccountingPeriod/ram:SpecifiedAAAPeriod/ram:StartDateTime | venu de l'écran d'export | ||
| ram:SpecifiedAAAWrapAccountingPeriod/ram:SpecifiedAAAPeriod/ram:EndDateTime | venu de l'écran d'export | ||
| ram:SpecifiedAAAWrapDayBook/ram:ID | journal_code |
La relation pour la plupart des lignes est assez simple à établir mais j’attire votre attention sur les lignes suivantes :
- ram:Name : le nom du logiciel est une constante
- ram:StartDateTime et ram:EndDateTime : ces dates viennent des paramètres de l'export (et donc des écrans de contrôle) plutôt que des écrans de données
- ram:SpecifiedAAAWrapDayBook/ram:ID : cet identifiant fait la liaison entre les paramètres du journal dans le message comptable et la même classe dans la transmission des écritures. En pratique les deux messages seront transmis simultanément.
D'un point de vue pratique, j'aime à annoter directement la description du fichier mais il vous est loisible de travailler avec un tableau ou tout autre format qui vous convienne. Prenez soin de conserver la documentation, elle sera utile pour la maintenance et les corrections.
Comme pour toute analyse, il convient de garder en tête qu'elle permet de traiter les cas les plus fréquents mais qu'un certain nombre d'aspects n'apparaîtront qu'aux tests ! Et le risque est d'autant plus grand si votre base de données ou votre modèle de données est riche ou est en service depuis longtemps.
Une fois l'analyse terminée, on peut passer à la mise en œuvre à l’aide des composants identifiés préalablement.
Tests d’export
On commence par l’export, qui est plus simple puisqu’on a une bonne connaissance des données a traiter.
Les tests se font d'abord en local. Il suffit de produire quelques fichiers XML à partir de plusieurs bases comptables (si possible, essayez d'obtenir des bases comptables réelles couvrant une longue période pour tester le maximum de cas d'erreur).
Vous pouvez tester vos fichiers en les validant par rapport au schéma XML. N'oubliez pas que le schéma ne permet qu'une validation formelle (vérifier si le champs ID est présent, est de la bonne longueur, etc.) mais ne permet pas une validation logique (est-ce que le champ ID contient vraiment un identifiant). Il est utile de vérifier quelques documents dans un éditeur de texte pour faire cette validation logique.
| Conservez tous les bases de données collectées pour ces tests. Après une mise à jour, refaites un test avec tous ces bases de données. |
N'oubliez pas : il est plus facile de corriger un problème lors du développement (quand vous avez toutes les données fraîchement en tête) que par la suite donc testez aussi complètement que possible.
Import d'un fichier d'écritures
Le point de départ est l’analyse, vous pouvez ré-utiliser l’analyse précédente. L’import pose trois difficultés supplémentaires :
- vous ne pouvez pas être certain de la correction des données ;
- d’autres logiciels appliquent d’autres contrôles. Des données qui sont valides pour le logiciel qui a produit l’export peuvent ne pas être valide pour vous (notamment du à la longueur des champs), vous devez gérez ces différences ;
- vous devrez définir une stratégie de ré-import, voir de ré-export.
Le premier problème est simple à traiter : les données à importer peuvent contenir des erreurs, elles doivent donc être validées comme une saisie utilisateur pour vérifier que toutes les données obligatoires sont saisies, que les comptes sont équilibrés, etc. Si possible essayer de réutiliser vos routines de validation existantes pour éviter toute incohérence.
La plupart des logiciels comptables ont déjà prévu un module d’échange (par exemple pour les télédéclarations), vous pouvez vous appuyez sur ces mêmes contrôles. Le deuxième problème est plus complexe. Il prend deux formes :
- les champs obligatoires vides : un logiciel tiers aura des contrôles de saisie différent. Il se peut que des données obligatoires par rapport à vos contrôles ne soient pas renseignées. C’est le cas inverse des règles de conversion évoquées pour l’export, la solution est similaire : soit on calcule la donnée manquante, soit on la fixe par constante, soit on interroge l’utilisateur
- les longueurs de champs : il est fréquent que les données transmises soient trop longue pour votre base de données. Il faut alors appliquer un algorithme de raccourcissement. Deux solutions : soit la donnée est ignorée. On se souvient que dans le champs date/heure de valeur, on ne stocke que la date. On choisira donc d’ignorer l’heure si elle est renseignée. Soit la donnée est réduite : par exemple, le numéro de pièce peut-être limité à 13 caractères dans votre base de données, il n’est pas limité dans le fichier ebXML. Comment traiter les comptes plus long ? Il faut établir une table de correspondance pour éviter que deux comptes différents soient importés comme identique.
Ce dernier problème mérite un exemple, tant il est fréquent : supposons que vous recevez les données suivantes : AGC324.345323.32, AGC324.345323.62 et AGC324.345323.35.
Clairement c’est plus de 13 caractères mais il serait dangereux de simplement réduire la longueur de l’identifiant, on obtient AGC324.345323 pour les 3 valeurs bien qu’il s’agisse de trois pièces différentes.
Il faut alors établir une liste de correspondance pour garantir que les numéros générés restent uniques, par exemple : AGC324.345321, AGC324.345322 et AGC324.345323.
Idéalement on stockera cette table de correspondance pour les imports suivants. Seul ce stockage garantit la cohérence des ré-imports dans le temps :
| Correspondant | NumPieceOriginal | NumPieceImportee |
|---|---|---|
| AGCD | AGC324.345323.32 | AGC324.34532A |
| AGCD | AGC324.345323.62 | AGC324.34532B |
| AGCD | AGC324.345323.35 | AGC324.34532C |
De même on pourra utiliser la table lors d’un export à destination de ce correspondant pour rétablir les identifiants d’origine et donc assurer une communication bi-directionnelle parfaite.
