Acquisition librarians want to add automatically the "item policy" and "temporary location" to predicted issues to speed up their work and limit the number of clicks. At this moment the added value of prediction pattern functionality is being restricted by the lack of functionality (parameter setting) …
Use case: It’s not possible to add the item policy/temporary location as a parameter to continuous pol’s. If issues are created via prediction patterns the item policy/temporary location should be indicated automatically based upon parameter settings on pol level. This would save a lot of time and additional clicks when receiving the issues.
In addition this should also be possible when items are created based upon templates via the “receive new items” button.

In Alma task lists ...

• Electronic resources - activation - unassigned (Electronic Resource Activation Task List)


• Order Lines - review - unassigned (Purchase Order Lines in Review)


• Invoices - review - unassigned (In Review Invoices)

... there is only a row action ("..." button) to start the "Assign to" dialog which opens a pop-up window where you can select a user. Our colleagues are not satisfied with this cumbersome assignment functionality.

The missing functionalities are:
(1) a one-click "Assign to me" button
(2) a bulk functionality for "Assign to" and "Assign to me" (it is already possible to mark several records in the task list but you can only change the Status with a bulk action)

As someone who manages serial subscriptions, I would like the ability to choose the quantity of predictions I create for any given holdings record. This would allow for quicker navigation of list of items, and reduce the number of inaccurate predictions.

It is not always desired to predict an entire year’s worth of predictions (which currently is the only option). Depending on the publishing frequency and the number of copies of a subscription, we can have 11 pages of predictions in a list of items, in addition to the received items. This greatly increases the amount of clicking needed at times to find the item you are looking for. Also, due to variations in publishing schedules and the general inconsistent nature of periodicals, creating weekly predictions a year in advance often results in inaccurate predictions which will need to be modified later.

It is possible to upload attachments to a PO Line or an invoice. These attachements can be viewed, edited and deleted as well.

In case of using Alma as (the only) data storage for e.g. invoice PDFs, it is very important that attachments can be deleted only by specially privileged staff users. Deletion might be necessery e.g. because of erroneous uploads.

Looking into the 'Roles Reports' shows that there is no 'Delete' option listed (so Edit means also Delete):

Purchasing Operator / Purchasing Manager

• polineattachments.xml ... View Edit


• po_attachments.xml ... Edit


• invoiceattachmentstab.xml ... View


• polineattachments.xml ... View


• po_attachments.xml ... View

Purchasing Operator Extended

[nothing for attachments]

Invoice Operator / Invoice Manager / Invoice Operator Extended

• invoiceattachmentstab.xml ... View Edit


• polineattachments.xml ... View Edit


• invoiceattachmentstab.xml ... View


• polineattachments.xml ... View


• po_attachments.xml ... View

The 'Delete' and 'Edit' options should be removed from user roles which are allowed to upload and view attachments.
The 'Delete' option should be be an own user role. Alma already has this differentiation in other areas, e.g.:
- Purchase Request Operator Extended (Delete purchase requests)
- Selector Extended (Delete purchase requests)
- Cataloger Extended (additional delete privilege)
- Physical Inventory Operator Extended (additional delete privilege)
- Electronic Inventory Operator Extended (additional delete privilege)

At the moment, when you link to an interface from a vendor record in Alma the interface record cannot be linked to one that has already been set up. For example, if you have Vendor A and link it to Interface X you cannot also link Vendor B to Interface X. You are also unable to have two interfaces with the same name. This is required in situations where we have multiple vendors for the one interface. For example, SAGE journals are acquired directly through SAGE but the ebooks are acquired through iGroup. In this case we would like to link the SAGE interface to both vendors SAGE and iGroup. That way we only need to update the one interface record for SAGE.

We are aware that this is a fulfillment configuration, but it is one which causes problems with acquisitions.

We would like the ability to 'edit' existing location codes that would automatically update everything within those locations to the new location, including holdings, items, and PO lines...rather than having to create new locations and move things before deleting the old location.

This would eliminate the problems with "change physical items" jobs that don't change locations for things with no items attached (common with serials).

This would also eliminate the problem of POs becoming unlinked from holdings when a location is changed. For example, we recently changed a location name that had many standing orders for serials, and thus open POs. Now when we try to receive something, the PO has to be updated every time because a location is mandatory and the old location was deleted thus the PO has no location associated with it. There are hundreds of these, possibly thousands.

It would also be helpful if the "Change PO line information" job included space for changing the location.

The Alma renewals workflow for continuous resources (Subscription POLs) involves creating Invoices and updating the renewal date and other data such as Notes in the Purchase Order Line. This should be possible as part of a unified workflow when invoicing, i.e. adding the invoice line and then linking through to a live Purchase Order Line to update and save the renewal date etc.
Currently the Invoice Line PO Line link is View Only which means a separate search and action is required to find and update the renewal dates etc in POLs. This is inefficient and wastes time - given that this is a core workflow and this information needs to be updated for all subscription POLs as part of the renewal process. It also increases the chances of forgetting to update the renewal date and having resources appear in error in Waiting for Renewal and Order Lines with Claims lists.

In the list of licenses it would be useful to have a colour/shading gradient difference between active and inactive licenses.
For example, when you delete a license it still remains in Alma, it is just given the status deleted. This is fine as it provides a history, however, as the deleted licenses in the list look exactly the same as active licenses, apart from the status note it can often be difficult to tell the active and deleted licences apart, especially at a glance.

It would be useful to change the colouring/shading gradient, for example, grey out the text, for the deleted licences to make the Active licenses prominent, so you can quickly determine the correct license to link to a collection etc.

A similar thing for the retired licenses would also be great.

It would be useful to have some additional search criteria, such as operator id, and facets, such as a last update date range and status, available to monitor staff productivity. Not just in purchasing but in all areas of acquisitions the site reports the need for functionality that will allow a combination of attributes of the records to generate results. For example, an operator should be able to search using their user name, some category of task (po lines in review, invoice lines in review, invoices pending approval, etc.) and a date or date range, or status (sent/ waiting auto packaging, etc.). Typically operators are expected, as a point of quality and workflow management to "self-police" and answer questions such as: what is the status of the invoices/invoice lines I handled today? have all the purchase order lines I worked on today been resolved? Etc.