Discuss adding Acquisitions Method for category "free"
Discussion items
Time
Item
Who
Notes
Continue UAT Receiving results.
Dennis
Dennis has all the feedback aggregated
He is going to work on possible actions based on feedback regarding manually add pieces for receiving. We will come back to the discussion, but needs time to put something together for that to bring back to us.
Discussed short cut keys. Would like to do usability testing. Capturing some heat map data to capture where people are clicking.
Feedback about creating pieces, especially multiple pieces. For the most part, it's working the way users are expecting. The exception is receiving something that is electronic.
From Virginia Martin to Everyone 12:09 PM Speaking of Material Type, it would be great to have a Material Type list specific to the Orders app! Just had to plug that Duke wishlist item :)
Dennis: Need some indication of the different material types, and if we want to receive it or not.
Dennis: In the context of serials receiving, it was usable but is a lot of work because you have to manually create pieces. At the moment, we aren't getting a lot of value. There isn't a claiming workflow implemented. We have features for them. For those that want to manage serials receiving, what are the highest priorities that are not there?
Claiming, pattern management, notifications... what are you most interested in seeing? Are there deal breakers for not using receiving?
From Dung-Lan Chen to Everyone 12:13 PM ability to create predictive patterns
From Nancy Finn to Everyone 12:13 PM Pattern creating From Kristin Martin to Everyone 12:13 PM No deal breakers. I think getting the pieces to appear on the holdings is the biggest desire for us.
Virginia: Being able to use patterns is the biggest part. Having expected dates and generating reports on what is late. But creating individual records is to much.
FY21 checked in over 9,000 pieces.
From Jackie Magagnosc to Everyone 12:13 PM The ability to manage multiple components against the same P.O. From Shyama to Everyone 12:15 PM +1 to Jackie
From Kristin Martin to Everyone 12:17 PM Chicago's numbers are similar to Duke's
Dung Lan Chen: Also barcode each issue. Barcode field not doing anything in receiving.
Possible things to pay attention to:
Barcode only possible in receiving when you have an item record related to your piece. May be the reason not seeing as active.
In order to get item connected to piece POL has to say Instance, Holding, Item.
From Jackie Magagnosc to Everyone 12:21 PM Just for another set of numbers, Cornell Law checked in 3067 periodicals and 790 "supplementary" pieces FY 20/21
From Bob Scheier (Holy Cross) to Everyone 12:24 PM Holy Cross checks in about 500 titles
Check-in maintenance defined as a high priority. UXPROD-194
Kristin: I don’t know how many people on this call have the ability to rank things in JIRA. As community has grown it is hard to keep up with everybody and not overwhelm JIRA with too many rankings. Talking with road map group. Chicago has survived okay without predictive check-in.
From Julie Brannon (she/her) to Everyone 12:25 PM And at Duke, there are additional print serials managed in other libraries (mostly at our Law school) in addition to the numbers provided by Virginia :)
From Jackie Magagnosc to Everyone 12:25 PM That's pieces, not titles
New enumeration and chronology fields – limited by being free text fields
More context? In current system is there validation of some kind?
From Virginia Martin to Everyone 12:27 PM we use MARC holdings at Duke
Lloyd: In MARC there are two different fields controlled and not
Ann-Marie: If we need controlled and not controlled need to think about this in context of inventory. FOLIO acquisitions apps have zero understanding or recognition of MARC.
Virginia: We’d be open to standard or controlled vocabulary that isn’t using MARC, but important to recognize the level of complexity that MARC offers. Aleph has free text that you can build out hierarchically. We use MARC standard. Would like to keep this.
Dennis: I’m not sure that orders is the best place to enforce a standard. Maybe this needs to be a setting especially if different libraries are using differently. Goal for receiving workflow right now is to create more alignment with item records. If there is going to be a standard enforced, should maybe be with the item record and pieces should be informed by that.
Lloyd: Data needs to be able to move back and forth and be the same structure. Even if you aren’t using MARC at all you might want to migrate.
Dennis: Currently inventory app does not restrict. For acquisitions to be more restrictive might be a complication.
From Julie Brannon (she/her) to Everyone 12:35 PM To follow-up on Ann-Marie's comment earlier wondering if there are any JIRAs that discuss using MARC sourced prediction patterns:
UXPROD-194
-
Getting issue details...STATUS
does include a note about MARC in the JIRA description.
Ann-Marie: If you are looking to the MARC fields to provide control: Is control to enable predictive patterns? Is it to require data to be input in a certain way? What I’m hearing is more of a connection between holdings and orders and receiving than we currently have. Lloyd: I think that’s correct.
Dennis: Would not be a complex transition if MARC carries both. Concern would be migrating if people are populating with whatever they want right.
From Ann-Marie Breaux to Everyone 12:39 PM And keep in mind that right now, the only part of FOLIO that knows about MARC and has some dependency (but not required) on MARC is Inventory. We made a deliberate decision to keep FOLIO agnostic with regards to individual bibliographic formats, with the exception of the Inventory record formats.
Ability to set default for "display on holdings"
UIREC-135
-
Getting issue details...STATUS
Comment that ideally for all ongoing orders would not have to think about it and would always be checked. That was too broad for some institutions. Only checking or not checking box based on “Manually add pieces for receiving.” Could possibly have setting for the order in general so that every time you or the system create pieces that display on holding is checked. Are folks thinking they would want piece information displaying on holdings for any sort of one-time orders, e-book orders, etc.?
Martina: Would like to see link to order, but would not necessarily need any more info. (On holdings record).
Consensus in comments that link is important.
Ann-Marie: Other ones that come to mind to me are order date and status (ongoing, closed, etc.). Would that be important?
From Virginia Martin to Everyone 12:45 PM well, it might be nice to have a status with the order given Ann-Marie's example
Acquisition accordion will be a part of Kiwi.
From Shyama to Everyone 12:48 PM Also, it is important that check-in display can be limited by Acq Unit. At Duke we have some common title subscriptions for more than one library on campus.
From Marmot Office to Everyone 12:50 PM +1 Shyama
A few things to highlight regarding bugs:
Errors in piece creation – resolved post UAT
Invalid reference in location column – resolved post UAT (now storing holdings ID)
Incorrect instance match for POL when order opened – resolved for Kiwi – most often happens when print vs. electronic. Small issue with query being used to match.
System will not populate enumeration and chron in item – incomplete at time of test but will populate for Kiwi. Working on data consistency, but will still be an issue in Kiwi. If you change item record enumeration there will be discrepancy between item and piece.
From Ann-Marie Breaux to Everyone 12:51 PM For the instance matching, orders was basically ignoring the difference between valid and invalid ISBNs on an instance. Now (Kiwi) it pays attention to whether the product ID is valid or invalid for a particular instance
Creation of Inventory Records
Confusion around holdings still, when they are created vs. not created.
Moving forward, if there are no item records associated, when you delete the piece will be asked about deleting the holdings.
Also confusion about when new holdings are created vs. when existing are being used.
When in receiving area in dropdown list will see existing holdings. Order line locations shown which could be different. Those are all holdings links and will not result in new holdings.
If you use create new holdings, even one that you already have a holdings record for, you now have a location. Field looks very different.
If setting is just instance or none, can still choose a location, but no holding will be created for that location.
Hoping when we get into BugFest that this can be tested and validated.
Piece data in Receiving History accordion and order information in Acquisition accordion
More conversations about what other acq information need to display on inventory records and maybe revisit the label.
All information called from Acquisitions not actually stored in Inventory record.
Discussion regarding impact on Data Import.
Can still add receiving history manually into inventory.
On Friday
Will review desired feature enhancements from UAT overview:
Also want to discuss displaying acquisitions information on instances.
