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