[grisbi-bugs] [Grisbi-0.6.0 0000915]: Conversion d'un fichier gsb de la version 0.5.9 vers la version 0.6-cvs - Mauvais rapprochement
bugtracker at grisbi.org
bugtracker at grisbi.org
Tue Mar 16 13:02:02 CET 2010
A NOTE has been added to this issue.
======================================================================
http://grisbi.tuxfamily.org/mantis/view.php?id=915
======================================================================
Reported By: dante
Assigned To: pbiava
======================================================================
Project: Grisbi-0.6.0
Issue ID: 915
Category: Main
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Plateforme: Linux
OS: Autre(Other)
Version OS:
Unstable Impact: Yes
Version GTK:
======================================================================
Date Submitted: 01-27-2010 00:02 UTC
Last Modified: 03-16-2010 12:02 UTC
======================================================================
Summary: Conversion d'un fichier gsb de la version 0.5.9 vers
la version 0.6-cvs - Mauvais rapprochement
Description:
Les rapprochements générés à partir d'une version 0.5.9 d'un fichier .gsb
non buggué sont erronés. En effet, la valeur du dernier rapprochement ne
correspond plus à la vraie valeur sur le compte.
Lorsque l'on regarde la liste ds rapprochements, on peut voir que la
valeur initiale du premier rapprochement est erronée, ainsi que toutes les
valeurs de tout les rapprochements.
Ci-joint, le fichier obfusqué de la version 0.5.9 qui va générer un
fichier faux avec la version 0.6-CVS
======================================================================
----------------------------------------------------------------------
pbiava - 01-28-10 21:58
----------------------------------------------------------------------
Peux-tu rendre anonyme ton fichier et me l'envoyer à l'adresse ci-dessous
:
pierre.biava at nerim.net
----------------------------------------------------------------------
pbiava - 02-14-10 19:06
----------------------------------------------------------------------
pas de nouvelles ni fichier.
----------------------------------------------------------------------
dante - 02-14-10 19:11
----------------------------------------------------------------------
http://dante.kollok.org/tmp/grisbi_debug.zip
Voici les fichiers. anonyme_bogue.gsb correspond à la version original et
anonyme_bogue_0.6.gsb a la version après conversion qui contient donc des
erreurs aux niveaux des rapprochements. Le tout ayant été obfusqué.
----------------------------------------------------------------------
pbiava - 02-14-10 19:36
----------------------------------------------------------------------
Le fichier anonymisé ne fonctionne pas parce que les rubriques ne sont pas
remplies correctement.
je pense que c'est du à "l'anonymisation" du fichier.
à la place des chaines présentes il faut des chiffres. vérifie que dans
ton fichier d'origine c'est le cas et envoie moi les lignes
correspondantes.
<Solde_initial>Solde_initial 1</Solde_initial>
<Solde_mini_voulu>Solde_mini_voulu 1</Solde_mini_voulu>
<Solde_mini_autorise>Solde_mini_autorise 1</Solde_mini_autorise>
<Solde_courant>Solde_courant 1</Solde_courant>
Comme tous tes comptes sont comme ça je ne peux rien faire.
----------------------------------------------------------------------
dr4Ke - 03-13-10 17:01
----------------------------------------------------------------------
J'ai voulu mettre des valeurs initiales et courantes pour ses comptes mais
ils semblent plus que corrompus. Toutes les lignes sont en crédit. Il n'a
aucun débit.
De plus, les valeurs semblent complètement farfelues (35.7399815547836,
899.221746620551...).
C'est inutilisable.
----------------------------------------------------------------------
dr4Ke - 03-13-10 17:48
----------------------------------------------------------------------
Sur mon fichier de compte, j'ai aussi un problème avec les rapprochements
sur un seul compte. J'ai remarqué que j'avais utilisé le même nom de
rapprochement sur différents comptes. Du coup, j'ai des transactions de
comptes différents qui pointent sur le même numéro de rapprochement. Je ne
sais pas comment ce cas est géré lors de la conversion.... J'étudie un peu
le code pour voir.
EDIT: après avoir jeté un oeil, le code prend déjà en compte ce cas. Je
vais chercher ailleurs.
Sinon, comment puis-je, simplement, anonymiser mon fichier de comptes en
version 0.5.9 ?
----------------------------------------------------------------------
pbiava - 03-13-10 20:50
----------------------------------------------------------------------
Pour anonymiser ton fichier de compte tu vas sur le site de grisbi ici :
http://www.grisbi.org/bugtracking.fr.html
tu télécharges le script obfuscate.pl et tu fais ce qui est dit dessous.
Tu m'envoies le fichier ensuite.
Pour le problème des rapprochements je crée autant de rapprochements que
ce que j'en trouve dans las opérations. Le fait qu'ils portent le même nom
pour plusieurs comptes n'a pas d'importance.
Pour les montants il se peut qu'il y ait des problèmes de séparateurs qui
expliquent ces chiffres bizarres.
On regardera dans le détail mais si les opérations sont bonnes on peut
reprendre les rapprochements assez facilement.
----------------------------------------------------------------------
dr4Ke - 03-14-10 10:11
----------------------------------------------------------------------
Les montants sont modifiés par le script obfuscate.pl de manière aléatoire.
C'est cela qui donne les montants étranges.
Je ne suis pas sûr que cela influe sur le résultat, cependant.
Voici le fichier anonyme :
http://dedibox.dr4ke.net/Comptes-0.5-obfuscated.gsb
Je n'ai pas réussi à l'uploader. Est-ce un problème sur le serveur mantis
?
Les rapprochements faux sont sur le compte "Nom 1"
----------------------------------------------------------------------
dr4Ke - 03-14-10 18:08
----------------------------------------------------------------------
Le problème vient de la date du dernier relevé qui est erronée. J'ai fait
des rapprochements de manière irrégulière et le dernier rapprochement sur
ce compte contient des opérations datées du 4/6/2005 au 31/8/2005.
Quand j'ai fait ce rapprochement, j'ai laissé la date de relevé proposée
(4/7/2005).
Sur ce compte, j'ai 6 relevés :
1: 3/1/2004 -> 5/10/2004, bal: 300, solde initial : 0
2: 7/10/2004 -> 3/11/2004, bal: 200, solde initial : 300
3: 2/11/2004 -> 10/1/2005, bal: -120, solde initial : 500
4: 10/1/2005 -> 15/3/2005, bal: -300, solde initial : 380
5: 19/3/2005 -> 3/6/2005, bal: 130, solde initial : 80
6: 4/6/2005 -> 31/8/2005, bal : -200, solde initial : 210
Date du dernier relevé : 4/7/2005.
Solde du dernier relevé : 10 (qui correspond bien au solde après la
dernière opération du rapprochement 6)
Comme la différence entre 4/7/2005 et 31/8/2005 est supérieure à 10 jours,
grisbi considère que le rapprochement 6 n'est pas le dernier en date et
tente de recalculer le solde du dernier relevé en cherchant le dernier
rapprochement dont la date finale est située avant la date du dernier
relevé. Ici, le 5.
Du coup, grisbi pense que le solde du dernier relevé (10), est celui du
rapprochement 5.
En gros, on peut conclure que le problème vient de mon fichier qui
contient une erreur de date.
Néanmoins, je ne vois pas comment il serait possible d'avoir des
rapprochements après la date du dernier relevé. On ne peut pas, il me
semble, faire des rapprochements n'importe comment. Cela supposerait de
pouvoir faire des rapprochements dans le désordre. Est-ce possible ?
Pour ma part, j'aurais pris le dernier rapprochement ET le solde du
dernier relevé et je n'aurais pas tenu compte de la date du dernier
relevé.
Je vais corriger l'erreur dans mon fichier et regarder si celui fourni par
dante contient la même erreur que le mien.
D'autre part, je ne pense pas qu'on puisse bien débugger cette erreur avec
un fichier anonyme car, dans celui-ci, le solde du relevé ne correspond à
aucun solde réel puisque tout est aléatoire.
----------------------------------------------------------------------
pbiava - 03-14-10 20:14
----------------------------------------------------------------------
Tous est question d'appréciation. J'étais parti du principe que ce qui est
juste ce sont les opérations marquées rapprochées. A partir de la je recrée
les rapprochements. Ça me parait plus pertinent mais ça se discute.
Ton fichier en 0.5 est sans erreur de rapprochement quand tu fais le test
?
----------------------------------------------------------------------
dr4Ke - 03-16-10 09:56
----------------------------------------------------------------------
Sur le fichier que j'ai fourni, le passage en 0.6 provoque des
rapprochements erronés sur le compte "Nom 1".
Par contre, en modifiant la date du dernier relevé à une date ultérieure à
mon dernier rapprochement, je n'ai plus d'erreur.
Je suis d'accord que les opérations marquées rapprochées sont la bonne
source d'information. Je ne pense pas que la date de dernier relevé soit à
prendre en compte du tout. Pour moi, il n'est pas possible d'avoir un
rapprochement après cette date. Donc, s'il y en a, c'est que cette date est
erronée. Du coup, soit on ne la regarde même pas, soit, on avertie
l'utilisateur qu'il y a une incohérence et que cette date n'a pas été prise
en compte. Qu'en penses-tu ?
J'y penses maintenant. Ne peut-on pas valider la série des rapprochements
en comparant le solde initial calculé du premier rapprochement avec le
solde initial du premier compte (s'il n'y a pas d'opération antérieure non
rapprochée.) Et s'il y en a, on pourrait partir du solde initial calculé du
premier rapprochement, retrancher les montants des opérations non
rapprochées antérieures et vérifier qu'on retombe sur le solde initial du
compte.
Ou dans l'autre sens :
partir du solde initial du compte, ajouter les montants des opérations non
rapprochées jusqu'à la première opération rapprochée. On obtiendait ainsi
le solde initial du premier rapprochement. On vérifie, au dernier
rapprochement, que le calcul tombe bien sur le solde du dernier relevé.
Si tu es d'accord pour l'une ou l'autre de ces idées, je peux essayer de
l'implémenter pour tests...
----------------------------------------------------------------------
pbiava - 03-16-10 12:02
----------------------------------------------------------------------
[citation]
Donc, s'il y en a, c'est que cette date est
erronée. Du coup, soit on ne la regarde même pas, soit, on avertie
l'utilisateur qu'il y a une incohérence et que cette date n'a pas été
prise
en compte. Qu'en penses-tu ?
Il faut que je me replonge dans le code mais effectivement on pourrait
ignorer cette date.
Pour le reste quelque soit la solution il y aura des cas ou ça ne
fonctionnera pas donc on va attendre de voir avant de faire autre chose.
Je vais clore le bug.
Issue History
Date Modified Username Field Change
======================================================================
01-27-10 00:02 dante New Issue
01-28-10 21:58 pbiava Note Added: 0001765
01-30-10 08:29 pbiava Status new => assigned
01-30-10 08:29 pbiava Assigned To => pbiava
02-14-10 19:06 pbiava Plateforme => Linux
02-14-10 19:06 pbiava OS => Autre(Other)
02-14-10 19:06 pbiava Unstable Impact => Yes
02-14-10 19:06 pbiava Status assigned => resolved
02-14-10 19:06 pbiava Fixed in Version => 0.6.0rc2
02-14-10 19:06 pbiava Resolution open => no change
required
02-14-10 19:06 pbiava Note Added: 0002018
02-14-10 19:11 dante Status resolved => feedback
02-14-10 19:11 dante Resolution no change required =>
reopened
02-14-10 19:11 dante Note Added: 0002020
02-14-10 19:36 pbiava Note Added: 0002022
02-23-10 19:51 dr4Ke Issue Monitored: dr4Ke
03-13-10 17:01 dr4Ke Note Added: 0002193
03-13-10 17:04 dr4Ke Note Added: 0002194
03-13-10 17:48 dr4Ke Note Edited: 0002194
03-13-10 20:50 pbiava Note Added: 0002195
03-14-10 10:05 dr4Ke Note Added: 0002199
03-14-10 10:11 dr4Ke Note Edited: 0002199
03-14-10 18:08 dr4Ke Note Added: 0002204
03-14-10 20:14 pbiava Note Added: 0002206
03-16-10 09:56 dr4Ke Note Added: 0002216
03-16-10 09:56 dr4Ke Note Edited: 0002216
03-16-10 12:02 pbiava Note Added: 0002218
======================================================================
More information about the bugsreports
mailing list