Acquisition librarians want to extend the current "interested users" functionality in order to serve the end user in a better and faster way. The current "interested users" functionality is not sufficient enough, to become useful and really benefit from this functionality we would like to extend it with:
• The ability to sort the interested user list.
Use case: some users (e.g. academic staff) have priority and should get the issue first!
• Make it possible to create hold requests on these items regardless of the existing fulfillment policy:
Use case: some libraries don't allow requests for available items, but this means they're not able to request items for interested users during receiving. (Apparently in the beginning of going live with Alma this was possible...).
• Make it possible to automatically loan the issue to the first interested user when receiving! This way limited routing functionality is made possible for (print) journal subscriptions.

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.

As a Purchasing operator, I would like a better correspondence between the number of items ordered and the "Quantity for pricing" in the PO line summary.

When we are ordering more than one item of a physical title, we have to add the extra items in the Quick add field, and then have to update the Quantity for pricing field manually. We see that Purchasing operators tend to forget to update both fields. The result is that the number of items that we intended to order, not always corresponds with the number of items that is supplied by our vendors. This causes a lot of extra work for the Receiving operators. The best thing would be if Quantity for pricing were updated automatically when we added new items. If this is not possible, it would help a lot if we could get a warning or a confirmation message when the number of items differs from the number in the Quantity for pricing field.

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.

From time to time, a vendor interface goes down temporarily. While we follow the access issue up with the vendor, we add a public note for our students and staff indicating that the interface is temporarily down. The issue is that often we have many electronic collections with the same interface, and therefore must add a public note to each and every electronic collection that uses the affected interface, and then remove all of the notes once access is restored.

Since all of these electronic collections link back to a single interface, it would be great if there were a field in the interface screen to add a public note about temporary interface unavailability that would appear in the discovery layer for all eresources (portfolios) in the electronic collections linked to that interface.

This would improve the process by significantly reducing the time it takes to add/remove public notes to multiple electronic collections - and also reduce human errors when a public note for a particular electronic collection is missed.

Working with purchase orders and invoices requires frequent switching between a purchase order and invoices attached to it. Under the tab Invoice lines in a purchase order Invoice Numbers are listed to the left. On the right side there is a View button, which gives some basic information about the invoice.
In order to view payment date, cheque number, view attached invoice, view other purchase orders associated with this invoice, one must copy the invoice number, then go to Invoices in Open Search Menu, paste the invoice number and then access the invoice record that way.
To directly access invoice records through hyperlinked invoice numbers in PO would save time and make work more efficient.

If this doesn't work, then to access the entire invoice under the View button would be helpful, as well.

Current Alma practice is that EDI invoices automatically load into Alma and expend from a fund whilst still 'in review' and before the 'approval' stage.

Below are some examples where the practice of expending a fund whilst the invoice is still 'in review' is causing us issues:

1. We have full end-to-end invoice integration from our suppliers, via Alma and into Agresso. We don't send through manual invoices for payment. Our invoice data is automatically transferred through to Agresso every evening once an invoice has been approved. Only those invoices that have moved out of review are included in the export. Any invoices 'in review' will not be in the export but will be showing as expended on our system. This means that Agresso and Alma will always be out of step whilst we have invoices 'in review'. This makes it impossible to reconcile Alma and Agresso.




2. Some invoices have over 200 lines and it may take us some days to work through each transaction. There may be issues with incomplete or inaccurate data. We have to make a few manual amendments in order to ensure that the Agresso transfer completes successfully. Only once all of that is done do we 'approve'. Whilst this is happening our Alma and Agresso systems are out of sync. What is the point of the approval step?




3. We are working with IT on enabling the accrual accounting functionality so that our Finance Team don't have to maintain a separate spreadsheet of prepayments and meet monthly to reconcile. There is little benefit to be gained from working on this functionality if, once again, the two systems are always out of sync. We can't reliably turn up to meetings to discuss our accounts when the Alma reported expenditure includes invoices that aren't yet paid.




4. If an invoice arrives that doesn't have an Alma PO number on it, the transaction amount is expended but because there is no PO to match to the amount remains encumbered too.

Any 'in review' invoices should remain as 'encumbrance' until they have been 'approved' or have another 'pending expenditure' type invoice status.

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.

At the moment Alma only sends one claim request to the vendor. If the ordered item is still not received, staff need to follow up and re-claim manually; usually a number of times.

We would like to see claim cycle functionality in Alma so that we can configure follow-up claims based on a set interval per vendor, as well as a maximum number of claims to be sent before the order is automatically cancelled and the vendor automatically notified. It would also be useful to be able to see the history of claims for an order, and be able to report on this for vendor performance monitoring.