[grisbi-bugs] [Grisbi 0000540]: Migration des rapprochements

bugtracker at grisbi.org bugtracker at grisbi.org
Sun Apr 19 00:18:36 CEST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://grisbi.tuxfamily.org/mantis/view.php?id=540 
====================================================================== 
Reported By:                MyKeul
Assigned To:                pbiava
====================================================================== 
Project:                    Grisbi
Issue ID:                   540
Category:                   Main
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
OS:                         Debian 
Unstable Impact:            Yes 
Version OS:                  
Version GTK:                 
====================================================================== 
Date Submitted:             04-17-2009 21:35 UTC
Last Modified:              04-18-2009 22:18 UTC
====================================================================== 
Summary:                    Migration des rapprochements
Description: 
En 0.5.9, il est possible (malgré un avertissement) d'utiliser un même nom
de rapprochement sur plusieurs comptes. (Vu que j'ai plusieurs comptes
détaillés sur un même relevé papier, ça me semblait logique d'utiliser le
même nom).

Dans mon fichier gsb, j'ai donc une multitude d'opérations ayant le même
R="nnn" répartis sur plusieurs comptes.

Dans la version CVS, les rapprochements sont rattachés à un et un seul
compte, mais ce cas n'est visiblement pas pris en compte lors de la
migration des données. Les rapprochements sont répartis aléatoirement
(enfin certainement suivant l'ordre des comptes dans le fichier, ou quelque
chose du genre) sur les différents comptes, mais des données sont perdues
et/ou non affichables. Dans la liste des rapprochements, certains comptes
n'en ont aucun (de rapprochement) alors que les données sont bien présentes
dans le fichier (les Re="nnn" sont bien là).

Pistes :
* Dans le modèle de données (dans le xml), la déclaration des noms de
rapprochements ne devraient-elle pas être locale à chaque compte ? (Ce qui
résoudrait naturellement le problème)
* Solution à priori moins couteuse en développement : lors de l'import, un
croisement entre les nom de comptes et de rapprochement permettrait de
contourner le problème.
====================================================================== 

---------------------------------------------------------------------- 
 pbiava - 04-18-09 22:18  
---------------------------------------------------------------------- 
Je n'ai pas constaté de problème particulier dans l'import des
rapprochements. J'ai regardé le code mais je n'ai rien vu de particulier.
Le programme actuel tient bien compte du numéro de compte pour reconstituer
la liste des rapprochements d'un compte.

Pour essayer d'avancer j'ai modifié l'import du fichier pour afficher ce
qui est fait lors de l'import. Si tu pouvais recompiler avec cette version
ça nous avancerais peut-être.

après compilation il faut lancer grisbi dans une console après avoir entré
les commandes suivantes :

export DEBUG_GRISBI=5 puis ENTER
grisbi

cela devrait afficher tout un tas de ligne dans la console avec un tableau
des différents rapprochements listés par compte. C'est ce tableau qu'il
faut étudier pour voir si des anomalies ont été rencontrées. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-17-09 21:35  MyKeul         New Issue                                    
04-17-09 21:35  MyKeul         OS                        => Debian          
04-17-09 21:35  MyKeul         Unstable Impact           => Yes             
04-17-09 22:14  pbiava         Status                   new => assigned     
04-17-09 22:14  pbiava         Assigned To               => pbiava          
04-18-09 22:18  pbiava         Note Added: 0000882                          
======================================================================



More information about the bugsreports mailing list