[grisbi-bugs] [Grisbi 0002111]: Inrémentation automatique du numéro de chèque incorrecte

Grisbi Bug Tracker bugtracker at grisbi.org
Lun 6 Sep 13:27:08 CEST 2021


The following issue has been RESOLVED. 
====================================================================== 
https://www.grisbi.org/bugsreports/view.php?id=2111 
====================================================================== 
Reported By:                ghpom
Assigned To:                pbiava
====================================================================== 
Project:                    Grisbi
Issue ID:                   2111
Category:                   Main
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
OS:                         Debian 
Unstable Impact:            No 
Version OS:                 10 
Version GTK:                3.24.5 
Resolution:                 fixed
Fixed in Version:           development (git)
====================================================================== 
Date Submitted:             2021-02-28 09:25 CET
Last Modified:              2021-09-06 13:27 CEST
====================================================================== 
Summary:                    Inrémentation automatique du numéro de chèque
incorrecte
Description: 
Sous certaines conditions, grisbi propose automatiquement un numéro de chèque
pour lequel une transaction existe déjà.

C'est une fonctionnalité très pratique mais ce bug est pénible dans le sens
ou l'on doit vérifier les numéros de chèques dans son carnet à chaque
nouvelle transaction de ce type ce qui implique d'avoir le chéquier sous la
main.

Steps to Reproduce: 
1. Créer une transaction par chèque avec le numéro 2.
2. Créer une transaction par chèque, le numéro 3 est automatiquement mis dans
la case, ce qui est correct. Remplacer par le numéro 1.
3. Créer une transaction par chèque, le numéro 2 est automatiquement mis dans
la case, ce qui est incorrect car déjà existant.

Cas différent :
1. Créer une transaction par chèque avec le numéro 4 à date du jour.
2. Créer une transaction par chèque à date du jour, le numéro 5 est
automatiquement mis dans la case.
3. Incrémenterer la date de la transaction en 1. 
4. Créer une transaction par chèque, le numéro 5 est automatiquement mis dans
la case, ce qui est incorrect.


Additional Information: 
Grisbi ne retient que le numéro utilisée lors de la dernière validation d'une
transaction par chèque. Propositions :
- Scanner la liste des transactions à la recherche du numéro le plus élevé
(à l'init ?) et ne retenir toujours que le numéro le plus élevé même quand
l'utilisateur réédite une ancienne transaction par chèque (en changeant la
date par exemple). En revanche, je ne sais pas si il est possible que les
numéros soient inférieurs avec un nouveau chéquier...
- Scanner la liste à la recherche de la dernière transaction par chèque et
retenir ce numéro. Dans ce cas, sur quel critère trier la liste ? Par ordre
croissant de création des transactions ? 
====================================================================== 

---------------------------------------------------------------------- 
 (0006319) pbiava (administrator) - 2021-09-04 13:19
 https://www.grisbi.org/bugsreports/view.php?id=2111#c6319 
---------------------------------------------------------------------- 
C'est très compliqué de "deviner" le prochain numéro de chèque en
particulier si deux chéquiers sont utilisés sur le même compte.
Pour résoudre ton cas, il me parait plus simple de ne pas mettre à jour le
dernier numéro de chèque en cas de modification de l'opération. 

---------------------------------------------------------------------- 
 (0006322) pbiava (administrator) - 2021-09-06 13:27
 https://www.grisbi.org/bugsreports/view.php?id=2111#c6322 
---------------------------------------------------------------------- 
fixed in github 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2021-02-28 09:25 ghpom          New Issue                                    
2021-09-04 12:40 pbiava         Assigned To               => pbiava          
2021-09-04 12:40 pbiava         Status                   new => assigned     
2021-09-04 13:19 pbiava         Note Added: 0006319                          
2021-09-06 13:27 pbiava         Status                   assigned => resolved
2021-09-06 13:27 pbiava         Resolution               open => fixed       
2021-09-06 13:27 pbiava         Fixed in Version          => development (git)
2021-09-06 13:27 pbiava         Note Added: 0006322                          
======================================================================



Plus d'informations sur la liste de diffusion bugsreports