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

[Lebbeous Fogle-Weekley]

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.

[Alex Lazar (alex-lazar)]

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).

[Josh Stompro (u-launchpad-stompro-org)]

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

[Josh Stompro (u-launchpad-stompro-org)]

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

[Josh Stompro (u-launchpad-stompro-org)]

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

Josh

[Jennifer Pringle (jpringle-u)]

This looks like it's fixed in 3.8.0 with the angularized acquisitions admin interfaces! My test with prorated debits has all debits rounding to two decimal spots.

[Tiffany Little (tslittle)]

Marking Won't Fix based on Jennifer's testing in 3.8.