PO totals do not include all amounts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.6 |
Fix Released
|
Undecided
|
Unassigned | ||
2.7 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Evergreen master (circa 2.7); likely affects all versions.
In the purchase order UI , the total estimated and total spent values do not include all of the values relevant to the PO.
1. Charges created directly from the PO via the New Charge button at the bottom of the page appear in the total encumbered and spent, but not the total estimated. To fix this, we can move the total-estimated calculation into the API which counts the debits for total encumbered and spent. Inside the function, we can add po_item amounts to the estimated amount.
2. Charges created directly from an invoice do not appear in either the total spent or total estimated on the PO. (These would never be encumbered, so they won't show there, regardless). This is slightly trickier, because this type of charge doesn't link to a specific PO, since you can have multiple PO's on one invoice.
Note there is an acq.invoice_
My proposed solution for this is to virtually prorate the shared costs when calculating the amount estimated/spent on such charges across the relevant POs. For example, if an invoice has two POs with $5 charged for one and $15 for the other, a $4 tax would be (virtually) attributed as $1 (25%) to the $5 PO and $3 (75%) to the $15 PO. The extra $1 and $3 would be added to the total estimated and total spent for their respective PO's. That is, the $5 PO would show $6 estimated and $6 spent.
Of course for single-PO invoices, no virtual prorating is required. A $3 tax would just show as an extra $3 on the amounts estimated and spent for the single PO.
Does the proposed solution to #2 sound reasonable and would it be useful? Confusing?
Are there cases where an invoice containing multiple PO's would include a charge (tax, fee, etc.) that should not be attributed to all PO's on the invoice?
Changed in evergreen: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
I assume we would only prorate where acq.invoice_ item.purchase_ order is null. If that's the case, I have an adjustment to request for the "add Item from Invoice" workflow. When doing that, I think the UI should offer to add the item to a specific PO, but allow "all" ("none"?) as an option. If one PO is chosen, we know where the line item belongs. If it's null, we prorate. That is, I think, the crux of you second question.
With that, it all makes perfect sense to me and sounds good.
And, for pedantry's sake, the single-PO case needn't be special -- the virtual prorating still happens, but 100% is applied to the one PO. I don't think there's a need for a special code path there.