2021-10-29 Acquisitions Meeting notes

Date

AttendeesĀ 


Agenda

  • PC Update (5 min)
  • Bulk edit updates (5 min)
  • EDIFACT invoices and Kiwi (20 min)
  • Implementers topics

Discussion items

TimeItemWhoNotes
5 minPC UpdateKristin Martin

Meeting Minutes: 2021-10-21 and 2021-10-28

Volunteer opportunity: Prioritization Working Group

  • Looking for volunteer members, putting together a new prioritization working group. Need people that are deeply engaged in their area willing to be a part of this group.Ā  There is a time limit, will submit proposal my March 2022.Ā  Please reach out in the next two weeks to the current group members. Anya Arnold, Martina Schildt, Tod Olson and Jana Freytag.Ā 


5 min

Bulk Edit Update

Scott Perry

The group had it's first meeting.Ā 

The first app will be users, expected in Jan. or Feb.Ā Ā 

8 minutes after the hourImplementers Topics -Dennis Bridges
  • #14 "Cover records" submitted by Sara Colglazier from the page.Ā 
  • Cover Records are a term that can have different meanings to different people in different systems. They can also serve different purposes depending on the order type and formats of the things they are representing.
  • Sara Colglazier: There are different types of standing orders. And represented in different ways in inventory compared to the order. I am thinking now the package will take care of that. But does the package take care of all the different types?Ā 
  • From Susan.Martin@mtsu.edu to Everyone 08:10 AM Basically a dummy record/order.
    • For some things we don't need to receive on, it will not have a record in inventory.Ā 
    • Trying to think of a way to handle approvals so am interested in this topic as well.Ā 
  • Dennis: You could use a Package Order Line as something that would link to inventory records and invoice against it.Ā Ā 
  • If you need to add additional titles than a package POL is the way to go.Ā 
  • There shouldn't be any specific impediments to opening something, adding an additional one, then opening it up again.Ā 
19 minutes after the hourContinue to review receiving enhancement mock-upsĀ Dennis Bridges
  • Ā https://docs.google.com/presentation/d/1uMGr1_HJ2yVzcJq_fTgUlibOmf8O7_SZiQCyyx4MdVc/edit#slide=id.gf8b007a9f0_0_10
  • Bulk Edits and Lists Apps Home - BELA ... and for the scope of the Pilot: UXPROD-3225
  • The value in being able to manage pieces deals with larger volumes. Being able to bulk manage is critical for serials receiving. One of the ways we can allow users to users to create pieces in bulk is to allow import from a file.Ā 
  • Dennis: Is there anyone who would definitely use this to create multiple pieces?
  • From Peter Sbrzesny to Everyone 08:26 AM Creating expected pieces for subscriptions is an important topic for us.
    Especially concerning reminders when pieces are not delivered.
  • Sara Colglazier:Ā  The benefits of creating expected pieces is that we pay for pieces we have not received yet, so a way to keep up with that is important.Ā  Need a way to create and edit.Ā 
  • From Tracy Patton to Everyone 08:27 AM Manually creating a piece for each single expected individual issue is just cumbersome.
  • From Julie Brannon (she/her) to Everyone 08:28 AM
    The publication pattern is stored in our MARC records (853) and we're looking for the expected pieces to be created based on the publication pattern defined there.
  • From Tracy Patton to Everyone 08:28 AM
    When creating multiple pieces manually to use for claiming purposes, having to update the whole batch manually when something changes is also cumbersome.
  • From Peter Sbrzesny to Everyone 08:29 AM
    We also use publication patterns
  • Dennis: We have worked on mock ups for managing publication patterns. In your current systems are you relying on the import of those marc records to generate the files for receiving that you require?Ā 
  • Julie, May rely on the MARC record for the initial set up, but once the pattern is established, the user edits on the fly.Ā 
  • From Dung-Lan Chen to Everyone 08:29 AM
    Having predictive pattern available automatically having pieces expected listed is great and having a way to generate a list of expected issues that have not arrived will have to be available with this function to make it more useful.
  • From Susan.Martin@mtsu.edu to Everyone 08:31 AM
    The amount of print that we have is not worth the time and energy for creating publication patterns or excepted issues.
    *Expected* issues.
  • From Dung-Lan Chen to Everyone 08:31 AM
    Agree with Tracyā€™s point!
  • From Tracy Patton to Everyone 08:31 AM
    MSU had not relied on MARC record pattern.
  • From Peter Sbrzesny to Everyone 08:31 AM
    We don' t have MARC records. Everything happens in our ACQ module.
  • From Dung-Lan Chen to Everyone 08:32 AM
    +1 Julie!
  • From Tracy Patton to Everyone 08:33 AM
    We defined locally.
  • From Peter Sbrzesny to Everyone 08:35 AM
    We set up a subscription order and know how many issues are expected. Then we set up the pattern for the subscription in the acq module. The next expected issue is created.
    Can you hear me Talking?
    • no
  • From Peter Sbrzesny to Everyone 08:36 AM
    Depending on the pattern the next expected receiving date is calculated and reminder Dates are set up on this.
  • From Susan.Martin@mtsu.edu to Everyone 08:36 AM
    How many print subscriptions do folks have? Here at MTSU we have less than 200. I know we're are not one of the "big" institutions, but there are others our size on the call.
  • From Tracy Patton to Everyone 08:36 AM
    That was the case in Sierra
  • From Julie Stauffer to Everyone 08:38 AM
    We used to have a fully predictive serial checkin years ago (not MARC) -- our current system does not use prediction, but it does have the ability to support saved labels for enum and chron, i.e., v. [year], and different labeling for main/supp/index
  • From Peter Sbrzesny to Everyone 08:38 AM
    My home library SUB Gƶttingen has more than 4,000 print subscriptions and About 30,000 issues received each year.
  • From Martina Karlsson to Everyone 08:39 AM
    We at Chalmers have 171 open ongoing orders at the moment. Not working with serials myself so I don't know the details, but I know some kind of predictive pattern is much wished for here!
  • From Julie Brannon (she/her) to Everyone 08:39 AM
    https://www.oclc.org/bibformats/en/8xx/891.html
  • From Dennis Bridges to Everyone 08:41 AM
    Thanks for that Julie :)
  • From Owen Stephens to Everyone 08:42 AM
    Patterns are a nightmare
  • Sara C: Considers patterns a nightmare. But the benefit is knowing what to claim. You paid for it and need to know what to claim within the claim limit.Ā 
  • Kristin: Then the reason patterns are important is for claiming, is there another way to manage? There is a lot of pre work to manage patterns. And there are not a lot of new print orders being set up for the amount of work.Ā 
  • Dennis: Sara, you are managing the receiving process in a spreadsheet?
  • Sara: We keep the patterns, like this should come weekly..... then skim to see if you are receiving in that pattern.Ā 
  • From Owen Stephens to Everyone 08:42 AM
    I wrestled with them about 20 years ago in Aleph!
    (20 years ago - thatā€™s painful to type!)
  • From Susan.Martin@mtsu.edu to Everyone 08:43 AM
    I wrestled with them in Alma and then gave up years ago as well.
    Yes. It's time to think outside the proverbial box with our traditional workflows.
  • From Peter Sbrzesny to Everyone 08:44 AM
    We are quite contented with the patterns in our system.
  • From Owen Stephens to Everyone 08:45 AM
    Is that using the MARC holdings standard for patterns Peter?
  • From Peter Sbrzesny to Everyone 08:46 AM
    No, best would be to give a short demo of it. Martina Schildt and me just talked about it as a topic for one of our next SIG meetings.
  • Dennis: The critical value of the pattern is knowing when the next expected issue should arrive, and being alerted when it doesn't arrive. It's not necessarily to have a perspective on all the of the issues that are coming in.Ā 
  • From Julie Stauffer to Everyone 08:47 AM
    I would much rather see the differentiation among the 3 standard types (main/supp/index) than necessarily prediction
  • From Julie Brannon (she/her) to Everyone 08:48 AM
    And there is value for us at Duke in speeding up check-in due to our high volume of print
  • Owen: There is also data entry, The pattern will auto fill, you just check that it arrived, rather than fill in all the information.Ā 
  • Dennis: It's a template so they don't have to think about how to fill in.Ā 
  • Owen: It's also know what information is important to record and how to record it.Ā 
  • From Julie Stauffer to Everyone 08:47 AM
    I would much rather see the differentiation among the 3 standard types (main/supp/index) than necessarily prediction
  • From Julie Brannon (she/her) to Everyone 08:48 AM
    And there is value for us at Duke in speeding up check-in due to our high volume of print
  • From Owen Stephens to Everyone 08:51 AM
    I think it would be great to take up Peterā€™s offer of showing us an approach patterns that is working effectively for them
  • From Nancy Pelis to Everyone 08:51 AM
    Sometimes having the issues in the system is helpful for Interlibrary Loan
  • From Susan.Martin@mtsu.edu to Everyone 08:52 AM
    +1. We could do that on Tuesday
  • From Owen Stephens to Everyone 08:52 AM
    Some libraries circulate issues
  • From Peter Sbrzesny to Everyone 08:52 AM
    We only ceate the next expected issue, not all the issues for the next year
  • From Lisa G Smith to Everyone 08:52 AM
    At Mich State, we tend to not predict ahead too much; maybe 3 issues in advance.
  • From Kristin Martin (she/her) to Everyone 08:52 AM
    How does predictive help ILL?
  • From Peter Sbrzesny to Everyone 08:52 AM
    No, that's too early.
  • Dennis: How much value is there for having multiple expected issues?
  • Having some use cases around needing the next two or three expected issues.
  • From Nancy Pelis to Everyone 08:54 AM
    For ILL, it is helpful to know if the issue is "arrived" or still "expected" when trying to fill article requests.
  • Dennis: No one is excited about the ability to bulk create pieces by uploading a file. Which means you would be managing the pattern in a different location then uploading to folio.Ā 
    • NoĀ 
  • From Heather McMillan to Everyone 08:56 AM
    Yes, I would use a pattern
  • From Susan.Martin@mtsu.edu to Everyone 08:56 AM
    No, MTSU will not use patterns.
  • From Owen Stephens to Everyone 08:57 AM
    Serials checkin on actual cards was one of the first library jobs I remember doing
  • From Susan.Martin@mtsu.edu to Everyone 08:57 AM
    Yup. I remember that as well. Filed card catalog cards as well!
  • Julie: Do not use predictive check in. And do not put a lot of effort into claiming. Will claim when binding and see we don't have an issue.Ā 
  • Owen: Consistency is what is achieved by copying the last one checked in.Ā 
  • From Susan.Martin@mtsu.edu to Everyone 09:00 AM
    Same here.
  • From Julie Brannon (she/her) to Everyone 09:00 AM
    This thread from our slack channel earlier this month might help provide context for the volume of print subscriptions at various institutions are which are expecting predictive check-in https://app.slack.com/client/T1EPYQDAQ/C217N937A/thread/C217N937A-1633465154.179900
  • From Susan.Martin@mtsu.edu to Everyone 09:00 AM
    To what Julie said on Claiming
  • Summary: no one's overly excited about the ability to bulk create pieces with a file by uploading a specific file, which would ultimately mean you're managing this pattern in a different interface. What many want from receiving is a way to know what information is important to record and how to record it.Ā As well as when the next piece expected is, so we know to claim it.

20 min

EDIFACT Invoices and Kiwi

NOT COVERED IN MEETINGĀ 

  • Main enhancements in Kiwi
    • Ability to link (or re-link) an Invoice line to a PO line after the invoice line has been created
    • Hotlink from Data Import log to each imported invoice line (and invoice) in the Invoices app
    • Corrected problems with acquisitions unit assignment (remember: whichever user imports an invoice and assigns a specific acq unitĀ MUST be a member of that acq unit before import
    • Created EDIFACT field mapping syntax page
  • Still being worked on
    • Import large EDIFACT file without errors (e.g. 18 invoices, 1000+ invoice lines)
      • No problem with the code. Data Import, Acq, and Perf Task Force developers working together to see if configuration changes will allow the import to succeed
      • Temporary workaround: vendor or library splits the file into individual invoices before importing
    • Map multiple EDIFACT fields to the same free-text invoice line field (e.g. details of multiple volumes shipped on a standing order) (possible bugfix in Kiwi)
  • Not fixed in Kiwi
    • POL o12345-1 and O12345-1 are treated as non-matches by Data Import. Does this need to be corrected?
    • Invoice and Invoice-line adjustments: must be added manually after the invoice has been imported, before the invoice is approved
  • If migrating previous ILS PO numbers
    • FOLIO POs and POLs cannot have punctuation except hyphen between PO and Line number (e.g. 12345-1). If former POL has punctuation, may need to be adjusted by library or vendor (e.g.Ā .o1234567)
    • FOLIO matches on POL, not PO, e.g. previous ILS PO 1ABC1234 will be FOLIO POL 1ABC1234-1
    • Possible solutions
      • Have the vendor update the library's previous POs to the new FOLIO POLs
      • Include the former ILS PO as a Vendor reference number in the FOLIO POL
      • Match on the vendor reference number (e.g. subscription number, title number, vendor order number) instead of POL

Closed Captioning transcript of the meeting

closed_caption 20211029.txt