GNOME Bugzilla – Bug 653594
wrong amount printed on checks
Last modified: 2018-06-29 22:59:35 UTC
Created attachment 190889 [details] check printing file for 3 part voucher checks. When printing checks, sometimes the wrong amount of a split transaction is printed on the check. Sometimes the check amount will be for just one entry of a split transaction. All entries will print on the check stub, and the register will show that the check was for the total amount, The register will still show that the complete amount was printed. See below. Transaction Report From 06/26/2011 To 12/31/2011 Date Num Description Memo/Notes Amount Trash Service June 2011 06/26/2011 2010 Lloyds Loads 1304 S Rouse $18.50 06/26/2011 2010 Lloyds Loads 1908 Windsor $18.50 06/26/2011 2010 Lloyds Loads 502,504 Village $37.00 06/26/2011 2010 Lloyds Loads 601 Canterbury $18.50 06/26/2011 2010 Lloyds Loads 606,608,616,620 631 Village $111.00 Total For June 2011 $203.50 Total For Trash Service $203.50 Grand Total $203.50 We are using a 3part voucher check. I modified the check print file to print split memos. See attached file. Transaction report did not print in the order of entry in the register. The check was actually printed for $37.00, which was the first entry of the split transaction. The register still says the check amount was 203.50. This was entered as a split transaction, 1 203.50 credit, and 5 debits for 37.00,111.00,18.50,18.50,18.50 It appears that if the curser is on one entry of a split transaction (the 37.00 entry) when CTRL-P is pressed, the check is printed only for the single amount. The check stub will print all 5 entries and amounts totalling 203.50, even though the check is only for 37.00 If the cursor is on the cash account (the 203.50 entry) and CTRL-P is pressed, then the check will print for the correct amount. However, the register will show the check amount for the totoal amount (203.50) instead of what the check was actually written for (37.00)
I have had the same issue along with the last line of splits not being printed.
I am also having the same problem with the last line of a split missing. I spent some time messing around before I came across this but, the thread can be found at. If someone knows another more relevant bug I should be following I'd love to know it, I just stumbled on Kent's comment. http://lists.gnucash.org/pipermail/gnucash-user/2013-December/051601.html
There are two separate issues discussed in this bug report. The first one has to do with which split in a transaction controls the amount printed on a check. If the transaction is expanded and a specific split is selected then print check will print a check with an amount taken from that split. I think this is intentional. Suppose you have a transaction that has two or more splits from one or more checking accounts. By selecting the split you care about you can print a any of the relevant checks. It is probably wrong to select a split from an account that isn't a bank account, but it currently doesn't check for that. Otherwise I think it's probably working as intended. The other problem mentioned is that if you print to a check format that itemizes splits, then the last split doesn't print. This is correct, but I'm not sure whether this is a bug or intentional. I suspect it's just a bug, but it's possible that the person who wrote that assumed that the last split will be the one for the checking account whose check is being printed. For simple transactions with one credit to a single checking account and several debits to different expense accounts this will be true. However it's not true in the case that led to the EMail discussion referenced above. I'll see what I can do about cleaning this up a bit.
I just checked in r23497 which should fix the problems described here. It selects the split to use to print the check (from which it gets the amount for the check) as follows: if the transaction is expanded and a split for the account shown in the register is selected, use that split. Otherwise use the split that anchors the transaction to the register. If there is only one split in the register's account, that one will be used. Otherwise which one it uses depends on whether you are using the old or new register code and whether the register is in "Transaction Journal" mode. If you really care about this case you should expand the transaction and select the split you want. I also changed it to always omit the split from which the check's value is obtained from the split lists it prints for SPLITS_MEMO, SPLITS_ACCOUNT, and SPLITS_AMOUNT instead of omitting the last split.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=653594. Please update any external references or bookmarks.