[Kmymoney-devel] [kmymoney4] [Bug 319801] program looses track of check number if check number sequence is interrupted.

[allan]

https://bugs.kde.org/show_bug.cgi?id=319801

allan <agander93 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |agander93 at gmail.com

--- Comment #2 from allan <agander93 at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.