If I make a non-numeric note in the ledger number field, KMyMoney looses track of the next check number. It always reverts to number 1 in the next transaction. Reproducible: Always Steps to Reproduce: 1.enter several checking transactions, using number (for example) 1000, 1001, 1002, 1003, 1004 - then: 2.enter a debit transaction and enter EFT in the number box, then: 3.enter another transaction - KMyMoney will offer the check number 1 instead of 1005 Many transactions do not have a number, such as EFT (electronic fund transfer) and ATM (automated teller machine). To help keep track of these transactions, I enter EFT or ATM in the number box in the ledger window. If I enter several consecutive checks , KMyMoney offers the correct check number in each new transaction. If I enter EFT or ATM, the next transaction that follows will offer the number 1 in the number box, not the correct check number. FYI: PCLinuxOS 2013 64 is my operating system. I hope I have explained this clearly. I am new to Linux and KMyMoney.
On Mon, 13 May 2013 20:18:17 +0000 <jr09877@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=319801 > > Bug ID: 319801 > Summary: program looses track of check number if check > number sequence is interrupted. > Classification: Unclassified > Product: kmymoney4 > Version: 4.6.3 > Platform: Other > OS: Linux > Status: UNCONFIRMED > Severity: normal > Priority: NOR > Component: general > Assignee: kmymoney-devel@kde.org > Reporter: jr09877@gmail.com > > If I make a non-numeric note in the ledger number field, KMyMoney > looses track of the next check number. It always reverts to number 1 > in the next transaction. > > Reproducible: Always > > Steps to Reproduce: > 1.enter several checking transactions, using number (for example) > 1000, 1001, 1002, 1003, 1004 - then: > 2.enter a debit transaction and enter EFT in the number box, then: > 3.enter another transaction - KMyMoney will offer the check number 1 > instead of 1005 > > > > Many transactions do not have a number, such as EFT (electronic fund > transfer) and ATM (automated teller machine). To help keep track of > these transactions, I enter EFT or ATM in the number box in the > ledger window. If I enter several consecutive checks , KMyMoney > offers the correct check number in each new transaction. If I enter > EFT or ATM, the next transaction that follows will offer the number 1 > in the number box, not the correct check number. FYI: PCLinuxOS 2013 > 64 is my operating system. I hope I have explained this clearly. I > am new to Linux and KMyMoney. > Another user reported this same problem yesterday (see Feature request). I see you use just integers for your numbers, yes?
Your explanation was very clear, thanks. [from the lists...] > I suspect it may be different editing an existing transaction from > entering a new one. Entering a new transaction, if you change the > offered number, it probably alters what is remembered as the highest > used number. I believe I've gotten into situations where it tried > to use an already used number, because I missed a check, and entered > it out of order, after I had entered later checks. > > Jack Yes and no. I think the difference was more to do with the position of the transaction within the ledger. Editing a transaction now could result in that item moving up the sort order. Then, another transaction with a valid number may subsequently be found, and then the sequencing will restart. The main problem though, is that there is this comment - " // if a new transaction has a valid number, keep it with the account" and the test is - " if (!number.isEmpty())" so any non-numeric value would get stored. When that value was encountered in a subsequent new transaction, it would be treated as zero, and the number '1' would be the default entry. I've changed it here to store only an integer value, and that seems to work as required. But, might a user want to have a number with a decimal symbol in it? I've tried that too, saving a double, and the decimal part now gets incremented. So, who wants what? For a check number, an integer would be the logical choice, but I think I've seen it used with a prefix - say, the year, eg. 2013.1. That is presently accepted, but the incrementation is confined to the decimal part.
While in this general area, I noticed that an edit of an existing transaction's number does not get saved.
> I've changed it here to store only an integer value, and that seems to work > as required. But, might a user want to have a number with a decimal > symbol in it? I've tried that too, saving a double, and the decimal > part now gets incremented. > > So, who wants what? For a check number, an integer would be the logical > choice, but I think I've seen it used with a prefix - say, the year, eg. > 2013.1. That is presently accepted, but the incrementation is confined to > the decimal part. Having been underwhelmed by the responses, I've decided to accept all the different entries tested for in the unit tests, to ensure that those work, and which allows for mixed alpha and numeric content in the 'number' field.
Submitted to Reviewboard 7 Oct. https://git.reviewboard.kde.org/r/113143/
Git commit 1dede8b9dfb550b3a26e4fc0ade208788c877b2c by Allan Anderson. Committed on 26/01/2014 at 10:49. Pushed by allananderson into branch 'master'. REVIEW:115302 M +16 -8 kmymoney/dialogs/transactioneditor.cpp M +7 -1 kmymoney/dialogs/transactioneditor.h M +14 -0 kmymoney/kmymoneyutils.cpp M +6 -0 kmymoney/kmymoneyutils.h http://commits.kde.org/kmymoney/1dede8b9dfb550b3a26e4fc0ade208788c877b2c
The above commit resolves the initial bug. Additional patch, to handle discovered issues, submitted to Reviewboard https://git.reviewboard.kde.org/r/115338/ on 27 Jan.
Git commit 0a3ef042a8bd7494c5bae192e76a1818beb5c96f by Allan Anderson. Committed on 27/01/2014 at 11:09. Pushed by allananderson into branch 'master'. Related: bug 2 REVIEW:115338 M +43 -12 kmymoney/dialogs/transactioneditor.cpp M +10 -0 kmymoney/kmymoney.cpp M +58 -0 kmymoney/kmymoneyutils.cpp M +14 -0 kmymoney/kmymoneyutils.h http://commits.kde.org/kmymoney/0a3ef042a8bd7494c5bae192e76a1818beb5c96f