Discussion :

[xavier.ninane]

Bonjour à tous,

Comme à chaque fois que j'ai le nez dans le guidon et que je n'ai pas trouvé de réponse à mes interrogations sur le forum, je poste.

Je réalise un logiciel qui comporte une partie comptable (un enfer ), et je souhaite mettre en place un algo qui me permet de screener tous les extraits bancaires et les mettre en relation avec les factures encodées.
Bien entendu, cet algo n'est qu'une proposition pour l'utilisateur : il garde la main pour mettre en lien tel mouvement bancaire avec telle facture.

Parmi les éléments que l'algo teste, il y'a le nom de la contrepartie dans l'extrait bancaire afin de faire un "matching" avec le nom des fournisseurs encodés dans ma BD (Hyperfile)
Je précise : l'extrait bancaire a été importé en brut de décoffrage depuis un fichier xml (standard imposé)

Je crée la procédure qui lit les branches de l'extrait bancaire, et pour chacune des branches "nom contrepartie" je lance une requête en index full text pour voir si ce nom est connu dans ma BD. (c'est lourd, mais les utilisateurs sont bien contents d'attendre 5 min. pour économiser 2h d'encodage manuel !)

Tout roule, sauf que j'ai des p de cas particulier : SWDE encodé comme fournisseur dans la BD, et S.W.D.E. dans l'extrait bancaire.
Vu la difficulté de traiter ce cas, j'opte pour la création d'une 2e rubrique (Nom2) pour encoder le nom avec ses spécificités lexicographiques.
J'inclus cette 2e rubrique dans mon index, et résultat de la requête... nada !

J'ai un retour de ma requête sur swde et aucun retour sur s.w.d.e. !
J'ai bien entendu testé "s.w.d.e." en paramètre. Nada.

Je suis certain qu'un des aimables membres de notre communauté a déjà été confronté à ce cas particulier et qu'il pourra m'éclairer sur la marche à suivre pour résoudre ce (petit) problème.

D'avance merci.

PS : voici la manière dont ce fournisseur est libellé dans les différents extraits de compte
1/ S.W.D.E.
2/ Swde
3/ S.W.D.E. SOCIETE WALLONNE DES EAUX

Ok, je vous écris de Wallonie

X.

[Hemgé]

Bonsoir,

Dans ces cas-là, j'utilise un index "nettoyé" : tout en minuscule/majuscule (au choix), sans accent et sans ponctuation, éventuellement même expurgé des caractères numériques.
Ensuite, il vous resterait à faire la recherche pour chaque mouvement en utilisant impérativement la même procédure pour construire la clé de ce mouvement que celle utilisée pour indexer votre fichier, ce qui vous garantira que les deux traitements sont et resteront toujours en phase.

Cela marcherait impeccablement dans les deux premiers cas.
Pour le troisième, il faudrait envisager un match partiel.

En espérant que cela vous aide,

Hemgé

[xavier.ninane]

C'est +/- la solution vers laquelle je m'orientais, étant entendu que j'ai eu à traiter des s**** du style "dupont-durand".
Si je passe "dupont-durand" à requête, il interprète le "-" entre dupont et durand comme une exclusion.
J'ai eu le même coup avec des "+" dans les noms (si, si).

J'ai contourné en faisant un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Remplace(COL_Nom_contrepartie,["-","+"]," ")

Par contre, ce subterfuge est à proscrire avec les "." car je vais créer une suite de mots d'une seule lettre.

J'ai donc imbriqué un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ChaîneSupprime(Remplace(COL_Nom_contrepartie,["-","+"]," "),".")

Pas top, top, mais bon. J'ai d'ailleurs peur des effets pervers tant il y'a des spécificités dans les noms et dénominations et qu'aucun standard n'est imposé dans les échanges de données.

Le match partiel ne me pose pas de soucis car je pondère les résultats textuels par d'autres éléments pour exclure les faux positifs.

Toutes les idées et critiques sont les bienvenues...

[frenchsting]

un "matching"

Une correspondance, ça marche très bien en Wallon.

+1 à Hemgé et j'affine en te disant de faire une procédure qui va tester la conformité d'une chaîne de caractères et lever une erreur si elle comporte un caractère indésirable (genre : |, \,....).

Il va de soi que cette procédure est a exécuter avant ton traitement.

Pour info, j'avais eu le cas lorsque je recevais des fichiers émis par des machines EBCDIC via X25. Le logiciel de transfert ne faisait pas complètement le transcodage...

[xavier.ninane]

@Hemgé

Construire un index "nettoyé" ?!? Je me mettais dans une logique d'index full text.
Je ne vois pas comment "nettoyer" cet index...
De ce que j'ai compris, et détrompez-moi le cas échéant, l'index full text ne tient pas compte de la ponctuation.
En ce cas "G.I.L." (cas concret) ne semble pas indexé. Or mes extraits bancaires réfèrent à cette dénomination qui est la dénomination correcte.

Comment faire un matching (oups, une correspondance ) de l'index full text sur ce mot ?!?
Je précise que je dois travailler avec l'index full text pour pouvoir combiner plusieurs critères (nom, prénom, nom composé, etc.)

Est-ce que je devrais créer une rubrique supplémentaire, laquelle serait créée par programmation pour faire le nettoyage en question ?

Je suis régulièrement confronté à des noms de sociétés dont la dénomination légale et réelle est une suite de lettre et de points.

PS : je n'ai aucune difficulté à passer en paramètre le nom de la société expurgé de la ponctuation, mais c'est bien au niveau de la source initiale (le nom encodé) que j'ai un soucis avec l'index full text.

[Hemgé]

Bonjour,

L'indexation fulltext est sensible à casse (..SensibleCasse) et à l'accentuation (..SensibleAccentuation).
Donc, pour autant que vous ayez passé ces propriétés booléennes à FAUX, Windev retiendra tant "G.I.L.", que "GIL", que "G.IL", , que "gil" etc.

Puisque vous êtes en V20, vous disposez aussi de ..Synonyme.

Mais je ne pense pas que l'index FullText soit exactement ce que vous recherchez ni qu'il puisse fournir la réponse à votre problème.

A mon sens, la seule solution viable, si vous voulez tenir compte de tous les facteurs et toutes les variations possibles est de passer par un "fichier des désignations" annexe qui contiendra toutes les dénominations rencontrées, leur systématisation et le pointeur vers la fiche correspondante, en n'oubliant pas de prévoir un possible synonyme. Ce fichier est à indexer sur la dénomination systématisée.

Rubriques :
- ent : identifiant automatique (pas indispensable)
- ch : désignation (telle que rencontrée)
- ch : systématisation (complétée par pointeur pour gérer d'éventuels synonymes après systématisation et on peut être certain qu'on finira par rencontrer deux synonymes)
- ent : pointeur vers fichier principal

Personnellement, je procéderais de la manière suivante, au travers d'une routine à appeler tant à la constitution du fichier des désignations que lors de la recherche :
- ne conserver que les caractères alphanumériques, soit [A-Za-z0-9]
- tout passer en majuscule ou minuscule soit [A-Z09] ou [a-z0-9]
- compléter par le pointeur formaté avec des zéros à gauche (NumériqueVersChaine(Pointeur, "06d") (6, ce la laisse de la marge ...)
Aucun problème majeur pour les transformations, avec les fonctions de Windev ou via les expressions régulières.

Ensuite, après une première indexation initiale de l'existant, le système détectera toute nouvelle désignation inconnue et l'opérateur assignera la correspondance qui sera retenue et indexée.
Dans ce processus "d'apprentissage", le système connaîtra de plus en plus de variations qu'il pourra résoudre sans intervention des opérateurs.

La recherche se fera avec HLitRecherche sur la clé systématisée, suivi d'une petite boucle pour détecter un éventuel synonyme.
HLitRecherche donnera le premier enregistrement avec une clé commençant par la clé systématisée (et complétée par le pointeur).

J'espère que ceci peut vous aider.

Il y a sans doute d'autres approches, par exemple une rubrique dans le fichier principal comprenant la liste des désignations et leur épluchage, mais cela prendrait beaucoup plus de place et serait sans doute plus lent.

Bon travail

Hemgé