Author: echatellier Date: 2010-03-30 16:15:15 +0200 (Tue, 30 Mar 2010) New Revision: 2819 Log: Add old site documentation from callao. Added: trunk/src/site/resources/callao/ trunk/src/site/resources/callao/class/ trunk/src/site/resources/callao/class/class-diag.png trunk/src/site/resources/callao/uc/ trunk/src/site/resources/callao/uc/uc-base.png trunk/src/site/resources/callao/uc/uc-cloture.png trunk/src/site/resources/callao/uc/uc-comptes.png trunk/src/site/resources/callao/uc/uc-etats.png trunk/src/site/resources/callao/uc/uc-exercice.png trunk/src/site/resources/callao/uc/uc-fichiers.png trunk/src/site/resources/callao/uc/uc-journal.png trunk/src/site/rst/callao/ trunk/src/site/rst/callao/callao.rst trunk/src/site/rst/callao/classes.rst trunk/src/site/rst/callao/contact.rst trunk/src/site/rst/callao/developpement.rst trunk/src/site/rst/callao/howto.rst trunk/src/site/rst/callao/index.rst trunk/src/site/rst/callao/lexique.rst trunk/src/site/rst/callao/news.rst trunk/src/site/rst/callao/roadmap.rst trunk/src/site/rst/callao/todo.rst trunk/src/site/rst/callao/usecases.rst Added: trunk/src/site/resources/callao/class/class-diag.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/class/class-diag.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-base.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-base.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-cloture.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-cloture.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-comptes.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-comptes.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-etats.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-etats.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-exercice.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-exercice.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-fichiers.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-fichiers.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/callao/uc/uc-journal.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/callao/uc/uc-journal.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/rst/callao/callao.rst =================================================================== --- trunk/src/site/rst/callao/callao.rst (rev 0) +++ trunk/src/site/rst/callao/callao.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,68 @@ +====================== +Présentation de CALLAO +====================== +(Computing Active Layer for Lutin's Accounting Organization) + +``1. Présentation`` +------------------- + +La comptabilité est une tâche longue, répétitive, et induisant un nombre +important de contrôles et de calculs. + +C'est un excellent exemple de ce que l'automatisation grâce à l'informatique +peut apporter en terme de gain de temps. Longtemps réservée aux grosses +entreprises, l'explosion de l'informatique personnelle (puis portable) à +largement démocratisé la comptabilité par informatique mais toujours par le biais +de solutions malheureusement propriétaires et/ou peu portables. + +L'essor récent du logiciel libre permet l'émergence de solutions encore plus +accessibles, débarrassées des traditionnels verrous emprisonnant l'information +comptable, et donc son propriétaire, dans un contexte étriqué d'utilisation. +Ces logiciels nécessitant l'achat de licences spécifiques en cas d'emplois sur +plusieurs postes, et interdisant le partage ou la migration entre applications +"concurrentes". + +``2. Naissance`` +---------------- + +Issu du projet Chorem_, +CALLAO_ est un moteur de comptabilité `libre de droits`_ respectant les conventions +ainsi que les normes comptables imposées aux entreprises par la législation +française. + +Bien que créé pour fonctionner avec l'interface graphique LIMA_, CALLAO_ a été +conçu pour pouvoir être utilisé par différentes interfaces graphiques. Il est +donc possible de créer une interface Web de comptabilité reposant sur le moteur +CALLAO_ + +``3. Architecture`` +------------------- + +Les utilisateurs de l'interface utilisateur LIMA_ effectuaient jusqu'alors cette gestion +des données gràce au moteur de comptabilité d'OFBiz-Neogia. CALLAO_ doit pouvoir se +substituer à ce moteur mais sans nécessité une refonte de LIMA_ afin de laisser aux +utilisateurs de ce dernier le choix du moteur de comptabilité qu'ils +utilisent ou de faciliter les migrations d'un moteur à l'autre [#]_. + +Ainsi notre couche de DTO se substituera à toute la partie exterieure à +l'interface de LIMA_ comme suit : + +.. image:: resources/schemas/schema-architecture.png + + + +On peut voir que le DTO utilise le modèle définit par le design pattern du même +nom pour décrire le moteur CALLAO de l’application comptable finale. +L’architecture est elle même composée de deux couches : une de persistance pour +la gestion des données, et une autre métier pour la gestion des flux entre la +persistance et les interfaces d’entrées/sorties véhiculées par des objets +JavaBeans. + + +---- + +.. _`libre de droits`: licence.html +.. [#] A cet effet des fonctions d'import et d'export seront mises en place. +.. _ChoreM: http://chorem.org/ +.. _LIMA: http://maven-site.chorem.org/lima/ +.. _CALLAO: callao.html Added: trunk/src/site/rst/callao/classes.rst =================================================================== --- trunk/src/site/rst/callao/classes.rst (rev 0) +++ trunk/src/site/rst/callao/classes.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,364 @@ +==================== +Diagramme de classes +==================== + +.. image:: class/class-diag.png + +``Entry`` +========= +``Description :`` +----------------- +Une Entry est une écriture comptable, qui traduit le passage d'une somme au débit +ou au crédit d'un compte. + +``Attributs :`` +--------------- + +- description : Description textuelle de l'opération. + +- amount : Montant de l'opération, stocké sous forme de string. + +- debit : Booléen indiquant s'il s'agit d'une opération de type débit ou crédit. + +- lettering : Chaîne de caractères employée pour le lettrage + +- detail : Chaîne de caractères servant au stockage d'informations caractérisant +l'écriture en question au format CSV. + +- Transaction : Une Entry fait forcément partie d'une Transaction (soit d'une +Transaction existante, soit une nouvelle Transaction est créée lors de la +création + + +``Liens :`` +----------- + +- Log : Toute opération sur une Entry sera consignée dans un objet Log(RM). + +- Account : Une Entry est une opération de débit ou de crédit sur un compte donné. +Chacune d'elle concerne donc un et un seul compte. + + + +``Transaction`` +=============== +``Description :`` +----------------- +Une Transaction représente une opération comptable, soit un ensemble d'écritures +(Entry). Une Transaction n'est dite équilibrée que si la somme des montants des +écritures de débit qui la composent est égale à celle des écritures de crédit(RM). +Elle fera souvent référence à un document justificatif (par exemple une facture) +qu'elle représentera comptablement. Elle est passée à une date donnée qui concerne +par extension toutes les écritures qu'elle contient. + +``Attributs :`` +--------------- + +- entryDate : La date d'entrée de l'opération (saisie par l'utilisateur). + +- voucherRef : Si utile, référence du document justificatif. + +- description : Description textuelle. + + +``Liens :`` +----------- + +- Entry : Une Transaction est une composition d'un certain nombre d'écritures +(Entry). + +- TimeSpan : Une transaction intervient pendant un intervalle de temps. La clôture +de cet intervalle de temps (TimeSpan) implique que la Transaction n'est pas +modifiable (règles métier de l'application(RM)). + +- Journal : Une Transaction appartient à un journal donné, selon là où elle a +été entrée par l'utilisateur. + + + +``TimeSpan`` +============ +``Description :`` +----------------- +Un TimeSpan, ou intervalle de temps, représente une subdivision de l'exercice +comptable (Period) en plusieurs périodes plus petites afin de pouvoir clôturer +son travail au fur et à mesure. La loi impose juste que les exercices soient +clôturés de manière définitive, donc les clôtures de TimeSpan seront +réversibles(RM). Un intervalle de temps ne pourra être verrouillé que si les +précédents intervalles sont également verrouillés(RM). L'idée de cette +fonctionnalité nous a été soumise par notre professeur de comptabilité. Nous +avions commencé par concevoir des intervalles de temps de durée quelconque mis +en place par l'utilisateur avant de s'orienter vers des TimeSpan d'une durée +d'un mois, également sur ses conseils. Les différents TimeSpan (autant que de +mois pour l'exercice) seront générés lors de la création de l'exercice(RM). + +``Attributs :`` +--------------- + +- beginTimeSpan : Date de début de l'intervalle de temps. + +- endTimeSpan : Date de fin de l'intervalle de temps. + +- locked : Booléen indiquant si l'IT est clôturé ou non. + + +``Liens :`` +----------- + +- Period : Un intervalle de temps appartient à un exercice (Period donné). En +fait, il constitue un mois de cet exercice. Les dates de début et de fin de l'IT +sont donc évidemment comprises dans celles de l'exercice auquel il appartient. + +- Transaction : Un ensemble de transactions est effectué pendant un intervalle +de temps donné, déterminé par la date de transaction. Un intervalle de temps ne +peut être clôturé que si toutes ses transactions sont équilibrées(RM). + + + +``Period`` +========== +``Description :`` +----------------- +Il s'agit d'un exercice comptable. Ses dates seront définies par l'utilisateur +dans la limite de certaines règles métier qui permettront de respecter le cadre +légal : un exercice commence là où le précédent se finit; la durée de l'exercice +est fixée à l'avance et ne peut être modifiée; la clôture d'un exercice est +définitive(RM). Il ne peut y avoir plus de deux exercices ouverts en même temps(RM) +et aucun exercice ne peut être clôturé sans que le précédent ait été clôturé(RM). +Lors de la clôture d'un exercice, une opération de report à nouveau est effectuée +sur l'exercice suivant(RM). De fait, il est impossible de clôturer un exercice +sans avoir préalablement créé le suivant(RM). + +``Attributs :`` +--------------- + +- beginTimeSpan : Date de début de l'exercice. + +- endTimeSpan : Date de fin de l'exercice. + +- locked : Booléen indiquant si l'exercice est clôturé ou non. + + +``Liens :`` +----------- + +- TimeSpan : Un exercice contient, selon sa longueur, un certain nombre +d'intervalles de temps qui correspondent à ses différents mois. Les différents +TimeSpan sont créés en même temps que l'exercice(RM). La clôture de l'exercice +implique automatiquement la clôture de tous ses TimeSpan(RM). + + + +``Journal`` +=========== +``Description :`` +----------------- +Le logiciel supporte la « comptabilité multi-journal », c'est-à-dire que +l'utilisateur peut saisir ses opérations dans plusieurs journaux différents +(Journal des ventes, journal des achats...). + +``Attributs :`` +--------------- + +- label : Libellé du journal. + +- prefix : Prefix du journal, utilisé par l'interface. + + +``Liens :`` +----------- + +- Transaction : Un journal est composé de transactions, mais peut être vide. + + + +``Log`` +======= +``Description :`` +----------------- +Chaque ajout/modification/suppression sur une Entry entraine la création d'un +log contenant toutes les nouvelles informations de celui-ci (qui seront vides +s'il s'agit d'une suppression(RM)). La modification d'une Transaction entraine +aussi la création d'un log pour chacune de ses Entry(RM). Dans la mesure où les +logs devraient pouvoir être consultés sans impliquer de traitement, on y réunira +les informations consultant les Entry et les Transaction. + +``Attributs :`` +--------------- + +- logDate : Date où le log est créé (déterminée à partir de l'horloge système) + +- type : Type de modification. Peut prendre 4 valeurs différentes : add (ajout), +mod (modification), del (suppression), tmod (modification de transaction). + +- transDate : Date de la Transaction. + +- voucherRef : Référence du justificatif de la Transaction. + +- transDesc : Description de la Transaction. + +- entryDesc : Description de l'Entry. + +- amount : Montant de l'Entry. + +- debit : Booléen indiquant s'il s'agit d'une écriture de débit ou de crédit. + +- lettering : Letterage de l'Entry. + + +``Liens :`` +----------- + +- Entry : Le log correspond à une Entry qui, elle, peut avoir plusieurs logs (au +moins un et autant qu'elle a subi de modifications). + + + +``Account`` +=========== +``Description :`` +----------------- +Correspond à un compte du PCG. Les sous-comptes (e.g. 4111) sont considérés +comme étant agrégés dans leur « compte père » (e.g. 411). Un compte ne peut être +supprimé s'il contient des écritures(RM). + +``Attributs :`` +--------------- + +- label : Libellé du compte. + +- accountNumber : Numéro de compte. + +- Entry : Les Entry représentent les différentes opérations effectuées sur les +comptes. Plusieurs écritures peuvent être passées concernant un compte donné, +mais celui-ci peut exister sans écriture. + + +``Liens :`` +----------- + +- Account : Un compte peut contenir des sous-comptes. + + +``CallaoUser`` +============== +``Description :`` +----------------- +Bien que l'interface prévoit une phase d'authentification à son lancement, il +n'est pour l'instant pas prévu d'implémenter une gestion multi-utilisateurs de +Callao. Nous ajoutons néanmoins cette classe afin de pouvoir prévoir cette +gestion dans une implémentation future. + +``Attributs :`` +--------------- + +- userID : ID de l'utilisateur. + +- login : Login de l'utilisateur. + +- password : Mot de passe de l'utilisateur + +- right : Code le groupe de droits auquel l'utilisateur a accès + + + +``User`` +======== +``Description :`` +----------------- +Cette classe va permettre de typer des écritures vis à vis des utilisateurs +relatifs qu'elle touche. Ceci permettre d'effectuer des tris d'écriture afin +d'extraire le coût ou produit généré par des individus. +Cette démarche s'inscrit dans l'optique d'une synchronisation des données entre +Chorem et Callao. + +``Attributs :`` +--------------- + +- matcher : Le nom d'utilisateur + + + +``Type Presta`` +=============== +``Description :`` +----------------- +Correspond aux propriétés d'une écriture. Permet de définir et classifier les +écritures grâce aux catégories pertinentes afin de mieux analyser les résultats +des différentes activités de l'entreprise. + +``Attributs :`` +--------------- + +- matcher : Description du type de prestation associée à une écriture + + + +``Client`` +========== +``Description :`` +----------------- +Les catégories de clients sont des informations venant éventuellement se greffer +sur des comptes afin de mieux renseigner les informations sur ces derniers, de +pouvoir éventuellement les regrouper et déduire des généralisations par catégories +de client, anticiper des durées de stockages de créances pour un client lambda +fonction de sa catégorie. +Ces catégories seront cependant le plus souvent associées aux comptes descendants +du compte 411 (client) et assez rarement (voir pas du tout) d'autres comptes +sauf exceptions sur les comptes 416 ou autres cas exceptionnels. +Ce système reste évolutif et permet à un comptable d'associer des catégorie à +n'importe quel compte dans la mesure où il le jugerait utile. + +``Attributs :`` +--------------- + +- matcher : Le nom de la catégorie du client. + + + +``Project`` +=========== +``Description :`` +----------------- +Les projets sont un moyen de regrouper des écritures afin de réaliser des +recherches et des calculs de coûts associés à un projet précis. Ainsi un +comptable pourra réaliser une compta-analytique et connaître la rentabilité de +ses différents contrats. +A long terme ces informations relatives à un projet proviendront de Chorem ou +d'autre solutions purement de gestion de projet, ces informations seront importé +afin d'en faciliter l'analyse comptable. + +``Attributs :`` +--------------- + +- matcher : Le nom du projet. + +- uri : Une adresse vers laquelle sur laquelle pointera le projet Chorem relatif +à l'écriture ciblée. + + + +``Tax`` +======= +``Description :`` +----------------- +Permettra d'assigner un type d'impot à une écriture comptable (TVA, IS, Banque, +etc.). + +``Attributs :`` +--------------- + +- matcher : Un type de taxe. + + + +``Particularité des classes : User, TypePresta, Client, Project et Tax`` +======================================================================== +``Explication :`` +----------------- +Ces classes s'inscrivent dans une démarche de synchronisation des données entre +Callao et Chorem dans l'objectif de pouvoir catégoriser des données en fonctions +de ces cinq critères, fournis par Chorem. +Ces données seront en fait stockées dans l'attribut detail d'une instance d'Entry +afin dans une structure de données formatée CSV. +Par exemple : "user:dupont;user:martin;typePresta:dev;client:LM;projet:lima" Added: trunk/src/site/rst/callao/contact.rst =================================================================== --- trunk/src/site/rst/callao/contact.rst (rev 0) +++ trunk/src/site/rst/callao/contact.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,75 @@ +============ +Contact list +============ + +Pour contacter les membres du projet ou suivre son évolution, vous pouvez +utiliser les listes de diffusion du projet : + +- Liste utilisateurs : (..USERS_) Liste de discussions des utilisateurs de CALLAO_ +- Liste développeurs : (..DEVEL_) Liste de discussions des développeurs de CALLAO_ +- Liste des commits : (..COMMITS_) Liste des modifications du code de CALLAO_ + +======= +Support +======= + +.. image:: logo/codelutin.png + + +Code Lutin est une société de services en logiciels libres spécialisée dans les +technologies Java/J2EE, XML, UML. Son offre s'étend à l'audit, au conseil, à la +tierce maintenance applicative et à la formation. + +SARL Code Lutin +44 boulevard des Pas Enchantés +44230 Saint-Sébastien-Sur-Loire +France + +Contact : Benjamin Poussin, gérant et chef de projet. + +Tél : 02 40 50 29 28 + + +Code Lutin participe activement au mouvement du logiciel libre et fait partie du +consortium ObjectWeb, d'Alliance Libre et du réseau Libre-entreprise + + +Plus_. + +.. _Plus: http://www.codelutin.com + + + + +---------------- +Libre-entreprise +---------------- + +.. image:: http://www.csquad.org/stages/stage-tech3/img/libre-entreprise.jpeg + +Un regroupement de sociétés expertes en solutions libres + +Libre-entreprise est un réseau de sociétés de services en logiciel libre. Son +développement est fondé sur celui de la communauté du libre : mutualisation des +compétences et transparence. + + +SiteLibreEntreprise_. + +.. _SiteLibreEntreprise: http://www.libre-entreprise.com/index.php/Accueil + + +-------------- +Alliance Libre +-------------- + +.. image:: http://www.solago.com/images/logo_AL.png + +SiteAllianceLibre_. + +.. _SiteAllianceLibre: http://www.alliance-libre.org/ + +.. _USERS: http://list.chorem.org/cgi-bin/mailman/listinfo/callao-users +.. _DEVEL: http://list.chorem.org/cgi-bin/mailman/listinfo/callao-devel +.. _COMMITS: http://list.chorem.org/cgi-bin/mailman/listinfo/callao-commits +.. _CALLAO: http://maven-site.chorem.org/callao/ \ No newline at end of file Added: trunk/src/site/rst/callao/developpement.rst =================================================================== --- trunk/src/site/rst/callao/developpement.rst (rev 0) +++ trunk/src/site/rst/callao/developpement.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,82 @@ +============= +Développement +============= + +Nous utiliserons cette section pour fournir des informations concernant +l'avancement du développement du moteur Callao. + + +----------------------- +La génération via ToPIA +----------------------- + +A l'heure actuelle, la génération de code concerne uniquement la couche de +données via l'utilisation de ToPIA-persistence_ avec xmi pour la définition du +modèle, H2 pour la base de données, Hibernate pour la couche d'accès aux données, +et Java pour l'implémentation. +La construction et la génération du code du projet s'effectue directement via +Maven à l'aide de la commande de compilation : + +``mvn clean compile`` + +L'ensemble des paramètres commandant cette génération sont définis dans les +fichiers de configuration de Maven du super pom et du pom du module +''callao-entity''. Le modèle quant à lui est stocké dans un fichier ''zargo'', +toujours dans le module ''callao-entity'' et peut être consulté à l'aide +d' ArgoUML_ . +LIMA propose un certain nombre de services disponibles via des interfaces, le but +initial de CALLAO et de pouvoir implémenter ces services de manière locale ou +distante. L'utilisation de Web Services, comme mis en place pour effectuer la +communication entre LIMA et OFBiz constitue la solution à cette problématique. + + + +Néanmoins, pour le moment, les implémentation s'effectuent uniquement de manière +locale. CALLAO s'occupe uniquement d'implémenter les interfaces de LIMA situées +dans le module ''lima-service'' de manière locale, et les échanges de Web Services +n'ont pas encore été mis en place. + + + +Cependant, une configuration de la génération de cette couche de communication +par services a tout de même été effectuée via l'utilisation de ToPIA-soa_ . A ce +titre, un modèle des services est présent en parallèle du modèle entité dans le +module ''callao-entity''. Ce modèle décrit l'ensemble des services fournissant +l'application des règles métiers définies pour l'application CALLAO. Couplé à +ToPIA-soa_ , il permet la génération de cette couche et de ses interfaces associées. +Cependant une problèmatique de connection aux services de LIMA reste encore non +résolue. + + + +De même que pour la partie entity, la génération de la couche service est +commandée par Maven via la configuration du fichier pom du module +''callao-service''. + + + +------------------------------- +L'implémentation des interfaces +------------------------------- + +Les implémentations des interfaces services de LIMA dans CALLAO représentent les +fragments de code source de l'application qui vont définir les règles métiers. +L'ensemble de ce code source se situent dans le module ''callao-service'' et +s'occupe à l'heure actuelle d'implémenter uniquement localement les interfaces +services de LIMA. + + + +L'état d'avancement actuel de ces implémentations est inachevé. En effet, il +reste encore des améliorations à fournir à celles effectuées et à compléter +celles des classes ''Period'' et ''Journal'' pour pouvoir au moins répondre aux +interfaces services existantes de LIMA. De plus, notre modèle de services ne +reflétant pas entièrement celui de LIMA, il est fort à penser que LIMA aura à +intégrer de nouvelles fonctionnalités notamment au niveau de l'intégration à +Chorem, de la gestion des Imports Exports de sauvegardes et de la génération des +états comptables. + + +.. _ToPIA-persistence: http://topia.labs.libre-entreprise.org/topia/topia-persistence/ +.. _ToPIA-soa: http://topia.labs.libre-entreprise.org/topia/topia-soa/ +.. _ArgoUML: http://argouml.tigris.org/ Added: trunk/src/site/rst/callao/howto.rst =================================================================== --- trunk/src/site/rst/callao/howto.rst (rev 0) +++ trunk/src/site/rst/callao/howto.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,6 @@ + +============================ +Installer et démarrer Callao +============================ + +A venir \ No newline at end of file Added: trunk/src/site/rst/callao/index.rst =================================================================== --- trunk/src/site/rst/callao/index.rst (rev 0) +++ trunk/src/site/rst/callao/index.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,21 @@ + +================== +Callao +================== + +Issu du projet Chorem_, et créé pour fonctionner en collaboration avec LIMA_, +CALLAO_ est *un moteur de comptabilité générale* respectant les conventions +ainsi que normes imposées par la législation française aux entreprises. + +Ce rôle était jusqu'à alors remplis via le moteur de comptabilité d'OfBiz-Neogia, +CALLAO_ doit pouvoir se substituer à ce moteur mais sans refondre LIMA_ afin de +laisser aux utilisateurs de LIMA_ le choix du moteur de comptabilité qu'ils +utilisent ou de faciliter les migrations d'un moteur à l'autre [#]_. + + +---- + +.. [#] A cet effet des fonctions d'import et d'export seront mises en place. +.. _ChoreM: http://chorem.labs.libre-entreprise.org +.. _LIMA: http://maven-site.chorem.org/lima +.. _CALLAO: http://maven-site.chorem.org/callao Added: trunk/src/site/rst/callao/lexique.rst =================================================================== --- trunk/src/site/rst/callao/lexique.rst (rev 0) +++ trunk/src/site/rst/callao/lexique.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,127 @@ +========================== +Lexique de la comptabilité +========================== + +Nous définirons ici les quelques notions de comptabilité d'entreprise nécessaires +à l'appréhension du fonctionnement de CALLAO. + +``Actif :`` +----------- +L'actif d'une entreprise est l'ensemble de son patrimoine. Il comporte notamment +la trésorerie, les immobilisations et les créances (sommes dues par des tiers). + +``Bilan :`` +----------- +Le bilan est un état comptable, obligatoirement publié à l'issue de l'exercice +et déduit du Grand Livre. Il présente l'état des actifs (patrimoines, ou emplois +des ressources) et passifs (ressources, sous diverses formes de dettes) de +l'entreprise à une date donnée : la date de clôture de l'exercice. +On peut également établir un bilan provisoire avant la fin de l'exercice. + +``Compte :`` +------------ +Un compte est la plus petite unité retenue pour le classement des flux de valeur. +Il sera débité ou crédité pour symboliser certaines opérations. Il existe par +exemple des comptes de charges (Impôts sur les sociétés, Achats, Variations de +stocks...) qui sont débités lors de l'enregistrement d'une charge, des comptes +d'actifs (Immobilisations...), qui sont débités lors de l'enregistrement d'une +acquisition d'actif, etc. +La liste des comptes est données, en France, par le Plan Comptable Général. Ce +dernier définit, pour chaque compte, un numéro d'identifiant normalisé permettant +de l'identifier. On distingue 4 grands types de comptes : d'actif, de passif, de +charge et de produit. L'augmentation d'un compte de charge ou d'actif se traduit +par un débit du compte concerné (et sa diminution par un crédit). De même, +l'augmentation d'un compte de produit ou de passif se traduit par un crédit du +compte concerné (débit pour la diminution). +Ces comptes sont généralement représentés par deux colonnes (débit et crédit), +dans lesquelles sont consignées par ordre chronologique descendant les sommes +passées respectivement au débit et au crédit du compte. Cela leur donne une +forme de T, ce qui a donné naissance à l'appellation de compte en T. + +``Compte de résultat :`` +------------------------ +Le compte de résultat est un état comptable, obligatoirement publié à l'issue de +l'exercice et déduit du Grand Livre. Il oppose la liste des différentes charges +(pertes d'argent ou de valeur, que ce soit par consommation, par paiement de +taxes ou de salaires, par donations, par dépréciation d'actif...) à celle des +différents produits (gains d'argent, généralement par vente de produits finis ou +de marchandises). +Il met également en avant la différence entre les deux, qui représente le +résultat de l'entreprise pour l'exercice. Celui-ci peut être positif ou négatif, +suivant que la somme des produits dépasse celle des charges ou non. S'il est +positif, on parle alors de bénéfice qui pourra être redistribué aux actionnaires +(propriétaires) ou conservé pour financer l'activité. + +``Ecriture :`` +-------------- +Une écriture comptable représente tout simplement le débit ou le crédit d'un +compte. Elles sont passées par compte dans le Grand Livre, et rassemblées par +opérations dans le Journal. + +``Etats comptables :`` +---------------------- +Les états comptables sont des documents de synthèse déduits du Journal et du +Grand Livre et dont la publication est également obligatoire à la fin de +l'exercice. Ils fournissent des indications sur la santé de l'entreprise. Les +états sont, en France, le bilan, le compte de résultat et l'annexe. + +``Exercice :`` +-------------- +Un exercice est une période, généralement de un an, pour laquelle l'entreprise +établit sa comptabilité. A l'issu de l'exercice, l'entreprise doit publier sa +comptabilité concernant cette période. Une fois cette publication effectuée, +aucun retour en arrière ne peut être effectué. C'est pourquoi on considère qu'un +exercice, une fois fini, doit être clôturé, ce qui interdit alors toutes +modifications sur les informations comptables concernant cet exercice. + +``Grand Livre :`` +----------------- +Historiquement, le Grand Livre est le cahier où sont consignés tous les comptes +en T de l'entreprises (tableaux de deux colonnes, débit et crédit, consignant +les diverses écritures passées sur le compte), à raison d'un par page. + +``Journal :`` +------------- +Historiquement, le journal est le cahier où l'entreprise consigne par ordre +chronologique la trace de ses opérations comptables (transactions). Parfois, +celle-ci utilise plusieurs journaux (journal des achats, journal des stocks, +journal des ventes...) afin de séparer les différents types d'opération et de +mieux s'y retrouver, ou de diviser la responsabilité de la consignation des +transactions entre différentes personnes, chacune responsable d'un domaine +précis (achat, vente, stock...). On parle alors de comptabilité multi-journaux. + +``Passif :`` +------------ +Le passif d'une entreprise est l'ensemble des ressources de l'entreprise, sous +la forme de capitaux et de dettes. + +``Report à nouveau :`` +---------------------- +Historiquement, lors de la clôture d'un exercice comptable, on changeait de +cahiers (Journal et Grand Live) pour attaquer la consignation des opérations du +nouvel exercice. On soldait alors tous les comptes du Grand Livre en débitant +les comptes créditeurs et en créditant les comptes débiteurs de la valeur du +solde (différence entre débit et crédit) du compte. On effectuait alors +l'opération inverse en première opération du nouvel exercice. On appelle cette +opération un report à nouveau. +Dans notre cas, comme dans tous les logiciels de comptabilité, le report à +nouveau ne sera que partiellement effectué. Si CALLAO reportera bien le solde +des différents comptes sur l'exercice suivant, nous ne solderons pas l'exercice +précédent. + +``Transaction :`` +----------------- +Ce que nous appelons ici transaction désigne une opération comptable, c'est-à-dire +l'inscription au journal, à une date donnée, d'un certain nombre d'écritures de +débit et de crédit. Pour que l'opération soit équilibrée, il faut que la somme +des écritures de crédit (sur certains comptes) la composant soit égale à celle +des écritures de débit (sur d'autres comptes). C'est pourquoi on peut voir +l'ensemble comme une transaction entre plusieurs comptes. +Une transaction peut, par exemple, représenter une opération d'achat à un +fournisseur (Crédit du compte de "Achat", débit du compte "Fournisseur"), une +opération de vente à un client... Dans ce genre de cas, la réalité de l'opération +peut être prouvée à l'aide d'un justificatif, dont la référence sera inscrite +dans la comptabilité. +Historiquement, une transaction est inscrite au Journal (ou, pour la comptabilité +multi-journaux au journal concerné : journal des ventes, journal des achats...) +et ses écritures sont reportées au Grand Livre. \ No newline at end of file Added: trunk/src/site/rst/callao/news.rst =================================================================== --- trunk/src/site/rst/callao/news.rst (rev 0) +++ trunk/src/site/rst/callao/news.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,14 @@ +==== +News +==== + +Quoi de neuf sur le projet CALLAO ? + +Mise en Ligne du site +===================== + +``Par :`` Jean ``[le Jeudi 24 septembre 2009]`` + +Le site du projet est enfin en ligne, il faisait précédemment partie du site de +Lima, il est maintenant autonome et s'étoffera au fur et à mesure de l'avancée +du projet. \ No newline at end of file Added: trunk/src/site/rst/callao/roadmap.rst =================================================================== --- trunk/src/site/rst/callao/roadmap.rst (rev 0) +++ trunk/src/site/rst/callao/roadmap.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,9 @@ +======= +RoadMap +======= + ++-----------------------------------------------------------------------------------------+ +| **A venir** | ++-------------------+---------------------------------------------------------------------+ +| *Release* | Release d'une version packagée exécutable comprenant Lima et Callao | ++-------------------+---------------------------------------------------------------------+ Added: trunk/src/site/rst/callao/todo.rst =================================================================== --- trunk/src/site/rst/callao/todo.rst (rev 0) +++ trunk/src/site/rst/callao/todo.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,17 @@ +TODO +==== + +- suppression des DTOs et utilisation directe des entities +- suppression des convertObject qui du coup ne servent plus +- les services devrait plutot lever des exceptions au lieu de retourner des + codes d'erreur. (donc revoir la gestion des erreurs dans lima) +- les methodes de recherche devrait plutot etre dans les DAO que sur les + services +- certaine methode de service ne devrait pas exister (modifyAccount qui prend + en argument les differents champs de l'entity, est a remplacer simplement + par un store de l'entity) +- potentiellement il ne faudrait qu'un service CallaoService: + store(Object); load(Object); delete(Object); search(Criteria); search(????); + getReportList():List<String>; getReport(String name): html/pdf/data? + pas de: import(); export(); car c le job de lima ce qui uniformise les formats +- a quoi sert les UserSerice (ne faut-il pas plutot utiliser celui de Topia ?) Added: trunk/src/site/rst/callao/usecases.rst =================================================================== --- trunk/src/site/rst/callao/usecases.rst (rev 0) +++ trunk/src/site/rst/callao/usecases.rst 2010-03-30 14:15:15 UTC (rev 2819) @@ -0,0 +1,312 @@ +===================== +Les Cas d'Utilisation +===================== + +| Cette section présente les cas d'utilisation du moteur CALLAO couplé à LIMA. + +``Cas d'utilisation`` +===================== + +``Diagramme global`` +-------------------- + +| Afin d'optimiser la lisibilité des diagrammes, nous avons commencé par décrire les grandes groupes de fonctionnalités, avant d'entrer dans le détail des cas d'utilisation pour chacun. + +.. image:: uc/uc-base.png + +| On se retrouve donc avec 5 cas d'utilisation globaux : + +- Gérer Ecritures : Saisie et modification des écritures comptables. +- Gérer Périodes : Paramétrage et clôturage des exercice, gestion de la semi-clôture des intervalles de temps. +- Gérer Comptes : Ajout et modification des comptes. +- Gérer Fichiers : Import et export des données. +- Générer Etats : Génération d'états comptables sous forme imprimable, ainsi que des journaux et du grand livre. +- Synchronier Chorem : Cette fonctionnalité ne correspond pas vraiment à un cas d'utilisation inhérent à LIMA-CALLAO, mais plus à une possibilité d'accès à certaines données qui doit être prévue pour une synchronisation entre CALLAO et Chorem via un logiciel tiers (qui est néanmoins détaillé ici). + +``Gérer Ecritures`` +------------------- +.. image:: uc/uc-journal.png +| Le diagramme parle de lui-même. Il faudra être vigilent à ne pas pouvoir ajouter d'écriture dans un exercice non encore ouvert ou déjà verrouillé. Il en va de même pour les modification et les suppression. + + + +| **Cas d'utilisation** : Ajouter Écriture étend : Ajouter Transaction; Gérer Ecritures +| Acteur principal : Comptable +| Invariants : + +- Une écriture (Entry) appartient à une transaction. +- Toute opération (par extension tout ajout) sur une écriture (Entry) est répertoriée dans un Log. +- On ne peut ajouter d'entrée à un exercice (Period) ou un intervalle de temps (TimeSpan) clôturé ou inexistant. +| Scénario +| Cas 1 : Ajout d'une écriture dans une transaction non existante pour un intervalle de temps (TimeSpan) non clôturé : +| Préconditions : + +- L'entrée à créer n'appartient pas à une transaction déjà existante. +- La date entrée pour cette transaction correspond à l'intervalle de temps en cours ou à un intervalle non clôturé. +| Résultat : + +- Une nouvelle entrée est créée et répertoriée dans une nouvelle transaction, elle-même répertoriée dans un journal donné et dans l'intervalle de temps correspondant à la date donnée pour la transaction. +- Cet ajout d'entrée est consigné dans un nouveau Log. +| Description : + +- Une nouvelle transaction est créée, avec pour attributs les valeurs de la date et de la référence justificatif entrée dans l'interface. +- Elle est ajoutée au journal depuis lequel l'utilisateur l'a créée (menu déroulant de l'interface), ainsi que dans l'intervalle de temps correspondant à la date donnée. +- L'entrée est créée avec les données saisies (description, montant, débit, lettrage, compte) et ajoutée à la nouvelle transaction. Un Log est également créé, consignant la date courante (date de modif), la date donnée pour la transaction, le type d'opération (en l'occurrence, ajout) et les attributs de l'écriture et de la transaction. +| Cas 2 : Ajout d'une écriture dans une transaction existante pour un intervalle de temps (TimeSpan) non clôturé : +| Préconditions : + +- L'entrée à créer appartient à une transaction déjà existante. +- La date entrée pour cette transaction correspond à l'intervalle de temps en cours ou à un intervalle non clôturé. +| Résultat : + +- Une nouvelle entrée est créée dans une transaction existante. Cet ajout d'entrée est consigné dans un nouveau Log. +| Description : + +- L'entrée est créée avec les données saisies (description, montant, débit, lettrage, compte) et ajoutée à la transaction donnée. +- Un Log est également créé, consignant la date courante (date de modif), la date donnée pour la transaction, le type d'opération (en l'occurrence, ajout) et les attributs de l'écriture. +| Exceptions +| Exception1 : Ajout d'une écriture pour un exercice à venir n'existant pas encore. +| Préconditions : + +- La date de la transaction correspondant à l'entrée ne correspond à aucun exercice existant. +| Résultat : Rien. +| Description : + +- Un message est affiché pour indiquer à l'utilisateur la démarche à suivre pour créer un nouvel exercice. +| Exception 2 : Ajout d'une écriture pour un exercice (Period) ou un intervalle de temps (TimeSpan) clôturé. +| Préconditions : + +- La date de la transaction correspondant à l'entrée appartient à un exercice ou un IT clôturé. +| Résultat : Rien. +| Description : + +- Un message d'erreur est affiché, indiquant à l'utilisateur qu'il ne peut effectuer l'opération d'ajout. + +| **Cas d'utilisation **: Modifier Ecriture étend : Gérer Ecritures +| Acteur principal : Comptable +| Invariants : + +- Une écriture (Entry) ne migre pas d'une transaction à l'autre. +- Toute opération (par extension toute modification sur une écriture (Entry) est répertoriée dans un Log. +- On ne peut migrer une entrée vers un exercice (Period) ou un intervalle de temps (TimeSpan) clôturé ou inexistant. + +| Scénario : +| Cas 1 : Modification d'une écriture pour un intervalle de temps (TimeSpan) non clôturé : +| Pré-conditions : + +- L'entrée à créer n'appartient pas à une transaction déjà existante. +- La date entrée pour cette transaction correspond à l'intervalle de temps en cours ou à un intervalle non clôturé. +| Résultat : + +- Une nouvelle entrée est créée et répertoriée dans une nouvelle transaction, elle-même répertoriée dans un journal donné et dans l'intervalle de temps correspondant à la date donnée pour la transaction. +- Cet ajout d'entrée est consigné dans un nouveau Log. +| Description : + +- L'entrée est modifiée avec les données nouvellement saisies (description, montant, débit, lettrage, compte). +- Un Log est également créé, consignant la date courante (date de modif), la date donnée pour la transaction, le type d'opération (en l'occurrence, modification) et les attributs de l'écriture et de la transaction. +| Exceptions +| Exception1 : Modification d'une écriture pour un intervalle de temps clôturé. +| Pré-conditions : + +- La date de la transaction correspondant à l'entrée correspond à un intervalle de temps semi-clôturé, voire à un exercice clôturé. +| Résultat : Rien. +| Description : + +- Un message d'erreur est affiché, indiquant à l'utilisateur qu'il ne peut effectuer l'opération de modification. + +| La suppression d'écriture se comporte de manière analogue à la modification, c'est pourquoi nous ne la détaillerons pas ici. Notons juste que si la dernière écriture restant dans une transaction est supprimée, celle-ci sera également supprimée. + +| +| **Cas d'utilisation** : Modifier Transaction étend : Gérer Transactions +| Acteur principal : Comptable +| Invariants : + +- Aucune transaction ne peut être déplacée dans une période clôturée ou un intervalle de temps semi-clôturé, ni dans un exercice n'existant pas. +| scénario +| Cas 1 : Modification du voucherRef ou de la date vers un intervalle de temps existant et non-clôturé : +| Pré-conditions : + +- La transaction n'appartient pas à un intervalle de temps clôturé. +- La date n'est pas modifiée pour une date concernant un intervalle de temps non existant ou clôturé. +| Résultat : + +- La transaction est modifiée. +- Un nouveau log est créé pour chacune des Entry de la Transaction. +| Description : + +- La transaction est modifiée avec les données nouvellement saisies (description, montant, débit, lettrage, compte). +- Pour chacune des écritures de la transaction, un Log est également créé, consignant la date courante (date de modif), la date donnée pour la transaction, le type d'opération (en l'occurrence, modification) et les attributs de l'écriture et de la transaction. +| Exceptions +| Exception1 : Modification d'une transaction dans un intervalle de temps clôturé. +| Pré-conditions : + +- La date de la transaction correspond à un intervalle de temps semi-clôturé, voire à un exercice clôturé. +| Résultat : Rien. +| Description : +- Un message d'erreur est affiché, indiquant à l'utilisateur qu'il ne peut effectuer l'opération de modification. +| Exception2 : Modification de la date de la transaction vers un intervalle de temps clôturé. +| Pré-conditions : +- La nouvelle date donnée pour la transaction correspond à un intervalle de temps semi-clôturé, voire à un exercice clôturé. +| Résultat : Rien. +| Description : +- Un message d'erreur est affiché, indiquant à l'utilisateur qu'il ne peut effectuer l'opération de modification. + + +``Gérer Périodes`` +------------------ +.. image:: uc/uc-exercice.png +| Lors de l'ouverture d'un exercice, il est automatiquement divisé en TimeSpan (qui représenteront des mois en pratique). Ces TimeSpan sont verrouillables, de manière à accéder à un état proche de la clôture, mais où il reste possible de les déverrouiller, ce afin d'éviter d'éventuelles erreurs de saisie. La clôture d'un exercice entraîne la fermeture (définitive cette fois) de tous les TimeSpan qui le composent. A noter également qu'un TimeSpan ne peut être ouvert qu'à la condition que tous les TS posterieurs le soient aussi (et consecutivement un TS ne peut être semi-cloturé que si les TS anterieurs le sont aussi. +| +| **Cas d'utilisation** : UC Ouvrir Nouvel Exercice étend l'UC « cloture de periode » +| Acteur principal : Comptable. +| Invariant + +- Il ne peut jamais y avoir plus de deux exercices non clôturer en même temps. +| Scénario +| Cas 1: Création d'un exercice(Period). +| Pré-condition : + +- L'exercice ne doit pas être déjà créer. +| Description : + +- La création d'un nouvel exercice à besoin de connaitre la durée de ce nouvel exercice. +- Par défaut cette période est de 12 mois. +- Pour chaque mois, on crée un intervalle de temps. +- On réalise les différents report à nouveau pour équilibrer l'exercice précèdent et commencer avec les bons chiffre l'exercice nouvellement créer. +| Post-condition : + +- L'intégralité de l'exercice est couvert par des intervalles de temps. +- La date de début d'exercice et la date de fin de l'exercice précédent se suivent. + +| Cas d'utilisation : UC Clôturer Exercice étend l'UC « cloture de periode » +| Acteur principal : Comptable. +| Scénario +| Cas 1: Clôture d'un exercice(Period). +| Pré-condition : + +- L'exercice ne doit pas être déjà clôturé. +- La date de fin d'exercice doit être atteinte pour pouvoir clôturer l'exercice. +| Description : + +- La clôture de l'exercice entraine la clôture définitive de l'ensemble des intervalles de temps qui le compose. +- Les opérations de l'exercice ne sont plus éditables. +- Il est alors possible de publier les documents comptables (ex: bilan, compte de résultat). +- Les reports à nouveau sont calculés et passés sur l'exercice suivant. +- Un backup de l'exercice est alors généré. +| Post-condition : + +- L'ensemble des écritures n'est modifiable depuis Callao. + + +| **Cas d'utilisation** : UC Semi-clôturer Intervalle de Temps (Cet UC est étendu par l'UC « création de période ») +| Acteur principal : Comptable. +| Invariant + +- Toutes les périodes d'un exercice clôturé sont clôturé. +- Un intervalle de temps dure 1 mois +| Scénario + +- Cas 1: Clôture d'un intervalle de temps(TimeSpan). +| Pré-condition : +- L'intervalle de temps ne doit pas être déjà clôturé. +- La date de fin de période doit être supérieure à la date de début de la période à clôturer. +| Description : + +- Lorsque l'utilisateur clôture l'intervalle, l'ensemble des écritures du mois sont bloquées. +- S'ils ne le sont pas déjà, l'ensemble des mois précédents sont clôturés. +- L'utilisateur a toujours la possibilité de débloquer cet intervalle tant que +l'exercice n'est pas clôturé lui même. +| Post-condition : + +- L'ensemble des écritures n'est plus modifiable depuis Callao. +- Les périodes précédents cet intervalle sont clôturés. +| Cas 2: Dé-clôturer un intervalle de temps. +| Pré-condition : + +- L'intervalle de temps doit être clôturer. +- L'exercice dont il fait parti ne doit pas être clôturer. +| Description : + +- L'intervalle de temps redevient modifiable par l'utilisateur. +- Le comptable peut alors ajouter, modifier ou supprimer des transactions sur cet intervalle. +- Tout les intervalles de temps qui le suivent sont dé-clôturés, si ils sont déjà clôturés. +- L'intervalle est de nouveau clôturable. +| Post-Condition : +- Les écritures sont de nouveaux modifiables, les périodes suivantes sont dé-clôturés. + + +``Gérer Comptes`` +----------------- +.. image:: uc/uc-comptes.png +| La seule petite particularité de ces cas d'utilisation est qu'on ne pourra pas modifier le numéro ou supprimer un compte sur lequel des écritures ont été passées. + +``Gérer Fichiers`` +------------------ +.. image:: uc/uc-fichiers.png +Génère des fichiers pour sauvegarder ou échanger les données. + +| **Cas d'utilisation** : UC Exporter vers Fichiers +| Acteur principal : Comptable. +| Scénario +| Cas 1: Export d'un exercice comptable. +| Description : + +- Récupération de l'ensemble des données. +- Un fichier est crée avec l'ensemble des paramètres de l'application. Il comprend : +- les données relatives à l'entreprise (siret, raison sociale...) +- les comptes de l'entreprise +- les journaux +- Les exercices de l'entreprise.(Intervalle de temps, transactions, écritures...) +| Post-condition : + +- Un fichier XML valide est généré. + +| **Cas d'utilisation** : UC Importer depuis Fichiers +| Acteur principal : Comptable. +| Scénario +| Cas 1: Import de données +| Description : + +- L'utilisateur spécifie le chemin du fichier à importer. +- Le fichier est parsé, on supprime l'ensemble des données de la base +- On enregistre dans la base de données les informations récupérer du fichier. +| Cas exceptionnels +| Cas Exceptionnel 1 : Le fichier spécifier n'est pas valide ou n'existe pas. +| Description : + +- Un message d'erreur est affiché. +- La base de données n'est pas changer. + + +``Générer Etats`` +----------------- +.. image:: uc/uc-etats.png +| On aura une génération d'états provisoires pour les périodes non clôturées, et définitif pour les périodes clôturées. On prévoit pour l'instant une génération en PDF. Cette génération pourra être effectuée à n'importe quel moment. + +| **Cas d'utilisation** : UC Générer état +| Acteur principal : Comptable. +| Invariants + +- Un état concerne un seul exercice. +- Un état sera prévisionnel tant que l'exercice concerné ne sera pas clôturé. +| Scénario +| Cas 1: Génération d'un état(Bilan, compte de résultat...). +| Pré-condition : + +- Il faut que l'exercice existe pour pouvoir générer un état. +| Description : + +- On solde les comptes concernés ( ex :produit et charge pour compte de résultat... ). +- On les affectes aux champs de l'état comptable. +- On récupère les informations sur la société ( numéro siren, raison sociale...) +- On exporte dans un fichier au format pdf dont le chemin est prédéfini, l'état concerné. +- Si l'état n'est pas clôturé, le fichier indique que c'est un état prévisionnel. +| Post-condition : + +- Un fichier pdf est créé. + + +``Synchronier Chorem`` +---------------------- +.. image:: uc/uc-liaison.png +| Cette liaison permet de récupérer des informations de facturation depuis Chorem afin de les passer en écriture dans Lima/Callao, de fait cette "couche de liaison" disposera d'informations persistantes de manière à associer les clients de Chorem à des comptes (client tartenpion = 4111tartenpion etc ...) et de répercuter les domaines tout en sachant aussi éviter les redondances et faciliter les corrections. Une fois les informations éxtraite de Chorem et les données de liaison mises à jour, ces données pourront être poussées dans Lima/Callao.