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_item.purchase_order column, but this is only populated for invoice_item's which are created from acq.po_item's. invoice_item's created within an invoice are assumed to not have a specific PO target, so the column is unset.
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?
I assume we would only prorate where acq.invoice_
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.