Bug 36846

Summary: Collected and change variables are set to 0.00 when printing from POS Transaction history
Product: Koha Reporter: Lucas Gass (lukeg) <lucas>
Component: Fines and feesAssignee: Martin Renvoize (ashimema) <martin.renvoize>
Status: In Discussion --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: clackman, jacob.omara, lisette, martin.renvoize, pedro.amorim, sally.healey, samalau
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 40305, 24381    
Bug Blocks:    
Attachments: Bug 36846: PROOF OF ISSUE
Bug 36846: Fix 'tendered' vs 'collected' variable name inconsistency
Bug 36846: Add database update to fix existing notice templates

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