Loading orders to Alma: EOD or RTO?
Purchase order lines might be manually created in Alma. It is also common that an order is initiated outside of Alma – in a vendor dedicated system or in a selection portal – and then loaded to Alma for processing and further management.
Purchase order lines (PO lines) can be loaded to Alma in 2 ways:
In this blog we will review advantages and disadvantages of each method.
Embedded order data (EOD)
This methodology is based on bibliographic records with embedded order data in specific MARC fields/subfields. These files should be placed on an FTP server, from which the Alma import job will take and process them.
Alma import job is a scheduled job, based on an import profile that specifies the scheduling and the mapping between the MARC fields and the PO line fields.
Alma API (Real time ordering)
Alma has a dedicated API for creating a PO line. The API is based on Alma standard API methodology – meaning an API key is required in order to use it. Submitting an API gives an immediate response including Alma PO line number, so it can be imminently displayed to the staff user that initiated the order in the vendor system or selection portal. In addition, if some of the information is missing or erroneous (e.g. invalid vendor code), an error can be displayed to the staff user and be imminently corrected.
The following table compares the 2 methodologies:
|prerequisite||FTP server||API key|
|Runtime||asynchronous (using scheduled job)||immediate|
|Number of po lines||each EOD file might include multiple po lines||the POST API creates a single po line|
|Entities||BIB record, PO line and physical/electronic inventory||BIB record, PO line and physical/electronic inventory|
|Bibliographic information||Any MARC field||Specific bibliographic information – as specified in po_line.xsd|
|Configuration options||All standard import profiles configuration – see OLH||Dedicated “New order API” configuration profile – see blog|