Expérience technique

Dans le cadre de l'association EDIFICAS (http://fr.wikipedia.org/wiki/Edificas et http://www.edificas.fr/) 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 (représenté par Gérard Colo),
• Productiv' de EIC (représenté par 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.

Des exemples de code sont également disponibles en téléchargement.

Le besoin

D'emblée, les deux développeurs insistent sur le besoin d'un format reconnu et pérenne pour la profession comptable.

Depuis une quinzaine d’années nous avons été participé à un tas de travaux de dématérialisation des échanges avec différentes administrations. L’administration fiscale bien entendu mais également ce qui tourne autour du social. Des déclarations relatives aux personnels, aux salariés etc. Et pour cela aussi bien ceux qui les reçoivent que ceux qui les émettent ont travaillé ensemble pour savoir comment faire et comment rationnaliser tout cela. On est bien entendu partie prenante en tant qu’éditeur de logiciel. Et on participe aussi bien en matière sociale qu’en matière fiscale à tout ce genre de travaux.

Un des axes de notre développement est que tout ce qui s’imprime s’exporte. On le répète en permanence à nos clients et ça a des implications commerciales fortes pour nous. Cela veut dire, "venez chez nous pour la qualité de nos produits, mais si jamais vous êtes déçu, vous pourrez de toutes façons, exporter tous vos données et les récupérer par ailleurs. On comprend bien qu’il y ait des contraintes dans la vie d'une société qui font qu’à un moment donné vous allez peut être absorbé par quelqu’un qui voudra garder son service comptable et donc le votre sera prié d’oublier ses anciennes habitudes, ces anciens logiciels, ces anciens partenaires." C’est vraiment très fort comme discours.

On dit à nos clients, ne vous inquiétez pas, vous appuyez sur le bouton "Impression," vous avez un onglet juste à coté et votre fichier vous le récupérez en Excel 2003, en Excel 2010, en ASCII, en texte. Nos travaux avec l'UN/XML s'inscrive dans ce cadre là. (GC)

Outre l'objectif commercial, un format pérenne permet également de répondre à des contraintes légales. 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 dans 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. (AP)

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)

Il y a toutes ces applications où le fonctionnement des logiciels n'est pas standardisé, sauf pour les sorties. Je pense à la paye par exemple. Tout le monde a un bulletin de paye, tout le monde a un virement de fin de mois, tout le monde a ses déclarations annuelles etc. Ces documents là se ressemblent tous parce qu'il y a des choses règlementaires dedans. Mais la façon de les produire dépend beaucoup du logiciel aussi d’une entreprise à l’autre on pense qu'il n'y a pas grand choses à récupérer.

Moi je dis toujours "mais si !" Vous pouvez récupérer les codes, les identités, les RIBs, les tables d'ancienneté de votre personnel. Tout cela peut s’exporter. Ce qui n’a pas beaucoup d’intérêt sur 3, 4 salariés mais peut en avoir si la société a 300 salariés. On ne peut pas se retaper la saisie des 300 RIBs. (GC)

Bref ces travaux sont utiles, pour des raisons diverses, à la profession comptable.

Le développement

Quand est arrivé le moment de la mise en œuvre, les deux développeurs ont travaillé 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 fonctionnent très bien.

J’ai utilisé Visual Studio qui permet de valider avec le schéma XML. C'est très pratique parce qu'il est capable de repérer les erreurs de le fichier d’export. Il permet aussi de visualiser les différents composants de XML et leur structure, l'affichage ressemble un peu à un diagramme de classes. Le schéma XML, en tant que fichier source, est assez illisible alors que la représentation graphique permet d'avoir une vue d'ensemble. C'est-à-dire qu’on peut partir du schéma XML lui-même qui contient les documentations, sans forcément reprendre le BRS ou le RSM. Sans oublier les contrôles qui sont possibles. (AP)

Nous, on utilise pas Visual Studio, ce n'est pas dans nos traditions. On est plutôt Pascal et C++, des choses comme cela. Ce développement s'est fait en C++ Builder. (GC)

Notons que le langage de programmation est secondaire dans ce projet, les briques XML sont disponibles pour tout les langages de programmation. Et avaient une expérience des échanges de données informatisés, via EDIFICAS, mais pas nécessairement de la norme XML.

Notre conception c'est "tout ce qui s’imprime s’exporte." C'est à dire que quand on a un petit bouton imprimante, ça ouvre une fenêtre qui permet à l’utilisateur de sa mise en page, le truc classique. Et nous on y rajoute l’onglet donc qui permet de faire un export fichier.

C'est un petit peu différent pour XML qui sera plutôt réservé aux gros travaux d’export. Je m’explique, si j’ai un plan comptable à créer pour une entreprise, je ne vais pas m’embêter, je vais prendre le mien, l’exporter et ré-importer de l’autre coté. Ca est une opération facile.

Mais une base d’écriture comptable c’est un petit peu plus compliqué, il va falloir que je l’importe dans un nouveau module parce qu’il est difficile de mélanger les bases. Je suis plutôt parti là, dans les travaux, sur j’exporte le tout et je ré-importe tout. Il faut que tout l’environnement soit récupéré d'ailleurs avec les premiers essais, lorsqu'on ne ne traitait pas encore le plan de compte, quand on essayait de récupérer le numéro de compte d'une écriture on devait mettre un point d’interrogation à coté.

Voilà, c’est ce genre de petites choses qui font que ce n’est pas facile d’intégrer. Il faut que ce soit vraiment un module particulier. Alors on avait développé une base d’empilement d’écritures, toutes les écritures s'empilent mais quand les restituent à l'utilisateur on les présente plus traditionnellement.

Pour cette base d'empilement on a développé un module de requête : tous les montants qui sont à 100€, toutes les écritures qui ont été saisies pas Dupond, parce que j’ai un doute sur ce qu’il a fait, etc. Cette base d'empilement sert aussi quand on veut récupérer des écritures qui viennent d’ailleurs. C'est une module qui était déjà dans notre logiciel mais on n’imprime jamais une base de 100 000 écritures d’un seul coup. Cela n’a pas de sens à remplir trois rames de papier avec des informations sous forme de listing. Donc on s’est dit, pour cette base là, ce serait intéressant d'en faire l’export sans passer par l’opération traditionnelle de "j’imprime" donc je peux exporter et c'est là que j'ai logé nos développement UN/XML. (GC)

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 virements 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 sont limitées :

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.

J'ai utilisé le parseur XML est fournit par Windows, c'est un object COM qui implémente l'API DOM et qui permet de lire et d'écrire de l'XML. Il y a pas mal d'exemples sur Internet pour apprendre à s'en servir, c'est un peu abrupt au début mais on s'y fait rapidement. La partie Unicode est très bien gérée par le composant et je me suis fait un surcouche pour masquer complètement Unicode.

Par contre j'ai eu des problèmes avec les espaces de noms parce que je ne les avais pas géré au départ. Or le schéma produit par l'UN/CEFACT utilise plusieurs espaces de noms. Autre petite difficulté, en lecture, il faut parfois stocker des données. Par exemple, pour une conversion on a besoin d'un montant et d'une unité monétaire. Donc quand tu reçois le montant, il faut attendre pour trouver l'unité avant de faire la conversion, c'aurait été plus pratique si l'unité avait été avant le montant. En pratique je stocke toutes les informations d'une ligne en mémoire et je ne commence à les écrire dans la base de données que après avoir récupérer toutes les informations et donc après avoir fait les traitements éventuels. (AP)

C++ Builder a des composants XML, avec les interfaces SAX et DOM. C’est relativement simple mais c'est moins simple, une fois qu’on l’a écrit, à entretenir. Parce que pour l’instant on a codé à chaque fois les balises en dur, donc l’entretien ne se fait pas la réécriture d’un nombre relativement important de ligne, à chaque fois que cela évolue. (GC)

Le schéma XML c’est du bonheur, parce que c’est lui qui fait la vérification de la structure, sinon on n’importe pas. On aura que du contenu sur autre chose. Mais la vérification de la structure c’est primordial. (GC)

Lors de l'import des données, il est bon d'utiliser une table temporaire.

Pour l'import UN/XML, j’ai besoin d’un fichier temporaire ou d’un brouillard comptable. C'est-à-dire d’une écriture comptable non centralisé, et ensuite je fais tourner le logiciel dessus pour qu’il me détecte les erreurs. Cela peut être des erreurs comptables de base, débit différents de crédit. Mais cela permet de mettre en évidence, que les choses toutes bêtes, comme ce qu’on a utilisé comme séparateur pour le décimal, bien il fallait mettre une virgule, on a mis un point ou le contraire. On applique sur ce qu’on a importé une moulinette qui vérifie l’intégrité et la cohérence de tout ce qu’on rentre dans la base.

Ce sont exactement les mêmes contrôles qu’à la saisie. Ce qu’on fait pratiquement toujours en import.

Je transforme le paquet d’écriture que j’importe en ligne de brouillard comptable, qui sont intégrés au fur et à mesure que la moulinette passe dessus. Et s’il y a des calculs à faire, par exemple pour vérifier l’égalité des crédits c’est fait au moment du traitement du dossier dans le logiciel pas lors de l'import. Et quand j’exporte il n’y a pas de valeur de contrôle imposé. (GC)

Notre brique d'import stocke dans une table intermédiaire. On s'est rendu compte, quand on a développé les premiers imports, c'est qu'il y a des cas d'utilisation où les comptes ne sont pas au format, des écritures qui ne sont pas équilibrées, etc. Bref il y a plusieurs problématiques donc on importe dans une table intermédiaire pour vérifier la conformité des données et présenter à l'utilisateur les écrans nécessaires pour corriger les erreurs : par exemple dans le cas d'une écriture non-équilibrée, il peut passer l'écriture manquante, pour corriger un export incomplet, ou corriger un montant en cas d'erreur de saisie.

Après cette brique d'import, les données sont aussi propres que si elles avaient été saisie par le logiciel. Les écritures importées passent par le même moteur d'écriture que si on les avait saisies, il y a donc la même validation. (AP)

Analyse des données

Après avoir maîtrisé les outils, la partie la plus délicate du travail a été d'analyser les données. Il y a des données qui sont exportables, d'autres qui ne le sont pas. Parce que, et on avait l’exemple du code d’un tiers qui, comme il n’est pas lui-même régis par une norme, peut comporter un jeu de caractère très différent entre deux logiciels. Donc, dès qu’on touche aux spécificités des logiciels, remarque j’enfonce une porte ouverte, tout ne peut pas être géré.

On va exporter des tas de choses que la personne qui est en face n’utilisera peut être pas. En gros, on exporte tout et puis la personne qui est à l’autre bout elle transcrit ce qu’elle comprend, ce qu’elle peut utiliser. Elle complète quand elle n’a pas, et puis elle ne prend pas quand elle ne veut pas utiliser ou quand elle n’utilise pas. (GC)

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 logiciel ? 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)

N'oublions pas les tests

Les tests sont essentiels pour s'assurer du caractère complet de l'analyse. D'abord un conseil : Je pars d'une base que je ne connais, comme cela je suis sûr de ne pas être influencer par ma connaissance du client et le résultat. Ce n’est pas moi qui ai décidé de ce que j’acceptai, je tolérais etc. Je pars simplement d'une base reçue à la hot line.

On disposait également d'un fichier de test (voir le téléchargement) ce qui nous a permis d'avoir une base de travail commune. Cela permet de se poser les questions sur des champs que l’on n’utilise pas nous dans notre logiciel. (GC)

Ces problèmes je les ai repéré pendant la phase de tests. Je n'avais pas imaginé au départ que, dans le numéro de compte, je puisse trouver des points. C'est une question que je ne me serais jamais posée en fait, la longueur oui parce que c'était déjà traité chez nous mais les caractères spéciaux c'était nouveau. Sur le nombre de champs que j'ai eu à traiter, le compte est peut-être le plus complexe. (AP)

A l'export il y a beaucoup moins de soucis parce que je connais mes données et je sais ce que je dois exporter. Si je n'ai pas la donnée alors je ne l'exporte pas parce que le but n'est pas de casser tout le logiciel pour faire rentrer XML ! Au contraire, le but est de conserver les logiciels, avec leurs particularités, et d'essayer de les faire communiquer : y compris vers des logiciels d'archivage d'ailleurs. (AP)

Elements optionnels

Tous les éléments spécifiés par le schéma ne doivent pas nécessairement être fourni dans le logiciel.

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)

Je serai plutôt du coté de entre 50 et 75. En tout cas sur de l’écriture comptable parce que j’ai beaucoup d’utilisateurs qui sont multi devises. On tombe dans des cas de figure plus riche dans la variété de mes clients que dans celle du cabinet comptable traditionnel français. Le fait justement qu’on ait d’énormes besoin de transcodage, est une caractéristique de notre clientèle. "Vous avez monté un GIO au Portugal, ils utilisent tel code dans leur plan comptable, mais nous qui sommes une entreprise Hollandaise on aurait bien aimé avoir autre chose." (GC)