Expérience technique
Dans le cadre de l'association EDIFICAS et, plus particulièrement du GT4, un échange de test des messages comptables a été mis en œuvre entre deux logiciels comptables d'éditeurs différents :
- Gestion Intégrée de Logic Systems (Gérard Colo),
- Productiv' de EIC (Alex Pajon).
Cette échange a permis de corriger et d'améliorer la structure des messages mais également de collecter un maximum d'expérience sur la mise en œuvre concrète des normes correspondantes. Ainsi, on a pu résumer cette expérience sous forme d'extraits du code (généreusement mis à disposition par les deux éditeurs) et d'interviews avec les développeurs.
En cela, la présente section complète le reste de la documentation avec une approche résolument pratique.
Le besoin
D'emblée, les développeurs insistent sur le besoin d'un format reconnu et pérenne pour la profession comptable.
"L’administration française exige, pendant un délai relativement court (5 ans), d'obtenir les écritures comptables de n’importe quel dossier quand ils font leur contrôle. Donc, soit on fait une archive de notre sauvegarde, au moment de la clôture de l’exercice, soit on archive directement un format reconnu par tous, qui peut être réutilisé par l’administration mais aussi pour faire de la consolidation, pour faire du retraitement comptable."
Il ajoute :"Quand on a des gens qui changent de logiciel, on a besoin de récupérer en fait l’historique des clients. C’est une grosse problématique et qui n’est pas forcément évidente à traiter aujourd’hui. Et la normalisation de l’écriture comptable, doit pouvoir y concourir." (AP)
Le développement
Les deux équipes travaillent en C++.
"Aujourd’hui, la plateforme est assez disparate, puisqu’on a des outils en C++ Builder, des outils en Visual C++, des outils en Visual C#. Sur les bases de données historiquement, on a du fichier indexé, du Paradox, et du Firebird. En fait, on a plusieurs technologies qui se marient entre elles à l’intérieur de notre logiciel, mais qui fonctionne très bien." (AP)
Et avaient une expérience des échanges de données informatisés, via EDIFICAS, mais pas nécessairement de la norme XML.
"Aujourd’hui on traite aussi toutes les télédéclarations possibles. Je dirais toutes formes de déclarations fiscales à destination de quasiment tous les émetteurs possible. A savoir, DGFiP, OGA, banques, banques de France. On a aussi des liens vers les banques pour la récupération de relevés, l’envoi d’ordres, de virement ou de prélèvements. Et je dirais qu’on est quand même assez tourné vers la dématérialisation des données autour de l’écriture. C’est un sujet qui va tendre à se déployer fortement."
"On a une brique technique qui permet de gérer les télédéclarations aussi bien pour la partie IHM, c'est à dire la sélection des dossiers générés, des flux à envoyer, etc., que pour la création du fichier de télédéclaration. On réutilise le même principe un peu partout ce qui est beaucoup plus simple. Après l’effort il est surtout sur les déclarations en elles mêmes et cela, qu’on fasse des papiers ou qu’on fasse de la démat' c’est exactement la même chose." (AP)
L'intégration XML pose des questions techniques nouvelles mais elles ne sont pas très importantes :
L’outil dans lequel j’ai voulu intégré cela est un vieil outil qui n’avait pas les fonctions XML en natif. Donc, il a fallu que je me documente sur comment faire de l’XML propre. Ce qui a été globalement assez simple. Une fois que j’ai ces briques XML, j’ai réutilisé, en les adaptant, toutes les briques qu’on avait déjà sur l’import et sur l’export. Le plus gros de la complexité, a été par l’apprentissage du fichier, de la norme XML, de comment la traiter correctement et enfin la surcouche UN/CEFACT avec les espace de noms, etc. (AP)
Analyse des données
Les modules que j'ai utilisé avaient déjà toutes les données accessibles. Pour les données obligatoires de toute façon cela ne pose pas de problèmes. Pour les données optionnelles, il faut savoir est-ce qu’on les a ou pas dans le logiciel. Il faut également le lien, entre la donnée du logiciel et la donnée qui est demandée dans les XML. Autant en lecture qu’en écriture d’ailleurs. C’est une lecture des données de la norme et j’ai regardé dans mon logiciel à quoi cela pouvait correspondre par rapport aux définitions qui étaient inscrites. Et en lisant les définitions je regardais, est ce que j’ai la donnée dans le ? Si je ne l’ai pas, est ce que je peux la calculer ? Est ce que je peux la renseigner par défaut ? Ou alors je la mets pas.
Comme exemple du premier cas, le montant de la ligne d’écriture y a pas de problème. Je pense que cela serait difficile de faire un logiciel comptable sans. J'ai la donnée qui correspond un pour un, dans le fichier XML, alors la question se pose à peine de savoir où est ce qu’on met la donnée. Dans un sens comme dans l’autre d'ailleurs.
Le deuxième cas c’est le type de ligne d'écriture. Quand je n’ai pas la donnée mais que je peux la calculer. Donc, dans ce cas là il faut établir une règle de calcul pour savoir quelle est la donnée que je vais mettre dans le fichier XML, et si je la trouve en lecture de fichier XML, comment je dois l’interpréter. Est-ce qu’il faut que je l’interprète déjà ? Dans les types d’écritures on a, en général, des activités analytiques, on a des écritures, de. On a plein de type d’écritures au fait. Moi dans <0:18:55> j’en ai qu’un. Je n’ai que le type général. Et quelque part, je n’ai pas la donnée générale. Dans mon logiciel y a aucun, je dirais qu’on a une valeur par défaut qu’il va falloir déterminer en disant mes écritures elles sont de quel type. Si je n’ai pas la donnée, la elles sont générales. Voilà, donc, j’ai mis en dur dans le fichier, cela va écrire que, mes écritures sont de type général. Voilà, puisque c’est un peu ce que j’appelle une donnée calculée. Après on a d’autres données calculées, qui sont des totaux de contrôles par exemple. Donc là effectivement, moi les totaux de contrôle, je ne les ai pas directement dans le logiciel, je les fais au fur et à mesure. Et une fois que j’ai terminé mes totaux de contrôle, je les écrits dans le fichier en fait à la fin. (AP)
