[grisbi-devel] Problème avec "extraire un numéro à enregistrer dans N° de chèque/Virement"

Discussion:

Ludovic Rousseau

2018-10-14 20:39:40 UTC

Bonjour,

J'ai un problème avec l'option d'importation "extraire un numéro à
enregistrer dans N° de chèque/Virement"

Le code cherche n'importe quel suite de caractères qui ressemble à un
nombre pour l'utiliser comme numéro de chèque.
Mon problème est que la banque ajoute une date sur les paiements par CB.
Par exemple :
$ ofxdump telechargement.ofx
[...]
ofx_proc_transaction():
Account ID : 11315 00001 xxxxxxxxxx
Transaction type: DEBIT: Generic debit
Date posted: Wed Aug 15 11:59:00 2018 CEST
Total money amount: -50.00
# of units: 50.00
Unit price: 1.00
Financial institution's ID for this transaction: xxxxxxxxxx-17.13.57.177042
Name of payee or transaction description: CB FRAMASOFT FACT 140818
Extra transaction information (memo): CB FRAMASOFT FACT 140818
[...]

Donc ici Grisbi va prendre "140818" comme un numéro de chèque alors
que c'est une date.

Pour un chèque ça marche très bien.
Par exemple avec :
[...]
ofx_proc_transaction():
Account ID : 11315 00001 xxxxxxxxxx
Transaction type: DEBIT: Generic debit
Date posted: Mon Aug 6 11:59:00 2018 CEST
Total money amount: -571.37
# of units: 571.37
Unit price: 1.00
Financial institution's ID for this transaction: xxxxxxxxxx-02.03.45.399201
Name of payee or transaction description: CHEQUE N 8786734
Extra transaction information (memo): CHEQUE N 8786734
[...]

Ici "8786734" est bien un numéro de chèque.

Ma proposition : est-ce une bonne idée d'ajouter un critère
supplémentaire avant de prendre un nombre pour un numéro de chèque ?
Par exemple il faut que la transaction contienne "CHEQUE".

ça fonctionnerait pour mon cas. Mais je suis peut-être une exception ?
Le patch est très simple :
diff --git a/src/import.c b/src/import.c
index b41f84f9c..3e493cea1 100644
--- a/src/import.c
+++ b/src/import.c
@@ -2313,7 +2313,7 @@ static gint gsb_import_create_transaction
(struct ImportTransaction *imported_tr
gsb_data_transaction_set_notes (transaction_number,
imported_transaction->tiers);
}
- if (etat.extract_number_for_check)
+ if (etat.extract_number_for_check &&
strstr(imported_transaction->tiers, "CHEQUE"))
{
tmp_str = gsb_string_extract_int (imported_transaction->tiers);
if (tmp_str && strlen (tmp_str) > 0)

On peut rendre le texte à chercher paramétrable.

Des commentaires ?

à+

--
Dr. Ludovic Rousseau

Pierre Biava

2018-10-15 13:01:05 UTC

Permalink

Ludovic Rousseau a écrit le 14/10/2018 à 22:39 :

Bonjour,

Post by Ludovic Rousseau
Bonjour,
J'ai un problème avec l'option d'importation "extraire un numéro à
enregistrer dans N° de chèque/Virement"
Le code cherche n'importe quel suite de caractères qui ressemble à un
nombre pour l'utiliser comme numéro de chèque.
Mon problème est que la banque ajoute une date sur les paiements par CB.
$ ofxdump telechargement.ofx
[...]
Account ID : 11315 00001 xxxxxxxxxx
Transaction type: DEBIT: Generic debit
Date posted: Wed Aug 15 11:59:00 2018 CEST
Total money amount: -50.00
# of units: 50.00
Unit price: 1.00
Financial institution's ID for this transaction: xxxxxxxxxx-17.13.57.177042
Name of payee or transaction description: CB FRAMASOFT FACT 140818
Extra transaction information (memo): CB FRAMASOFT FACT 140818
[...]
Donc ici Grisbi va prendre "140818" comme un numéro de chèque alors
que c'est une date.
Pour un chèque ça marche très bien.
[...]
Account ID : 11315 00001 xxxxxxxxxx
Transaction type: DEBIT: Generic debit
Date posted: Mon Aug 6 11:59:00 2018 CEST
Total money amount: -571.37
# of units: 571.37
Unit price: 1.00
Financial institution's ID for this transaction: xxxxxxxxxx-02.03.45.399201
Name of payee or transaction description: CHEQUE N 8786734
Extra transaction information (memo): CHEQUE N 8786734
[...]
Ici "8786734" est bien un numéro de chèque.

En fait le problème vient du fait que la banque ne détaille pas le moyen
de paiement. Du coup libofx ne peut pas ranger le débit dans la bonne case.

Ceci étant dit, comme je mets le bon moyen de paiement, le numéro de
chèque disparaît car il n'est pas utile.

Post by Ludovic Rousseau
Ma proposition : est-ce une bonne idée d'ajouter un critère
supplémentaire avant de prendre un nombre pour un numéro de chèque ?
Par exemple il faut que la transaction contienne "CHEQUE".

C'est une bonne idée car ça limiterai le nombre de fausses informations.
Il reste le cas des Virements qui ont parfois un numéro valide.

Post by Ludovic Rousseau
ça fonctionnerait pour mon cas. Mais je suis peut-être une exception ?
diff --git a/src/import.c b/src/import.c
index b41f84f9c..3e493cea1 100644
--- a/src/import.c
+++ b/src/import.c
@@ -2313,7 +2313,7 @@ static gint gsb_import_create_transaction
(struct ImportTransaction *imported_tr
gsb_data_transaction_set_notes (transaction_number,
imported_transaction->tiers);
}
- if (etat.extract_number_for_check)
+ if (etat.extract_number_for_check &&
strstr(imported_transaction->tiers, "CHEQUE"))
{
tmp_str = gsb_string_extract_int (imported_transaction->tiers);
if (tmp_str && strlen (tmp_str) > 0)

Ça doit fonctionner comme ça. Il faut remplacer CHEQUE par _("Check") et
utiliser la formule de recherche my_strcasecmp (). Ça devrait fonctionner.

Post by Ludovic Rousseau
On peut rendre le texte à chercher paramétrable.

A voir. La fonction d'importation gsb_import_create_transaction () est
complexe. Je me demande si je ne vais pas la réécrire et mettre en forme
les données au niveau de l'interface avec l'importation des fichiers
OFX, QIF et CSV.

Ce serait plus clair.

--
A+

Pierre Biava

Ludovic Rousseau

2018-10-15 19:15:21 UTC

Permalink

Post by Ludovic Rousseau
Bonjour,

En fait le problème vient du fait que la banque ne détaille pas le moyen
de paiement. Du coup libofx ne peut pas ranger le débit dans la bonne case.

Ma banque (Caisse d'Epargne) propose aussi les format CSV et QIF pour
récupérer les transactions. Mais il n'y a pas plus d'information dans
ces formats.

Ça ressemble à quoi un enregistrement OFX avec les bonne informations ?
Je peux remonter le problème à ma banque (même si il y a peu d'espoir
qu'ils changent quelque chose).

La spécification OFX 2.2 fait 695 pages et je n'ai pas encore tout lu :-)
http://www.ofx.net/downloads/OFX%202.2.pdf

Post by Ludovic Rousseau
Ceci étant dit, comme je mets le bon moyen de paiement, le numéro de
chèque disparaît car il n'est pas utile.

C'est une bonne idée car ça limiterai le nombre de fausses informations.
Il reste le cas des Virements qui ont parfois un numéro valide.

Ça doit fonctionner comme ça. Il faut remplacer CHEQUE par _("Check") et
utiliser la formule de recherche my_strcasecmp (). Ça devrait fonctionner.

strstr(3) recherche un chaine dans une chaine.
my_strcasecmp() ne fait pas la même chose.

J'ai modifié le code pour utiliser strcasestr(3) pour être insensible
à la casse.
Par contre _("Check") ne fonctionne pas car ma banque utilise "CHEQUE"
et pas "CHÈQUE" ou "Chèque". L'accent pose problème.

Si le problème vient des données fournies par la banque il vaut mieux
corriger le problème à la source. Même si ça peut prendre du temps.

Post by Ludovic Rousseau
A voir. La fonction d'importation gsb_import_create_transaction () est
complexe. Je me demande si je ne vais pas la réécrire et mettre en forme
les données au niveau de l'interface avec l'importation des fichiers
OFX, QIF et CSV.
Ce serait plus clair.

En tout cas la fonction gsb_import_create_transaction () duplique du
code et c'est mal :-)

Merci

--
Dr. Ludovic Rousseau

Pierre Biava

2018-10-16 09:16:41 UTC

Permalink

Ludovic Rousseau a écrit le 15/10/2018 à 21:15 :

Re,

Post by Ludovic Rousseau
Ma banque (Caisse d'Epargne) propose aussi les format CSV et QIF pour
récupérer les transactions. Mais il n'y a pas plus d'information dans
ces formats.

Ça dépend des banques. Ainsi dans grisbi j'avais ajouté une option
spécifique pour les fichiers QIF de la Société Générale. Toutefois ça
reste marginal. Les banques font le minimum.

Post by Ludovic Rousseau
Ça ressemble à quoi un enregistrement OFX avec les bonne informations ?
Je peux remonter le problème à ma banque (même si il y a peu d'espoir
qu'ils changent quelque chose).
La spécification OFX 2.2 fait 695 pages et je n'ai pas encore tout lu :-)
http://www.ofx.net/downloads/OFX%202.2.pdf

La structure GsbOfxTransactionType dans structures.h donne les types
d'information qu'on pourrait trouver mais je n'ai pas encore vu de
fichiers avec ce détail de données.

Post by Ludovic Rousseau

Post by Pierre Biava
Ceci étant dit, comme je mets le bon moyen de paiement, le numéro de
chèque disparaît car il n'est pas utile.

C'est une bonne idée car ça limiterai le nombre de fausses informations.
Il reste le cas des Virements qui ont parfois un numéro valide.
J'ai modifié le code pour utiliser strcasestr(3) pour être insensible

à la casse.
Par contre _("Check") ne fonctionne pas car ma banque utilise "CHEQUE"
et pas "CHÈQUE" ou "Chèque". L'accent pose problème.
Si le problème vient des données fournies par la banque il vaut mieux
corriger le problème à la source. Même si ça peut prendre du temps.

Effectivement c'est plus compliqué que je pensais. Immédiatement on
pourrait changer la traduction de "Check" par "Cheque" ce qui résoudrait
provisoirement le problème.

Il faut que je revoie la fonction utils_str_remove_accents () pour la
généraliser car elle ne gère que les lettres. Du coup on pourrait
peut-être l'utiliser dans ce cas pour trouver la bonne correspondance.

Bonne journée.

--
A+

Pierre Biava