[Intégré 5.8.55.5328] Importation - Règles d'importation à appliquer sur les données importées

[Patrice15220]

J'ai pas réussi à reproduire ce cas

Il suffit de se positionner sur le format, faire un clic de souris pour le rendre modifiable, changer de nom, et se positionner sur un autre format et le programme demande d'enregistrer. Après enregistrement les règles sont perdues.

Il est probable les deux problèmes soient liés.

[Jacques Leblond]

C'est normalement corrigé dans la dernière version intermédiaire.
Merci pour ton aide.

[Patrice15220]

C'est normalement corrigé dans la dernière version intermédiaire.

Je viens de tester les deux anomalies que j'avais précédemment constatées et je peux te confirmer que tout est OK.

Encore une fois, mais je me répète, tu es au TOP.

[Caster]

bonjour Jacques,

tout d'abord merci pour ce développement qui devrait rattraper les négligences des banques et/ou des commerçants dans nos relevés

j'ai téléchargé la version intermédiaire 5.7.53.5292 pour tester
après plusieurs essais, je n'ai gardé qu'une règle simple : Libellé/tiers, Supprimer le contenu, sans condition
mais je ne vois pas le résultat ni dans la fenêtre de validation, ni une fois les opération importées
qu'est ce que j'ai raté ?

[Jacques Leblond]

Bonjour Guy,

Le développement n'est pas terminé, comme je l'indique dans un précédent message, seule la gestion des règles est finalisée (sauf nouveaux besoins à découvrir) mais leur application sur les données importées reste à développer, c'est donc normal que tu ne constates aucun changement sur les données.

Sinon, de l'extrait que tu m'avais envoyé tu peux en écriture bien plus, par exemple tu avais :

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140704
<TRNAMT>-60.01
<FITID>0000
<NAME>Machin
<MEMO>PAIEMENT PAR CARTE
</STMTTRN>

Il faut donc basculer le champ Memo (Notes dans GesFine) dans le champ TRNType (Type de GesFine). Sans écrire de règle cette opération aura le type Prélèvement, or il devrait être Carte bancaire.
Voici donc les règles à écrire

Code : Tout sélectionner

Règle 1 :
Champ Source = Type
Action = Remplacer le champ par
Résultat = Notes
Condition si : Notes est égal à : PAIEMENT PAR CARTE

Règle 2 : A mettre après la 1
Champ Source = Type
Action = Remplacer le contenu
Résultat = Carte bancaire
Condition si : Type est égal à : PAIEMENT PAR CARTE

Règle 3 : A mettre après la 2
Champ Source = Carte bancaire
Action = Ajouter champ
Résultat = "Nom de ta carte"
Condition si : Type est égal à : Carte bancaire

Autre exemple, écrire les 2 mêmes types de règles

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140509
<TRNAMT>-30.00
<FITID>xxxxx
<NAME>ST JEAN
<MEMO>RETRAIT AU DISTRIBUTEUR
</STMTTRN>

Code : Tout sélectionner

Règle 4 :
Champ Source = Type
Action = Remplacer le champ par
Résultat = Notes
Condition si : Notes est égal à : RETRAIT AU DISTRIBUTEUR

Règle 5 : A mettre après la 4
Champ Source = Type
Action = Remplacer le contenu
Résultat = Retrait d'espèce par carte
Condition si : Type est égal à : RETRAIT AU DISTRIBUTEUR

Règle 6 : A mettre après la 5
Champ Source = Carte bancaire
Action = Ajouter champ
Résultat = "Nom de ta carte"
Condition si : Type est égal à : Retrait d'espèce par carte

Plus voir si tu veux aussi supprimer systématiquement le champ Name (Libellé, tiers) pour un retrait par carte
si oui, écrire la règle :

Code : Tout sélectionner

Règle 7 :
Champ Source = Libellé, tiers
Action = Supprimer le contenu
Condition si : Type est égal à : Retrait d'espèce par carte

Cas des chèques si yyyyy est bien le numéro de chèque de l'opération, rectification du type et passage du numéro de chèque dans le champ dédié

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140507
<TRNAMT>-428.14
<FITID>xxxxx
<NAME>yyyyy
<MEMO>CHEQUE EMIS
</STMTTRN>

Code : Tout sélectionner

Règle 8 :
Champ Source = Type
Action = Remplacer le champ par
Résultat = Notes
Condition si : Notes est égal à : CHEQUE EMIS

Règle 9 : A mettre après la 8
Champ Source = Chèque ou Réf
Action = Remplacer le champ par
Résultat = Libellé, tiers
Condition si : Type est égal à : CHEQUE EMIS

Règle 10 : A mettre après la 8 et 9
Champ Source = Type
Action = Remplacer le contenu
Résultat = Chèque émis
Condition si : Type est égal à : CHEQUE EMIS

Encore un autre exemple, ici l'inversion du type est à faire avec le champ Name (Libellé, tiers de GesFine)

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140624
<TRNAMT>-5.97
<FITID>xxxxx
<NAME>PRELEVMNT
<MEMO>EDF clients particuliers
</STMTTRN>

Code : Tout sélectionner

Règle 11 :
Champ Source = Type
Action = Remplacer le champ par
Résultat = Libellé, Tiers
Condition si : Libellé, Tiers est égal à : PRELEVMNT

Règle 12 :
Champ Source = Libellé, Tiers
Action = Remplacer le champ par
Résultat = Notes
Condition si : Type est égal à : PRELEVMNT

Règle 13 : A mettre après la 11 et 12
Champ Source = Type
Action = Remplacer le contenu
Résultat = Prélèvement
Condition si : Type est égal à : PRELEVMNT

Voilà quelques exemples qui semblent se reproduire pour chaque type que gère ta banque.
Je pense qu'une fois le jeu de règles écrit pour chaque type cela devrait couvrir la grande majorité de tes besoins.

[Caster]

merci pour ta réponse rapide et détaillée (et même personnalisée !)
j'ai lu un peu vite les posts précédents avant de m'empresser à tester

sinon pas de problème sur le principe même si cela risque de faire un nombre de règles assez important
est-ce qu'une présentation des règles dans ce style (copie des filtres sur messages de Thunderbird), avec les conditions et les actions successives groupées dans la même fenêtre pour une même tiers aurait été possible ?

[Jacques Leblond]

Les règles ne sont pas uniquement à faire pour un tiers particulier. Dans ton fichier pour les exemples que j'ai donné, c'est souvent 2 ou 3 champs qui sont inversés et que j'ai essayé de "réagencer par des règles", le tiers ne fait pas référence dans la logique d'écriture des règles.

Sinon je ne suis pas sûr que l'IHM que tu présentes répondent au besoin de regroupement qui nous concernent.
Dans cette IHM, à un groupe de conditions est associé à un groupe d'actions. Or dans les exemples que j'ai écris le regroupement est de plus haut niveau car c'est un ensemble indépendant de "Conditions => Actions" (conditions différentes selon les actions) qui nécessitent d'être regroupées. La présentation proposée n'y répond pas.

Le seul intérêt que j'y vois est qu'elle mutualise l'écriture de la condition pour un groupe d'action. C'est un cas qui peut exister pour nous, notamment pour les modifications à réaliser sur le contenu textuel d'un champ.
Mais pour ces modifications, beaucoup d'actions seront sans conditions car systématique, je pense par exemple à la mise au format, passage en minuscule, passage de la première lettre des mots en majuscules, etc...

Enfin ce n'est pas du tout la structure de table que j'ai adoptée en base de donnés où la condition dépend de l'action, faire l'inverse revient à tout refaire et surtout me laisse dubitatif quant à systématiser la logique qui consiste à définir la condition avant l'action.

Malgré tout, l'idée d'amélioration que je note serait de pouvoir effectuer des regroupements d'actions qui permettent de corriger une configuration de données.
Je vais y réfléchir car cela complexifie pas mal l'IHM et nécessite une nouvelle table en base de données, les données que vous seriez amener à saisir dans cette version seraient perdues.

Donc dans tous les cas ne vous lancez pas à écrire trop de règles, rester en au stade du test.

[Jacques Leblond]

Bon finalement je viens de reprendre tous les exemples, qui tout en ayant des conditions différentes pour les actions pourraient malgré tout être regroupées sous une unique condition, disons la condition "déclencheuse", charge à la logique d'application des actions d'en tenir compte pour effectuer correctement toutes les modifications.

Cela me parait pas mal ...

Rendez vous dans quelques semaines, faut tout refaire... Ne saisissez pas de règles cela ne sert plus à rien.

[Patrice15220]

Bonsoir Jacques,

Peut-on tout de même conserver le fichier de la version 5292 ou faut-il revenir sur une version précédente ?

[Jacques Leblond]

Oui bien sûr vous pouvez conserver votre fichier, je me chargerai de supprimer vos règles avec la prochaine version pour éviter tout conflit lors de l'importation dans la future structure de tables.

[Caster]

Les règles ne sont pas uniquement à faire pour un tiers particulier. Dans ton fichier pour les exemples que j'ai donné, c'est souvent 2 ou 3 champs qui sont inversés et que j'ai essayé de "réagencer par des règles", le tiers ne fait pas référence dans la logique d'écriture des règles.

je crois que si justement

les erreurs dans les champs MEMO et NAME sont variées mais répétitives selon le tiers. (ce qui laisse à penser que c'est le commerçant qui transmet à la banque des infos en vrac). tu ne l'as peut-être pas remarqué dans le relevé que je t'ai envoyé car j'avais éliminé les opérations répétitives.

c'est la raison pour laquelle je pensais d'abord établir des règles pour les tiers courants et ensuite des règles globales pour les tiers occasionnels

[Jacques Leblond]

Si l'inversion des champs dépend du tiers, tu devrais avoir dans tes fichiers des cas où pour un même type d'opération "paiement par carte" par exemple, les opérations sont avec le type géré dans des champs différents (TRNTYPE, MEMO, NAME)
Ce n'est pas ce que j'ai perçu mais je n'ai qu'un échantillon.

Par ailleurs si tous les tiers pratiquent de la même façon pour les paiement par carte, il est plus simple d'écrire une unique règle par type de paiement plutôt qu'une règle par tiers.
De plus je prévois des "conditions" d'application pour les règles associées par l'opérateur "ET" uniquement. Si l'on veut un opérateur OU il faut réécrire une règle, donc c'est coûteux en gestion si l'on doit écrire une règle par tiers.

Personnellement je n'importe pas les opérations par fichier, je saisis tout, j'ai donc pas vraiment d'expérience sur le contenu des fichiers de type OFX mais dans ceux que j'ai vu je n'ai pas constaté une dépendance par rapport au tiers.

Si tu as un exemple je suis preneur, donc pour un même type de paiement (crédit et débit dissocié) avoir un remplissage différent des champs.

[Caster]

je te renverrai le même relevé en conservant les opérations des tiers récurents

[Jacques Leblond]

Merci Guy, j'ai bien reçu les 2 fichiers.

Voilà ce que je constate pour le premier, il s'agit du Crédit Agricole, je le cite car cela doit intéressé d'autres utilisateurs. Nous pourrons d'ailleurs probablement en fonction de l'organisme bancaire, établir un jeu de règles génériques qui s'appliquent systématiquement.

Pour les types gérés dans le format OFX :

• Les PAIEMENT PAR CARTE sont tous dans MEMO => Création d'une règle
• Les PRELEVMNT sont tous dans NAME => Création d'une règle
• Les PRELEVEMENT sont tous dans MEMO => Création d'une règle
• Les VIREMENT EN VOTRE FAVEUR sont tous dans MEMO sauf un dans NAME avec MEMO = DE GUY, peut être un virement interne entre 2 de tes comptes
  Je constate pour ce type que le champ FITID est égal à 0000000000000, cela pourrait poser problème car j'utilise ce champ pour détecter les doublons puisqu'il s'agit de l'identifiant unique de la transaction, il faudra peut être le supprimer pour ce type.
• Les VIREMENT EMIS sont dans MEMO quand ils semblent automatiques/périodiques et dans NAME quand il semble que ce soit de personne à personne
  Ici il faut probablement introduire le tiers dans la règle donc avoir 1 règle par tiers, à moins de trouver une autre donnée différenciante.
  A défaut pour les types on ne fait rien, ce seront ceux par défaut de GesFine, ce qui est peut être aussi satisfaisant.

Pour le deuxième fichier chez l’écureuil, la nature (credit/débit) est gérée dans le champ type du format OFX (TRNTYPE).
Il semble que l'on puisse néanmoins récupérer assez facilement les types de GesFine chèque émis, cartes bancaires, Prélèvement et Versement puisque le champ NAME de nombreuses opérations commence par CHEQUE, CB, PRLV ou VIR. Pour les autres opérations n'ayant pas ce distinctif les types par défaut de GesFine seront appliqués.

Pour les chèques, on devrait pouvoir mettre le numéro dans le champ dédié plutôt que de le conserver dans le champ tiers.
Enfin il faudrait pouvoir supprimer les doublons entre le champ NAME et MEMO qui comportent la même information dans de nombreuses opérations et ça je ne l'avais pas prévu, il faudrait que je fasse évoluer les possibilités d'expression des conditions et notamment pouvoir sélectionner un champ dans le résultat et pas uniquement une expression textuelle (Si Tiers = Notes)
Je le note pour les travaux à venir.

Si tu vois d'autres choses n'hésite pas à me l'indiquer, l'idée est de s'assurer avec les fonctionnalités que je vais mettre en place que l'on peut améliorer au mieux l'agencement des données dans les fichiers.

[Caster]

bonjour Jacques,

Les VIREMENT EN VOTRE FAVEUR sont tous dans MEMO sauf un dans NAME avec MEMO = DE GUY, peut être un virement interne entre 2 de tes comptes
Je constate pour ce type que le champ FITID est égal à 0000000000000

c'est bien un virement interne et à première vue cet ID n'est nul que dans le cas d'un relevé multi comptes (les tenants et aboutissants sont sur le même relevé)

ton analyse semble juste
le but étant de limiter le nombre de règles car on ne peut pas exclure qu'il faille les ajuster si la banque change les siennes.
à regarder les comptes importés avec Money, cela arrive de temps en temps

autre point:
ne pourrait-on pas profiter du solde figurant en fin de fichier pour générer un message en cas de décalage avec Gesfine en fin d'importation ?

[Kerni29]

Bonjour, il y a quelques mois j'avais commencé à exporter les opérations de ma banque. J'avais laissé tombé trop compliqué de reprendre toutes les opérations, Je saisis les opérations manuellement, inconvénient pour faire correspondre le relevé banque avec Gesfine. Hélas je le reçois que tous les mois et demi. J'essaie de suivre l'évolution , je ne comprends pas trop comment on peut changer les libellés avant importation pour pouvoir mettre la bonne catégorie et sous catégorie. Je ne suis pas doué pour ecrie des formules : Tiers = Tata Si Tiers = Toto
Tiers = Tata Si Catégorie = Titi. Ou et quand les insérer.

[Jacques Leblond]

Ou et quand les insérer.

L'évolution n'est pas encore implémentée, j'ai dans les dernières versions intermédiaires proposé une interface de gestion mais Caster m'a proposé une approche différente à l'image de ce qui existe dans un autre logiciel et cela me parait adapté pour ceux qui devront gérer beaucoup de règles.
Je vais donc refaire complément la structure des tables et l'interface.

Il faut donc attendre, te concernant si les règles évoquées dans ce sujet te semblent difficiles à comprendre, le plus simple est d'attendre la version officielle qui implémentera cette évolution, dans le cas contraire tu peux contribuer aux tests, mais inutile de le faire avec la version actuelle, devenue obsolète, je vous indiquerai dès qu'une nouvelle version de l'IHM de gestion des règles sera disponible.

[Jacques Leblond]

ne pourrait-on pas profiter du solde figurant en fin de fichier pour générer un message en cas de décalage avec Gesfine en fin d'importation ?

C'est une spécificité du format Ofx, je verrai cela plus tard, dans tous les cas le montant et sa comparaison avec le solde résultant après importation dans GesFine ne peut être qu'informatif.
Je le note.

[Jacques Leblond]

[*]Les VIREMENT EMIS sont dans MEMO quand ils semblent automatiques/périodiques et dans NAME quand il semble que ce soit de personne à personne
Ici il faut probablement introduire le tiers dans la règle donc avoir 1 règle par tiers, à moins de trouver une autre donnée différenciante..[/list]

Un remarque sur ces propros. Inutile de faire des règles dépendantes du tiers pour traiter ce cas
Il suffit de créer 2 règles, la première si "Notes" (MEMO) = "VIREMENT EMIS" et la deuxième si "Tiers,Libellé" (NAME) = "VIREMENT EMIS".
Je ne sais pas pourquoi je n'y ai pas pensé hier. 2 Règles valent mieux que n règles dépendant des tiers.

[Jacques Leblond]

La nouvelle gestion des règles est disponible dans la dernière version intermédiaire.
Dans cette version, les règles ne sont toujours pas appliquées aux données importées.

ne pourrait-on pas profiter du solde figurant en fin de fichier pour générer un message en cas de décalage avec Gesfine en fin d'importation ?

J'ai complété le formulaire de validation des opérations à importer en ajoutant le solde dans GesFine après importation et le solde "attendu" spécifié dans le format ofx.
Lorsqu'il s'agit de l'importation de ses dernières opérations, les 2 soldes devraient être équivalents.
Merci à Guy pour son aide sur le décryptage des dates et soldes contenus dans le format ofx.