We would like more order types to choose from when creating additional orders on a portfolio using the “Additional Order” button. Particularly, Electronic Book - One Time and Electronic Title - One Time.

Currently there are only a limited number of order types available when creating an order via this method. This creates inefficiencies, because using the Additional Order button is the easiest, quickest and neatest way to create an additional order on a portfolio.

An example of where this change would be helpful is when purchasing additional copies of a limited-user ebook. Because we don’t have the option of creating an Electronic Book - One Time order via the Additional Order function, we have to follow an unnecessarily convoluted process to create the order and attach it to the portfolio. Simply adding more “type” options for Additional Order would save us a great deal of time.

It would be great if we could use templates for adding new items.
At the moment, whenever we add an item, for each single one of them we have to manually fill in the same values in "Material type" and "Item call number type". The "inventory date" has to be chosen manually as well.
It would be extremely useful if we could load the physical item editor form with some values already filled in, and with the date fields automatically filled with the current day's date.

If this idea has already been posted or it the option already exists, please let me know.

Thank you and kind regards
Barbara

Currently, ‘Withdraw’ and ‘Open Predicted Items’ functions cannot be performed from the ‘Received Items List’, during normal receiving operations.

https://drive.google.com/file/d/1qdNSY1xkPr71R7XJzPp8QtQJEa_h-00i/view?usp=sharing

Instead, a user must back out of the receiving windows, perform a title search, and access these features through the ‘List of Items’ window.

https://drive.google.com/file/d/17yB9XwMI6MYAmnHq95mna6cOUMpXzlbq/view?usp=sharing

This drastically decreases efficiency in performing routine tasks in Prediction, Receiving, and Weeding.

What should be changed: As Serials Processors, we would like to see the ‘Withdraw’ and ‘Open Predicted Items’ functions added to the ‘Received Items List’ window, so that all serials management tasks can be done from one screen. This would eliminate the excessive clicking needed to navigate to another window to perform these actions.

Sometimes providers change a journal’s publication frequency throughout the year. So, the prediction’s pattern selected / elaborated at the beginning of the year doesn’t work anymore in Alma. One part of predictions (date of receipt) will be ok until the change but all other predicted items will be false. Now, we can revise the prediction during the year but we must erase the items already received. We can also leave the prediction defined at the beginning of the year and edit manually the false items from the time of the prediction change.

It would save a lot of time if Alma could change the description (number, date, …) only for the items that are impacted by a new publication during the year. We would just have to fill the « Next prediction item’s information » with the new frequency.
This enhancement would save a lot of time to catalogers.

The new shortloancourtesyreminder & shortloanoverduereminder cannot be configured for multiple locations. For institutions with several hourly loan locations (for example Boston College maintains 2 and 3 hour loan periods for Course Reserves and a 4 hour loan period for some technology items) this dictates that the reminder notice has to be set based on the location with the shortest loan period. The overdue notice must be timed to make sense for for the longest loan period.

In our test configuration we used the following time parameters:

​shortloancourtesyreminder - 105 minutes
shortloanoverduereminder - 241 minutes

However, this creates a situation whereby patrons borrowing from some locations will have already incurred an overdue charge before the overdue notice is sent.

In order for this functionality to provide the service is designed for, it must be robust enough to support different loan periods.

https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/080Configuring_Fulfillment/110General#Configuring_Fulfillment_Jobs

When the URL in a bib record attached to a portfolio is updated (individually edited, or batch load/overlay of records), there should be a setting to the action so that the URL in an attached portfolio would also be updated and we don't have to remember to manually do this. We have had 2 recent instances, one where we used APIs to update bib records using our old PURL manager to use our new one, only to find that the portfolio URLs also needed to be changed separately, and one where we have a batch of vendor records with changed URLs that we had to delete and re-add in order to get the portfolio URL updated. Both of these were large batches... We'd like to tell Alma to synch URLs in the attached portfolios when we make a manual edit, or load/overlay a batch of records.

If there's a way to do this we don't know, please tell us!

When opening predicted items, the Description-Field is populated by the data provided in “Next Predicted Item´s information” and displays these data in a certain punctuation-logic. Unfortunately, this logic is not equal to the description- (and punctuation-) logic used in German speaking countries (which is following ZETA-Standard) – and there is no possibility to edit this. Since there has to be a correct description (for sorting etc.), the only way is to open and edit every single item once it is created by prediction pattern. This is causing a lot of unnecessary work to be done manually - we need the description template to be editable so that items with a correct description can be created automatically in the first place!

Impact of Problem: Predicted items are displayed in a certain logic, for example: “V:No(Year)” [journal] or “Year: Day” [newspaper]. Format needs to be editable to suit local format (and punctuation) logic – for example “V.Year,No” [journal] or “Year,Day” [newspaper]

Preferred Term Correction is not flipping all LCSH headings when the authority record changes. If there is an authority record that has a subdivision, it is only flipped by PTC if the heading in the bib has no additional subdivisions. This means there is a significant gap in the PTC process that requires manual attention and handling, which is unsustainable. The PTC process needs to be more thorough.

For example, this LCSH:

$a Germany $x Politics and government $y 19th century

was updated by LC to be:

$a Germany $x Politics and government $y 1789-1900

When the authority record changed, bib headings that had the original $a $x $y (only) were flipped by PTC to have the new $y. But any headings that had additional subdivisions were not flipped.

For example, this bib heading was flipped to the new form:
BEFORE: $a Germany $x Politics and government $y 19th century
AFTER: $a Germany $x Politics and government $y 1789-1900

But this bib heading was NOT flipped:
$a Germany $x Politics and government $y 19th century $v Congresses.

More example of headings that were not flipped but should have been flipped:
651 0 $a Germany $x Politics and government $y 19th century $v Caricatures and cartoons.
651 0 $a Germany $x Politics and government $y 19th century $v Congresses.
651 0 $a Germany $x Politics and government $y 19th century $v Exhibitions.
651 0 $a Germany $x Politics and government $y 19th century $x In literature.
651 0 $a Germany $x Politics and government $y 19th century $v Periodicals.
651 0 $a Germany $x Politics and government $y 19th century $v Poetry.

Impact of Problem: The fact that PTC does not flip these headings means that staff have to manually correct hundreds or thousands of headings. The PTC process is lacking and is not performing its function of managing authority control automatically.

It would be nice to be able to move up and down within a field using arrow keys in MDE. For example, when a lengthy 505 or 520 MARC field has many lines, the cataloger must now move to the desired line using either mouse or left/right arrow keys, since pressing up/down arrow causes the pointer to move to the previous/next field.

My suggestion is that the pointer should be able to move within the field using up/down arrows and move only to the previous/next field when the pointer is on the first/last line of the field.

Using up/down arrow keys when moving within a field would streamline cataloger’s work and help making the MDE more user-friendly.