After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653594 - wrong amount printed on checks
wrong amount printed on checks
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Check Printing
2.4.x
Other Linux
: Normal normal
: ---
Assigned To: David Hampton
Depends on:
Blocks:
 
 
Reported: 2011-06-28 20:55 UTC by chuck h
Modified: 2018-06-29 22:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
check printing file for 3 part voucher checks. (1.43 KB, text/plain)
2011-06-28 20:55 UTC, chuck h
Details

Description chuck h 2011-06-28 20:55:02 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)
Comment 1 Kent Lorentzen 2013-10-14 17:40:42 UTC
I have had the same issue along with the last line of splits not being printed.
Comment 2 Dennis Shimer 2013-12-05 15:06:25 UTC
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
Comment 3 Mike Alexander 2013-12-05 22:52:10 UTC
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.
Comment 4 Mike Alexander 2013-12-07 07:40:59 UTC
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.
Comment 5 John Ralls 2017-09-24 22:49:09 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 6 John Ralls 2018-06-29 22:59:35 UTC
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.