invoice print amounts-per-fund uses wrong value when item price varies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.7 |
Won't Fix
|
Medium
|
Unassigned | ||
2.8 |
Won't Fix
|
Medium
|
Unassigned | ||
2.9 |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
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.
Changed in evergreen: | |
milestone: | 2.7.1 → 2.7.2 |
Changed in evergreen: | |
assignee: | nobody → Jennifer Pringle (jpringle-u) |
Changed in evergreen: | |
milestone: | 2.7.2 → 2.7.3 |
Changed in evergreen: | |
milestone: | 2.7.3 → 2.7.5 |
no longer affects: | evergreen/2.5 |
Changed in evergreen: | |
milestone: | 2.7.5 → none |
milestone: | none → 2.8.1 |
no longer affects: | evergreen/2.8 |
Changed in evergreen: | |
milestone: | 2.8.1 → 2.8.3 |
assignee: | Jennifer Pringle (jpringle-u) → nobody |
status: | New → Triaged |
importance: | Undecided → Medium |
no longer affects: | evergreen/2.6 |
Changed in evergreen: | |
milestone: | 2.8.3 → 2.9.0 |
Changed in evergreen: | |
milestone: | 2.9.0 → 2.9.1 |
Changed in evergreen: | |
milestone: | 2.9.1 → 2.9.2 |
milestone: | 2.9.2 → 2.next |
Changed in evergreen: | |
assignee: | nobody → Jennifer Pringle (jpringle-u) |
Changed in evergreen: | |
milestone: | 2.next → 2.10-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
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.