Tech Blog

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:

EODAPI
prerequisiteFTP serverAPI key
Runtimeasynchronous (using scheduled job)immediate
Number of po lineseach EOD file might include multiple po linesthe POST API creates a single po line
EntitiesBIB record, PO line and physical/electronic inventoryBIB record, PO line and physical/electronic inventory
Bibliographic informationAny MARC fieldSpecific bibliographic information – as specified in po_line.xsd
Configuration optionsAll standard import profiles configuration – see OLHDedicated “New order API” configuration profile – see blog

Leave a Reply