When duplicating a transaction (Transaction / Duplicate Transaction), values are requested for the new transaction's Date and Number fields. However, if the value entered for the Number is non-numeric, it is discarded, and the Number field in the new transaction is left blank. The Number field, whilst designed to support incrementing numeric values, accepts non-numeric values during normal data entry into the register. From the user's point of view, the duplicate transaction operation should not behave any different. (And NB - please do not even *think* of enforcing numeric data in the number field - it would render gnucash useless in many applications!!! :-)
Yes I am also using a beginning letter for the folder, where the voucher is stored. * The register has no restrictions for the number field, * The Action->"Transfer Funds" dialogue has no restriction, but * Transaction->"Duplicate Transaction" has. OTOH: Register has the +/- funtionality to change the number and Duplicate Transaction has a similar functionality with the up/down buttons. So I fear other users could miss this. But then again the number of the old or last transaction is not remembered by the dialog and so this functionality is of less use. So I think we should replace or tweak the GTKSpinButton to allow non numeric input. I do not really understand ste meaning of the "numeric" property, which the buton could have.
I have changed the duplicate transaction dialog to use GtkEntry widgets instead of the GtkSpinbuttons which is the same as the register and transfer dialog. This will be in the next nightly or version 4.3
*** Bug 724423 has been marked as a duplicate of this bug. ***
I'm getting unexpected behaviour in the Num field in 4.4 (and 4.3 and 4.2 but I wasn't noticing the quick change) and this seems to be the most likely change that has caused it. I think this should be opened again OR point me to the "fix" that made the change so I can look at that OR I can start a new bug I think the underlying issue isn't so much the duplication so much as the overuse of the field. To be clear: I think the main problem is database laziness that we have discussed before. Ergo: we have a "field" called "Num" that has multiple uses and purposes. Of course something is going to go wrong! If you want to see how weird things can get, create a tx with splits and then toggle File / Properties / Accounts / Use split action field weird things happen because the field is overused. We *know* the database needs to be fixed! Re-open this and add this to the pressure point for db work. If you think this was fixed you are wrong.
