FR3066299A1

FR3066299A1 - Un systeme et un procede pour le traitement et le rapprochement comptable d'un fichier de donnees de facture

Info

Publication number: FR3066299A1
Application number: FR1754112A
Authority: FR
Inventors: Marianne Beatrice Fredriksson Eva; Frank Boeckx; Peter Hannes; Wim Maes
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2017-05-11
Filing date: 2017-05-11
Publication date: 2018-11-16

Abstract

L'invention présente fournit un système et un procédé pour effectuer un rapprochement de comptes sur un réseau informatique. Le système 10 comprend des moyens pour la réception d'une facture (30) et une base de données de vente réelle (14) et une plateforme de rapprochement en réseau (15). La plateforme de rapprochement en réseau (15) traite la facture du fournisseur (30) pour extraire et stocker les données SII correspondantes dans un ensemble d'enregistrements SII (SII1 -4). Un module de rapprochement (22) est fourni pour sélectionner, sur la base d'au moins un critère de rapprochement, des enregistrements SII (SII1 -4) et des enregistrements ASI (ASI1 -6) aux fins d'un rapprochement. Le module de rapprochement (22) est configuré pour agréger et stocker, pour chaque critère de rapprochement, les valeurs des enregistrements SII et ASI dans un ensemble de champs de donnée correspondants d'un enregistrement d'éléments de rapprochement (38). Le module de rapprochement (22) compare par ailleurs les valeurs agrégées des champs de donnée correspondants de l'enregistrement d'éléments de rapprochement (38) et détermine un état de rapprochement (36b).

Description

UN SYSTEME ET UN PROCEDE POUR LE TRAITEMENT ET LE RAPPROCHEMENT COMPTABLE D’UN FICHIER DE DONNEES DE FACTURE

Domaine technique L’invention en question concerne un système et un procédé pour effectuer un rapprochement de comptes sur un réseau informatique. Plus spécifiquement, l’invention en question vise un système et un procédé pour effectuer le rapprochement des factures de fournisseurs.

Art antérieur EP2413279B1 décrit un procédé implémenté par ordinateur pour rapprocher des données de facturation dans un réseau de télécommunications. Plus spécifiquement, le procédé de rapprochement qui est décrit permet le rapprochement de comptes entre un réseau-hôte mobile et virtuel (MVNO) et un opérateur-hôte mobile (MHO).

Cependant, en dépit des avances technologiques, le traitement et le rapprochement des factures de fournisseurs contenant au moins une liste d’éléments achetés à un fournisseur, tels que des marchandises et/ou des services, reste un processus complexe et chronophage. Généralement, les factures de fournisseurs peuvent être reçues par un service comptable d’une entité commerciale, sous format papier ou électronique, tel que pdf, Excel, etc. L’information contenue dans la facture reçue peut ensuite être saisie dans un système de comptabilité pour le traitement et le rapprochement. Cependant, même avec des processus hautement automatisés pour la saisie de données dans les systèmes comptables, p. ex. des techniques de numérisation de document, une grande partie des données contenues dans le fichier de données de facture de fournisseur peut malgré tout nécessiter une gestion, p. ex. une saisie ou une modification manuelle de l’utilisateur pour assurer un traitement correct de la facture de fournisseur par le système comptable. Cela s’explique du fait que les formats des factures émises par les fournisseurs varient largement d’un fournisseur à l’autre et répondent rarement aux exigences du système comptable utilisé par l’entité commerciale qui doit donc recourir à une gestion manuelle des données de facture de fournisseur par l’utilisateur. Par exemple, sur la facture de fournisseur reçue, certains éléments de données peuvent faire défaut, p. ex. la référence du fournisseur, le type d’éléments de fournisseur achetés, la date d’échéance du règlement, etc., ou les données de la facture de fournisseur peuvent être présentées dans un format incompatible, p. ex. la représentation des devises, des données non structurées, l’utilisation de codes de référence erronés, etc. Cependant la nécessité de gérer manuellement les données de chaque facture de fournisseur reçue augmente considérablement les ressources humaines et le temps nécessaire pour effectuer le traitement et le rapprochement, surtout au regard du nombre de factures reçues chaque jour par une entité commerciale qui ont besoin d’être traitées dans un délai spécifié. De surcroît, la gestion manuelle des données est une source courante de données erronées qui peuvent considérablement affecter la qualité des données saisies dans le système comptable et peuvent par ailleurs affecter les résultats du processus de rapprochement.

Une fois que les données de factures ont été saisies dans le système comptable, l’utilisateur peut procéder à la phase de rapprochement de la facture de fournisseur afin de décider s’il faut, ou non, payer la facture de fournisseur reçue. Généralement, le rapprochement d’une facture de fournisseur est effectué par la personne responsable de la commande des éléments sur la facture de fournisseur qui valide l’authenticité et l’exactitude de la facture fournisseur. La phase de rapprochement peut par ailleurs impliquer une comparaison entre les données de facture de fournisseur saisies dans le système comptable avec les données d’achat d’un bon de commande émis qui peuvent indiquer le type de services/marchandises faisant l’objet d’un achat et un budget. En pratique, le bon de commande contient rarement assez d’informations relatives au fournisseur individuel des éléments faisant l’objet de la commande pour prendre une décision de rapprochement. Par conséquent, l’utilisateur ne peut rapprocher la facture de fournisseur que sur la base d’informations de très haut niveau, p. ex. le coût total de multiples éléments fournis, ce qui donne lieu à un rapprochement de facture largement inefficace et imprécis. Généralement, toutes les factures reçues doivent être rapprochées manuellement à un certain degré, ce qui rend le processus de rapprochement extrêmement chronophage. Dans certains cas, afin d’améliorer l’efficacité du processus de rapprochement, les factures reçues de fournisseurs réputés de confiance ne sont peut-être pas scrutées avec autant d’attention que les factures reçues de fournisseurs ponctuels ou inhabituels. Dans ce cas, bien que le montant soit vérifié, la facture de fournisseur est automatiquement traitée comme un document authentique.

En outre, afin d’améliorer encore l’efficacité, certaines compagnies peuvent payer les factures en dessous d’un certain montant de façon automatique quand elles proviennent de fournisseurs réputés de confiance. Cependant, de telles pratiques, dans le but d’améliorer l’efficacité du processus de rapprochement, peuvent s’avérer extrêmement insécurisées et peuvent donner lieu au paiement automatique de factures frauduleuses qui semblent authentiques.

Au vu de ce qui précède, on peut estimer que les procédures courantes pour le traitement et le rapprochement des factures de fournisseurs sont inefficaces, imprécises, extrêmement insécurisées et coûteuses en matière de ressources humaines et de temps. Révélation de l’invention L’invention a pour but d’apporter un système qui surmonte les problèmes auxquels se heurtent les procédures actuelles pour traiter et rapprocher les factures de fournisseurs.

Plus particulièrement, l’objectif désiré est d’apporter un système et un procédé pour traiter et rapprocher une facture de fournisseur reçue d’un fournisseur de façon efficace, précise, économe et sécurisée. L’invention en question atteint ce but avec le système décrivant les caractéristiques techniques de la première revendication indépendante.

Plus spécifiquement, un système est fourni pour effectuer le traitement et le rapprochement de comptes sur un réseau informatique. Selon un aspect de l’invention en question, le système est fourni avec des moyens permettant de recevoir un fichier de données de facture de fournisseur comprenant au moins un premier ensemble de données de facture comprenant des informations sur les éléments de fournisseur achetés au fournisseur. Le système de l’invention en question peut être fourni avec une base de données de vente réelle comprenant au moins un enregistrement d’éléments de vente réelle (ASI) comprenant des données de vente réelle pour des éléments de fournisseur achetés à au moins un fournisseur. Ledit au moins un enregistrement d’éléments de vente réelle (ASI) étant stocké sous la forme d’un tableau d’éléments de vente réelle (ASI) comprenant un nombre de champs de donnée d’éléments de vente réelle (ASI), chaque champ étant configuré pour stocker une valeur de donnée d’élément de vente réelle dans un format prédéterminé de donnée. Une plateforme de rapprochement en réseau est fournie pour effectuer le rapprochement d’une facture de fournisseur reçue. La plateforme de rapprochement en réseau est opérationnelle avec les moyens pour recevoir le fichier de données de facture de fournisseur et, avec la base de données de vente réelle, pour effectuer le rapprochement des éléments de fournisseur indiqués dans le fichier de données de facture de fournisseur avec les enregistrements ASI correspondants, récupérés dans la base de données de vente réelle. Selon l’invention en question, la plateforme de rapprochement en réseau est fournie avec un module de traitement de facture configuré pour traiter le fichier de données de facture de fournisseur reçu de façon à extraire au moins le premier ensemble de données de facture. Le module de traitement de facture est configuré pour déterminer, à partir du premier ensemble de données de facture extraites, des données d’éléments de facture de fournisseur (SU) correspondant à chacun des éléments de fournisseur indiqués dans le fichier de données de facture. Le module de traitement de facture est configuré pour stocker dans une première portion d’une base de données de facture de fournisseur chaque donnée d’élément de facture de fournisseur (SU) extraite sous la forme d’un enregistrement d’éléments de facture de fournisseur (SU). Chaque enregistrement d’éléments de facture de fournisseur (SU) est stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée d’élément de facture de fournisseur (SU), chaque champ étant configuré pour stocker une valeur de donnée d’un élément de facture de fournisseur (SU) dans un format prédéterminé de donnée. Le système de l’invention en question est par ailleurs fourni avec un module de rapprochement de facture configuré pour sélectionner aux fins du rapprochement, sur la base d’au moins un critère de rapprochement (RC) comprenant au moins une valeur de rapprochement (RV), au moins un enregistrement d’éléments de facture de fournisseur (SU) à partir de la base de données d’éléments de facture de fournisseur (SU) et au moins un enregistrement d’éléments de vente réelle (ASI) dans la base de données de vente réelle. Le module de rapprochement de facture est configuré pour sélectionner des enregistrements d’éléments de facture de fournisseur (SU) et d’éléments de vente réelle (ASI) aux fins du rapprochement en comparant la valeur de chaque critère de rapprochement (RC) aux valeurs des données stockées dans l’ensemble des champs de donnée d’élément de facture de fournisseur (SU) et des champs de donnée correspondants de vente réelle (ASI) dans les tableaux d’éléments de facture de fournisseur (SU) et d’éléments de vente réelle (ASI) afin d’identifier les enregistrements correspondants d’éléments de facture de fournisseur (SU) et les enregistrements correspondants d’éléments de vente réelle. Le module de rapprochement de facture est configuré pour chaque valeur de rapprochement (RV), ou chaque combinaison de valeurs de rapprochement (RV), pour agréger et stocker les valeurs récupérées dans les champs de donnée des enregistrements correspondants d’éléments de facture de fournisseur (SU) identifiés et des enregistrements correspondants d’éléments de vente réelle (ASI) respectivement dans un ensemble de champs de donnée correspondants d’élément de facture de fournisseur (SUR) et dans un ensemble de champs de donnée d’élément de vente réelle (ASIR) d’au moins un enregistrement d’éléments de rapprochement (RI). L’enregistrement d’éléments de rapprochement (RI) est stocké dans une base de données d’enregistrements de rapprochement sous la forme d’au moins un tableau d’éléments de rapprochement (RI). Le module de rapprochement de facture est par ailleurs configuré pour effectuer le rapprochement des enregistrements d’éléments de facture de fournisseur (SU) appariés identifiés avec les enregistrements correspondants d’éléments de vente réelle (ASI) appariés en comparant les valeurs stockées dans les champs de donnée de rapprochement d’élément de facture de fournisseur (SUR) avec les valeurs stockées dans les champs de donnée correspondants de rapprochement d’élément de vente réelle (ASIR) d’au moins un enregistrement RI (38) de façon à identifier toutes les différences. Le module de rapprochement de facture est configuré pour stocker les valeurs de la comparaison dans un ensemble de champs de donnée de rapprochement d’au moins ledit enregistrement RI avec un état de rapprochement indiquant l’état du rapprochement. Par exemple, l’état de rapprochement peut indiquer que le rapprochement pour chaque élément de facture de fournisseur (SU) a été effectué avec succès ou qu’il a échoué.

Il a été constaté qu’avec le système de l’invention en question, les problèmes associés aux procédures courantes pour le traitement et le rapprochement des factures de fournisseurs peuvent être surmontés. Plus spécifiquement, en utilisant le module de traitement de facture, les données d’une facture de fournisseur peuvent être extraites tout en limitant l’intervention manuelle de l’utilisateur, quel que soit le format présenté, ce qui améliore ainsi considérablement l’efficacité, l’économie de coût et la précision du traitement d’une facture de fournisseur. Par ailleurs, en fournissant une plateforme de rapprochement en réseau connectée à une base de données de vente réelle, le système augmente de façon notable la précision et la transparence du processus de rapprochement. Cela s’explique du fait qu’en utilisant la plateforme de rapprochement, le rapprochement est effectué au niveau des enregistrements SU individuels, permettant ainsi une comparaison biunivoque entre les données SU extraites directement de la facture de fournisseur et les données ASI correspondantes extraites de la base de données de vente réelle. Par ailleurs, il s’avère que le rapprochement de la facture de fournisseur avec les données de vente réelle accroît de façon non négligeable la sécurité du processus de rapprochement. Cela s’explique du fait que, dans le cas d’une facture frauduleuse, la plateforme de rapprochement en réseau ne serait pas en mesure de récupérer un quelconque enregistrement ASI de la base de données de vente réelle ASI et par conséquent le rapprochement échouerait tout en incitant l’utilisateur à identifier la cause de l’échec. De surcroît, l’utilisation d’au moins un critère de rapprochement pour sélectionner les enregistrements SU et ASI aux fins du rapprochement accroît de façon notable la facilité d’utilisation du système en permettant de filtrer les données visées par le rapprochement, ce qui entraîne par ailleurs une nette amélioration de la vitesse et de la facilité de mise en œuvre du processus de rapprochement.

Selon un mode de réalisation de l’invention en question, le module de traitement de facture est configuré pour déterminer, à partir des données extraites d’une facture de fournisseur, un second ensemble de données comprenant des données de facture de fournisseur (SI) génériques. Par exemple, les données de facture de fournisseur (SI) génériques peuvent inclure des informations pour identifier le fournisseur de la facture, telles que le nom du fournisseur, le numéro de téléphone, l’adresse, les informations bancaires, et ainsi de suite. Le module de traitement de facture est configuré pour stocker au moins une portion des secondes données dans une seconde portion de la base de données de facture de fournisseur sous la forme d’un enregistrement de facture de fournisseur (SI) dans un tableau SI comprenant un ensemble de champs de donnée de facture de fournisseur (SI). Les données SI extraites peuvent être utilisées par la plateforme de rapprochement en réseau afin d’identifier les enregistrements SU pertinents et les enregistrements ASI correspondants à partir des bases de données respectives. L’utilisation d’information supplémentaire dans le processus de rapprochement peut avoir l’avantage d’augmenter la vitesse, la précision et la sécurité du rapprochement. La plateforme de rapprochement en réseau peut, par exemple, utiliser les données SI de la facture de fournisseur pour optimiser la précision du processus d’appariement des enregistrements SU aux enregistrements ASI correspondants. Autrement, ou de surcroît, le système peut utiliser l’apprentissage automatique pour apparier de façon plus précise les enregistrements SU aux enregistrements ASI correspondants, avec des mesures correctives humaines, ou autres, utilisées par le système pour améliorer sa connaissance des liens vraisemblables.

Selon les modes de réalisation de l’invention en question, le module de rapprochement est configuré pour sélectionner les Slls et les ASIs aux fins du rapprochement sur la base de la combinaison d’une pluralité de critères de rapprochement. Le module de rapprochement peut combiner les valeurs de deux ou plusieurs critères de rapprochement (RC) afin d’augmenter par ailleurs la précision du processus d’appariement des enregistrements SU aux enregistrements ASI et de réduire d’autre part la quantité de données à rapprocher. Par exemple, en utilisant le critère de rapprochement « ID de fournisseur» avec la valeur «fournisseur X» en combinaison avec le critère de rapprochement « Type d’élément de fournisseur » avec la valeur « Type X » le module de rapprochement serait amené à ne récupérer que les enregistrements SU et ASI dont les valeurs correspondent aux valeurs des critères de rapprochement.

Selon des modes de réalisation de l’invention en question, la plateforme de rapprochement en réseau comprend un outil de génération de critère de rapprochement qui est configuré pour générer la pluralité des critères de rapprochement (RC) à partir d’un ensemble de champs de donnée, sélectionnés dans les tableaux SI et/ou SU qui correspondent aux champs de donnée du tableau ASI. L’utilisation de l’outil de génération de critère de rapprochement simplifie considérablement la génération de critères de rapprochement (RC) pertinents à utiliser dans le processus de rapprochement pour la sélection des enregistrements SU et ASI pertinents aux fins d’un rapprochement. Les critères de rapprochement (RC) peuvent être utilisés individuellement ou en combinaison par le module de rapprochement. Par exemple, la liste des critères de rapprochement peut être présentée via une interface graphique d’utilisateur d’un terminal d’utilisateur, dans laquelle un utilisateur effectue une sélection des critères de rapprochement à utiliser dans le processus. Dans un autre exemple, l’outil de génération de critère de rapprochement peut communiquer les critères de rapprochement directement au module de rapprochement, réduisant ainsi de façon notable la nécessité d’une intervention manuelle de l’utilisateur durant le processus de rapprochement. Par ailleurs, l’outil de génération de critère de rapprochement peut générer les critères de rapprochement à partir de champs de donnée qui ont été identifiés comme étant communs aux tableaux SI/SII et aux tableaux ASI. Le fait d’identifier les champs de donnée utilisés couramment dans les deux bases de données (la base de données de vente réelle et la base de données de facture de fournisseur) assure que chaque critère de rapprochement retournera des données utilisables. Par exemple, le processus de détermination de la pertinence de chaque champ de donnée comme critère de rapprochement peut impliquer, sans restriction, une étape pour vérifier qu’il existe pour chaque champ de donnée d’enregistrement SI et/ou SU un champ de donnée correspondant dans l’enregistrement ASI et une étape pour créer une liste de champs de donnée couramment utilisés comme critères de rapprochement par le module de rapprochement. En outre, l’outil de génération de critères de rapprochement peut générer une liste de critères de rapprochement basée sur les informations historiques collectées au cours des processus de rapprochement antérieurs. Autrement, ou de surcroît, le module de rapprochement peut parcourir de façon hiérarchique les champs de donnée de chaque base de données et comparer les valeurs qui en résultent pour identifier les enregistrements SU et ASI correspondants.

Selon des modes de réalisation de l’invention en question, la plateforme de rapprochement en réseau est configurée pour générer, sur la base des résultats de rapprochement, un nombre de mesures de suivi, via une interface graphique d’utilisateur d’un terminal d’utilisateur, qui ont été sélectionnées à partir d’un groupe incluant : rejet de la facture, acceptation de la facture, rapport de facture, suivi de la commission, et refacturation. Le fait de fournir un nombre de mesures de suivi, déterminées sur la base des résultats du rapprochement, contribue à simplifier considérablement le processus de rapprochement pour l’utilisateur et à réduire par ailleurs le besoin en compétences requises de la part de l’utilisateur pour effectuer le rapprochement et le suivi des factures de fournisseurs. Cela permet de surmonter les problèmes des procédures traditionnelles de rapprochement, dans lesquelles les mesures de suivi du rapprochement doivent être déterminées manuellement par l’utilisateur sur la base de l’état du rapprochement et doivent être exécutées en utilisant des modules de système séparés, augmentant ainsi la complexité et le temps requis pour compléter le processus de rapprochement. Par exemple, dans les systèmes traditionnels de rapprochement, les mesures de suivi de commission et de refacturation nécessitent le traitement de la facture par des modules séparés du système. Le système de l’invention en question peut détecter les mesures de suivi attendues qui sont présentées à l’utilisateur pour sélection et exécution, sur la base de l’information extraite directement dans la facture de fournisseur, ce qui apporte une précision accrue des mesures de suivi générées. Autrement, ou de surcroît, le système de l’invention en question peut utiliser l’apprentissage automatique pour déterminer les mesures de suivi attendues, ce qui permet d’améliorer encore la précision des mesures de suivi générées. Le système peut, par exemple, utiliser une information historique pour déterminer la mesure de suivi la plus appropriée pour la facture de fournisseur en cours de traitement par le système. Le système peut être couplé de façon opérationnelle à au moins un module de suivi de facture configuré pour exécuter les mesures de suivi de facture, de façon à permettre la collecte et le partage d’informations historiques entre les différents modules du système. De cette façon, à partir des modules du système, le système rassemble un plus grand éventail d’informations qui peuvent être utilisées pour améliorer la précision du processus de rapprochement. Par exemple, après un rapprochement réussi, le système de l’invention en question peut directement présenter une mesure de suivi à l’utilisateur en l’incitant à payer la facture. Dans un autre exemple non restrictif, la plateforme de rapprochement en réseau peut signaler à l’utilisateur qu’aucun enregistrement ASI n’a été trouvé et que certaines données de la facture de fournisseur ont besoin d’être vérifiées avant de poursuivre. Dans encore un autre exemple non restrictif, la plateforme de rapprochement en réseau peut indiquer à l’utilisateur qu’un montant de commission doit être payé par le fournisseur et elle peut inciter l’utilisateur à sélectionner, soit de déduire la commission de la facture actuelle, soit d’envoyer une facture pour la commission au fournisseur. Par conséquent, l’utilisateur du système n’a pas besoin d’être un utilisateur compétent ayant une expertise en comptabilité et en pratiques de rapprochement puisque ces tâches sont effectuées par le système, ce qui donne lieu à un traitement plus précis et moins complexe de la facture de fournisseur.

Selon des modes de réalisation de l’invention en question, la plateforme de rapprochement en réseau comprend une unité d’intelligence de rapprochement agencée pour collecter des métadonnées de facture de fournisseur correspondant aux mesures prises et aux modifications effectuées sur les données durant le traitement et le rapprochement du fichier de données de facture de fournisseur. Il a été constaté que l’apport d’une unité d’intelligence de rapprochement a pour avantage d’améliorer considérablement l’efficacité, la précision et la sécurité du processus de rapprochement. Par exemple, le fait d’identifier comment un fichier de données de facture de fournisseur reçu a été traité et rapproché dans le passé, p. ex. en identifiant le type de critères de rapprochement utilisés ou le type d’enregistrements SU extraits, peut permettre au système d’extraire des modèles de traitement et de rapprochement qui peuvent être appliqués à des factures de fournisseur reçues de façon similaire. En conséquence, l’application de métadonnées historiques aux factures reçues améliore considérablement la précision, l’efficacité et la sécurité du processus de rapprochement.

Selon des modes de réalisation de l’invention en question, l’unité d’intelligence de rapprochement est configurée pour stocker les métadonnées des factures de fournisseurs dans une base de données historiques de serveur qui peut être accessible par la plateforme de rapprochement en réseau. Par exemple, le module de traitement de facture de la plateforme de rapprochement en réseau peut être configuré pour enrichir les enregistrements SI et SU stockés dans la base de données de facture de fournisseur avec les métadonnées déterminées à partir de la base de données historiques. Par exemple, lorsqu’une facture de fournisseur reçue contient un élément de fournisseur pointant vers une « réservation de chambre », le module de traitement peut déduire que l’élément de facture de fournisseur « type » correspond à «hébergement» et l’ajouter à l’enregistrement SU comme un champ de donnée en utilisant les métadonnées extraites de factures traitées de façon similaire. L’enrichissement des enregistrements SI et SU avec des métadonnées extraites de la base de données historiques améliore considérablement la qualité des données traitées et rapprochées, ce qui entraîne une nette amélioration de l’efficacité, de la précision et de la sécurité du processus de rapprochement.

Selon des modes de réalisation de l’invention en question, le système est en communication directe avec une plateforme de vente en réseau comprenant une base de données d’enregistrement financier (Fl) contenant un nombre d’enregistrements Fl, chaque enregistrement comprenant une donnée Fl enregistrée au moment de l’achat (ou de la vente pour le compte du fournisseur) de chaque élément de fournisseur. Selon des modes de réalisation de l’invention, le système comprend un gestionnaire de base de données qui est configuré pour traiter et transformer les enregistrements Fl de la base de données Fl afin de générer les enregistrements ASI qui doivent être stockés dans la base de données de vente réelle. Il a été constaté que la génération d’enregistrements ASI basés sur une donnée Fl, contenue dans les enregistrements Fl stockés dans la base de données Fl d’une plateforme de vente en réseau ayant été utilisée pour l’achat d’éléments de facture de fournisseur, améliore considérablement la précision du processus de rapprochement. Cela est dû au fait que les enregistrements ASI utilisés pour le rapprochement sont directement déterminés à partir de la donnée Fl qui a été enregistrée par la plateforme de vente en réseau au moment de l’achat de l’élément de facture de fournisseur.

Selon des modes de réalisation de l’invention en question, le gestionnaire de base de données est configuré pour extraire un sous-ensemble de données Fl correspondant aux champs de donnée ASI du tableau ASI à remplir. Le fait de sélectionner uniquement les données Fl pertinentes correspondant aux champs ASI du tableau ASI à remplir réduit considérablement la quantité de données à utiliser dans le processus de rapprochement, améliorant ainsi de façon non négligeable la précision et l’efficacité du processus de rapprochement. Le fait, par exemple, de réduire la quantité de données à rapprocher réduit considérablement le temps nécessaire pour identifier les enregistrements ASI correspondant audit au moins un critère de rapprochement.

Selon des modes de réalisation de l’invention en question, le gestionnaire de base de données est configuré pour convertir le format du sous-ensemble des données Fl extraites au format des données de la base de données de vente réelle, p. ex. en convertissant les montants à une devise locale. Il est possible de cette façon d’assurer que les données Fl extraites sont compatibles avec le format utilisé par la base de données de vente réelle pour stocker les enregistrements ASI, évitant ainsi des problèmes d’incompatibilité qui peuvent affecter le processus de rapprochement.

Selon des modes de réalisation de l’invention en question, le gestionnaire de base de données est configuré pour harmoniser les données Fl extraites avec les données stockées dans la base de données de facture de fournisseur. Par exemple, le gestionnaire de base de données peut être configuré pour étiqueter les données Fl extraites selon un système d’étiquetage des données SU et/ou SI stockées dans la base de données de facture de fournisseur. En effectuant une harmonisation des données, il est possible d’assurer que les enregistrements ASI et SU auront un nombre de champs de donnée couramment désignés, ce qui réduit considérablement la complexité d’apparier les enregistrements ASI aux enregistrements SU, réduisant ainsi considérablement l’efficacité et la précision du processus de rapprochement.

Selon des modes de réalisation de l’invention en question, le gestionnaire de base de données est configuré pour enrichir les données Fl avec les métadonnées extraites de la base de données historiques. L’enrichissement des données avec les métadonnées extraites de la base de données historiques améliore considérablement la qualité des données ASI utilisées dans le rapprochement, ce qui entraîne une amélioration notable de l’efficacité, de la précision et de la sécurité du processus de rapprochement.

Selon des modes de réalisation de l’invention, le gestionnaire de base de données est configuré pour surveiller la base de données Fl afin de détecter tout changement survenant dans la base de données Fl et pour actualiser les enregistrements ASI correspondants stockés dans la base de données de vente réelle. Le fait de vérifier continuellement et périodiquement que les données stockées dans les enregistrements Fl ont été mises à jour assure que les enregistrements ASI utilisés dans le rapprochement contiennent toujours des données actualisées, améliorant ainsi considérablement la précision du processus de rapprochement. Par exemple, lorsqu’un enregistrement Fl d’un élément de fournisseur acheté a été modifié, p. ex. un changement de quantité, le gestionnaire de base de données actualise l’enregistrement ASI correspondant pour refléter les changements effectués dans l’enregistrement Fl. Le gestionnaire de base de données peut, par exemple, utiliser un identifiant de version permettant de déterminer la version actuelle des enregistrements stockés dans la base de données de vente réelle qui peut ensuite être comparé à l’identifiant de version des enregistrements ASI correspondants stockés dans la base de données de vente réelle.

Selon des modes de réalisation de l’invention en question, le système comprend un outil de génération de facture configuré pour générer, directement à partir des enregistrements ASI stockés dans la base de données de vente réelle, une facture de fournisseur, dite facture « éphémère ». La facture « éphémère » peut être présentée à l’utilisateur pour être éditée et traitée par ailleurs, sans qu’il soit nécessaire de saisir un fichier de données de facture de fournisseur séparé dans le système, ce qui simplifie considérablement le traitement des factures de fournisseur. De cette façon, il est possible de comparer aisément la facture de fournisseur « éphémère » avec la facture reçue, améliorant ainsi considérablement la vitesse et la précision du processus de rapprochement. La sécurité du rapprochement peut par ailleurs être accrue avec la génération des factures « éphémères » puisque seules les factures provenant de fournisseurs de confiance peuvent être générées à partir de la base de données ASI pour le rapprochement. Par ailleurs, une facture « éphémère » peut être utilisée pour supplémenter ou remplacer des factures de mauvaise qualité reçues pour un rapprochement. Par exemple, lorsqu’une facture de fournisseur de mauvaise qualité reçue contient un niveau d’information insuffisant pour effectuer le rapprochement, l’utilisateur peut utiliser une facture « éphémère » pour supplémenter l’information manquante identifiée, permettant ainsi au processus de réconciliation de reprendre sans qu’il soit nécessaire pour l’utilisateur de demander l’information additionnelle au fournisseur émetteur de la facture ou de rejeter la facture. Par ailleurs, dans certains cas, l’utilisateur peut décider de générer une facture de fournisseur pour des éléments achetés avant même que la facture réelle soit émise par le fournisseur. Pour des raisons fiscales, par exemple, l’utilisateur peut désirer payer tous les achats effectués pendant l’année fiscale avant de communiquer un rapport financier aux administrations fiscales.

Selon des modes de réalisation de l’invention en question, le module de traitement de facture, le module de rapprochement et le gestionnaire de base de données sont configurés pour optimiser le stockage des enregistrements dans les bases de données respectives. Par conséquent, le temps nécessaire pour rechercher et récupérer des données dans les bases de données respectives est considérablement réduit, ce qui améliore de façon notable l’efficacité des ressources matérielles du système qui sont mises à contribution, p. ex. le temps d’accès à la mémoire, les opérations de lecture/écriture de base de données, la puissance de calcul et le trafic de réseau. L’optimisation des ressources matérielles du système peut, par exemple, être atteinte en fournissant une représentation de valeur « clé » de tous les champs de donnée des bases de données respectives qui peuvent être stockés sous la forme d’un tableau de valeurs clés. Le tableau de valeurs clés peut contenir une collection d’enregistrements contenant des données, chaque enregistrement étant identifié de façon unique par une valeur « clé ». Ainsi, en utilisant des valeurs « clés », la recherche d’enregistrements correspondants peut être effectuée à un niveau plus élevé, ce qui réduit nettement le temps de réponse aux interrogations et la puissance de calcul requise. Les valeurs « clés » peuvent par ailleurs donner lieu à une utilisation notablement réduite de la mémoire pour le stockage de la même base de données, ce qui peut entraîner des gains de temps non négligeables pour certaines charges de travail et des réductions substantielle de la puissance de calcul requise et du trafic afférent des données de réseau.. Par ailleurs, l’utilisation de valeurs «clés» peut permettre l’utilisation de données non structurées dans le processus de rapprochement. Autrement, ou de surcroît, les ressources matérielles du système peuvent être optimisées en dénormalisant les bases de données respectives et/ou en indexant les colonnes des tableaux SU et ASI qui s’y trouvent pour obtenir des champs de donnée familiers basés sur des informations de métadonnées extraites de la base de données historiques. Par exemple, les tableaux indexés peuvent être fournis pour la plupart des combinaisons de champs de donnée représentant les critères correspondants pour identifier les enregistrements SU et ASI correspondants dans les bases de données respectives des systèmes. Les combinaisons les plus courantes de champs de donnée peuvent être déterminées, soit directement par l’utilisateur, soit sur la base des informations historiques stockées dans la base de données historiques. La dénormalisation peut impliquer l’ajout de copies de données redondantes ou le groupement de données stockées dans les bases de données du système, ce qui entraîne une augmentation de la performance de lecture de la base de données et se traduit par des améliorations notables du temps de réponse aux interrogations.

Selon un second aspect de l’invention en question, un procédé pour effectuer un rapprochement de comptes sur un réseau informatique est fourni. Le procédé comprend les étapes suivantes : la réception au moyen d’un fichier de données de facture de fournisseur comprenant au moins un premier ensemble de données de facture qui comprend les informations relatives aux éléments de fournisseur achetés au fournisseur, l’apport d’une base de données de vente réelle comprenant au moins un enregistrement d’éléments de vente réelle (ASI) comprenant des données de vente réelle pour des éléments de fournisseur achetés à au moins un fournisseur, ledit au moins un enregistrement ASI étant stocké sous la forme d’un tableau ASI comprenant un nombre de champs de donnée ASI, chaque champ étant configuré pour stocker une valeur de donnée ASI sous un format prédéterminé de donnée, et le rapprochement des éléments de fournisseur indiqués dans le fichier de données de facture de fournisseur avec les enregistrements correspondants ASI récupérés dans la base de données de vente réelle, dans lequel l’étape de rapprochement comprend les étapes suivantes : le traitement par le module de traitement de facture du fichier de données de facture de fournisseur (30) de façon à extraire au moins un premier ensemble de données de facture, la détermination par le module de traitement de facture, à partir du premier ensemble de données de facture (30a), des données d’élément de facture de fournisseur SU qui correspondent à chacun des éléments de fournisseur indiqués dans le fichier de données de facture, le stockage dans une première portion d’une base de données de facture de fournisseur de chaque donnée SU extraite sous la forme d’un enregistrement d’éléments de facture de fournisseur (SU) chaque enregistrement SU étant stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée SU, chaque étant configuré pour stocker une valeur de donnée SU sous un format prédéterminé de donnée, et l’extraction des données de facture de fournisseur à partir du fichier de données de facture de fournisseur, la sélection au moyen d’un module de rapprochement, sur la base d’au moins un critère de rapprochement comprenant au moins une valeur de rapprochement, d’au moins un enregistrement SU de la base de données SU et d’au moins un enregistrement ASI correspondant de la base de données de vente réelle, dans lequel l’étape de sélection des enregistrements SU et ASI aux fins du rapprochement comprend l’étape de comparaison des valeurs de chaque critère de rapprochement aux valeurs des données stockées dans l’ensemble des champs de donnée SU et des champs de donnée ASI correspondants des tableaux SU et ASI respectivement afin d’identifier les enregistrements correspondants SU et les enregistrements correspondants ASI qui se correspondent, dans lequel, pour chaque valeur de rapprochement ou chaque combinaison de valeurs de rapprochement, l’étape de rapprochement comprend par ailleurs les étapes suivantes : l’agrégation et le stockage des valeurs récupérées, à partir des champs de donnée des enregistrements correspondants SU et ASI identifiés, respectivement dans un ensemble de champs de donnée de rapprochement SU, SUR, correspondants et dans un ensemble de champs de donnée de rapprochement ASI, ASIR, d’au moins un enregistrement d’éléments de rapprochement (RI), l’enregistrement d’éléments de rapprochement étant stocké dans une base de données d’enregistrement de rapprochement sous la forme d’au moins un tableau d’éléments de rapprochement, RI, le rapprochement des enregistrement appariés SU identifiés avec les enregistrements appariés ASI qui leur correspondent en comparant les valeurs stockées dans les champs SUR (35a) avec les valeurs stockées dans les champs ASIR correspondants dudit au moins un enregistrement RI de façon à identifier toutes les différences, le stockage des valeurs de la comparaison dans un ensemble de champs de donnée de rapprochement (36a) dudit au moins un enregistrement RI, et la mise à jour de l’enregistrement RI via un état de rapprochement indiquant l’état du rapprochement.

Selon des modes de réalisation de l’invention en question, un milieu-support fourni est configuré pour stocker des instructions exécutables qui, lorsqu’elles sont chargées sur un système informatique, amènent le système informatique à mettre en œuvre le procédé de rapprochement conformément au second aspect de l’invention en question.

Brève description des dessins L’invention sera par ailleurs expliquée au moyen de la description qui suit et des dessins annexés.

Figure 1 montre, à titre d’exemple, une plateforme de vente en réseau pour vendre et acheter des marchandises et des services sur un réseau informatique selon des modes de réalisation de l’invention en question.

Figure 2 illustre un exemple de données d’éléments financiers (Fl) stockées dans la base de données Fl représentant des données de vente brute générées au cours d’une vente et/ou d’un achat de marchandises et de services auprès d’un fournisseur selon des modes de réalisation de l’invention en question.

Figure 3 illustre un exemple de fichier de données de facture de fournisseur reçue d’un fournisseur selon des modes de réalisation de l’invention en question.

Figure 4 illustre, à titre d’exemple, un système intermédiaire d’arrière-plan (Middle-Back Office [MBO]) selon des modes de réalisation de l’invention en question.

Figure 5 illustre, à titre d’exemple, un système pour traiter et rapprocher des factures de fournisseurs selon des modes de réalisation de l’invention en question.

Figure 6 illustre un exemple de conversion des enregistrements Fl, présentés dans la figure 2 en enregistrements ASI selon des modes de réalisation de l’invention en question.

Figure 7 illustre, à titre d’exemple, un système pour effectuer le traitement et le rapprochement des factures de fournisseurs selon des modes de réalisation de l’invention en question.

Figure 8 illustre, à titre d’exemple, l’implémentation d’un module de traitement de facture selon des modes de réalisation de l’invention en question.

Figures 9 et 10 montrent un exemple de conversion de données de facture de fournisseur respectivement en enregistrements SI et SU selon des modes de réalisation de l’invention en question.

Figure 11 illustre, à titre d’exemple, une implémentation de la plateforme de rapprochement en réseau selon des modes de réalisation de l’invention en question.

Figure 12 illustre, à titre d’exemple, une implémentation du module de rapprochement selon des modes de réalisation de l’invention en question.

Figure 13 montre un exemple d’un ensemble de critères de rapprochement utilisés pour des enregistrements SU et ASI correspondants dans les bases de données de système respectif selon des modes de réalisation de l’invention en question.

Figure 14 montre un exemple d’agrégation des enregistrements SU et ASI correspondants selon des modes de réalisation de l’invention en question.

Figure 15 montre un exemple d’agrégation des valeurs à partir des enregistrements identifiés SU et ASI correspondants de la figure 14 selon des modes de réalisation de l’invention en question.

Figure 16 montre un exemple de la comparaison des valeurs agrégées de la figure 15 selon des modes de réalisation de l’invention en question.

Figure 17 montre un exemple d’un enregistrement d’éléments de rapprochement (RI) généré selon des modes de réalisation de l’invention en question.

Figure 18 est un diagramme séquentiel montrant, à titre d’exemple, un procédé pour effectuer un rapprochement de comptes selon un mode de réalisation de l’invention en question.

Figure 19 est une vue schématique d'un système informatique exemplaire.

Modes de mise en œuvre de l’invention L’invention en question sera décrite par rapport à divers modes de réalisation et en se référant à certains dessins, mais la portée de l’invention n’est pas limitée à ceux-là, et ne peut l’être que par les revendications. Les dessins décrits sont schématiques et ne sont pas restrictifs. Les dessins sont fournis à titre d’illustrations et à ce titre, la taille de certains éléments peut être exagérée et ne pas être dessinée à l’échelle. Les dimensions et les dimensions relatives ne correspondent pas nécessairement aux réductions réelles de pratique de l’invention.

Par ailleurs, les termes « premier, second, troisième » et ainsi de suite, dans la description et dans les revendications, sont utilisés pour faire la distinction entre des éléments similaires et ne sont pas nécessairement utilisés pour décrire un ordre séquentiel ou chronologique. Les termes sont interchangeables dans des circonstances appropriées et les modes de réalisation de l’invention peuvent fonctionner selon d’autres séquences que celles décrites ou illustrées dans les présentes.

En outre, les termes « dessus, dessous, sur, en dessous » et ainsi de suite, utilisés dans la description et les revendications le sont dans un but descriptif et ne sont pas nécessairement utilisés pour décrire des positions relatives. Les termes utilisés ainsi sont interchangeables dans des circonstances appropriées et les modes de réalisation de l’invention décrits dans les présentes peuvent fonctionner avec d’autres orientations que celles décrites ou illustrées dans les présentes.

Par ailleurs, les modes de réalisation, bien qu’ils soient qualifiés de « préférés » doivent être interprétés comme des modes d’implémentation exemplaires de l’invention dont la portée n’est pas restrictive.

Le terme « comprenant » utilisé dans les revendications ne doit pas être interprété dans un sens restrictif des éléments ou des étapes détaillés par la suite ; il n’exclut pas d’autres éléments ou étapes. Il faut l’interpréter comme un verbe qui spécifie la présence de caractéristiques énoncées, de nombres entiers, d’étapes ou de composants auxquels une référence est faite, mais exclut en aucun cas la présence ou l’ajout d’une ou de plusieurs autres caractéristiques, de nombres entier, d’étapes ou de composants, ou des groupes de ceux-là. Ainsi, la portée de l’expression « un dispositif comprenant A et B » ne se limite pas à des dispositifs consistants uniquement de composants A et B, mais signifie plutôt que les seuls composants énumérés des dispositifs sont A et B, et que d’autres composants peuvent exister. Par ailleurs, la portée de la revendication doit être interprétée comme incluant des équivalents de ces composants. L’invention en question sera expliquée en se référant aux exemples montrés dans les figures 1 à 18.

Les progrès de la technologie Internet ont fondamentalement altéré la façon dont les activités commerciales sont menées, telles que les achats et les ventes de marchandises et de services Dans le monde connecté d’aujourd’hui, la majorité des transactions commerciales entre un acheteur et un fournisseur peuvent être facilitées directement par des plateformes de vente en ligne. Les plateformes de vente en ligne peuvent être utilisées pour connecter un acheteur à des produits et des services offerts par au moins un fournisseur et facilitent par ailleurs toutes les transactions qui suivent, telles que le paiement, l’émission de factures etc.

La figure 1 montre un exemple de plateforme de vente configurée pour connecter un acheteur 11 à des produits offerts à la vente par au moins un fournisseur 13. La plateforme de vente peut être configurée, par exemple, pour faciliter la vente et l’achat p. ex. de billets d’avion, chambres d’hôtel, voitures de location et ainsi de suite, liés à un voyage. Via la plateforme de vente, un acheteur 11, p. ex. un agent de voyage, peut acheter un nombre de produits auprès d’au moins un fournisseur 13. Par exemple, un agent de voyage 11 peut réserver, via la plateforme de vente, un nombre de chambres d’hôtel chez un fournisseur hôtelier 13 pour une période donnée. Une fois que le processus d’achat est finalisé, la plateforme de vente peut communiquer les produits achetés au fournisseur 13 et peut, par ailleurs, envoyer une confirmation de l’achat à l’acheteur 11. Au cours du processus d’achat des produits, la plateforme de vente peut être configurée pour collecter et stocker des informations de vente brutes associées aux produits achetés dans une base de données d’enregistrement financier 12. La plateforme de vente peut être configurée, par exemple, pour consolider et stocker des informations de vente brutes associées aux produits achetés dans la base de données d’enregistrement financier 12, une fois que l’acheteur 13 a finalisé l’achat.

La figure 2 donne un exemple d’informations de ventes brutes, stockées dans la base de données d’enregistrement financier 12 qui sont associées à la réservation d’un nombre de chambres d’hôtel auprès d’un fournisseur hôtelier. Dans l’exemple de la figure 2, les informations de vente brutes associées à chaque produit acheté sont stockées sous la forme d’un enregistrement de base de données FI1-6, désigné comme enregistrement d’élément financier (Fl), comprenant un nombre prédéterminé de champs de donnée 12a. Chacun des champs de donnée d’enregistrement Fl peut contenir au moins une valeur de donnée déterminée à partir des informations de vente brutes extraites des produits achetés. Dans l’exemple de la figure 2, la base de données d’enregistrement financier 12 comprend six enregistrements Fl, FI1-6, chaque enregistrement comprenant des informations relatives à un nombre correspondant de produits achetés. Les enregistrements Fl, FI1-6, peuvent par exemple stocker différents types d’information associée aux produits achetés dans les champs de donnée correspondants 12a. Des exemples d’information pouvant être stockée dans les champs de donnée Fl 12a peuvent inclure le type (du produit), la devise d’achat, le tarif, le nom du passager, le type de réservation, la date de réservation, les dates d’arrivée et de sortie, l’hôtel, le type de chambre réservée, le nombre de nuits, l’achat et la vente de devises, la réduction, le prix à payer, les unités et ainsi de suite. Comme l’illustre l’exemple de la figure 2, tous les enregistrements financiers FI1-6 sont du même type « hébergement » et ont été réservés auprès du même hôtel « AALON133 », alors que le tarif et le prix à payer peuvent être différents en fonction du type de réservation de chambre attribuée et du nombre d’unités achetées. La base de données d’enregistrement financier 12 peut-être une base de données relationnelle, configurée pour stocker les enregistrements Fl, FI1-6, sous la forme d’au moins un tableau contenant un nombre de champs de donnée 12a. Les champs de donnée 12a peuvent être configurés pour stocker des valeurs de donnée saisies dans un format prédéterminé. Les champs de donnée 12a peuvent par ailleurs être étiquetés selon un système prédéterminé d’étiquetage.

Selon des modes de réalisation de l’invention en question, le fournisseur 13 peut émettre un fichier de données de facture de fournisseur 30, une fois que l’achat des produits a été finalisé, Le fichier de données de facture de fournisseur 30 est transmis à l’acheteur 11 pour règlement, soit dans un format électronique, p. ex. pdf, Excel, XML, etc. via un lien de communication, tel qu’un serveur d’échange de courriels, soit comme une copie physique via un service postal ou autre. La figure 3 montre un exemple d’un fichier de données de facture de fournisseur 30 émis pour les produits achetés à partir du réseau de vente illustré dans la figure 2. La facture du fournisseur 30 contient une variété d’informations, telles que les différents produits achetés, le prix payé pour chaque produit, la commission due, la date d’échéance du solde à payer, le nom du fournisseur hôtelier émettant la facture, le compte bancaire et les détails de contact du fournisseur hôtelier émettant la facture, et ainsi de suite. Les différentes informations contenues dans la facture de fournisseur peuvent être catégorisées sous au moins un premier ensemble de données 30a et un second ensemble de données 30b. Par exemple, le premier ensemble de données 30a peut contenir des informations relatives aux produits achetés, également désignés comme éléments de facture de fournisseur (SU), p. ex. la quantité, le type, le prix de vente de chaque élément de fournisseur, la TVA due, la commission due, la date d’échéance du solde et ainsi de suite. Le second ensemble de données 30b peut contenir des données associées à plusieurs informations génériques, telles que le nom du fournisseur, le contact, les détails bancaires du fournisseur et ainsi de suite, également désignées comme éléments de fournisseur (SI) de la facture de fournisseur.

Une fois que le fichier de données de facture de fournisseur 30 est reçu, l’acheteur 11 peut accéder, via un terminal informatique, à un système de rapprochement de comptes 10 pour traiter et rapprocher le fichier de données de facture de fournisseur 30 reçu. Par exemple, comme l’illustre la figure 4, l’acheteur 11 peut accéder, via un lien de communication 11a, à un système intermédiaire d’arrière-plan (Middle-Back Office [MBO]) fourni avec un système de rapprochement de comptes 10. Bien que le système de rapprochement de comptes 10 dans la figure 4 soit représenté comme faisant partie d’un système MBO générique, p. ex. sous la forme d’un module logiciel, il peut aussi être fourni comme un système autonome auquel l’utilisateur peut accéder indépendamment.

Comme l’illustre la figure 4, le système MBO fourni peut être en communication directe avec la base de données Fl 12 de la plateforme de vente. De cette façon, le système de rapprochement de comptes 10 peut accéder et utiliser l’information stockée dans les enregistrements Fl, FI1-6, pour rapprocher le fichier de données de facture de fournisseur 30.

Comme l’illustre la figure 5, le système de rapprochement de comptes 10 peut comprendre des moyens pour recevoir un fichier de données de facture 30. Le fichier de données de facture de fournisseur 30 peut être fourni par l’utilisateur via le lien de communication 11a. Par exemple, les moyens 16 pour recevoir un fichier de données de facture 30 peuvent être fournis avec un système de numérisation actionné par un utilisateur qui est configuré pour convertir une copie physique d’un fichier de données de facture 30 en format électronique. Dans un autre exemple, les moyens 16 pour recevoir un fichier de données de facture de fournisseur 30 peuvent comprendre un outil de téléchargement de fichier fonctionnant sur un dispositif informatique. L’outil de téléchargement de fichier peut, en réponse à une requête d’un utilisateur, être configuré pour récupérer une version numérique d’un fichier de données de facture de fournisseur, p. ex. pdf, Excel, XML, ou tout autre format approprié, à partir d’une base de données locale ou distante aux fins d’un traitement par le système de rapprochement de comptes 10.

Comme l’illustre la figure 5, les moyens 16 peuvent transmettre le fichier de données de facture de fournisseur 30 à une plateforme de rapprochement en réseau 15, configurée pour traiter et rapprocher le fichier de données de facture de fournisseur 30. La plateforme de rapprochement en réseau 15 peut être fournie en communication dirigée avec une base de données de vente réelle (ASI) 14 comprenant des données de vente réelle extraites à partir des données de vente brutes stockées dans la base de données d’enregistrement financier 12.

La figure 6 montre un exemple de données d’éléments de vente réelle stockées dans la base de données d’éléments de vente réelle (ASI) 14. Dans l’exemple illustré, les données de vente réelle sont stockées sous la forme d’au moins un enregistrement de base de données ASI 1-6, désigné comme enregistrement d’éléments de vente réelle (ASI), contenant un nombre de champs de donnée prédéterminés 14a. Chaque champ de donnée ASI 14a peut contenir au moins une valeur de donnée extraite et/ou déterminée à partir des données de vente brutes stockées dans les enregistrements Fl, Fl 1-6, de la base de données Fl 12. Dans l’exemple de la figure 6, la base de données ASI 14 comprend six enregistrements ASI 1-6 correspondant au nombre d’enregistrements Fl, FI1-6 stockés dans la base de données Fl 12, comme le montre la figure 2. Les enregistrements ASI, ASI1-6 peuvent stocker l’information associée aux produits achetés dans les champs de donnée correspondants 14a. Des exemples d’information pouvant être stockée dans les champs de donnée ASI 14a peuvent inclure le type (de produit), le type de chambre (dans le cas d’une chambre d’hôtel), le montant de la vente, le montant total de TVA, le montant total de commission, le montant brut total de l’achat, le montant net total de l’achat, le nom du fournisseur/hôtel, l’adresse du fournisseur/hôtel, le pays du fournisseur/hôtel et ainsi de suite. Comme l’illustre l’exemple de la figure 6, les champs de donnée ASI 14a peuvent ne pas correspondre nécessairement aux champs de donnée Fl 12a des enregistrements Fl, FI1-6, représentés dans la figure 2. Il peut donc être nécessaire d’établir la correspondance entre les champs de donnée ASI 14a et les champs Fl 12a. Cela peut être effectué par un système de gestion de base de données 19, comme l’illustre la figure 5. Le système de gestion de base de données 19 peut déterminer la correspondance entre les champs de donnée ASI 14a et les champs de donnée Fl en utilisant un tableau de correspondance de champs de donnée. Autrement, ou de surcroît, le système de gestion de base de données 19 peut déterminer la correspondance entre les champs de donnée ASI 14a et les champs de donnée Fl en utilisant les informations historiques collectées au cours de rapprochements antérieurs. Le système de gestion de base de données 19 peut être configuré pour extraire et/ou déterminer les données d’éléments de vente réelle devant être stockées dans la base de données ASI 14 à partir des données Fl stockées dans la base de données Fl 12. Le gestionnaire de base de données 19 peut être configuré pour accéder à la base de données Fl 12 de façon à récupérer au moins une portion des données Fl stockées dans chacun des enregistrements Fl, FI1-6. Le gestionnaire de base de données 19 peut être configuré pour générer les enregistrements ASI, ASI1-6, devant être stockés dans la base de données ASI 14 en traitant et en transformant les données Fl des enregistrements Fl, FI1-6, récupérés à partir de la base de données Fl 12, ce qui peut impliquer l’exécution d’un nombre d’actions pour le traitement et le formatage de données. Par exemple, le gestionnaire de base de données 19 peut être configuré pour extraire uniquement un sous-ensemble des données Fl contenues dans chaque enregistrement Fl, FI1-6 qui peut être sélectionné sur la base des champs de donnée ASI 14a du tableau ASI devant être rempli dans la base de données ASI 14. Autrement, ou de surcroît, le gestionnaire de base de données 19 peut être configuré pour convertir le format de la source de données du sous-ensemble de données Fl au format de données de destination de la base de données ASI 14, p. ex. en convertissant les montants monétaires dans la devise locale, en convertissant des symboles en texte ou en nombres, en convertissant des valeurs de date et d’heure au format de destination, etc. Dans les exemples illustrés dans les figures 2 et 6, le champ de l’hôtel dans la liste des champs de donnée Fl 12a indiquant AALON133 est converti à Hôtel & Leisure Club, incluant l’adresse, le pays et le numéro de téléphone de l’hôtel. En outre, le système de gestion de base de données 19 peut déterminer la valeur des champs de donnée ASI 14a à partir de données déjà identifiées. Par exemple, le champ de donnée ASI 14 dans la liste intitulé « Total achat net » peut être déterminé en soustrayant la valeur stockée dans le champ de donnée «Total commission» de la valeur stockée dans le champ de donnée « Montant de vente total ». Ces détails sont placés dans les enregistrements pertinents des champs de donnée ASI 14a.

Selon un mode de réalisation de l’invention en question, le gestionnaire de base de données 19 peut être configuré pour harmoniser le sous-ensemble de données Fl extraites afin d’assurer la compatibilité avec d’autres données gérées par le système 10, telles que les données stockées dans la base de données de facture de fournisseur 21. Dans un autre exemple non restrictif, le gestionnaire de base de données peut être configuré pour étiqueter le sous-ensemble de données Fl extraites selon un système d’étiquetage des données stockées dans d’autres base de données de système, telles que les données stockées dans la base de données de facture de fournisseur 21. Dans un autre exemple non restrictif, le gestionnaire de base de données 19 peut être configuré pour enrichir le sous-ensemble des données Fl avec des métadonnées extraites d’une base de données historiques 18, p. ex. certains des champs de donnée de l’enregistrement ASI généré peuvent être déterminés à partir des informations de métadonnées stockées dans la base de données historiques 18, p. ex. le champ de donnée de type de chambre. Dans les exemples illustrés dans les figures 2 et 6, l’enregistrement Fl, FI1 indique que la valeur du champ de donnée Fl « Type de réservation de chambre » est « D2A » ce qui, dans le champ de donnée ASI1 14a correspondant de l’enregistrement ASI ASI1 «Type de chambre », est converti en valeur de donnée « Double ».

De surcroît, le gestionnaire de base de données 19 peut être configuré pour surveiller la base de données Fl 12, de façon continue ou périodique, afin de détecter des mises à jour ou des modifications effectuées récemment dans les enregistrements Fl, FI1-6 qui y sont stockés et pour actualiser en conséquence les enregistrements ASI correspondants, ASI1-6 de la base de données ASI 14. Par exemple, le gestionnaire de base de données 19 peut utiliser un identifiant de version d’enregistrement Fl qui peut être stocké avec les enregistrements Fl 1-6 dans la base de données Fl 12 pour déterminer si la version actuellement stockée dans la base de données Fl 12 est bien celle qui est utilisée pour générer les enregistrements ASI, ASM-6. Si la version d’enregistrement Fl n’est pas la même que la version ASI, le gestionnaire de base de données 19 peut alors extraire la portion modifiée des enregistrements Fl 1-6 et actualiser en conséquence les portions correspondantes des enregistrements ASI, ASM -6.

Comme l’illustre la figure 7, le système de rapprochement de comptes 10 peut être fourni avec une unité d’intelligence de rapprochement 17 qui peut être configurée pour collecter des métadonnées au cours du traitement et du rapprochement du fichier de données de facture de fournisseur. Les métadonnées collectées peuvent définir comment les données des factures de fournisseurs précédentes ont été manipulées au cours du processus de traitement et de rapprochement par les composants du système 10 et/ou par l’utilisateur du système 10 via une interface graphique d’utilisateur (GUI). Par ailleurs, les métadonnées collectées peuvent définir les décisions prises par l’utilisateur du système par rapport au traitement et au rapprochement de chaque facture de fournisseur reçue. Par exemple, les enregistrements de métadonnées peuvent être générés lorsqu’un utilisateur effectue des rapprochements de facture régulièrement en dépit d’une petite différence avec les valeurs des données de vente réelle correspondantes. Ces enregistrements peuvent, par exemple, être utilisés pour proposer automatiquement un rapprochement des factures dont il a été déterminé qu’elles contiennent de petites différences avec les valeurs des données de vente réelle correspondantes. Autrement, ou de surcroît, le système 10 peut récupérer des enregistrements de métadonnées stockées dans la base de données historiques 18 pour déterminer automatiquement comment un fichier de données de facture de fournisseur reçu a été traité et rapproché, sur la base des leçons apprises à partir des fichiers de base de données de facture de fournisseur traités et rapprochés antérieurement, à la fois manuellement et automatiquement par le système 10. Une boucle d’apprentissage automatique peut être implémentée par l’unité d’intelligence de rapprochement 17 pour améliorer la précision du système dans le rapprochement des factures.

Comme l’illustre la figure 8, la plateforme de rapprochement en réseau 15 peut être fournie avec un module de traitement de facture 20 qui peut être configuré pour traiter le fichier de données de facture 30 de façon à extraire les données de facture de fournisseur. Par exemple, le module de traitement de facture 20 peut extraire le premier et le second ensemble de données 30a et 30b à partir du fichier de données de facture de fournisseur 30. Le module de traitement de facture 20 peut être configuré pour déterminer, à partir du premier ensemble de données extrait 30a, les données d’éléments de facture de fournisseur (SU) correspondant à chacun des éléments de fournisseur, indiqués dans le fichier de données de facture 30. Le module de traitement de facture 20 peut par ailleurs, à partir du second ensemble de données de facture de fournisseur 30b, extraire les données de facture de fournisseur (SI) correspondant à l’information de la facture de fournisseur générique, comme expliqué précédemment. Le module de traitement de facture 20 peut par la suite stocker les données SI et les données SU extraites du fichier de données de facture 30 dans une première portion 32 et une seconde portion 31 de la base de données de facture de fournisseur 21. Comme l’illustre la figure 9, les données SI peuvent être stockées dans la seconde portion 31 de base de données sous la forme d’un enregistrement SI, SU, contenant un nombre de champs de donnée SI 31a, chaque champ contenant une valeur de donnée extraite de la facture de fournisseur illustrée dans la figure 3. Des exemples d’information pouvant être stockée dans les champs de donnée SI 31a peuvent inclure: le type de document, la devise, le fournisseur, l’adresse et les détails de contact du fournisseur et ainsi de suite. Comme l’illustre la figure 10, les données SU peuvent être stockées dans la première portion 32 de base de données sous la forme d’un enregistrement d’éléments de facture de fournisseur (SU), SII1-4. Dans l’exemple de la figure 10, la première portion de base de données 32 peut contenir quatre enregistrements SU, chaque enregistrement SU, SII1-4 étant stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée SU 32a, chaque champ étant configuré pour stocker une valeur de donnée SU extraite du fichier de données de facture 30 représenté dans la figure 3. Des exemples d’information pouvant être stockée dans les champs de donnée SU 32a peuvent inclure : un nombre SU, la description d’un élément de fournisseur extrait, la devise, le montant, la date de départ, le type de service, la commission, le type de chambre et ainsi de suite. Les éléments de facture de fournisseur (SU) peuvent inclure les informations qui ont été capturées directement à partir de la facture, les informations dérivées d’autres informations capturées dans la facture et les informations qui ont été calculées ou «devinées» par le système 10, telles que le prix HT (taxe sur la valeur ajoutée, TVA, exclue), le montant de la commission pour l’entité de réservation et ainsi de suite.

Comme l’illustre la figure 11, la plateforme de rapprochement peut par ailleurs être fournie avec un module de rapprochement 22 configuré pour sélectionner, en partie sur la base d’au moins un critère de rapprochement (RC) qui comprend au moins une valeur de rapprochement (RV), des enregistrements SI et ASI pour un rapprochement les uns avec les autres. Le critère ou les critères de rapprochement peuvent être sélectionnés à partir d’un critère de rapprochement (RC) stocké dans une base de données de critères de rapprochement 23. Par exemple, les critères de rapprochement (RC) peuvent être sélectionnâmes par l’utilisateur via une interface graphique d’utilisateur (GUI). Les critères de rapprochement (RC) peuvent être un ensemble de critères fixes, stockés avant le rapprochement par l’utilisateur ou l’administrateur du système. Autrement, ou de surcroît, les critères de rapprochement (RC) peuvent être générés par un outil de génération de critère de rapprochement 25 sur la base d’un ensemble de champs de donnée dans les tableaux SI et/ou SU qui correspondent aux champs de donnée du tableau ASI. Par ailleurs, l’outil de génération de critère de rapprochement 25 peut générer les critères de rapprochement à partir des champs de donnée identifiés comme des champs désignés de façon courante à la fois dans les tableaux SI/SII et dans les tableaux ASI. Des exemples de champs de donnée désignés de façon courante peuvent inclure : le type de chambre, le fournisseur/hôtel, la date d’arrivée et ainsi de suite. En outre, l’outil de génération de critères de rapprochement 25 peut générer une liste de critères de rapprochement sur la base des informations historiques stockées dans la base de données historiques 18 collectées à partir de processus de rapprochements antérieurs. Autrement, ou de surcroît, le module de rapprochement 22 peut sélectionner les enregistrements SU et ASI aux fins du rapprochement en parcourant simplement de façon hiérarchique les champs de donnée 14a et 31a de chaque base de données 14 et 31 et en comparant les valeurs de résultat pour identifier les enregistrements correspondants SU et ASI, SII1-4 et ASI1-6.

Comme l’illustre la figure 12, le module de rapprochement 22 peut être fourni avec un module de sélection d’éléments de rapprochement 33 configuré pour sélectionner les critères de rapprochement (RC) en identifiant les enregistrements SU et ASI correspondants aux fins du rapprochement. Un exemple d’un ensemble de critères de rapprochement RC1-3 pouvant être utilisé par le module de sélection d’éléments de rapprochement 33 est illustré dans la figure 13. Dans l’exemple illustré, trois critères de rapprochement RC1-3 ont été sélectionnés, p. ex., le fournisseur, la date d’arrivée et le type de chambre, chaque critère contenant trois valeurs de rapprochement RV1-3.

Le module de rapprochement 22 peut être fourni avec un module 34 d’identification SU et ASI configuré pour identifier et sélectionner, sur la base des critères de rapprochement sélectionnés RC1-3, les enregistrements SU et ASI, SII1-3 et ASM-6, aux fins du rapprochement. Le module 34 d’identification SU et ASI peut être configuré pour sélectionner les enregistrements SU and ASI, SII1-3 et ASI, ASM-6 aux fins du rapprochement en comparant ledit au moins une valeur de rapprochement RV1-3 aux valeurs stockées dans l’ensemble de champs de donnée SU 32a et des champs de donnée ASI 14a afin de trouver les enregistrements SU, SII1-3 et ASI,ASI1-6 correspondants. Le module 34 d’identification SU et ASI peut être configuré pour agréger les enregistrements appariés SU et ASI identifiés pour chacune des valeurs de critères de rapprochement RV1-3 sélectionnées, comme l’illustre la figure 14. Dans l’exemple illustré, pour la première combinaison de valeurs de critères de rapprochement RV1, le module 34 d’identification SU et ASI a identifié un enregistrement apparié SU, « 1 » et l’enregistrement SII1 correspondant dans la base de données SU 32 de la figure 10, ainsi que trois enregistrements ASI correspondants «ABDDEF/1, DEFGH/1 et GHIKL/1 » qui correspondent à ASM, ASI-4, et ASI-6 dans la base de données ASI 14 de la figure 6, tous ayant un champ de donnée FIID 14a d’une valeur « 1 ». Dans le même exemple, pour la troisième combinaison de valeur de critères de rapprochement RV3, le module 34 d’identification SU et ASI a identifié un enregistrement apparié SU, « 4 » et un enregistrement correspondant SI4 dans la base de données SU 32 de la figure 10, mais aucun enregistrement ASI correspondant n’a été trouvé dans la base de données ASI 14.

Comme l’illustre la figure 12, le module de rapprochement 22 peut être fourni avec un module agrégateur de valeurs SU et ASI 35 configuré pour agréger et stocker, pour chacune des valeurs de critères de rapprochement RV1-3 sélectionnée, les valeurs contenues dans les champs de donnée des enregistrements SU et ASI correspondants SII1-4 et ASM-6 identifiés par le module 34 d’identification SU et ASI. Les valeurs agrégées peuvent être stockées respectivement dans un ensemble de champs de donnée de rapprochement SU (SUR) 35a et de champs de donnée de rapprochement ASI (ASIR) 35b correspondants d’un enregistrement d’éléments de rapprochement (RI) 38, comme le montre la figure 15. L’enregistrement d’éléments de rapprochement (RI) 38 peut être généré par le module générateur d’enregistrement RI 37 du module de rapprochement 22 comme le montre la figure 12. Dans l’exemple illustré de la figure 15, pour RV1 les valeurs des enregistrements appariés SU (SU) identifiés et des enregistrements ASI (AS11, ASM et ASI6) indiquées dans la figure 14, sont agrégées dans des champs de donnée correspondants SUR et ASIR 35 a et 35b.

Les valeurs agrégées pour les enregistrements SU et ASI identifiés peuvent ensuite être comparées pour déterminer toutes les différences entre les montants indiqués. Par exemple, le module de rapprochement 22 peut être fourni avec un module de comparaison 36 pour comparer les valeurs agrégées SU et ASI des enregistrements appariés SU et ASI identifiés. Comme l’illustre la figure 16, les résultats de la comparaison peuvent être stockés dans un ensemble de champs de donnée de rapprochement 36a dudit au moins un enregistrement RI 38. Sur la base des résultats de la comparaison, il est possible d’extraire l’état du rapprochement indiquant que le rapprochement a été effectué avec succès (OK) ou qu’il a échoué (KO). L’état du rapprochement est stocké dans les champs de donnée d’état de rapprochement correspondants 36b de l’enregistrement RI 38, comme le montre la figure 16. Dans l’exemple illustré de la figure 16, pour la valeur de rapprochement RV1, la comparaison entre les valeurs agrégées ne donne aucune différence, p. ex. le montant total des ventes est à « 0 », ce qui signifie un rapprochement réussi, indiqué par l’état de rapprochement 36b «apparié OK». Par contre, pour la valeur de rapprochement RV3, la comparaison indique une différence de « 20,00 » pour le montant total des ventes ce qui signifie que le rapprochement a échoué, indiqué par l’état de rapprochement 36b « apparié KO ».

La figure 17 représente un exemple d’enregistrement d’éléments de rapprochement (RI) 38 devant être stockés dans la base de données d’enregistrement de rapprochement 24.

Selon des modes de réalisation de l’invention en question, le système de rapprochement de comptes 10 de l’invention en question peut générer un nombre de mesures de suivi sur la base des résultats ou de l’état du rapprochement. Par exemple après un rapprochement réussi, le système 10 de l’invention en question peut proposer un nombre de mesures de suivi à l’utilisateur via une interface graphique d’utilisateur d’un terminal d’utilisateur. Les mesures de suivi peuvent inclure : le rejet de la facture, l’acceptation de la facture, le rapport de facture, un suivi de commission et une refacturation. Le fait de fournir un nombre de mesures de suivi déterminées sur la base des résultats du rapprochement contribue à simplifier considérablement le processus de rapprochement pour l’utilisateur et à réduire par ailleurs le besoin en compétences requises de la part de l’utilisateur pour effectuer le rapprochement et le suivi des factures de fournisseurs. Cela permet de surmonter les problèmes des procédures traditionnelles de rapprochement pour lesquelles les mesures de suivi de rapprochement doivent être déterminées manuellement par l’utilisateur et exécutées en utilisant des modules de systèmes séparés, augmentant ainsi la complexité et le temps requis pour compléter le processus de rapprochement.

Le système 10 de l’invention en question peut par ailleurs être fourni avec un outil de génération de facture configuré pour générer une facture de fournisseur, également désignée comme facture «éphémère», directement à partir des enregistrements ASI stockés dans la base de données de vente réelle 14. La facture « éphémère » peut être présentée à l’utilisateur pour être éditée et traitée par ailleurs, sans qu’il soit nécessaire de saisir manuellement un fichier de facture séparé dans le système, ce qui simplifie considérablement le traitement d’une facture de fournisseur pour le rapprochement. De cette façon, il est possible de comparer aisément la facture de fournisseur « éphémère » avec la facture reçue, ce qui améliore considérablement la vitesse et la précision du processus de rapprochement. La sécurité du rapprochement peut être encore améliorée avec la génération de factures « éphémères, puisque seules les factures provenant de fournisseurs de confiance peuvent être générées aux fins du rapprochement à partir de la base de données ASI. Par ailleurs, une facture « éphémère » peut être utilisée pour supplémenter ou remplacer des factures de mauvaise qualité reçues pour un rapprochement. Par exemple, lorsque l’utilisateur reçoit une facture de fournisseur de qualité médiocre contenant un niveau d’information insuffisant pour effectuer le rapprochement, l’utilisateur peut générer une facture « éphémère » de façon à supplémenter l’information manquante, permettant ainsi au processus de rapprochement de poursuivre sans qu’il soit nécessaire de demander une information supplémentaire au fournisseur émetteur de la facture ou de rejeter la facture. Par ailleurs, dans certains cas, l’utilisateur peut décider de générer une facture de fournisseur pour des éléments achetés avant même que la facture réelle soit émise par le fournisseur. Pour des raisons fiscales, par exemple, l’utilisateur peut désirer payer tous les achats effectués pendant l’année fiscale avant de communiquer un rapport financier aux administrations fiscales.

Selon des modes de réalisation de l’invention en question, le système 10 peut être configuré pour optimiser la façon dont les données sont stockées et récupérées dans les différentes bases de données de façon à améliorer l’efficacité du matériel informatique utilisé pour implémenter le système. L’optimisation du stockage des données peut considérablement réduire le temps d’accès à la mémoire, les opérations de lecture/écriture de base de données, la puissance de calcul, et la charge de trafic de réseau. L’optimisation des ressources matérielles du système peut, par exemple, être atteinte en fournissant une représentation de valeur « clé » de tous les champs de donnée des bases de données respectives qui peut être stockée sous la forme d’un tableau de valeurs clés. Le tableau de valeurs clés peut contenir une collection d’enregistrements contenant des données, chaque enregistrement étant identifié de façon unique par une valeur « clé ». Ainsi, en utilisant des valeurs « clés », la recherche d’enregistrements correspondants peut être effectuée à un niveau plus élevé, ce qui réduit nettement le temps de réponse aux interrogations et la puissance de calcul requise. Autrement, ou de surcroît, les ressources matérielles du système peuvent être optimisées en dénormalisant les bases de données respectives et/ou en indexant les colonnes des tableaux SU et ASI qui s’y trouvent pour obtenir des champs de donnée courants basés sur des informations de métadonnées extraites de la base de données historiques. Par exemple, les tableaux indexés peuvent être fournis pour la plupart des combinaisons de champs de donnée représentant les critères correspondants pour identifier les enregistrements SU et ASI correspondants dans les bases de données respectives des systèmes. Les combinaisons les plus courantes de champs de donnée peuvent être déterminées soit directement par l’utilisateur, soit sur la base des informations historiques stockées dans la base de données historiques. La dénormalisation de base de données du système peut impliquer l’ajout de copies redondantes de données ou le groupement de données, entraînant une augmentation de la performance de lecture de la base de données, ce qui entraîne une amélioration non négligeable du temps de réponse aux interrogations.

Selon des modes de réalisation de l’invention en question, un procédé d’ordinateur 100 implémenté peut être fourni pour effectuer le rapprochement de comptes sur un réseau informatique, comme l’illustre la figure 18. Plus spécifiquement, le procédé peut être fourni avec un nombre d’étapes. Le procédé peut commencer à l’étape 101 en recevant un fichier de données de facture de fournisseur 30, p. ex., avec les moyens 16 pour recevoir un fichier de données de facture 30, comprenant au moins un premier ensemble de données de facture 30a qui comprend des informations relatives aux éléments achetés au fournisseur. Une base de données de vente réelle 14 peut être fournie comprenant au moins un enregistrement ASI ASI1-6 d’éléments de vente réelle qui comprend des données de vente réelle pour des éléments de fournisseur achetés à au moins un fournisseur ; ledit au moins un enregistrement ASI, ASI1-6, étant stocké sous la forme d’un tableau ASI comprenant un nombre de champs de donnée ASI 14a, chaque champ étant configuré pour stocker une valeur de donnée ASI dans un format prédéterminé de donnée. Une fois que le fichier de données de facture de fournisseur 30 est reçu, le rapprochement de la facture peut commencer par rapprocher les éléments de fournisseur indiqués dans le fichier de données de facture de fournisseur 30 avec des ASIs, ASI1-6, correspondants récupérés dans la base de données de vente réelle 14. Le rapprochement de la facture de fournisseur peut traiter le fichier de données de facture de fournisseur 30 dans un module de traitement de facture 20 de façon à extraire au moins un premier ensemble de données de facture 30a, comme indiqué dans l’étape 102. Le procédé continue à l’étape 104 en déterminant, à partir d’au moins un premier ensemble de données de facture 30a, des données SU d’éléments de facture de fournisseur correspondant à chacun des éléments de fournisseur indiqués dans le fichier de données de facture 30. Le procédé peut, à l’étape 104, stocker dans une première portion 31 d’une base de données de facture 21 chaque donnée SU extraite sous la forme d’un enregistrement SU, SII1-4 d’éléments de facture de fournisseur SU. Chaque enregistrement SU, SII1-4, est stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée d’éléments de facture de fournisseur SU 32a, chaque champ étant configuré pour stocker une valeur de donnée dans un format prédéterminé de donnée et pour extraire les données de facture de fournisseur du fichier de données de facture de fournisseur 30. Un critère de rapprochement RC1-3 comprenant au moins une valeur RV1-3 est reçu à l’étape 105. À l’étape 106, le procédé sélectionne des SIIs et ASIs pour le rapprochement, sur la base d’au moins un critère de rapprochement RC1-3. L’étape 106 peut, par ailleurs, comprendre l’étape de comparaison de ladite au moins une valeur de rapprochement RV1-3 aux valeurs stockées respectivement dans l’ensemble des champs de donnée SU 32a et ASI 14a des tableaux respectifs SU et ASI pour trouver des enregistrements SU et ASI correspondants. Pour chaque valeur de rapprochement RV1-3, l’étape de rapprochement peut par ailleurs comprendre les étapes d’agrégation des valeurs contenues dans les champs de donnée des enregistrements correspondants SU et ASI identifiés comme indiqué à l’étape 107 et le stockage des valeurs agrégées des enregistrements SU et ASI correspondants, respectivement, dans un ensemble de champs de rapprochement SU (SUR), et dans un ensemble de champs de rapprochement ASI (ASIR), d’un d’enregistrement RI d’éléments de rapprochement comme indiqué à l’étape 108. Les valeurs stockées dans les champs SUR sont comparées aux valeurs stockées dans les champs ASIR correspondants de l’enregistrement RI de façon à identifier toutes les différences comme indiqué à l’étape 109 et l’enregistrement RI est actualisé avec les résultats de la comparaison à l’étape 110.

Faisant maintenant référence à la figure 19, les plateformes, modules, unités, etc. décrits dans les présentes peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes, tels que le système informatique exemplaire 126. Le système informatique 126 peut comprendre un processeur 128, une mémoire 130, un dispositif de mémoire de masse 132, une interface entrée/sortie (I/O) 134, et une interface homme-machine (HMI) 136. Le système informatique 126 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes 138 par l'intermédiaire du réseau 122, ou d'une interface 1/0 134. Les ressources externes peuvent inclure, de façon non restrictive, des serveurs, des bases de données, des dispositifs de mémoire de masse, des dispositifs périphériques, des services de réseau cloud, ou toute autre ressource informatique appropriée qui peuvent être utilisés avec l'ordinateur 126.

Le processeur 128 peut inclure un ou plusieurs dispositifs sélectionnés: microprocesseurs, microcontrôleurs, processeurs de signal numérique, microordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basés sur des instructions de fonctionnement enregistrées dans la mémoire 130. La mémoire 130 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s’y limiter, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 132 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile, ou tout autre dispositif capable de stocker des informations.

Le processeur 128 peut fonctionner sous le contrôle d'un système d'exploitation 140 qui réside dans la mémoire 130. Le système d'exploitation 140 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, tels que l'application 142 qui réside dans la mémoire 130, puisse disposer d'instructions exécutées par le processeur 128. Dans un autre mode de réalisation alternatif, le processeur 128 peut exécuter l'application 142 directement et dans ce cas, le système d'exploitation 140 peut être omis. Une ou plusieurs structures de donnée 144 peuvent également résider dans la mémoire 130, et peuvent être utilisées par le processeur 128, le système d’exploitation 140 ou l’application 142 pour stocker ou manipuler des données. L'interface 1/0 134 peut fournir une interface machine qui couple le processeur 128 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 122 ou la ressource externe 138. Le serveur d'application 142 peut ainsi collaborer avec le réseau 22 (122) ou avec la ressource externe 138 en communiquant via l'interface 1/0 134 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l'invention. L'application 142 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources externes 138, ou autrement repose sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externe au système informatique 126. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement à l'ordinateur 126, distribuées à des ordinateurs multiples et à d'autres ressources externes 138, ou apportées par des ressources informatiques (matériel et logiciel) qui sont fournies comme services sur le réseau 122, par exemple un service d'informatique en nuage (cloud computing).

Le HMI 136 peut être couplé de façon fonctionnelle avec le processeur 128 du système informatique 126 d'une manière connue pour permettre à un utilisateur d'interagir directement avec système informatique 126. Le HMI 136 peut inclure un affichage vidéo ou une unité d'affichage à caractères, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 136 peut aussi inclure des dispositifs de saisie et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 128.

Une base de données 146 peut résider sur le dispositif de mémoire de masse 132, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 146 peut inclure des données et les structures de données qui les supportent pour stocker et organiser les données. En particulier, la base de données 146 peut-être arrangée selon toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, ou des combinaisons de celles-là. Un système de gestion de base de données sous forme de logiciel informatique d'application qui s'exécute sous la forme d'instructions sur le processeur 128 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 146 en réponse à une requête, lorsqu'une requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 140, les autres applications 142, ou un ou plusieurs modules.

En général, les routines exécutées pour mettre en œuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme «code de programme informatique» ou simplement «code de programme». Le code de programme comprend typiquement des instructions lisibles par ordinateur résidant à des moments divers dans des dispositifs divers de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, provoquent l'exécution par l'ordinateur d'opérations et/ou d’éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisibles par ordinateur pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple : le langage d'assemblage ou, un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation.

Divers codes de programme décrits dans les présentes peuvent être identifiés, selon l'application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature d'un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui sont résidents dans un ordinateur typique [par ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de programme (API), les applications, les petites applications (applets), etc.], on remarquera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique des fonctionnalités de programme telles qu'elles sont décrites dans les présentes.

Le code de programme mis en œuvre dans toute application/module décrit (e) dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur en amenant un processeur à exécuter des aspects des modes de réalisation de l'invention.

Les supports de stockage de données lisibles par ordinateur et qui sont intrinsèquement durables, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, implémentés dans toute méthode ou technologie de stockage de données, telles que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre une mémoire à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture seule programmable et effaçable (EPROM), une mémoire à lecture seule, programmable et effaçable électriquement (EEPROM), une mémoire flash ou toute technologie de support solide de mémoire, un disque compact portable doté d'une mémoire à lecture seule (CD-ROM) ou tout autre stockage optique, bandes d'enregistrement magnétique, une mémoire à disque magnétique ou tout autre médium pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (p. ex., des ondes radio ou toutes autres ondes électromagnétiques se propageant à travers un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau.

Les instructions de programme lisibles par ordinateur, stockées dans un support lisible par ordinateur, peuvent être utilisées pour instruire un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs pour fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies par un ou plusieurs processeurs sur un ordinateur à usage général, un ordinateur à usage spécial, ou tout autre appareil programmable de traitement de données pour produire une machine telle que les instructions qui s'exécutent par l'intermédiaire d'un ou de plusieurs processeurs provoquent une série de calculs devant être effectués pour implémenter les fonctions, actions et/opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.

Dans certains modes de réalisation alternatifs, les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagramme séquentiel et/ou diagrammes blocs peuvent inclure plus ou moins de blocs que ceux qui sont illustrés tout en restant conformes avec les modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l'invention.

La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n'est pas destinée à limiter les modes de réalisation de l'invention. On comprendra par ailleurs que les formes verbales du verbe «comprendre», «comprend» et/ou «comprenant», lorsqu’elles sont utilisées dans cette spécification, précisent la présence de caractéristiques, de nombres entiers, d’étapes, d’opérations, d’éléments, et/ou de composants, mais n’excluent pas la présence ou l’ajout d’un ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes, en cela. De plus, dans la mesure où les verbes « inclure », « ayant », « a », « avec », « composé de » ou des variantes de ceux-là, sont utilisés dans la description détaillée et les revendications, ces termes sont censés être inclusifs de façon similaire à la forme verbale « comprenant ».

Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n'est pas de l'intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L'invention sous un angle plus large n'est donc pas limitée aux détails spécifiques, aux procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d'exemple. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général de l'appliquant.

Claims

Revendications

1. Un système (10) pour effectuer des rapprochements de comptes sur un réseau informatique, le système comprenant : des moyens (16) pour la réception d’un fichier de données de facture d’un fournisseur (30) comprenant au moins un premier ensemble de données de facture (30a) comprenant des informations sur les éléments de fournisseur achetés au fournisseur ; une base de données de vente réelle (14) comprenant au moins un enregistrement d’élément de vente réelle, ASI (ASM-6) comprenant des données de vente réelle pour les éléments de fournisseur achetés à au moins un fournisseur, ledit au moins un enregistrement ASI (ASM-6) est stocké sous la forme d’un tableau ASI comprenant un nombre de champs de donnée ASI (14a), chaque champ étant configuré pour stocker une valeur de donnée ASI dans un format prédéterminé de donnée, et une plateforme de rapprochement en réseau (15) opérationnelle avec les moyens (16) pour recevoir le fichier de données de facture de fournisseur (30) et, avec la base de données de vente réelle (14), pour rapprocher les éléments de fournisseur indiqués dans le fichier de données de facture de fournisseur (30) avec les enregistrements correspondants ASI (ASM-6) récupérés dans la base de données de vente réelle (14). dans lequel la plateforme de rapprochement en réseau (15) comprend un module de traitement de facture (20) configuré pour le traitement d’un fichier de données de facture de fournisseur (30) de façon à extraire au moins le premier ensemble de données de facture (30a), pour déterminer à partir du premier ensemble de données de facture (30a) les données d’élément de facture de fournisseur, SU, correspondant à chacun des éléments de fournisseur indiqués dans le fichier de données de facture (30), et stocker dans une première portion (31) d’une base de données de facture de fournisseur (21) chaque donnée SU extraite sous la forme d’un enregistrement d’éléments de facture de fournisseur SU (SII1-4), chaque enregistrement SU (SI 11-4) étant stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée SU (32a), chaque champ étant configuré pour stocker une valeur de donnée SU dans un format prédéterminé de donnée, et un module de rapprochement de facture (22) configuré pour sélectionner aux fins d’un rapprochement, sur la base d’au moins un critère de rapprochement (RC1-3) comprenant au moins une valeur de rapprochement (RV1-3), au moins un enregistrement SI (SII1-4) de la base de données de facture de fournisseur (21) et au moins un enregistrement ASI (ASI1-6) de la base de données de vente réelle (14), dans lequel le module de rapprochement (22) est configuré pour sélectionner les enregistrements SU et ASI aux fins du rapprochement en comparant les valeurs de chaque critère de rapprochement (RC1-3) aux valeurs de données stockées dans les champs de donnée SU (32a) et dans les champs de donnée ASI (14a) correspondants des tableaux SU et ASI respectivement afin d’identifier les enregistrements correspondants SU (SI 11-4) et les enregistrements correspondants ASI (ASI1-6) qui se correspondent. dans lequel, pour chaque valeur de rapprochement, ou pour chaque combinaison de valeurs de rapprochement (RV1-3), le module de rapprochement de facture (22) est configuré pour agréger et stocker les valeurs récupérées dans les champs de donnée (14a, 32a) des enregistrements correspondants SU (SII1-4) et ASI (ASI1-6) identifiés dans respectivement un ensemble de champs de donnée de rapprochement SU, SUR, (35a) et un ensemble de champs de données de rapprochement ASI, ASIR (35b) correspondants d’au moins un enregistrement (38) d’éléments de rapprochement (RI), l’enregistrement d’éléments de rapprochement étant stocké dans une base de données d’enregistrement de rapprochement (24), sous la forme d’au moins un tableau d’éléments de rapprochement, RI. le module de rapprochement étant par ailleurs configuré pour rapprocher les enregistrements appariés SU (SII1-4) identifiés avec les enregistrements appariés ASI (ASI1-6) qui leur correspondent en comparant les valeurs stockées dans les champs SUR (35a) aux valeurs stockées dans les champs ASIR (35b) correspondants d’au moins un enregistrement RI (38) de façon à identifier toutes les différences, et pour stocker les valeurs de la comparaison dans un ensemble de champs de donnée de rapprochement (36a) d’au moins un enregistrement RI (38), et pour actualiser l’enregistrement RI (38) via un état de rapprochement (36b) indiquant l’état du rapprochement.
2. Un système (10) selon la revendication 1, dans lequel le module de traitement de facture (20) est configuré pour déterminer, à partir des données de facture de fournisseur extraites, un second ensemble de données (30b) comprenant des données de facture de fournisseur (SI) génériques comprenant une information pour identifier le fournisseur de la facture, et dans lequel le module de traitement de facture (20) est configuré pour stocker au moins une portion des secondes données (30b) dans une seconde portion (32) de la base de données de facture de fournisseur (21) sous la forme d’un enregistrement de facture de fournisseur (SI) (SU) dans un tableau SI comprenant un ensemble de champs de donnée SI (31a).
3. Un système (10) selon la revendication 2, dans lequel le module de rapprochement (22) est configuré pour sélectionner les Slls et les ASIs (SII1-4, ASM-6) aux fins du rapprochement sur la base de la combinaison d’une pluralité de critères de rapprochement (RC1-3).
4. Un système (10) selon la revendications, dans lequel la plateforme de rapprochement en réseau (15) comprend un outil de génération de critère de rapprochement (25) configuré pour générer la pluralité de critères de rapprochement (RC1-3) à partir d’un ensemble de champs de donnée (32a, 31a) sélectionnés dans les tableaux SI et/ou SU qui correspondent aux champs de donnée (14a) du tableau ASI.
5. Un système (10) selon l’une quelconque des revendications précédentes, dans lequel la plateforme de rapprochement en réseau (15) est configurée pour générer, sur la base des résultats du rapprochement, un nombre de mesures de suivi via une interface graphique d’utilisateur d’un terminal d’utilisateur (11) sélectionnées dans le groupe consistant au moins de : rejet ou acceptation de la facture de fournisseur, rapport de facture, suivi de la commission, et refacturation .
6. Un système (10) selon l’une quelconque des revendications précédentes, dans lequel la plateforme de rapprochement en réseau (15). comprend une unité d’intelligence de rapprochement (17) agencée pour collecter des métadonnées de facture de fournisseur correspondant aux mesures prises et aux modifications effectuées sur les données durant le traitement et le rapprochement du fichier de données de facture de fournisseur.
7. Un système (10) selon la revendication 6, dans lequel l’unité d’intelligence de rapprochement (17) est configurée pour stocker les métadonnées de facture de fournisseur dans une base de données historiques de serveur (18).
8. Un système (10) selon la revendication 7, dans lequel le module de traitement de facture (20) est configuré pour enrichir les enregistrements SI et SU (SU, SII1-4) stockés dans la base de données de facture de fournisseur (21) avec les métadonnées récupérées dans la base de données historiques (18).
9. Un système (10) selon l’une quelconque des revendications précédentes, dans lequel le système (10) est en communication directe avec une plateforme de ventes en réseau comprenant une base de données (12) d’élément financier (Fl) contenant un nombre d’enregistrements (FI1-6), chaque enregistrement comprenant une donnée d’élément financier (Fl) relative à une information de vente réelle enregistrée au moment de l’achat de chaque élément de fournisseur.
10. Un système (10) selon la revendication 9, dans lequel le système (10) comprend un gestionnaire de base de données (19) configuré pour traiter et transformer les enregistrements Fl (FI1-6) de la base de données Fl (12) de façon à générer des enregistrements ASI (ASI1-6) correspondants devant être stockés dans la base de données de vente réelle (14).
11. Un système (10) selon la revendication 10, dans lequel le gestionnaire de base de données (19) est configuré pour effectuer au moins une des mesures suivantes : extraire un sous-ensemble des données Fl correspondant aux champs de donnée (14a) du tableau ASI devant être remplis ; convertir le format du sous-ensemble de données Fl extrait au format de la base de données de vente réelle (14), de préférence en convertissant les montants dans une devise locale ; harmoniser le sous-ensemble de données Fl extrait avec les données stockées dans les champs de donnée SU (32a) de la base de données de facture de fournisseur (21); étiqueter le sous-ensemble de données Fl extrait selon un système d’étiquetage des champs de donnée SU de la base de données de facture de fournisseur (21) ; enrichir le sous-ensemble de données Fl avec des métadonnées extraites de la base de données historiques (18).
12. Un système (10) selon les revendications 10 ou 11, dans lequel le gestionnaire de base de données (19) est configuré pour surveiller l’état des données Fl stockées dans la base de données Fl (12) pour tout changement et pour actualiser de façon pertinente des enregistrements ASI (ASI1-6) correspondants, stockés dans la base de données de vente réelle (14).
13. Un système (10) selon l’une quelconque des revendications précédentes, dans lequel le système comprend un outil de génération de facture configuré pour générer une facture de fournisseur directement à partir des données stockées dans les enregistrements ASI (ASI1-6) stockés dans la base de données de vente réelle (14).
14. Un système (10) selon l’une quelconque des revendications précédentes, dans lequel le module de traitement de facture (20), le module de rapprochement (22) et le gestionnaire de base de données (19) sont configurés pour manipuler les données devant être stockées dans les bases de données respectives (14, 21, 24) en attribuant des valeurs clés aux champs de donnée génériques d’un tableau, en dénormalisant les bases de données respectives et en indexant les colonnes des tableaux sur des champs de donnée courants basés sur des métadonnées extraites de la base de données historiques (18).
15. Un procédé implémenté par un ordinateur (100) pour effectuer un rapprochement de comptes sur un réseau informatique, le procédé comprenant les étapes suivantes : la réception au moyen (16) d’un fichier de données de facture de fournisseur (30) comprenant au moins un premier ensemble de données de facture (30a) comprenant les informations relatives aux éléments de fournisseur achetés au fournisseur, l’apport d’une base de données de vente réelle (14) comprenant au moins un enregistrement d’éléments de vente réelle, un enregistrement ASI (ASI1-6), comprenant des données de vente réelle pour des éléments de achetés à au moins un fournisseur, ledit au moins un enregistrement ASI (AS11 -6) étant stocké sous la forme d’un tableau ASI comprenant un nombre de champs de donnée ASI (14a), chaque champ étant configuré pour stocker une valeur de donnée ASI sous un format de donnée prédéterminé, et le rapprochement des éléments de fournisseur indiqués dans le fichier de données de facture de fournisseur (30) avec les ASIs (ASI1-6) récupérés dans la base de données de vente réelle (14), dans lequel l’étape de rapprochement comprend les étapes suivantes : le traitement par le module de traitement de facture (20) du fichier de données de facture de fournisseur (30) de façon à extraire au moins un premier ensemble de données de facture (30a), la détermination par le module de traitement de facture (20), à partir du premier ensemble de données de facture (30a) de données d’éléments de facture de fournisseur SU qui correspondent à chacun des éléments de fournisseur indiqués dans le fichier de données de facture (30), le stockage dans une première portion (31) d’une base de données de facture de fournisseur (21) de chaque donnée SU extraite sous la forme d’un enregistrement d’éléments de facture de fournisseur SU, (SII1-4), chaque enregistrement SU (SII1-4) étant stocké sous la forme d’un tableau SU comprenant un ensemble de champs de donnée SU (32a), chaque champ étant configuré pour stocker une valeur de donnée SU sous un format prédéterminé de donnée, et l’extraction des données de facture de fournisseur à partir du fichier de données de facture de fournisseur (30), la sélection au moyen d’un module de rapprochement (22), sur la base d’au moins un critère de rapprochement (RC1-3) comprenant au moins une valeur de rapprochement (RV1-3), au moins un enregistrement SU (SII1-4) de la base de données SU (21) et au moins un enregistrement ASI (ASM-6) correspondant de la base de données de vente réelle (14). dans lequel l’étape de sélection des enregistrements SU et ASI aux fins du rapprochement comprend l’étape de comparaison des valeurs de chaque critère de rapprochement (RC1-3) aux valeurs des données stockées dans l’ensemble de champs de donnée (32a) et des champs de donnée ASI (14a) correspondants des tableaux SU et ASI respectivement afin d’identifier les enregistrements correspondants SU (SI 11-4) et les enregistrements correspondants ASI (ASI1-6) qui se correspondent. dans lequel, pour chaque valeur de rapprochement ou chaque combinaison de valeurs de rapprochement (RV1-3), l’étape de rapprochement comprend par ailleurs les étapes suivantes : l’agrégation et le stockage des valeurs récupérées, à partir des champs de donnée (14a, 32a) des enregistrements SU et ASI correspondants (SII1-4) et (ASM-6) identifiés, respectivement dans un ensemble de champs de donnée de rapprochement SU, SUR (35a), et un ensemble les champs de donnée de rapprochement ASI, ASIR (35b) correspondants, d’au moins un enregistrement (38) d’éléments de rapprochement (RI), l’enregistrement d’éléments de rapprochement étant stocké dans une base de données d’enregistrement de rapprochement (24) sous la forme d’au moins un tableau d’éléments de rapprochement, RI, le rapprochement des enregistrements appariés SU (SII1-4) identifiés avec les enregistrements appariés ASI (ASM-6) qui leur correspondent en comparant les valeurs stockées dans les champs SUR (35a) avec les valeurs stockées dans les champs correspondants ASIR (35b) d’au moins un enregistrement RI (38) de façon à identifier toutes les différences, le stockage des valeurs de la comparaison dans un ensemble de champs de donnée de rapprochement (36a) d’au moins ledit enregistrement RI (38), et la mise à jour de l’enregistrement RI (38) via un état de rapprochement (36b) indiquant l’état du rapprochement.