FR3061337A1 - Moteur de regles universel et optimise pour le traitement de documents de gestion - Google Patents
Moteur de regles universel et optimise pour le traitement de documents de gestion Download PDFInfo
- Publication number
- FR3061337A1 FR3061337A1 FR1663314A FR1663314A FR3061337A1 FR 3061337 A1 FR3061337 A1 FR 3061337A1 FR 1663314 A FR1663314 A FR 1663314A FR 1663314 A FR1663314 A FR 1663314A FR 3061337 A1 FR3061337 A1 FR 3061337A1
- Authority
- FR
- France
- Prior art keywords
- rule
- rules
- database
- data
- management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
Abstract
L'invention concerne un système pour l'analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de règles (110) adapté - pour récupérer des règles à partir d'une base de règles (120) selon un ordonnancement qui est fonction de métadonnées associées auxdites règles, - pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, comparer ledit résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, exécuter une action associée à ladite règle.
Description
Titulaire(s) :
DHATIM Société par actions simplifiée.
O Demande(s) d’extension :
® Mandataire(s) : NOVAGRAAF TECHNOLOGIES.
® MOTEUR DE REGLES UNIVERSEL ET OPTIMISE POUR LE TRAITEMENT DE DOCUMENTS DE GESTION
FR 3 061 337 - A1 (® L'invention concerne un système pour l'analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de règles (110) adapté
- pour récupérer des règles à partir d'une base de règles (120) selon un ordonnancement qui est fonction de métadonnées associées auxdites règles,
- pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, comparer ledit résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, exécuter une action associée à ladite règle.
| ! R j | |||
| 141] | |||
| '140 | |||
| ; -j-iw | i | R | |
| ip. j r | t 'l60 | 1/130 | 150 |
| MS02 | 110 | 120 | |
| ; 103! L. | 170 |
MOTEUR DE REGLES UNIVERSEL ET OPTIMISE POUR LE TRAITEMENT DE DOCUMENTS DE GESTION
DOMAINE DE L’INVENTION
L'invention concerne le domaine de l’analyse automatique de documents de gestion au sein d’une entreprise. Elle s’applique particulièrement bien à l’analyse automatique de factures, notamment à des fins de contrôle de cohérence ou de classification.
CONTEXTE DE L’INVENTION
Les entreprises ont à gérer un nombre très important de documents de gestion. Ces documents « de gestion » regroupent l’ensemble des documents relatifs à la gestion d’une entreprise, et que l’on peut donc distinguer des documents purement métiers et relatifs à l’activité de l’entreprise. Cela comprend notamment les factures, les relevés de consommation, les fiches de paie, la gestion des commandes, des documents comptables, etc.
Dans une entreprise de taille importante, le volume de ces documents est tel qu’il est dès lors impossible de procéder à un contrôle manuel de ces documents.
Pourtant la problématique de l’analyse des documents de gestion est extrêmement importante pour les entreprises. Des incohérences peuvent en effet entraîner des risques légaux, notamment du fait des règlements comptables et fiscaux. On peut par exemple citer les erreurs sur les cotisations versées aux différentes caisses que l’analyse des feuilles de paie peut permettre de détecter. On peut également citer, parmi de nombreux autres exemples, les erreurs sur les taux de TVA dans les factures.
Une autre conséquence de ces incohérences est d’entraîner le paiement de sommes indues par exemple, si les montants figurants sur des factures sont erronés.
En outre les documents de gestions sont de natures très variées, et correspondent à des types d’analyse également très variées. Chaque type documents de gestion fait donc appel à des expertises spécifiques, de sorte que les outils informatiques permettant l’automatisation de l’analyse sont, très généralement, dédiés à un type de documents, et utilisés par un corps de métier (comptabilité, service paie, direction des achats, etc.)
Il n’existe donc pas d’outils universels, c’est-à-dire à même de s’adapté à tout type de documents de gestion.
Compte tenu du volume important de données à traiter, un tel outil doit atteindre des performances élevées afin d’être utilisable. Il doit également proposer une adaptation au fonctionnement de l’entreprise afin de prendre en compte les spécificités de son activité et des processus internes.
Il n’existe en outre pas d’outils généralistes visant à optimiser les dépenses de l’entreprise, en procédant à l’analyse des documents de gestion.
L'invention vise à proposer une solution alternative permettant l’analyse de tout type de documents de gestion, afin d’optimiser les dépenses d’une entreprise, et avec des performances permettant de traiter un très grand nombre de documents en un temps très court. Elle vise en outre l’optimisation des dépenses de l’entreprise utilisatrice, en permettant une meilleure analyse des documents de gestion, notamment par l’utilisation de règles personnalisables et adaptables au métier de l’entreprise et à son fonctionnement par un expert du domaine concerné.
RESUME DE L’INVENTION
Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités.
A cette fin, la présente invention propose un procédé pour l’analyse de documents de gestion relatifs à une entreprise, lesdits documents de gestion étant stockés dans une base de données relationnelle sous la forme d’un ensemble de données, le procédé comportant :
- la récupération de règles à partir d'une base de règles, par un moteur de règles, puis,
- de façon itérative, pour chacune desdites règles, la transmission par ledit moteur de règles d'au moins une requête associée à ladite règle vers un système de gestion de ladite base de données, la comparaison du résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, l'exécution d'une action associée à ladite règle.
Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles :
les règles sont générées à partir d'un langage haut-niveau ;
les règles récupérées sont transformés en requêtes exprimés selon ledit système de gestion en utilisant le schéma de ladite base de données ;
lesdites requêtes transformées sont exprimées en SQL ou PL/SQL et exécutée dans ledit système de gestion de données ;
lesdits documents de gestion sont des factures et lesdites actions sont prévues pour vérifier la cohérence des données dudit ensemble ;
- ladite action peut alimenter une base de résultat, fonctionnellement distincte de ladite base de données
- ladite action peut déclencher l’exécution d’une fonction par un dispositif extérieur audit moteur de recherche ;
- ladite base de règles est un entrepôt de règles.
Un autre objet de l’invention est un produit logiciel comportant des instructions exécutables par une plateforme de traitement de l’information pour mettre en œuvre le procédé tel que précédemment décrit.
Un autre objet de l’invention concerne un système pour l’analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de règles adapté
- pour récupérer des règles à partir d'une base de règles selon un ordonnancement qui est fonction de métadonnées associées auxdites règles,
- pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion de ladite base de données, comparer ledit résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, exécuter une action associée à ladite règle.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.
BREVE DESCRIPTION DES DESSINS
La figure 1 représente schématiquement une architecture fonctionnelle selon un mode de réalisation de l’invention.
La figure 2 représente schématiquement un organigramme d’un procédé selon un mode de réalisation de l’invention.
La figure 3 représente un exemple de schéma d’une base de règles selon un mode de réalisation de l’invention.
DESCRIPTION DETAILLEE DE L’INVENTION
L’invention repose sur une base de données contenant des données issues de documents de gestion. Comme il a été évoqué en introduction, ces documents de gestion peuvent être de différentes natures : factures, documents de paie, de consommation, relevés de compteurs, etc. Toutes sortent de données traités dans la vie d’une entreprise peuvent être considérés et entrer dans ce cadre de « documents de gestion ».
Le contenu de la base de données peut être constitué de différentes façons. Par exemple, il peut être transféré depuis une base de données du client, ou bien importé via des fichiers au format CSV (pour « CommaSeparated Values», en langue anglaise). D’autres mécanismes de « population » de la base à partir de documents de gestion numérisés sont bien évidemment possibles et accessibles à l’homme du métier.
Par ailleurs, il est possible de construire la base à partir de documents de gestion au format papier et de les numériser. Une phase de prétraitement peut alors être mise en œuvre pour numériser ses documents et pour en analyser le contenu afin de structurer l’information contenue dans ces documents de gestion.
Ce prétraitement peut utiliser les techniques existantes de reconnaissance optique de caractères ou OCR, pour « Optical Character
Récognition » en langue anglaise. Une mise en œuvre de l’invention peut se baser sur un module logiciel implémentant une telle technique, et fournissant un ensemble de documents numériques, chacun représentant un document de gestion.
Le prétraitement peut également comporter une sous-étape de correction et de structuration de ces documents numériques. En effet, les différentes techniques de reconnaissance optique de caractères sont imparfaites et produisent des erreurs en reconnaissance. Il est alors possible de tirer profit de la sémantique et du formalisme des documents de gestion.
Par exemple, si le document de gestion est une facture, le système sait qu’une facture répond à un certain formalisme et possède une certaine structure. En utilisant ces informations, il est donc possible de détecter et de corriger certaines erreurs en reconnaissance de caractères. Par exemple, si on reconnaît qu’une information représente un prix, on peut en déduire qu’elle est formée de chiffre et éventuellement d’un symbole d’une monnaie. Cette information permet d’aiguiller la correction d’une erreur en reconnaissance sur un caractère de ce champ.
D’une façon générale, les factures contiennent des informations correspondant à une structure attendue : on sait qu’une facture doit contenir une adresse d’émetteur, une adresse de facturation, une date, un numéro de facture, un total facturé, un taux de TVA, etc. On sait aussi qu’une facture contient un élément facturé par ligne.
Toutes ces informations, à la fois sémantiques et de forme, peuvent non seulement guider la correction des erreurs, mais aussi peuvent servir à structurer les données correspondant à une facture numérique.
En outre, les factures sont des documents dans lesquels l’information est structurée selon une hiérarchie des données. Par exemple, il est possible de définir une hiérarchie correspondant aux prix figurants dans une facture : chaque élément facturé représente le niveau inférieur de la hiérarchie, tandis que le total facturé représente le niveau haut ; des sous-totaux peuvent représenter des niveaux intermédiaires.
Le prétraitement peut consister à utiliser une connaissance du type d’information attendue dans une facture pour construire une structure de données, voire pour construire une structure hiérarchique des données.
Une étape de lemmatisation peut également être mise en place afin de détecter les racines des mots et de comparer plusieurs variances lexicales à partir de ces racines pour les informations textuelles comme le titre, l’objet, les libellés des factures, etc.
Ce prétraitement ne représente qu’un mode de réalisation possible pour construire le contenu de la base de données des documents de gestion et l’invention est donc indépendante de la présence ou non de ce prétraitement et de la façon dont est construit le contenu de la base de données. L’invention se base en effet sur une base de données constituée et peut être adaptée à tout type de formats et de schéma de cette base de données. Dans le cadre de l’invention, il est uniquement supposé qu’elle soit suffisamment structurée pour permettre l’application de règle.
La figure 1 schématise de façon fonctionnelle et haut niveau une architecture possible d’un système selon l’invention.
La structure de données représentant les documents de gestion est stockée dans une base de données relationnelle, référencée 100 sur cette figure 1.
De façon connue en soi, cette base de données 100, nommée base de travail ODS (pour « Operational Data Store » en anglais), peut être mise en œuvre par une structure 101, sous la forme d’un ensemble de tables pouvant être liées les unes aux autres via des clés, dans lequel est stockée la structure de données, et qui est associé à un système de gestion 102 permettant d’assurer l’interface entre le contenu de la base et le monde extérieur.
Ce système de gestion 102 reçoit typiquement en entrée des requêtes qui sont, assez généralement, décrite en langage SQL (« Structured Query
Language ») ou en une de ses variantes.
Classiquement, un système de gestion de base de données 102 (SGBD ou DBMS pour « Database Management System) comporte un processeur de requêtes pour recevoir et exécuter ces requêtes sur le contenu 101 de la base de données.
L'exécution de la requête sur les données stockées dans la base génère en général des données de résultat. Ce résultat peut alors être retourné à l'émetteur de la requête.
Le système de gestion 102, et notamment le processeur de requêtes, est intiment lié à la structure même de la mémoire 101. Il interprète les requêtes (SQL ou autres) et les exécute en tirant profit de la connaissance qu'il possède de la structure de la base, de sorte à ce que l'interaction entre le système de gestion et la base elle-même soit optimisée.
Une structure distincte 170 permet de stocker les résultats, tel qu’il sera décrit plus loin.
La base de données 101 possède en général un schéma 103 qui décrit les métadonnées de sa base : les noms des tables, les colonnes, les relations entre elles. Ce schéma est récupérable par un mécanisme de rétro-ingénierie (ou « reverse engineering » en langue anglaise). Cette information de schéma peut permettre au moteur de règles de construire correctement les requêtes, SQL ou autres, ainsi qu’il sera vu plus loin.
Selon l'invention, une base de règles 120 permet de stocker un ensemble de règles à appliquer sur les données représentatives des documents de gestion stockées dans la base 100. Ces règles visent à analyser ces données afin de les classifier ou d'en vérifier la cohérence.
La base de règles 120, nommée entrepôt de règles (ou « Rule Store » en anglais) peut être mise en œuvre en utilisant l’API appropriée. Cette notion d’entrepôt de règles est connue en soi et est notamment décrite dans le brevet US7356522 ou dans la demande de brevet US20090171903.
Les règles peuvent être en partie des règles prédéfinies et communes au traitement de tout document de gestion d'un même type. Mais d'autres règles peuvent être plus spécifiques à des documents de gestion particuliers traités par l'entreprise, ou aux modes de fonctionnement de cette entreprise.
Par exemple dans le cadre du contrôle de cohérence de factures, des règles peuvent concerner:
- la cohérence mathématique de chaque facture. Il s'agit de vérifier que la somme des éléments facturés correspond bien au total de la facture, ou que le produit d'un prix unitaire multiplié par la quantité correspond bien au montant total par ligne. Il peut aussi s'agir de vérifier qu'une même mention est présente sur l'ensemble des factures d'une même série (pour détecter une erreur dans un numéro de référence ou de bon de commande, par exemple). Dans ce même cadre d'une série de factures, il peut aussi s'agir de vérifier qu'il n'y a pas d'incohérence entre des périodes de facture d'une facture à l'autre ;
- la détection d'anomalies comme des informations manquantes ou bien possiblement erronées par rapport à un gabarit d'informations attendues. Il peut par exemple s'agir d'un taux de TVA erroné, voire manquant, d'un rabais annuel non-appliqué, de l'absence d'un élément de facturation attendu... Il est également possible de définir des règles pour comparer des montants facturés par rapport à des moyennes et d'ainsi détecter des dépassements importants par rapport à une moyenne ;
- le respect de la législation. Selon les lois applicables, des mentions particulières doivent obligatoirement apparaître sur une facture, notamment la date d'émission, un numéro de référence, l'identité des parties, etc. Des règles peuvent être prévues pour vérifier la présence de ces mentions et leur conformité à la législation ;
- le respect d'un catalogue de tarification. Il peut en effet être possible de définir des règles pour comparer les montants indiqués dans les factures avec des catalogues de prix et de déterminer des incohérences.
ίο
Il ressort de ces exemples qu'il existe une grande variété de règles possibles, et que certaines ne peuvent être définies que par l'utilisateur. Un des avantages de l’invention réside justement dans la possibilité pour les utilisateurs de définir ou d’adapter leurs propres règles.
Des outils peuvent être prévus pour faciliter la définition de ces règles, et notamment par des personnes qui ne sont pas des spécialistes en informatique et/ou en gestion de base de données. Il est important, en effet, que l'outil puisse permettre à des personnes responsables de la comptabilité de l'entreprise de rédiger leurs propres règles en fonction des contrôles qu'elles veulent effectuer sur les documents de gestion, factures ou autres.
Aussi, un outil de conversion 130 peut être prévu afin de générer des règles exploitables par un moteur de règles 110. Ces règles générées peuvent être exprimés dans un langage de type DSL («Domain Spécifie Language ») intitulé DRDL (« Dhatim Rule Définition Language »). Les languages DSL sont par exemple explicité dans l’encyclopédie participative en-ligne wikipedia :
https://en.wikipedia.org/wiki/Domain-specific_language
L’outil de conversion 130 peut convertir des règles issues d’une base tierce 150, qui peut notamment être un catalogue de règles disponibles. En pratique, ce catalogue peut être mis en œuvre par une même base que la base de règles 120, mais les deux sont fonctionnellement séparées.
L’outil de conversion peut également convertir des règles exprimées en un langage de haut niveau, notamment au travers d’une interface hommemachine 140.
Les deux mécanismes peuvent avantageusement être combinés. Sur l’organigramme de la figure 2, on voit que dans un premier temps des règles peuvent être importées, 210, depuis la base tierce 150 vers la base de règles, puis celles-ci peuvent être éditées, 211, au moyen de l’interface homme3061337 machine 140 et réintroduites, sous une forme adaptée, dans la base de règles 120. Cette interface homme-machine 140 est classiquement appelée environnement de développement intégré (ou IDE pour « Integrated Development Environment » en anglais).
Le langage de haut-niveau peut être du langage naturel ou seminaturel. Il peut également s’agir d’un langage visuel. Une interface graphique 141 peut être proposée au sein de l’interface homme-machine 140 du système de l’invention, pour permettre aux utilisateurs de définir leurs règles.
Il est possible de mettre en place des mécanismes d’auto-complétion qui consiste à proposer un mot ou une séquence de mots à l’utilisateur, lorsque celui-ci saisit les premiers caractères d’un mot.
Ces suggestions peuvent se baser sur un dictionnaire standard mais aussi sur le schéma 103 de la base de données 100. Le contenu des données de gestion (factures...) peut ainsi fournir un vocabulaire lexicographique qui peut être ainsi proposé à l’utilisateur via l’interface 140, 141 afin d’adapter plus facilement ses règles au contenu des données à traiter. Ce vocabulaire peut être utilisé tel quel dans la définition des règles ou bien être surchargé selon l’application.
En outre dans le cadre de la fonction d’auto-complétion, ce vocabulaire peut être présenté à l’utilisateur par d’autres moyens, par exemple en affichant une liste des mots ou expressions les plus représentées dans la base sur l’interface 140.
Ces règles exprimées dans un langage haut-niveau peuvent alors être converties pour générer des règles utilisables par un moteur de règle 110.
Ainsi, le système est universel et peut s’adapter à n’importe quelle base de données de travail et est indépendant de cette base 100. Moyennant l’adaptation de l’outil de conversion 130, il peut être déployé sur tout type de base de données relationnelle 100.
Dans certains cas complexes, le moteur de règles peut disposer d’un mécanisme de description pour guider la génération de bonnes requêtes SQL dans ces bases de travail : par exemple jointure de deux tables n’ayant pas de liens directs, résolution de conflits en cas d’ambiguïté d’un même nom de colonnes présent dans plusieurs tables, navigation entre les données pour certains opérateurs particuliers de règles, etc.
La notion de moteur de règles est connue en soi. A titre d’exemples informatifs, on peut citer le brevet US7761397 ou les demandes de brevet WO1989011684 ou US20040034848. Le brevet US5664173 et les demandes de brevets US20060206468 et US20030212657 concernent plus particulièrement l’application de moteurs de règles à des bases de données. Des moteurs de règles ont été développés pour différents domaines : contrôle d’accès, gestion des risques, traitement de flux de données RS S, etc. L’invention est relative à l’utilisation d’un moteur de règles pour le contrôle des documents de gestion au sein d’une entreprise.
Les règles sont stockées dans une base de règles 120. Il peut être prévu d’associer les règles à des droits d’accès afin de permettre la mutualisation de la base de règles 120 entre plusieurs utilisateurs et plusieurs applications, tout en permettant leur cloisonnement.
Les règles peuvent prendre différentes formes et être adaptées selon différentes applications.
La figure 3 illustre un schéma permettant de stocker les règles au sein de la base de règles 120.
Les tables Tl, T2 sont des tables permettant d’organiser plusieurs ensembles de règles au sein d’une même base de règles, pouvant correspondre à plusieurs applications, plusieurs profils d’utilisateurs, etc. Un premier niveau, Tl, correspond à un projet, et le second niveau T2 permet de spécifier plusieurs ensembles de règles par projet.
La table T3 correspond aux règles proprement dites et permettent notamment d’associer à chaque règle des informations associées, notamment un nom (« name ») et certaines métadonnées immutables de la règle.
Selon un choix d’implémentation, les informations plus détaillées sont associées à une autre table, T4, tenant l’historique de la règle avec la définition et les métadonnées associées. Cette table possède des pointeurs vers la table mère T3, mais aussi vers elle-même afin de permettre une arborescence entre les versions.
Ces informations plus détaillées, ou métadonnées, permettent d’associer à chaque révision de règle, des informations permettant notamment d’en guider l’exécution par le moteur de règles. Un certain nombre de ces métadonnées sont techniques et peuvent être propres aux mises en œuvre techniques du moteur de règles.
Ces métadonnées peuvent comprendre un identifiant, ou nom, de la règle, une description et des informations permettant de déterminer un ordre entre les règles. Il peut s'agir de priorités (« priority ») ou d'un numéro d'ordre. Il est ainsi possible d'influencer, lors de la conception des règles, l'ordre dans lequel elles seront exécutées sur un ensemble de données, soit en les regroupant par priorités, soit en en fixant un ordre bien défini.
La métadonnée « description » peut par exemple permettre d’afficher des informations aux utilisateurs via l’interface 140.
En plus des métadonnées prédéfinies, par exemple tels que représentés sur la figure 3, les tables Tl, T2, T3 et T4 peuvent comporter des métadonnées flexibles (champs « metadata ») définis par l'utilisateur. Elles peuvent être exprimées en un format extensible tel que le format JSON (« JavaScript Object Notation »)
En sus des métadonnées, la table T4 mémorise les informations définissant la règle elle-même, c’est-à-dire un corps de règle pouvant comporter une seule ou plusieurs parties.
Par exemple :
- Une règle complète : SI <condition> ALORS <action>
- Une règle fonctionnelle pour grouper plusieurs règles techniques
- Une règle de contrôle des montants dans les factures peut avoir deux parties : une partie correspondant à une règle de détection des incohérences et une partie correspondant au formulaire de calcul quand l’erreur est trouvée par la règle en question.
D’une façon générale, les règles permettent d’associer des conditions et des actions.
La prémisse d’une règle peut contenir une ou plusieurs clauses qui peuvent elles-mêmes prendre la forme d’un couple associant une requête à un résultat attendu. La clause est remplie lorsque le résultat de l’exécution de la règle est égal au résultat attendu. Les clauses peuvent être reliées entre elles selon des connecteurs logiques (« et », « ou »...), de façon classique en soi.
Les actions peuvent être choisies dans un catalogue d’actions types, prédéfinies. Il peut s’agir de requêtes également.
Les actions visent à créer un ensemble de données 170 représentatives de l’analyse des documents de gestion représentés dans la base de données
100. Une partie des actions consistent donc à mettre à jour cet ensemble de données 170 au fur et à mesure de l’exécution des règles sur la base 101. Ces actions peuvent donc être des requêtes visant à mettre à jour une base de données de résultats, représentant cet ensemble de données.
Selon un mode de réalisation, cette base de résultats forme une entité 170 fonctionnellement distincte de la base de données 101, de sorte que le moteur de règles 110 ne modifie jamais le contenu de la base de données
101, constituée des documents de gestion, et ne fasse qu'alimenter une base de résultats 170.
Typiquement, dans le cas d'un contrôle de documents de gestion, cette base de résultats 170 est progressivement alimentée par les détections d'erreurs de cohérence au sein des documents de gestion, déterminées par l'application des règles.
Une partie des actions possibles consistent donc à générer des erreurs, ou autres informations destinées à alimenter la base de résultats 170.
En langage très haut-niveau, on peut exprimer de telles règles sous la forme :
SI <conditions> ALORS <créer erreur>
Des informations complémentaires sur le type d'erreur à créer ou, pour complémenter les informations qui seront associés à l'erreur dans la base de résultats 170, peuvent être définies dans les métadonnées associées à la règle.
D'autres types d'actions peuvent consister à créer des catégories ou autres actions de classements des données. Une telle règle peut s'exprimer sous la forme générique :
SI <conditions> ALORS <créer catégorie, « catégorie »>
Une telle règle permet d'ajouter une nouvelle catégorie dans la base de résultats 170 pour tous les enregistrements de la base de données 101 remplissant la ou les conditions.
Il est également possible de définir des règles sous la forme générique :
SI <conditions> ALORS fonction (paramètres)
Une telle règle fait appel à une action extérieure au moteur de règles 110, en lui passant des paramètres. Ces actions peuvent être définies par l'utilisateur, via une implémentation externe et intégrable au moteur lors de l’exécution.
Le moteur de règles 110 a pour charge d’appliquer les règles sur les données stockées dans la base de données 100, c’est-à-dire d’exécuter les requêtes associées à chaque règle sur ces données.
Pour ce faire, le moteur de règle peut accéder à la base de règles 120. Cette base de règles 120 et le moteur de règles 110 peuvent être localisés, c’est-à-dire déployés sur un même système de traitement de l’information. Ils peuvent également être répartis sur plusieurs dispositifs de traitements connectés entre eux. Il est toutefois important que pour le moteur de règles l’accès à la base de règles soit rapide, afin d’assurer de bonnes performances au système global.
L’accès aux règles peut se faire par les métadonnées attachées à chaque règle.
Si l'on revient à la figure 2, on voit que dans un premier temps, le moteur de règle 110 récupère les règles de la base de règles 120 dans une étape 212.
Dans une étape 213, le moteur de règles procède à un traitement de ces règles récupérées.
Notamment, il peut procéder à leur ordonnancement. Cet ordonnancement peut être guidé par les métadonnées, et notamment par la métadonnée « priorité » attachée à chaque règle stockée dans la base de règles. D’autres critères de tri des règles récupérées par le moteur de règles 110 sont évidemment possibles et envisageables.
Le schéma de la base de données peut être récupéré, dans une étape 214, par le moteur de règles 110 afin que celui-ci puisse générer les règles en un format exploitable par le système de gestion 102.
Le moteur de règles 110 peut alors mettre en place un processus itératif (zone en pointillés « Loop ») selon lequel chaque règle récupérée est traitée individuellement, de façon ordonnée.
Tout d'abord, dans une étape 2015, en utilisant le schéma de la base de données 101, le moteur de règles 110 peut transformer la règle en requêtes exprimés selon le langage et le format propre à la base de données. Typiquement, cette conversion consiste à transformer les règles exprimées en langage DRDL, comme évoqué précédemment, en un langage plus « bas niveau », comme le langage SQL. Il peut notamment s’agir de l’évolution PL/SQL (« ProcéduralLanguage /Structured Query Language »). D’autres mises en œuvre sont toutefois possibles.
Ensuite, dans une étape 216, le moteur de règles peut transmettre la requête vers le système de gestion de la base de données 102. Ce-dernier exécute alors la requête sur le contenu de la base de données 101 et renvoie le résultat vers le moteur de règles 110, dans une étape 217.
Celui-ci peut alors le comparer avec une valeur attendue associée à la règle. En fonction du résultat de cette comparaison, la ou les actions associées peuvent être exécutés.
Comme on l'a vu plus haut, une action possible consiste à alimenter le contenu de la base de résultats 170 (étape 218). Une autre action possible consiste à exécuter une fonction par un dispositif 160, extérieur au moteur de règles 110 proprement dit (étape 219).
Ainsi, le traitement se fait règle par règle. Le moteur de règles peut récupérer un ensemble de règles depuis la base de règles, mais les requêtes associées sont transmises et exécutées par le système de gestion de base de données une après l’autre.
Ce procédé se distingue fortement des mécanismes habituels de traitement massif de données, dans lesquels les données contenues dans la base de données sont récupérées dans la mémoire associée au moteur de règles afin d’y être localement traitées. Ce mécanisme correspond à un grand nombre d’outils du commerce pour le traitement de données basés sur des règles et notamment :
les solutions de la société IBM, tels qu’ODM (Operational Decision Manager) des solutions en “source ouvert” (open source) ou sous forme de logiciels libres (freewares ») telles que celles décrites dans l’article « EnhancedDesign of a Rule BasedEngine Implemented using Structured Query Language » de J Sawar Mohammad, Abdullah Unmair et Ahmed Aftab, in « Proceedings of the World Congress on Engineering”, 2010, volume 1
Ces différentes solutions nécessitent typiquement la création d’objets de travail (par exemple un objet Java) pour chaque donnée récupérée, et une implémentation spécifique pour le chargement de ces données selon chaque application.
Selon l’invention, les données des documents de gestion ne sont pas récupérées dans la mémoire associée au moteur de règles 120, et il n’y a donc pas de création d’objets de travail en mémoire (notamment d’objets Java). Tout le calcul est délégué au système de gestion de base de données
102.
Seul le résultat de la requête retourné par le système de gestion 102 occupe la mémoire locale associée au moteur de règles, soit un volume d'information très réduit en comparaison de la totalité de l'ensemble des données correspondant aux factures à traiter.
Dans la mesure où le volume de données à traiter peut être extrêmement important, le mécanisme de l’invention permet d’économiser un temps de traitement considérable en évitant la création, et donc la gestion, d’un grand nombre d’objets de travail en mémoire.
Il n’est pas non plus nécessaire de transmettre ce grand volume de données entre la base de données 101 et la mémoire associée au moteur de règles 120. Selon l’invention, uniquement des requêtes et des résultats sont transmis, ce qui représente des volumes de données bien moindre. On peut ainsi économiser un temps substantiel en évitant le transfert d’un important volume de données ayant potentiellement à transiter sur un réseau de communication.
Cette économie est d’autant plus importante que dans le cadre de l’invention, qui consiste à appliquer des règles sur des données de gestion, les règles sont relativement peu nombreuses (la plupart étant définie par des opérateurs humains).
En outre, dans la mesure où le système de gestion 102 est adapté au mieux à la base de données 101, on obtient une haute performance d'exécution de la requête, au détriment d'un échange d'information pour chaque règle. Toutefois comme l’impact de ces transmissions d’information est très réduit, comme nous venons de le voir, le bilan global est très largement positif.
Ainsi, des tests ont été effectués afin de comparer les performances du mécanisme selon l’invention et un mécanisme basé sur une solution consistant à récupérer les données depuis la base 101 et à créer des objets de travail en mémoire, telle que celle d’IBM ou des solutions Open Source. Il en résulte que l’invention permet d’atteindre un gain très substantiel pouvant dépasser un facteur 10.
Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.
Claims (10)
- REVENDICATIONS1. Procédé pour l’analyse de documents de gestion relatifs à une entreprise, lesdits documents de gestion étant stockés dans une base de données relationnelle (101), sous la forme d’un ensemble de données, comportant :- la récupération de règles à partir d'une base de règles (120), par un moteur de règles (110), puis,- de façon itérative, pour chacune desdites règles, la transmission par ledit moteur de règles (110) d'au moins une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, la comparaison du résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, l'exécution d'une action associée à ladite règle.
- 2. Procédé selon la revendication précédente, dans lequel les règles sont générées à partir d'un langage haut-niveau.
- 3. Procédé selon l’une des revendications précédentes, dans lequel les règles récupérées sont transformés en requêtes exprimés selon ledit système de gestion en utilisant le schéma (103) de ladite base de données.
- 4. Procédé selon la revendication précédente, dans lequel lesdites requêtes transformées sont exprimées en SQL ou PL/SQL et exécutée dans ledit système de gestion de données.
- 5. Procédé selon la revendication précédente, dans lequel lesdits documents de gestion sont des factures et dans lequel lesdites actions sont prévues pour vérifier la cohérence des données dudit ensemble.
- 6. Procédé selon l’une des revendications précédentes, dans lequel ladite action peut alimenter une base de résultat (170), fonctionnellement distincte de ladite base de données (101).
- 7. Procédé selon l’une des revendications précédentes, dans lequel ladite action peut déclencher l’exécution d’une fonction par un dispositif (160) extérieur audit moteur de recherche (110)
- 8. Procédé selon l'une des revendications précédentes dans lequel ladite base de règles (120) est un entrepôt de règles.
- 9. Produit logiciel comportant des instructions exécutables par une plateforme de traitement de l’information pour mettre en œuvre le procédé selon l’une des revendications précédentes.
- 10. Système pour l’analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de règles (110) adapté- pour récupérer des règles à partir d'une base de règles (120) selon un ordonnancement qui est fonction de métadonnées associées auxdites règles,- pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, comparer ledit résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, exécuter une action associée à ladite règle.1 /22/2
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1663314A FR3061337A1 (fr) | 2016-12-23 | 2016-12-23 | Moteur de regles universel et optimise pour le traitement de documents de gestion |
| PCT/FR2017/053288 WO2018115616A1 (fr) | 2016-12-23 | 2017-11-30 | Moteur de regles universel et optimise pour le traitement de documents de gestion |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1663314A FR3061337A1 (fr) | 2016-12-23 | 2016-12-23 | Moteur de regles universel et optimise pour le traitement de documents de gestion |
| FR1663314 | 2016-12-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3061337A1 true FR3061337A1 (fr) | 2018-06-29 |
Family
ID=58737660
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1663314A Pending FR3061337A1 (fr) | 2016-12-23 | 2016-12-23 | Moteur de regles universel et optimise pour le traitement de documents de gestion |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3061337A1 (fr) |
| WO (1) | WO2018115616A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11727283B2 (en) | 2020-05-19 | 2023-08-15 | International Business Machines Corporation | Rule distribution across instances of rules engine |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030212657A1 (en) * | 2002-05-10 | 2003-11-13 | Oracle International Corporation | Extensible rules engine in a database management system |
| US20090171903A1 (en) * | 2007-12-29 | 2009-07-02 | Aetna Inc. | Business Rules Externalization System |
| US20160171627A1 (en) * | 2014-12-15 | 2016-06-16 | Abbyy Development Llc | Processing electronic documents for invoice recognition |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0813127A3 (fr) | 1988-05-20 | 1998-05-06 | Matsushita Electric Industrial Co., Ltd. | Procédé pour déterminer des règles d'inférence et dispositif d'inférence |
| US5664173A (en) | 1995-11-27 | 1997-09-02 | Microsoft Corporation | Method and apparatus for generating database queries from a meta-query pattern |
| US7761397B2 (en) | 2001-03-21 | 2010-07-20 | Huelsman David L | Rule processing method and apparatus providing automatic user input selections |
| CN1659589A (zh) | 2002-04-19 | 2005-08-24 | 电脑联合想象公司 | 用于提供推理服务的系统和方法 |
| AU2003259744A1 (en) | 2002-08-09 | 2004-02-25 | Corticon Technologies, Inc. | Rule engine |
| US7089235B2 (en) | 2003-04-17 | 2006-08-08 | International Business Machines Corporation | Method for restricting queryable data in an abstract database |
-
2016
- 2016-12-23 FR FR1663314A patent/FR3061337A1/fr active Pending
-
2017
- 2017-11-30 WO PCT/FR2017/053288 patent/WO2018115616A1/fr active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030212657A1 (en) * | 2002-05-10 | 2003-11-13 | Oracle International Corporation | Extensible rules engine in a database management system |
| US20090171903A1 (en) * | 2007-12-29 | 2009-07-02 | Aetna Inc. | Business Rules Externalization System |
| US20160171627A1 (en) * | 2014-12-15 | 2016-06-16 | Abbyy Development Llc | Processing electronic documents for invoice recognition |
Non-Patent Citations (1)
| Title |
|---|
| MOHAMMAD J. SAWAR ET AL: "Enhanced Design of a Rule Based Engine Implemented using Structured Query Language", LECTURE NOTES IN ENGINEERING AND COMPUTER SCIENCE, 1 June 2010 (2010-06-01), pages 67 - 71, XP055403995, Retrieved from the Internet <URL:http://www.iaeng.org/publication/WCE2010/WCE2010_pp67-71.pdf> * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2018115616A1 (fr) | 2018-06-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220382752A1 (en) | Mapping Natural Language To Queries Using A Query Grammar | |
| Johann et al. | Safe: A simple approach for feature extraction from app descriptions and app reviews | |
| Rattenbury et al. | Principles of data wrangling: Practical techniques for data preparation | |
| US10896392B2 (en) | Methods and systems for generating supply chain representations | |
| US20200218737A1 (en) | Method, system and program product for matching of transaction records | |
| US8712990B2 (en) | Methods and systems for providing a business repository | |
| AU2016318212A1 (en) | Systems and methods for identifiying and explaining schema errors in the computerized preparation of a payroll tax form | |
| Zhu et al. | IBM Watson content analytics: discovering actionable insight from your content | |
| US20050182736A1 (en) | Method and apparatus for determining contract attributes based on language patterns | |
| US20110295854A1 (en) | Automatic refinement of information extraction rules | |
| AU2016201095A1 (en) | Simplified tax interview | |
| WO2002067142A2 (fr) | Dispositif d'extraction d'informations d'un texte a base de connaissances | |
| Vlas et al. | Two rule-based natural language strategies for requirements discovery and classification in open source software development projects | |
| CN105723335A (zh) | 数据流探索 | |
| US11176620B1 (en) | Systems and methods for generating an error report listing errors in the preparation of a payroll tax form | |
| EP3683683A1 (fr) | Optimisation de cycles de test utilisant le mappage d'associations contextuelles | |
| US20220051665A1 (en) | Artificial intelligence (ai) based user query intent analyzer | |
| US20120143813A1 (en) | Techniques for data generation | |
| EP1895410A1 (fr) | Procédé et système d'extraction d'un tableau croisé d'une base de données, et produit programme d'ordinateur correspondant | |
| Bhatia et al. | Towards a change taxonomy for machine learning pipelines: Empirical study of ML pipelines and forks related to academic publications | |
| FR3061337A1 (fr) | Moteur de regles universel et optimise pour le traitement de documents de gestion | |
| US20170337570A1 (en) | Analytics system for product retention management | |
| Galitsky et al. | Building chatbot thesaurus | |
| Edwards | Visualization of Data Flow Graphs for In-Situ Analysis | |
| US11893008B1 (en) | System and method for automated data harmonization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20180629 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |