2021-10-05 Acquisitions Meeting notes

• 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: 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

• 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.

• 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

• 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.

• 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.

• Will review desired feature enhancements from UAT overview
• Also want to discuss displaying acquisitions information on instances.