2020-05-15 Meeting notes
Date
Attendees
- Sara Colglazier
- Scott Stangroom
- Tracy L Patton
- Paul Trumble
- Dwayne Swigert
- Abigail Wickes
- Kirstin Kemner-Heek
- Dennis Bridges
- Martina Schildt
- Eric Hartnett
- Tim Whisenant
- Charlotte Whitt
- Martina Tumulla
- Heather Thoele
- Julie Brannon
- Julie McNulty
- Marie Widigson
- Monica Arnold
- Sarah Dennis
- Virginia Martin
- Marmot User Services
- Lindsey Taggart
- Owen Stephens
- Former user (Deleted)
- Ann Crowley
Discussion items
| Item | Who | Notes |
|---|---|---|
| Minute taker? | ||
Announcements/Updates | Highlights from the PC meeting:
Hoping to have Emma Boettcher join next week's meeting to review Item States | |
Continued Receiving discussion Receiving discussion - review updates to Receiving App, review connections between Receiving App and Inventory, and Receiving for packages
Relevant Issues
| Charlotte Whitt guided the group through Inventory to show what currently displays (empty shell for now - data isn't populating from Receiving app)
Data from the receiving app is intended to populate this Dennis: Small Group discussed what info should display, but the question remains - what of the piece information do you edit from the holding record itself - would you need to do that? Maybe it doesn't make sense to store the info on the holding record. Do we need to be able to edit from the Holding record? CW: The beauty would be if the data were maintained in the Receiving app, but it populated here (not just a link back) so that you don't have to jump between apps. Would like to see the same "connected" functionality that's available elsewhere, such as in the Preceding and Succeeding Titles sections. Dennis: Are there situations where there wouldn't be a receiving record and you'd need to add a holding? Owen Stephens: What about for historic data? Sara: Gifts in a series - not part of receiving process . What about standing orders? Virginia: At Duke we create for serials standing orders but not for monographic sets standing orders. Much of our info goes into order notes because we don't have a better place for it in the system when we don't receive those. For a monographic series or set you might have the record you have your order on, but you won't have an inventory item for the series . Would have an order for a series, you catalog the item but not the series. Monographic volumes, orders for serials and sets. Sarah - you have a series title and your standing order is tied to that. But the volumes are so distinct they stand on their own and the items live on their own with their title, contents, etc. Containers Virginia: Duke used to maintain all of the holdings info at both the series and item level, but stopped that double maintenance due to staffing. Gets complex due to the way things are acquired and it makes it difficult to know where to store certain information during receiving. CW: What did the acquisitions small group identify? Dennis: Went through each data point on the piece. The assumption was that if data appears on the holding then it's something that's been received. It would need to be received first before appearing on the holding. Based on that assumption, there is a lot of info that doesn't need to be displayed in inventory such as received date, PO Line, Edge case: you might want the next upcoming thing to display if its a series of things. Focused on wanting to see:
CW: Sounds like if the data is going to be shown in public needs to be defined at the data element level. The use case for showing the next expected volume would be for a patron to put in a request for a piece that hasn't arrive yet. Virginia: Or to display that something that is on order or is expected to come in. Dennis: That would likely be a separate feature - to display expected pieces. Virginia: Aren't most of us doing this tracking manually - you get a volume in that's a serial and you pay the invoice and then you add the serial volume to the holdings record. Kristin Martin: If a piece comes in that gets an item record (standing order) she believes the item record for the analytic lives on the series record. The dummy record points to it. The challenge here is that this is hard even for us to understand. Analytics are complicated and different institutions handle them differently. For most of us we are manually adding the item and updating the holdings. Don't think we need an automated solution for this. Sara: We don't update the holding unless its non-predictive - if the sequence gets broken. You indicate volume 1-96 and only indicate breaks. Done manually. Some materials arrive very much out of sequence From Marie Widigson to Everyone: 08:47 AM From Scott Stangroom to Everyone: 09:05 AM Kristin: Have a lot of print journal subscriptions and its not a growing area - the current situation will only accelerate the transition to online. The standing order analytics are very complicated, so its hard to define an automated workflow without defining the 15 variations. Would be hard to define a pattern to be used in the majority of cases due to complexities and exceptions. Virginia: We use marc holdings. New question: Is there a place to put staff notes about routing? We have traveling serials - a volume arrives and it gets sent to the main library and then that triggers the prior issue at the main library to get sent to remote storage or for binding once there is a year of issues for example. CW - we have holdings notes which are maintained in settings to define different types of notes and can define whether it should display internally or not. From Scott Stangroom to Everyone: 09:10 AM From Virginia Martin to Everyone: 09:10 AM From Marie Widigson to Everyone: 09:16 AM Sara - Revisit discussion from above - do we need to define for each data element whether it displays publicly? Might want to display the latest. CW The holdings statement is where that would be stored. Sounds good Kristin: The current layout mirrors what we have now. Viriginia: Having a link is sufficient. Dennis: You will have a toggle to define whether the holding it should be public displayed or not. Do we need to add that capability on the receiving side to indicate public display? Kristin - yes that's what we have now CW Where should the link back to receiving history be? In the detail view there would be a link back to the receiving record to see more detailed data? Dennis - it would take you back to the receiving title and you would have your list of received pieces there. Maybe we could pop up the piece modal for the piece you indicated or you could land at the title level. It would be more complicated to display the piece. Virginia - would prefer to go to title level to see the whole thing - usually problem-solving so want more info Sara: Yes, also would prefer to be taken to the title level rather than pulling up the piece. Often you're scrolling through and want to see how prior things looked for that series title. Virginia: Will there be user ids on who is receiving things in the system? We divide this work between 5 or 6 staff and want to know which person received it? CW: In Inventory you can see who updated the record last time. Julie: But would last update date give you the history Martina S.: Would need to be optional since we're not allowed to track or display that information Dennis: Is that a law or a library rule? Martina . Yes, it is an EU law and was in place even before GDPR CW: If you need to capture the last update user ID and date for each piece it would make sense to add it here:
Virginia: This is a nice to have - not a go live requirement. Dennis: Package purchase order lines. There was need to give the librarian the ability to relate the title POL with the package POL. In the near future you'll be able to add a POL to an order that is for a package. If you want to keep track of specific cost info for specific titles in that package or if you're adding on an additional title to that package and have to pay for it separately you can relate that title to the package POL so that when you're in receiving you see the package name and can see that relationship.
Virginia: we would have one PO for the overarching package unless there are are two invoices in which case we'd have 2 POs. Kristin M: Electronic resources. You have to pay for some ebook titles individually and the agreement would be how those things would get put together. We are only planning to do one POL per PO. So if they purchased a collection and then added 5 more titles - 6 POs - but we want the titles to be connected that we would do that on the agreement side. Virginia : Print example: Membership for mixed formats but can't think of an example of a print package then having a sub package. Can only think of e resource examples of that level of insanity. Sara: Supplement to the Roman something-something - did a lot in the past to try to link those together since they currently do one POL per PO, but in FOLIO she's thinking of moving to more than one POL on an order to show those types of relationship. Agrees that this is more common for electronic. Buy in and annual access fee - how would those get defined on the same PO since one is ongoing and one isn't. Would like the payment and invoice history to be represented together when I pull data from there. FOLIO gives different options than now and trying to think through ways to take advantage of that.
Krisitn: One-time purchase we close the order to indicate that it's done. Virginia - Year end rollover complications too. Kristin - the ERM is where we plan to make that relationship Virginia e-resources will be in inventory so we'd want to see a container to help with this too. Would be nice to connect them in orders too, but don't want to mix order types (ongoing and one time) Dennis: A POL can have a package and a title name. It also creates a relationship of cost info in Allow you to say this one relates to that one even if they are on different POs. To allow you to relate the packages together - maybe this would complicate things in ways that will require a lot of investigation/testing. It's just a relationship but if there isn't an immediate use case then I think it's ok to leave this as a foundation that could be expanded on later. The select list to relate this POL to another will be a good place to start. Virginia: Doing a diagram would be helpful - having trouble following Sara: The example of Elsevier - have restricted package of titles and then you have the Freedom collection. Those can be seen as two different packages. Those would be different POLs but want to show that the freedom collection is dependent on the Elsevier package. And I may want to list all of the titles that are in the restricted package with $0. From Owen Stephens to Everyone: 09:47 AM Kristin: The complicated relationships tend to occur in the e-resources world. Can't think of an example in print. Trying to avoid repeating things in Agreements and in orders. Virgina: Yes, everyone likely wants to avoid duplicating these relationships in multiple places, but still allow flexibility for each library to do what they want Kristin M: Back to the print plus online example - Still not sure how that works in FOLIO. Did we completely come up with a solution there? That discussion was from the "before times." From Owen Stephens to Everyone: 09:51 AM Sara: This is a cost connected thing - the cost per use for the package I do consider the two together. Dennis: The reliable actual cost info is in the invoice. You have POLs that have related invoices, so there are benefits for reporting but primarily this was about describing what you are acquiring.
Virginia: Trying to imagine what I will get from this - why do I need this? If i have a total for the PO. We are solving a lot of the complexity and relationships in Agreements. Is there a use case that could help explain this need? Kristin: I will also be using agreements for relationship building. Container would be helpful for print plus online. Virginia: You are paying for the membership so are you you artificially divvying up the cost among the titles? Sara: will use $0 for the titles - the way that EBSCO represents it on your invoice Dennis: Or you could have the package with $0 and then distribute the costs among the title POLs Virginia - that's a "dummy" structure then which isn't ideal Sara But it does reflect my invoice. Virginia - but that's also EBSCO's fake way of doing it. Cross-reference for comes-with, but the cost is for the membership and bundle. Kristin: Need to wrap up. Future topics: Erin N and Laura W want to talk Material Types, Emma B about Item States. Not sure what our next steps are for receiving. Dennis: Intuition is to keep it simple Kristin: We can talk more about this Owen: Print + Online is the big issue I agree we haven’t got to the bottom of that yet |
