Expérience technique : Différence entre versions

De Guide utilisateur des messages comptables UN/XML
Ligne 29 : Ligne 29 :
 
L'intégration XML pose des questions techniques nouvelles mais elles ne sont pas très importantes :
 
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 [[Introduction rapide à XML|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|espace de noms]], etc.|AP}}
+
{{Citation|L’outil dans lequel j’ai voulu intégré cela est un vieil outil qui n’avait pas les fonctions [[Introduction rapide à XML|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|espace de noms]], etc.|AP}}

Version du 22 septembre 2011 à 08:09

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)