- A step-by-step guide to filling out the AbsysNET to Alma Migration Form.
- An explanation of the the fields in the AbsysNET Field Mapping Form, plus migration rules for AbsysNET to Alma that do not require any customer input,
- Indicate which local fields correspond to Ex Libris' expected fields using the AbsysNET Field Mapping Form prior to data delivery (customer responsibility).
- Validate the flat files using Ex Libris’ Validation Tool Excel. It is recommended that this step be done against a small subset of data to ensure that the header of each of your flat files and the filled in field mapping form match each other. Note that the validation only works for CSV files. If you do not modify the AbsysNET flat files after exporting them from AbsysNET, there is no need to validate them before sending them to Ex Libris.
- Extract the relevant data elements from AbsysNET into standard files (customer responsibility). This is done using standard AbsysNET extract tools.
- Upload the files to Ex Libris’ secure file server along with the AbsysNET Delivered Files form and the executed/validated Non-ExLibris to Alma Validation Tool (customer responsibility).
- Transform the data elements, based on the Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
- Load the transformed data into Alma (Ex Libris responsibility).
Recommendations for Using this Guide
- Physical to Electronic
- Field Explanations - File delivery requirements and explanations of individual fields where relevant, to be used when filling out the Field Mapping Form.
- Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
- Individual Tabs – Instructions for how to fill in individual tabs on the Migration Form.
- Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
- This document is intended to complement the AbsysNET Migration Form and the AbsysNET Field Mapping Form. Both are used in the migration process by the migration programs.
- Prerequisites: Basic knowledge of Alma and AbsysNET key concepts and architecture, and the requirements (including the migration-related approach) described in Getting Ready for Alma and Discovery Implementation, as well as in Electronic Resource Handling in Alma Migration.
- It is recommended that you view the Introduction to the Alma Configuration Process video session before completing your migration form, as the mapping and migration of libraries and locations have implications for subsequent configurations.
AbsysNET Field Mapping Form
AbsysNET Delivered Files Form
AbsysNET Migration Form
Expected File Formats
Suppressed Bibliographic Records
- From Bib – Summary statement embedded in a bib tag.
- None – no holdings records are delivered. In this case, holdings records are generated from item information.
Non-MARC Serial Holdings
If non-MARC serial holdings are provided, they should be sent as a CSV file. The file can be mapped to the generic serial holdings format included in the Holdings tab of the AbsysNET Field Mapping form.
The following format is used for an AbsysNET holding record in CSV format. Records should be provide one record per line, with quotes and commas. Provide a header at the top. If something is allowed to be repeatable, provide the repeated information with a semicolon.
|Expected Field Name||Repeat-able?||Notes|
|TITULO||N||Mandatory. Links to the related bib record|
|BIBLIOTECA||N||First level of location|
|LOCALIZATION||N||Second level of location|
|SUMMARY_STATEMENT||will be placed in 866 $a|
If you have fields which are not in the above table but wish to keep them in a note, place those fields in the note section
|NON_PUBLIC_NOTE||placed in 852 $x|
|PUBLIC_NOTE||placed in 852 $z|
Holdings From a Bib Tag
|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|
|Expected Field Name||Description||Note|
|COFSAD||createDate||This is not migrated. Place in a note if you want to retain the original create date.|
|CONTIT||No de titre||links to bib record|
|COCOCL||Localisation||use in Alma Location map in migration form|
|COFREC||Date de réception|
|COCOCP||Type exemplaire||use in Item Type map in migration form|
|COCOSU||Succursale||use in Alma Location map in migration form|
|COSIGN||Cote||data will be placed in 852 $h|
|COSIGS-Call_Number_2||Cote supplémentaire||place field COSIGS here to have the data be placed in 852 $i (second part of regular call number)|
place field COSIGS here to have the data be placed in Item Call Number.
If customer uses this option, they MUST use 'bch' in the 852_subfield_for_hol question; if they use 'bc', then differing call number information may be lost - we can't put both into the same field Item_call_number.
|COSTAT||Situation exemplaire||use in item status map in migration form|
|CONREG||No de registre||is placed in INVENTORY_NO in Alma|
|COFINV||Date de Récolement||is placed in INVENTORY_DATE in Alma|
|CONPRE||Nbr de prêts||
To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
Alma increments the loan count for items currently on loan, so it is recommended that you send (loans - 1) for currently loaned items.
|COFULT||Date de retour|
|COCOCS||Support||use in Material Type map in migration form|
|COIDVO||Identifiant de volume||is placed in item DESCRIPTION field|
|REPLACEMENT_COST||COVALU||Use only if this is an actual replacement cost. If not, put only in the Inventory price field above.|
|P2E_LINK||P2E_LINK||URL access to this material. This value is transferred to the holding record 856 subfield u, and then is used during the p2e process.|
|P2E_NOTE||P2E_NOTE||This value is transferred to the holding record 856 subfield z, and then is used during the p2e process.|
|TEMP_ITEM_TYPE||Temporary item type|
|TEMP_CALL_NUMBER||temporary call number|
|TEMP_CALL_NO_TYPE||temporary call number type|
If duplicate item barcodes are found, the item barcode is migrated according to the following rules:
- If the barcode is empty, leave as empty in Alma.
- 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>
|Note Name||Default Local Subfield||Note Label|
Item Statistics Notes (STAT_NOTE_*) can use controlled vocabulary when statistics_note_controlled is set to true. For more information, see Configuring Item Statistics Notes.
Secondary Item File
|Expected Field Name||Notes|
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.
|description||Provide in a format such as: Vol. 12, No. 6 (February 2015)|
|enumA||For example, “12”.|
|enumB||For example, "6".|
|chronI||For example, "2015"|
|chronJ||For example, "2".|
Electronic Identification (P2E)
Institution Code, Customer Code, Institution Name, Customer Name, Time Zone
MARC/Country Organizational Code
(MOC)<AbsysNET record id>-<customer code>
List Prefix for bibs from SFX or other management system
Do you use internal system numbers in Linked Entry fields?
Indicate if you use internal system numbers in linking fields. Internal system numbers from your legacy system are not continued in Alma, and therefore should be changed to MMSID (the Alma internal system number).
MARC fields: $w subfield for tags 76x-78x, 80x, 81x, and/or 83x
Unimarc fields: $1 subfield with prefix 001 for fields 423, 461, 462, 463, 464 [example: bib key 99999 in tag 461 = 461 $100199999]
Options: If you answered Yes to this question, the internal system numbers in the subfield w of the specified tags are converted from the former system number to the Alma system number.
Internal record designation for Linked Entry fields $w
Options: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to be matched to identify the local system number. If the system numbers in $w do not have a prefix, or if you answered No to the previous question, leave this question blank.
Further information on LINKED_ENTRY_W and LINKED_ENTRY_PREFIX: When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, your previous ILS may store the information in bibliographic fields 76x-78x, 80x, 81x, and 83x $w for MARC, and 423, 461, 462, 463, 464 for Unicode. If the number in the $w or $1001 of the linking tags is the internal legacy ILS system number, these numbers must be changed to the Alma representation of the system number. If your library does not use the internal system number to link and instead relies on more general identifiers such as the ISBN, ISSN, or shared cataloging DB (OCLC or DLC), these numbers are not modified.
In Alma, the system numbers in the linking field are used to link two related bibliographic records together using the related records process. Related records can be found by clicking the More Info link on the Alma Search Results page. For more information on configuring related records, see Configuring Related Records for Physical Inventory.
Indicate which 852 subfields to use to determine unique holding records
Limit exported records by location
Bib Key Prefix
Move 001/003 to 035 or 035
Options: If your incoming bibliographic records have a number in the 001, then the migration programs move it elsewhere as (<003>)<001>. For example: (OCoLC)12345. To move to the 035, which is the default, then select 035 in the dropdown. If you are part of a consortium and are using OCLC numbers to determine matching records when linking to the NZ, you may wish to move this number to the 935 so that the moved number does not interfere with another matching key you may be using. If you are not linking to the NZ, then this question is likely not useful. Default: 035
Ex Libris marks the moved 035 or 935 with $9 ExL to indicate that the migration programs created this field.
Further information: If an 035 exists in the record already with the identifier that was in the 001, then a second (duplicate) tag is NOT made. Also, when checking if the identifier already exists, the migration programs compare to the $a only. Meaning, if an existing tag contains
035 $a(OCoLC)12345 $z (OCoLC)54321
then the existing 035 $a is considered a duplicate and a second tag is not created.
Add institution suffix to Bib ID
Options: When moving the legacy bibliographic identifier to the 035 or 935, you can choose to add the institution code to the end of the string, like 12345-34ABC where 12345 is the legacy bib ID and 34ABC is the institution code. This may be used in conjunction with other bib identifier options, such as BIB_KEY_PREFIX and MARC_OC.
Yes = include suffix
No = do not include suffix
Use subfield indicators in item call number (AltCallNo)
Options: When generating an Item Call Number field (also known as AltCallNo), you can decide if the string contains subfield indicators. Default = Yes
Yes = $h PZ3.A93 Pr16 $i A975
No = PZ3.A93 Pr16 A975
For more information on when an Item Call Number is generated, see the section Changing the Holding Record Grouping, which depends on the question 852_SUBFIELDS_FOR_HOL.
Add $9 LOCAL to specified tags
Options: Add $9 LOCAL to specified bib tags, for use in consortia where an IZ environment links to an NZ. Tags marked as Local will be kept in the IZ, and not moved to the NZ.
Format for this input: tag + indicator. Use # for any/wildcard, and b for the space character. Separate with semicolon.
Example: 59###; 69###;960##;970##;090b#
Alma Library Tab
Alma Location Tab
|AbsysNET Library Code||AbsysNET Home Location||Alma Library Code||Alma Location Code||Alma Location Desc||Alma External Loc Desc||Suppress from Externalization|
|ALMA_ME_ VALUE_NOT _FOUND||ALMAME_VALUE_NOT_FOUND||MAIN||UNASSIGNED||Problem location from Migration||Problem: See Library Staff||Yes|
Alma Location Name and Alma External Location Name
|Library||Alma Location Code||Alma Location Name||Alma External Location Name|
|Library A||stacks||Main Stacks||Main Stacks|
|Library B||stacks||Main Stacks||Main Stacks|
|Library A||archa||Archives A||Archives|
|Library B||archa||Archives B||Archives|
|Library A||archstk||Archives Stacks||Archives|
|Library A||archref||Archives Reference||Archives|
|Library||Alma Location Code||Alma Location Name||Alma External Location Name|
- The Alma library is placed in the 852‡b field.
- The Alma location is placed in the 852‡c field.
|AbsysNET Location Code||Alma Library||Alma Location Code||Alma Location Name||Alma External Loc Name||Suppress from Externalization||Electronic Location|
Item Base Status Tab
Item Type Tab
Item Material Tab
Further Explanation – Inventory
Determining Groups of Holding Records
- Item 1, 2 in Location A
- Item 3, 4 in Location B
- Item 5 in Location C
Changing the Holding Record Grouping
Attaching Items to Existing Holding Records
|LENLEC||No lecteur||use to link patron to loans, fines, requests|
|LEFSAD||createDate||This is not migrated. Place in a note if you want to retain the original create date.|
|LEFCAD||Date de fin de droit|
|LEFNAC||Date de naissance|
|LEFSUS||Date de suspension||if present, a block will be created with type 'CONV'|
|GENDER||must contain 'Male' or 'Female' or leave blank|
|LANG||language||must contain two-letter ISO code https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes|
Use these fields only if providing a single block per patron.
If multiple blocks are provided for a single patron, provide the blocks in a separate file. See User Block section below.
|Alma Address Field||AbsysNET Field Name|
|ADDRESS_COUNTRY||If country is provided, it must be a three-letter ISO country code, which can be found here https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3|
|Address Type (Select):||ALL|
|SEC_ADDRESS_COUNTRY||If country is provided, it must be a three-letter ISO country code, which can be found here https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3|
|Secondary Address Type (Select):||ALL|
|PHONE||The preferred phone should go in PHONE_PREFERRED, other phones in PHONE_x|
|The preferred email should go in EMAIL_PREFERRED, other emails in EMAIL_x|
|Alma Identifier Type||AbsysNET Field Name||AbsysNET Field Name for Note|
User Statistical Categories
|User Statistical Category||Local Field Name||Field Label|
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.
|OTHER_NOTE||The 'OTHER_NOTE' is marked by the migration programs as viewable by the user. 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.|
User Blocks (if multiple blocks per patron)
If a single block is provided per patron, the blocks can be provided within the patron record. Otherwise, if there can be multiple blocks for a single patron, provide the blocks in this separate file.
|PATRON_ID||There may be multiple lines in the file for a single patron ID - meaning that the patron has multiple blocks.|
|BLOCK_TYPE||Use the User Block tab in the migration form.|
|BLOCK_CREATE||If this is not present, migration will use use patron create date, then patron migration date.|
|PRBARC||Code-barres||links to item ID in item file|
|PRPRSU||Succursale du prêt|
|PRNLEC||Lecteur||links to ORIGINAL_ID in patron file|
|PRFPRE||Date de prêt|
|PRFDEV||Date de retour|
|PRRECL||Nbr de réclamations||checks if the loan was recalled; to keep actual number of recalls, also put this field in notes|
|PRNREN||Nbr de renouvellements||checks if the loan was renewed; to keep actual number of renewals, also put this field in notes|
|PRRERE||Date de réclamation de réservation|
|Note Name||Default Local Fields|
Active Requests on the Hold Shelf
|RENLEC||links to User ID in patron file|
|Note Name||Local Fields|
Default Patron Language
Which identifier should be as the patron's Primary Identifier?
How should we handle duplicate identifiers in the same patron?
Options: Alma does not allow duplicate identifiers anywhere, even in the same patron. If the patron has the same number in two or more different identifier types, we can either not migrate the second one, or disambiguate it with -1, -2 etc.
DISCARD: do not migrate the second and subsequent identifiers
ADD_SUFFIX: add -1, -2, etc
Currency for patron fines
Use a map for the patron campus to campus code migration?
Merge Patron Prefix
User Group Tab
- Which identifier should be used b as the patron's Primary Identifier?
User Stat Categories Tab
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.
The migration engine adds a space between the label and the value.
Campus Code Tab
Further Explanation – Fulfillment
- Provide a field called INTERNAL_EXTERNAL in the AbsysNET patron extract, containing either “INTERNAL” or “EXTERNAL”.
- Identify patrons as internal or external by user group on the AbsysNET Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.
|UNIV ID||LEDDNI||UNIV ID|
|P BARCODE||LENLEC||P BARCODE|
|ADDL ID 1||LEDDNN||ADDL ID 1|
|ADDL ID 2||ADDL_ID_2|
|ADDL ID 3||ADDL_ID_3|
|ADDL ID 4||ADDL_ID_5|
Provide the vendor file in comma delimited format, as a standard Millennium extract. The following fields are expected.
Vendor accounts are mandatory in Alma, so the migration programs generate a single vendor account for each vendor migrated from AbsysNET.
|SECUENCIAL Absys||Vendor code|
|Nobmbre tercero||Vendor name|
|Correo electronico||Vendor email|
|NIT||National Tax ID|
|ID Acreedor SAP||Additional code for Vendor|
|VENDOR_NOTE||Multiple fields may be mapped here. There there is only one type of vendor note.|
AbsysNET provides an order header and multple lines per header.
|AANADQ||Purchase order number|
|AANPRV||vendor code; links to vendor record. Required|
|AACOMO||currency, in 3-letter ISO, like USD, EUR, AUD|
|AASTAT||entry point; use in PO Entry Point map|
|AAFPRE||Expected activation date|
|AACOPR||Acq Method; use in PO Acq Method and PO Line Type maps|
|PO_NOTES||multiple fields may be mapped to PO Notes.|
|ADNSEQ||PO Line Number (POL Reference)|
|ADNADQ||links to header file|
|ADNTIT||Bib ID; required. In Alma, a purchse order must be linked to inventory.|
|ADCOCU||Fund code; links to a fund code in the FUND file|
|ADESTI||Amount, in currency specified by AACOMO|
|POL_NOTE||multiple fields may be mapped to POL Notes|
Fund records are collected in an Excel form and then exported to CSV format and submitted to Ex Libris. Funds are not extracted from AbsysNET directly. All funds must be listed in the first tab of a spreadsheet before exporting to CSV. Files in Excel format are not accepted by Ex Libris. Also, since the file must be exported to CSV before submitting, there is no possibility of having multiple Excel tabs in the submitted file. Each csv file must contain a header line with the field names as described below.
In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory and if your institution does not have ledgers in the legacy ILS, define one general ledger for use in Alma.
Note that fund codes, summary codes, and ledger codes are unique across the entire fiscal period, not just within specific hierarchies – so in the file submitted, there should be no fund or ledger code duplication since all of the funds and ledgers go into a single active fiscal period. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes. See the section 'Uniqueness examples' below for further explanation on this point.
Funds are grouped under summary funds, and summary funds or allocated funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, you can create a new summary fund in Alma after migration and drag other summary funds underneath it in the hierarchical fund structure.
You can use the LIBRARY field to differentiate the funds of multiple campuses or libraries from one another. The library code must be a valid AbsysNET location code.
The FUND CODE in this file must match a fund code used by AbsysNETs order records to make an encumbrance transaction in Alma that links the order to the fund.
|LEDGER CODE||May be repeated across lines to group funds under a single ledger.|
|LEDGER NAME||May be repeated across lines to group funds under a single ledger.|
|SUMMARY FUND CODE||Not mandatory, may be repeated across lines within the same ledger. See the section 'Uniqueness examples'|
|SUMMARY FUND NAME||Not mandatory, may be repeated across lines within the same ledger. See the section 'Uniqueness examples'|
Alphanumeric, not repeatable (This is the fund code that links to the fund code in the Millennium order record.) THis must be unique, even across ledgers.
If providing invoices and therefore funds across multiple fiscal years, all funds must still be unique. In that case, codes should be like this:
Current year fund code unsuffixed, like BOOKS
Previous year fund codes have a suffix of the year, like BOOKS-2020, BOOKS-2019. You may only submit previous year funds if you are also submitting invoices. Submit only single-year funds if you are submitting orders but not invoices.
|FUND NAME||Alphanumeric, repeatable.|
|LIBRARY||The values here must be in the AbsysNET library list. Matching is case sensitive. There can be multiple libraries n this field, separated by a semicolon. This field can be left empty, which means that all locations in the institution can use the fund.
If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
|EXT ID||External ID for linking to an external source, if one exists.|
|ALLOCATION||Allocation, in local currency, of the current fiscal year’s funds. Enter only the numbers with decimal places, not the currency symbol. For example: 10000.00.|
|FY||Fiscal Year YYYY. Typically this is the active fiscal year. AbsysNET customers may only provide funds for one fiscal year (the active fiscal year). Multiple fiscal years are only allowed if customers are providing invoices.|
|NOTE||optional note for the fund|
When creating funds, the fund codes must be unique. The only exception to this is the summary fund code, which may be repeated but only within the same ledger to indicate a hierarchy. See the table below for more examples of uniqueness in fund codes.
|Ledger code||Summary fund code||Allocated Fund Code||Fiscal Year||Comment|
|L1||ARTS||MUSIC||2021||"ARTS" may be repeated here because this indicates a single summary fund ARTS in the ledger L1, which contains two allocated funds below it (MUSIC and DRAMA).|
|L2||ARTS||PERFORM||2021||"ARTS" may not be repeated here in the L2 ledger because it is already being used in the L1 ledger.|
|L2||SCITECH||BIOLOGY||2021||"BIOLOGY" may not be repeated here since it is already in use in the L1 ledger|
|L2||SCITECH||BIOLOGY_L2||2021||Either come up with a completely different fund code or put a ledger suffix on the fund code.|
|L1||ARTS||MUSIC||2020||both "ARTS" and "MUSIC" may not be used here since they are being used in Ledger L1 in FY 2021. Codes may not be repeated even in different fiscal years.|
|L1||ARTS_2020||DRAMA_2020||2020||This is a correct use of fund codes for funds in different fiscal years. Funds in different fiscal years is only available for customers who provide invoices.|
|L1||BOOKS||L2||2021||"L2" as an Allocated Fund Code is not allowed here because it is already being used as a ledger code.|
|L1||BOOKS||ARTS||2021||"ARTS" as an Allocated Fund Code is not allowed here because it is already being used as a Summary Fund Code.|
Default currency for Ledgers/Funds
Default language of conversation with vendors
Fiscal Period Cycle Pattern
Which year do you use to name the fiscal year?
- second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
- first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.
Current Fiscal Year
- Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
- 2013-2014 – Select this option if the date of conversion is later than the fiscal period to which you want your orders to migrate. For example, if the migration date is July 3, 2014, and the previous fiscal period ended on June 30, 2014, select this to put all of your orders in the fiscal period that ended on June 30, 2014. Select this option if you want to run fiscal period close in Alma instead of in your old system.
- 2014-2015 – If the date of conversion is earlier than the start date of the desired fiscal period, select this option. For example, if the migration date is June 15, 2014, and the next fiscal period begins on July 1, 2014, select this option to put all of your orders in the next fiscal period. Select this option if you want to perform the fiscal period rollover in your legacy ILS prior to conversion.
- No, do not make an additional fiscal year.
- Yes-No Funds ¬ make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
- Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.
Central Order Library or Default Order Library
Default Order Library
Default: First library found on the Alma Library list
Options for Central and Default Order Library: The Order Location field specifies the order location for orders in the previous system. The migration attempts to map the location field to the corresponding Alma Library. If you want to override this field and instead assign an order library to all orders migrated, fill in a value for the Central Order Library question. Otherwise, if you want to use the order location field to determine the order library, leave the Central Order Library question blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the order location field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.
Default claiming period
Options: Default claim used for vendors and orders (if applicable), in days.
Options: If you are combining data from two or more separate databases into a single combined institution in Alma, indicate a prefix here that will be used to distinguish the former fund codes in Alma after migration. Provide a string to be used to prefix all fund codes in the database. A hyphen is NOT provided. For example, if your fund code is SCIENCE-MONO and you put UWS- here, the final fund code is UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.
See also BIB_KEY_PREFIX and MERGE_PATRON_PREFIX
PO Entry Point Tab
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 AASTAT (status) values that may not have been found in the map.
Additionally, since all possible values for the AASTAT field in Millennium cannot be accommodated in the Alma values, every original AASTAT value is placed in the note field for each individual migrated order for reference after migration.
AASTAT: The possible values for the order status in Millennium, found in the AASTAT field in your order extract (header).
Description: The description of the AASTATfield, 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 drop-down 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. A SENT continuous order is set to waiting for renewal if the subscription to date is earlier than the renewal date.
- 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.
PO Line Type Tab
This tab is mandatory if you are migrating orders. Include a line for ALMAME_VAL_NOT_FOUND since this field is mandatory in Alma.
AACOPR: Value of the order type field in AbsysNET, found int he AACOPR field in your order extract (header).
Description: A description of the AACOPR 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.
Since monographic one time orders (PRINTED_BOOK_OT) in Alma are connected to a specific item and in AbsysNET orders are not necessarily connected to specific items, it is required that sent monographic one time orders be manually connected to their orders in order to receive them in Alma.
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 ('SENT') indefinitely.
Alma does have other PO Line types, but they are not available for use in migration.
Line Types and Electronic Orders
The above line types are all descriptions based on a print order. All orders are stored in Symphony as print and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process. See the section on Physical to Electronic Processing below for more information on the overall P2E process.
PO Acq Method Tab
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.
AACOPR: The value of the AACOPR field in AbsysNET, found in your order extract (header).
Description: A description of the Order Type in AbsysNET for information purposes only. This field is not used in the mapping to Alma.
poLineAcqMethod: The Acquisition method in Alma. AcqMethod is mandatory in Alma. If not found, then use PURCHASE. 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
Comment: Add any comments while filling out this form. This field is not used by the migration programs.
Further Information: 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.
Physical to Electronic (P2E) Processing
If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator that does not match the specific indicator in the question P2E_LINK, below. For example, if you say that we use 85641u for the P2E_LINK, and you provide a bib record *without* a 85641u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource). Be careful which bibs are placed in the bib file.
Further, the P2E process attempts to identify an order related to the identified inventory for conversion to electronic. Similarly to items and holdings, orders are initially migrated as print and are transformed to electronic through the p2e process. See the guide https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides/Electronic_System_Migrations/Electronic_Resource_Handling_in_Alma_Migration for more information.
- Specific indicators: 85641u
- No indicator – meaning, the # is used for a blank character: 8564#u
- All possible indicators: 8564*u
- Multiple specific indicators: 85641, 85642 (separate with a comma)
Which Holding or Bib field stores electronic link information
Which Holding or Bib field stores electronic link public note
Which Holding or Bib field stores electronic provider name information
Alma Location Tab
Electronic Location Column
Further Explanation – P2E
AbsysNET stores item barcodes and patron barcodes in the database in a shorter format than is on the item. AbsysNET uses internal routines to match the full barcode (on the item) with the shortened barcode in the database.
Alma stores the entire barcode in Alma as is. Therefore, when migrating to Alma, we need to modify the exported (shortened) barcode to be the full barcode which matches the item.
There are a number of different routines that can be used to modify barcodes. Customers specify these routines using the 'Barcode Modification' tab of the AbsysNET Field Mapping form.
|INPUT Columns: we will use these columns to identify which barcodes will be changed||OUTPUT columns: after identifying barcodes, this is how they are modified|
|patron or item||operator||length||prefix||range begin||range end||output string||padding when =<||Checkdigit routine (X)|
These columns are used to determine which barcodes will be modified.
Patron or Item: Indicate if the barcode is a patron barcode or an item barcode.
Operator: there are three choices
- length = : Length of the barcode is exactly equal to the number in the 'length' column
- length =< : Length of the barcode is less than or equal to the number in the 'length' column
- range : The length of the field is equal to the number in the 'length' column, and also the number is between the two values 'range begin' and 'range end'.
Length: used with 'Operator' column.
Prefix: the barcode begins with the specified number(s).
Range: used with the Operator column, when option 'range' is selected.
After we have identified the barcodes which should be modified, this is how they are modified.
Output string: N represents the original number, and there should be as many Ns as the length. Example, length = 6, then NNNNNN is in the output string. The other numbers around the NNNNNN represent what should be added to the string. An X indicates the checkdigit to be added, routine specified in column 'Checkdigit routine'.
Example, for an original barcode whose length is 6.
means, add 114 to the beginning of the number, and then add a checkdigit at the end.
If the incoming number is 123456, then the final number is 1141234569, where the 9 is a calculated checkdigit.
Padding when =<: If the original operator is =<, then we can add padding to the original number.
Example, for an original barcode whose length is 4, but the operand said =< 6.
87NNNNNN, padding 0
If the incoming number is 1234, then the final number is 87001234. THe two zeroes are added to move the number from 4 digits to 6 digits in length.
Checkdigit routine: Specify the checkdigit routine to use. The two options are Luhn or Mod10. If you use a different checkdigit routine, inform your Ex Libris representative.