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