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
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.
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.
Created attachment 174961 [details] [review] Bug 36846: PROOF OF ISSUE This patch is a proof of issue and not a fix.
Created attachment 183785 [details] [review] Bug 36846: Fix 'tendered' vs 'collected' variable name inconsistency "One Ring to rule them all, one Ring to find them, One Ring to bring them all and in the darkness bind them" We've been battling against this for years, with a mixed use of terminology and thus confusion in templates vs controllers and notice templates. I've decided to just try and make sure all the terminology matches throughout, and use the more popular 'tendered' term over the 'collected' term. This patch standardizes the terminology used throughout the payment system to consistently use 'tendered' instead of the mixed usage of 'collected' and 'tendered' that has caused confusion over the years. Changes include: - Update all payment form templates to use 'tendered' input names - Update JavaScript validation and change calculation logic - Update controller parameter handling in pos/pay.pl, pos/printreceipt.pl, and members/paycollect.pl - Update sample notice templates (RECEIPT) to use 'tendered' variable - Add null check for $total_tendered to prevent perl warnings Test plan: 1. Test Point of Sale payments with tendered amounts and change calculation 2. Test member account payments with tendered amounts 3. Test receipt generation (both print and email) 4. Verify JavaScript validation works correctly 5. Confirm no perl warnings when tendered amount is undefined
Created attachment 183786 [details] [review] Bug 36846: Add database update to fix existing notice templates This database update fixes existing RECEIPT and ACCOUNT_CREDIT notice templates that may still use the old 'collected' variable instead of 'tendered'. It handles various formatting patterns and provides verification that the conversion was successful.
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.
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.
I've split the bugs.. see bug 40305 for my patches around existing inconsistencies.
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