Rebecca Bearden
My feedback
9 results found
-
425 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 An error occurred while saving the comment Rebecca Bearden
commented
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.
Rebecca Bearden
supported this idea
·
-
10 votesRebecca Bearden
supported this idea
·
-
82 votesRebecca Bearden
supported this idea
·
-
61 votesRebecca Bearden
supported this idea
·
-
57 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,
To answer your questions above, they are saying the description of the remaining predicted items that are NOT recieved yet should be updated to reflect the new pattern. Items are only recieved if they match the description perfectly to begin with, otherwise that means the pattern needed to be changed anyway. As Sylvain explained, often when a pattern is used, its under the assumption that the pattern will be consistent year after year, which often changes unexpectedly after the years worth of predicted items are already generated. While its easy to fix something that is semiannual or quarterly, since its only a few incorrect items, something that is weekly or daily is very time consuming to delete all items and start over once the pattern is corrected. Using the excel load functions to update existing predicted items is an option, but likely takes just a as much time, if not more, so I wouldn't say it is more efficient. Periodicals and other journal publications change all the time through combined issues, skipped dates due to holidays, or frequency changes. An example would be a journal that is published monthly, and then changes to quarterly, or a periodical which usually has 52 weekly issues, but then has combined issues based on when holidays fall that year, which could be different year by year. What would be helpful in Alma is to be able to correct existing year worth of issues, in addition to generating a follow year of issues, once you correct the pattern.