Orders, UX iteration 5

This is the last update to orders which now includes Receiving and Checkin.

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

Here is the video walkthrough

I think the link to the wiki should be: https://wiki.folio.org/display/RM/Acquisitions+Orders+Module

Hi,
we discussed the receiving workflow in our FOLIO team and two questions occured:

• Will there be an accession number to be registered during receiving process – best by support of an automatically number generation?
• Where will the statistical data be stored during the receiving process? E.g. counted physical items, material type, publication type, subject, publication country (1, print, book, biology, UK)

Thanks a lot.
Best,
Kirstin

Hi,
we asked for feedback from our network libraries concerning the receiving process for ebooks. The summarized feedback can be found here: https://docs.google.com/document/d/1FBUNxkGswzorPffJjgl9eybjN4Qyg7g_0WHY9OUWhr8/edit
Please add and comment.

Very much appreciate the feedback, Kristin. At the moment there’s no random number generator built into Acquisitions. However, an accession number could be added as a tag where needed.

With respect to statistical data, we are still exploring the possibility of sending it to the inventory app.

I think this video was pretty similar to what we saw in the RM SIG meeting. These functions both look good to me. Very straightforward, nice simple UI. A few questions that occured to me while watching:

• On the receive screen, it’s not totally clear that the “Receiving” field is expecting a number. Maybe it would be helpful to label this something like “Number of copies received.”
• On the pattern setup for check-in, it seems like “end date” can’t be a required field if “Number of occurrences” is used. I would expect that one of these two fields needs to be populated, but never both.
• For the check-in screen, what happens if there are multiple ongoing orders attached to the PO? I think it would be confusing to see a list of expected issues for multiple titles all at once. Will there be a way to select a specific orderline and view its check-in record?

For the pattern set-up, I can also see that both “End Date” and “Number of Occurrences” could be blank, to indicate a title with ongoing, indefinite issues being supplied by the library. For example, if a periodical is being received by the library that comes monthly, maybe the library would like to leave both fields blank, and only edit the prediction pattern to end it if the title is canceled by the library or ceases publication. This would seem easier than having to edit the prediction pattern each time a title is renewed to extend the end date.

I left a couple of comments in the Google Doc. I think many libraries would like to bypass the receiving process altogether for electronic items. At Chicago, we do not proactively check every link on purchased e-books, but rather assume they work correctly, and only check in cases of reports of lack of access. For individual ebook titles, generally purchased through Gobi, vendors and platforms are already all set up, and we have only very rarely run across any sort of access issue. For titles that come as part of package purchases, we have been more likely to run across access issues, but that is generally because the title list and the MARC records received don’t quite match up. However, we still don’t routinely verify access on every title where we load a record, focusing on auditing titles and access on collections that are found to be problematic. I don’t think such verification would happen through a receiving process, as in a lot of packages, ebooks are purchased for a particular publication year, paid for in advance, and then added to the collection as they are published. So names of titles and dates of receipt aren’t even know at the title of purchase. I think ERM functionality would help with a post-purchase audit, but it is a different scenario from receipt.

In short, I think a receiving process for e-resources should be left optional, using the format type to help guide the workflow.

1. Certainly appreciate the feedback on the “receiving” field as the team will be looking at some of the finer UI elements as they build the interface from this prototype and I agree that it should be more clear.

2. Regarding “end date”/“occurrences” you are correct. The system will use one or the other and not both.

3. Great question! The thought at the moment is to have a popup that allows you to select one of the available POs before seeing the Check-in overlay. Thus you only see items relating to one at a time.

Some additional feedback on receiving from Susan Martin, University of Chicago:

1. Ebook Receiving: we are definitely not interested in making receiving a routine part of e-resource workflows. That said, an interesting twist could be using FOLIO for making e-book availability notifications easier. For example, we order ebooks for patron requests or reserves through GOBI. We get notification when the title is available, but it doesn’t come to the ILS, so we have to track this separately. If the notification were able to go into FOLIO directly, and the PO had a note about notifying a patron, when the title was available, FOLIO could use the workflow app to (potentially even with automation) send out notice to the patron or reserves.

2. When thinking about serials receiving, we’d like to reiterate that not using predictive check-in is very freeing, and we don’t want to lose that freedom. We don’t think the project should put too much effort and time into creating a predictive check-in routine, given the shrinking size of print serials.

3. Finally, this comment applies to the whole acquisitions model, I’ll put the comment here, we’d like to stress the system will work as well for libraries that create only one-line POs and not create too cumbersome a workflow based on a multiline PO, when that functionality won’t be used. We need to be able to easily create a PO either manually or in batch that contains only one item.

I agree completely with Kristin’s take on “receipts” for e-resources; it should be bypassed. Instead, we should think about new ways to facilitate access audits in the ERM.

Duke has a very different perspective on serials receiving than Susan Martin from University of Chicago (also we have a lot of Martins on this thread!!). We still receive thousands of print serials at Duke, and predictive check-in, which is the basis for claiming, is essential for us to operate with the very small amount of staff time that we have dedicated to receipts of these thousands of titles.

I am wondering how check-in of print serials will be tied to holdings in Inventory. This is not my area of expertise, but I know that in our current system, Aleph, check-in isn’t connected to Order records, but instead patterns and check-in are related to Subscription records. I am not sure, but I suspect that check-in of items on the Subscription has some sort of automated tie-in to our holdings records so that the holdings don’t have to manually updated every time something is received. We also don’t want to have to look at a bunch of different Order records for different iterations of the same subscription if our Order has changed. We create new orders for the same subscription a lot within our current system, and perhaps the way FOLIO is built we could do away with Subscription records, but I simply don’t know enough about it to be sure.

I have asked my colleagues in Serials & Retention Management to take a look and provide feedback since they do all of our print serial receiving, but anyone else already on this thread who has more expertise in this area, thanks for sharing your thoughts as well!

Hi Kristin,

It’s great to see all this discussion this week. I know Dennis has been reviewing all the comments, and hopefully this will lead to some good conversation at this morning’s SIG meeting. I’m not going to try to answer all the detailed comments here in Discuss, but here’s a few quick thoughts.

1. Just like for physical materials, you should be able to include notify information for eContent. I know this is problematic for some current ILS. We’ll just need to ensure that the notify workflow is triggered by something other than receiving if a library prefers not to formally “receive” eContent. For v1, I’m not sure how automated that notify workflow will be in general.
2. Nothing in FOLIO will require a library to set up prediction patterns, and we definitely want to keep the whole prediction piece as simple as possible.
3. Agreed on single-line POs. Folks are coming from systems like Millennium/Sierra where single line POs are the norm versus Symphony or Voyager where multi-line POs are the default. We need to ensure that it’s easy for libraries to default to single or multi-line POs, whichever is most appropriate for their situation.

Yes, there’s still lots to be done to sort out ERM functionality in FOLIO and define the intersection and distinction between the various activities that have previously been handled in separate Acquisitions and ERM systems.

We’ll definitely need to walk through these bits of workflow, to ensure that check-in and holdings update are efficient. More to follow as the order/receiving/check-in app starts to be coded.

Hi, all,

A little late to the party, and not specifically addressing Receiving and Check-in, but this is where the “Comment” button on the prototype brought me:

I have a question about the “Order Type”, which is marked with an asterisk and only contains “One-Time” and “Ongoing” as options. Is that drop-down customizable?

At Cornell, we have a problem with the Order Type for optional, annual ebook packages: for example, some years we buy the ScienceDirect Veterinary ebook package and some years we don’t. Right now, we call those Continuations (Ongoing), because we will probably be buying them again in another year, so we want the payment all collected on one PO. But they’re really a set of related one-time firm orders. This causes problems when we need to get stats on how much we’ve spent on Subscriptions vs. One-Time purchases - our stats folks just split it by the Order Type, Continuation vs. Firm Order. Buuuuut that’s not really accurate.

Off the top of my head, what might solve this would be a third option in that dropdown - I don’t know what it ought to be called, since “Recurring One-Time Order” sounds pretty absurd - that collects all the years of orders, but doesn’t commit you to purchase every year, and still gets counted in the one-time expenditure bucket. But I’m not sure yet whether maybe some other function in FOLIO’s structure alleviates this problem?

Heather

Hi Heather,

I think what you are driving at is an ability to encumber funds in the next fiscal year for a likely purchase of one-time content, right? Currently at Chicago, we end up creating a new PO for each year of purchasing a new package (kind of a pain), or enter it as a continuation, and then use some additional fields in an external database to identify the payment as monographs and permanent. I believe, and someone from the Acquisitions Group can verify, that Order Type will be customizable, but I think some functionality will be driven by whether it is a one-time or recurring order.

Hi, Kristin,

Actually, encumbrance for the next fiscal year was a different topic that I was looking for the right place to ask about! What we currently do is enter $0 for all Continuations, so nothing gets committed - which prevents commitments from getting all mucked up with inaccuracies from year to year, but is a real pain for selectors when they’re trying to figure out what they’re already planning to spend on their subscription renewals. I think they wind up using spreadsheets… or just losing track.

On that note: yes, I think it would be nice to be able to click a button to encumber funds into the next fiscal year, or not! And a way to choose how much money to encumber - a manually entered price, or the number off the last invoice paid, or that number plus 5%, or what.

But what I was originally driving at was the stats-gathering consequences, and invoice payment consequences, of putting these possibly-but-not-necessarily-recurring purchases into the same bucket as either One-Time or Ongoing.

In Voyager, if you call them Firm Orders (so that the stats will properly register them as things that don’t go away if we don’t keep paying), then Voyager thinks you’re paying for them just once and it goes all wonky if you try to pay another invoice on the same PO, and wonkier depending on whether you’ve clicked “Receive” or not.

But if you call them Continuations (so that invoice payment actually works properly from year to year, and keeps all the invoices collected in one place so you can compare the way the price on this annual frontlist is changing from year to year), then when the stats get collected, that money gets lumped in with the “if we stop paying for this we lose access to stuff” or “we do expect to pay this every year” expenditures, which is not the right place to put them.

So, I feel like we need another bucket for the stuff that needs to be invoiced like an ongoing order, but tagged for statistics as a whole bunch of one-timers.

What a great explanation! We also aren’t encumbering continuations, but would like to investigation the option in FOLIO. I think you have described an excellent use case in acquisitions for using tags (or potentially even a separate field). @Ann-Marie, want to make sure you see this one.

Hi Kristin, I’m pretty sure that’s the intent - that you could decide for categories of orders or funds, whether to roll them over to the new FY as encumbered or not encumbered.

Hi Virginia,

I saw this and thought I would answer…In Aleph the check-in function does not update the holdings, which is too bad because manual editing of the summary holdings is required.

Thanks, Jessica! I do think in FOLIO we should aim to have any check-in functionality automatically update holdings if possible.