https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43290 Bug ID: 43290 Summary: Cashup summary totals can carry excess decimal precision Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Point of Sale Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: martin.renvoize@openfifth.co.uk Target Milestone: --- Koha::Cash::Register::Cashup->summary sums accountlines.amount (a decimal(28,6) column) via MySQL SUM() and then Perl addition to build the top-level 'total' field and each entry in 'total_grouped'. These sums can come back with more precision than the 2 decimal places these amounts are ever displayed or entered at, and the extra digits pass straight through the /api/v1/cashups/:id JSON response since neither field is otherwise formatted. This patch sprintf's both derived sums to 2 decimal places, matching the amounts they represent. The per-row income_grouped/payout_grouped entries are untouched, since they are a straight get_column() * -1 negation rather than a Perl-side addition of two separately-summed values. Test plan: 1. prove t/db_dependent/Koha/Cash/Register/Cashup.t 2. prove t/db_dependent/Koha/Cash/Register/Cashups.t 3. prove t/db_dependent/api/v1/cashups.t 4. Complete a cashup with several payment types and confirm the summary modal's Total and per-payment-type rows show a clean 2 decimal place amount -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.