Bug 36846 - Collected and change variables are set to 0.00 when printing from POS Transaction history
Summary: Collected and change variables are set to 0.00 when printing from POS Transac...
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Martin Renvoize (ashimema)
QA Contact: Testopia
URL:
Keywords:
Depends on: 40305 24381
Blocks:
  Show dependency treegraph
 
Reported: 2024-05-13 20:41 UTC by Lucas Gass (lukeg)
Modified: 2025-08-14 16:55 UTC (History)
7 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 36846: PROOF OF ISSUE (1.03 KB, patch)
2024-11-24 12:47 UTC, Jacob O'Mara
Details | Diff | Splinter Review
Bug 36846: Fix 'tendered' vs 'collected' variable name inconsistency (13.94 KB, patch)
2025-07-04 08:58 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 36846: Add database update to fix existing notice templates (4.52 KB, patch)
2025-07-04 08:58 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Gass (lukeg) 2024-05-13 20:41:14 UTC
TO recreate:
1. Configure your Koha to enable the point of sale system (i.e. enable syspref,
   set up a register, set up an item to sell).
2. Complete a transaction in the POS system.
3. Go to Cash summary for { THIS BRANCH }
4. Click on the line with a link that includes your register name. ( /cgi-bin/koha/pos/register.pl?registerid=X )
5. Click 'Print receipt'.
6. Tendered ( collected ) and Change ( change ) are 0.00
Comment 1 Sam Lau 2024-08-23 15:07:00 UTC
After completing a transaction, if you press the print receipt button at the top on the pos/pay.pl page, the receipt prints fine. That is because we have direct access to the 'collected' and 'change' variables and can pass them in the print receipt href. However, from the register summary page, these variables are now gone, so when we press print, they are both 0. It doesn't appear like these are stored anywhere so I think we would need to add them to the DB in order for this to work.
Comment 2 Jacob O'Mara 2024-11-24 12:43:11 UTC
This seems to also be an issue in accounts->make a payment
The change and tendered variables do not populate.

To recreate:
1. Enable syspref ('FinePaymentAutoPopup')
2. Change the ACCOUNT_CREDIT notice for print to contain:
```
[% USE Price %]
[% PROCESS 'accounts.inc' %]
<table>
  <tr>
    <td colspan="3">Amount tendered: </td>
    <td>[% tendered | $Price %]</td>
  </tr>
  <tr>
    <td colspan="3">Change given: </td>
    <td>[% change | $Price %]</td>
  </tr>
<table>
```
3. Create a Manual invoice for a patron for any amount.
4. Go to pay this charge
5. Tender a greater amount than the amount of the charge
6. Observe the receipt generated has 0 for change given and amount tendered.

So we can actually get the change given to populate correctly with a small patch to modify the expected variable from change to change_given (I've also modified the return variable to change_given in my patch as I believe this is the intended return variable so make sure to amend the notice from <td>[% change | $Price %]</td> to <td>[% change_given | $Price %]</td> to match)


Apply patch
Repeat steps 3-5
See that the change given now populates correctly.

Tendered however is not even passed in to the url so this needs further looking.
Comment 3 Jacob O'Mara 2024-11-24 12:47:50 UTC Comment hidden (obsolete)
Comment 4 Martin Renvoize (ashimema) 2025-07-04 08:58:08 UTC Comment hidden (obsolete)
Comment 5 Martin Renvoize (ashimema) 2025-07-04 08:58:10 UTC Comment hidden (obsolete)
Comment 6 Martin Renvoize (ashimema) 2025-07-04 09:01:28 UTC
There are two distinct things here.. Jacob has highlighted a bug in the controllers/templates/notices for live payments.. whilst Lucas's bug is more around reproducability of receipt printing.. if you print after the fact we don't know the tendered and change amounts as we don't store those.

We could add these prints to the notice queue, allowing for a future reprint.. but then we could be adding a lot of additional baggage to that table?

Anyway.. I've dealt with Jacob's issue here and I'm open to suggestions regarding the initial report..

We should probably split the bug up again however.
Comment 7 Martin Renvoize (ashimema) 2025-07-04 09:04:25 UTC
Additional note.. I believe the default notices put the change and tendered displays within an IF block for precisely this.. to prevent noisy 0.00 amounts in reprints after the fact.
Comment 8 Martin Renvoize (ashimema) 2025-07-04 09:10:25 UTC
I've split the bugs.. see bug 40305 for my patches around existing inconsistencies.
Comment 9 Cheryl 2025-08-14 16:55:57 UTC
If you choose email (instead of print) right after the transaction, "tendered" will also be incorrectly zero in that case. "Change" did populate correctly.

e.g. text of email (I had put $21 in the "tendered" field when I did the transaction):

Main Library
08/12/2025
Transaction ID: 1097913
Operator ID: 	312879
Payment type: 	CASH
	
Fee receipt
	
Description of charges	                Amount
Black and White copies or prints	-0.15
Black and White copies or prints	-0.15
Tech Fee (meeting rooms)	        -20.00

Total: 	        20.30
Tendered: 	0.00
Change: 	0.70