Invoices with mixed status line item details can leave hanging encumbrances
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
Tested on 3.7ish master and first found in 3.6.2 production.
Scenario with some real-ish info: A line item is ordered with 9 copies. The EDI invoice is pulled in, and bills for 8 copies. At some point afterward, the items are delivered to the library. 8 copies are marked received, with 1 copy marked as canceled by vendor. The library checks the invoice--all good, 8 copies received, 8 copies billed for--and saves and closes the invoice. However, the PO still shows an amount as being encumbered.
When I tested this on a master server I found that: when the invoice entry is created and links up to the line item details (fund debits), it picks the first X number of line item detail ids, starting with the lowest.
To replicate and test this:
1. Create a purchase order
2. Create a lineitem with multiple copies and activate.
3. Create an invoice with that line item, and bill for 1 or more copies *less* than were ordered.
4. Go back and mark all the copies received except for 1 or more (however many you deducted from the invoice), starting from the bottom
5. Mark those unreceived copies as cancelled
6. Save and close the invoice.
You can check in the database that there are received copies that were *not* marked encumbrance=f even though the number of copies received matches the number of copies billed for. Here's a quick query for that:
select acqlid.*, acqfd.encumbrance from acq.lineitem_detail acqlid
left join acq.fund_debit acqfd on acqfd.id=
where lineitem=X order by acqlid.id;
I also tested this with just picking a copy in the middle to mark canceled, and got the same result.
This bug is problematic because the user has no way to know which fund debits are linked up and which ones aren't. Additionally, often multi-item line items are intended for multiple branches. So all line item details aren't necessarily equal; even if they knew "if you need to cancel one, cancel the bottom one," that isn't always a viable workaround because they might need to cancel a specific branch's copy.
My proposed fix would be that invoice entries aren't linked up to fund debits until an invoice is closed. The only way you can turn a fund debit into encumbrance=f *is* by closing an invoice, so until then there's no need for them to be linked up, and it can obviously cause some crossed wires in the system.
Having said all that, I haven't tested every iteration I could think of to narrow this down even further. Questions I might have that I haven't tested: Does it behave correctly if the copy you choose to cancel is the bottom one (the highest id)? Should the invoice linking be between line item detail based on whether a cancel reason is present, or against fund debit directly? What should happen if you bill for 8 copies but only 7 of them have fund debits? What if I marked the copies as received/cancelled *before* the invoice came in?*
*Even if that did work, this would still be a bug because often vendors will include the invoice in the box (meaning it's been generated), and thus send the EDI invoice before the library even receives the box. So EDI invoices linking up to lineitems can and regularly does happen before receiving.
| description: | updated |
| Tiffany Little (tslittle) wrote | #1 |
| tags: | added: acq-invoice acq-lineitem |
| Changed in evergreen: | |
| status: | New → Confirmed |
| Josh Stompro (u-launchpad-stompro-org) wrote | #2 |
If anyone stumbles across this bug and needs a workaround. If you detach the line item from the invoice, save and close, and then add the line item to the invoice again, then save and close, the fund debits will shuffle themselves to be correct.