Modèle:Boilerplate export rest
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.
