invoice print amounts-per-fund uses wrong value when item price varies

[Bill Erickson]

Evergreen master; likely affects all versions.

When the price of one copy on a lineitem differs from the price of another copy on the same lineitem, the invoice printout shows the incorrect value for "amount spent per fund" for one of the copies. Steps to reproduce:

create PO with one lineitem and two copies.
activate the PO
create invoice from PO (or from lineitem)
set # invoiced / # paid to 1.
set a billed amount (e.g. $5)
save invoice
return to PO
create another invoice on the PO
set #billed/paid to 1
set billed amount to a different value (e.g. $6) than the first invoiced copy
save invoice
return to PO
click View Invoices button
select first invoice and "Print Selected Invoices"
repeat with the second invoice.
value for "amounts spent per fund" show $5 for both invoices, even though $6 was spent on the second invoice.

This happens because there is no direct link between a fund_debit (derived from a lineitem_detail) and the invoice that applied the value to the debit. Without it, the code which looks up debits for a given invoice simply returns the first reasonable looking debit it finds, sorted by date, which is why the $5 repeats in the example above.

As a solution, I'd like to propose a new column on acq.fund_debit which refers back to acq.invoice_entry to indicate which entry was responsible for applying the last value to the fund_debit. (I say "last" value instead of "final" value, because the value can be further modified via invoice UI).

In my example above, the $6 fund_debit would refer back to the invoice_entry from the second invoice, making it obvious which invoice applied the $6 value.

[Bill Erickson (berick)]

Code to implement the above pushed to:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1380709-fund-debit-invoice-links

Confirmed it resolves the problem described above.

Since this tracks (and thus requires) new data, it will only effect invoices created or modified after the code is applied. All other invoices / debits will behave as before.

[Kathy Lussier (klussier)]

Adding a note that I tried adding this branch (a few times) to a MassLNC VM on Bug Squashing Day. However, whenever we load this branch, we have a problem where the Concerto dataset doesn't load in the VM. The script that sets up the VM's typically loads the full Concerto dataset as part of the install.

It's still possible to test this branch without the data, but I wasn't sure if the problem with loading the dataset is caused by the branch or with something being done on our end.

[Bill Erickson (berick)]

Pushing a fix to the base schema in moments...

[Bill Erickson (berick)]

Thanks for testing, Kathy. I've force-pushed a fix to the base schema. I was able to install the schema and install the concerto data set.

[Bill Erickson (berick)]

Forgot to add an index on the new column.. pushed another commit to address that.

[Jennifer Pringle (jpringle-u)]

I have tested this code and consent to signing off on it with my email address, <email address hidden>, and name, Jennifer Pringle.

[Bill Erickson (berick)]

Thanks, Jennifer!

I have rebase the code to master, incorporated Jennifer's sign-off's, and pushed a live test commit. There should be no user-facing changes, so I opted not to create release notes.

[Bill Erickson (berick)]

Note the live test is not tagged with an LP#, because I intend to add more tests as part of bug #1333254

[Bill Erickson (berick)]

After working w/ this code to implement bug #1333254, I believe this represents enough of an internal change of behavior that it should not be considered for backporting. Setting milestones for existing releases to won't-fix.

[Kathy Lussier (klussier)]

Thank you Bill and Jennifer! I merged the code to master with an additional commit to rename the live-t test since another #12 had been added since Bill first pushed his live t commit.