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

[Jacques Leblond]

Bonjour Patrice
Exact pour le numéro de build, les yeux devaient se croiser hier soir, ce n'est pas bien grave, je vais de toute façon publier la prochaine version officielle prochainement.
Je voudrais faire quelques manipulations sur ma box avant. Le forum sera probablement indisponible quelques instants.

[Patrice15220]

Aucun problème. De toute façon il faut que j'aille nettoyer un peu le jardin sinon je vais me faire engueuler.
Au cas où tu ai besoin de faire des tests je serais disponible cet-après-midi

[bruno33]

Bonjour Jacques,

Je ne sais pas si c'est un bug ou une mauvaise utilisation de ma part ou une amélioration a faire dans le logiciel mais, voici un cas où l'importation pourrait être améliorée.
J'ai un compte au Crédit Agricole avec une carte à débit différé.

Lorsque j'importe le fichier ofx du CA, Gesfine ne sait pas retrouver les transactions de la carte bancaire.
Le fichier ofx est (grosso modo) en 2 parties (voir fichier joint):
- une partie pour toutes les transactions courante
- une partie pour les transactions de la CB à débit différé.
==> la banque traite comme si j'avais 2 comptes dans ce cas (les ACCTID ont des valeurs différentes pour la CB et le cpte courant)

Question subsidiaire: serait-il possible, à partir du fichier ofx de faire l'importation sur le bon compte dans Gesfine (en utilisant le numéro de compte)?

Merci encore
Bruno

[Jacques Leblond]

L'importation multi-comptes n'est pas envisagé à ce stade, c'est trop lourd à réaliser (structurellement par rapport à l'existant).
Si tu gères les cartes bancaires dans le compte courant (comme préconisé), cela ne doit pas poser de problème majeur. Seul le "solde bancaire" indiqué dans le formulaire de validation des opérations à importer pourrait être erroné.

Pour l'affectation du type Carte bancaire aux opérations réalisées par carte, il faut trouver le discriminent pour le faire. Pour ce que j'ai vu d'un fichier ofx du CA, on peut peut être affecter le type Carte bancaire si aucun des types que l'on trouve dans les champs MEMO ou NAME n'est présent.
Sans fichier je ne peux pas le confirmer.

[bruno33]

Jacques,

Si je gère la carte bancaire dans le compte courant, je retrouve le débit du compte courant vers la CB et vice-versa.
Le CA traite ma carte à débit différé de cette façon.
Donc après un essai, j'ai préféré créer 2 comptes

J'ai regardé et seul MEMO=. (caractère .) pourrait permettre de distinguer les paiements par carte (à l'exception des retraits au distributeur) des autres opérations (cf le fichier que j'ai joint dans mon post précédent).
Utiliser ce critère me semble un peut trop aléatoire...

Je pensais qu'une condition pourrait être ajoutée dans les règles sur l'ACCTID qui est différent dans mon cas entre le débit différé et le débit immédiat (par contre je ne sais pas si c'est généralisable).
Ça pourrait être un palliatif au "multi-compte".

En tout cas merci, les règles sont vraiment sympa

Bruno

[Jacques Leblond]

Si je gère la carte bancaire dans le compte courant, je retrouve le débit du compte courant vers la CB et vice-versa.
Le CA traite ma carte à débit différé de cette façon.

Ces 2 opérations ont peut être un discriminent qui permettrait de les supprimer en supprimant le champ date (elles seraient alors exclues de l'importation).
Si tu peux me les envoyer je regarderai

J'ai regardé et seul MEMO=. (caractère .) pourrait permettre de distinguer les paiements par carte (à l'exception des retraits au distributeur) des autres opérations (cf le fichier que j'ai joint dans mon post précédent).
Utiliser ce critère me semble un peut trop aléatoire...

Je ne suis pas sûr de comprendre "MEMO=. (caractère .)"

Je pensais qu'une condition pourrait être ajoutée dans les règles sur l'ACCTID qui est différent dans mon cas entre le débit différé et le débit immédiat (par contre je ne sais pas si c'est généralisable).
Ça pourrait être un palliatif au "multi-compte".

Non ce n'est pas possible car les règles ne s'appliquent pas sur des informations contenues dans le format ofx mais uniquement sur celles importées dans les champs de GesFine. ACCTID n'en fait pas partie.

[bruno33]

Si je gère la carte bancaire dans le compte courant, je retrouve le débit du compte courant vers la CB et vice-versa.
Le CA traite ma carte à débit différé de cette façon.

Ces 2 opérations ont peut être un discriminent qui permettrait de les supprimer en supprimant le champ date (elles seraient alors exclues de l'importation).
Si tu peux me les envoyer je regarderai

OK je regarderai et je t'enverrai un exemple (à la fin du mois - j'espère que j'y penserai)

J'ai regardé et seul MEMO=. (caractère .) pourrait permettre de distinguer les paiements par carte (à l'exception des retraits au distributeur) des autres opérations (cf le fichier que j'ai joint dans mon post précédent).
Utiliser ce critère me semble un peut trop aléatoire...

Je ne suis pas sûr de comprendre "MEMO=. (caractère .)"

Dans le fichier du CA, j'ai vu que j'ai:

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140718
<TRNAMT>-xxx.xxx
<FITID>20140831000000004
<NAME>SAS L ECAILLER
<MEMO>.
</STMTTRN>

D'ailleurs le FITID contient la date de valeur... (faut que je vois si je peux l'exploiter)

Je pensais qu'une condition pourrait être ajoutée dans les règles sur l'ACCTID qui est différent dans mon cas entre le débit différé et le débit immédiat (par contre je ne sais pas si c'est généralisable).
Ça pourrait être un palliatif au "multi-compte".

Non ce n'est pas possible car les règles ne s'appliquent pas sur des informations contenues dans le format ofx mais uniquement sur celles importées dans les champs de GesFine. ACCTID n'en fait pas partie.

ok

Merci pour les réponses
Bruno

[Jacques Leblond]

Si je gère la carte bancaire dans le compte courant, je retrouve le débit du compte courant vers la CB et vice-versa.
Le CA traite ma carte à débit différé de cette façon.

Ces 2 opérations ont peut être un discriminent qui permettrait de les supprimer en supprimant le champ date (elles seraient alors exclues de l'importation).
Si tu peux me les envoyer je regarderai

Autre alternative, ne pas importer ces deux opérations en les décochant dans le formulaire d'importation

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140718
<TRNAMT>-xxx.xxx
<FITID>20140831000000004
<NAME>SAS L ECAILLER
<MEMO>.
</STMTTRN>

Dans cette opération tu vois qu'il n'y a pas les types : PRELEVEMENT, PRELEVMNT, CHEQUE EMIS, VIREMENT EMIS, etc sur lesquels on a construit les règles. Donc par exception si aucun de ces types n'existe on pourrait affecter le type "Carte Bancaire". A voir.
Je vais ajouter l'opérateur "est différent de" que j'ai oublié.

Pour la date dans le FITID, je vais y réflechir.

[bruno33]

Code : Tout sélectionner

<STMTTRN>
<TRNTYPE>OTHER
<DTPOSTED>20140718
<TRNAMT>-xxx.xxx
<FITID>20140831000000004
<NAME>SAS L ECAILLER
<MEMO>.
</STMTTRN>

Dans cette opération tu vois qu'il n'y a pas les types : PRELEVEMENT, PRELEVMNT, CHEQUE EMIS, VIREMENT EMIS, etc sur lesquels on a construit les règles. Donc par exception si aucun de ces types n'existe on pourrait affecter le type "Carte Bancaire". A voir.

je n'y avais pas pensé... pour l'instant j'ai créé 2 règles pour MEMO=. :
- pour les echéances de prêts (tiers = ECH PRET)--> j'enlève le champs NOTE
- pour les débits différés où j'assigne la carte bancaire

Je vais ajouter l'opérateur "est différent de" que j'ai oublié.

Super, j'avais essayé avec la négation des expressions régulières (!) mais ca ne marche pas.
Au fait, y-a-t-il un guide pour les expression régulières utilisables? (je pensais à tout ce qui est disponible sous Perl)

Pour la date dans le FITID, je vais y réflechir.

A mon avis, il faut pouvoir utiliser une expression régulière pour la stocker dans la date de valeur mais je pense que ca peut attendre (je doute que toutes les banques fassent de même)
Sinon, bien que j'ai déclaré ma carte à débit différé (jour d’arrêté le 20 et jour de débit le 31), celui-ci n'est pas pris en compte par gesfine automatiquement.
J'ai manqué quelque chose?

Merci

[Jacques Leblond]

Au fait, y-a-t-il un guide pour les expression régulières utilisables? (je pensais à tout ce qui est disponible sous Perl)

Je ne suis pas très calé en expression régulière, le mieux serait de trouver quelque chose sous vb.net ou C# car c'est le langage de GesFine. Il faut que l'expression soit compatible avec ces langages.

Sinon, bien que j'ai déclaré ma carte à débit différé (jour d’arrêté le 20 et jour de débit le 31), celui-ci n'est pas pris en compte par gesfine automatiquement.

Je l'ai codé ainsi, la date de l'opération et la date de valeur pouvant être importées, je ne fais donc aucun calcul pour déterminer la date de valeur en fonction de la date de l'opération si le type est "Carte bancaire".
Je vais néanmoins regarder si je peux insérer le calcul mais uniquement si la date de valeur n'est pas définie.

[Jacques Leblond]

Je suis en train d'adapter le code pour faire le calcul de la date de valeur des cartes à débit différé si celle-ci n'est pas définie.
Or je constate que dans le format ofx du Crédit Agricole, la date qui est connue est DTPOSTED soit en théorie la date de valeur. Donc mon code sera inefficace. Il faudrait que ce soit la date DTUSER conformément aux spécifications du format OFX
Si DTUSER est connu et DTPOSTED non défini alors cela fonctionnera.
Peux tu m'indiquer si la date en face de DTPOSTED est la date de valeur ou la date de l'opération quand il s'agit d'une opération réalisé par carte à débit différé ?
On pourrait toujours inverser les champs avec une règle si le CA les a inversé.

EDIT :
Je crois avoir la réponse à ma question, dans l'exemple que tu as donné
DTPOSTED = 20140718
Or je vois dans FITID => 20140831 qui doit être la date de valeur

Donc il faut créer une règle d'inversion des dates.
Je ne sais plus si tu me l'as dit, ton exemple est issu du Crédit Agricole ou d'une autre banque ?

EDIT 2 :

Au fait, y-a-t-il un guide pour les expression régulières utilisables? (je pensais à tout ce qui est disponible sous Perl)

J'ai trouvé ça : http://lgmorand.developpez.com/dotnet/regex/

[bruno33]

Je suis en train d'adapter le code pour faire le calcul de la date de valeur des cartes à débit différé si celle-ci n'est pas définie.
Or je constate que dans le format ofx du Crédit Agricole, la date qui est connue est DTPOSTED soit en théorie la date de valeur. Donc mon code sera inefficace. Il faudrait que ce soit la date DTUSER conformément aux spécifications du format OFX
Si DTUSER est connu et DTPOSTED non défini alors cela fonctionnera.
Peux tu m'indiquer si la date en face de DTPOSTED est la date de valeur ou la date de l'opération quand il s'agit d'une opération réalisé par carte à débit différé ?
On pourrait toujours inverser les champs avec une règle si le CA les a inversé.

EDIT :
Je crois avoir la réponse à ma question, dans l'exemple que tu as donné
DTPOSTED = 20140718
Or je vois dans FITID => 20140831 qui doit être la date de valeur

oui c'est ça mais à mon avis, toutes les banques n'utilisent pas le champ FITID de la même manière....
Je pense que DTPOSTED est la date de l'opération

Sinon, j'ai utilisé l'expression régulière suivante pour extraire la date: ^([0-9]{4})([0-9]{2})([0-9]{2})[0-9]*~$1$2$3
où $1 = l'année, $2 = le mois, $3 = le jour
Je passe par le champs "note" pour recopier et manipuler la chaîne de caractère.
Le champ note contient le date mais par contre je n'arrive pas à l'affecter à la date de valeur.
C'est quoi le fomat? AAAAMMJJ ou JJMMAAAA ou JJ/MM/AAAA ou ?

Donc il faut créer une règle d'inversion des dates.
Je ne sais plus si tu me l'as dit, ton exemple est issu du Crédit Agricole ou d'une autre banque ?

Du Crédit Agricole

EDIT 2 :

Au fait, y-a-t-il un guide pour les expression régulières utilisables? (je pensais à tout ce qui est disponible sous Perl)

J'ai trouvé ça : http://lgmorand.developpez.com/dotnet/regex/

et moi: lien

Bruno

[Jacques Leblond]

Ok donc pour la date il faut créer une action pour mettre la Date de valeur dans la Date de l'opération, ensuite tu peux utiliser le champ Date de valeur pour définir les autres actions d'extraction de la date.
La date que tu dois générer doit avoir la même structure que les dates dans le fichier ofx, donc AAAAMMJJ

je vais tester ton expression, je faisais aussi des tests avec les variables $ mais sans succès, ne sachant pas si c'est mon code ou la Regex qui ne fonctionnait pas...

EDIT : je viens de tester unitairement ton expression et elle marche bien a priori :ugeek:
Je vais créer la règle complète pour avoir le rendu dans le formulaire.

[Jacques Leblond]

J'ai publié une nouvelle version intermédiaire avec l'opérateur "est différent de" pour l'expression des conditions

Voici la règle que j'ai écrite à partir de ton expression, à tester de ton coté car je n'ai pas de données correctes à mon niveau

L'autre alternative à l'utilisation de l'expression régulière pour récupérer la date de valeur est de laisser GesFine la calculer, en supprimant la date de valeur, ce qui donnerait comme règle :

[bruno33]

J'ai essayé la première méthode, mais ca ne veut rien savoir....

La date de valeur n'est pas modifiée même quand je rentre une valeur en dur :
date de valeur | définir le contenu | 20140731

note: je télécharge la nouvelle version et je ré-essaie (on ne sait jamais)

Bruno

[Jacques Leblond]

Voilà j'ai trouvé la règle à écrire pour que cela marche

Ce qu'il faut retenir :

• Il ne faut pas appliquer l'expression régulière sur un champ "date" et notamment ne pas faire une action qui envoie le contenu d'un champ texte vers un champ date avant qu'il soit au bon format.
• La date est correctement interprétée si elle est au format AAAA/MM/JJ
  Il faut que je regarde ce point qui doit être spécifique au format ofx car normalement c'est comme ce qui est défini dans le format, or avec l'ofx l'utilisateur ne définit rien.

J'ai donc modifié la chaîne de remplacement de ton expression régulière pour y mettre les /

Cela dit j'ai failli me faire avoir car au départ ce n'est pas la règle qui récupérait la date de valeur mais le code que j'ai ajouté cet après midi pour le calcul de la date de valeur si la date de l'opération est connue et pas sa date de valeur.
On obtient donc le même résultat avec la règle suivante si bien sûr la date de valeur de FITID est la même que la date calculée.

[bruno33]

oui, j'arrive à la même conclusion.
Dans mon cas, je passe maintenant par le champ Note en intermédiaire pour traiter l'expression régulière puis je met la valeur dans le champ "date de valeur".

Il se peut que le format de la date fournit doive correspondre au format date de C# pour que le code l'interprète correctement (mais je peux me tromper)

Merci
Bruno

[Jacques Leblond]

J'ai trouvé, la fonction de construction du format de date utilisait systématiquement le / comme séparateur de date au lieu de prendre celui du format qui dans le cas de l'ofx n'existe pas (vide).

La correction est faite dans la dernière version intermédiaire. Il faudra donc retirer les / que tu as ajouté dans la chaîne de remplacement de l'expression régulière avec cette nouvelle version.

[Patrice15220]

Bonjour Jacques,

Je viens de constater une petite anomalie à l'importation du fichier OFX.

En effet, je te joins une copie d'écran où les soldes sont identiques avec une opération à importer, et le message m'indique que les soldes sont différents

Qu'en penses-tu ?

EDIT : J'ai également noté que si je souhaite tout de même importer une opération avec un drapeau jaune, il ne se passe absolument rien en cliquant sur le bouton OK

[Jacques Leblond]

Ok Patrice, j'ai corrigé. Avant de publier une nouvelle version qu'entends tu par :

il ne se passe absolument rien en cliquant sur le bouton OK

pour les opérations au drapeau jaune.
Dès lors qu'elles sont cochées elles sont importées, j'ai fait un petit test pour le vérifier.