Angular purchase orders: can't edit fund after PO has been activated

[Jane Sandberg]

Reported by Christine Morgan:

"In the dojo interface it is currently possible to use the batch updater in the purchase order to update the fund in selected line items after the purchase order has been activated. Our libraries use this to change the fund when they have accidentally used the wrong fund, have decided to use a different fund, or have uploaded a file with the wrong fiscal year set. In the new interface I see that the batch update option in the PO Actions menu is disabled after the purchase order has been activated so that it is now not possible to update funds. I realize that everything else in the batch updater, except possibly for the collection code, should be disabled after PO activation. The loss of the ability to update the fund, however, is an issue for us. If the batch updater could remain active after PO activation, with only the fund and possibly collection code enabled, that would be ideal but just leaving the batch update option active would give us what we have now."

Here are the steps I took to reproduce this with the concerto data set:

1) Acquisitions > Purchase Orders
2) Do a search for on-order purchase orders.
3) You should get at least one matching PO (PO #2). Click its name.
4) Try to find something in the UI that allows you to change the fund on one of the items connected to the first line item.

[Jennifer Pringle (jpringle-u)]

Tiffany's comment from the original LP this came up on

"Per the AIG, we don't consider this particular regression a blocker for Sprint 4 getting into 3.10, but we *do* consider it a blocker for removing the PO/LI dojo interface(s)."

[Jennifer Pringle (jpringle-u)]

I've given this bug an importance of high since the AIG considers it a blocker for removing the PO/LI dojo interfaces and the new angular PO/LI interfaces have now been in for 2 versions.

[Jennifer Pringle (jpringle-u)]

Confirmed this is still an issue in 3.11

[Andrea Neiman (aneiman)]

Since PO activation is the action that sends EDI orders, I'm curious what constraints would want to be established here in cases where a library would NOT want the fund(s) to be editable post-activation.

At the very least it should probably be gated by permission, or perhaps a flag or setting.

I'd be interested in thoughts of libraries using Acq as to whether there are circumstances to block editing post-activation.

[Tiffany Little (tslittle)]

I'm not necessarily the requested audience since I *do* want the funds editable post-activation, but...

In 99% of cases, I don't think it's a problem for the fund to be editable post-activation. In Dojo it was, so this is a regression. Having said that, I looked at the available fields in EDI attribute sets and there *is* an option to INCLUDE_FUND. If that setting was used, then yes, I don't think fund should be editable. Anything that's sent via EDI should be static.

But I don't know what the use case for sending funds to vendors would be. If it's for the vendor to process items differently, we're already able to send copy IDs, call numbers, collection codes, line item notes, shelving locations, owning library etc etc. Whatever info is contained in a fund is probably best sent in some other data point that doesn't affect fund tracking.

So in my opinion I see two options right now:

1. A new flag/setting should be created to govern whether fund can be edited or not. This would protect safe use of the EDI attribute.
2. Remove the INCLUDE_FUND option from EDI attribute sets and then fund should be editable, governed by the already existing fund permissions.

My two cents is I would prefer option #2.

[Andrea Neiman (aneiman)]

Thanks, Tiffany - I appreciate the extra info!

[Lena Hernandez (lfhernandez)]

Similar to Tiffany's comments, I would say that fund should be editable but that EDI messages and settings are not changed with the update. We should retain the functionality to send funds information to vendors but perhaps could ignore the fund info in messages coming FROM the vendor?

Some libraries may have deposits set up with the vendor that are tied to the fund information, or may have set up limitations on what types of resources can be ordered under a particular fund code. An example from my previous life of academic acq, we had two pots of money on deposit with our vendor. One was our general funds and the other was from a grant. The grant money could only be used to order replacement copies of physical books. Those parameters were set up when we created the deposit so that if I accidentally tried to order an ebook using the grant fund code it would be flagged. The selected fund was important to our workflows.

Perhaps we could treat this more like we do with claiming, there is a flag so the system creates an alert, but the humans are the ones that need to do any follow up. So, for example:

Workflow from the PO
1. library updates the fund from the PO
a. modal opens with alert that only the local information has changed and that EDI messages will not be modified
b. Note with this alert is added to line item
c. Incoming EDI messages from the vendor ignore the fund information.
3. When the invoice is received, the line item that had a changed fund has a visible alert displayed next to it noting that the fund was changed and so additional follow up may be required.
4. Invoice continues to be processed with the locally re-set fund.

Workflow from the Invoice
1. Library updates the fund on the invoice
a. modal opens with alert that only the local information has changed and that EDI messages will not be modified
b. Note with this alert is added to line item
c. The alert displays on the invoice interface
2. Invoice continues to be processed with the locally re-set fund

I would agree with Tiffany that it would be preferable to always be able to change the fund regardless of EDI.