Rebecca Bearden
My feedback
9 results found
-
10 votesRebecca Bearden
supported this idea
·
-
82 votesRebecca Bearden
supported this idea
·
-
422 votes
Thank you for the suggested idea.
After reading it carefully, I understand that the main pain point here is the removal/fix of items already received.
To be more specific, the description of already received items should be updated to reflect the new pattern.
- Is this understanding correct?
- How often such change happens?
- Can you please add examples of the existing description and the needed update?
- Can the 'Update items using Excel load' CloudApp be utilized for fixing the description? see https://developers.exlibrisgroup.com/appcenter/item-updater-by-excel/
Thanks for the collaboration,
Tamar Fuches
Alma product
An error occurred while saving the comment Rebecca Bearden
supported this idea
·
-
60 votesRebecca Bearden
supported this idea
·
-
58 votesRebecca Bearden
supported this idea
·
An error occurred while saving the comment Rebecca Bearden
commented
I have had some luck with getting the fall/autumn season to start by utilizing the subfield x and y. Example: $$a v. $$b no. $$u 2 $$v c $$i (year) $$j (season) $$w f $$x 23 $$y ps23,21 $$8 1 for a publication issued Fall, then spring the following year. I will note that you also need to be careful what you input as your issue date. You may have to be more generous or conservative with that date for it to choose the proper year for each issue. However, the season prediction pattern problems I run into that are still problematic are 1. preferring Fall over Autumn in general. It would be nice if there were a way to specify which is preferred for a particular publication rather than editing manually, and 2. Whether winter is the final issue of the year, or the first issue of the year. It typically defaults as the first, and creates incorrect patterns depending on which year you want that issue to reflect vs. the others in that volume.
-
98 votesRebecca Bearden
supported this idea
·
-
97 votesRebecca Bearden
supported this idea
·
-
22 votesRebecca Bearden
supported this idea
·
-
171 votesRebecca Bearden
supported this idea
·
Hi Tamar, I think the intent behind this suggestion is more flexibility with existing predicted items/patterns, not post receipt cleanup. Currently, if you predict a years worth of items, for example, a weekly periodical, and 2 months in, there is an unexpected combined issue or skipped issue, the enum or chron for all subsequent issues is completely thrown off. You then have several options but all are labor intensive.
1) You could delete the all incorrect expected items for the remainder of the year, create a new/updated pattern with that exception built into the $$y, and then re-create expected items. You then have to delete the duplicates of the issues you've already received.
2) You could manually update each item for the rest of the year as recieved, which slows down the whole point of having expected items in the first place (ready for quick/accurate receipt and description). Then, when the year is over, you could ensure that the following year's pattern is correct.
Solving this problem would require Alma to be able to correct the existing items that have NOT yet arrived using updated pattern information, without disrupting already recieved items for that year. The manual options mentioned above are easy for something like a quarterly publication, but a daily or weekly publication can be very inconvenient, especially if the publisher is not consistent about it year after year.