Technologie d'information et de communication en comptabilité et

© TIC-CR 1.8 Français page 2

Sommaire

INTRODUCTION .......................................................................................................................... 3

SYNTHESE ..................................................................................................................................... 4

1. L'IMMATERIALITE DE LA COMPTABILITE .............................................................. 7 1.1 LA COMPTABILITE INFORMATISEE EST PAR ESSENCE IMMATERIELLE................................ 7 1.2 LES BESOINS DE VERIFICATION....................................................................................... 10 1.3 LES STANDARDS NOUVEAUX SONT ARRIVES................................................................... 10 1.4 POUR RESOUDRE DES INCOMPATIBILITES........................................................................ 11 1.5 DES GUIDES UTILISATEURS SONT REDIGES ET DES LABELS DELIVRES ............................. 12 1.6 DES NORMES DESTINEES A ETRE INTERNATIONALES....................................................... 12

2. L'ORGANISATION DU SYSTEME COMPTABLE....................................................... 13 2.1 L'ORGANISATION DU SYSTEME COMPTABLE DES PETITES ET MOYENNES ENTITES........... 13

2.11 Lien avec les autres sous-systèmes d'applications du système d'information........... 14 2.12 Liens avec les bases de données de l'entité............................................................... 15 2.13 Flux de données et d'informations et collecticiel ...................................................... 17 2.14 Archivage des informations ...................................................................................... 21

2.2 L'ORGANISATION DU SYSTEME COMPTABLE DES GRANDES ET MOYENNES ENTITES ........ 25 2.21 Le portage de la comptabilité sur le Web ................................................................. 25 2.22 La fourniture d'applications hébergées .................................................................... 28

2.3 LA COMMUNICATION DE DONNEES INFORMATISEES ....................................................... 30 2.31 La fonction communication....................................................................................... 30 2.32 Liaison avec le sous-système de comptabilité ........................................................... 31 2.33 Conversion des informations .................................................................................... 32 2.34 Signature électronique .............................................................................................. 33

3. LES NORMES ET CONCEPTS INFORMATIQUES COMPTABLES ........................ 35 3.1 LES NORMES INFORMATIQUES COMPTABLES DE BASE .................................................... 35

3.11 Le fichier comptable ................................................................................................. 35 3.12 L'écriture comptable ................................................................................................. 37 3.13 Le jeton comptable.................................................................................................... 41 3.14 Le plan de comptes de l'entité ................................................................................... 46 3.15 Le journal comptable ................................................................................................ 47 3.16 Les caractéristiques d'identification du transport des documents comptables......... 47

3.2 LA NOMENCLATURE DES DONNEES................................................................................. 49 3.21 Exemple d'application française de traitement des informations de l'entité............. 49

3.3 LES PLANS DE REGROUPEMENT ...................................................................................... 56 3.4 LE REPORTING FINANCIER ET AUTRES ETATS ASSIMILES................................................. 58

3.41 L'information comptable et financière ...................................................................... 59 3.42 Définition de l'en-tête du message ............................................................................ 60

4. EXEMPLE D'UTILISATION EDIFACT ......................................................................... 62

5. EXEMPLE D'UTILISATION XML.................................................................................. 65


IIINNNTTTRRROOODDDUUUCCCTTTIIIOOONNN

Le principal problème qui se pose à une étude conceptuelle de la comptabilité et du repor-ting financier provient des techniques utilisées actuellement en complet bouleversement. Assurément, cette situation devient systématique et constante dans le domaine informati-que mais, signe d'évolution inéluctable, elle est assez marquée et particulièrement chaoti-que depuis l'irruption simultanée d'Internet comme réseau de communication et de XML pour les données et les documents. Or, si les deux techniques rappelées ici ont plus de trente ans, c'est seulement aujourd'hui qu'elles se diffusent largement, avec évidemment leur lot de transformations et d'adaptations des systèmes informatiques.

La comptabilité n'échappe pas à ce phénomène. Si ses concepts de base n'ont pas beau-coup évolué, les techniques qu'elle emploie ont largement progressé et, depuis que les ordinateurs ont vu le jour, toujours épousé l'évolution informatique. Comptabilité et in-formatique sont intimement imbriquées par un mariage de raison.

Ainsi, la démocratisation des systèmes informatiques induit une lente révolution jusqu'au sein du milieu familial. Il reste que les concepts sont toujours les mêmes, à savoir : con-ception, réalisation, test et mise en œuvre. Vouloir faire l'économie d'une étape est un signe d'écueil certain et programmé à l'avance.

Par ailleurs, la comptabilité n'a pas de vie si elle n'est pas confrontée à des impératifs d'ordre commercial, économique, fiscal, social, juridique, si elle n'est pas assujettie à des contraintes générées par la société elle-même et par l'entité économique en particulier.

En outre, et on vient de s'en apercevoir dans le milieu du commerce électronique, c'est la seule norme internationale compréhensible utilisant une seule et même unité de mesure, la monnaie. C'est également la seule source d'informations ultérieures pour répondre aux besoins de contrôle a posteriori. Elle est même le seul élément de traçabilité entre l'activi-té économique de l'entité et la communication des informations à l'administration et autres partenaires économiques.

C'est pourquoi, il est apparu important pour la profession comptable française de repenser tout le système comptable informatique dans un esprit de totale indépendance des maté-riels mis en œuvre, en symbiose avec les hommes qui édictent les règles et ceux qui les utilisent. C'est ce que ce document tente d'exposer.

Michel LESOURD Directeur Adjoint des études techniques Conseil supérieur de l'Ordre des experts-comptables Délégué Général d'EDIFICAS Vice-Président d'EDIFRANCE Vice-Chairman TBG12 UN/CEFACT

Robert LEMENSE Administrateur d'EDIFICAS Belgium Chairman TBG12 UN/CEFACT


SSSYYYNNNTTTHHHEEESSSEEE

Le présent document présente le fruit des travaux entrepris en France par le Conseil supé-rieur de l’Ordre des experts-comptables et l’association Edificas depuis 1989, en Europe depuis 1991 et au niveau international (Nations Unies) depuis 1996.

Il constitue l’état de l’art du moment en matière de comptabilité face aux développements du commerce électronique et de ses conséquences sur l’informatisation des comptabilités des entités. Il est fondé sur les projets organisés et les réalisations conduites à leur terme par des experts-comptables avec la participation d’experts en informatique, d’experts en commerce électronique et en télétransmission de données.

De nombreuses applications sont aujourd’hui opérationnelles dans plusieurs pays euro-péens. Le courant récent des techniques développées autour d’Internet semble bénéficier d’une large audience mais aucune application réelle n'a encore à ce jour démontré la réali-té de leur vocation à servir les professionnels de la comptabilité.

Les réalisations opérationnelles permettent de faire état des nombreux constats auxquels ces projets, expérimentations et applications en France et en Europe ont donné lieu au fil de ces quinze années :

• les experts-comptables français sont conscients des formidables enjeux liés au com-merce électronique, des risques que cette révolution engendre pour leur profession et de l'ouverture de nouveaux créneaux de marché ;

• le modèle d’organisation suivi par l’association Edificas et proposé dans le présent rapport est basé sur les principes fondateurs et universels de la comptabilité et de l’audit, principes dépouillés des contraintes nationales liées à la tenue des comptes des entités ;

• l’approche "Bottom-Up" retenue (approche qualité totale) coïncide parfaitement avec les principes fondateurs : on peut passer de l'élément de détail à l'agrégat et de l’agrégat à l’élément de détail sans avoir à modifier les bases de données ;

• la comptabilité est désormais le résultat de la conjonction entre techniques compta-bles et informatiques ; dès lors, la relation entre les sociétés de services informatiques (éditeurs de logiciels ou offreurs de services) et les instances professionnelles de la comptabilité évolue vers une plus étroite collaboration où les premiers réalisent au plus près les applications destinées à résoudre les besoins exprimés par les seconds ;

• le rapprochement des techniques informatiques et comptables n’est ni nouveau, ni incongru : depuis longtemps les sociétés de services souhaitent la création d’un label de qualité auprès des organisations professionnelles comptables ; une première dé-marche dans cette direction a été franchie par la création d’une attestation de confor-mité des fichiers importés ou exportés par les progiciels de comptabilité en France aux normes EDIFACT ou aux recommandations du CS-OEC, laquelle attestation est délivrée par les experts-comptables ou les auditeurs ;

• en matière comptable, comme d’ailleurs pour toute autre discipline, la communica-tion électronique de données n’a de sens que si ces données sont directement exploi-tables par les applications informatiques du destinataire ; c’est particulièrement vrai pour les informations issues de la comptabilité destinées aux autorités publiques en


matières fiscales, sociales ou statistiques ; c’est également vrai lorsque l'entité trans-met elle-même ses informations à ces administrations ou lorsqu’elle communique tout ou partie de ses comptes à son expert-comptable, à son auditeur ou à son commissaire aux comptes ou lorsqu’elle reçoit ces mêmes informations de l’un ou l’autre de ses partenaires commerciaux (fournisseurs, banques, etc.) ;

• le commerce électronique ne peut, au risque de se perdre, faire l’impasse sur les exi-gences formulées par les autorités publiques pour la transmission et la conservation électronique de documents ;

• dans ce contexte, la relation des experts-comptables avec les administrations publi-ques est appelée à se développer considérablement ; en effet, les administrations sou-haitent ou souhaiteront de plus en plus recevoir les informations qu’elles réclament aux entreprises par voie électronique plutôt que par le support traditionnel papier, long à traiter, lourd à conserver et coûteux à exploiter ; les déploiements informati-ques ont démontré un accroissement très significatif de la productivité des collecteurs publics (par exemple performance accrue de 400 % en matière de collecte de déclara-tions TVA en Belgique, suppression potentielle de 2 600 postes administratifs en France, etc.) ;

• les administrations n’ont plus seules la main mise sur le contenu des documents ad-ministratifs : elles doivent établir un dialogue positif avec les entités ou leurs manda-taires (les experts-comptables pour la majorité des entités en France et dans l’Union Européenne d’aujourd’hui) ainsi qu’avec les sociétés de services afin de ne demander en priorité que les données disponibles dans les bases de données, et singulièrement dans les bases de données comptables ; c’est particulièrement vrai pour ce qui concerne les codes identifiant les informations et les métadonnées correspondantes ;

• la télétransmission de données n’est pas une fin en soi pour l’expert-comptable ; il importe qu’en comparaison avec les procédures traditionnelles, il puisse bénéficier d’une réduction de ses coûts de production et de transmission de ces informations ; c'est l'approche gagnant-gagnant ("win-win") ;

• les applications opérationnelles ont démontré pour un cabinet moyen français des réductions brutes possibles allant jusqu’à 75 à 90 % des coûts par rapport à la procé-dure papier ; ces diminutions de coûts doivent cependant être modérées avec l’apparition de nouvelles organisations requérant davantage de support informatique ; c’est le cas en l’occurrence pour de véritables workflows des documents électroni-ques traceurs des étapes telles que par exemple "envoi à préparer", "données extrai-tes", "données vérifiées", "document/message à construire", "document/message prêt à transmettre", "document/message transmis", "accusé de réception reçu" et le cas échéant "information transmise au client" ; cette suite d’étapes n’est pas exhaustive ;

• les documents établis par le cabinet d’expertise comptable portent généralement la signature de l’expert-comptable, associée ou non avec une autre signature ; la procé-dure de signature digitale française avec les administrations, les banques et la COB est actuellement étudiée avec la collaboration de la profession comptable française ;

• l’authentification du signataire d’un document et la certification de sa qualité sont une nécessité absolue dans bien des cas ; la mise en place d’une infrastructure de clés publiques a été évaluée par la profession comptable française afin d'aboutir à une reconnaissance de la signature de l'expert-comptable ;

• le recours aux normes Edificas en matière d’archivage électronique des fichiers comptables est de nature à réduire les nombreuses difficultés rencontrées lors de


contrôles a posteriori par les auditeurs, de modifications de configurations, de chan-gements de progiciels, voire même en cas de fusion d’entreprises dont les systèmes comptables sont fréquemment incompatibles ;

• un guide méthodologique s'appuyant sur les concepts exposés a défini les bonnes pratiques pour tout tiers de confiance archiveur de données informatiques compta-bles ;

• les évaluations en cours montrent que les normes Edificas peuvent être appliquées à de nouveaux langages de communication liés à Internet tels que XML ;

• dans le même contexte du Web, il est certain que les normes Edificas constituent une excellente base de départ pour la mise en œuvre du concept de tenue de grand livre sur Internet.


111... LLL'''IIIMMMMMMAAATTTEEERRRIIIAAALLLIIITTTEEE DDDEEE LLLAAA CCCOOOMMMPPPTTTAAABBBIIILLLIIITTTEEE

La comptabilité et les informations qui en résultent sont assimilables à des produits manu-facturés par les services comptables auxquels l’entité fait appel. Ces produits sont fré-quemment internes pour les plus grandes entités et pour une majorité de PME/PMI. Ils sont externes pour les autres et confiés généralement à des cabinets d’expertise compta-ble.

La fabrication du produit “comptabilité” impose de gérer des stocks de données à traiter “en flux tendus” pour être capable de livrer des informations de qualité “juste à temps” à ses partenaires. En ce sens, il constitue l’outil par excellence capable d’identifier, de clas-ser, de localiser ou de mesurer les activités de l’entité, notamment pour obtenir les nom-breux chiffres de toutes natures à l’usage des administrations et organismes de toutes sortes. Très souvent, le rôle imparti aux services comptables s’étend aux services admi-nistratifs tant la séparation entre les deux domaines est ténue.

1.1 La comptabilité informatisée est par essence immatérielle Sur un plan organisationnel, la comptabilité met en œuvre un ensemble de règles et de procédures permettant de remplir plusieurs objectifs :

• permettre le regroupement des informations pour les analyser, les classer, les archiver et obtenir ladite comptabilité de l'entité ;

• déterminer les résultats de l'entité ;

• vérifier ces résultats par rapport aux objectifs recherchés dans un cadre analytique et/ou budgétaire ;

• respecter la loi (au niveau commercial, fiscal, social, statistiques, douanier, etc.) et pour ce faire apporter les éléments qui permettent de vérifier ce respect ;

• correspondre avec les partenaires de l'entité en leur communiquant partiellement ou intégralement les résultats de l'entité notamment à la norme IAS/IFRS ;

• fournir aux analystes financiers les informations dans un format standard utilisable par des logiciels bureautiques du marché.

Pour cela, elle applique une procédure qui peut être considérée comme universelle quel que soit le pays. Celle-ci est représentée ci-dessous :


Le processus d'enchaînement des documents comptables comprend un certain nombre de documents qui ne sont pas tous obligatoirement utilisés. Certains sont implicites (la de-mande de documents peut être verbale), d'autres obligatoires (le journal, par exemple).

Dans toute relation par EDI, la demande de documents précède leur envoi. Elle précise les documents attendus, les périodes couvertes ainsi que d'autres caractéristiques comptables comme la section analytique ou plus particulièrement les plans de comptes.

Toute comptabilité d'entité répond à une organisation d'entité. Ceci induit qu'un même progiciel peut être utilisé différemment suivant les ressources affectées (moyen humain et matériel) et les objectifs poursuivis dans le management (analyse financière comparative, gestion budgétaire, etc.).

Ainsi, les modèles exposés ci-dessus apparaissent tous dans le guide des procédures comptables qui expose, outre l'organisation mise en place, les moyens de contrôle et de sécurité. Mais ils peuvent s'appeler différemment. Le modèle de profil de dossier s'appelle parfois paramètres comptables ou de configuration, paramètres que l'on doit retrouver dans le fichier comptable informatique et dont certains éléments sont fournis au destina-taire. Le modèle journal, celui de plan de comptes, de grand livre et de balance sont connus. C'est moins vrai en ce qui concerne le modèle de plan de regroupement qui reste pour beaucoup d'entités une sorte de mystère. Dans l'organisation qui nous intéresse, il s'agit d'une sorte de plan qui agit comme interface entre les balances de l'entité et les do-


cuments à fournir à des tiers internes ou externes à l'entité. En fait, il sert à calculer les informations agrégées à partir des informations de base de la comptabilité.

A partir des plans de regroupement, la comptabilité peut fournir toutes sortes d'états fi-nanciers : comptes annuels, déclarations fiscales et sociales, statistiques, reporting, états IAS/IFRS, analyse financière, etc. Il ne s'agit là que de quelques exemples, tellement la variété d'informations produites par l'entité est immense.

En informatique, la comptabilité est pratiquement toujours immatérielle. Elle collecte les informations soit à partir de chaînes informatiques en amont (facturation, chaîne achat, production, paie, etc.), soit à partir d'une dématérialisation d'un document par un scanner, soit à partir d’une saisie au clavier. Le schéma ci-après montre qu'à partir de la pièce dé-matérialisée ou immatérielle, on est susceptible de produire des états financiers ou autres sans faire la moindre concession matérielle.

La comptabilité en original se trouve dans la mémoire de l’ordinateur (disque dur, dis-quette, bande, etc.) ou externalisée sur des supports numériques éventuellement chez des tiers archiveurs. Elle est souvent matérialisée à nouveau sur papier pour les besoins inter-nes du service comptable ou des contrôleurs internes ou externes.

Le schéma met l'accent sur les points suivants :

• une grande automaticité entre les différentes phases de travail y compris dans les phases de contrôle,

• une absence pratiquement totale de papier,

• l'horodatage de certaines phases : traitement de la saisie, de la validation des écritures, de sortie des états, des archives, etc.,


• la connaissance de la taxonomie utilisée par les destinataires (centre des impôts par exemple) ou pour remplir certaines obligations (états IAS/IFRS, par exemple),

• le recours à des tiers archiveurs pour pérenniser la comptabilité de l'entité et éviter les problèmes d'évolution des supports informatiques,

• le recours à de nouveaux moyens de communications de l'entité par la diffusion des informations financières via un cédérom ou Internet.

1.2 Les besoins de vérification On constate quand même que, pour des besoins de vérification, les contrôleurs internes ou externes demandent de plus en plus un accès directs aux fichiers informatiques pour accé-lérer leur tâche, faciliter les recoupements et être le plus près possible de la source de l’information originale stockée. En outre, c’est la grande tendance actuelle de numériser tous les fichiers et d’offrir des possibilités d’interrogation. Les "autoroutes de l’information" y sont certainement pour quelque chose et la comptabilité n’échappe pas à ce phénomène.

1.3 Les standards nouveaux sont arrivés Ces faits étant constatés et avérés, il devenait urgent que des normes de communication et de stockage d’informations soient arrêtées d’un commun accord entre la profession comp-table (qui doit dans ce domaine exprimer ses besoins et ses contraintes), les éditeurs et concepteurs de logiciels de comptabilité (qui ont leur propres spécificités), les profes-sionnels de l'archivage de documents électroniques et les "censeurs" de l'information (au-diteurs, commissaires aux comptes, inspecteurs internes et externes, etc.).

Ces normes s’inscrivent dans l’histoire de la comptabilité car elles permettent de rendre communicants des logiciels de comptabilité qui, à l’origine, ne sont pas destinés à se met-tre en rapport entre eux. Nous sommes passés de l’ère du traitement à l’ère de l’information. Deux mondes totalement distincts.

Pour ce faire, dans le monde EDIFACT, cinq normes ont été définies et deux autres sont prévues.


ModèleEcr iture

Ensemble d'écritures comptables par journaux

ModèleGrand Livre

Ensemble d'enregistrements comptables formantun ou des extraits de comptes

ModèleBalance

Ensemble de comptes généraux, auxiliaires, analytiques ou budgétaires formant une balancespécifique

ModèleReporting

Ensemble d'états comptables constituantun ou des documents financiers, d'analyse, déclaratifs ou de reporting

ModèlePlan comptes

Ensemble de comptes généraux, auxiliaires, analytiques ou budgétaires destiné à codifier les écritures comptables

ModèlePlan regroup.

Ensemble de paramètres comptables permettantà partir du plan de comptes, la création des états comptables

Détails

Synthèse

Paramètres

Modèles créés pour le domaine comptable EDIFACT

Ces cinq normes sont complétées par deux projets, le premier étant destiné à définir une demande de document comptable (par exemple, balance des tiers fournisseurs à une date donnée), le second, un profil de dossier comptable (comptes ayant une longueur variable de chiffres, caractéristiques de certains comptes collectifs, etc.).

L’utilisation d'un langage qui n’est ni attaché au seul domaine comptable, ni au domaine informatique, et donc ne dépend pas des normes utilisées par les sociétés de services, rend plus facile le dialogue entre les utilisateurs (et leurs exigences) et les programmeurs (et leurs contraintes).

Les normes Balance, Plan de comptes, Ecritures comptables, Comptes annuels (Repor-ting, déclarations administratives ou dossier de gestion) et Grand livre ont été mises au point après plusieurs années d’études par l’association EDIFICAS. Elles ont été élaborées avec le concours d'experts-comptables, d'informaticiens et d'auditeurs au niveau européen et validées au niveau ONU. Elles facilitent l'importation et/ou l'exportation des fichiers comptables d’un système informatique comptable à un autre quel que soit le système d'exploitation utilisé, quel que soit le système comptable informatisé employé.

1.4 Pour résoudre des incompatibilités La profession comptable se trouvait confrontée à des incompatibilités dues soit à des mo-difications intempestives ou révisionnelles de format de fichiers, soit à des descriptions incomplètes ou insuffisantes de fichiers ou encore à des systèmes d’exploitation différents (MAC OS, Windows, Linux, etc.).

Les normes EDIFICAS permettent de faire face et de dépasser ces difficultés : ce ne sont plus les sociétés de services qui prescrivent leurs conditions dans la communication des balances ou des écritures, par exemple, d’un système à l’autre. Elles doivent désormais respecter un cahier des charges établi dans le cadre des normes.


1.5 Des guides utilisateurs sont rédigés et des labels délivrés

Afin de faciliter la tâche des informaticiens qui développent ou réactualisent leurs appli-cations informatiques comptables, les guides de mise en œuvre des modèles ci-dessus ont été développés en France pour couvrir des besoins particuliers comme :

• le transfert d'informations comptables entre des systèmes numériques (caisses enre-gistreuses, appareils de pesée, etc.) et le système comptable ;

• le transfert d'informations comptables entre les entités et les auditeurs ;

• le transfert d'informations comptables entre entités mères et filiales ;

• le transfert d'informations comptables vers des tiers archiveurs ;

• le transfert de statistiques comptables ;

• les télédéclarations fiscales et sociales vers les administrations ;

• le reporting vers les organismes financiers ;

• etc.

Depuis la fin de l'année 1999, des attestations de conformité à ces guides sont délivrées aux concepteurs des logiciels qui intègrent les normes susmentionnées. Elles permettent de remplir trois rôles :

• s'assurer que les équipes informatiques ont bien assimilé le langage à utiliser : ANSI X12, TRADACOM, EDIFACT, XML, etc. ;

• s'assurer que les fichiers issus de ces normes et qui sont télétransmis respectent stric-tement les guides utilisateurs ;

• inversement, s'assurer que les fichiers reçus peuvent être incorporés directement dans les applications.

1.6 Des normes destinées à être internationales

Ces normes sont à ce jour arrêtées au niveau international. Elles sont destinées à être des normes à part entière en France (AFNOR), en Europe (CEN) et enfin dans le monde (ISO).


222... LLL'''OOORRRGGGAAANNNIIISSSAAATTTIIIOOONNN DDDUUU SSSYYYSSSTTTEEEMMMEEE CCCOOOMMMPPPTTTAAABBBLLLEEE

Comme dans toute organisation, les systèmes qui sont étudiés et élaborés doivent s'ap-puyer sur plusieurs éléments de base :

• l'organisation et le management (scénarii et traçabilité),

• les ressources humaines mises en œuvre,

• les techniques nécessitées par le système,

• les sites de traitement et d'exploitation,

• la temporalité des actions (juste à temps).

Si l'un de ces cinq éléments n'est pas pris en compte, on peut s'attendre à élaborer un sys-tème bancal ou non abouti. On peut s'attendre à des surprises lors du déploiement.

En outre, comme tout système, il faut réfléchir à l'ensemble du système à concevoir et ne pas se limiter à une "fenêtre" sur une partie de l'organisation (think big, start small). Si tel était le cas, le risque certain est de voir apparaître des "verrues" pour joindre des éléments d'un même système non destinés à être complémentaires, voire des phénomènes de rejet pour incompatibilité de sous-systèmes.

Cela étant dit, il convient de distinguer deux types d'organisation, l'une touchant plus particulièrement les petites et moyennes entités pour lesquelles, dans la grande majorité des cas, le système comptable ne se conçoit qu'à un niveau interne à l'entité, l'autre concernant plus particulièrement les grandes et moyennes entités. Dans ce dernier cas, le système ne peut se concevoir qu'en combinant les plans internes et externes de l'organisa-tion. Ici, apparaissent notamment les notions de groupes et de prestations inter entités.

Les "moyennes" entités peuvent suivant leur structure être concernées par l'un ou l'autre des types d'organisation (comme également certaines petites entités dans une petite mino-rité).

2.1 L'organisation du système comptable des petites et moyennes entités

Généralement, dans une organisation où les ressources humaines, les techniques em-ployées et les sites de traitement sont réunis en un même lieu, les principales difficultés à traiter dans un système comptable se concentrent dans l'organisation et le management dudit système, notamment en matière de traçabilité des opérations et de régulation du juste à temps.

Sur ce type d'organisation, l'attention est concentrée sur les points suivants :

• liens avec les autres sous-systèmes d'applications du système d'information de l'entité,

• liens avec les bases de données de l'entité,

• flux de données et d'informations et collecticiel,


• archivage des informations.

2.11 Lien avec les autres sous-systèmes d'applications du système d'information Au préalable, il importe de garder à l’esprit que si la comptabilité constitue un aboutisse-ment pour les flux financiers, elle est en même temps le point de départ de différentes obligations légales, en particulier en matière de fiscalité. On associe donc obligatoirement des données extra-comptables aux écritures enregistrées dans les comptes.

Dans un système d'information d'une entité, les sous-systèmes ayant un rapport direct ou indirect avec le sous-système comptable sont nombreux. En dresser une liste pourrait s'avérer restrictif. On peut toutefois citer les sous-systèmes suivants :

• sous-système Achats : en coordination parfois avec le sous-système Commercial, pour l'acquisition des biens, fournitures et services ; dans ce cas, le sous-système Achat peut enregistrer et envoyer les informations au sous-système Comptabilité avec ou sans règlements ;

• sous-système Production : en coordination avec le sous-système des Achats et le sous-système Commercial, pour la gestion des entrées et sorties de biens, fournitures et services ;

• sous-système Analytique : ce sous-système peut être placé en amont ou en aval du sous-système de Comptabilité générale avec une périodicité qui n'est pas obligatoire-ment identique ;

• sous-système Trésorerie : en coordination avec les sous-systèmes Prêts et emprunts et Titres financiers ;

• sous-système Commercial : en coordination avec le sous-système des achats et le sous-système commercial, pour la cession des biens, fournitures et services ;

• sous-système Crédits-bails : en coordination avec le sous-système des Immobilisa-tions et le sous-système de la Comptabilité des engagements hors bilan, pour la récep-tion ou l'octroi de ce type de crédits ;

• sous-système Prêts et emprunts : en coordination avec le sous-système des Immobili-sations et le sous-système de la Comptabilité des engagements hors bilan, pour la réception ou l'octroi de ce type de crédits ;

• sous-système Paie et personnel ;

• sous-système Titres financiers ;

• sous-système Consolidation ;

• sous-système Etablissement des comptes annuels et déclarations fiscales, si ce sous-système n'est pas intégré dans le sous-système de Comptabilité ;

• sous-système Calcul et contrôle des taxes, si ce sous-système n'est pas intégré dans le sous-système de Comptabilité ;

• sous-système Budgétaire ;

• etc.


La principale difficulté dans le traitement de bases de données distinctes entre sous-systèmes réside dans le contrôle permanent qu'il faut instituer entre deux bases compre-nant des informations identiques mais issues de deux sous-systèmes distincts. On le com-prend bien lorsqu'on cite le cas des comptes d'immobilisations de la classe 2 du sous-système de Comptabilité et les comptes gérés par le sous-système Immobilisations. La difficulté est accrue lorsqu'il s'agit d'éditeurs de logiciels différents.

A défaut de rapprochement automatique, il faut donc faciliter le travail de l'utilisateur.

Dans certains sous-systèmes, le rapprochement peut être automatisé lorsque des standards internes ou des normes internationales sont utilisés : c'est le cas d'EDIFACT par exemple qui propose des normes pour toute sorte d'opérations y compris comptables. L'utilisation de telles normes facilite la transmission entre systèmes informatiques, entre sous-systèmes d'applications, sans intervention humaine.

2.12 Liens avec les bases de données de l'entité L’harmonisation des informations réclamées aux entités et l’utilisation de procédures s’adossant à des normes internationales, avec la mise en place de fonctions logicielles adéquates et l'ouverture sur des protocoles de télétransmission simples, stimulent la trans-mission électronique des informations des entités.

La mise en œuvre d'une procédure automatisée peut s'appuyer sur un entrepôt de données administratives que l'on peut appeler Base d'Informations Economiques, BIE. Le contenu de cette base est exposé dans le chapitre 3.2.

Un rapport, une déclaration fiscale ou sociale, une enquête statistique, un reporting, une consolidation, etc., représentent chacun un ensemble d’informations à fournir, attachées à un même document (questionnaire) destiné à identifier les questions et à livrer les répon-ses. Pour faciliter la compréhension, il sera fait usage d'une appellation générale “formu-laire électronique”.

La réponse à fournir à chaque information demandée est :

• le résultat d’un calcul opéré à partir de données directement disponibles dans un sous-système d’informations (par exemple sous-système Paie, sous-système Comptabilité, sous-système Stock, etc.) ;

• le résultat d’un calcul opéré à partir de la BIE ;

• une combinaison des deux modes précédents ;

• une donnée indisponible introduite directement et manuellement au clavier.

La passerelle entre l’information agrégée demandée par l'utilisateur destinataire et les éléments de données qui entrent dans son calcul est fournie par la métadonnée. Une mé-tadonnée est constituée d’un ensemble de données et éléments à partir desquels un agent logiciel ou une fonction programmée est capable de produire une information. Ainsi, chaque information peut être directement calculée à partir de la métadonnée qui fournit notamment la méthode d'agrégation comme, par exemple, la ou les séquences de comptes à prendre en considération, la période pour laquelle les écritures interviennent dans le calcul, le sens débiteur ou créditeur des montants, les opérateurs arithmétiques de calcul, etc. La métadonnée relative à chaque information stockée dans la BIE définit d’autres données telles que le niveau de granularité, la fréquence et le mode de mise à jour, sa longévité dans la BIE, etc. (voir dans le chapitre 3.2 le détail du contenu d'une métadon-née type).


La BIE est construite de telle manière qu’à chaque question, correspond une réponse re-connue par une étiquette identifiant à la fois le nom de l’information, la métadonnée qui fournit les éléments de données à prendre en compte pour produire la réponse, la source de ces données, la formule de calcul et le lien avec le formulaire électronique de réponse (entre autres l’étiquette du code donné à l’information par le destinataire).

Un système de codification des étiquettes rend obligatoirement unique et univoque toute information de réponse. C'est l'équivalent du code à barres des marchandises.

Une table de correspondance crée le lien entre l’information de réponse et le ou les for-mulaires (électroniques) où ladite information est requise.

Pour chaque formulaire électronique, cette correspondance permet de prendre en compte le système de codification du destinataire et de conserver l'indépendance entre les systè-mes de codification.

Ainsi, la BIE est un entrepôt où sont stockées, à un niveau élémentaire ou agrégé, les données économiques disponibles dans l’un des sous-systèmes d’information d’une enti-té.

Elle s’articule autour des concepts suivants :

• l'utilisation d’une ou de plusieurs nomenclatures identifiant et indexant les informa-tions collectées par les autorités, les partenaires, l’entité pour elle-même,

ENTREPÔT DE DONNEESBase Informationnelle

économique

Achats

Stocks

Fourn.

Créd.

Product.

Perso.

Immob.

Paie

Formulairesrapports

Tabled'équivalence

Destinatairesdes

informations

Compta. téléchargement

traitement

Utilisation d'une BIE pour l'émission de formulaires

• la mise en place de procédures de gestion et de maintenance de la BIE :

le modèle ou maquette de chaque formulaire ou rapport à compléter, son calen-drier et les informations nécessaires à son acheminement (électronique) au desti-nataire,


le lien entre l’identifiant de chaque information du formulaire réclamée par le destinataire et l’identifiant des informations de la BIE qui interviennent dans la production de l’information réclamée,

la règle de calcul associée à chacun des identifiants de chacune des informations du formulaire permettant de produire automatiquement l’information réclamée ou de la saisir au clavier,

les agents logiciels assurant la mise à jour automatique de la BIE,

les procédures de saisie des informations indisponibles dans les sous-systèmes d’information de l’entité.

Les caractéristiques d'une BIE et ses conditions d’utilisation se définissent comme un ensemble d’outils et de techniques qui permettent de saisir, dématérialiser, classer, gérer, stocker, retrouver, calculer, mettre en forme, transmettre les informations nécessaires à la production électronique de rapports, déclarations administratives ou réponses à des ques-tionnaires à partir d’applications informatiques dans les limites du périmètre habituel des activités de l’entité.

Le principe premier repose sur un concept permettant d’établir la relation entre le système d’information de l’entité et les différents rapports qu’elle a obligation de délivrer ou pour couvrir ses propres besoins dans le cadre du reporting ou de la consolidation par exemple.

La BIE est alimentée par des progiciels en amont comme par exemple la gestion des achats, la gestion des stocks, la gestion de production, la paie, la gestion des immobilisa-tions, la comptabilité, etc. Elle est donc indépendante des progiciels de gestion.

Pour ce faire, il est indispensable que l'émetteur de l’information et l'utilisateur destina-taire aient une compréhension identique du contenu de l’information collectée quant à la manière de produire l’information, son mode d’identification ainsi que de la structure du message électronique correspondant au document et du protocole de transport.

A partir de la BIE, un traitement informatique permet à l'aide d'une table d'équivalence d'extraire les données conformément aux formulaires (ou rapport) à remplir, de compléter ledit formulaire ou rapport pour ensuite procéder à son envoi au destinataire. La table d'équivalence est mise à jour en permanence à l'aide des formulaires ou rapports à pro-duire et des nomenclatures de données fournis par les destinataires.

2.13 Flux de données et d'informations et collecticiel 2.131 Nouvelles fonctions et obligations comptables

Les sous-systèmes de comptabilité évoluent en incorporant des nouvelles fonctions et en s’intégrant assez fréquemment dans des sous-systèmes plus vastes :

• Gestion Electronique d'Informations et de Documents Existants (GEIDE),

• Gestion automatisée des processus de traitement de l’information (Workflow),

• Collecticiel (Groupware, GroupWeb) et Télétravail.

Ces nouvelles fonctions peuvent également se regrouper dans des caractéristiques de communication, de coordination et de collaboration. En effet, les logiciels permettent de communiquer, de planifier et de coordonner les tâches.

La mise en service de ces nouvelles fonctions modifie profondément les habitudes de travail. C’est en effet l’introduction dans le secteur tertiaire d’une forme "d'industrialisa-


tion" ou de "taylorisation" de la production d’informations. La division du travail est plus poussée avec un souci de rendement et de sécurité très marqué.

Ces nouvelles fonctions apportent des réponses aux exigences légales concernant l'orga-nisation comptable, et aux attentes des réviseurs.

2.132 Gestion Electronique d'Informations et de Documents Existants (GEIDE)

La Gestion Electronique d'Informations et de Documents Existants (GEIDE) est un en-semble d’outils et de techniques qui permet de classer, gérer, visualiser, éditer, imprimer et stocker des documents dans leurs formats d’origine à partir d’applications informati-ques. Elle recouvre un grand nombre d’applications et d’outils :

• Gestion de documents de tous types (administratifs, commerciaux, techniques, etc.),

• Gestion documentaire,

• Système de reconnaissance de caractères associé à des correcteurs orthographiques,

• Recherche en texte intégral,

• Acquisition ou transformation d’un document papier en image électronique,

• Archivage sur divers types de périphériques (cédérom, disque dur, etc.),

• Mise à disposition de l’utilisateur, sous forme papier ou sur écran.

La pénétration de la GEIDE dans les sous-systèmes de comptabilité se fait de manière transparente pour l’utilisateur. Dès qu’un document est porteur d’une information devant être incorporée dans le sous-système Comptabilité, une codification comptable automati-sée, combinée au référencement automatique dudit document, peut être envisagée en re-courant si cela est possible à la reconnaissance optique de caractères.

Quelques exemples illustrent l’intérêt des liens entre les pièces justificatives et les écritu-res :

• chaînage avec les écritures comptables du traitement d’une opération commerciale, du bon de commande à la facturation ;

• référencement des factures d’achat d’un logiciel envoyées par mél ;

• indexation du fichier du traitement de texte contenant les statuts d’une société avec les comptes de la comptabilité (ou avec l’écriture comptable) afin d'afficher simulta-nément (ou à la demande) un document de base et son écriture comptable correspon-dante ;

• etc.

Ces exemples montrent l'origine distincte des fichiers de différentes sources (texte, image, image document, son, spool d'impression, appel ou émulation de programmes, courriel, etc.).

La Gestion Electronique d'Informations et de Documents Existants permet la mise en place de règles et de procédures visant à sécuriser les documents. Elle gère le cycle de vie du document en plusieurs étapes : création, validation, approbation, distribution et conser-vation. Ces étapes déterminent la traçabilité du document et donc la fiabilité de l’enregistrement de l’information. Elle offre également des possibilités multiples de re-cherches, tris et classement, un accès aux documents de base immédiat et permet une amélioration de la productivité des contrôles.


2.133 Gestion automatisée des processus de traitement de l’information (Workflow)

La Gestion automatisée des processus de traitement de l'information (workflow) se définit comme une automatisation des processus de traitement de l’information.

La Gestion automatisée des processus de traitement de l'information (workflow) permet de centraliser l'ensemble des règles de traitements appliquées dans son périmètre d'action et de contrôler le déroulement des processus automatisés. Le workflow permet non seu-lement d’acheminer l’information vers les utilisateurs mais décompose, planifie et contrôle l’exécution des tâches. Le workflow introduit sécurité, simplification et fluidité dans des diagrammes de circulation des documents.

L’intérêt d’un workflow dans les traitements comptables est multiple. Il permet :

• de décomposer en modules élémentaires les fonctions d'un sous-système de compta-bilité,

• d'affecter chaque module à des ressources humaines spécifiques,

• de neutraliser les effets de distance sur des sites différents,

• de maîtriser le juste à temps pour l'enrichissement des informations comptables,

• d'organiser les contrôles internes ou externes en aval,

• de faciliter les réorganisations dans le cas d'une modification de procédure,

• etc.

L’automatisation des processus de traitement permet des contrôles plus efficaces. Le workflow apporte à l'auditeur une connaissance accrue de l'environnement général de l'entité et de son système de contrôle interne ainsi qu'un outil performant et fiable pour les contrôles sur pièces.

Les outils workflow peuvent être indépendants des logiciels qu'ils sollicitent. On peut donc se trouver en face de trois possibilités :

• la comptabilité est greffée sur le logiciel workflow, ce dernier sollicitant directement des fonctions du progiciel de comptabilité ;

• la comptabilité est organisée en composants élémentaires électroniques, le logiciel de workflow sollicitant à ce moment-là seulement lesdits composants ;

• la comptabilité incorpore complètement le concept workflow.

Dans tous les cas, les modules doivent recourir à des standards.

2.134 Collecticiel (groupware, groupweb), Télétravail

Le groupware peut se définir comme un ensemble de logiciels permettant l'échange de données au sein d'un groupe de travail. Le groupware comprend en règle générale une messagerie électronique et une GEIDE et s’intègre dans un workflow.

L’accessibilité des informations dans un collecticiel par l’intermédiaire du Web permet d’introduire la notion de groupweb (voir chapitre 2.2).

Le télétravail est caractérisé par la réalisation à domicile, ou en nomade dans une entité, d’un certain nombre de tâches en utilisant la possibilité de communiquer et de transmettre


à distance par ordinateur tout type de document. Les sociétés de services, qui utilisent les mêmes techniques, réalisent des téléservices. Grâce à l’essor du Web, les notions de télé-travail et de téléservices se fondent dans un environnement de travail de plus en plus na-turellement communicant.

La comptabilité n’échappe pas à cette évolution et les applications comptables à distance peuvent utiliser ces techniques. Les documents d’une société peuvent par exemple être stockés sur un serveur Internet afin que le cabinet d’expertise comptable puisse avoir accès à l’information. Les documents sont ensuite indexés et enregistrés en comptabilité. La société peut consulter enfin les informations comptables et les documents référencés.

De nombreuses tâches peuvent ainsi être intégrées, notamment :

• Clôture de fin de mois, de fin de trimestre, avant inventaire ou de fin d'exercice,

• Inventaire de fin d'année (collecte d'informations, de documents, etc.),

• Situation trimestrielle,

• Situation budgétaire,

• Consolidation,

• Archivage d'un dossier,

• Intégration des écritures d'extraits de compte bancaire dans la comptabilité avec les étapes successives à respecter.

2.135 Traçabilité

En matière de traçabilité, c'est-à-dire "l’aptitude à retrouver l’historique, l’utilisation ou la localisation d’un article ou d’une activité ou d’articles ou d’activités semblables au moyen d’une identification enregistrée" (définition AFNOR), le système doit permettre de s'assurer une similitude d'action entre le flux d’informations et le flux physique des biens. En d’autres termes, la facture datée du 30 décembre correspond-elle bien à un flux de marchandises antérieur au 31 décembre ? Cet exemple ne découvre qu’un petit aspect de la traçabilité. Il y en a bien d’autres.

Dans un système totalement dématérialisé, la démarche conduit à une rupture totale entre les flux physiques et informationnels.

Pour établir un lien permanent entre ces flux qui sont autonomes et entre des entités qui sont indépendantes par principe (et par obligation juridique), la coordination peut s’exercer sur trois domaines :

• la possibilité d’établir à tout moment un lien entre le flux physique et le flux d’information qui lui est logiquement associé, mais qui évolue à son propre rythme en fonction des besoins des partenaires impliqués ;


Flux d'informations

Identification des produits(étiquette codée à barres,

étiquette radio, car te magnétique,implant, etc.)

Flux physique

Echange dedonnées

Restitution

Télétransmission de donnéessystème standardisé universel

BD

Fou

rnis

seur

s

BD

Cli en ts

La traçabilité et les flux de données • la normalisation des identifiants de manière non univoque à travers un environnement

non homogène ;

• la normalisation des procédures d’interrogation et de réponse.

Sur un plan pratique, la traçabilité met en jeu de gros volumes de données générées selon des modalités propres à chaque entité ; il est donc plus économique de mémoriser et en-suite de consulter les données là où elles ont pris naissance plutôt que de les transférer systématiquement, ces données ne servant que dans un nombre limité de cas.

La traçabilité est un élément important de la crédibilité de l'entité : elle constitue un label de qualité et fidélise les partenaires.

2.14 Archivage des informations Toujours en bout de chaîne du traitement de l’information et quelle que soit la méthode de travail des services administratifs de l'entité, les données à conserver, qui sont pourtant sa mémoire, ont toujours été victimes d’un désintérêt, lequel a grandi au fur et à mesure de l’augmentation du nombre d’informations à stocker.

Une certitude existe : les entités produisent de plus en plus d’informations. Il faut donc disposer d’outils pour systématiser et rationaliser l’ensemble et pour retrouver rapidement les documents archivés. L’informatique permet cela et elle seule.

On constate aussi, aujourd’hui, une dilution totale des archives au sein du système d’in-formation de l'entité en même temps que le besoin de plus en plus pressant de retrouver rapidement l’information. Ce nouveau besoin est à couvrir au même titre que l’archivage proprement dit car, au bout du compte, l'entité ne fait plus la distinction entre archives mortes, semi vivantes et vivantes : toutes les informations doivent pouvoir être consul-tées en direct et dans un minimum de temps.


A ces observations, il convient d’ajouter une contrainte, une exigence d’ordre juridique : l’obligation pour l'entité de présenter ses archives en cas de contrôle quel qu’il soit (légal, judiciaire, audit interne ou externe, etc.). Cette contrainte n'est pas nouvelle mais il con-vient de le rappeler.

Ainsi, les archives doivent répondre à toutes ces contraintes auxquelles il faut adjoindre les notions classiques de sécurité et de pérennité des archives pour se prémunir contre des cessations d’activité de sociétés de services qui ne peuvent plus assurer le service après vente, contre les changements de version des logiciels dont les compatibilités ascendantes ne sont pas toujours assurées, voire contre les changements de systèmes informatiques, les systèmes d’exploitation pouvant être totalement discordants.

"L’archivage est dans ce contexte un sous-produit du système d’information auquel on assigne les fonctions suivantes :

• rapidité de restitution de l’information,

• proximité des informations,

• retraitement éventuel des informations.

De nouveaux besoins sont apparus qui sont principalement des besoins de com-munication : l’information doit être fiable, bien stockée et utilisable par plusieurs person-nes de l'entité".1

Les entités ont de plus en plus recours à un archivage électronique :

• soit dans un seul souci de conservation des informations et de meilleure gestion des dossiers,

• soit parce que le document n'a jamais eu de consistance matérielle,

• soit parce que la conservation de certains documents électroniques est rendue obliga-toire par un texte.

Exemples de documents dématérialisés : une facture scannée pour recueillir la totalité des informations, une saisie d’un journal comptable manuscrit, etc.

L'absence de distinction, sur le plan juridique, entre donnée immatérielle et document dématérialisé, n’est pas sans incidence au regard des règles de preuve en raison de la pré-sence ou de l’absence, selon la situation considérée, d’un document préalablement écrit.

Pour les "données immatérielles" qui se situent dans un état apparent de "non droit", l’emploi de compléments techniques s’avérera indispensable pour la validation juridique de l’ensemble de l’opération, tant au niveau de l’authentification et de la preuve qu’au niveau du contrôle ("Centre certificateur, authentification, preuve et contrôle" Alain BENSOUSSAN, Colloque du 10 novembre 1995 "Informatique, Télématique et Preuve"). En effet, sur le plan juridique, le recours à l'échange de données par télécommunication a pour corollaire la disparition de l’écrit.

Cette atteinte à l’un des piliers du système juridique latin doit être compensée par un véri-table dispositif de validation juridique, établi dans un contrat spécifique entre les utilisa-teurs de ce mode d’échanges. Tel est l’objet de l’accord d’échange entre entités, lequel devra, dans un premier temps, dénouer la position des données immatérielles au regard du formalisme juridique et des règles de preuve.

1 Mémoire Isabelle GUILLOU. Voir bibliographie.


Dans un second temps, cet accord d’échange aura notamment pour objet d’indiquer les documents qui seront transférés par voie télématique et de prévoir comment, en termes de preuve, seront résolus les éventuels litiges concernant le contenu de chacun des docu-ments dématérialisés qui ont été échangés.

Afin de gérer les questions de preuve, les parties désigneront un tiers indépendant, lequel tient son pouvoir des parties et non de la loi. Ce tiers devrait améliorer incontestablement la qualité de la preuve.

Le recours à un tiers indépendant est, pour l’instant, le moyen le plus sûr de prouver sa bonne foi ; cette solution semble aujourd’hui la seule possible dans les systèmes d’information des entités où les documents sont générés par l'entité elle-même, sans même parfois qu’il existe en contrepartie des pièces produites par des entités extérieures à l'entité.

L’intervention d’un tiers "témoin" ou d’un "tiers extérieur indépendant", semble pouvoir également être retenue, en l’état actuel du droit positif, pour les données immatérielles dans le secteur concerné par la présente étude.

D’ailleurs, il est intéressant de relever que les études menées au Canada sur la préserva-tion de l’intégrité des archives électroniques destinées à servir de fondement à un grand projet de recherche international, dont les premières conclusions ont été transmises, font ressortir que le meilleur garant de l’intégrité des documents mis en archive électronique consiste à confier :

• la responsabilité de la fiabilité des documents électroniques à l’organisme producteur,

• et celle de leur authenticité à l’organisme conservateur.

En conclusion, il apparaît :

• que l’organisme producteur d’informations pourrait être l'entité ou son expert-comptable,

• que l’organisme conservateur de ces informations pourrait être respectivement l’expert-comptable ou un tiers dans le cas où l’expert-comptable joue lui-même le rôle d’organisme producteur,

• que le sous-traitant informatique de l’organisme producteur ne peut être organisme conservateur.

Sachant qu’il est toujours possible de manipuler des archives immatérielles, le fait de les déporter vers un tiers extérieur archiveur dont le code de bonne conduite lui interdit toute manipulation de fichiers, apporte une garantie et une sécurité que les tribunaux et les arbi-tres pourraient apprécier.

Quatre cas ont pu être observés en France :


Donnée immatérielle

Document dématérialisé

Tiers archiveur

Pas de tiers archiveur

Code de bonne conduite

Codes civil, commercial et fiscal à observer

Acte juridique immatériel = vide juridique

Code de bonne conduite Codes civil, commercial et fiscal

à observer

12

34

1. le document est dématérialisé, il n’y a pas de tiers archiveur : c’est un cas fré-

quent aujourd’hui. Il convient de respecter les codes civil, commercial et fiscal en matière de preuve (conservation implicite du document original en matière civile et commerciale, conservation du document dématérialisé les trois premières années en matière fiscale).

2. le document est dématérialisé, il y a un tiers archiveur : le document dématérialisé peut être un moyen de preuve car une sécurité suffisante a été apportée sur des archi-ves qui ne peuvent plus être modifiées par les producteurs-détenteurs de celles-ci.

3. la donnée est immatérielle, il n’y a pas de tiers archiveur : la loi n’a apparemment pas prévu ce cas de figure très fréquent en comptabilité.

4. la donnée est immatérielle, il y a un tiers archiveur : la donnée immatérielle peut être un moyen de preuve car une sécurité suffisante a été apportée sur des archives qui ne peuvent plus être modifiées par les producteurs/détenteurs de ceux-ci.


2.2 L'organisation du système comptable des grandes et moyennes entités Outre tout ce qui touche les systèmes comptables des petites et moyennes entités, les grandes et moyennes entités doivent faire face également à la multiplicité des relations inter entités d'un même groupe et à la pluralité des sites de traitements.

Par expérience, compte tenu de la rapidité de rapprochement entre entités en matière de fusion, de scission, de regroupement d'unités de ventes ou de productions, etc., les sous-systèmes Comptabilité comme les sous-systèmes Informatique sont rarement homogènes. De ce fait, la standardisation des données comptables informatisées s'avère de plus en plus indispensable.

2.21 Le portage de la comptabilité sur le Web Une des solutions consiste à mettre en commun les comptes inter entités afin d'éliminer la conservation et l'archivage de tous les documents redondants entre les entités voire les partenaires commerciaux dans le cadre du commerce électronique et par suite les écritures comptables correspondantes. Cet objectif peut d'autant mieux être atteint grâce aux facili-tés de communication par Internet.

L'extension de ce concept à la comptabilité des tiers est déjà à l'étude en Amérique du Nord et chez les principaux éditeurs de progiciels de ERP. Il s'agit entre autres des projets PTR (Public Transaction Repository). WebLedger est une autre étude qui a débuté en 1999 et dont le concept repose sur la tenue des comptes par des fournisseurs de services hébergés Internet (BSP par exemple).

Parmi les services apportés, le fournisseur peut proposer ensemble ou séparément :

• le routage des documents commerciaux : cotation, bon de commande, confirmation de commande, bon de livraison, facture, traite, documents douaniers, etc. et accusés de réception correspondants, entre les tiers y compris les paiements et les accusés de réception correspondants ;

• l'horodatage des documents commerciaux ;

• la vérification des autorisations de dépenses et des signatures électroniques ;

• l'archivage des documents commerciaux ;

• l'archivage des écritures comptables de tiers correspondants générées automatique-ment ou fournies par l'un des tiers à la transaction commerciale et accusés de récep-tion correspondants ;

• l'archivage des écritures comptables de règlements correspondants générées automa-tiquement ou fournies par les organismes financiers lors de la transaction financière et extraits de comptes correspondants ;

• le plan comptable et la tenue des comptes et leur archivage ;

• etc.


LLee ccoonncceepptt WWeebbLLeeddggeerr

Le concept WebLedger vise par exemple à assurer et gérer la progression de toute tran-saction commerciale électronique depuis la commande jusqu’à la facture. Ce premier domaine d’application constitue déjà en soi un tout autonome. Depuis cette sorte de livre de bord, le concept peut être prolongé dans deux directions dérivées qui sont exposées ci-dessous.

Tout acte de commerce est à l’évidence la concrétisation de la volonté d’un acheteur d’acquérir un produit ou un service proposé par un vendeur. D’innombrables modèles ont analysé le processus depuis l’appel d’offre jusqu’à la livraison et la remise de la facture. Il est évident que la source de l’enregistrement comptable se trouve dans des données communes aux protagonistes en présence.

Les étapes successives depuis le bon de commande telles que confirmation de commande, avis de livraison, accusé de réception, etc., génèrent des informations échangées entre acheteur et vendeur en mode miroir. Les données relatives aux achats de l’un se retrou-vent parmi les informations relatives aux ventes de l’autre. Ce double enregistrement des mêmes données est remplacé par un "livre de bord" ou journal de transactions sur un site Web auxquels ils ont accès ensemble et séparément pour mise à jour et consultation.

Cette sorte de workflow se compose de différentes tables qui, pour chaque commande, permettent à l’un des partenaires de connaître les prévisions d’avancement et les étapes déjà franchies chez l’autre.

Une première table recense les données générales connues des parties : elle contient no-tamment les codes ou identifiants respectifs de l’acheteur et du vendeur, la référence et la date de la commande chez chacun des partenaires. On peut supposer que les partenaires ne feront généralement pas appel au même fournisseur de services hébergés ; cette table sera donc également capable de fournir l’adresse de la page Web du partenaire comme www.partenaire.com/commande/ vers laquelle le fournisseur de services pourra établir un hyper-lien.

Cette première table pointe vers une deuxième qui liste les lignes qui composent le bon de commande.

Outre les données habituelles telles que le code de référence de l’article, le prix unitaire et la quantité commandée, chaque ligne contient les différents champs que l’un et l’autre complètent à tour de rôle après exécution de chacune des phases intermédiaires.

Ainsi, le fournisseur pourra-t-il remplir les champs relatifs à l’accusé de réception de la commande, la date d’expédition, la quantité expédiée pour chaque article, le montant hors taxes, le montant de la taxe, la date de facturation pour chaque article, le numéro et la date de la facture, etc.

De son côté l’acheteur complétera au fur et à mesure les champs de confirmation de commande, l’accusé de réception des biens livrés, la date de remise à la banque et le mon-tant de l’ordre de règlement, etc.

AApppplliiccaattiioonnss ddeess ccoonncceeppttss ddee llaa ttrraaççaabbiilliittéé

Ce premier volet du concept fait partie de l’initiative eBIS-XML conduite par l’association BASDA (Business and Accounting Software Developers Association). Elle se retrouve partiellement ou totalement dans les offres des grands éditeurs de PGI tels que SAP ou Oracle Financials, en particulier dans les produits qu’ils proposent en ASP sur leurs sites internet. L’ubiquité de l’information signifie que l’information est simultané-


ment disponible en plusieurs lieux ou depuis plusieurs endroits à la fois. Cette propriété est aisément réalisable lorsque les deux partenaires font appel au même fournisseur de services ou feront usage des mêmes applications ou services hébergés.

LLee ccoonncceepptt WWeebbLLeeddggeerr :: dduu bboonn ddee ccoommmmaannddee jjuussqquu''aauuxx ccoommpptteess

La comptabilité est un des vingt-sept domaines identifiés par le projet de la Citibank Glo-bal Cash & Trade et concernés directement par le cycle des approvisionnements.

Un PGI établit sans peine la liaison entre ses différents modules, en particulier avec les sous-ensembles de comptabilité. Il n’en va pas de même lorsque les partenaires à la tran-saction (de 2 au moins, jusqu’à n) utilisent des systèmes de comptabilité incompatibles entre eux.

Les travaux entrepris par EDIFICAS depuis dix ans trouvent ici une application des plus évidentes. On se souviendra que la normalisation de l’écriture comptable était parmi les premières investigations de l’association.

V E N D E U R A C H E T E U R

vente&

livraison

achat&livraison

AR de commandecomptabilitélivraisoncomptabilité

commande

comptabilitéstock

comptabilité

facturation facturationfacturecomptabilité

facturecomptabilité

transfertde fonds

transfert de fonds

comptabilitéavis de créditcomptabilité

avis de débitcomptabilité

a r c h i v a g e

contrôle contrôlecircularisationcontrôlecomptabilitéétats financiers

circularisationcontrôle

comptabilitéétats financiers

paiement paiementdocument paiementcomptabilitédépôt banque

document paiementcomptabilité

pré-vente

pré-achat

offre

cotationdemande de cotation

Source - Michel Lesourd - UN-EWG Paris - 03-00 Génération d'écritures à chaque étape du cycle des achats

L’association du "Webjournal" au concept WebLedger permet de terminer la chaîne vers les comptes. L’écriture normalisée simplifie la création des affectations aux comptes par un ou plusieurs journaux auxiliaires dédiés à chaque étape du cycle des approvisionne-ments. L’écriture normalisée constitue le plus petit commun dénominateur servant de passerelle entre progiciels différents de comptabilité, qu’ils soient hébergés par un BSP2 ou un ASP3 ou encore que le sous-système comptable soit interne à l'entité ou externalisé au cabinet de l’expert comptable.

2 BSP : Business Services Providers (Fournisseurs de Services Hébergés) : il s'agit d'un concept de niche totalement

similaire à celui de ASP.

3 ASP : Applications Services Providers: Fournisseurs de Services et Applications Hébergés.


Les données nécessaires à la création automatique des écritures sont présentes dans les tables décrites ci-dessus. Ces données concernent notamment le numéro de compte du fournisseur dans la comptabilité du client et, symétriquement, celui du client dans la liste des comptes chez le fournisseur. Chaque ligne article comprend le numéro du compte d’investissement ou d’achat associé au bien ou service acquis, ainsi que le ou les comptes concernés par les taxes, le pourcentage et la ventilation de la déductibilité dans la comp-tabilité de l’acheteur ; parallèlement ces même lignes articles contiendront les données identifiant les comptes de ventes et taxes dans la comptabilité du vendeur.

Les journaux peuvent être envoyés automatiquement par le fournisseur de services héber-gés vers l’ordinateur du client (push) où ils sont mis en attente de traitement par le sous-système de comptabilité, ou à l’inverse conservés sur le site WebLedger jusqu’à leur télé-chargement commandé par l’utilisateur (pull) qui peut être l'entité ou le cabinet. Dans un cas comme dans l’autre, l'entité ou le cabinet dispose d’un sous-système comptable auto-nome.

Cette organisation est à rapprocher de celle des systèmes de gestion intégrés où chaque sous-système en amont de la comptabilité prépare les écritures et alimente les comptes.

La comptabilité chez un fournisseur de services hébergés est une alternative qui com-mence à voir le jour. La comptabilité se base alors sur de simples index et pointeurs vers toutes les lignes dont l’entité est propriétaire sur différents sites hôtes, entrepôts publics de transactions et sites WebLedger sur Internet, ainsi que la clé de chiffrement permettant de les lire.

Ce dispositif n’est certes pas actuellement envisageable en France pour des raisons essen-tiellement fiscales. Il est cependant techniquement possible et tous les éléments nécessai-res à un tel assemblage sont disponibles. La coopération entre les fournisseurs de services reste une inconnue qui pourrait cependant être résolue si d’aventure un grand du Web allait s’en mêler où si ceux-ci s'organisaient en syndicat pour gérer leur profession et créer des standards de communication.

Plus de fastidieuse copie de sauvegarde à faire, les comptes en ligne pour l’entité comme pour son expert comptable, l’accès depuis n’importe quel endroit du globe, plus de nou-velle version du progiciel à acheter et à installer, plus de problème d’espace disque à gé-rer.

Une plus grande porosité se fera entre la comptabilité et le commerce électronique ; telle est la tendance qui causera peut-être la fin des progiciels autonomes, que ce soit en entité ou dans les cabinets (voir le site http://www.gldialtone.com/exploration.htm).

2.22 La fourniture d'applications hébergées Les fournisseurs d'applications de gestion proposent aujourd'hui sur le marché une très large panoplie d'outils que l'utilisateur peut ou non utiliser directement. Il peut choisir deux solutions :

• soit il décide d'investir en faisant l'acquisition des matériels et des logiciels dont il a besoin,

• soit il délègue tout ou partie de ses applications à un prestataire extérieur. Le recours à une société de services, à un cabinet d'expertise comptable, etc., est ainsi une prati-que courante.


Depuis 1999, une nouvelle tendance est apparue, soutenue par de nombreux acteurs de l'industrie informatique : le modèle FAH (Fournisseur d'applications hébergées) ou ASP (Application Service Provider).

Le FAH peut proposer des solutions variées, partielles ou complètes, horizontales ou verticales (orientées métiers). La solution peut se limiter à un simple hébergement ; elle peut aussi concerner l'ensemble du traitement, englobant la gestion des communications. C'est une nouvelle forme d'offre qui, loin d'être une location d'applications en ligne, concerne un droit d'utilisation particulier.

Pour l'utilisateur, faire appel à un FAH revient à "externaliser" tout ou partie de ses trai-tements. La décision peut être organisationnelle, technique ou financière. Dans ce dernier cas, l'appel à des applications très coûteuses mais d'utilisation peu fréquente, peut s'avérer un nouveau débouché pour les sociétés de services et d'une très grande utilité pour les entités.

La répartition contractuelle des tâches entre le FAH et l'entité repose sur une constante communication entre les sous-systèmes résidant dans les entités et ceux offerts en loca-tion. Là également se situe tout un réseau de standards.


2.3 La communication de données informatisées De tout temps, la comptabilité a rassemblé les informations issues des sous-systèmes de l'entité pour fournir aux partenaires des informations agrégées.

2.31 La fonction communication La communication de ces données peut être faite en comptabilité dans les domaines sui-vants :

• au niveau des sorties, pour la télétransmission :

des déclarations fiscales aux centres des impôts et à des collecteurs publics et pri-vés (syndicats professionnels par exemple),

d'états de synthèse comme le reporting, la consolidation, les états statistiques, etc.,

de documents aux fins d'édition par le destinataire notamment en matière fiscale (TVA) et sociale (bulletin de salaire) (téléimpression) ou aux fins de consultation ou de contrôle (extraits de compte, dossier ou feuille de travail, etc.),

des archives de la comptabilité ;

• au niveau des entrées, pour la télétransmission :

des opérations bancaires (extraits de comptes),

des opérations "internes" à l'entité (sous-système Commercial, sous-système Paie, sous-système Productions, sous-système Stocks, sous-système Immobilisations, etc.),

des opérations en provenance des réseaux IP (Intranet, Extranet et Internet) ou de tout autre type (X400, CFT, etc.) : WebLedger, saisie décentralisée non client/serveur, etc.,

des opérations issues du télétravail (saisie ou production décentralisée) ;

• au niveau de la messagerie interne et externe ;

• etc.

Lorsque le sous-système de comptabilité intègre la fonction EDI pour l'un des domaines ci-dessus, il doit prendre en compte impérativement plusieurs composants résumés dans le schéma ci-dessous :


Pro

gici

el d

e co

mpt

abili

té

dictionnaire

traduction

interfaceavec les

applications

stockagedes messages

sécurité

traçage

Interface decommunication

Part

enai

res

EDI

Source - L'EDI. WEKA

Schéma d'émission d'informations issues d'un progiciel de comptabilité.

Les différents composants doivent donc assurer la conversion des informations du sous-système de comptabilité en messages et réciproquement, la gestion des normes figurant dans les dictionnaires, la gestion des messages tant en émission qu'en réception et leur stockage, le suivi des messages par la traçabilité, la sécurité des messages et leur transfert vers les partenaires à l'échange.

Ces composants peuvent être regroupés dans une fonction intégrée dans le sous-système de comptabilité, dans un progiciel autonome sur le même système ou dans une plate-forme spécialisée. Dans tous les cas, pour le confort de l'utilisateur, les outils de pilotage et de contrôle des composants de communication doivent être intégrés dans le sous-système de comptabilité afin d'éviter les va-et-vient entre la comptabilité et le composant de télécommunication et d'optimiser le contrôle.

2.32 Liaison avec le sous-système de comptabilité Lorsque le sous-système de comptabilité émet des informations vers des partenaires à l'échange, l'utilisateur souhaite connaître l'état d'avancement de ses envois. S'il est facile de gérer sans outil un petit nombre de messages, il est par contre difficile, voire impossi-ble, d'exercer un contrôle de qualité sur un grand nombre. Pour ce faire, des outils exis-tent qui permettent d'aider l'utilisateur à exercer son contrôle d'une part et, d'autre part, de vérifier à quelle étape le message a été refusé. Les huit étapes ci-dessous illustrent ceux généralement admis pour le suivi d'un document.

étapes de la traçabilité d'un message

Message émis par l'application, Message pris en charge par le convertisseur, Message traduit sans erreur, Message traduit avec erreur, Message préparé pour télétransmission, Message transmis dans la messagerie du destinataire, Message lu dans la messagerie du destinataire, Message pris en charge par l'application du destinataire.

Source : L'EDI. WEKA.


De son côté, l'AFNOR a défini un tableau des besoins fonctionnels de sécurité, de preuve recherchée et d'offre technologique, dont un extrait figure ci-après :

besoin offre technologique remarques

1 Habilitation de l'émetteur identification, authentification, autorisation

éléments d'authentification

2 Habilitation du partenaire EDI identification, authentification, autorisation

éléments d'authentification

3 Attestation de tentative d'émission dans le cas où une transmission requise n'a pu être effectuée à temps

4 Attestation d'émission avis de dépôt 5 Attestation de tentative de livraison dans le cas où une transmission n'a pu être

effectuée jusqu'à son terme 6 Attestation de livraison au partenaire EDI accusé de réception le partenaire certifie que toutes les conditions

d'échange convenues étaient respectées et que les éléments de sécurité (chiffrement, etc.) ont été activés.

7 Engagement de l'émetteur vis-à-vis du partenaire EDI sur les informations émises

non répudiation de l'émetteur l'émetteur ne peut renier ce qui a été remis

8 Reconnaissance par le partenaire EDI des informations reçues et du respect des conditions d'échange convenues

non répudiation du partenaire EDI le partenaire EDI ne peut nier ce qui a été émis

9 Détection de l'altération de l'information échangée

intégrité les deux protagonistes sont mutuellement impliqués dans le contrôle

10 Assurance de la confidentialité des informations pendant l'échange

confidentialité les deux protagonistes sont mutuellement impliqués dans le contrôle

11 Disposition d'une chronologie opposable horodatage ne peut être établie que par contrat

2.33 Conversion des informations La conversion des informations en documents et réciproquement est une étape importante après celle qui assure la liaison avec le sous-système de comptabilité. Généralement, lors-qu'il ne s'agit pas de fichier natif c'est-à-dire généré directement par le sous-système de comptabilité, les informations issues de l'application passent par un convertisseur appelé traducteur dans le monde EDIFACT, parseur dans le monde XML, etc.

La conversion transforme un format de données en un autre format. Il s'agit de passer d'un format privatif à un format normalisé ou réciproquement. La solution qui consisterait à générer directement un format normalisé est risquée et peu évolutive notamment quant à l'intégration de nouveaux partenaires, de nouvelles versions de la norme ou du message, d'évolution de la législation, etc. La conversion permet d'éviter cela en imposant une in-dépendance application/norme.

Les critères relevés dans les points à examiner et non repris ici, servent principalement à sélectionner les convertisseurs. Ce sont également d'excellents critères à exiger de tout type de convertisseurs.


2.34 Signature électronique La signature électronique est un mode de signature d'un document lui-même électroni-que. Elle permet d'associer la volonté d'une personne au contenu dudit document tout en garantissant sa qualité ou sa fonction, son authentification, sa non répudiation, l'intégrité dudit document. Cette notion ne doit pas être confondue avec celle de sécurisation élec-tronique aussi appelée signature électronique dans le monde de la sécurité informatique.

Quels que soient les noms donnés aux 'sceaux' d'un fichier ou d'un message, il faut pren-dre garde qu'ils répondent à des fonctions précises afin d'éviter toutes sortes de confusion ultérieure :

• signature électronique pour la sécurisation du transport du message : il s'agit ici d'un problème unique de sécurité qui permet de vérifier l'authentification, l'intégrité et la non répudiation ; cette signature peut être déléguée à une secrétaire ou au service courrier interne d'une entité car elle correspond à l'équivalent 'lettre recommandée avec accusé de réception' ;

• signature électronique pour assurer la confidentialité du message : il s'agit ici de chif-frer le contenu d'un document inclus dans un message afin de ne pas autoriser sa lec-ture directe en cas d'interception (cas des données nominatives ou de données sensibles par exemple) ;

• signature électronique pour engager sur le contenu d'un message : dans ce cas, il s'agit toujours d'associer le nom d'un signataire et sa fonction ; ainsi, une liasse fiscale peut comporter plusieurs signatures de ce type, celle de l'expert-comptable qui vise le do-cument en tant que tel (signature attachée au contenu d'un document dans le cadre de la fonction d'expert-comptable qui a rempli une mission) et celle du chef d'entité qui signe le document en s'engageant sur le contenu de celui-ci (c'est le seul à le faire) ;


Texteclair

Signature

CompressionChiffrement

Codage DécodageDéchiffrement

Décompression

Vérificationde signature

Texteclair

Alice Bob

Enchaînement des opérations de sécurisation d’un message.

Toutes ces signatures doivent être indépendantes bien qu'elles utilisent sensiblement les mêmes algorithmes de calcul. Elles sont l'aboutissement d'une suite d'opérations qui doi-vent être intégrées dans le progiciel de comptabilité. Le schéma ci-après donne un aperçu d'un échange entre Alice et Bob avec signature, compression, chiffrement et codage.

La signature doit pouvoir être intégrée dans les documents électroniques comme sur n'importe quel document papier. C'est une question de qualité et de sécurité de l'informa-tion.


333... LLLEEESSS NNNOOORRRMMMEEESSS EEETTT CCCOOONNNCCCEEEPPPTTTSSS IIINNNFFFOOORRRMMMAAATTTIIIQQQUUUEEESSS CCCOOOMMMPPPTTTAAABBBLLLEEESSS

Comme il a été précisé dans les chapitres précédents, pour diffuser les informations fi-nancières agrégées issues d'un sous-système d'information comptable, c'est tout l'ensem-ble du sous-système qu'il faut analyser et standardiser. Ce qui est exposé ci-après est la reprise (simplifiée volontairement pour le présent rapport) de l'analyse faite à la fin des années '80 par l'association EDIFICAS. Depuis, cette date, il n'y a pas eu d'événement susceptible de modifier le modèle. Il est rappelé à cette occasion, que le modèle est euro-péen puisque plusieurs pays ont participé à l'élaboration finale des standards.

Le modèle s'appuie sur un constat qui relève une convergence de pratiques. Les docu-ments de l'entreprise, quels qu'ils soient, sont dématérialisés systématiquement lorsqu'ils ne le sont pas déjà. Ensuite, la comptabilité suit un processus complètement immatériel qui fait qu'il n'y a plus d'original ou de copie comptable, de report d'un livre à un livre, etc.

3.1 Les normes informatiques comptables de base Les normes informatiques comptables se basent sur les capacités des logiciels présents et futurs à introduire des écritures de tout type, les classer et restituer des informations agré-gées. Pour ce faire, les normes, qui ne reprennent pas les normes de procédures de télé-transmission, s'appuient sur les composants ci-après :

• identification du fichier comptable,

• identification de l'écriture comptable,

• identification du plan de comptes,

• identification du journal.

Pour diffuser ces composants, une enveloppe unique de transport est définie par ailleurs répondant aux normes internationales ISO et UN/CEFACT. Elle contient les informations nécessaires au cheminement dans les réseaux internes et externes.

3.11 Le fichier comptable Le "stockage4" des écritures comptables s'effectue par fichier correspondant sans obliga-tion à des périodes comptables civiles. Il est donc nécessaire d'identifier l'entité concer-née, la personne ou le département ayant procédé audit "stockage", la comptabilité elle-même, le type de fichier, les logiciels utilisés et quelques paramètres comptables.

Les définitions de chacune des informations requises figurent au regard de celles-ci.

4 Le stockage correspond soit à un archivage, soit à une sauvegarde, soit à un stockage temporaire pour reprise ulté-rieure.


Identification de l'entité personnelle ou sociétale traitée nom complet de l'entité traitée identification par sa dénomination complète de l'entité personnelle ou socié-

tale traitée.

nom abrégé de l'entité traitée identification par sa dénomination abrégée, lorsqu'elle existe, de l'entité per-sonnelle ou sociétale traitée.

catégorie sociale de l'entité traitée

identification de la catégorie de dénomination de l'entité personnelle ou socié-tale traitée.

forme légale de l'entité traitée identification de la forme légale de l'entité personnelle ou sociétale traitée.

identification nationale de l'entité traitée identification nationale de l'entité personnelle ou sociétale traitée.

catégorie de nom de person-nes

identification de la catégorie de nom de personne s'il s'agit d'une entité per-sonnelle.

civilité de la personne identification de la civilité de la personne s'il s'agit d'une entité personnelle.

adresse de l'entité traitée identification de l'adresse de l'entité traitée.

Identification de la personne ou du département personne à l'origine de la création du fichier

identification de la personne ou du département qui a procédé à la constitu-tion du fichier.

fonction de la personne à l'origine de la création du fichier

identification de la fonction de la personne ou du département qui a procédé à la constitution du fichier.

mode de communication de la personne à l'origine de la création du fichier

identification du mode de communication de la personne ou du département qui a procédé à la constitution du fichier.

n° appel de la personne à l'origine de la création du fichier

identification du n° d'appel de la personne ou du département qui a procédé à la constitution du fichier.

n° de compte bancaire de l'entité traitée

identification du n° de compte bancaire de l'entité personnelle ou sociétale traitée.

nom de l'institution financière de l'entité traitée

identification du nom de l'institution financière de l'entité personnelle ou socié-tale traitée.

Identification de la comptabilité de l'entité méthode comptable utilisée identification de la méthode comptable utilisée. plan de comptes utilisé identification du plan de comptes utilisé.

monnaie utilisée identification de la monnaie utilisée par la comptabilité.

période annuelle comptable identification de la période couverte par l'exercice comptable.

période annuelle fiscale identification de la période couverte par l'exercice fiscal.

Information concernant le fichier traité totaux monétaires de contrôle totaux monétaires de contrôle du fichier traité.

monnaie utilisée pour les totaux de contrôle identification de la monnaie utilisé des totaux de contrôle du fichier.

totaux de contrôle des quanti-tés totaux de contrôle des quantités du fichier traité.

date/heure de préparation du fichier identification de la date/heure de préparation du fichier traité.

référence du fichier identification de la référence du fichier traité.

date/heure de période comp-tabe identification de la date/heure de la période comptable du fichier traité.

accusé de réception identification de la demande d'accusé de réception.


date/heure de création du fichier identification de la date/heure de création du fichier traité.

nature du fichier traité identification de la nature du fichier traité pour indiquer qu'il est provi-soire ou à l'essai.

Identification des logiciels utilisés logiciel source ou destination Identification du logiciel source ou de destination.

nom du logiciel Identification du nom du logiciel ayant créé le fichier traité.

n° de version du logiciel Identification du n° de version du logiciel ayant créé le fichier traité.

n° de révision du logiciel Identification du n° de révision du logiciel ayant créé le fichier traité.

nom de l'éditeur du logiciel Identification du nom de l'éditeur du logiciel.

dernière de date de mise à jour du logiciel Identification de la dernière date de modification du logiciel.

Identification du plan de comptes utilisé référence du plan de comptes utilisé Identification de la référence du plan de comptes utilisé.

n° de version du plan de comptes utilisé Identification du n° de version du plan de comptes utilisé.

n° de révision du plan de comptes utilisé Identification du n° de révision du plan de comptes utilisé.

date de début d'utilisation du plan de comptes Identification de la date de début d'utilisation du plan de comptes.

Informations diverses Information concernant le fichier Information libre jointe au fichier traité.

3.12 L'écriture comptable Le plus petit dénominateur commun de tout système comptable est l'écriture comptable. On entend par écriture comptable, un ensemble de plusieurs lignes comptables informa-tiques relatives à un même événement. Une ligne comptable informatique est une partie d'une écriture comptable comportant plusieurs données reliées logiquement entre elles précisant entre autres pour un seul montant, sa date de valeur, son origine, son compte d'affectation, son sens débit/crédit et ses références à la pièce justificative.

Chaque écriture comptable informatique contient les informations ci-dessous. La totalité des informations n'est pas acquise dès la création de l'événement comptable, l'écriture s'enrichissant au fur et à mesure de son avancement dans le système comptable informati-que. Informations concernant le document à l'origine de la ou des écritures

catégorie de pièce comptable identification et spécification caractéristiques d'un objet ou d'un document destiné à être une pièce comptable.

référence interne de la pièce comptable

identification de la référence interne de la pièce comptable donnée par un département ou un service.

référence d'origine de la pièce comptable

identification du numéro figurant sur la pièce comptable. En règle générale, n° attribué par le fournisseur, la banque ou le partenaire extérieur à l'entité.

date de la pièce comptable identification de la date figurant sur la pièce comptable attribuée par le four-nisseur, la banque ou le partenaire extérieur à l'entité.

date d'entrée ou de réception dans l'entité

identification de la date à laquelle la réception de la pièce comptable a été actée par l'entité ou le service qui en est destinataire.

localisation de la pièce comp-table

identification de la localisation de la pièce comptable dans un service, une archive, etc.


commentaire apporté à la pièce comptable commentaire explicite relatif à la pièce comptable.

service à l'origine de la pièce comptable

identification du service à l'origine de la réception de la pièce comptable : département, division, sous-entité, filiale, etc.

Informations communes concernant l'écriture pour l'ensemble des lignes la composant

journal comptable d'origine identification du document comptable dans lequel sont enregistrées les écritu-res comptables.

catégorie d'écriture compta-ble identification d'une sorte d'écritures comptables.

statut de l'écriture comptable identification du statut de traitement de l'écriture. date de réversibilité de l'écri-ture

identification de la date à laquelle l'écriture doit être extournée ou contre-passée.

date de validation identification de la date à laquelle l'écriture comptable est validée par un responsable et devient par conséquent définitive.

Libellé comptable commentaire explicite relatif à l'écriture comptable.

Libellé automatique code identifiant une catégorie de pièce comptable figurant dans un libellé comptable et permettant une exploitation automatique par des outils de révi-sion.

libellé comptable complémen-taire commentaire explicite complémentaire au libellé comptable.

écriture déséquilibrée identification d'une écriture qui n'est pas encore équilibrée.

Informations élémentaires composant une ligne d'écriture Identification d'une ligne d'écriture

niveau de ligne identification du niveau de ligne pour placer un niveau comptable avant un autre. Par exemple : Comptabilité Générale en amont de la Comptabilité Analytique, comptabilité budgétaire avant comptabilité analytique, etc.

catégorie de ligne comptable identification de la catégorie de journal.

élimination automatique de la ligne comptable

identification d'une ligne comptable devant faire l'objet d'une élimination automatique en cas de consolidation.

numéro de ligne comptable identification du numéro d'ordre affecté à l'entrée d'une ligne comptable dans le journal attribué automatiquement et séquentiellement par le système.

n° de folio du document de saisie

identification du numéro de page d'un journal manuscrit ou informatique pour une période concernée.

n° de ligne du document de saisie

identification du numéro d'ordre donné à la ligne à l'intérieur d'un folio affecté à la saisie.

NB - Obligatoire soit FOLIO/LIGNE, soit N° LIGNE COMPTABLE Information d'une ligne comptable date de saisie de la ligne comptable

identification de la date à laquelle l'événement a été pris en charge par le système comptable informatique.

date de valeur comptable

identification de la date essentielle prise en compte pour le rattachement d'une ligne comptable à une période : cette date peut être soit la date de la pièce comptable, la date d'entrée ou de réception dans l'entité ou la date de saisie de la ligne comptable.

catégorie d'origine de la ligne comptable identification de l'origine de l'entrée de la ligne comptable.

numéro de compte

identification du ou des numéro(s) de comptes du ou des plans des comptes utilisé(s) par l'entité : n° compte général, auxiliaire, analytique, budgétaire ou de ventilation, etc. Généralement, le compte est identifié par un nom complet et/ou abrégé, une monnaie de base et une référence à la catégorie de plans de comptes.

code débit/crédit identification unique d'un code Débit ou Crédit lié à la ligne d'écriture.


signe du montant

identification unique du sens positif ou négatif des montants de ligne compta-ble. Combiné avec le code débit/crédit, il permet d'obtenir quatre positions pour un montant (débit + ou -, crédit + ou -) afin de localiser les non flux ne correspondant pas à des flux financiers (par exemple, régularisation de comp-tes), pour faciliter les analyses financières.

montant en monnaie de tenue de compte

identification du montant exprimé en monnaie de tenue de compte ; il corres-pond à la ligne comptable informatique et est unique par ligne comptable.

code devise du montant en monnaie de tenue de compte identification de la monnaie liée au montant en monnaie de tenue de compte.

Montant d’origine identification du montant exprimé sur la pièce comptable ; il correspond à la ligne comptable informatique et est unique par ligne comptable ; il complète le montant de tenue en retraçant les conditions initiales d'une opération.

code devise du montant d'origine identification de la monnaie liée au montant d'origine.

catégorie de taxe, droit et versement assimilé

identification de la catégorie de taxe, droit ou versement relatif à la ligne comptable.

base de calcul de taxe, droit et versement assimilé

identification de la base sur laquelle se calcule la taxe, le droit ou le verse-ment relatif à la ligne comptable.

taux de taxe, droit et verse-ment assimilé identification du taux de taxe, droit ou versement relatif à la ligne comptable.

commentaire apporté à la ligne comptable commentaire explicite relatif à la ligne comptable.

Information de contrôle

code de lettrage

identification des caractères alphanumériques constituant la référence de rapprochement entre le montant de cette ligne affecté à un compte de la comptabilité de l'entité et un ou plusieurs autre(s) montant(s) affecté(s) au même compte de la comptabilité de la même entité.

code de pointage

identification des caractères alphanumériques constituant la référence de rapprochement entre le montant de cette ligne affecté à un compte de la comptabilité de l'entité et un ou plusieurs autre(s) montant(s) d'un ou de plusieurs autre(s) compte(s) de la comptabilité de la même entité ou d'une comptabilité d'une autre entité.

Informations financières date d'échéance identification de la date de règlement accepté ou prévisible.

date de valeur financière identification de la date de valeur financière, date à laquelle la ligne compta-ble est enregistrée dans les organismes financiers ou chez les tiers concer-nés.

banque de paiement identification de la ou des banque(s) et du ou des compte(s) à utiliser.

modalités de paiement identification des modalités de paiement.

garantie de paiement identification des garanties pour un paiement différé ou non.

moyen de paiement identification des moyens de paiement.

acheminement du paiement identification du mode d'acheminement du paiement.

conditions de paiement identification des conditions de paiements.

moment du paiement identification du moment du paiement.

lien temporel du paiement identification du lien temporel au moment du paiement.

catégorie de période du paiement identification de la catégorie de période de paiement.


nombre de périodes de paie-ment identification du nombre de périodes pour procéder au paiement complet.

montant devise le montant libellé en devises correspond à la ligne comptable informatique et est unique par ligne comptable ; il vient en complément du montant libellé en monnaie de tenue de compte.

code devise du montant devise identification de la monnaie liée au montant devise.

Informations complémentaires comptables quantité indication d'une quantité attachée à un montant : nombre d'unités pour une

acquisition d'immobilisation, etc.

unité quantité identification de l'unité utilisée : km, kg, quantité de devises, litre, etc.

libellé d'un abonnement identification du libellé des informations permettant l'abonnement de charges ou de produits.

date de début d'abonnement identification de la date de début de période permettant l'abonnement de charges ou de produits.

date de fin d'abonnement identification de la date de fin de période permettant l'abonnement de charges ou de produits.

nombre de répétitions d'abon-nement

identification du nombre total de répétitions périodiques permettant l'abonne-ment de charges ou de produits.

nombre de répétitions restant à servir

identification du nombre de répétitions périodiques restant à servir permettant l'abonnement de charges ou de produits.

périodicité d'abonnement identification de la périodicité (jour, semaine, mois, trimestre, etc.) liée au nombre de répétitions d'abonnement ou restant à servir.

catégorie de travail réalisé identification d'une catégorie de travail, d'une phase de travail ou d'une fonc-tion attachée à la ligne comptable.

clé de répartition identification par un code de renvoi à une table de clés de répartition analyti-que, budgétaire, de ventilation, etc.

Informations concernant les immobilisations durée de vie fiscale de l'amor-tissement à pratiquer

identification de la durée fiscale de l'amortissement à pratiquer telle que prévue par la législation nationale.

unité de mesure durée de vie fiscale

identification de l'unité de mesure appliquée à la durée fiscale de l'amortisse-ment à pratiquer.

durée de vie économique de l'amortissement à pratiquer

identification de la durée économique de l'amortissement à pratiquer telle que prévue par la législation nationale.

unité de mesure durée de vie économique

identification de l'unité de mesure appliquée à la durée économique de l'amor-tissement à pratiquer.

durée de vie en juste valeur de l'amortissement à prati-quer

identification de la durée de l'amortissement à pratiquer telle que prévue par les normes IAS/IFRS.

unité de mesure durée de vie en juste valeur

identification de l'unité de mesure de la durée de vie en juste valeur de l'amor-tissement à pratiquer.

méthode d'amortissement à pratiquer

identification de la méthode d'amortissement à pratiquer pour le bien acquis : linéaire, dégressif, digital, etc.

base d'amortissement à pratiquer en monnaie de tenue de compte

identification de la base du calcul de l'amortissement à prendre en considéra-tion en monnaie de tenue de compte, lorsque le montant à amortir diffère du montant d'acquisition dans cette même monnaie.

code devise de la base d'amortissement à pratiquer

identification de la monnaie liée à la base d'amortissement à pratiquer en monnaie de tenue de compte.

valeur résiduelle de bien à amortir

identification de la valeur résiduelle non amortissable (valeur de revente par exemple) du bien à amortir.

code devise de la valeur résiduelle de bien à amortir identification de la monnaie liée à la valeur résiduelle du bien à amortir.

date de début d'amortisse-ment à pratiquer

identification de la date à partir de laquelle commence effectivement l'amor-tissement du bien acquis.

Coût de destruction à la fin de durée de vie

identification du coût de la destruction du bien à amortir en fin de période de vie.


code devise du coût de des-truction du bien à amortir identification de la monnaie liée au coût de destruction du bien à amortir.

Coût de l'entretien annuel identification du coût de l'entretien annuel prévisionnel du bien à amortir.

Code devise du coût de l'entretien annuel identification de la monnaie liée au coût d'entretien annuel.

Volume de production annuel identification du volume de production annuel relatif à l'utilisation du bien à amortir.

Taux d'actualisation identification du taux d'actualisation utilisé pour certaines formules de calcul d'amortissement.

Taux de réévaluation identification du taux de réévaluation utilisé pour certaines formules de calcul d'amortissement.

Raison arithmétique identification de la raison arithmétique utilisée pour certaines formules de calcul d'amortissement.

Raison géométrique identification de la raison géométrique utilisée pour certaines formules de calcul d'amortissement.

Nombre d'heures de travail annuel

identification du nombre d'heures de travail annuel utilisé pour certaines formules de calcul d'amortissement.

Abattement à la base d'amor-tissement

identification de l'abattement à la base d'amortissement utilisé pour certaines formules de calcul d'amortissement.

code devise de l'abattement à la base d'amortissement identification de la monnaie liée à l'abattement à la base d'amortissement.

Informations concernant les modifications de lignes d'écriture date de dernière modification de la ligne d'écriture

identification de la date de la dernière modification avant validation de la ligne d'écriture réalisée par un département ou un service responsable.

responsable de la dernière modification de la ligne d'écri-ture

identification du département ou du service responsable de la dernière modi-fication de la ligne d'écriture.

Ces enregistrements sont classés pour la télétransmission soit par ordre de journal d'ori-gine, soit par ordre de n° de compte, mais l'ordre n'a pas d'importance dans la mesure où tous les logiciels de comptabilité ont une fonction tri très rapide. Dans certains cas, le fichier correspond à un seul compte et donc il n'y a pas d'équilibre débit/crédit. C'est no-tamment le cas d'un extrait de compte délivré à des clients ou des fournisseurs.

3.13 Le jeton comptable C'est à partir du format de l'écriture comptable (voir 3.12) qu'est tiré le "jeton" comptable qui permet de préparer l'enregistrement informatique correspondant des événements éco-nomiques de l'entreprise, automatiquement à partir des chaînes d'information de l'entité.

En procédant ainsi, on assiste à un renforcement du contrôle interne de l'entité, à une coopération plus étroite entre les directions de l'entité, à une intégration plus forte de la comptabilité dans les opérations économiques de l'entité et à un allègement du travail administratif.

La transaction commerciale a été largement analysée en particulier pour les relations EDIFACT entre acheteur et vendeur, leurs partenaires en matières de transport et d'assu-rance et leurs intermédiaires financiers respectifs. Les aspects comptables avaient été omis lors de cette première analyse.

ebXML a redéfini l'orchestration générale de cette transaction à partir des modes de com-portement attendu de chacun des partenaires. Le jeton comptable est destiné à compléter l'analyse initiale. Le modèle évoqué ci-dessus à titre d'exemple (voir Le concept We-bLedger : du bon de commande jusqu'aux comptes) montre l'imbrication normale de la


comptabilité à chaque étape de la chaîne des approvisionnements et met en exergue le mécanisme logique de la création des écritures comptables reflétant l'avancement du flux événementiel et financier en parallèle de celui des biens ou services.

Le contenu du jeton comptable est contextuel (encore que symétrique) selon qu'il vise la comptabilité de l'acheteur ou la comptabilité du vendeur, son contenu évoluant en rapport direct avec la progression de l'exécution du processus de la fonction dont il est issu et se complétant d'informations ensuite dans la chaîne d'information comptable..

A. Chez l'acheteur / le vendeur

Le jeton comptable comprend tous les éléments nécessaires à la production des écritures entre la commande (en tout cas à partir de son acceptation par l'acheteur et le vendeur), la réception de la facture et son règlement.

Il en va de l'identification des comptes suivants donnés à titre d'exemple : • identification du compte du fournisseur/client dans la comptabilité de l'acheteur /

vendeur, • le ou les comptes d'achat/vente s'il y a lieu de les différencier par ligne article, • le ou les comptes taxes à déduire/à payer, • le ou les comptes éventuels de remise, escompte ou rabais, • le ou les comptes d'immobilisation si nécessaire chez l'acheteur, • le ou les comptes d'amortissement d'immobilisation si nécessaire chez l'acheteur, • le compte Facture à recevoir / Facture à payer, • le compte comptable correspondant à l'organisme financier par lequel le règlement de

la facture sera opéré, • pour un ou plusieurs de ces comptes, le ou les comptes analytiques ou budgétaires, • etc.

B. Les étapes successives du modèle

1. Le bon de commande • chez l'acheteur : trace déjà l'engagement pris qui se traduit par une écriture aux

comptes de la catégorie hors bilan avec le cas échéant et imputation de cet enga-gement au(x) compte(s) budgétaire(s) ;

• chez le vendeur : le vendeur n'est pas encore concerné.

2. La confirmation / acceptation de la commande • chez l'acheteur : rien ne se passe si l'engagement a déjà été constaté à la com-

mande ; dans le cas contraire, l'engagement est constaté comme prévu à l'étape bon de commande (1) ;

• chez le vendeur : trace de l'engagement de vente qui se traduit par une écriture aux comptes de la catégorie hors bilan avec le cas échéant, imputation de cet en-gagement au(x) compte(s) budgétaire(s).

3. La réception / livraison physique du bien ou service • chez l'acheteur : trace de la réception physique et annulation des écritures d'enga-

gement d'achat au profit des écritures d'achats ; • chez le vendeur : trace de la sortie physique et annulation des écritures d'engage-

ment de vente au profit des écritures ventes.

4. Emission / réception de la facture


• chez l'acheteur : enregistrement de la facture en comptabilité si ce n'est déjà fait à l'étape 3 ;

• chez le vendeur : établissement de la facture en comptabilité si ce n'est déjà fait à l'étape 3.

5. Emission / réception de l'ordre de paiement de la facture • chez l'acheteur : émission de l'ordre de paiement (ou remise de chèque ou autre

mode de règlement) et enregistrement en comptabilité ; • chez le vendeur : réception de l'ordre de paiement (ou remise de chèque ou autre

mode de règlement) et enregistrement en comptabilité.

6. Réception de l'avis de crédit / débit de la banque (pour mémoire).

Cela dit, le jeton comptable comprend les informations suivantes, toutes issues de l'écri-ture comptable, mais constituant un sous-ensemble de cette dernière.

Informations concernant le document à l'origine de la ou des écritures

catégorie de pièce comptable identification et spécification caractéristiques d'un objet ou d'un document destiné à être une pièce comptable.

référence interne de la pièce comptable

identification de la référence interne de la pièce comptable donnée par un département ou un service.

référence d'origine de la pièce comptable

identification du numéro figurant sur la pièce comptable. En règle générale, n° attribué par le fournisseur, la banque ou le partenaire extérieur à l'entité.

date de la pièce comptable identification de la date figurant sur la pièce comptable attribuée par le fournisseur, la banque ou le partenaire extérieur à l'entité.

date d'entrée ou de réception dans l'entité

identification de la date à laquelle la réception de la pièce comptable a été actée par l'entité ou le service qui en est destinataire.

localisation de la pièce compta-ble

identification de la localisation de la pièce comptable dans un service, une archive, etc.

commentaire apporté à la pièce comptable commentaire explicite relatif à la pièce comptable.

service à l'origine de la pièce comptable

identification du service à l'origine de la réception de la pièce comptable : département, division, sous-entité, filiale, etc.

Informations communes concernant l'écriture pour l'ensemble des lignes la composant journal comptable d'origine identification du document comptable dans lequel sont enregistrées

les écritures comptables. catégorie d'écriture comptable identification d'une sorte d'écritures comptables. statut de l'écriture comptable identification du statut de traitement de l'écriture.

Libellé comptable commentaire explicite relatif à l'écriture comptable.

Libellé automatique code identifiant une catégorie de pièce comptable figurant dans un libellé comptable et permettant une exploitation automatique par des outils de révision.

libellé comptable complémen-taire commentaire explicite complémentaire au libellé comptable.

Informations élémentaires composant une ligne d'écriture Identification d'une ligne d'écriture

niveau de ligne identification du niveau de ligne pour placer un niveau comptable avant un autre. Par exemple : Comptabilité Générale en amont de la Comptabilité Analytique, comptabilité budgétaire avant comptabilité analytique, etc.

catégorie de ligne comptable identification de la catégorie de journal.

élimination automatique de la ligne comptable

identification d'une ligne comptable devant faire l'objet d'une élimination automatique en cas de consolidation.


numéro de ligne comptable identification du numéro d'ordre affecté à l'entrée d'une ligne comptable dans le journal attribué automatiquement et séquentiellement par le sys-tème.

Information d'une ligne comptable

date de valeur comptable

identification de la date essentielle prise en compte pour le rattache-ment d'une ligne comptable à une période : cette date peut être soit la date de la pièce comptable, la date d'entrée ou de réception dans l'entité ou la date de saisie de la ligne comptable.

numéro de compte

identification du ou des numéro(s) de comptes du ou des plans des comptes utilisé(s) par l'entité : n° compte général, auxiliaire, analyti-que, budgétaire ou de ventilation, etc. Généralement, le compte est identifié par un nom complet et/ou abrégé, une monnaie de base et une référence à la catégorie de plans de comptes.


signe du montant

identification unique du sens positif ou négatif des montants de ligne comptable. Combiné avec le code débit/crédit, il permet d'obtenir quatre positions pour un montant (débit + ou -, crédit + ou -) afin de localiser les non flux ne correspondant pas à des flux financiers (par exemple, régularisation de comptes), pour faciliter les analyses finan-cières.


identification du montant exprimé en monnaie de tenue de compte ; il correspond à la ligne comptable informatique et est unique par ligne comptable.

code devise du montant en monnaie de tenue de compte

identification de la monnaie liée au montant en monnaie de tenue de compte.


code devise du montant d'ori-gine identification de la monnaie liée au montant d'origine.

catégorie de taxe, droit et ver-sement assimilé

identification de la catégorie de taxe, droit ou versement relatif à la ligne comptable.

base de calcul de taxe, droit et versement assimilé

identification de la base sur laquelle se calcule la taxe, le droit ou le verse-ment relatif à la ligne comptable.

taux de taxe, droit et versement assimilé identification du taux de taxe, droit ou versement relatif à la ligne comptable.

commentaire apporté à la ligne comptable commentaire explicite relatif à la ligne comptable.

Informations financières date d'échéance identification de la date de règlement accepté ou prévisible.

date de valeur financière identification de la date de valeur financière, date à laquelle la ligne comp-table est enregistrée dans les organismes financiers ou chez les tiers concernés.

banque de paiement identification de la ou des banque(s) et du ou des compte(s) à utiliser. modalités de paiement identification des modalités de paiement. garantie de paiement identification des garanties pour un paiement différé ou non. moyen de paiement identification des moyens de paiement. acheminement du paiement identification du mode d'acheminement du paiement.

conditions de paiement identification des conditions de paiements.

moment du paiement identification du moment du paiement.

lien temporel du paiement identification du lien temporel au moment du paiement.

catégorie de période du paie-ment identification de la catégorie de période de paiement.

nombre de périodes de paie-ment identification du nombre de périodes pour procéder au paiement complet.

montant devise le montant libellé en devises correspond à la ligne comptable informatique et est unique par ligne comptable ; il vient en complément du montant libellé en monnaie de tenue de compte.


code devise du montant devise identification de la monnaie liée au montant devise.

Informations complémentaires comptables

quantité indication d'une quantité attachée à un montant : nombre d'unités pour une acquisition d'immobilisation, etc.

unité quantité identification de l'unité utilisée : km, kg, quantité de devises, litre, etc.

libellé d'un abonnement identification du libellé des informations permettant l'abonnement de char-ges ou de produits.

date de début d'abonnement identification de la date de début de période permettant l'abonnement de charges ou de produits.

date de fin d'abonnement identification de la date de fin de période permettant l'abonnement de char-ges ou de produits.

nombre de répétitions d'abon-nement

identification du nombre total de répétitions périodiques permettant l'abon-nement de charges ou de produits.

nombre de répétitions restant à servir

identification du nombre de répétitions périodiques restant à servir permet-tant l'abonnement de charges ou de produits.

périodicité d'abonnement identification de la périodicité (jour, semaine, mois, trimestre, etc.) liée au nombre de répétitions d'abonnement ou restant à servir.

catégorie de travail réalisé identification d'une catégorie de travail, d'une phase de travail ou d'une fonction attachée à la ligne comptable.

clé de répartition identification par un code de renvoi à une table de clés de répartition analy-tique, budgétaire, de ventilation, etc.

Informations concernant les immobilisations durée de vie économique de l'amortissement à pratiquer

identification de la durée économique de l'amortissement à pratiquer telle que prévue par la législation nationale.

unité de mesure durée de vie économique

identification de l'unité de mesure appliquée à la durée économique de l'amortissement à pratiquer.

base d'amortissement à prati-quer en monnaie de tenue de compte

identification de la base du calcul de l'amortissement à prendre en considé-ration en monnaie de tenue de compte, lorsque le montant à amortir diffère du montant d'acquisition dans cette même monnaie.

code devise de la base d'amor-tissement à pratiquer

identification de la monnaie liée à la base d'amortissement à pratiquer en monnaie de tenue de compte.

valeur résiduelle de bien à amortir

identification de la valeur résiduelle non amortissable (valeur de revente par exemple) du bien à amortir.

code devise de la valeur rési-duelle de bien à amortir identification de la monnaie liée à la valeur résiduelle du bien à amortir.

date de début d'amortissement à pratiquer

identification de la date à partir de laquelle commence effectivement l'amor-tissement du bien acquis.

Coût de destruction à la fin de durée de vie

identification du coût de la destruction du bien à amortir en fin de période de vie.

code devise du coût de destruc-tion du bien à amortir identification de la monnaie liée au coût de destruction du bien à amortir.

Coût de l'entretien annuel identification du coût de l'entretien annuel prévisionnel du bien à amortir. Code devise du coût de l'entre-tien annuel identification de la monnaie liée au coût d'entretien annuel.

Volume de production annuel identification du volume de production annuel relatif à l'utilisation du bien à amortir.

Nombre d'heures de travail annuel

identification du nombre d'heures de travail annuel utilisé pour certaines formules de calcul d'amortissement.

Ce jeton s'enrichit au fur et à mesure de son traitement dans le système d'information comptable pour devenir progressivement une écriture comptable complète.


3.14 Le plan de comptes de l'entité

On entend par plan de comptes, une liste méthodique des comptes suffisamment détail-lée pour permettre l'enregistrement des opérations affectant le patrimoine de l'entité. Le plan de comptes peut être soit conforme à des normes comptables sectorielles, nationales ou internationales, soit propre à l'entité qui l'utilise. Il fait partie de la documentation comptable.

Ce message permet d'envoyer plusieurs types de plans de comptes :

• plan de comptes généraux identifiant le type de plan de comptes généraux ;

• plan de comptes auxiliaires identifiant le type de plan de comptes divisionnaires (ou auxiliaires) ;

• plan de comptes analytiques identifiant le type de plan de comptes analytiques ;

• plan de comptes budgétaires identifiant le type de plan de comptes budgétaires ;

• etc.

Chaque compte du plan de comptes contient les informations suivantes :

Identification du plan ce comptes plan de comptes de référence identification de la référence au plan de comptes type de la CNC duquel est

tiré le plan de comptes utilisé par l'entité.

monnaie du compte identification de la monnaie habituellement utilisée par ce compte.

catégorie de plan de comptes Identification de la catégorie de plan de comptes.

Identification du compte

numéro de compte

identification du ou des numéro(s) de comptes du ou des plans des comp-tes utilisé(s) par l'entité : n° compte général, auxiliaire, analytique, budgé-taire ou de ventilation, etc. Généralement, le compte est identifié par un nom complet et/ou abrégé, une monnaie de base et une référence à la catégorie de plans de comptes.

qualité du compte identification de la qualité du compte pour indiquer s'il est principal ou se-condaire (auxiliaire).

nom complet du compte identification du nom complet du compte.

nom abrégé du compte identification du nom abrégé sur 20 caractères du compte.

date ouverture du compte identification de la date d'ouverture du compte.

date fermeture du compte identification de la date de fermeture du compte.

département à l'origine de la création du compte

identification de la personne, du service ou du département à l'origine de la création du compte.

département à l'origine de la fermeture du compte

identification de la personne, du service ou du département à l'origine de la fermeture du compte.

département à l'origine du dernier mouvement débit du compte

identification de la personne, du service ou du département à l'origine du dernier mouvement débit du compte.

département à l'origine du dernier mouvement crédit du compte

identification de la personne, du service ou du département à l'origine du dernier mouvement crédit du compte.

date dernier mouvement débit du compte identification de la date de dernier mouvement débit du compte.

date dernier mouvement crédit du compte identification de la date de dernier mouvement crédit du compte.


référence NGCSF identification des références de paramétrage pour obtenir une information agrégée NGCSF.

référence fiscale identification des références de paramétrage pour obtenir une information agrégée fiscale.

référence IAS / IFRS identification des références de paramétrage pour obtenir une information agrégée IAS / IFRS.

taux de TVA lié au compte identification du taux de TVA lié habituellement au compte.

Informations diverses Institutions financières Identification des institutions financières liées à ce compte.

Moyens de paiement Identification des moyens de paiement liés habituellement à ce compte.

Comptable attaché au compte Identification du nom du comptable attaché habituellement à ce compte. Mode de communication du comptable

identification du mode de communication du comptable attaché habituelle-ment à ce compte.

n° d'appel du comptable identification du n° d'appel du comptable attaché habituellement à ce compte.

3.15 Le journal comptable Le journal comptable est un document qui constate en informatique l'entrée des écritures en comptabilité. Bien que le classement par nature des écritures devienne de moins en moins utile puisque les logiciels comptables se chargent de leur classement automatique-ment, chaque entité continue à utiliser des familles de journaux pour distinguer les achats des ventes, de la trésorerie, etc. et, à l'intérieur de chaque famille, pour distinguer une catégorie d'une autre comme par exemple les achats des véhicules neufs et ceux d'occa-sion.

Chaque journal contient les informations suivantes :

journal comptable d'origine identification du document comptable dans lequel sont enregistrées les écritures comptables.

nom du journal comptable d'origine

identification du document comptable dans lequel sont enregistrées les écritures comptables.

catégorie de journal comptable identification d'une catégorie de journal : achat, vente, trésorerie, opération diverse, etc.

dernière période clôturée du journal

identification de la dernière période du journal ayant fait l'objet d'une clôture période ou annuelle.

date de clôture de la dernière période clôturée du journal

identification de la date à laquelle la dernière période clôturée du journal a été faite.

responsable de la dernière clôture du journal

identification de la personne et/ou du service ayant procédé à la dernière clôture du journal.

3.16 Les caractéristiques d'identification du transport des documents comptables Chaque document/message doit être préalablement identifié afin d'assurer un chemine-ment correct de l'expéditeur au destinataire.

Après avoir spécifié les renseignements suivants :

• type de syntaxe utilisé (table UNOA, B, C, etc. pour EDIFACT, le n° de version pour XML),

• identification de l'émetteur et des récepteurs,


• référence de contrôle entre émetteur/récepteur (incrémentation attachée à chaque couple émetteur/récepteur dans un but de contrôle),

• éventuellement rappel de la référence du destinataire ou son mot de passe,

• référence de l'application utilisée,

• code priorité pour le traitement du document/message,

• demande d'un accusé de réception,

• identification du contrat d'échange,

• indicateur d'essai,

le document/message doit distinguer les documents-types différents en faisant mention du type de document, de son numéro de version et de son numéro de révision, puis plus spé-cifiquement attaché au dossier transmis :

• la date de préparation manuelle du document/message,

• Nom et adresse de l'émetteur, du récepteur et du dossier comptable ainsi que son identification numérique nationale lorsqu'elle existe,

• Références du dossier de l'émetteur et du receveur,

• Numéro de la demande de documents/messages.

Pour le transport des documents et l'identification des destinataires, il est seulement fait référence ici aux généralités des spécifications MIME ou SOAP auxquelles on se réfèrera.


3.2 La nomenclature des données Comme il a été exposé au chapitre 2.12 – Liens avec les bases de données de l'entité, l'application informatique qui a la lourde tâche de collecter les informations détaillées, de les agréger soit pour des besoins internes (statistiques) soit pour des besoins externes, compte tenu de la variété des informations à fournir aux destinataires, compte tenu de la complexité à maintenir une base de donnée à jour du fait de la modification constante des paramètres de regroupement et d'agrégation, il est apparu nécessaire rapidement d'isoler des applications informatiques en amont et en aval, la nomenclature utilisée par ladite application informatique afin de conserver toute la souplesse possible. Ainsi :

• il est toujours possible à un émetteur en amont ou à un récepteur en aval d'une infor-mation de modifier ses paramètres sans interférer sur ceux de l'application qui va la recevoir à la réserve suivante que le résultat obtenu de l'information reste identique à la précédente, sinon il faut lui affecter une autre identification ;

• il est toujours possible à l'application informatique de modifier son système de codifi-cation sans avoir de compte à rendre aux émetteurs et aux receveurs.

nomenclatures données

Modificationsde l'émetteur

Modificationsdu récepteur

Mise à jour dela nomenclature

Donnéescodées

Données"brutes"

Donnéesenr ichies

Archivage

Traitementsantér ieurs

Traitementsà effectuer

La gestion des nomenclatures doit être détachée de celle des données.

Cette ouverture permet une adaptation rapide des paramètres sans avoir obligatoirement des contraintes à observer. Ainsi, en France, le système retenu a permis de faire face à sept années de modifications dues aux lois de finances sans avoir à modifier ni les docu-ments/messages, ni la base de données, et à l'introduction de nouveaux destinataires lé-gaux ayant leur propre système de codification.

La codification retenue et attachée à l'application informatique suit un modèle strict desti-né à juguler tout écart dans le temps et dans l'espace.

3.21 Exemple d'application française de traitement des informations de l'entité Les données comptables, fiscales, sociales, économiques et financières demandées par les partenaires économiques de l'entité ont fait l'objet d'un classement idéologique afin de


faciliter la recherche sur plusieurs milliers d'informations différentes, ces informations pouvant être des montants, des quantités, des textes, des pourcentages, etc.

Pour ce faire, un système de codification à 15 caractères alphanumériques a été retenu pour établir la liste des informations n° 01 (base Nouveau plan comptable national 1999) destinées à alimenter le document/message d'informations financières pour la communi-cation des informations déclaratives à différents destinataires publics ou privés a été éla-boré comme suit :

N AA A AAA NN A NN AAA Système de codification N Type d'informations (voir table) AA Catégorie d'informations (voir table) A Niveau d'informations (voir table) AAA Identification par ordre alphanumérique des entités ou

filiales (voir commentaire) NN Identification par ordre numérique des informations

composites (voir table) A Statut de l'information (voir table) NN Identification par ordre numérique des informations

"élémentaires" (voir table) AAA Détail unitaire des informations élémentaires (voir

commentaire)

Les tables utilisées pour la codification des informations élémentaires se présentent comme suit :

TTyyppee dd’’iinnffoorrmmaattiioonnss

Codifié sur 1 caractère numérique : • 0 = Informations comptables • 1 à 9 = Informations statistiques

CCaattééggoorriiee dd’’iinnffoorrmmaattiioonnss

Codifiée sur 2 caractères alphabétiques : • CA Capital • EC Ecarts de conversion • EM Emprunts • EN Engagements • FI Comptes financiers • IA Avances acomptes immobilisations • IC Immobilisations concédées • IE Immobilisations en cours • IM Immobilisations • PR Provisions pour Risques et Charges • PV Plus-values • RE Réserves • RR Résultat période - Report à nouveau • ST Stocks • SU Subventions • TI Tiers • WA Activités


• WC Détail des comptes • WE Entités apporteuses ou bénéficiaires d’apports • WI Détail des éléments cédés

NNiivveeaauu dd’’iinnffoorrmmaattiioonn

Codifié sur 1 caractère alphanumérique : • C Consolidation • E Filiale Etrangère • F Filiale France • L Entité liée • N Entité non liée • P Entité

IIddeennttiiffiiccaattiioonn ppaarr oorrddrree aallpphhaannuumméérriiqquuee ddeess eennttrreepprriisseess oouu ffiilliiaalleess

Codifiée sur 3 caractères alphanumériques : • 000 L’information donnée ne comporte pas de détail de niveau inférieur (cas

le plus courant) • ZZZ L’information donnée est un cumul des détails de niveau inférieur

SSttaattuutt ddee ll’’iinnffoorrmmaattiioonn

Codifié sur 1 caractère alphanumérique : • A Valeur des amortissements • B Valeur Crédit-bail • C Valeur des cessions ou apports • D Valeurs diverses • E Valeur des provisions spéciales de réévaluation • F Valeur des opérations fiscales sur amortissements • G Résultat Produits • H Nombre d’heures • I Valeur des immobilisations • L Libellés • N Valeur nominale • P Valeur des provisions • Q Quantité • R Résultat Charges • S Nombre de salariés • V Valeurs monétaires

DDééttaaiill uunniittaaiirree ddeess iinnffoorrmmaattiioonnss éélléémmeennttaaiirreess

Codifié sur 3 caractères alphanumériques : • 000 L’information donnée ne comporte pas de détail unitaire (cas le plus courant) • ZZZ L’information donnée est un cumul des détails unitaires


IIddeennttiiffiiccaattiioonn ppaarr oorrddrree nnuumméérriiqquuee ddeess iinnffoorrmmaattiioonnss ““ccoommppoossiitteess””

Codifiée sur 2 caractères numériques. Voir ci-après exemple développé sur les comptes de capitaux.

IIddeennttiiffiiccaattiioonn ppaarr oorrddrree nnuumméérriiqquuee ddeess iinnffoorrmmaattiioonnss ““éélléémmeennttaaiirreess””

Codifiée sur 2 caractères numériques. Voir ci-après exemple développé sur les comptes de capitaux.

EExxeemmpplleess dd’’aapppplliiccaattiioonn

Amortissements antérieurs réévalués du matériel de bureau, mobilier et informatique 0 IM P 000 35 A 01 000

Amortissements non pratiqués en comptabilité et correspondant à la déduction fiscale pour investissement, définie par les lois de 1966, 1968 et 1975 effectivement utilisée

0 IM P 000 00 F 37 000

Dividendes encaissés au cours de l’exercice (par filiale ou participation) concernant la filiale 102

0 TI E 102 17 D 11 000

Actions acquises au cours de la période (pour la 58e opération de la filiale 218) 0 CA C 218 01 Q 31 058

AApppplliiccaattiioonn ssuurr lleess ccoommpptteess ddee ccaappiittaauuxx 0 Informations comptables CA CAPITAL A Niveau d’informations (voir table) AAA Identification par ordre alphanumérique des entités ou filiales (de 000 à ZZZ) 01 Capital social ou individuel versé 02 Capital social appelé non versé 03 Capital social non appelé V Valeurs 01 Début de période 02 Souscription en numéraire 03 Apports reçus par société bénéficiaire 04 Incorporation de réserves 05 Incorporation report à nouveau 06 Incorporation résultat 67 Remboursement ou amortissement 99 Fin de période D Valeurs diverses 01 Prime d'émission de la période 02 Apports fournis par société qui apporte 03 Capital appelé dans la période 04 Capital appelé et versé dans la période Q Quantités 31 Nombre de créations au cours de la période, actions

ordinaires


32 Nombre de créations au cours de la période, actions amorties

33 Nombre de créations au cours de la période, actions à dividende prioritaire sans droit de vote

34 Nombre de créations au cours de la période, actions préférentielles

35 Nombre de créations au cours de la période, parts sociales

36 Nombre de créations au cours de la période, certifi-cats d'investissement

61 Nombre de remboursement au cours de la période, actions ordinaires

62 Nombre de remboursement au cours de la période, actions amorties

63 Nombre de remboursement au cours de la période, actions à dividende prioritaire sans droit de vote

64 Nombre de remboursement au cours de la période, actions préférentielles

65 Nombre de remboursement au cours de la période, parts sociales

66 Nombre de remboursement au cours de la période, certificats d'investissement

91 Nombre à la clôture de la période, actions ordinaires 92 Nombre à la clôture de la période, actions amorties 93 Nombre à la clôture de la période, actions à divi-

dende prioritaire sans droit de vote 94 Nombre à la clôture de la période, actions préféren-

tielles 95 Nombre à la clôture de la période, parts sociales 96 Nombre à la clôture de la période, certificats d'inves-

tissement N Valeur nominale 91 Actions ordinaires 92 Actions amorties 93 Actions à dividende prioritaire sans droit de vote 94 Actions préférentielles 95 Parts sociales 96 Certificats d'investissements AAA Détail unitaire des informations élémentaires (de

000 à ZZZ)

Bien entendu, ce sont ces codes qui sont repris dans les documents/messages.

EExxeemmppllee dd''aapppplliiccaattiioonn ddee rreennsseeiiggnneemmeennttss aappppoorrttééss àà uunnee ddoonnnnééee

Ci-après figurent deux exemples de données figurant dans une base appelée NGCSF5 en France.

Fiche de donnée Le 10/08/00 Page 1

5 NGCSF : Nomenclature Générale Comptable Sociale et Fiscale.


Référence N.G.C.S.F. 0ACP000ZZP99000

Libellé court Amort. Prov.

Nom de la donnée Amortissements et provisions

Créée le 10/02/94

Mise à jour le 21/11/96 DESCRIPTION Définition L'amortissement pour dépréciation se traduit par l'amoindrissement irré-

versible de la valeur des immobilisations. Détails Comptes comptables 39 / 49 / 59 ORIGINE Type Loi Détails Code de commerce Plan comptable général 1999 Code général des impôts TYPE DE L'INFORMATION Structure Elément Nature Numérique – Monétaire Périodicité Annuelle DOCUMENTS CONCERNES 01BQ2033A dans 2033-A zone BQ Segment MOA 01CK2050 dans 2050 zone CK Segment MOA 01CM2144 dans 2144N zone CM Segment MOA 01CKCA dans CABI zone CK Segment MOA 0 ------------------------> Informations Comptables AC --------------------> Actif circulant P ------------------> Entité 000 -------------> L'entité elle-même ZZ ----------> Totalisation P --------> Valeurs des provisions 99 -----> Fin de la période 000 > Détails éventuels

Fiche de donnée Le 10/08/00 Page 1

Référence N.G.C.S.F. 0CAP00002D30000

Libellé court Cap app non v lié

Nom de la donnée Capital souscrit appelé non versé par les entités liées

Créée le 10/02/94

Mise à jour le 28/11/96 DESCRIPTION Définition Le capital souscrit appelé n'est pas encore versé par les entités du

groupe. Détails Comptes comptables 101 ORIGINE Type Loi Détails Code de commerce Plan comptable général 1999 TYPE DE L'INFORMATION


Structure Elément Nature Numérique – Monétaire Périodicité Annuelle DOCUMENTS CONCERNES 01AICA10 dans CA10 zone AI Segment MOA 0 ------------------------> Informations Comptables CA --------------------> Capital P ------------------> Entité 000 -------------> L'entité elle-même 02 ----------> Capital social appelé non versé D --------> Valeurs diverses 30 -----> Entités liées 000 > Détails éventuels


3.3 Les plans de regroupement L'objectif recherché par les plans de regroupement est de permettre la transmission, entre une société de services et ses clients dans un but de maintenance, entre deux partenaires intéressés dans l’utilisation de documents communs, un plan de regroupement d’unité de comptes comptables élémentaires (général, auxiliaire, analytique, budgétaire, etc.) per-mettant d’obtenir des informations agrégées. Ce document/message peut être utilisé pour effectuer :

• soit des déclarations obligatoires du type fiscal, social, statistique, etc.,

• soit des formalités contractuelles ou conventionnelles du type reporting, consolida-tion, etc.,

• soit des transmissions de description d’Etats pour faciliter une lecture ultérieure.

Le terme plan de regroupement est un document comptable qui consiste à mentionner la relation à effectuer entre des informations reçues, stockées et des informations à fournir. Il peut y avoir plusieurs types de plans de regroupement :

• entre un plan général de regroupement présentant tous les comptes d'un grand livre et leur affectation dans un compte d'une balance générale,

• entre un plan de regroupement issu de la balance de vérification et les comptes an-nuels, ou le reporting mensuel, ou les déclarations fiscales, ou les statistiques annuel-les,

• entre un plan de regroupement issu de la balance de vérification et l'affichage à l'écran sur un site Web,

• etc.

Le document/message qui véhicule le plan de regroupement doit mentionner les informa-tions suivantes : .

Identification de l'état agrégé Code de l'état agrégé identification du code de l'état agrégé pour lequel un plan de regroupement

est requis.

Nom de l'Etat agrégé identification du nom de l'état agrégé pour lequel un plan de regroupemet est requis.

Identification source de l'information à agréger

numéro de compte


Dates de mise à jour et/ou d’application de l’information

identification des dates critiques de la dernière date de mise à jour de la donnée et de la date à partir de laquelle elle peut être prise en compte.

Description, Note, Références légales et Synonymes de l’information

identification de quelques renseignements qui permettent d'apprécier la quali-té de la donnée.



signe du montant






code devise du montant d'origine identification de la monnaie liée au montant d'origine.

Identification cible de l'information agrégée

numéro de l'information


Dates de mise à jour et/ou d’application de l’information

identification des dates critiques de la dernière date de mise à jour de la donnée et de la date à partir de laquelle elle peut être prise en compte.

Description, Note, Références légales et Synonymes de l’information

identification de quelques renseignements qui permettent d'apprécier la quali-té de la donnée.


signe du montant






Opérateurs mathématiques et booléens opérateurs mathématiques et booléens

identification des opérateurs mathématiques (+-x:√∆∑) ou booléens (AND OR NOT) permettant d'obtenir l'information agrégée demandée.

Période prise en compte identification de la période à prendre en compte dans l'information source.

Ce document permet d'automatiser les relations entre émetteur et receveur notamment sur la problématique des mises à jour des tables. Il permet de résoudre tous les types de do-cuments connus ou inconnus.


3.4 Le reporting financier et autres états assimilés Le reporting, qu'il soit financier, statistique, fiscal, social ou autre, requiert toujours une démarche à peu près identique :

• vérification de la mise à jour des tables et des bases pour la production ou la réception du reporting,

• sélection du type de reporting,

• traitement, vérification avant envoi, signature électronique éventuel, chiffrement éventuel du reporting (confidentialité),

• émission du reporting sélectionné,

• archivage du reporting émis,

• gestion des accusés de réception (vérification, relance, archivage),

• etc.

Un soin très particulier doit être apporté à la diffusion du reporting car, suivant les scéna-rii, les destinataires peuvent traiter le reporting de différentes façons :

• réception, contrôle (chiffrement, signature), accusé de réception et archivage pur et simple du reporting (GEIDE),

• réception, contrôle (chiffrement, signature), accusé de réception, archivage, traite-ment dans des chaînes d'applications spécifiques, etc.,

• réception, contrôle (chiffrement, signature), accusé de réception, archivage, affichage sur écran pour mise à disposition du public, etc.,

• réception, contrôle (chiffrement, signature), accusé de réception, archivage, routage vers d'autres destinataires, etc.,

• etc.

De ce fait, il est très important de désynchroniser le reporting de l'utilisation qui en sera faite ultérieurement par le destinataire.

Par ailleurs, le reporting informatisé n'est pas lu directement par un utilisateur : c'est tou-jours une traduction fournie par le système informatique qui lui permet de prendre connaissance en clair du document/message qui lui a été envoyé. Il n'est donc pas néces-saire d'étiqueter les informations en clair dans le document/message mais, au contraire, il faut plutôt utiliser des tables de codes afin d'émettre (ou de recevoir) des fichiers plus légers. En outre, ces tables de codes évitent le problème de la langue utilisée.

Ainsi, pour satisfaire les besoins des émetteurs utilisateurs, des informaticiens qui produi-sent les applications informatiques, des récepteurs utilisateurs, des auditeurs, etc., il est nécessaire d'avoir recours à un document/message passe-partout pour émettre à travers le monde, les milliers et milliers de documents qui sont produits aujourd'hui.

L'informatique permet de trouver la solution idoine, car en se débarrassant du support papier, elle n'a plus qu'à transmettre les données proprement dites. Ce concept testé dans plusieurs pays d'Europe depuis plusieurs années repose sur les notions exposées précé-demment, savoir :


• utilisation de tables de codes de données (définies conjointement entre émetteurs et récepteurs) : les tables sont prévues pour être traduites en plusieurs langues (anglais, espagnol, allemand, etc.),

• utilisation d'un document/message unique quel que soit le reporting à transmettre,

• émetteurs et récepteurs ne sont pas liés dans leurs propres applications informatiques par les tables uniques de codes de données puisque les uns comme les autres utilisent des tables d'équivalence,

• intégration de nouveaux documents par mise à jour des tables de codes de données seulement,

• contrôle des tables et du document/message par une instance internationale secto-rielle,

• dans le cas XML, utilisation éventuelle par le destinataire du schéma de présentation de l'émetteur.

3.41 L'information comptable et financière Ainsi, on peut dire qu'une information de la comptabilité d’une entité est un renseigne-ment ou un événement porté à la connaissance d’une personne publique ou privée ou d’un organisme public précisant une référence, une date, une heure, une période, un texte d'ob-servations ou commentaires, un nom, une adresse, une quantité, une caractéristique comp-table et administrative, un pourcentage, un statut légal d'entité ou un montant en vertu des relations commerciales, financières, comptables, légales, sociales ou fiscales ou en vertu de dispositions ou réglementations législatives nationales ou régionales.

Une entité émet un document/message selon un index prédéfini. A chaque valeur de l’index correspond une information répertoriée dans les tables.

Chaque information comptable peut contenir les renseignements suivants (cette liste n'est pas exhaustive) :

séquencement de l'infor-mation

identification du numéro séquentiel de l'information agrégée figurant dans l'état.

index de la nomenclature identification du numéro de l'information agrégée pris dans une nomenclature fournie par l'une des parties à l'échange.

information - référence identification d'une référence relative à l'information demandée.

information –montant identification d'un montant relatif à l'information demandée.

information – texte identification d'un texte relatif à l'information demandée.

information – date identification d'une date relative à l'information demandée.

information – quantité identification d'une quantité relative à l'information demandée.

information – devise identification d'une devise relative à l'information demandée.

information – pourcentage identification d'un pourcentage relatif à l'information demandée.

information – compte comptable

identification d'un compte comptable relatif à l'information demandée.

information – contact identification d'un contact relatif à l'information demandée.

information – caractéristi-ques

identification d'une caractéristique comptable, financière, fiscale, statistique, sociale, etc. relative à l'information demandée.


etc.

SSééqquueenncceemmeenntt ddee ll''iinnffoorrmmaattiioonn

L'information à télétransmettre peut être "simple" ou "composite" c'est-à-dire composée de plusieurs données différentes comme par exemple un texte associé à deux montants dont l'ensemble forme un tout homogène.

Dans le cas d'une information simple, un seul renseignement étant requis, l'index renvoie directement à la nomenclature pour connaître sa définition.

Exemple : l'index 0IMP00035A01000 renvoie à l'identification de l'information agrégée suivante : Amortissements antérieurs réévalués du matériel de bureau, mo-bilier et informatique.

Si le document/message comporte un tableau comprenant tout ou partie des informations composites, la séquence comprendra plusieurs informations différentes.

Exemple :

index 0CAC00078L11000 (Libellé demandé pour l'apport d'Alain),

index 0CAC00078N11000 (Valeur demandé pour l'apport d'Alain),

index 0CAC00078L11000 (Libellé demandé pour l'apport de Bertrand),

index 0CAC00078N11000 (Valeur demandé pour l'apport de Bertrand),

index 0CAC00078L11000 (Libellé demandé pour l'apport de Claude),

index 0CAC00078N11000 (Valeur demandé pour l'apport de Claude),

etc.

IInnddeexx ddee llaa nnoommeennccllaattuurree

L'indication de l'index de la nomenclature dont le code est signalé dans l'en-tête du docu-ment/message permet de qualifier une information agrégée.

3.42 Définition de l'en-tête du message L'en-tête du document/message, plus que les autres étudiés ci-dessus, doit être particuliè-rement soigné parce qu'il peut faire l'objet de nombreux routages.

Il doit mentionner successivement :

• la date de préparation manuelle du document/message,

• les dates de la période comptable couverte par le reporting,

• les références du logiciel comptable utilisé (nom du logiciel, nom de l'auteur du logi-ciel, n° de version du logiciel à l'origine du document/message),

• les devises liées au document/message : monnaie de tenue du dossier (principale et pivot), monnaie d'expression, taux de conversion, etc.


• Nom et adresse de l'émetteur, des récepteurs et du dossier comptable ainsi que les identifications numériques nationales lorsqu'elles existent,

• Nom et adresse de facturation des prestations servies par le provider,

• Références du dossier de l'émetteur et du receveur,

• Numéro de la demande de documents/messages,

• Nom et adresse de la personne à contacter en qualifiant le contact (comptable, audi-teur, directeur commercial, etc.),

• Identification du moyen de communication (téléphone, télécopie, courrier électroni-que, X400, etc.) et le numéro d'appel,

• Numéro de la liste d'index attachée au document/message et le numéro de version correspondant,

• Monnaie utilisée pour l'ensemble du document/message.

Pour le transport des documents et l'identification des destinataires, il est seulement fait référence aux spécifications générales de MIME ou SOAP auxquelles on se réfèrera.


444... EEEXXXEEEMMMPPPLLLEEE DDD'''UUUTTTIIILLLIIISSSAAATTTIIIOOONNN EEEDDDIIIFFFAAACCCTTT Modèle INFENT étudié et exploité par l'association EDIFICAS (extraits). UNA:+,? ' UNB+UNOC:3+32788110000103:5:TXXXXXXXX+Code_conf_emetteur+000809:1700+00080917001900+++++CAB-PED0100' UNG+INFENT+NON_SECURISE_NON_SIGNE+EDI_TDFC+000809:1700+1+UN+D:97B:FD0101' UNH+00001+INFENT:D:97B:UN:FD0101' BGM+IDF:71:211' DTM+242:20000809:102' RFF+ZZ2:CEGID' RFF+ZZ3:TDI:0:9.9A' RFF+ZZ4:AGREMENT' NAD+DT+31950367800041:100:107++SA PHOSYN:BP 6+58 BIS RUE GAMBET-TA+FLEURANCE++32500' NAD+FR+32788110000103:100:107++CEC_EDI_TDFC:SA SOFIREN+156 Bd des Brotteaux+LYON++69006+FR' NAD+MS+32788110000103:100:107++SA SOFIREN:::::ZZ1+156 Bd des Brot-teaux+LYON++69006+FR' RFF+ACD:00582' NAD+MR+6900502:100:ZZ1++Relais Cegid Test+123, Avenue Barthélémy Buyer+LYON++69005' NAD+HP+++DGI_EDI_TDFC:CRI DE NEVERS::::ZZ1+test pour EDI TDFC+NEVERS' RFF+ZZ1:420050130556977' CCI+++TAR:LIS:211' CAV+AR:TAR:211' SEQ++000001' IND++F-IDENTIF 0000000000CBDTM' DTM+ZZZ:19991231:102' SEQ++000002' IND++F-IDENTIF 0000000000CDDTM' DTM+ZZZ:20191231:102' SEQ++000003' IND++F-IDENTIF 0000000000CCDTM' DTM+ZZZ:12:802' SEQ++000004' IND++F-IDENTIF 0000000000CEDTM' DTM+ZZZ:12:802' SEQ++000005' IND++F-IDENTIF 0000000000BACCI' CCI+++TCF:LIS:211' CAV+BI:TCF:211' SEQ++000006' IND++F-IDENTIF 0000000000BBCCI' CCI+++TRF:LIS:211' CAV+RS:TRF:211' SEQ++000007' IND++F-IDENTIF 0000000000BECCI' CCI+++TAP:LIS:211' CAV+PDP:TAP:211' SEQ++000008' IND++F-IDENTIF 0000000000BFCCI' CCI+++TDP:LIS:211' CAV+NOR:TDP:211' SEQ++000009'


IND++F-IDENTIF 0000000000BCCCI' CCI+++TBS:LIS:211' CAV+IR:TBS:211' SEQ++000010' IND++F-IDENTIF 0000000000DACUX' CUX+2:FRF' SEQ++000011' IND++F-IDENTIF 0000000000AANAD' NAD+ZZZ+31950367800041:100:ZZZ++SA PHOSYN:BP 6+58 BIS RUE GAMBET-TA+FLEURANCE++32500' CTA+ZZZ+:Mr Pierre Dupré' COM+0176329645:TE' SEQ++000012' IND++F-IDENTIF 0000000000ABRFF' RFF+ZZZ:515L' SEQ++000013' IND++2033A 0000000000AAMOA' MOA+ZZZ:60000,00' SEQ++000014' IND++2033A 0000000000BAMOA' MOA+ZZZ:30000,00' ... SEQ++000160' IND++2033C 0000000001KAFTX' FTX+ZZZ+++Presse hydraulique' SEQ++000161' IND++2033C 0000000002LAMOA' MOA+ZZZ:89000,00' ... SEQ++000165' IND++2033C 0000000002KAFTX' FTX+ZZZ+++Fourgonnette' SEQ++000166' IND++2033D 0000000000AEMOA' MOA+ZZZ:18948,00' ... SEQ++000171' IND++2033D 0000000000DHMOA' MOA+ZZZ:10685,20' SEQ++000172' IND++CA17PROREC0000000001ABMOA' MOA+ZZZ:30396,00' SEQ++000173' IND++CA17PROREC0000000001AAFTX' FTX+ZZZ+++Clients fact a etabl' SEQ++000174' IND++CA17PROREC0000000002ABMOA' MOA+ZZZ:16166,00' ... SEQ++000178' IND++CA18CHAPAY0000000001ABMOA' MOA+ZZZ:109,00' SEQ++000179' IND++CA18CHAPAY0000000001AAFTX' FTX+ZZZ+++Banques interets courus' ... SEQ++000199' IND++CA19CHAREP0000000001AAFTX' FTX+ZZZ+++Frais d?'augmentation capital' ... SEQ++000201'


IND++CA20CHAAVA0000000001ACMOA' MOA+ZZZ:33268,00' ... SEQ++000203' IND++CA20CHAAVA0000000001AAFTX' FTX+ZZZ+++CHARGES CONSTAT.D?'AVANCE' SEQ++000204' IND++ANNEXLIB010000000001 AFTX' FTX+ZZZ+++Commentaire.....' SEQ++000205' IND++ANNEXLIB010000000002 AFTX' FTX+ZZZ+++Commentaire......' SEQ++000206' IND++2031 0000000000ABFTX' FTX+ZZZ+++PRODUITS PHYTOSANITAIRES' SEQ++000207' IND++2031 0000000000CAMOA' MOA+ZZZ:636461,19' ... SEQ++000211' IND++2031 0000000000BMNAD' NAD+ZZZ+++PHOSYN+45BAllée des Alouettes+Firminy++42100' CTA+ZZZ+:M Duchemol' COM+0230343536:TE' SEQ++000212' IND++2031 0000000000DCNAD' NAD+ZZZ+++M Dumond+12True des bastides+Annecy++74000' CTA+ZZZ+:...' COM+0474983318:TE' ... SEQ++000231' IND++2067 0000000000PDMOA' MOA+ZZZ:0,00:::ZZ1' SEQ++000232' IND++ATTESTATAA0000000000AANAD' SEQ++000233' IND++ATTESTATAA0000000000EANAD' NAD+ZZZ+101670:100:ZZZ++ALSACE+11, Avenue de la Forêt Noire+Strasbourg Cedex++67084' CTA+ZZZ+:Mme Braun' COM+0388456020:TE' ... SEQ++000241' IND++ATTESTATAA0000000000DBCCI' CCI+++TON:LIS:211' CAV+OUI:TON:211' UNT+759+00001' UNE+1+1'

UNZ+1+00080917001900'


555... EEEXXXEEEMMMPPPLLLEEE DDD'''UUUTTTIIILLLIIISSSAAATTTIIIOOONNN XXXMMMLLL Modèle DTD étudié par l'association EDIFICAS <?xml version="1.3" encoding="UTF-8"?>   <xs:schema targetNamespace="http://www.edificas.org/namespace" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.edificas.org/namespace" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.15"> <xs:include schemaLocation="EDIFICAS_ComplexType.xsd"/> <xs:element name="ENTREPRISE_INFORMATION"> <xs:annotation> <xs:documentation>Root element</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Routing"> <xs:annotation> <xs:documentation>Group of elements defining message routing process to identify interchange partners; Note: some or all elements could be managed by protocol (e.g. SOAP) For this reason, perhaps a part of this set of data are not considered.</xs:documentation> <xs:documentation>Group of elements defining routing process (some of all elements could be managed by protocol (e.g. SOAP)</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="RelatedParty" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>An information to provide party related to exchange message. e.g. Sender, Recipient, Router, Entity, Sub Entity, Collection Center, Represen tative Sender, Invocing, Service Operator, etc.</xs:documentation> <xs:documentation>Group of elements defining routing process (some of all elements could be managed by protocol (e.g. SOAP)</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="IdentityId" type="IdentityId"/> <xs:element name="PartyQualifierId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>Code giving specific meaning to a party. e.g. MS = Issuer of a document and/or sender of a message.</xs:documentation> </xs:annotation>


</xs:element> <xs:element name="PartyReferenceId" type="ReferenceCodeType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Code identifying a reference attached to a party of an electronic exchange. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="BankingAccountCode" type="FinancialAccountHolderType" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="InformationFile"> <xs:annotation> <xs:documentation>Group of elements providing enterprise information details.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="EntityId"> <xs:annotation> <xs:documentation>An information identifying the type of enterprise information which is transmitted and provide its identification number. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="ReferenceId" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>To indicate references concerning the document. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:choice> <xs:element name="DocumentName" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>To identify: - the name of the document - each occurence of a document between partners.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TypeMessage"> <xs:complexType> <xs:sequence> <xs:element name="Code" type="ReferenceCodeType" minOccurs="2" maxOccurs="2"> <xs:annotation>


<xs:documentation source="http://unece.org/cefact/ ">To identify : - the message type - the control agency CodeListIdentification mandatory. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="MessageVersionNumber" type="xs:string"> <xs:annotation> <xs:documentation>e.g. UNCL 01.A element 1056 Version identifier</xs:documentation> </xs:annotation> </xs:element> <xs:element name="MessageRevisionNumber" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>To indicate the code of Software revision. e.g. UNCL 01.A element 1058 Release identifier or element 1060 Revision identifier </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Code" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation source="http://unece.org/cefact/ ">To indicate e.g. : - the number and the step of the used scenario, - the reference code of the previous message, - the internal reference sender - the social return type - etc. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DatePeriodId" type="DatePeriodType" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>To indicate e.g. the preparation date of the file, or the start and/or the end dates for an accounting period, the period to which social return is sent, etc.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TimeId" type="TimeType" minOccurs="0" maxOccurs="unbounded">


<xs:annotation> <xs:documentation>To indicate e.g. the preparation hour of the file, or the start and/or the end hours for an accounting period, the period to which so cial return is sent, etc.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ReceiptAcknowledgementId" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>To indicate the type of acknowledgements of receipt. e.g. UN-EDIFACT element 4343. 0 = no Acknowledgement of receipt 1 = Acknowledgement of receipt 2 = Paper Edition 3 = Acknowledgement of receipt and Paper Edition</xs:documentation> </xs:annotation> </xs:element> <xs:element name="UsedListId" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>An information identifying the number of the list of information or taxonomie that is transmitted and provide its identification number. e.g. UN-EDIFACT element 1153.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FileDescriptionId" type="FreeTextType" minOccurs="0"> <xs:annotation> <xs:documentation>Text for Enterprise Information File description.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FileSoftwareId" type="AccountingFileSoftwareIdType" minOccurs="0"> <xs:annotation> <xs:documentation>Is required for some e-filing to public authorities</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FeaturesId" type="CharacteristicType" minOccurs="0"> <xs:annotation> <xs:documentation>Is required to provide accounting, fiscal, social or legal characteristics of the enterprise information message.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="CurrencyId" minOccurs="0"> <xs:annotation> <xs:documentation>Currency that is used in this Enterprise Information file</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Detail" type="CurrencyDetailType" maxOccurs="2"> <xs:annotation> <xs:documentation>see ebXML CC 000136


Currency. Exchange. Details: Source. Currency. Code (000137) Target. Currency. Code (000138) Base. Currency. Code (000139) Currency Exchange. Rate (000120) Source Currency. Scale. Value (000140) Target Currency. Scale. Value (000141) Exchange. Rate. Date Time (000142) </xs:documentation> </xs:annotation> </xs:element> <xs:element name="RateValue" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>To specify the rate at which one specified currency is expressed in another specified currency. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ExchangeRateCurrencyMarketID" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>To identify an exchange rate currency market. e.g. UNCL 01.A element 6341 Exchange rate currency market identifier abstract: AAA Paris exchange CAN Toronto exchange FRA Frankfurt exchange LNF London exchange, first closing LNS London exchange, second closing NYC New York exchange ZUR Zurich exchange </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="EntityAndSubEntityId" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="SequenceNumber" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information identifying the number of the sequence of Sub Entity information which is transmitted and provide its identification number. e.g. P = Entity; S = Sub-entity</xs:documentation> </xs:annotation>


</xs:element> <xs:element name="ExpectedInformationId" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>A group providing the expected information related to the enterprise. The index value contained in the index determines how information in the subordinate segments in the same group, should be interpreted.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="SequenceId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information providing the sequential number of the provided information in the message. An information providing the sequential number to identify information with respect to its membership relation with elementary or com plex information.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="DeclarationOccurrenceId" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>An information to identify each declaration having the same ID by a sequential number.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IndexId"> <xs:annotation> <xs:documentation>An information to identify a relevant index.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="CodedId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information providing the value of index.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="NatureId" minOccurs="0"> <xs:annotation> <xs:documentation>An information providing the nature of below expected information.</xs:documentation> </xs:annotation> <xs:complexType> <xs:choice> <xs:element name="URICoreComponentValue" type="xs:string"> <xs:annotation> <xs:documentation>To indicate the address where to find the alternative structure of the core component corresponding to the value of each nature of below information. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Code" type="ReferenceCodeType">


<xs:annotation> <xs:documentation>To indicate the nature of below information, e.g.: ReferenceInformationId AmountInformationId FreeTextInformationId etc. </xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="RowValue" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>An information providing the row completing the information index to include the repetability of same information. </xs:documentation> </xs:annotation> </xs:element> <xs:choice> <xs:element name="ReferenceId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information to provide reference related to information specified in the index. e.g. Invoice number. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AmountId" type="MonetaryAmountType"> <xs:annotation> <xs:documentation>An information to provide amount related to information specified in the index. e.g. Asset. ebXML Amount Class: A number of monetary units specified in a currrency where the unit of currency is explicit or it may be implied. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="FreeTextId" type="FreeTextType"> <xs:annotation> <xs:documentation>An information to provide text related to information specified in the index. e.g. Explanation of provision.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="DatePeriodId" type="DatePeriodType"> <xs:annotation> <xs:documentation>An information to provide date or time or period related to information specified in the index.


e.g. Event date.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TimeId" type="TimeType"> <xs:annotation> <xs:documentation>An information to provide date or time or period related to information specified in the index. e.g. Event date.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="QuantityId" type="QuantityDetailsType"> <xs:annotation> <xs:documentation>An information to provide quantity related to information specified in the index. e.g. Staffing number. Quantity information in a transaction, qualified when relevant.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="CurrencyId" type="CurrencyDetailType"> <xs:annotation> <xs:documentation>An information to provide currency related to information specified in the index. e.g. EUR/USD exchange rate. see ebXML CC 000136 Currency. Exchange. Details: Source. Currency. Code (000137) Target. Currency. Code (000138) Base. Currency. Code (000139) Currency Exchange. Rate (000120) Source Currency. Scale. Value (000140) Target Currency. Scale. Value (000141) Exchange. Rate. Date Time (000142) </xs:documentation> </xs:annotation> </xs:element> <xs:element name="PercentageId" type="PercentageType"> <xs:annotation> <xs:documentation>An information to provide percentage related to information specified in the index. e.g. Interest rate.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="BankingAccountId" type="FinancialAccountHolderType"> <xs:annotation> <xs:documentation>An information to provide account holder related to information specified in the index. e.g. Bank account number.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="AccountingAccountId" type="AccountingAccountType">


<xs:annotation> <xs:documentation>An information to provide account related to information specified in the index. e.g. Provision Account Number.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IdentityId" type="IdentityId"> <xs:annotation> <xs:documentation>An information to provide party related to information specified in the index. e.g.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FeaturesId" type="CharacteristicType"> <xs:annotation> <xs:documentation>An information to provide accounting, fiscal, social or legal characteristics of the enterprise related to information specified in the index.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ObjectID" type="ObjectType"> <xs:annotation> <xs:documentation>An information to identify object (file) of the enterprise related to information specified in the index. </xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="PaymentFile" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Group of elements providing information on payment.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="SequenceId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information providing the sequential number of the provided information in the message. An information providing the sequential number to identify information with respect to its membership relation with elementary or complex information. </xs:documentation> </xs:annotation>


</xs:element> <xs:element name="DeclarationOccurrenceId" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>An information to identify each declaration having the same ID by a sequential number.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IndexId"> <xs:annotation> <xs:documentation>An information to identify a relevant index.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="CodedId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information providing the value of index.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="NatureId" minOccurs="0"> <xs:annotation> <xs:documentation>An information providing the nature of below expected information.</xs:documentation> </xs:annotation> <xs:complexType> <xs:choice> <xs:element name="URICoreComponentValue" type="xs:string"> <xs:annotation> <xs:documentation>To indicate the address where to find the alternative structure of the core component corresponding to the value of each nature of below information.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Code" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>To indicate the nature of below information, e.g.: ReferenceInformationId AmountInformationId FreeTextInformationId etc.</xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="RowValue" type="xs:string" minOccurs="0">


<xs:annotation> <xs:documentation>An information providing the row completing the information index to include the repetability of same information.</xs:documentation> </xs:annotation> </xs:element> <xs:choice> <xs:element name="DetailPayment"> <xs:annotation> <xs:documentation>To indicate terms of payment.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0"> <xs:element name="FinancialInstitution"> <xs:annotation> <xs:documentation>see ebXML 000010 Financial Account. Details Financial Account. Identifier (000077) Financial Account. Name (000078) Financial Account. Country. Code (000080) Financial Account. Currency. Code (000081) Financial Account Product. Type. Identifier (000084) Financial Account Nickname. Name (000085) group elements 3194+3433 required for automated processing at banks alternative: group 3432+3434+3207 Both groups better; Otherwise automated process impossible What about INP+GIS Balance of payments ?</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="AccountHolderId" type="FinancialAccountHolderType"/> <xs:element name="FinancialInstitutionId" type="FinancialInstitutionIdType" minOccurs="0"/> <xs:element name="Country" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>To indicate e.g. FRANCE or e.g.CA, DE, IE, FR, IT, NO, US, etc. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="PartyFunctionCode" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>e.g. UNCL 01.A element 3035 Party function code qualifier abstract: .../... AO Account of AP Accepting party AQ Approved consignor AR Authorized exporter


AS Account servicing financial institution AZ Issuing bank B1 Contact bank 1 B2 Contact bank 2 BA Booking agent BB Buyer's bank BC Negotiating bank BD Documentary credit reimbursing bank BE Beneficiary BF Beneficiary's bank .../...</xs:documentation> </xs:annotation> </xs:element> <xs:element name="CommunicationId" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>see ebXML core components catalogue for (000050) Communication Number. Details Communication. Type. Code (000052) Communictation. Mode. Code (000053) Communication. Identifier (000055) Telephone. Country. Identifier (000057) Telephone area. Identifier (000058) Telephone Subscriber. Identifier (000059) Telephone Extension. Identifier (000060) Communication number of a department or a person to whom communication should be directed: SITA, ARINC, ATI mailbox, US Defense Switched Network, WWW, Telefax, Telex, X400, Pager, GEIS, etc. ebXML Code Class: A character string that represents a member of a set of values e.g. uncl.01A element 3155 Communication Address Code Qualifyer abstract: AF U.S. Defense Switched Network, AG U.S. federal telecommunications system, AH World Wide Web, EI EDI transmission, EM Electronic mail, FT File transfer access method, FX Telefax, SW S.W.I.F.T. etc.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Value" type="xs:string"/> <xs:element name="Code" type="ReferenceCodeType" minOccurs="0"/> </xs:sequence> </xs:complexType>


</xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="TermsBasis" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>e.g. UNCL 01.A element 4279 Payment terms type code qualifier abstract:

1 Basic 2 End of month 3 Fixed date 4 Deferred 5 Discount not applicable 6 Mixed 7 Extended 8 Basic discount offered 9 Proximo 10 Instant .../... 69 Discount with prompt pay 70 Discount with advance payment 71 Certified cheque 72 Cash against documents 73 Bill of exchange 74 Progressive discount 75 Lump sum 76 Fixed fee ZZZ Mutually defined

XBRL: Payment Method</xs:documentation> </xs:annotation> </xs:element> <xs:element name="PaymentMeansId" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>To specify the payment terms basis.

e.g. 20 Cheque 21 Banker's draft 22 Certified banker's draft 23 Bank cheque (issued by a banking or similar establishment) 24 Bill of exchange awaiting acceptance 25 Certified cheque 26 Local cheque


31 Debit transfer 44 Accepted bill of exchange 48 Bank card</xs:documentation>

</xs:annotation> </xs:element> <xs:element name="PaymentInstruction" type="ReferenceCodeType" minOccurs="0"> <xs:annotation> <xs:documentation>e.g. UNCL 01.A element 2475

Time reference code abstract: 1 Date of order 2 Date of confirmation 3 Date of contract 4 Date of signature of contract 5 Date of invoice 6 Date of credit note 7 Date of present document 8 Date of confirmation of order received 9 Date invoice received 11 Date credit note received 12 Date present document received .../... 72 Payment date 73 Draft(s) at ... days sight 74 Draft(s) at ... days date 75 Draft(s) at ... days after date of issuance of transport document(s) 76 Draft(s) at ... days after date of presentation of documents 77 Specified draft date 78 Customs clearance date (import) 79 Customs clearance date (export) 80 Date of salary payment 81 Date of shipment as evidenced by the transport document(s) 82 Payment due date </xs:documentation>

</xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="MonetaryAmount" type="MonetaryAmountType"> <xs:annotation> <xs:documentation>ebXML Amount Class: A number of monetary units specified in a currrency where the unit of currency is explicit or it may be implied.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="DatePeriodId" type="DatePeriodType">


<xs:annotation> <xs:documentation>To indicate due date for a payment.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TimeId" type="TimeType"> <xs:annotation> <xs:documentation>To indicate due time for a payment.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="QuantityId" type="QuantityDetailsType"> <xs:annotation> <xs:documentation>An information to provide quantity related to virement.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="CurrencyId" type="CurrencyDetailType"> <xs:annotation> <xs:documentation>An information to provide currency linked to above amount.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ReferenceId" type="ReferenceCodeType"> <xs:annotation> <xs:documentation>An information to provide reference related to the payment.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IdentityId" type="IdentityId"> <xs:annotation> <xs:documentation>An information to provide party related to information specified in the index. e.g.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FeaturesId" type="CharacteristicType"> <xs:annotation> <xs:documentation>An information to provide choice of payment mode such as TLRA, check, virement, cash.</xs:documentation> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>