[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