The National Library of New Zealand (NLNZ) is ordering and receiving an increasing amount of born digital material, particularly through Legal Deposit. These publications are collected as individual monograph publications and serial issues, not as part of an aggregation or domain/website harvesting, for the purposes of long term access and preservation in our Heritage Collections. They are publications in their own right, not digitised version of print holdings. Alma’s Acquisitions workflows do not currently have any options to allow for steps that are specific to receiving born digital material.

Our current workflow involves the creation of Vendor records and POLs using a physical workflow (Print Book – One Time or Print Journal – Subscription). This allows us to manage vendor information, orders, claims and occasionally invoices. Born digital material is distinguished by a specific location and material type. We receive each born digital item in the physical workflow and then ingest it into our repository (Rosetta). There is then a synchronisation between systems that creates the digital rep and updates the label information. This means, particularly for serial issues, that we are duplicating data in the receiving (Alma) and ingest (Rosetta). The physical location we use for all born digital material is supressed so that what shows in Primo is the digital rep, not the physical item.

What we would like to see is a suite of born digital options within acquisitions in the same way as there are currently separate options for electronic material. This would include functionality for additional information such as access levels, in vendor management, orders, claims, invoices etc.. Our thinking is that the critical difference in a born digital workflow is functionality where item receipt is triggered by the creation of the digital rep either in Alma or through syncing with an external repository. This would remove the need to enter data twice and would also allow us to manage a claims workflow effectively.

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 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.

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.

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.