FR2822978A1

FR2822978A1 - Dispositif de traitement de donnees comptables locales de formats differents, et installation et procede de traitement de donnees associes

Info

Publication number: FR2822978A1
Application number: FR0104402A
Authority: FR
Inventors: Angel Fuentes
Original assignee: Financial & Accounting Intergr
Current assignee: Financial & Accounting Intergr
Priority date: 2001-03-30
Filing date: 2001-03-30
Publication date: 2002-10-04
Anticipated expiration: 2021-03-30
Also published as: FR2822978B1

Abstract

Un dispositif de traitement de données comptables comprend i) un module de supervision (9) comportant une mémoire (10) stockant des données d'identification de terminaux locaux, équipés chacun d'un module logiciel comptable local délivrant des données d'écritures comptables détaillées, selon un format local, et accompagnées de données d'identification, et propre à recevoir les données comptables détaillées et locales et les données d'identification transmises sur un réseau de télécommunications par les terminaux locaux, et pour communiquer les données d'écritures comptables détaillées et locales lorsqu'elles sont accompagnées par des données d'identification stockées dans la mémoire (10), et ii) un module d'interfaçage (11) pour convertir des données d'écritures comptables détaillées et locales, communiquées par le module de supervision (9), en données d'écritures comptables détaillées et locales au format d'une base de données (4), en vue de leur mémorisation dans une première zone locale choisie (12) de la base de données.

Description

DISPOSITIF DE TRAITEMENT DE DONNEES COMPTABLES LOCALES DE FORMATS DIFFERENT, ET INSTALLATION ET PROCEDE DE TRAITEMENT DE DONNEES ASSOCIES
L'invention concerne le domaine du traitement de données d'écritures comptables de formats variables.

De nombreux groupes, notamment internationaux, sont constitués d'une multiplicité de sociétés locales}}, ou d'entités, dont les comptabilités locales respectives dépendent des spécificités et obligations légales et fiscales des pays dans lesquelles elles sont implantées. Ces comptabilités locales présentant des formats locaux généralement différents les uns des autres et différents du format de la comptabilité du groupe, il est particulièrement difficile, voire impossible, de transférer automatiquement vers le groupe les données comptables locales, des sociétés locales, en vue de la tenue et de la production de comptes consolidés, dits comptes groupe .

De ce fait, les sociétés locales doivent généralement communiquer au groupe leurs données d'écritures comptables locales sur un support papier, afin qu'elles soient saisies manuellement, parfois après un premier traitement. Mais, en raison du nombre très important de données d'écritures comptables (locales) détaillées, générées par chaque société locale, celle-ci ne communique généralement au groupe que ses données d'écritures comptables (locales) de synthèse. Par conséquent, les groupes et leurs experts comptables et auditeurs ne peuvent ni contrôler, ni assurer la traçabilité, ni même analyser les opérations comptables des sociétés locales.

Il n'est pas non plus possible d'effectuer une gestion délocalisée, automatisée, des opérations comptables locales des sociétés locales d'un groupe.

Ces inconvénients sont encore renforcés par le fait que les sociétés locales utilisent des devises différentes et/ou des logiciels de comptabilité différents pour générer leurs écritures comptables locales.

L'invention a donc pour but de résoudre tout ou partie des inconvénients précités.

Elle propose à cet effet un dispositif de traitement de données comptables comprenant : * un module de supervision équipé d'une mémoire pour stocker des données d'identification de terminaux locaux (associés à des sociétés locales), chaque terminal étant équipé d'un module logiciel comptable local (par exemple un ERP) délivrant des données représentatives d'écritures comptables détaillées, selon un format local (lié aux spécifications et obligations fiscales et légales), et accompagnées de données d'identification, en vue de leur transmission sur un réseau de télécommunications (public, par exemple de type Internet, ou privé, par exemple de type Intranet), ledit module de supervision étant raccordé au réseau de télécommunications de manière à pouvoir recevoir les données comptables détaillées et locales et lesdites données d'identification transmises par les terminaux locaux, et à les communiquer lorsqu'elles sont accompagnées par des données d'identification stockées dans la mémoire, et * un module d'interfaçage permettant de convertir les données d'écritures comptables détaillées et locales, communiquées par le module de supervision, en données d'écritures comptables détaillées et locales, au format d'une base de données, en vue de leur mémorisation dans une première zone locale choisie de cette base de données.

De la sorte, chaque société locale peut continuer à utiliser son logiciel comptable, qui est adapté aux spécifications et obligations fiscales et légales du pays dans lequel elle est implantée, le dispositif selon l'invention se chargeant d'homogénéiser, de façon centralisée, au format de la base de données, toutes les données d'écritures comptables détaillées et locales transmises, par voie électronique ou numérique, par les différents terminaux locaux. Une fois l'homogénéisation effectuée, il devient alors possible de procéder à tout type de traitement comptable et financier sur les données

stockées dans la base de données.

Le format local des données d'écritures comptables détaillées et locales, qui sont transmises par un terminal local au module de supervision, porte de préférence sur un plan de comptes local et/ou une devise locale et/ou des journaux locaux.

Selon une autre caractéristique de l'invention, le module d'interfaçage comporte une mémoire dans laquelle sont stockées des tables de correspondance entre les formats locaux de chaque terminal local et le format de la base de données, de manière à effectuer la conversion.

Selon encore une autre caractéristique, et afin de permettre le traitement des données locales stockées au format de la base, le dispositif pourra comporter les caractéristiques suivantes, prises séparément et en combinaison : * un module de sommation locale capable d'extraire de la première zone locale de la base de données certaines au moins des données d'écritures comptables détaillées et locales, stockées au format de la base et associées à un unique terminal local, puis de générer à partir des données extraites des données d'écritures comptables locales de synthèse associées au terminal local concerné, et au format de la base, et enfin de stocker ces données locales de synthèse dans une seconde zone locale de la base de données ; * un module de filtrage permettant d'extraire de la première zone locale les données d'écritures comptables détaillées et locales, stockées au format de la base et associées à chaque terminal local, puis de convertir les données extraites en données d'écritures comptables détaillées dans un format global (ou format groupe , en référence au groupe auquel appartiennent les sociétés), et enfin de stocker ces données détaillées globales dans une première zone globale de la base de données. Dans ce cas, il est avantageux de prévoir un module de sommation globale capable d'extraire de la première zone globale certaines au moins de ses données d'écritures comptables détaillées et globales associées à un même terminal local, puis

de générer à partir de ces données extraites des données d'écritures comptables globales de synthèse, associées au terminal local concerné et au format global, et enfin de stocker ces données locales de synthèse dans une seconde zone globale de la base de données. Préférentiellement, le format global (ou format de groupe) des données de synthèse, stockées dans la seconde zone globale de la base de données, porte sur un plan de comptes global et/ou une devise globale et/ou des journaux globaux ; * un module d'exportation permettant de transmettre à un terminal global qui en fait la requête, et notamment à son module logiciel comptable global, certaines au moins des données détaillées et/ou de synthèse globales qui sont stockées dans les première et seconde zones globales.

* un module de supervision pouvant en outre recevoir du terminal global, via un réseau de télécommunications (éventuellement le même que celui utilisé par les terminaux locaux, mais pas nécessairement), des données d'écritures comptables détaillées au format global, associées à un terminal local, et accompagnées par les données d'identification du terminal global. Bien entendu, dans ce cas la mémoire du module de supervision stocke les données d'identification des terminaux globaux. Le module de supervision peut ensuite communiquer au module d'interfaçage les données comptables détaillées au format global qu'il reçoit du terminal global lorsqu'elles sont accompagnées par des données d'identification stockées dans la mémoire, de sorte qu'elles puissent être stockées dans la base de données ; * un module de filtrage pouvant en outre extraire de la première zone globale, sur requête, des données d'écritures comptables détaillées au format global et associées à chaque terminal local, puis convertir ces données extraites en données d'écritures comptables détaillées et locales au format de la base, et enfin stocker ces données détaillées locales dans la première zone locale de la base de données ; * des modules de liaisons implantables dans chaque terminal local ou global, destinés à être alimentés en données d'écritures comptables détaillées par leur module logiciel comptable, comprenant chacun une mémoire dans

laquelle est stockée l'adresse du module de supervision pour lui transmettre de façon automatisée les données reçues, via le réseau de télécommunications. Avantageusement, le module de liaison implanté dans chaque terminal place les données d'écritures comptables détaillées et locales dans des champs de données séparés les uns des autres par des indicateurs de champs, puis il constitue un fichier comportant les données et les indicateurs, et enfin il transmet le fichier au module de supervision. A réception du fichier, le module d'interfaçage détecte les indicateurs de champs de manière à effectuer la conversion des données. Il est également particulièrement avantageux que le module de liaison soit capable d'adresser au module de supervision un message signalant chaque modification de plan de comptes local et/ou de journal local. Dans ce cas, le module d'interface est capable de modifier, si cela s'impose, le format de la base lorsqu'il reçoit un message de modification de plan de comptes et/ou de journaux l'impose. Bien entendu, l'acceptation de la modification peut dépendre d'une confirmation de la part du terminal local ; * un module de saisie permettant, en fonction d'autorisations délivrées par un administrateur, d'une part, la saisie d'évènements transformables ultérieurement en écritures comptables par une utilisateur habilité, et d'autre part, la saisie directement dans la base de données d'écritures modifiant ou complétant des données reçues de sociétés locales, cette saisie pouvant s'effectuer dans un format local ou dans un format groupe.

Le dispositif selon l'invention, à l'exception des modules de liaison qui sont implantés dans les terminaux locaux et globaux, est de préférence implanté dans un serveur informatique raccordé à un ou plusieurs réseaux de télécommunications et à la base de données. Tous ses modules, y compris les modules de liaison, peuvent être réalisés sous la forme de circuits électroniques ( hardware))) et/ou de modules logiciels ( software ).

L'invention concerne également une installation de traitement de données comptables comprenant i) un dispositif du type de celui présenté ci-

avant, raccordé à au moins un réseau de télécommunications, une base de données, raccordée au dispositif, pour stocker des données comptables selon un format de base choisi, ii) au moins deux terminaux locaux comprenant chacun un module logiciel comptable local pour délivrer des données représentatives d'écritures comptables détaillées, selon un format local et accompagnées de données d'identification, et raccordés chacun audit réseau de télécommunications, et iii) au moins un terminal global raccordé au réseau de télécommunications.

L'invention concerne en outre un procédé de traitement de données comptables comprenant au moins les étapes suivantes : a) prévoir un dispositif de traitement de données raccordé à un réseau de télécommunications et à une base de données comptables stockées selon un format de base choisi, et au moins deux terminaux locaux raccordés au réseau et comprenant chacun un module logiciel comptable local qui délivre des données représentatives d'écritures comptables détaillées, selon un format local, b) stocker dans une mémoire du dispositif les données d'identification des terminaux locaux, c) établir une liaison, via le réseau, entre un terminal local et le dispositif, pour transmettre à ce dispositif des données comptables détaillées et locales accompagnées de données d'identification, d) convertir les données d'écritures comptables détaillées et locales, qui sont accompagnées par des données d'identification stockées dans la mémoire, en données d'écritures comptables détaillées et locales au format de la base de données, puis mémoriser ces données dans une première zone locale choisie de la base de données.

Le procédé pourra comporter d'autres étapes, prises séparément et en combinaison, ou bien des compléments d'étapes a) à d), et notamment : * à l'étape b), on stocke des tables de correspondance entre les formats locaux des terminaux locaux et le format de la base de données, de manière à effectuer ladite conversion de l'étape d) ;

* une étape e) dans laquelle on extrait de la première zone locale certaines au moins des données d'écritures comptables détaillées et locales, au format de la base et associées à un unique terminal local, puis on génère à partir des données extraites des données d'écritures comptables locales de synthèse associées au terminal local et au format de la base, et enfin on stocke ces données locales de synthèse dans une seconde zone locale de la base de données ; * une étape f) dans laquelle on extrait de la première zone locale les données d'écritures comptables détaillées et locales, au format de la base, associées à chaque terminal local, puis on convertit ces données extraites en données d'écritures comptables détaillées dans un format global, et enfin on stocke ces données détaillées globales dans une première zone globale de la base de données. Dans cette étape f) on peut répartir certaines données d'écritures comptables appartenant à certains plans de comptes locaux dans au moins deux plans de comptes globaux.

* une étape g) dans laquelle on extrait de la première zone globale certaines au moins des données d'écritures comptables détaillées et globales associées à un même terminal local, puis on génère à partir des données extraites des données d'écritures comptables globales de synthèse associées au terminal local et au format global, et enfin on stocke ces données locales de synthèse dans une seconde zone globale de la base de données ; * une étape i) dans laquelle on extrait, sur requête d'un terminal global identifiable par des données d'identification, certaines au moins des données détaillées et/ou de synthèse globales stockées dans les première et seconde zones globales, puis on transmet ces données extraites au terminal global requérant. On peut ensuite prévoir une étape j) dans laquelle le terminal global transmet au dispositif, via un réseau de télécommunications, des données d'écritures comptables détaillées au format global, associées à un terminal local, et accompagnées par ses données d'identification. Cette étape j) peut également être suivie d'une étape k) dans laquelle on stocke

les données comptables reçues dans ladite première zone globale de la base de données. Bien entendu, cette étape ne peut être effectuée qu'à condition que l'on ait stocké à l'étape b), dans la mémoire, les données d'identification des terminaux globaux ; * une étape 1) dans laquelle on extrait de ladite première zone globale des données d'écritures comptables détaillées au format global, associées à l'un des terminaux locaux, puis on convertit ces données extraites en données d'écritures comptables détaillées et locales au format de la base, et enfin on stocke ces données détaillées locales dans la première zone locale de la base de données ; * à l'étape c) on peut placer les données d'écritures comptables détaillées et locales dans des champs de données séparés les uns des autres par des indicateurs de champs, puis constituer un fichier comportant les données et indicateurs, puis transmettre le fichier au dispositif, de sorte qu'à l'étape d) on puisse effectuer la conversion après détection des indicateurs de champs ; * une étape m) dans laquelle on adresse au dispositif un message signalant chaque modification du plan de comptes local et/ou d'un journal local. Dans ce cas, on peut prévoir, en sortie d'une étape m), une étape n) dans laquelle on modifie le format de la base lorsque la modification de plan de comptes et/ou de journal l'impose. On peut également requérir à l'étape n), du terminal local qui a émis un message de modification, une confirmation de modification, avant de procéder à la modification définitive du format de la base ; * une étape o) dans laquelle on convertit, sur requête, des données d'écritures comptables détaillées et locales au format de la base, stockées dans la première zone locale, en association avec un terminal local, en données d'écritures comptables détaillées et locales, puis on transmet ces données converties à un terminal local désigné dans la requête.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur

lesquels : - la figure 1 illustre de façon très schématique une installation selon l'invention, - la figure 2 est un diagramme bloc illustrant de façon très schématique une partie d'un dispositif selon l'invention, - la figure 3 est un algorithme illustrant un transfert de fichier entre un terminal local et un serveur dans lequel est implanté le dispositif selon l'invention, - la figure 4 est un algorithme illustrant une exportation de fichier entre le serveur, dans lequel est implanté le dispositif selon l'invention, et un terminal groupe, - la figure 5 est un algorithme illustrant un transfert de fichier retraité après exportation, entre un terminal groupe et le serveur dans lequel est implanté le dispositif selon l'invention, et - la figure 6 est un algorithme illustrant une saisie de données à l'aide d'un module de saisie du dispositif selon l'invention.

Les dessins annexés sont, pour l'essentiel, de caractère certain. En conséquence, ils pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant.

Dans la description qui suit, il sera fait référence à une installation de traitement de données comptables, du type de celle illustrée sur la figure 1.

Plus précisément, cet exemple d'installation est dédié à un groupe de sociétés constitué d'une multiplicité de sociétés dites locales, matérialisées ici, chacune, par un terminal local 1-i (i=1 à 3 dans cet exemple), et à une société mère (ou groupe, ou encore holding) matérialisée par un terminal groupe 2 (ou terminal global).

Les terminaux locaux 1-i et le terminal groupe 2 sont raccordés à un réseau de télécommunications, qui peut être public, comme par exemple Internet, ou privé, par exemple de type Intrant.

Par ailleurs, l'installation selon l'invention comporte un serveur informatique 3 qui gère une base de données 4, et qui est également

raccordée au réseau de télécommunications. Ce serveur est géré par un administrateur.

Dans une variante, les terminaux locaux 1-i peuvent être raccordés à un réseau public, par exemple Internet, tandis que le terminal groupe 2 est raccordé au serveur 3 soit via un réseau privé, par exemple de type Intrant, soit directement par une liaison filaire.

Enfin, l'installation peut également comporter un ou plusieurs terminaux auxiliaires 5, par exemple pour les expertises ou les audits externes, raccordés au réseau de télécommunications et/ou au terminal groupe 2.

Dans la suite, on considérera que tous les terminaux sont raccordés à un seul et même réseau de télécommunications, privé, de type Intrant.

Chaque terminal local 1-i est équipé d'un logiciel (ou progiciel) de comptabilité 6-1, comme par exemple un ERP ( Entreprise Resource Planning ), en formant ainsi ce que l'homme de l'art appelle une application comptable. L'ERP qui est implanté dans un terminal local 1-i est adapté aux spécificités et obligations légales et fiscales du pays dans lequel est implantée la société locale. Ainsi, chaque société locale peut utiliser un ERP local adapté à ses besoins spécifiques. Un tel ERP local 6-i peut délivrer des données d'écritures comptables détaillées et des données d'écritures comptables de synthèse selon un format local, comme cela est bien connu de l'homme de l'art. Bien entendu, ces ERP délivrent des données comptables dans la devise du pays.

De même, le terminal groupe 2 est équipé d'un progiciel comptable groupe 7, tel qu'un ERP groupe, destiné à délivrer des données d'écritures comptables détaillées et des données d'écritures comptables de synthèse au format du groupe.

L'invention a notamment pour but de permettre l'utilisation par le terminal groupe 2, ainsi qu'éventuellement par les terminaux auxiliaires 5, de toutes les données d'écritures comptables, qu'elles soient détaillées ou de synthèse, délivrées par les ERP locales 6-i des sociétés locales.

Pour ce faire, on prévoit un dispositif de traitement de données comptables, qui est, comme on le verra plus loin, quasiment totalement implanté dans le serveur 3.

Le dispositif selon l'invention, qui est illustré à titre d'exemple non limitatif sur la figure 2, comporte tout d'abord un module de supervision 9 qui est préférentiellement implanté dans le serveur 3. Ce module de supervision 9 est destiné à assurer les liaisons entre les terminaux locaux 1-i et le terminal groupe 2 via le (ou les) réseau (x). Il comporte préférentiellement une mémoire 10 dans laquelle se trouvent stockées les données d'identification (ou identifiants) des terminaux locaux 1-i et du terminal groupe 2, ainsi qu'éventuellement ceux des terminaux auxiliaires 5 lorsque ceux-ci sont raccordés au réseau et autorisés à interroger la base de données 4. Ces données d'identification sont de préférence accompagnées des adresses respectives des terminaux.

Le module de supervision 9 est par conséquent alimenté en données par le réseau. Il peut ainsi recevoir les fichiers comptables émis notamment par les terminaux locaux 1-i ou groupe 2, et vérifier si ces fichiers sont accompagnés par leurs identifiants en comparant les données d'identification qui accompagnent les fichiers reçus aux identifiants stockés dans la mémoire 10.

Lorsque l'identifiant reçu correspond effectivement à un identifiant connu et stocké, le module de supervision 9 communique les données comptables du fichier à un module d'interfaçage 11 destiné à convertir (ou homogénéiser) les données d'écritures comptables détaillées, qui sont reçues selon le format local du terminal local 1-i (du fait de l'utilisation de son ERP local 6-i), en données d'écritures comptables détaillées et locales, au format de la base de données 4, et plus précisément au format choisi par le groupe pour leur stockage dans la base 4. Le format de la base de données peut être fixe ou paramétrable par l'administrateur, via le dispositif.

Une fois ces données détaillées et locales converties au format de la base, elles sont stockées dans une première zone 12, dite locale, de la base

de données 4. Ces données peuvent alors faire l'objet de deux types de traitement. Un premier type de traitement est effectué par un module de sommation 13. Il s'agit en fait de convertir les données d'écritures comptables détaillées et locales stockées dans la première zone locale 12 en données d'écritures comptables de synthèse, locales, au format de la base. Une fois la conversion des données détaillées et locales en données de synthèse locales, ces dernières sont stockées dans une seconde zone locale 14 de la base de données 4. Un second type de traitement est effectué par un module de filtrage 15. Il s'agit de convertir selon des filtres choisis, sur lesquels on reviendra plus loin, les données d'écritures comptables détaillées et locales, stockées dans la première zone locale 12, en données d'écritures comptables détaillées, au format du groupe (ou format global). Plus précisément, le format du groupe est celui qui est reconnu par le progiciel de comptabilité (ou ERP) groupe 7 du terminal groupe 2. Une fois cette conversion finie, les données d'écritures comptables détaillées et globales sont stockées dans une première zone 16, dite groupe (ou globale), de la base de données 4.

Préférentiellement, le module de sommation 13 est également agencé pour convertir (ou sommer) les données d'écritures comptables détaillées et globales (stockées dans la première zone globale 16) en données d'écritures comptables de synthèse, au format du groupe (ou format global). Une fois cette conversion effectuée, les données d'écritures comptables de synthèse, globales, sont stockées dans une seconde zone globale 17 de la base de données 4.

Le dispositif selon l'invention comporte également un module d'exportation de données 18 destiné à gérer l'exportation des données d'écritures comptables détaillées ou de synthèse, qui sont stockées dans les première 16 et seconde 17 zones globales de la base de données 4, vers le terminal groupe 2, et plus particulièrement vers son ERP groupe 7.

Bien entendu, le module d'exportation 18 pourrait être intégré dans le module de supervision 9. En fait, la différentiation des deux modules de

supervision et d'exportation est avantageuse lorsque, par exemple, les terminaux locaux 1-i sont raccordés au serveur 3 via un réseau public, tandis que le terminal groupe 2 est raccordé au serveur 3 via un réseau privé. Cela permet en effet de différencier les entrées/sorties des deux réseaux. Un expert comptable local, non identifié sur un réseau Intrant, peut ainsi recevoir par Internet les données d'une filiale (ou société locale) en vue de générer une liasse fiscale locale. Bien entendu, cet expert ne peut pas, de préférence, accéder à la base de données via 1'intrant.

Lorsque les deux modules sont différenciés, il est préférable que le module d'exportation 18 comporte une mémoire 19 dans laquelle se trouvent mémorisés les identifiants des terminaux groupes 2, ainsi qu'éventuellement ceux des terminaux auxiliaires 5. De la sorte, lorsqu'un terminal groupe 2 (ou auxiliaire 5) requiert des données comptables détaillées ou de synthèse, il ne peut les obtenir qu'à condition qu'il transmette au préalable son identifiant et que celui-ci soit stocké dans la mémoire 19. Bien entendu, la mémoire 19 stocke également, de préférence, les adresses des terminaux groupes et auxiliaires (si besoin).

Le dispositif selon l'invention pourra également comporter un module de saisie 20 destiné à permettre, d'une part, aux utilisateurs, de préférence non comptables, de saisir des événements que d'autres utilisateurs, habilités pourront transformer ultérieurement en écritures comptables, et d'autre part, aux utilisateurs habilités de saisir directement dans la base de données des écritures modifiant ou complétant celles reçues des filiales (ou sociétés locales). La saisie peut s'effectuer dans un format local ou dans un format groupe.

Par exemple, l'administrateur distribue à chaque utilisateur une ou plusieurs autorisations pour chaque dimension de la base de données et chaque zone de l'écran de saisie, et/ou des autorisations pour impacter la base de données en validant ses propres saisies ou seulement pour préparer des écritures qui sont stockés dans des fichiers, hors de la base, en vue d'être complétés par d'autres utilisateurs habilités.

L'utilisateur opère donc ses saisies en fonction de ses habilitations. Il peut soit créer une nouvelle saisie, soit rappeler un fichier de saisie, qu'il a, ou qu'un autre utilisateur a, préalablement enregistré dans un fichier hors de la base (on parle alors de fichier brouillard ). Par exemple, si l'utilisateur a saisi des données incomplètes, il choisit l'option fichier brouillard pour stocker les informations saisies. Un autre utilisateur, ou lui-même, pourra ensuite modifier, compléter ou supprimer ces informations saisies selon son type d'habilitation. En revanche, si les données saisies sont complètes (et correctes), l'utilisateur valide sa saisie. La base de données est alors alimentée par ces saisies directes, contrairement aux dépôts effectués dans la boîte aux lettres de l'administrateur qui annulent et remplacent les données préalablement stockées dans la base de données.

En fait, l'enregistrement (ou validation) des données saisies à l'aide du module de saisie 20 est identique à celle effectuée lors d'un dépôt par un terminal local, à l'exception de deux points : i) les données alimentent (ou incrémentent) la base au lieu d'annuler ou remplacer d'anciennes données de la base, et ii) les données saisies sont accompagnées d'un indicateur de saisie et de l'identifiant de l'utilisateur qui les a validées, cet indicateur permettant de renvoyer à la filiale (ou société locale) concernée les seules écritures comptables de correction , sans renvoyer toutes les écritures comptables qui la concernent.

Le module de saisie 20 pourra être implanté dans certains terminaux locaux, groupes ou auxiliaires, ou bien être implanté dans un terminal dédié raccordé à la base de données, éventuellement via un réseau de télécommunications.

Par ailleurs, il est particulièrement avantageux que le dispositif selon l'invention comporte des modules de liaison 21-i implantés dans chaque terminal local 1-i. Préférentiellement, on équipe également le terminal groupe et les terminaux auxiliaires 5 d'un tel module de liaison 22 ou 23.

Chaque module de liaison est agencé pour assurer la transmission des fichiers délivrés par les ERP (locaux ou groupes) sur le réseau. Plus

précisément, les données d'écritures comptables, qui sont contenues dans le fichier délivré par une ERP, sont de types différents, représentatifs de champs particuliers. Le module de liaison est préférentiellement destiné à placer un indicateur de champ devant les différents types de données du fichier, de manière à faciliter la conversion des données au format local par le module d'interfaçage 11.

Différents types de champs pouvant être utilisés sont indiqués ciaprès, à titre d'exemple.

Un champ"type"concerne le type de format local utilisé, c'est-à-dire le nombre de colonnes séparées par un caractère séparateur ou une longueur fixe. Ce champ peut prendre des valeurs de type"separator"ou

il "fixed".

Un champ"separator"désigne le caractère séparateur si le champ "type"est placé à la valeur"separator".

Un champ"length"désigne la longueur d'une ligne au sein d'une colonne, lorsque le champ"type"est à la valeur"fixed".

Un champ"firstdataline"désigne le numéro de la première ligne qui contient des données comptables. Sur certains logiciels, la première ligne peut contenir des titres de colonnes.

Un champ"dateformat"désigne le format des valeurs de dates contenues dans le fichier reçu. Ce format peut être par exemple du type "yyyymmdd".

Un champ"decimalchar"désigne le type de décimal utilisé dans les valeurs numériques, et notamment les montants.

Un champ"sensCvalue"désigne le caractère qui indique que le sens de l'opération comptable visée est un crédit.

Un champ"sensDvalue"désigne le caractère qui indique que le sens de l'opération comptable est un débit.

Le champ"sens"désigne la position dans le fichier du champ"sens" qui indique le sens de l'opération comptable.

Un champ"montantD"désigne la position dans le fichier du champ qui contient le montant de l'écriture comptable passée en débit.

Un champ"montantC"désigne la position dans le fichier du champ qui contient le montant de l'écriture passée en crédit.

Un champ"montant"désigne la position dans le fichier du champ qui contient le montant de l'écriture comptable.

Un champ"journal"désigne la position dans le fichier du champ qui contient le journal de l'écriture comptable.

Un champ"Nopiece"désigne la position dans le fichier du champ qui contient le numéro de pièce.

Un champ"Nocompte"désigne la position dans le fichier du champ qui contient le numéro de compte.

Un champ"dateécriture"désigne la position dans le fichier du champ qui contient la date de l'écriture comptable.

Un champ"dateéchéance"désigne la position dans le fichier du champ qui contient la date d'échéance.

Un champ"libellé"désigne la position dans le fichier du champ qui contient le libellé de l'écriture comptable.

Un champ"montantDEV"désigne la position dans le fichier du champ qui contient le montant en devise de l'écriture comptable.

Un champ"modepaiement"désigne la position dans le fichier du champ qui contient le mode de paiement.

Après avoir placé les indicateurs de champs, le module de liaison génère un nouveau fichier qu'il accompagne de l'identifiant du terminal dans lequel il est implanté, puis il transmet ce fichier au module de supervision 9, via le réseau de télécommunications.

Chaque indicateur de champ permet d'indiquer au module d'interfaçage 11 où se trouve chaque information utile pour placer les données du format local vers le format de la base de données, et sous quelle forme cette information se présente. A partir de ces indicateurs, le module

d'interfaçage 11 est alors capable de repositionner chaque information comptable dans la base, et dans son format d'origine, ou en sens inverse de prendre une écriture de la base pour la restituer au format local d'un terminal local, en utilisant de préférence des tables de correspondance stockées dans une mémoire 25.

Dans ces tables de correspondances local/groupe, chaque société locale est définie par un certain nombre de paramètres en correspondance des paramètres du groupe, et notamment son logiciel comptable (ERP local), son plan de comptes, sa devise, ses journaux et leurs correspondances avec les journaux du groupe, la maison mère à laquelle elle est rattachée et un code de regroupement. Par ailleurs, on crée une table de correspondance entre chaque journal local associé à chaque société locale et les journaux du groupe.

Toutes ces tables de correspondance sont de préférence élaborées préalablement au transfert (et traitement) des fichiers transmis par les sociétés locales.

Toutes les tables de conversion, et tous les filtres de conversion étant définis par rapport à une référence de groupe, tous les types de flux entre les différents terminaux peuvent alors être envisagés.

On peut notamment transférer des fichiers d'une filiale (ou société locale) vers la base de données 4, ou exporter des écritures comptables de la base de données 4 vers une filiale (ou société locale), qu'il s'agisse de la société concernée par lesdites écritures, ou bien d'une autre société locale équipée d'un ERP différent, ou encore réimporter des écritures d'un ERP différent de l'ERP à l'origine desdites écritures et pour ce faire un double filtrage (ou une double conversion) doit être effectué.

Préférentiellement, la transmission des données du terminal local vers le serveur 3 est automatisée, chaque module de liaison comportant, à cet effet, l'adresse du serveur 3 destinataire du fichier. On peut également envisager que les modules de liaison soient équipés d'un module de cryptage de manière à renforcer la sécurité du transfert de données.

Les différents modules qui constituent le dispositif selon l'invention peuvent être réalisés sous la forme de module logiciel ("software") et/ou de circuits électroniques ("hardware").

Le dispositif selon l'invention peut être implanté sur tout type de serveur, tel que notamment les serveurs NT et les serveurs LINUX, et de préférence, la représentation des données s'effectue en langage XML.

A titre d'exemple, la base de données 4 pourra être de type ORACLE 8i, le serveur 3 contrôlant la base de données pourra être de type TOMCAT, par exemple à programmation structurée de Jackson (plus connue sous l'acronyme JSP pour"Jackson Structure Programming"), les interactions avec la base de données ORACLE 4 s'effectuant alors, de préférence, selon un mode de type JDBC. Par ailleurs, on peut envisager d'utiliser entre le réseau et le module de supervision 9 un serveur de type http, tel que par exemple un serveur APACHE, notamment équipé d'un dispositif de cryptage de données de type OPEN SSL.

De la sorte, les requêtes émises par un terminal local ou un terminal groupe à destination du serveur http s'effectuent sous la forme de requêtes http, tandis que les données qui sont destinées à un terminal local ou groupe sont de préférence envoyées sous la forme de pages HTML cryptées.

Plus précisément, le transfert des données d'un fichier texte généré par une application comptable (terminal local 1 ou terminal groupe 2) vers la base de données 4 peut être mis en oeuvre en langage JAVA, en utilisant le mécanisme indiqué ci-après.

Tout d'abord, on lit le fichier de données d'entrée avec les fichiers de description qui correspondent au logiciel comptable qui l'a générés puis on crée un fichier XML selon un DTD (Document Type Definition) particulier, à partir du fichier de données lues, et enfin on"parse"le fichier XML généré et on stocke les données dans la base de données 4.

Un tel mode de mise en oeuvre permet une intégration facile des données issues de n'importe quel logiciel comptable (ou ERP). Il suffit en effet de créer un fichier de description correspondant au fichier texte qu'il

génère.

Dans certains cas particuliers, c'est-à-dire lorsque les logiciels comptables qui génèrent des fichiers de données ne peuvent pas être décrits à l'aide du fichier de description, on peut utiliser un filtre en langage JAVA qui va créer, à partir du fichier de données, le fichier XML correspondant.

Le transfert des données de la base de données 4 vers une application comptable (terminal local 1 ou terminal groupe 2) se fait en générant un fichier texte dans un format lisible par l'application comptable de destination. Pour ce faire, on utilise, comme pour le transfert en sens inverse, un fichier de description du fichier texte à créer. Dans le cas où le format du fichier ne peut être décrit par le fichier de description, on peut utiliser un filtre spécifique en langage JAVA qui va créer le fichier texte.

Les différents transferts de données entre les terminaux et le serveur vont maintenant être décrits en référence aux figures 3 à 5.

L'algorithme illustré sur la figure 3 décrit un procédé de transfert de fichiers comptables entre un terminal local 1-i et la base de données 4 via le dispositif 8 implanté dans le serveur 3.

Dans une première étape 100, l'ERP local 6-i d'un terminal local 1-i génère un fichier de données d'écritures comptables détaillées au format local. Ce fichier est modifié par le module de liaison 21-i (par ajout d'indicateurs de champs et de l'identifiant du terminal local 1-i) dans une étape 110. Il est alors transmis dans une étape 120 sur le réseau à destination du serveur 3 dont l'adresse (par exemple URL) est stockée dans la mémoire 24 du module de liaison 21-i. Puis, dans une étape 130, le module de supervision 9 réceptionne le fichier, vérifie l'identifiant du terminal local émetteur par confrontation avec les identifiants stockés dans la mémoire 10. Préférentiellement, dans cette étape 130, le module de supervision 9 détermine les opérations (ou fonctions) qui ont le droit d'être effectuées sur le fichier reçu. Ces fonctions sont stockées dans la mémoire 10, en correspondance de l'identifiant du terminal local émetteur. En fait, il s'agit d'autorisations qui sont délivrées par l'administrateur du serveur 3.

Par exemple, dans l'exemple illustré sur la figure 3, la seule fonction que l'émetteur (terminal local) est autorisée à effectuer, c'est le dépôt du fichier dans la base de données 4, en vue de son traitement ultérieur.

Le fichier de données comptables est alors communiqué au module d'interfaçage 11. Dans une étape 140, le module d'interfaçage 11 détermine les emplacements des différents indicateurs de champs, de manière à sélectionner ceux qui vont lui permettre de convertir le fichier reçu, au format local, en un fichier au format de la base de données 4. Il s'agit, en quelque sorte, de générer un filtre de conversion. Cette sélection consiste, par exemple, à déterminer i) le plan de comptes de la société locale émettrice, et par conséquent la table de correspondance de comptes (local/base) associée, ii) le logiciel comptable (ou ERP) utilisé par le terminal local émetteur, et la devise locale utilisée. Puis, on détermine les exercices et leur subdivisions en périodes. Il faut ici considérer le terme"exercice"dans son sens le plus large. On peut en effet créer des exercices comptables sur 12 périodes décalées du calendrier, mais aussi des exercices annuels sur 365 périodes calendaires (pour la trésorerie) ou des exercices annuels sur 4 périodes (pour les sommations destinées aux marchés financiers).

Enfin, dans cette étape 140 on détermine également, de préférence, si le fichier reçu a été compressé (par exemple zippé ) ou non.

Toutes ces déterminations de paramètres s'effectuent dans des sous-étapes 141 à 144. Par exemple, on détermine dans la sous-étape 141 si le fichier reçu doit être décompressé (ou en d'autres termes, si il comprend un indicateur de compression). Si ce n'est pas le cas, et que les tables de correspondance associées au terminal local émetteur indiquent qu'il devrait l'être, ou bien si le fichier doit être décompressé mais qu'il ne comprend pas d'indicateur de décompression, alors on génère un message d'erreur de format à destination de l'émetteur du fichier et l'on arrête le traitement du fichier. En revanche, si le fichier est compressé comme cela est prévu, ou bien qu'il ne l'est pas mais que cela est normal, on décompresse le fichier et on passe à la sous-étape 142 dans laquelle on détermine le type d'ERP local

utilisé. Si l'ERP local n'est pas celui attendu (stocké dans les tables de correspondance associées au terminal local émetteur), on génère un message d'erreur de format que l'on transmet à l'émetteur du fichier et l'on arrête le traitement du fichier. En revanche, si le type de logiciel local correspond effectivement à celui qui est associé à l'émetteur, le module d'interfaçage 11 convertit les données détaillées reçues, au format local du terminal local, en données d'écritures comptables détaillées et locales, mais au format de la base de données 4, puis on passe à la sous-étape 143 dans laquelle on détermine le plan de comptes et/ou les journaux associé (s) au terminal local émetteur. Si le plan de comptes et/ou les journaux n'est (ne sont) pas celui (ceux) attendu (s), on génère un message d'erreur que l'on adresse à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 155. En revanche, si le plan de comptes et/ou les journaux est (sont) celui (ceux) attendu (s), on passe à la sous- étape 144 dans laquelle on détermine le type de devise utilisé. Si la devise n'est pas celle attendue, on génère un message d'erreur que l'on transmet à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 155. En revanche, si la devise est celle attendue, on génère dans une étape 150 un message à destination de l'administrateur du serveur 3, pour lui signaler que les données reçues sont au bon format (ou conformes à ce que l'on attend), puis, préférentiellement, le module de supervision 9 transmet au module de liaison 21-i du terminal local 1-i émetteur, un accusé de réception lui indiquant qu'il a bien reçu l'intégralité des données contenues dans le fichier qu'il lui a transmis, avec leur statut ( conforme ou non conforme ).

Préférentiellement, seules les problèmes détectés lors des étapes 141 et 142 provoquent l'interruption du traitement. Lorsqu'un problème est détecté dans les étapes 143 et 144, il appartient au superviseur de décider, ou non, de corriger en conséquence les tables de correspondance dans l'étape 155. Quel que soit le résultat des étapes 143 et 144, on conserve la trace du flux de données. En fait, c'est lorsque le superviseur consulte ces

messages d'erreur qu'il lui est automatiquement proposé d'effectuer des corrections, ainsi qu'éventuellement de reprendre l'importation de données.

Préférentiellement, dès que les données du fichier parviennent dans la boîte aux lettres du superviseur, elles sont converties en données détaillées au format groupe, de sorte que le superviseur puisse les consulter, s'il le souhaite, avant qu'elles ne soient définitivement stockées dans la base de données (à l'étape 170).

Puis, dans une étape 160, on génère un historique des flux que l'on transmet à la société locale émettrice.

Enfin, dans une étape 170 on procède à l'intégration des données dans les différentes zones 12,14, 16 et 17 de la base de données 4. Plus précisément, le module d'interfaçage 11 stocke les données d'écritures détaillées et locales reçues dans la première zone locale 12 dans des comptes désignant les différentes sociétés locales (ou filiales) et dans les devises locales. Cela constitue la sous-étape 171.

Dans une sous-étape 172, on peut ensuite effectuer une sommation des données stockées dans la première zone locale 12 à l'aide du module de sommation 13. Cela consiste à extraire les données d'écritures comptables détaillées et locales, au format de la base, associées à la société locale émettrice, et à sommer ces différentes données pour les transformer en données d'écritures comptables de synthèse locales, mais toujours au format de la base de données 4. Ces données sont alors stockées dans la seconde zone locale 14 de la base de données 4.

On peut ensuite effectuer une sous-étape 173, à l'aide du module de filtrage 15, dans laquelle on extrait certaines au moins des données comptables stockées dans la première zone locale 12, en association d'un certain nombre de sociétés locales, pour générer des données d'écritures comptables détaillées, mais cette fois-ci dans un format groupe (ou format global). En fait, il s'agit d'alimenter les comptes groupes avec des données converties dans la devise du groupe. Le module de filtrage 15 possède, pour ce faire, des tables de conversion préalablement créées, qui contiennent

toutes les devises utilisées par les différentes sociétés locales du groupe avec leurs définitions respectives par rapport à la devise de référence du groupe. Préférentiellement, chaque devise est associée aux différents types de taux qui sont créés avec la devise de référence. Egalement de préférence, la table de correspondance devises comporte les différents taux qui doivent être utilisés pour les conversions de devises en fonction des exercices et des périodes. Ces taux peuvent être, par exemple, stockés selon un format de six chiffres et six décimales.

Pour chaque société locale (ou filiale, ou encore pour chaque entité), on renseigne les tables de correspondance avec le code de chaque compte local associé à chaque société locale, le libellé de chaque compte et le compte groupe correspondant. Par ailleurs, lorsqu'un groupe souhaite renvoyer des données aux sociétés locales, on doit paramétrer les tables de correspondance selon un mode"un compte pour un compte".

En revanche, les groupes qui ne souhaitent pas renvoyer d'écritures comptables à leurs sociétés locales peuvent regrouper plusieurs comptes locaux sur un même compte groupe. Il est également possible de répartir un compte local sur plusieurs comptes groupes en ajoutant des pourcentages de répartition dans les tables de correspondance.

Un exemple de table de correspondance est donné ci-après pour un plan de compte groupe sur un unique champ.

Table <SEP> de <SEP> correspondance
<tb> Compte <SEP> local <SEP> Libellé <SEP> Compte <SEP> groupe
<tb> 411 <SEP> Clients <SEP> 411000
<tb> 4110001 <SEP> Client <SEP> 1 <SEP> 411001
<tb> 4110002 <SEP> Client <SEP> 2 <SEP> 411002
<tb> 4110003 <SEP> Client <SEP> 3 <SEP> 411003
<tb> 4110004 <SEP> Client <SEP> 4 <SEP> 411004
<tb> 401 <SEP> Fournisseurs <SEP> 401000
<tb> 4010001 <SEP> Fournisseur <SEP> 1 <SEP> 401001
<tb> 4010002 <SEP> Fournisseur <SEP> 2 <SEP> 401002
<tb> 4010003 <SEP> Fournisseur <SEP> 3 <SEP> 401003
<tb> 4010004 <SEP> Fournisseur <SEP> 4 <SEP> 401004
<tb> 512 <SEP> Banques <SEP> 512000
<tb> 51200B1 <SEP> Banque <SEP> 1 <SEP> 512001
<tb> 51200B2 <SEP> Banque <SEP> 2 <SEP> 512002
<tb>

Un autre exemple de plan de compte groupe défini sur quatre champs, et permettant de créer une analytique groupe à partir des données de base de différentes sociétés locales (ou filiales) est donné ci-après :

<tb>
<tb> Table <SEP> de <SEP> correspondance
<tb> Compte <SEP> local <SEP> Libellé <SEP> Compte <SEP> groupe <SEP> @dn
<tb> 411 <SEP> Clients <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 411000
<tb> 4110001 <SEP> Client <SEP> 1 <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 411001
<tb> 4110002 <SEP> Client <SEP> 2 <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 411002
<tb> 4110003 <SEP> Client <SEP> 3 <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 411003
<tb> 4110004 <SEP> Client <SEP> 4 <SEP> EURO. <SEP> FRAN. <SEP> SOC1.411004
<tb> 401 <SEP> Fournisseurs <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 401000
<tb> 4010001 <SEP> Fournisseur <SEP> 1 <SEP> EURO. <SEP> FRAN. <SEP> SOC1. <SEP> 401001
<tb> 4010002 <SEP> Fournisseur <SEP> 2 <SEP> EURO. <SEP> FRAN. <SEP> SOC1.401002
<tb> 4010003 <SEP> Fournisseur <SEP> 3 <SEP> EURO. <SEP> FRAN. <SEP> SOC1.401003
<tb>

Dans une sous-étape 174, on extrait certaines au moins des données stockées dans la première zone globale 16 de la base de données 4, pour les convertir, à l'aide du module de sommation, en données d'écritures comptables de synthèse au format du groupe. Puis, on stocke ces données converties dans une seconde zone globale 17 (ou de groupe) de la base de données 4.

Bien entendu, la sous-étape 173 peut être effectuée avant la sous- étape 172.

On peut également envisager d'utiliser un module d'agrégation de données et/ou un module de consolidation de données.

On se réfère maintenant à la figure 4 pour décrire un exemple de procédé d'exportation de données contenues dans la base de données 4 à destination d'un terminal local 1-i.

Ce procédé commence par une étape 200 dans laquelle l'administrateur du réseau, ou bien le terminal groupe, ou encore un terminal local 1-i établit une connexion avec le serveur 3, via le réseau. Une procédure d'identification de l'initiateur de la connexion (ou émetteur) est

alors effectuée dans une étape 210 par le module de supervision 9. On vérifie si l'identifiant de l'émetteur est stocké dans la mémoire 10, et quelle (s) fonction (s) cet émetteur est autorisé à effectuer. Dans l'exemple illustré sur la figure 4, l'émetteur est autorisé à exporter des fichiers vers un terminal local
1-i. Débute ensuite une procédure de sélection des paramètres qui vont permettre de communiquer les données d'écritures comptables au format local du terminal local choisi. Cette étape de sélection des paramètres 220 est préférentiellement effectuée par le module d'interfaçage 11. Comme illustré sur la figure 4, on détermine, par exemple, l'entité concernée, les codes journaux, le destinataire, l'exercice et la période, le type de logiciel local, les tables de correspondance de plan de comptes, les fourchettes de compte, et les types de données (détaillées ou de synthèse).

Dans une étape 230, on détermine les droits du terminal destinataire. Cela consiste à déterminer si les dimensions sélectionnées par l'utilisateur qui souhaite exporter des données sont correspondent aux habilitations (ou droits) qu'il possède sur lesdites dimensions. On entend par dimensions les différentes sélections de paramètres effectuées à l'étape 220. Par exemple un utilisateur, tel qu'un contrôleur de gestion habilité à contrôler les entités de la zone Asie, n'est pas autorisé à exporter les données d'entités appartenant à la zone Amérique. Dans une telle situation, un message d'erreur lui est immédiatement adressé. En revanche, si les droits du destinataire correspondent aux paramètres sélectionnés, alors dans une étape 240 on extrait les données comptables stockées dans la base de données 4 qui correspondent aux paramètres sélectionnés. En cas de problème, un message d'erreur est généré de sorte que l'administrateur du serveur 3 puisse intervenir, par exemple en corrigeant les tables de correspondance stockées dans le dispositif. En revanche, si l'opération d'extraction se déroule correctement, via éventuellement l'intervention du module de sommation et/ou du module de filtrage, les données extraites parviennent au module d'interfaçage 11 qui les convertit au format local du terminal local 1-i concerné, selon son plan de comptes, son ERP local et sa

devise locale. Dans une étape 250, les données converties sont communiquées au module de supervision 9 qui génère un fichier. Puis, dans une étape 260 le fichier est transmis au terminal local 1-i dont l'adresse a été préalablement extraite de la mémoire 10.

On peut également envisager une étape finale dans laquelle le terminal local 1-i adresse au module de supervision 9 un accusé de réception une fois qu'il a fini de recevoir l'intégralité des données provenant de la base de données 4.

On se réfère maintenant à la figure 5 pour décrire un exemple de procédé de transfert de données d'écritures comptables, correspondant à un terminal local choisi, entre un terminal groupe 2 et la base de données 4. En fait, il s'agit ici d'exporter des données stockées dans la base de données, et correspondant à une société locale (ou entité), pour les traiter avec l'ERP groupe (ou d'un expert comptable, ou d'une autre entité), puis les retourner à la base de données.

Ce procédé de transfert commence par une étape 300 dans laquelle le logiciel comptable (ERP) groupe 7 du terminal groupe 2 délivre un fichier de données d'écritures comptables, par exemple détaillées et correspondant à un terminal local 1-i. Dans une étape 310, le module de liaison 22 du terminal groupe 2 constitue un fichier d'exportation en plaçant les identificateurs de champ et en adjoignant aux données comptables au format groupe son identifiant groupe. Puis, dans une étape 320, le module de liaison 22 tente d'établir une connexion avec le serveur 3 en extrayant son adresse.

Une fois la connexion établie, le module de supervision 9 engage dans une étape 330 une procédure d'identification de l'émetteur du fichier (ici le terminal groupe 2). Pour ce faire, il compare l'identifiant de l'émetteur aux identifiants stockés dans la mémoire 10. Puis, il détermine les fonctions que le terminal groupe a été autorisé à effectuer par l'administrateur du serveur 3.

Dans l'exemple illustré sur la figure 5, la fonction autorisée est le

dépôt de fichier dans la base de données 4.

Dans une étape 340, le module d'interfaçage 11 sélectionne les paramètres qui vont permettre la conversion des données reçues, en vue de leur stockage dans la base de données 4. Cela ce fait à l'aide des tables de conversion.

Ici, il s'agit de vérifier que les paramètres utilisés par le terminal groupe qui a transmis le fichier sont bien ceux qui sont connus de l'administrateur, et notamment le plan de comptes, les journaux, le type de logiciel groupe, la devise du groupe, le type d'exercice et de période utilisé par le terminal groupe, et l'éventuel mode de compression (par exemple zippé), et de déterminer le type du logiciel local concerné par les données traitées par le l'ERP groupe, sa devise, le type d'exercice et de période utilisé par le terminal local concerné, et l'éventuel mode de compression (par exemple zippé).

Ces déterminations de paramètres s'effectuent dans des sous- étapes 341 à 344. Par exemple, on détermine dans la sous-étape 341 si le fichier reçu doit être décompressé (ou en d'autres termes, si il comprend un indicateur de compression). Si ce n'est pas le cas, et que les tables de correspondance associées au terminal groupe émetteur indiquent qu'il devrait l'être, ou bien si le fichier doit être décompressé mais qu'il ne comprend pas d'indicateur de décompression, alors on génère un message d'erreur de format à destination de l'émetteur du fichier et l'on arrête le traitement du fichier. En revanche, si le fichier est compressé comme cela est prévu, ou bien qu'il ne l'est pas mais que cela est normal, on décompresse le fichier et on passe à la sous-étape 342 dans laquelle on détermine le type d'ERP groupe utilisé. Si l'ERP groupe n'est pas celui attendu (stocké dans les tables de correspondance associées au terminal local émetteur), on génère un message d'erreur de format que l'on transmet à l'émetteur du fichier et l'on arrête le traitement du fichier. En revanche, si le type de logiciel groupe correspond effectivement à celui qui est associé à l'émetteur, le module d'interfaçage 11 convertit les données détaillées

reçues, au format local du terminal local concerné, en données d'écritures comptables détaillées et locales, mais au format de la base de données 4, puis on passe à la sous-étape 343 dans laquelle on détermine le plan de comptes et/ou les journaux associé (s) au terminal groupe émetteur ainsi que ceux associés au terminal local concerné. Si le plan de comptes et/ou les journaux du terminal groupe n'est (ne sont) pas celui (ceux) attendu (s), on génère un message d'erreur que l'on adresse à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 355. En revanche, si le plan de comptes et/ou les journaux est (sont) celui (ceux) attendu (s) pour le terminal groupe, on passe à la sous-étape 144 dans laquelle on détermine les types de devise utilisés par l'ERP groupe et par l'ERP local concerné. Si la devise groupe n'est pas celle attendue, on génère un message d'erreur que l'on transmet à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 355. En revanche, si la devise est celle attendue, on génère dans une étape 350 un message à destination de l'administrateur du serveur 3, pour lui signaler que les données reçues sont au bon format (ou conformes à ce que l'on attend), puis, préférentiellement, le module de supervision 9 transmet au module de liaison 22 du terminal groupe 2 émetteur, un accusé de réception lui indiquant qu'il a bien reçu l'intégralité des données contenues dans le fichier qu'il lui a transmis, avec leur statut ( conforme ou non conforme ).

Préférentiellement, seules les problèmes détectés lors des étapes 341 et 342 provoquent l'interruption du traitement. Lorsqu'un problème est détecté dans les étapes 343 et 344, il appartient au superviseur de décider, ou non, de corriger en conséquence les tables de correspondance dans l'étape 355. Quel que soit le résultat des étapes 343 et 344, on conserve la trace du flux de données. En fait, c'est lorsque le superviseur consulte ces messages d'erreur qu'il lui est automatiquement proposé d'effectuer des corrections, ainsi qu'éventuellement de reprendre l'importation de données.

Préférentiellement, dès que les données du fichier parviennent dans

la boîte aux lettres du superviseur, elles sont converties en données détaillées et locales au format de la base, de sorte que le superviseur puisse les consulter, s'il le souhaite, avant qu'elles ne soient définitivement stockées dans la base de données (à l'étape 370).

Puis, dans une étape 360, on génère un historique des flux que l'on transmet à la société locale émettrice.

Enfin, dans une étape 370 on procède à l'intégration des données dans les différentes zones 12,14, 16 et 17 de la base de données 4. Plus précisément, le module d'interfaçage 11 stocke les données d'écritures détaillées et locales converties dans la première zone locale 12 dans des comptes désignant les différentes sociétés locales (ou filiales) et dans les devises locales. Cela constitue la sous-étape 371.

Dans une sous-étape 372, on peut ensuite effectuer une sommation des données stockées dans la première zone locale 12 à l'aide du module de sommation 13. Cela consiste à extraire les données d'écritures comptables détaillées et locales, au format de la base, associées à la société locale émettrice, et à sommer ces différentes données pour les transformer en données d'écritures comptables de synthèse locales, mais toujours au format de la base de données 4. Ces données sont alors stockées dans la seconde zone locale 14 de la base de données 4.

On peut ensuite effectuer une sous-étape 373, à l'aide du module de filtrage 15, dans laquelle on extrait certaines au moins des données comptables stockées dans la première zone locale 12, en association d'un certain nombre de sociétés locales, pour générer des données d'écritures comptables détaillées, mais cette fois-ci dans un format groupe (ou format global). En fait, il s'agit d'alimenter les comptes groupes avec des données converties dans la devise du groupe.

Dans une sous-étape 374, on extrait certaines au moins des données stockées dans la première zone globale 16 de la base de données 4, pour les convertir, à l'aide du module de sommation, en données d'écritures comptables de synthèse au format du groupe. Puis, on stocke ces

données converties dans une seconde zone globale 17 (ou de groupe) de la base de données 4. Bien entendu, la sous-étape 373 peut être effectuée avant la sous-étape 372.

On se réfère maintenant à la figure 6 pour décrire un exemple de procédé de saisie de données d'écritures comptables. Il s'agit ici de saisir des données comptables concernant une société locale (ou filiale) à l'aide d'un module de saisie 20.

Ce procédé de saisie commence par une étape 400 dans laquelle l'utilisateur établit une connexion avec le module de supervision 9, par exemple via un réseau privé de type Intrant, en transmettant son identifiant.

Une fois la connexion établie, le module de supervision 9 engage dans une étape 410 une procédure d'identification de l'utilisateur. Pour ce faire, il compare l'identifiant de l'utilisateur aux identifiants stockés dans la mémoire 10. Puis, il détermine les fonctions que l'utilisateur est autorisé à effectuer.

Dans une étape 420, les masques de saisie s'affichent sur l'écrant de l'utilisateur. En fait, de préférence, toutes les fonctions et/ou zones non autorisées sont masquées ou invalidées. Dans l'exemple illustré sur la figure 5, la fonction autorisée est la saisie suivie de la validation (ou enregistrement) de données comptables. L'utilisateur effectue alors sa saisie.

Dans une étape 430, l'utilisateur choisit soit de valider les données saisies (cas de données complètes), soit de créer un fichier brouillard temporaire devant être stocké en dehors de la base de données, en vue de compléments, par exemple. Dans la seconde hypothèse, on crée et on stocke le fichier brouillard dans une étape 435, puis on retourne à l'étape 420 en vue de compléter ou modifier les données du fichier brouillard, tandis que dans la première hypothèse on passe à l'étape 440.

Dans cette étape 440, on détermine le plan de comptes et/ou les journaux associé (s), locaux ou groupe, qui vont permettre d'effectuer la

conversion des données soit au format groupe si elles ont été saisies selon un format local, soit au format local si elles ont été saisies au format groupe. Puis la conversion est effectuée. Si il survient un problème, on génère dans une étape 445 un message d'erreur que l'on adresse à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 450.

En revanche, si tout ce passe bien, on détermine dans une étape 460, la devise locale ou groupe, qui va permettre d'effectuer la conversion des données soit au format groupe si elles ont été saisies selon un format local, soit au format local si elles ont été saisies au format groupe. Puis la conversion est effectuée. Si il survient un problème, on génère dans une étape 465 un message d'erreur que l'on adresse à l'administrateur en vue d'une éventuelle correction des tables de correspondance dans une étape 450.

En revanche, si tout ce passe bien, on génère dans une étape 470 un historique des flux que l'on transmet à l'utilisateur, et l'on procède au marquage des données saisies. En fait, comme indiqué précédemment, cela consiste à adjoindre aux données saisies un identificateur de saisie et l'identifiant de l'utilisateur.

Enfin, dans une étape 480 on procède à l'intégration des données dans les différentes zones 12,14, 16 et 17 de la base de données 4.

Dans les procédés présentés ci-avant, les autorisations d'accès peuvent être subdivisées en deux types. Un premier type concerne les fonctions d'administrateur, tandis qu'un second type concerne les fonctions d'utilisateur, qu'il s'agisse d'une société locale ou d'un groupe.

Les fonctions d'administrateur permettent, notamment, la création et la modification des paramètres tels que les exercices/périodes, les devises, les plans de comptes, la création et la modification des filtres de conversion adaptés à chaque utilisateur, la création et la modification des entités (ou sociétés locales ou filiales), la création et la modification des tables de correspondance comptables, la création et la modification des utilisateurs et

de leurs habilitations pour les différentes fonctions, le contrôle des flux en entrée et en sortie de la base de données, la gestion de la base de données (volume, purge, sauvegarde, et analogue), le dépôt de fichiers, l'exportation de fichiers, la consultation des données, la création de feuilles dynamiques de tableur, par exemple Excel.

Les fonctions utilisateurs permettent, notamment, selon les droits associés, le dépôt de fichiers, l'exportation de fichiers, la consultation de données de la base, et la création de feuilles dynamiques de tableur.

A titre d'exemple, la consultation des données stockées dans la base permet d'avoir accès au détail des écritures, aux totaux effectués pour les différents comptes, que ce soit dans le format local ou dans le format groupe. Bien entendu, la consultation peut porter sur les périodes/exercices

et/ou les entités et/ou les journaux et/ou les comptes.

Dans la description qui précède, il a été question d'une installation, de type propriétaire, dans laquelle la base de données est dédiée à un unique groupe de sociétés. Bien entendu, on peut envisager une installation partagée par plusieurs groupes de sociétés. Dans ce cas, il est bien évident que les données pourront être stockées selon différents formats de groupe.

Par ailleurs, le dispositif peut être utilisé pour définir des comptes à partir des écritures comptables reçues et/ou saisies. De la sorte, on peut notamment calculer automatiquement et afficher en ligne soit des soldes intermédiaires de gestion de type RBE, BFR, MBA, trésorerie nette, et analogues, soit des comptes dans plusieurs normes comptables différentes, comme par exemple la norme française, la norme américaine (US GAAP), une norme internationale (IASC). Pour ce faire, l'utilisateur doit tout d'abord définir le code, le libellé et la formule mathématique de calcul du compte par rapport aux comptes importés, avec les opérateurs classiques +,-,/, * , pour une période identique ou différente, par exemple pour le calcul automatique des écarts de change. Ensuite, le dispositif effectue les synthèses locales et groupe, puis il génère automatiquement les comptes.

En outre, le rattachement logique des entités (ou sociétés locales)

les unes par rapport aux autres, combiné à la génération de comptes calculés peut permettre de générer des logiques de consolidation produisant automatiquement les comptes consolidés du groupe ou de ses unités d'affaires.

Le dispositif selon l'invention peut également permettre de reconnaître des formats d'échanges bancaires différents.

Grâce à l'invention, chaque société locale (ou filiale ou entité) d'un groupe demeure libre du choix des logiciels qui sont les mieux adaptés à sa taille et à ses besoins locaux. Par ailleurs, toutes les données d'écritures comptables peuvent circuler d'amont en aval au sein d'une installation, et réciproquement, que ce soit d'un terminal local vers le serveur ou d'un terminal local vers un terminal groupe, ou encore d'un terminal local vers un autre terminal local. En outre, l'invention assure une fluidité de l'information et une traçabilité des données.

Enfin, l'invention permet à chaque groupe, ainsi qu'à ses expertscomptables et autres auditeurs de disposer d'informations complètes (détaillées et de synthèse) sur toutes leurs sociétés locales. Il devient alors possible de contrôler, analyser et saisir des données au niveau du groupe, ainsi qu'assurer une gestion centralisée au niveau du groupe, à l'attention de certaines au moins des sociétés locales de ce groupe.

Cela permet également de délocaliser, au niveau du groupe ou de l'une des sociétés du groupe, la gestion d'achats, d'opérations diverses, de trésorerie et analogues.

L'invention ne se limite pas aux modes de réalisation de dispositif, d'installation et de procédé décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après.

Claims

REVENDICATIONS 1. Dispositif de traitement de données comptables, caractérisé en ce qu'il comprend : * un module de supervision (9) comprenant une mémoire (10), dans laquelle sont stockées des données d'identification de terminaux locaux (1-i), comprenant chacun un module logiciel comptable local (6-i) propre à délivrer des données représentatives d'écritures comptables détaillées, selon un format local, et accompagnées de données d'identification, en vue de leur transmission sur un réseau de télécommunications, et agencé pour recevoir lesdites données comptables détaillées et locales et lesdites données d'identification transmises sur un réseau de télécommunications par lesdits terminaux locaux (1-i), et pour communiquer les données d'écritures comptables détaillées et locales qui sont accompagnées par des données d'identification stockées dans ladite mémoire (10), et * un module d'interfaçage (11) agencé pour convertir des données d'écritures comptables détaillées et locales, communiquées par ledit module de supervision (9), en données d'écritures comptables détaillées et locales au format d'une base de données (4), en vue de leur mémorisation dans une première zone locale choisie (12) de la base de données.
2. Dispositif selon la revendication 1, caractérisé en ce que ledit format local, des données d'écritures comptables détaillées et locales transmises par un terminal local (1-i), porte sur un plan de comptes local et/ou une devise locale et/ou des journaux locaux.
3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que ledit module d'interfaçage (11) comporte une mémoire (25) dans laquelle sont stockées des tables de correspondance entre les format locaux des terminaux locaux et le format de la base de données (4), de manière à effectuer ladite conversion.
4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce qu'il comprend un module de sommation locale (13) agencé pour extraire

<Desc/Clms Page number 35>

de ladite première zone locale (12) certaines au moins des données d'écritures comptables détaillées et locales, au format de la base, associées à un même terminal local (1-i), puis générer à partir desdites données extraites des données d'écritures comptables locales de synthèse associées audit terminal local (1-i) et au format de la base, et enfin stocker ces données locales de synthèse dans une seconde zone locale (14) de ladite base de données (4).
5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce qu'il comporte un module de filtrage (15) agencé pour extraire de ladite première zone locale (12) les données d'écritures comptables détaillées et locales, au format de la base, associées à chaque terminal local (1-i), puis convertir les données extraites en données d'écritures comptables détaillées dans un format global, et enfin stocker ces données détaillées globales dans une première zone globale (16) de ladite base de données (4).
6. Dispositif selon la revendication 5, caractérisé en ce qu'il comprend un module de sommation globale (13) agencé pour extraire de ladite première zone globale (16) certaines au moins des données d'écritures comptables détaillées et globales associées à un même terminal local (1-i), puis générer à partir desdites données extraites des données d'écritures comptables globales de synthèse associées audit terminal local (1-i) et au format global, et enfin stocker ces données locales de synthèse dans une seconde zone globale (17) de ladite base de données (4).
7. Dispositif selon l'une des revendications 5 et 6, caractérisé en ce que ledit format global, des données d'écritures comptables globales détaillées et/ou de synthèse, stockées dans la base, porte sur un plan de comptes global et/ou une devise globale et/ou des journaux globaux.
8. Dispositif selon l'une des revendications 5 à 7, caractérisé en ce que certains plans de comptes locaux comprennent des données d'écritures comptables destinées à être réparties par ledit module de filtrage (15) dans au moins deux plans de comptes globaux.
9. Dispositif selon l'une des revendications 4 à 8, caractérisé en

<Desc/Clms Page number 36>

ce qu'il comprend un module d'exportation (18) agencé, à réception d'une requête émise par un terminal global (2) identifiable par des données d'identification, pour extraire certaines au moins des données détaillées globales stockées dans la première zone globale (16) et/ou certaines au moins des données de synthèse globales stockées dans ladite seconde zone globale (17), de manière à les transmettre audit terminal global requérant (2).
10. Dispositif selon la revendication 9, dans lequel ledit terminal global comprend un module logiciel comptable global (7), caractérisé en ce que ledit module d'exportation (18) est agencé pour alimenter sur requête ledit terminal global (2) en données, et en ce que ledit module de supervision (9) est agencé pour recevoir du terminal global (2), via un réseau de télécommunications, des données d'écritures comptables détaillées au format global, associées à un terminal local (1-i), et accompagnées par les données d'identification dudit terminal global (2).
11. Dispositif selon la revendication 10, caractérisé en ce que la mémoire (10) du module de supervision (9) stocke les données d'identification des terminaux globaux (2), et en ce que ledit module de supervision (9) est agencé, à réception de données comptables détaillées au format global, circulant dans ledit réseau, pour transmettre audit module d'interfaçage (11) les données d'écritures comptables détaillées au format global qui sont accompagnées par des données d'identification stockées dans ladite mémoire (10), de sorte qu'elles soient stockées dans la base de données (4).
12. Dispositif selon l'une des revendications 5 à 11, caractérisé en ce que ledit module de filtrage (15) est agencé pour extraire de ladite première zone globale (16) des données d'écritures comptables détaillées au format global associées à l'un desdits terminaux locaux (1-i), puis convertir ces données extraites en données d'écritures comptables détaillées et locales au format de la base, et enfin stocker ces données détaillées locales dans la première zone locale (12) de ladite base de

<Desc/Clms Page number 37>

données (4).
13. Dispositif selon l'une des revendications 1 à 12, caractérisé en ce qu'il comprend une multiplicité de modules de liaisons (21-i, 22,23) propres à être implantés dans les différents terminaux locaux (1-i) et globaux (2) en vue d'être alimentés en données d'écritures comptables, et comprenant une mémoire (24) stockant l'adresse du module de supervision (9), et agencé pour transmettre lesdites données au module de supervision (9), via ledit réseau de télécommunications.
14. Dispositif selon la revendication 13, caractérisé en ce que ledit module de liaison (21-i) d'un terminal local (1-i) est agencé pour placer lesdites données d'écritures comptables détaillées et locales dans des champs de données séparés les uns des autres par des indicateurs de champs, puis constituer un fichier comportant lesdites données et lesdits indicateurs, et enfin transmettre ledit fichier au module de supervision (9), et en ce que ledit module d'interfaçage (11) est agencé pour détecter lesdits indicateurs de champs de manière à effectuer ladite conversion des données d'écritures comptables détaillées et locales en données d'écritures comptables détaillées et locales au format de la base, avant leur mémorisation.
15. Dispositif selon l'une des revendications 13 et 14, caractérisé en ce que ledit module de liaison (21-i) est agencé, en cas de modification du plan de comptes local et/ou de journaux locaux, pour adresser au module de supervision (9) un message signalant ladite modification.
16. Dispositif selon la revendication 15, caractérisé en ce que ledit module d'interfaçage (11) est agencé, en cas de réception d'un message de modification d'un plan de comptes local et/ou de journaux locaux par ledit module de supervision (9), pour modifier ledit format de la base lorsque ladite modification de plan de comptes et/ou de journaux l'impose.
17. Dispositif selon la revendication 16, caractérisé en ce que ledit module d'interfaçage (11) est agencé, en cas de besoin d'une modification du format de la base, pour ordonner au module de supervision (9) de

<Desc/Clms Page number 38>

transmettre au terminal local, ayant émis le message de modification de plan de comptes local et/ou de journaux locaux, un message requérant de sa part une confirmation de modification, en vue d'effectuer de façon définitive la modification dudit format de la base.
18. Dispositif selon l'une des revendications 1 à 17, caractérisé en ce que ledit module d'interfaçage (11) est agencé pour convertir, sur requête, des données d'écritures comptables détaillées et locales au format de la base, stockées dans la première zone locale (12), en association avec un terminal local (1-i), en données d'écritures comptables détaillées et locales, en vue de leur transmission audit terminal local concerné, via ledit module de supervision (9) et ledit réseau.
19. Dispositif selon l'une des revendications 1 à 18, caractérisé en ce qu'il comprend un module de saisie (20) agencé pour permettre en fonction d'autorisations délivrées par un administrateur, d'une part, la saisie d'évènements transformables ultérieurement en écritures comptables par une utilisateur habilité, et d'autre part, la saisie directement dans la base de données d'écritures modifiant ou complétant des données reçues de sociétés locales, ladite saisie pouvant s'effectuer dans un format local ou dans un format groupe.
20. Dispositif selon l'une des revendications 1 à 19, caractérisé en ce que lesdits modules d'interfaçage (11), de supervision (9), de sommation (13), d'exportation (18), de filtrage (15), et de saisie (20) sont implantés dans un serveur informatique (3) raccordé à un réseau de télécommunications.
21. Installation de traitement de données comptables, caractérisée en ce qu'elle comprend : * une base de données (4) agencée de manière à stocker des données comptables selon un format de base choisi, * au moins deux terminaux locaux (1-i) comprenant chacun un module logiciel comptable local (6-i) propre à délivrer des données représentatives d'écritures comptables détaillées, selon un format local, agencés chacun pour accompagner les données comptables de données d'identification, et

<Desc/Clms Page number 39>

raccordés chacun à au moins un réseau de télécommunications, * au moins un terminal global (2) raccordé à un réseau de télécommunications, et * un dispositif de traitement de données (8) selon l'une des revendications précédentes, raccordé audit réseau et à ladite base de données (4).
22. Installation selon la revendication 21, caractérisée en ce que ledit terminal global (2) comporte un module logiciel comptable global (7) et à transmettre au module de supervision (9) du dispositif (8), via un réseau de télécommunications, des données d'écritures comptables détaillées au format global, associées à un terminal local, et accompagnées par les données d'identification dudit terminal global (2).
23. Procédé de traitement de données comptables, caractérisé en ce qu'il comprend les étapes suivantes : a) prévoir un dispositif de traitement de données (8) raccordé à un réseau de télécommunications et à une base de données (4) propre à stocker des données comptables selon un format de base choisi, et au moins deux terminaux locaux (1-i) raccordés au réseau et comprenant chacun un module logiciel comptable local (6-i) propre à délivrer des données représentatives d'écritures comptables détaillées, selon un format local, b) stocker dans une mémoire (10) du dispositif (8) des données d'identification desdits terminaux locaux (1-i), c) établir une liaison, via ledit réseau, entre un terminal local (1-i) et ledit dispositif (8), pour transmettre à ce dispositif des données comptables détaillées et locales accompagnées de données d'identification, d) convertir les données d'écritures comptables détaillées et locales, qui sont accompagnées par des données d'identification stockées dans la mémoire (10), en données d'écritures comptables détaillées et locales au format de ladite base de données, puis mémoriser ces données dans une première zone locale (12) choisie de la base de données (4).
24. Procédé selon la revendication 23, caractérisé en ce que ledit

<Desc/Clms Page number 40>

format local, des données d'écritures comptables détaillées et locales transmises par un terminal local, porte sur un plan de comptes local et/ou une devise locale et/ou des journaux locaux.
25. Procédé selon l'une des revendications 23 et 24, caractérisé en ce qu'à l'étape b), on stocke des tables de correspondance entre les formats locaux des terminaux locaux et le format de la base de données (4), de manière à effectuer ladite conversion de l'étape d).
26. Procédé selon l'une des revendications 23 à 25, caractérisé en ce qu'il comprend une étape e) dans laquelle on extrait de ladite première zone locale (12) certaines au moins des données d'écritures comptables détaillées et locales, au format de la base et associées à un même terminal local (1-i), puis on génère à partir desdites données extraites des données d'écritures comptables locales de synthèse associées audit terminal local et au format de la base, et enfin on stocke ces données locales de synthèse dans une seconde zone locale (14) de ladite base de données (4).
27. Procédé selon l'une des revendications 23 à 26, caractérisé en ce qu'il comporte une étape f) dans laquelle on extrait de ladite première zone locale (12) les données d'écritures comptables détaillées et locales, au format de la base, associées à l'un des terminaux locaux (1-i), puis on convertit ces données extraites en données d'écritures comptables détaillées dans un format global, et enfin on stocke ces données détaillées globales dans une première zone globale (16) de ladite base de données (4).
28. Procédé selon la revendication 27, caractérisé en ce qu'il comprend une étape g) dans laquelle on extrait de ladite première zone globale (16) certaines au moins des données d'écritures comptables détaillées et globales associées à un même terminal local (1-i), puis on génère à partir desdites données extraites des données d'écritures comptables globales de synthèse associées audit terminal local et au format global, et enfin on stocke ces données locales de synthèse dans une seconde zone globale (17) de ladite base de données (4).
29. Procédé selon l'une des revendications 27 et 28, caractérisé

<Desc/Clms Page number 41>

en ce que ledit format global, des données d'écritures comptables globales détaillées et/ou de synthèse, stockées dans la base, porte sur un plan de comptes global et/ou une devise globale et/ou des journaux globaux.
30. Procédé selon l'une des revendications 27 à 29, caractérisé en ce qu'à l'étape f) on répartit certaines données d'écritures comptables appartenant à certains plans de comptes locaux dans au moins deux plans de comptes globaux.
31. Procédé selon l'une des revendications 26 à 30, caractérisé en ce qu'il comprend une étape i) dans laquelle on extrait, sur requête d'un terminal global (2) identifiable par des données d'identification, certaines au moins des données détaillées globales stockées dans la première zone globale (16) et/ou certaines au moins des données de synthèse globales stockées dans ladite seconde zone globale (17), puis on transmet ces données extraites audit terminal global requérant (2).
32. Procédé selon la revendication 31, dans lequel on prévoit un terminal global (2) équipé d'un module logiciel comptable global (7), caractérisé en ce qu'il comprend une étape j) dans laquelle le terminal global (2) transmet au dispositif (8), via un réseau de télécommunications, des données d'écritures comptables détaillées au format global, associées à un terminal local, et accompagnées par ses données d'identification.
33. Procédé selon la revendication 32, caractérisé en ce qu'à l'étape b) on stocke dans ladite mémoire (10) les données d'identification des terminaux globaux (2), et en ce qu'il comprend en sortie de l'étape j) une étape k) dans laquelle on stocke les données comptables reçues dans ladite première zone globale (12) de la base de données (4).
34. Procédé selon l'une des revendications 27 à 33, caractérisé en ce qu'il comprend une étape 1) dans laquelle on extrait de ladite première zone globale (16) des données d'écritures comptables détaillées au format global, associées à l'un des terminaux locaux (1-i), puis on convertit ces données extraites en données d'écritures comptables détaillées et locales au format de la base, et enfin on stocke ces données détaillées locales dans la

<Desc/Clms Page number 42>

première zone locale (12) de ladite base de données (4).
35. Procédé selon l'une des revendications 23 à 34, caractérisé en ce qu'à l'étape c) on place lesdites données d'écritures comptables détaillées et locales dans des champs de données séparés les uns des autres par des indicateurs de champs, puis on constitue un fichier comportant lesdites données et lesdits indicateurs, et on transmet ledit fichier audit dispositif (8), et en ce qu'à l'étape d) on effectue la conversion après détection des indicateurs de champs.
36. Procédé selon l'une des revendications 23 à 35, caractérisé en ce qu'il comprend une étape m) dans laquelle on adresse au dispositif (8) un message signalant chaque modification du plan de comptes local et/ou d'un journal local.
37. Procédé selon la revendication 36, caractérisé en ce qu'il comprend en sortie de l'étape m) une étape n) dans laquelle on modifie ledit format de la base lorsque ladite modification de plan de comptes et/ou de journal l'impose.
38. Procédé selon la revendication 37, caractérisé en ce qu'à l'étape n) on requiert du terminal local (1-i) émetteur d'un message de modification, une confirmation de modification, avant de procéder à la modification définitive dudit format de la base.
39. Procédé selon l'une des revendications 23 à 38, caractérisé en ce qu'il comprend une étape o) dans laquelle on convertit, sur requête, des données d'écritures comptables détaillées et locales au format de la base, stockées dans la première zone locale (12), en association avec un terminal local (1-i), en données d'écritures comptables détaillées et locales, puis on transmet ces données converties à un terminal local (1-i) désigné dans ladite requête.
40. Utilisation du dispositif, de l'installation et du procédé selon l'une des revendications précédentes, dans le domaine des réseaux de télécommunications choisis dans un groupe comprenant les réseaux publics et les réseaux privés.