Skip to main content

​
Bases de données compatibles ODBC

FlexiCapture for Invoices vous permet de connecter un jeu de données à une base de données compatible ODBC, puis de charger ses données une seule fois ou de mettre à jour ce jeu de données à partir de la base de données externe à intervalles réguliers. Pour plus d’informations, voir Utilisation des bases de données des fournisseurs et des unités commerciales et Mise à jour des jeux de données. La première étape consiste donc à stocker les données externes dans une base de données compatible ODBC, telle que Microsoft Access, Microsoft SQL Server ou Oracle.

​
Éliminer les enregistrements en double dans la base de données externe

Commencez par déterminer quel champ de la base de données externe des fournisseurs (ou des unités commerciales) contient la valeur dont vous avez besoin lorsque le fournisseur (ou l’unité commerciale) est détecté sur une facture. Ce champ (ou cet ensemble de champs) doit devenir la clé unique du jeu de données. La clé unique d’un jeu de données d’unités commerciales est le champ Id (voir jeu de données BusinessUnits). Du point de vue de l’utilisateur, ce champ est le résultat de la détection de l’unité commerciale à laquelle la facture est adressée. La clé unique d’un jeu de données de fournisseurs doit être la valeur transmise au système d’information externe lorsque FlexiCapture for Invoices détecte le fournisseur qui a émis la facture. Si un seul tableau de fournisseurs est utilisé, la clé unique doit être associée au champ Id du jeu de données. Si vous prévoyez de traiter, dans un même projet, des factures adressées à différentes unités commerciales de votre entreprise, chacune ayant sa propre base de données fournisseurs, associez la clé unique de chaque unité commerciale à la colonne BusinessUnitId du jeu de données Vendors, et la clé de chaque fournisseur à sa colonne Id. La clé unique de l’enregistrement fournisseur transmise au système d’information externe lorsque le fournisseur est détecté est alors la paire de valeurs Id et BusinessUnitId (voir jeu de données Vendors). Les explications qui suivent portent uniquement sur la détection des fournisseurs, car la situation est identique pour les unités commerciales. La clé unique d’un enregistrement doit définir une combinaison unique des paramètres utilisés pour la détection des fournisseurs. Très souvent, un système d’information externe considère qu’un enregistrement fournisseur est unique sur la base d’un plus grand nombre de paramètres que ceux indiqués dans la facture ou utilisés pour la détection des fournisseurs. Par exemple, un système d’information externe peut s’attendre à recevoir un identifiant MCN_USD si le fournisseur My Company Name Ltd. émet une facture en dollars américains, ou un identifiant MCN_EUR si la même entreprise émet une facture en euros. Même si la devise est indiquée dans la facture (vous pourriez donc savoir quand renvoyer MCN_USD plutôt que MCN_EUR), la devise n’est pas utilisée pour la détection des fournisseurs. Par conséquent, le mécanisme de détection des fournisseurs ne peut pas faire la distinction entre MCN_USD et MCN_EUR. Dans ce type de cas, créez un identifiant MCN qui corresponde à la fois à MCN_USD et à MCN_EUR, et qui soit renvoyé lorsque le fournisseur est détecté. Vous pourrez ensuite créer une règle dans la Document Definition qui choisira entre MCN_USD et MCN_EUR en fonction de la devise de la facture concernée. De façon générale, l’identifiant unique d’un enregistrement fournisseur doit correspondre à un ensemble unique de paramètres utilisés pour la détection des fournisseurs, comme le nom de l’entreprise, l’adresse de l’entreprise, les identifiants fiscaux (VATID, NationalVATID) et l’IBAN (voir jeu de données Vendors). Ce n’est qu’à cette condition que le mécanisme de détection des fournisseurs peut sélectionner le bon enregistrement fournisseur pour une facture.
Le programme peut ensuite capturer des champs supplémentaires et utiliser des règles dans la Document Definition pour affiner le résultat et obtenir la valeur requise.
Si le même ensemble de paramètres (ou un ensemble facilement confondu) utilisé pour la détection des fournisseurs correspond à plusieurs clés uniques, le programme ne peut pas choisir une seule clé, la détection des fournisseurs devient aléatoire et la qualité se dégrade. La raison est la suivante. Si le programme peut utiliser les données imprimées sur la facture pour détecter de manière fiable le fournisseur My Company Name, mais que plusieurs enregistrements (MCN1, MCN2, …, MCNN) du jeu de données correspondent à ces données, le programme peut choisir un autre enregistrement, moins pertinent, mais qui présente moins de correspondances. Cela finit par entraîner une détection incorrecte du fournisseur. Par conséquent, il est très important d’éliminer les enregistrements en double et de créer une colonne dans la base de données externe qui possède une valeur unique pour chaque combinaison unique des champs de l’enregistrement utilisés pour la détection des fournisseurs. Lors de la connexion à un jeu de données, les lignes présentant des valeurs identiques dans la colonne associée à la clé unique sont automatiquement regroupées en un seul enregistrement.

​
Colonnes à valeurs multiples dans un jeu de données

Un jeu de données peut stocker plusieurs valeurs pour une même colonne logique d’un enregistrement d’entreprise. Le stockage de plusieurs valeurs est nécessaire, car les paramètres d’une entreprise, tels que son nom et sa rue, peuvent varier d’une facture à l’autre (par exemple, « My Company Name » et « MCN Ltd. »). Pour identifier l’entreprise de manière fiable, le texte du jeu de données doit correspondre le plus possible au texte capturé à partir d’une image de facture. En outre, une entreprise peut avoir plusieurs comptes bancaires ou autres attributs.
Les colonnes à valeurs multiples dans les jeux de données doivent être utilisées pour stocker une même information écrite de différentes façons. Par exemple, « Karl Marx Street » et « K. Marx str. » sont deux manières différentes d’écrire la même adresse. En revanche, les succursales d’une entreprise à Londres et à Berlin doivent avoir deux enregistrements distincts.
Les valeurs des colonnes à valeurs multiples peuvent provenir d’une base de données externe (par exemple, une table de fournisseurs peut contenir de une à cinq informations bancaires pour chaque entreprise), ou elles peuvent être ajoutées par l’utilisateur lors de la capture de données (par exemple, un Operator peut ajouter au jeu de données une variante couramment utilisée d’un nom d’entreprise qui n’est pas connue de la base de données externe). Les jeux de données utilisent la dénormalisation des colonnes, c’est-à-dire qu’ils stockent les données sous la forme suivante : Pour un champ logique d’un enregistrement, tel que Nom, plusieurs colonnes sont créées dans le jeu de données pour stocker toutes les valeurs possibles de ce champ logique. Ainsi, Nom peut être appelé une « colonne complexe ». Lors de la connexion d’un tableau (ou d’une vue) depuis une base de données externe, vous pouvez utiliser la dénormalisation des colonnes comme décrit ci-dessus, ou la dénormalisation des lignes, plus courante. Dans ce dernier cas, les lignes qui doivent être fusionnées en un seul enregistrement doivent avoir la même valeur dans la colonne correspondant à la clé unique. Par exemple :
  • La clé unique d’un jeu de données BusinessUnits est le champ Id. La clé unique d’un jeu de données Vendors est soit le champ Id, soit la paire de champs Id et BusinessUnitId, selon les paramètres. Pour plus d’informations, voir jeu de données Vendors.