Order screen, UX iteration 4

This is the initial work of the sub-group that has been discussing orders, we presented it to the larger SIG in this Friday’s meeting and would like to give the larger community the opportunity to contribute feedback. This is only a mockup and documentation intended to help clarify how fields will behave and interact with each other. Your feedback and discussion here will help inform the development of the backend of this module.

Visit the wiki page to see the mockup and most recent versions of documentation: https://wiki.folio.org/display/RM/Acquisitions+Orders+Module

I shared with some others here. Here are some comments from me and the Head of Acquisitions

Field questions:

• Item Details: Purchase Material ID – what is that?
• PO Line: Manual Batching – if we don’t click this, are items ordered from the same vendor during the same day/time frame going to automatically batch together into one PO with multiple POLs?
• PO Line: Donor – will need to pass this code through to create an electronic bookplate in the public interface. Currently, this code gets mapped into a donor field in the item record or e-holdings record. How will this work in FOLIO?
• PO Line: Collection – what is that?
• What are the various acquisitions methods? - Approval, subscription, gift, etc?

Some suggestions for functionality:

• Ability to create templates, so that some of the fields are already filled in.
• Ability to fix claim settings in the vendor record as well as at the PO level. Maybe claim settings can be inherited from the vendor record at the PO level, but can be locally overridden.
• If there are special instructions required for receiving, can we have a place to record those? For example, it would be great to have instructions added into the PO and then have those special receiving instructions “pop up” for the receivers.
• It would be extremely helpful to the invoice from the PO once it’s attached. If we do end up creating a “new” PO every fiscal year (or new FOLIO item with the same PO number), it would be really helpful to have this invoice history brought together across all fiscal years for the same PO number.

And some general CRUD questions:

• What will be able to be edited?
• Will a PO/POL be able to be deleted? Under what circumstances? (e.g., only before payment is made against the PO?)

Finally, as got commented on at the RM SIG meeting last week, ERM libraries have gotten in the habit of storing certain data in the PO simply because there isn’t a better place to put it. The blue section on E-Resource Details could get pulled into a PO, or potentially populated when creating a PO, but it probably makes more sense to have this information live on a record independent from the PO, like an E-Resource Record, as was suggested, so we don’t have to create dummy POs for e-resources that don’t have payment associated with them.

Fund distribution - the mock-up shows both “amount” and “percentage.” Does that mean a library will be able to choose between the two? Really hoping the answer is yes, being able to use only % in current system is quite frustrating.

Excellent point! We sometimes just can’t split things up the way we want because we need to supply a percentage.

That is absolutely correct. Our intention is to provide as much flexibility as possible in distributing funds and this will be a major building block.

Thank you for compiling this feedback!

Regarding Fields:

1. Item Details - Purchase Material ID - This is intended to denote the Product/material ID for the physical or electronic item. It has been split into two potential fields in the latest mockup.

2. Manual Batching: That is correct, the system will batch lines based on Vendor and Date unless Manual Batching has been checked. If it has, only the lines you have in your current Purchase Order will be grouped together.

3. Donor: We have yet to determine how it will be passed to the public interface, hower as we collected it her we can expose it or forward it as needed

4. Collection: This is a flag to indicate whether the order is for a collection of items or not. The small group believed this would be valuable to indicate and would encourage further discussion as to possible uses.

5. Aquisition Methods: The current list includes - Approval Plan, Depository, Exchange, Gift, Legal Deposit, Technical, Purchase at Vendor System - The goal is to allow administrators to manage this list in their instance.

These functionality suggestions are excellent, we intend to leverage “default settings” as much as possible to speed the creation of new orders. Claim details are on that list, unfortunately, we don’t have an intuitive way to represent these details in the current mockup. We will work on clarifying these in our next update to documentation.

We are still narrowing down what fields will be editable, but are leaning towards opening as many as possible for version one as integrations/data source options will be limited.

Deleting PO and POL: PO and POL each have statuses. When in certain statuses they cannot be deleted (Eg. PO = Sent) but they could be canceled. The model essentially allows for available actions for PO or POL to be dependant on status.

The feedback regarding e-resource details for items that don’t require payment is something we need to discuss further. However, in certain scenarios, these details seem to be required here. Thus, we will likely need to keep them for the time being and discuss how we may address this with functionality in receiving or elsewhere?

One more thought that has come up with regards to POs is a good way to track multi-year payments. For example, we purchased a digital collection, and then are splitting payments over 3 fiscal years. It’s still a one-time purchase, although sort of like a subscription in that we are obligated to pay later. We want to make sure we have a way to enter an end date for when the PO should be closed after the final payment is made, and make sure the proper amount is encumbered upon fiscal year roll-over.

This is an interesting one. Would there be 1 invoice associated with this or three? Also, is there a specific reason why the invoice would be closed in year one vs. staying open until fully paid?

In a scenario like the one Kristin describes, there would usually be multiple invoices (“split invoices”). So, for example, for a $30,000 payment spread over 3 years, you would be billed $10,000 on an invoice in year 1, $10,000 on another invoice in year 2, and a final $10,000 on a 3rd invoice for year 3. Of course the timing, number of invoices, and amounts vary, but I have never run into a situation where one invoice was held open over time. Instead, an order would likely remain open until all payments were made. At Duke, I’ve seen these kinds of orders handled as any of our 3 order types - standing, subscription or monographic - in Aleph depending on who handled the order and invoicing since there’s no standard way to do them.

All good question - let’s aim to discuss more at the SIG meeting. A couple quick comments:

We’ve discussed most of the functionality suggestions in the small group and hopefully can include them. Note that claims and claim responses are not currently in scope for v.1, so those details may come a bit later.

And we definitely still need to do some work on how acquisitions/PO/invoice info and ERM-type info fit together smoothly in one system, instead of some of the workarounds that we’ve had to deal with so far.