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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
