Expérience technique : Différence entre versions

Version du 23 septembre 2011 à 10:10

Dans le cadre de l'[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. Il y a plein de types d'écriture : général, analytique, etc. mais dans mon logiciel je n’ai que le type général donc je n’ai pas la donnée, je dirais qu’on a une valeur par défaut que j'ai mis en dur dans le fichier. Après, le troisième cas, on a d’autres données calculées, qui sont des totaux de contrôles par exemple. Je ne les ai pas directement dans le logiciel, je les calcule au fur et à mesure.

J’ai trouvé plus facile de faire l’export d’abord et de lire en fait la documentation du fichier XML. Et pour chaque donnée, donc, je me suis posé la question, est ce que j’ai dans ma compta ou pas ? Et après l'avoir fait j'avais une vue, cela m'a aidé pour faire le plan en arrière.

A l'import j'ai aussi eu des problématiques ou le format qui est dans le fichier XML ne correspond pas au format dans notre base de données. Dans le fichier XML, le compte comptable est séparé en deux parties sans limite de taille. Or dans ma base de données, j’ai un compte sur 13 caractères. Donc il a fallu refaire un seul champ tout en gardant le compte d’origine pour pouvoir le ré exporter si besoin.

Par exemple, dans le fichier XML le compte est décrit comme 401 000, compte général, et EIC dans le compte de tiers. Dans mon logiciel ça devient 401 EIC, et il va falloir conserver, de manière cachée, le compte original (401 000 / EIC) pour pouvoir ré-exporter le dossier. Autre exemple, dans le fichier qui m'a été donné, il y avait des caractères de ponctuations dans le numéro de compte. Et les caractères de ponctuations (par exemple 401 e.i.c.), je suis complètement incapable de les gérer dans un numéro de compte.

Bien entendu ce que j’exporte, je suis capable de le lire. Puisque dans un fichier que j'ai créé, les tailles ne sont pas supérieures à ce que j’attends. C'est quand on a commencé à échanger avec un autre éditeur qu'on se rend compte des problématiques de formats. Il y a tout un tas de solutions je dirais. (AP)

Elements optionnels

En fait j’ai fait de la programmation par ajout. D'abord j'ai fait un export simple, et donc, je dirais, le plan comptable de base sans avoir les éléments d’adresse. Une fois que j’avais le plan comptable de base, j’ai validé avec le schéma XML. Quand ça a validé, j'ai ajoute les adresses, j'ai recommencé la vérification et ainsi de suite. J’ai trouvé cela beaucoup plus facile, plutôt que de faire tout et d’attendre d’avoir tout fini pour valider en fait.

Beaucoup d’élément sont optionnels. Si on regarde les éléments obligatoires, ce ne sont que les éléments classiques de l’écriture comme la date, les libellés, le montant, le sens, le compte. On a vite repéré le squelette ce qui peut permettre d’avancer après petit à petit, d’ajouter des briques petit à petit et de faire évoluer son export ou son import puisque c’est dans les deux sens.

L’import, c’est quasiment de la même façon. J’ai importé des valeurs principales d’abord et j'ai vérifié mon résultat. Non pas avec le schéma mais à l’intérieur des logiciels : j'ai vérifié que entre le dossier exporté et le dossier importé j'avais bien les mêmes résultats comptables.

Je n’ai pas fait l’exercice de vérifier combien de balises je remplissais par rapport au nombre de balises existantes. Mais à vue de nez, j’ai entre 25 et 50 pourcent. Nos logiciels s'adressent aux experts comptables. La clientèle experts comptables c’est beaucoup de TPEs, un peu de PMEs, peu de grosses entreprises. Mais le schéma XML peut s’adapter aussi bien à la comptabilité petites entreprises, que la comptabilité grosses entreprises. Voire même étrangères. Donc, nous effectivement, on traite qu’un aspect du problème. (AP)