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