Previous customers who migrated from Spydus to Alma did not provide suppressed bibliographic records. Suppressed records are those that are in the system and can be seen by cataloging staff, but cannot be seen by patrons.

If there is information in a field embedded in the bibliographic record, the migration programs can generate a holdings record from it. Fill in the values of the following fields in Holdings tab of the Spydus (Civica) Field Mapping form. If the SUMM_LIB_CODE and SUMM_LOC_CODE match an existing holdings record on the same bibliographic record, even a holdings record that was generated from items attached to the same holdings record, then the summary holdings statement will be attached to that holdings record, regardless of the call number. In other words, the summary holdings record will be placed on the holdings record with the same library and location, even if 852_SUBFIELDS_FOR_HOL contains call number subfields for matching like bchi. If there is no existing holdings record on the bibliographic record with the same location, a new holding record is generated.

Expected Field Name	Value	Notes
SUMM_TAG		Five characters; tag+2 indicators.  May use # as wildcard, for example, 866## or 86#3#.  Wildcard allowed for third digit and indicators but not first two digits. To indicate a space character, use b, for example 866b1.
SUMM_SUBFIELDS		Multiple subfields allowed, e.g. abz. May use # to indicate all subfields.
SUMM_CALLNO		Textual call number to be used in all newly generated holdings records if desired.
SUMM_LIB_SUBF		A single subfield code (like 'a') which contains a library code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
SUMM_LOC_SUBF		A single subfield code (like 'a') which contains a location code in local ILS format. Do NOT enter a different bib tag. The migration program searches for a subfield within the SUMM_TAG bib tag.
SUMM_LIB_CODE		If SUMM_LIB_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a library code in local ILS format.
SUMM_LOC_CODE		If SUMM_LOC_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a location code in local ILS format.
SUMM_PUBLIC_NOTE_SUBF		Public note, will be placed in 852 $z of the generated holding record
SUMM_NON_PUBLIC_NOTE_SUBF		Non-public note, will be placed in 852 $x of the generated holding record

You may want to provide item descriptive information in a secondary file. For example, you have a description in the format Vol. 12 No. 2 (2015 February), but Alma recommends that enumeration and chronology information are without labels and are in separate fields. You can provide your description in a secondary item file.

We recommend that EnumX and ChronX fields contain only numbers, for example '12' instead of 'Vol. 12' and '2' instead of 'Feb'.  However, it is programmatically time-consuming to distinguish between an invalid use (Vol. 12) and a valid use (12A), so in the interest of processing quickly, we allow any string in EnumX and ChronX fields.  Do not provide a full date in a single field.  Split any dates into three, for example 4 Feburary 2020 is ChronI=2020, ChronJ=2, ChronK=4.   

Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:

Expected Field Name	Notes
item_key	Provide either item_key or barcode, but not both. If both are provided, item_key is preferred Always provide both fields, even when one is empty.  E.g.
barcode
description	Provide in a format such as: Vol. 12, No. 6 (February 2015)
enumA	For example, “12”.
enumB	For example, "6".
enumC
enumD
enumE
enumF
enumG
enumH
chronI	For example, "2015"
chronJ	For example, "2".
chronK
chronL
chronM

Use this tab to create a list of libraries in Alma. At least one library is mandatory.

Alma Library name: Maximum 255 characters. This is visible to the public. This must be unique.  For example, you cannot have two libraries with code LIBA and LIBB and have them both called 'Library'.  They must have different names.

Address lines: Alma allows you to specify address, phone, and e-mail information about each library. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma (shipping, billing, claiming, etc.). At least one address line is mandatory.

Email: At least one email address is mandatory.

Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Further Explanation: The Spydus location, which is the higher level of location is comparable to the Alma library. Use the Alma Libraries tab in the Spydus Migration Form to indicate your list of Alma libraries. The actual mapping from the Spydus location to the Alma library is done in conjunction with the Spydus collection in the Alma Location tab.

Use this tab to map your Spydus locations and collections to libraries and locations in Alma. Filling in this tab is mandatory.

Spydus Location (LOC): Value from the field in the item extract. This is the higher level of location. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.

Spydus Collection (COL): Value from the field in the item extract. This is the lower level of location. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.

Spydus Location Description: A description of the location, for assistance in filling out this form. This column is not used in the mapping routine.

Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in Spydus, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.

Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Spydus, but this is not required. You may also use this form to collapse locations if desired, for example General_A and General_B in Spydus both map to General in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicator. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item record itself, we use this as a default for all items in the location.

Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.

Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.

Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.

Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.

Further Information: Do not leave the Alma location and library code fields blank. If you wish to stop using a location code after migration, map the Spydus code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Spydus database.

Use this tab to map your item statuses to Alma. This tab is not mandatory if you do not want to migrate your item statuses to Alma.

Spydus Status: The value in the status field from the Spydus item extract. The status typically indicates what is happening to the item, such as in binding, in repair, lost, etc.

Description: The description of the Status code. The text in this column is written to the internal note 1 in the item in Alma. Maximum 255 characters.

baseStatus: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, At Library Counter is on the shelf (1), but Being Repaired is not (0).

Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from Spydus are given the process type of TECHNICAL.  Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.

Include any status that may indicate no status, for example Available, but leave column B blank. This migrates the item to Alma with no status at all, which is how Alma indicates that an item has no status. If any status is in your data but is NOT included in column A, it is given a note of Unknown status.

Post migration, you can search for and re-route items with values in the internal note 1 to the appropriate handling or department in Alma. This process can also be used as a configurable criterion for suppressing items from display in the Get It services screens from discovery systems. See Appendix - Post-Migration Process Statuses for more information.

Use this tab to migrate the Spydus Item Type to the Alma Item Type. Not mandatory. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.

Spydus Item Type: The value in the item type field of the Spydus item. The item type is used to differentiate between items when determining how something circulates.

Spydus Description: The description of the Spydus item type, for information only. This column is not used during the mapping process.

Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired.

Alma Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.

You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.

Bibliographic records are migrated as is and each bibliographic record may be marked with Alma management tags in the following way during migration:

• Australian customers have ALL Bibs marked for Libraries of Australia Publish, if relevant.
• OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.
• The LDR position 9 (character coding scheme) is set to a indicating Unicode.

Spydus extracts provide Bibs and items, but not holdings. Holdings are mandatory in Alma, and, therefore are created based on the item data. The permanent location and call number in Alma is only stored in the holding record. All items attached to the generated holding record have the same permanent location and call number. On migration, the call numbers for any new holding record created are generated from the first item found in the group of equivalent items. By default, a group of equivalent items is determined by the location of each item attached to the same bibliographic record. For example, if a bibliographic record has five items:

• Item 1, 2 in Location A
• Item 3, 4 in Location B
• Item 5 in Location C

The migration program generates three different MARC holdings records, one for each location A, B, or C. The items for each location are then attached to the newly created holding record. If there are any call numbers that differ from the holding record’s call number, the differing call number is stored in the item’s Item Call Number field.

The item barcode must be unique in Alma, but it may be left blank.

The item barcode is migrated according to the following rules:

• If the incoming barcode is empty, the barcode is left as empty.
• If the barcode exists but is not unique:
  • First item barcode encountered – migrate as is.
  • Second and subsequent item barcodes encountered – migrate as <item barcode>-<item id> .

Because it is possible to use the barcode as the link between item and loan, request,fine,or order, if one of those is linked to an item with a duplicated barcode, it will be linked to the item with the unsuffixed barcode.

The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified.

If not provided in the extract, the migration automatically assigns a material type based on bibliographic record LDR and 007 fields. There is no customer input required for this part of the migration as the Alma types are fixed. The material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the resource type is determined, see the Resource Type Field description.

There may be a number of fields in the patron record that are user identifiers. The types of identifiers that are available for migration into Alma are listed in the left column. The typical expected field names from Spydus are in the right column. Change the field names and/or order of the right column to suit your library’s extract. The values in the left column cannot be changed. Use the values in the left column to select the appropriate primary identifier in the Questionnaire tab of the Spydus Migration Form. If there is a field that contains a note specific to the identifier, put it in the far right column.

Alma Identifier Type	Spydus Field Name	Spydus Field Name that Contains a Note
UNIV_ID	MEMBERSHIP_NO	MEMBERSHIP_TYPE
BAR	NRIC
ADDL_ID_1
ADDL_ID_2
ADDL_ID_3
ADDL_ID_4

There may be a number of fields in the patron record that function as a statistical category only, for example, a student’s department or major. The way the student borrows can be determined by the user group, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since there may be more than one field that has statistical information, we provide you the option to map the data from any field to the User Statistical Categories in Alma.

User Statistical Category	Local Field Name	Field Label
USER_STAT_CATEGORY	CATEGORY	DEPT:
USER_STAT_CATEGORY
USER_STAT_CATEGORY

You can add more lines as necessary, up to a maximum of 10 lines. To map the values, use the UserStatCategories map in the Spydus Migration Form. If a value is not found in the map, it is migrated as is. If you use a label, the userStatCategory map tries to map the field including the label. The first column in the userStatCategory map would be: LABEL: value, for example: COLLEGE: Law.  The migration program does not provide a colon, so if you want the colon to be present, include it in the label as above.  The migration program does provide a space between the label and the value.

If you use this prefix, be sure to use the prefix again in the Migration Form Mapping tab for User Stat Categories, in column A (incoming data).   In the Field Mapping form, provide labels to the right of the field:

Then, in the migration form, use that label as a prefix to the values in the field.  Be sure to put a space between the label and the code:

In the case above, you can see that if there were no prefix to the fields, it would not be possible to distinguish between 'b' from PC1 and 'b' in PC2.

Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration, but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary.

The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.

Note Name	Information
LIBRARY_NOTE
BARCODE_NOTE
ADDRESS_NOTE
OTHER_NOTE	OTHER_NOTE is set as user viewable by the migration programs.  This is the only note which migration marks as user viewable.
CIRC_NOTE	The 'CIRC_NOTE' is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.

Some customers may desire to provide multiple blocks per patron record. In this case, the patron blocks can be provided in a separate file.  The patron ID may have multiple entries in the file, meaning that a patron may have multiple blocks on their record.

Note Name	Information
PATRON_IRN	matches IRN number in patron file
ZBN	use in User Block map in the migration form
BLOCK_CREATE	create date of block

Extract only current circulation transactions. The loan file is expected in xml format, as a standard Spydus extract.

The fields in the following table are expected. Indicate the local field names for the expected fields in the Loans tab of the Spydus (Civica) Field Mapping form.

Field Name	Notes
<RECORD IRN>
<CREATED><FLD><DATE DISP>
<CREATED><FLD><USER XCODE>
<LASTUPD><FLD><DATE DISP>
<LASTUPD><FLD><USER XCODE>
<OND><FLD><BRW BID>	Matches patron ID in patron file
<OND><FLD><ITM ITN>	Matches item barcode in item file
<OND><FLD><LDTE DISP>
<OND><FLD><LTIM DISP>
<OND><FLD><RNW>	Checked for renewal status; if you also want the  number of renewals, put this field in a note
<ONC><FLD><DDTE DISP>

Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.

The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label can be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.

Note Name	Default Local Field	Note Label
NON_PUBLIC_NOTE	<OND><FLD><RNW>
NON_PUBLIC_NOTE	<OND><FLD><INHOUSE>

Extract only requests which are on the shelf waiting to be picked up.

Provide the request file in xml format.

The fields in the following table are expected. Indicate the local field names for the expected fields in the Requests tab of the Spydus (Civica) Field Mapping form.

Field Name	Notes
<CREATED><FLD><DATE DISP>
<CREATED><FLD><USER XCODE>
<LASTUPD><FLD><DATE DISP>
<LASTUPD><FLD><USER XCODE>
<RVP><FLD><BRW BID>	Matches patron ID in patron file
<RVP><FLD><BIBISS BRX>
<RVP><FLD><TLOC XCODE>
<RVP><FLD><XDTE DISP>
<ITMRSV><FLD><LNK ITN>	Matches item barcode in items

Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.

The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.

Note Name	Default Local Field	Note Label
NON_PUBLIC_NOTE

Extract only current fines and fees. Fines and fees which have a zero balance are not migrated to Alma. Provide the fines and fees file in csv format.

The fields in the following table are expected. Indicate the local field names for the expected fields in the Fines & Fees tab of the Spydus (Civica) Field Mapping form.

Field Name	Notes
Borrower	Matches patron ID in patron file
Accession No	Matches item barcode in items
Charge Code	Use in Fine Fee Type map
Charge Amount
Total Amount
Amount Due
Charge Date
Created
Last Updated

Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following table in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris.

The text in the Note Label column are used as a prefix to the subfield contents and can be modified. The note label may be in Unicode. If you want to include multiple local fields in the same Alma note, copy the line in the spreadsheet as many times as needed for all note name/local field combinations.

Note Name	Default Local Field	Note Label
FINE_FEE_COMMENT
FINE_FEE_COMMENT
FINE_FEE_COMMENT

The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, undergrad, etc.

If patrons are being migrated, then this mapping table is mandatory.

Spydus Category: The Spydus patron type code, found in the CATEGORY field of the patron extract.

Spydus Description: A description of the Spydus patron type code, here for information only. This column is not used in the mapping to Alma user group.

Alma userGroup Code: The mapped group code in Alma. You can choose to use the same codes that you used in Spydus, or you can choose to use different codes. You can also choose to collapse groups if desired, for example, having Freshman and Sophomore both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.

Alma userGroup Description: The description of the Alma userGroup. This description is loaded into the Alma code table as the description seen in the user interface. This description can be changed easily after migration.

Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are minority cases where community borrowers or alumni use library services. When Y, all of the patrons in the Alma userGroup are categorized as internal. When N, all of the patrons in the Alma userGroup are categorized as external.

External users are fully external (except patron notes), including all user identifiers and authentication and address information.

See also the following question on the Questionnaire tab, regarding Internal or External users:

• Which identifier should be used as the patron's Primary Identifier?

A user block is assigned to patrons that have a temporary suspension of borrowing privileges. Spydus stores patron blocks in the BLOCK_CODE field in the patron record.

This mapping table is not mandatory.

Spydus BLOCK: The Spydus patron block code as found in the patron extract.

Spydus BLOCK Description: A description of the Spydus patron block code, for information only. This column is not used in the mapping.

Alma userBlock code: The block code desired in Alma.

Alma userBlock description: The description of the block code in Alma. The value in this column is loaded to the server in the userBlock code table. This description can be easily updated after migration.

Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the CAMPUS_CODE to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.

The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the HOME_LIBR field in Spydus for a similar purpose, map the HOME_LIBR value to the Alma Campus Code value with this map.

Spydus USER_LIBRARY: The value of the patron home library as found in the HOME_LIBR field of the patron extract.

Spydus USER_LIBRARY Description: A description of the HOME_LIBR field, for information only. This column is not used in the mapping.

Alma campusCode: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes, if desired.

Alma campusCode Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.

Further Information:  Unlike other mapping tabs, the campus code and description are not loaded as a code table to Alma.   Customers should set up campuses in Alma.

Use this tab if you use statistical categories in your patron records and you want them to migrate to Alma. In Spydus, it is possible to have multiple fields that contain statistical codes.

Before filling in this tab, specify in the Patrons tab of the Generic to Alma Field Mapping form which fields from your legacy ILS are migrated to statistical categories in Alma. You can include a label before each category to distinguish between categories in different fields. For example, you can have LAW in USER_CATEGORY1 and also LAW in USER_CATEGORY2. If desired, use a prefix to distinguish between the two, for example, CAT1: LAW and CAT2: LAW. 

Spydus Statistical Category: List all of the values from all of the fields you chose to put into the statistical category mapping. For example, if you used all three fields HOME_INST, DEPT, and SCHOOL, list all values from all three fields in Spydus. Include the label applied if it is important to distinguish between values in different fields.

Statistical Category Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.

userStatCategory Code: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.

userStatCategory Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be easily updated after migration.

The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier for the patron.  You may map multiple identifiers from your previous ILS.  You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.

When selecting the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. 

If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.

Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.

Code: CENTRAL_ORDER_LIB

Default: None

Code: RENEWAL_DATE

Default: none

Options: Default renewal date for subscriptions. If your subscriptions are generally ordered on the same cycle and you do not provide that renewal date in the order data itself, place that date here. The first choice of populating this mandatory field for ongoing orders is based on explicit renewal date information in the order. The second one is to populate based on the answer to this question (if populated). The default is renewal date = migration + 1 Year. The fallback is used only if no renewal date is provided in the orders and no answer is provided in the migration form questionnaire.

Use this tab if you wish to map values from the <ORD><FLD><MATCDE> field to the Alma Reporting Code field. This tab is not required.

When an encumbrance transaction is created in Alma, the acquisitions staff can classify the transaction with a reporting code. Later, reports can be used to retrieve transactions with the same reporting code. Reporting codes are often (but not always) used to classify a purchase as serial, monograph, or electronic, for state or nation-wide reporting purposes.

Spydus Material Code: The value of the Spydus order format, found in the <<ORD><FLD><MATCDE> field in the order extract.

Form Description: A description of the Material Code field, for information only. This field is not used in the mapping.

Alma Reporting Code: The desired code value for the reporting code in Alma. You may choose to collapse Material Code values if desired.

Alma Reporting Code Description: The name for the reporting codes in Alma. This field is used to create a code table that is loaded into Alma. This value can be easily changed after migration.

The entry point value is used to determine where PO falls in the workflow in Alma. The PO entry point is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any <PST><FLD><STATUS> values that may not have been found in the map. Additionally, since all possible values for the <PST><FLD><STATUS> field in Spydus cannot be accommodated, every original <PST><FLD><STATUS> value is placed in the note field for each individual migrated order for reference after migration.

Spydus status code: The possible values for the order status in Spydus, found in the <PST><FLD><STATUS> field in your order extract.

Description: The description of the <PST><FLD><STATUS> field, for information only. This field is not used in the mapping to Alma.

poEntryPoint: The desired order status in Alma. Select from one of the values in the dropdown box. The following options are available:

• NEW – The order has been created but not sent to the vendor yet. Orders can have status NEW for years while librarians are reviewing what to order, or they can be NEW for just a short while if the acquisitions staff created the order to send to the vendor immediately.
• SENT – The order has been sent to the vendor and funds have been encumbered/committed. The item has not been received yet for one-item orders, or the item has been received for continuous orders. Continuous orders that continue to be invoiced/received remain with SENT status (which can be considered as a sub-status of waiting for renewal within Alma) until they are closed.
• WAITING_FOR_INVOICE – Use only for one-time orders. The item has been received, but not the invoice. Invoice status must not be FULLY_INVOICED.
• CLOSED – The order has been received and invoiced. Nothing else will be received on this order. (Do not use for open continuous orders that you are still receiving.)
• CANCELLED – Cancelled order.

Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times, and may remain open indefinitely.

This tab is mandatory if you are migrating orders. Include a line for ALMAME_VAL_NOT_FOUND since this field is mandatory in Alma.

Spydus Order Category: Value of the order type field in Spydus, found in the <ORD><FLD><ORCAT> field in your order extract.

Order Category Description: A description of the <ORD><FLD><ORCAT> field, for information only. This field is not used in the mapping to Alma.

poLineType: The Alma line type value. Select one of the following line types from the drop-down list:

• PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level. If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
• PRINTED_BOOK_OT: Print Book One Time
• PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
• PRINTED_JOURNAL_CO: Print Journal - Subscription
• PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published, or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record. If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
• PRINTED_BOOK_SO: Print Book - Standing Order
• PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
• OTHER_SERVICES_OT: Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
• OTHER_SERVICES_CO: Other Services Subscription – This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.

Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.

Alma does have other PO Line types, but they are not available for use in migration.

Use this tab to determine the Acquisition Method of an order in Alma. The acquisition method is an indication of how the order is acquired. Possible values for the acquisition method are PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL, and LEGAL_DEPOSIT.

The PO Acq Method is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any values that may not have been found in the map. Also, since all possible values for the <ORD><FLD><TYPE> field in Spydus cannot be accommodated, every <ORD><FLD><TYPE> value is placed in the note field for each individual migrated order.

Spydus Acq Type: The value of the <ORD><FLD><TYPE> field in Spydus, found in your order extract.

Spydus Acq Type Description: A description of the Acq Type in Spydus, for information purposes only. This field is not used in the mapping to Alma.

poLineAcqMethod: The Acquisition method in Alma. Select one of the following values from the drop-down list:

• PURCHASE – normal workflow
• GIFT – not sent to vendor and no invoicing or payment
• EXCHANGE – not sent to vendor and no invoicing or payment
• APPROVAL – pre-established delivery plan - normal workflow except not sent to vendor
• VENDOR_SYSTEM – the order is placed at the vendor site so that sending it to the vendor is not required. The normal workflow is followed except that the order is not sent to the vendor.
• DEPOSITORY – usually from the government. The order is not sent to vendor and there is no invoicing or payment.
• TECHNICAL – no fund or amount required
• LEGAL_DEPOSIT – does not require fund or price, and uses a special version of the PO Line order letter

Transactions from active purchase orders are created as encumbrances in Alma. An active purchase order is defined as one in which the mapped PO entry point is NEW, SENT, or WAITING_FOR_INVOICE and is in the current fiscal year.

Spydus allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, encumbrances or open orders of amount 0.00 are changed to 1.00.  The following types of orders (Acq method) can be open with amount 0 on the order, but with with no transaction/link to fund: GIFT, DEPOSITORY, EXCHANGE, TECHNICAL, and orders with the 'no charge' flag set to Y.

In The Alma Purchase Order has a field to indicate the invoice status of the order. The invoice status can be NO_INVOICE, PARTIALLY_INVOICED, or FULLY_INVOICED. Continuous orders must not be FULLY_INVOICED.

If the Invoice input file doesn’t contain an invoice record for the purchase order, then the invoice status of that order is NO_INVOICE.

If the Invoice input file contains an invoice record and po_line_type = PRINTED_BOOK_OT, then the invoice status is FULLY_INVOICED.

If the invoice input file contains an invoice record and po_line_type = PRINTED_BOOK_SO or po_line_type = PRINTED_BOOK_CO, the invoice status is PARTIALLY_INVOICED.

The migration programs fill out the following elements based on incoming data: 

• PO Line type
• PO Entry Point
• PO Invoice Status
• Send date
• Expected receiving interval/date 

Alma can have a further status of 'In Review'.   Migration does not set the 'In Review' status, but rather the 'In Review' status is set by a series of rules using the elements above and possibly other elements.   The initial set of rules used to determine these further statuses is not controlled by the customer; it is controlled by Alma Development. Customers are often frustrated by the statuses set for NEW orders: 

• when NEW and OT (one time), the status is set to 'In Review'
• when NEW and CO or SO (continuous), the status is set to 'Waiting for Renewal'

You can find out more about the PO Review Rules, and how to turn rules on or off, by consulting the page Configuring Purchasing Review Rules.  

For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:

• Specific indicators: 85641u – only tags with 41 as the indicator is used.
• No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4<blank> as an indicator are used.
• All possible indicators: 8564*u – tags with 4 as the first indicator are used. The second indicator is not taken into account.

The space character operates the same way as an asterisk (*), for example: 8564 u is the same as 8564*u.

Special Request: If you need to specify multiple specific indicators, for example, 85641 and 85642, it cannot be coded in the migration form but your ExL representative can make a special request to the migration team.

Code: P2E_LINK

Options: Provide a three digit Marc field code + subfield: 856u. Only one field/subfield is allowed.

Recommendation: 856 u

Default: If this is left empty, no tag is used.

Code: P2E_PROVIDER

Options: Provide a three digit Marc field code + subfield: 856m. Only one field/subfield is allowed.

Recommendation: 856 m

Default: If this is left empty, no tag is used.