Totals in funds do not round to two decimal places when prorating is used

Bug #996029 reported by Lebbeous Fogle-Weekley on 2012-05-07
44
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

To quote Sharon Herbert of Sitka:

---

Funds with prorated debits against them do not round to two decimal places. Instead they contain

---

The second sentence is cut off there, but I think we understand. The Evergreen developers currently appreciate that we're using floating point math when we need to be using money math in many places throughout Acq.

Addressing this specific instance should not be difficult, but small rounding errors may occur elsewhere for the same reason. An effort potentially involving multiple developers will be needed to overhaul these calculations across Acq.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Alex Lazar (alex-lazar) wrote :

To add to the original description of the problem, the invoice works correctly, but the two fund record debit transactions and dollar summaries are not limited to two decimal places (see attachment, by Dee Nolan, PALS).

Liam Whalen (whalen-ld) on 2014-02-19
Changed in evergreen:
assignee: nobody → Liam Whalen (whalen-ld)
Remington Steed (rjs7) on 2014-02-24
tags: added: money
Kathy Lussier (klussier) on 2014-10-03
Changed in evergreen:
assignee: Liam Whalen (whalen-ld) → nobody

We just ran into this issue. Normally we don't mix funds in one order, one got through by mistake and the prorating got split 11 ways, which resulted in a debit of 0.381034447718728 to one fund.

This is bugging our acquisition staff, just because it is messy to look at and will propagate forward forever.

Would it be safe to mess with the database an just manually round those numbers with an update to acq.fund_debit?

Josh

I'm been looking into this just to try and figure out if I can just update the database to fix our one instance of this problem.

Our logs had the following info about the prorated charge in question.

osrfsys.10.log.gz:2017-09-11 10:47:47 virt-egapp1 open-ils.acq: [INFO:14546:Invoice.pm:793:150514427114393310] invoice: attaching prorated amount 25.6589655522813 to fund 945 for invoice 18566
osrfsys.10.log.gz:2017-09-11 10:47:47 virt-egapp1 open-ils.acq: [INFO:14546:Invoice.pm:793:150514427114393310] invoice: attaching prorated amount 0.381034447718728 to fund 969 for invoice 18566

Which led me to
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/Invoice.pm#l793

I also noticed that in the acq.invoice_item the amount is rounded, and it looks like that is handled in the database with the datatype set to numeric(8,2).
http://docs.evergreen-ils.org/2.10/schema/_schema_acq.html#_invoice_item
   cost_billed numeric(8,2)
   actual_cost numeric(8,2)
   amount_paid numeric(8,2)

So I wonder if that would work for the acq.fund_debit origin_amount and amount fields.

It looks like there is already code to deal with cases like $1/3 = 0.333333333333, which adds the missing penny to the largest prorated debit to make it all work out.

Josh

Note: if anyone edits Invoice.pm, there is a spelling mistake in one of the log messages, discrepency -> discrepancy.

Josh

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers