2021-09-03 Acquisitions Meeting notes

2 min. after

Housekeeping

Susan Martin

• Dennis out of office next week. Tuesday, September 7, 2021, 1 PM ET meeting cancelled.

3 min. after

Product Council Update 

Kristin Martin

• PC Update (9/2) & PC Update (8/26)

• Update from Technical Council

  • Criteria for reviewing external code contributions, "What are the functional criteria?"

  • Grew around discussion of LDP and incorporation in FOLIO.

  • Charging a group next week to develop those criteria if of interest.

• Presentation from SysOps team about operational technical debt.

  • How to continue to address issues of technical debt.

  • What does a continuous release cycle look like vs. where we are at right now?

• Concluded with discussion around how to set agendas.

  • Discussion in Slack general about things being open vs. closed.

  • Concern that community is not as open as it could be.

  • Trying to come up with different ways to set the agenda, maybe more agenda setting directly within the Slack channel and then as needed may have preparatory meeting.

8 min. after

Order Line Locations

Dennis Bridges

• Receiving updates make some significant changes to how locations are selected.

• Now in holdings dropdown populating with all of the holdings from the instance; no longer populating with just what appeared in the PO.

• Trying to figure out how to tell the user what the expected locations from the POL were. 

• Thought we would display above "Select holdings" with "Order line locations."

Open

From Sara Colglazier (MHC/5C) to Everyone:  08:11 AM

Is the dropdown for Select holdings here like in Inventory that you can start typing and get closer to the one you want?

Open

• Part that is missing is the guidance of what location appears on the PO line.

• Discussion around choosing from all possible holdings. 

  • To create you would use "create new holdings for location."

  • System will create holdings for that location.

• Currently in Juniper, when you select the piece it only shows locations.

Open

Open

Open

• Is that useful? Confusing?

From Jackie Magagnosc to Everyone:  08:21 AM

If this works the way I’m understanding it, this is really awesome.

• Discussion about "on order" location. Will need to talk more about deletion of holdings records now that direct connection exists.

• Currently old holdings will still be in inventory when creating a new one.

• Martina: Important that old holding is no longer there if not used in inventory. Information of what was on order line is helpful.

• Julie: If PO has an "on order" location and that PO was generated to create holdings and items, when we go here will have order line location as "on order." Also will have "on order" as holdings because that was created when PO was created. See this as more beneficial for serials where the holdings change, not sure about one-time monograph orders. Whatever the location is for these (monographs) is either in the PO or assigned after receipt. 

• Dennis: What is the main reason you order things to an "on order" location? To indicate that materials are still on order?

  • Julie: Will display in discovery system and people can put in a request for it.

  • Kristin: Also easy to know when you have something on order.

• Dennis: Should put on agenda to talk about removing the holdings. Want to know a little more about purpose of "on order" location.

  • Kristin: Simplifies order process. When placing order don't have to worry about where the piece will live.

    • Never thought about this as I am going to create a holdings and delete. 

    • Always update holdings to the permanent location.

From Susan Martin to Everyone:  08:29 AM

MTSU also uses an "on order" location.

• May need to consider if you have ordered multiple things to "on order" location and how different receipt times impact.

• Sara: Agree with Julie that this would be beneficial for serials. For monographs may order and then in interim realize it needs to go on reserves. Would be great if you were able to choose temporary location. Also for displays; order things that will eventually go to the stacks. Could you have a toggle that will not replace or create holdings, but indicate that item has original and then temporary location? Can think of other reasons to want to update the holdings rather than deleting and creating new. Maybe another toggle.

• Dennis: Definitely something we could accomplish, but would be done on a piece by piece basis. Might be too cumbersome? If two pieces are related to a holding, what happens if the first piece updates holding to something else. Maybe not a concern because other piece would still be connected. Would update both at the same time.

From Kristin Martin (she/her) to Everyone:  08:34 AM

I think Dennis, if we were ordering more than one copy at the same time, each item would get its own On Order holdings record with a single item. I'm not thinking of where we would have both items on the same holdings.

• Can look at a couple of different workflows with a diagram.

• For the most part, is it logical to display the locations that appear on the POL in this piece form as guidance? In event that someone decides to change, at least will know what locations originally associated. Wording “order line locations” does that indicate to you that these are locations that appear on the POL? Is that helpful?

  • Agreement in chat.

From Sara Colglazier (MHC/5C) to Everyone:  08:39 AM

Slight suggestion. Order Line Location is great because it says what it is, how about for Select location: Select from existing Instance locations ... or something similarly clear/explicit

37 min. after

Caption Field in Edit Piece

Dennis Bridges

• Currently have caption field for pieces, which could be any information about the piece.

Open

• Part of updates coming for receiving is creating more alignment between piece details and item record so that more information can be exchanged.

• Plan to break down data points into three fields:

  • Copy number

  • Enumeration

  • Chronology 

• Information will be held consistent between piece and item record.

• Question: What do we do when migrating from where we are today with caption to these fields? What is most logical thing to do with this data?

  • Suggestion 1: Populate caption data in enumeration field.

    • Potentially try and retrieve chronology and copy number from item record if connected.

    • Enumeration would hold constant your current receiving details.

  • Suggestion 2: Where your piece is connected to an item, discard the caption information and retrieve copy number, enumeration, chronology from the attached item record.

    • If piece is connected to an item, we don’t care about our current caption. Could be out of date anyways. Use whatever data appears in item to populate.

    • Where no item connected, keep the caption data in the enumeration field.

  • Any powerful thoughts or feelings?

• Kristin: Question for libraries that have already implemented, how are you actually using the caption field?

  • Martina Karlsson: Putting everything about the journal issue in that field. Vol., year, issue, whatever we have. Looks different for different titles. Also put that information in the items as well.

• Dennis: The path of least resistance here from my side of the fence is to take whatever is in the caption field and put it in enumeration. Will have all data and will know where it is.

• Moving forward, you would then capture with those available options.

From Owen Stephens to Everyone:  08:45 AM

Does Caption need to be removed for this change? i.e. could caption be maintained for existing pieces, and enumeration+chronology available going forward?

From Jackie Magagnosc to Everyone:  08:46 AM

There’s so much variability in the way publishers lay out their volume and issue information that what ends up in the caption field is by its nature inconsistent.

• Certainly could keep caption. Concern initially was there is nowhere in the item record to put caption as defined in receiving. Could consider keeping for another release to have a testing period where we can collect feedback on whether to keep or not. Thinking was we would just relabel caption to enumeration. Would save having to write a migration script.

• Summary:

  • Now thinking that maybe it does make sense to keep caption at least for a time. Add new fields (copy number, enumeration, chronology). Allows you to not worry about making changes in receiving and migrating data to wrong places. Does complicate the piece details slightly, because now you have multiple fields with caption being the odd one out. Will not transfer to an item record. Is that a major concern? Do we need to run tests and see how usable or not usable that is?

  • If more thoughts put in Slack.

56 min. after

UAT for Receiving Changes

Dennis Bridges

Open

• Idea would be to run from Sept. 8-16. Format is basically to create some orders of various types, create some receiving records, and then receive those things. Then capture feedback on how straightforward it was, etc.

• Don’t have much time left to develop for this Kiwi release, so need to get this started.

• Are there folks willing to participate? Is it a reasonable time frame?

  • Consensus that it is good and that people will participate.

  • Dennis will try to get a post together in Slack. Spread the word.

• Will be missing a few things still, but will aim to kickoff on the 8th as long as no critical issues.