https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41772 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hdunne-howrie@westminster.g | |ov.uk, | |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41772 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- While looking at receipt variables on main, I noticed the Accounting pages and the POS pages are not consistent about what they hand to the receipt notice, which is another reason to store these amounts as this bug proposes. What happens today on main: - POS: pos/pay.tt opens pos/printreceipt.pl with both tendered and change, and the RECEIPT notices print both. - Accounting: members/pay.tt, members/paycollect.tt and members/boraccount.tt open members/printfeercpt.pl with change only (since Bug 43288). printfeercpt.pl does read a tendered parameter, but nothing ever sends it. - The stock ACCOUNT_CREDIT notice only prints "Change given", so on a stock install nothing looks wrong. But the DBRev for Bug 40305 treats ACCOUNT_CREDIT as a notice that can receive tendered and change, so any ACCOUNT_CREDIT or CREDIT_* notice that shows [% tendered %] prints it empty when the receipt is opened from the Accounting pages. - A reprint from the account lines (members/boraccount.pl) sends neither value, so tendered and change are lost for every receipt, on both paths. Suggestion: record tendered and change with the transaction, as this bug proposes. The Accounting receipts and every reprint would then show the same figures as the original, and the URL parameters between pay.tt, paycollect.tt and printfeercpt.pl could go away. A notice could read the values from the credit instead of relying on substitutions. These amounts only mean something for a cash payment, so I would not add new notice variables for other credit types such as write-offs or refunds. In the meantime, a workable stop-gap in printfeercpt.pl is to work the amount tendered out as the amount paid plus the change given when only change is supplied, letting an explicit tendered parameter win. That does not help reprints, which is why storing the values is the better fix. If it helps, I can attach a patch for the stop-gap, or for storing the values, once there is agreement on where to keep them (for example extra columns on the cash register action or accountline, or an offset note). -- You are receiving this mail because: You are watching all bug changes.