Libero to Alma Data Delivery and Migration Guide
- A step-by-step guide to filling out the Libero Migration Form.
- An explanation of the expected files from Libero and associated migration rules.
- Indicate which local fields correspond to Ex Libris' expected fields using the Libero 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.
- Extract the relevant data elements from Libero into flat files (customer responsibility).
- Upload the files to Ex Libris’ FTP server along with the Libero Delivered Files form and the executed/validated Non-ExLibris to Alma Validation Tool (customer responsibility).
- Transform the data elements, based on the Libero 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
- Files Expected - a description of the data files expected from Libero, along with descriptions of fields.
- Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
- Individual Tabs – Instructions for how to fill out the individual tabs on the migration form. (Examples: Alma Library Tab, User Group Tab, PO Line Type Tab).
- Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
- This document is intended to complement two forms:
- Libero Migration Form – an Excel spreadsheet that is read by the migration programs. It provides further information regarding the migration process and the steps required for migration to Alma.
- Libero Field Mapping Form - an Excel spreadsheet used to map incoming fields to the Ex Libris expected fields.
- Prerequisites: Basic knowledge of Alma and Libero key concepts and architecture and the requirements listed in Getting Ready for Alma and Discovery Implementation.
- 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.
Requested Files from Libero
- Bibliographic records – Bibliographic records are expected in MARC21 format. Ex Libris expects these records to be exported from the bibliographic utility BSZ.
- BSZ-to-Libero mapping file – A translation file mapping the BSZ identification number to the Libero identification number. This file also includes an indication if the bibliographic record is suppressed from public view.
- Holdings records – Alma requires MARC Holdings records. We expect to receive a MARC Holding file from BSZ that contains holdings records for some, but not all bibliographic records. Ex Libris will retain only those holdings records with serial summary information (866 tags). Additionally, the holding records from BSZ do not link to Libero item records.
- Physical Inventory (item) records – Ex Libris expects two item files: a main item file and a secondary call number file. Additionally, if purchase orders are NOT being migrated, the item order information can be included in the item record as a note.
- Serials information – Ex Libris expects seven different files related to serials. All of the data elements in the serials files will be placed in a note in the first MARC holding record found on the related bibliographic record.
- Electronic Resources (P2E file) – Most non-Alma ILS systems store records for both physical and electronic items in the same format, which is a physical format. Alma has different record formats for electronic and physical items. Provide a list of bibliographic records that represent electronic materials so they can be converted to electronic format after migration to Alma. The possible types of electronic resources are packages, databases, and portfolios. The identification number in this file is expected as a BSZ identifier.
The Libero item records are not linked to any existing MARC holding record, so the migration programs will generate a MARC holding record based on information in the item. No attempt will be made to link items to existing holding records, because items have location information and the BSZ holding records do not.
Link between BSZ and Libero + Suppressed Records
- The bibliographic record identifier from BSZ
- The related identifier from Libero (used to link to items, loans, orders, etc.)
- An indication if the bibliographic record should be suppressed
- From the MARC holding file extracted from BSZ. Items do not attach to these records, because the holding records do not have local holding codes
- From a bibliographic tag, such as an 866, with summary holdings statements (optional)
- From information in the item records, if the item is not already attached to a record from a bibliographic tag
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|
Aleph Sequential Holdings
Aleph sequential holding records are essentially MARC records but in a special format used by Aleph, an Integrated Library system produced by Ex Libris. The format is textual and is relatively easy to program, so customers may want to provide in this format. Also, if the library is part of a consortium where the holdings are in a shared repository, the repository may already export in this format. Customers may provide holdings in Aleph Sequential format for Libero.
In order to provide Aleph sequential holding records, the following must be true
- There must be a unique holding record key in the 001
- There must be a link to the Libero bib record in the 004
- The 852 must contain Libero-type library ($b) and location ($c) codes. These will be sent through the Alma Location mapping tab in the Libero Migration Form, so the values in the file belong in columns A and B of the mapping tab.
Items from Libero can link to Aleph sequential holdings as long as the items are linked to the same bib, and the items are in the same location as the holding. Items will attach to holding records using the algorithm described in the question 852_SUBFIELDS_FOR_HOL on the Questionnaire tab of the Migration form.
Note also that the match for the library/location codes is done AFTER the mapping. Therefore, the holding record and the item record could have two different Libero library/location codes, but if they map to the same thing in Alma, they will still attach.
- The main item file, delivered in CSV format. This file will include a Libero bibliographic ID, and Ex Libris will use the Libero ID to BSZ ID file to attach the item to the correct BSZ bib record.
- A secondary file containing multiple call numbers for each item, also delivered in CSV format.
|Expected Field Name||Notes|
|Libero Identnummer Titeldaten = Libero ID (Title)||links to bib-ID|
|Barcode = Item barcode||links to loan, request and fine files|
|Signatur = Main call number||
If a holding record is present, then this is used to match an item to a holding record, if $h is included in 852_subfields_for_hol.
If a holding record is not present, then this is used when generating a holding record. Further, if only bc is used in 852_subfields_for_hol, then this call number could* be placed in the ITEM_CALL_NUMBER field when multiple items are grouped together into a single holding record.
* 'could' because Item Call Number (below) will be placed in ITEM_CALL_NUMBER if present. If Item Call Number is NOT present, then Main call number is placed in the ITEM_CALL_NO according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.
|Exemplar-Richtlinie = Item Policy/Item Type||use item type map on Migration Form (1st column)|
|Exemplar-status = Item Status||use itemBaseStatus map|
|Bibliotek = Library||use Alma Location map on Migration Form|
|Standort = Location||use Alma Location map on Migration Form|
|Item call number||If this is present, then the value will be placed in ITEM_CALL_NUMBER. This value takes precedence over a possible value from the Main Call Number, according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.|
|Gesamtanzahl Ausleihen = Total no. of loans||
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.
|Datum der letzten Rückgabe = Date of the last return||To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.|
|Medientyp = Material type||use item type map on Migration Form (2nd column)|
|Inventory Number||Maps to the Inventory Number in Alma|
Inventory Price/Replacement Cost
|Expected Field Name||Notes|
|Ersatzkosten = Replacement price||Both fields may be filled with the local ‘Ersatzkosten’ field from Libero if desired. The REPLACEMENT_COST will be used to assess fines if the item is lost.|
Secondary Call Number File (mehrfachsignaturen)
|Expected Field Name||Notes|
|Signatur = Call number||The field from the secondary item file containing call numbers. Ja = call number goes to Item AltCallNumber field; Nein = call number goes to note field|
|Hauptsignatur-Kennzeichnung = Main call # indication||1 = Yes, 0 =No|
|Note Name||Local Fields|
Secondary Item File
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.
With the exception of the item_key and barcode, all other fields will force blank if an empty field is provided. In other words, if you have an item description in Alma, and you provide a blank description in this file, the incoming blank will be 'written' to Alma, meaning the Alma description will be deleted.
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.
Even though it is not recommended, if for any reason you need to provide a full date in a single field, put a tick (') before the date in the Excel cell so that it is treated like text (instead of the Excel date format).
Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:
|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. For example:
|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".|
- Serials acronyms & frequency
- Serials notes (financial)
- Serials notes (distribution)
- Serials notes (general notes)
- Serials notes (other notes)
- Serials notes (Receiving note)
- Serials notes (subscriptions)
|Expected Field Name||Notes|
|RSN = Libero Title ID|
|Bibliotek = Library||
Library, location, and summary statement were not found in the Libero serials files, but they are options if the customer can retrieve them.
|Standort = Location|
|Übersicht = Summary statement|
|Note Name||Local Field|
Customer Input - Inventory
Institution Code, Customer Code, Institution Name, Customer Name, Time Zone
List Prefix for bibs from SFX or other management system
MARC Organizational Code
Do you use internal system numbers in $w of Linked Entry fields?
Indicate if you use internal system numbers in fields 76x-78x, 80x, 81x, and/or 83x, subfield $w, to link bibliographic records to each other.
Internal record designation for Linked Entry fields $w
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 935
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 generated 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
|Libero Location code||Libero Locn Desc||Alma Library||Alma Location Code||Alma Location Desc||Alma External Loc Desc||etc|
|ALMA_ME_ VALUE_NOT _FOUND||MAIN||UNASSIGNED||Problem location from Migration||Problem: See Library Staff|
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.
|Libero 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
Material Type Tab
Further Explanation – Inventory
- Australian customers have ALL bibliographic records 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.
MARC Holding Records
- The Alma library is placed in the 852‡b field.
- The Alma location is placed in the 852‡c field.>/li>
Determining Groups for Holding Record Creation/Matching
- Item 1, 2 in Location A
- Item 3, 4 in Location B
- Item 5 in Location C
Changing the Holding Record Grouping/Matching
Call Numbers from Secondary File
Call Number Type
- 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, or fine, 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.
Customers may provide a material type in the item extract from Libero if desired. 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.
Areas/Fields Not In Scope
- Patrons – Ex Libris expects four different patron files from Libero. Ex Libris will combine the files into a single file to generate a patron record in Alma. In order to migrate any area of fulfillment (fines/ fees, loans, requests), all patrons must be migrated.
- Loans – generated from the circulation transaction extract for active loans only, from Libero.
- Fines/Fees – generated from the fine/fee extract from Libero. The migration programs will generate fines in Alma for those fines/fees with an outstanding balance. Closed fines/fee transactions will not be migrated.
- Requests – generated from the request extract from Libero. The migration programs will generate a request record only for those requests that are on the shelf waiting for pickup.
- general user file
- user Address file
- additional info file
- user notes (used only for notes)
|Nachname = Last name|
|Vorname = First name|
|Anrede = Title|
|Geburtsdatum = Birth date|
|Geschlecht = Gender|
|Benutzerkategorie = User category/group (code)||Use the “User Group” map in the migration form|
|Campus Code||use the Campus Code map in the migration form|
|From the user address file|
|Straße = Street|
|Straße Zusatz = Street additional info.|
|Stadt = City|
|Postleitzahl = Postal code|
|Land = Country||The migration programs do not standardize this country name. 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|
|Straße Adresse 2 = Street 2nd address|
|Straße Zusatz = Street 2nd address additional info.|
|Stadt Adresse 2 = City 2nd address|
|Postleitzahl Adresse 2 = Postal code 2nd address|
|Land Adresse 2 = Country 2nd address|
|Straße Adresse 3 = Street 3rd address|
|Straße Zusatz Adresse 3 = Street 3rd address additional info.|
|Stadt Adresse 3 = City 3rd address|
|Postleitzahl Adresse 3 = Postal code 3rd address|
|Land Adresse 3 = Country 3rd address|
|E-Mail = Email address|
|private Telefonnummer = Phone number (Home)|
|Mobilnummer = Phone number (Mobile)|
|geschäftliche Telefonnummer = Phone number (Work)|
|From the User Additional Information file|
|Benutzerstatuscode = user status|
|Benutzerstatuscode Beschreibung = Status code description||Use the User Block map in the Migration Form|
|Anmeldedatum = first seen on|
|Ablaufdatum = expiration date||may be left empty|
|letztes Änderungsdatum = last modified date|
|Note Name||Default Local Field|
|OTHER_NOTE||OTHER_NOTE is set as user viewable by the migration programs. This is the only note which migration marks as user viewable.|
|Alma Identifier Type||Librero Field Name|
User Statistical Categories
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 various ILS systems have different fields for tracking statistical categories, we provide you the option to map the data from any field in your local ILS to the User Statistical Categories in Alma.
|User Statistical Category||Local Field Name||Field Label|
Up to 10 incoming fields can be mapped. To map the values, use the UserStatCategories map in the Libero 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 in the Migration Form would be: LABEL: value, for example: SCHOOL: Law. The validation tool does not provide a colon, so if you want the colon be sure to include it , e.g. 'DEPT:', but the tool does add 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.
|Benutzernummer = User ID||matches user ID in patron file|
|Barcode = Item barcode||matches barcode in item file|
|Ausleihdatum = Loan date|
|Fälligkeitsdatum = Due date|
|Ausleihstatus = Loan status|
|Anzahl Verlängerungen = No. of renewals||Migration uses this to check for renewal status. If you want to keep the number of renewals, also put this in the note field|
|Note Name||Local Field|
|Benutzernummer = User ID||matches User Id in patron file|
|Barcode der Exemplarvormerkung = Item barcode||matches barcode in item file|
|Request status date = Datum Status Im Vormerkregal|
|User name = Nutzername|
|Bereitstellungsdatum = On hold user notification date|
|Bereitstellungszweigstelle = Library that has the item on hold|
|Note Name||Local Field|
|Benutzernummer = User ID||Matches user Id in patron file|
|Transaktionsdatum = Transaction date|
|Gebührentyp-Code = Fine/fee transaction type (code)||Use Fine Fee Type map in Migration Form|
|Gebührenbetrag = Fee amount|
|Barcode = Item barcode||Matches barcode in item file|
|Titel = Title of the bibliographic record|
|Note Name||Local Field|
Which identifier should be used 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
Enter a two-letter code for the default conversational language for your users (for example en or de)
Currency for patron fines
Use a map for the patron campus to campus code migration?
Options: Select Yes for this option only when you maintain and use different values in the your patron records to distinguish between different user groups for resource sharing activities like ILL borrowing. If you select Yes, fill in the mapping from the USER LIBRARY to the Alma CampusCode field on the Campus Code tab. If you select No, all users are simply considered part of the same group for resource sharing activities.
See also: Campus Code Tab
Request default destination library
Merge Patron Prefix
Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the incoming patron record original IDs. This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID. If you are not merging institutions, leave this question blank.
See also: BIB_KEY_PREFIX and FUND_PREFIX
User Group Tab
- Which identifier should be used as the patron's Primary Identifier?
User Block Tab
Fine Fee Type Tab
User Stat Categories Tab
This tab is used to migrate the statistical categories in your patron records (if you have them) to Alma. In many legacy ILS systems, it is possible to have multiple fields that contain statistical codes, usually named USER_CATEGORY1, USER_CATEGORY2, and USER_CATEGORY3.
Before filling in this tab, specify in the Patrons tab of the Libero to Alma Field Mapping form which fields from Libero 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 you specified in the Field Mapping form and the value. So if you included a label 'CAT:' in the field mapping, then use 'CAT: a' here (if 'a' is an incoming value).
Incoming patron category: List all of the values from all of the fields that you want to put into the statistical category mapping. For example, if you listed three different three fields that have a patron category in the field mapping form, then list all of the values from all three of those fields here. Include the label applied if it is important to distinguish between values in different fields.
Source Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.
Alma Stat Category: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.
Alma Stat Category Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be updated after migration.
Further Information: Alma has a Statistical Categories field in the patron record that can be used to retrieve statistics on groups of patrons.
Campus Code Tab
Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the patron campus to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.
Incoming patron campus: The value of the patron campus as found in the patron extract.
Description: A description of the patron campus field, for informational purposes only. This column is not used in the mapping.
Alma Campus Code: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes if desired.
Alma Campus Code Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.
Further Information: The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the such a field for a similar purpose, map the value to the Alma Campus Code value with this map.
Further Explanation – Fulfillment
Patron Identification Numbers
- Vendors – migrated from the vendor extract from Libero.
- Funds – generated for the current fiscal year based on a single list of funds; allocation transactions are generated for the current fiscal year only.
- Purchase Orders – migrated from the purchase order extract from Libero. Encumbrance transactions are generated for the current fiscal year only.
|Lieferantencode = Vendor code|
|Lieferantenname = Vendor name|
|Abteilung = Department|
|Firma (Alternativadresse 1) = Company (alternative address 1)|
|Straße mit Hausnummer = Street name and number|
|Postfach = PO box|
|Postleitzahl = Postal code|
|Stadt = City|
|Staat = Country|
|Telefonnummer geschäftlich = Phone number (Work)|
|Faxnummer = Fax number|
|Anrede Ansprechpartner = Contact person title|
|Ansprechpartner Vorname = Contact person first name|
|Ansprechpartner Nachname = Contact person last name|
|E-Mail = Email address|
|WWW = WWW|
|Steuernummer = Tax number|
|Firma (Alternativadresse) = Company (alternative address)|
|Abteilung (Alternativadresse) = Department (alternative address)|
|Straße mit Hausnummer (Alternativadresse) = Street name and number (alternative address)|
|Postleitzahl (Alternativadresse) = Postal code (alternative address)|
|Stadt (Alternativadresse) = City (alternative address)|
|Staat (Alternativadresse) = Country (alternative address)|
|Ansprechpartner (Alternativadresse) = Contact person (alternative address)|
|E-Mail (Alternativadresse) = Email (alternative address)|
|Telefonnummer 1 (Alternativadresse) = Phone number 1 (alternative address)|
|Telefonnummer 2 (Alternativadresse) = Phone number 2 (alternative address)|
|Faxnummer (Alternativadresse) = Fax number (alternative address)|
|Kundennummer = Account code|
|Lieferantennotizen = Vendor note|
|Lieferantenstatuscode = Vendor status (code)|
|Note Name||Default Local Field|
|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.|
|SUMMARY FUND NAME||Not mandatory, may be repeated across lines.|
|FUND CODE||Alphanumeric, not repeatable (This is the fund code that links to the fund code in the extracted order record.) This must be unique, even across ledgers.|
|FUND NAME||Alphanumeric, repeatable.|
|LIBRARY||Must be in the Alma Library List on the Libero Migration Form. The library code must match the code in the migration form exactly – the match is case-sensitive. There can be multiple libraries here, separated by a semicolon. This field can be left empty, which means that all libraries 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 dollars, of the current fiscal year’s funds.|
|FY||Fiscal Year, in form YYYY|
|Libero-Identnummer = Libero title ID||Links to bib record. Required.|
|Bestellnummer = Order no.||this must be unique per vendor in Alma|
|Bestellnummner-Zeile = Order line no.||this must be unique in Alma; migration will concatenate Order no. + Order line no. to make a unique number|
|Lieferanten_Code = Vendor code||Links to vendor file|
|Haushaltskostenstelle = Fund code||Links to fund file|
|Notiz für Lieferanten = Vendor note|
|Bestelltyp = Order type||Use map: PO Line Type|
|Bestellstatus = Order status||Use map: PO Entry Point|
|Erwerbungstyp = Acquisition type||Use map: PO Acq Method|
|Exemplarpreis = Item price|
|Rabatt = Discount||expressed as a percentage. Use '5' to express a 5% discount. Non-negative discounts only. Decimal point is ok, for example 2.5 is 2.5 percent discount.|
|Alma-Bibliothek = Alma Library||This code should be present in Library/Location mapping tab|
|Aktuelle Zweigstelle = ALma location||This code should be present in Library/Location mapping tab|
|Bestelldatum = Order sent date|
|Bezahldatum = Payment date||This is used to calculate PO Entry Point - the check is only to see if the date is present. If you also wish to retain this date for information, place it in a note.|
|Berichtscode 1 = Reporting Code 1||Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 1st Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.|
|Berichtscode 2 = Reporting Code 2||3Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the @nd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.|
|Berichtscode 3 = Reporting Code 3||Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 3rd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.|
|Berichtscode 4 = Reporting Code 4||Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 4th Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.|
|Berichtscode 5 = Reporting Code 5||Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 5th Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.|
Any additional fields not listed above can be put into notes. The possible note fields in Alma items are listed in the following chart 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.
|Note Name||Default Local Field|
|POL_RECEIVING_NOTE||This line cannot be duplicated; place only one local field name here.|
|POL_VEND_REF_NO||This line cannot be duplicated; place only one local field name here.|
|POL_ADDL_NO||This line cannot be duplicated; place only one local field name here.|
Enter a default language of conversation with vendors
Central Order Library
Default Order Library
What is your currency?
Fiscal Period Cycle Pattern
Which year do you use to name the fiscal year?
- Second – if the fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
- First – if the 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 examp le, 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.
Default claiming period
PO Line Type Tab
- 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.
Line Types and Electronic Orders
PO Acq Method Tab
- 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
PO Entry Point
The entry point value is used to determine where PO falls in the workflow in Alma. The following are the possible values for poEntryPoint:
- 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 have status NEW for 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.
For the migration from Libero, first the migration program checks if Bezahldatum = Payment date has value and it is a One-Time (OT) order. If so, the PO is set to CLOSED. Then, the program checks the PO Entry Point map.
Libero Order Status (Bestellstatus): The value of the Order Status field in Libero.
poLineType: The mapped PO Line Type (mapped in the PO Line TYpe tab)
Alma PO Entry Point: select an entry point for this order in Alma. Possible values are described above and can be selected from the dropdown.
PO Reporting Code Tabs
Use this tab if you wish to map values from the Libero reporting code field to the Alma Reporting Code field. These tabs are 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.
Libero Reporting Code: The value of the reporting code in order record, found in the POL_REP_CODE_* fields in the order extract.
Description: A description of the Libero reporting 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 incoming 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.
Further Explanation – Acquisitions
POL Copies/Inventory Handling
- One Time Orders
Less common case instead of 2a. in case the item was pre-created before receipt, open the item editor and link to the relevant POL, then proceed to step 2b.
- One time orders generally do not link to any specific item in source ILS systems. Only with a specific item id in hand can the location/copy information on such POLs be created.
- Since there is generally no such connection, we pass only the intended library/location and quantity in the POL receiving note, which most source systems do provide. This information allows the receiving/purchase operator upon receipt to:
- Open the POL and add the relevant copy which is being received - presuming the item wasn't created prior to the receipt.
- At this point, the item can be received normally.
- Ongoing Continuous/Subscriptions/Non-monographic Standing Orders. These order types often link to a specific holding record in source ILS systems. If they do, receiving occurs in Alma as usual. This is why a location/copy for continuous orders (which means an actual holdings record ID association was made to the order) are related to such orders.
- Alma supports only one order line per holding, while source systems may allow more than one order per holding. Therefore, in migration processing, the most recent open order is chosen for holdings that has more than one order line reference.
- Older orders will not have copy information and will also not undergo P2E.
- Some orders do not have any holding relationship in the source system.
- If the holding to receive upon exists – From the holding editor, link the holding to a specific order (taking into account that it is limited to one order from that holding).
- If the holding to receive upon does not yet exist – From the PO line edit page, select Add holding/copies to create and link a new holding to the order. This allows the receiving of new items.
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.
Transactions of Amount 0.00
Physical to Electronic (P2E) Processing
It is not possible to use the P2E process to generate a package; by definition, packages must have portfolios associated with them. Instead, you may migrate packages as type database, which is basically a zero-title package, and then change the database to a package (with titles) post-migration.
All records are converted to Alma as physical initially. A second process converts records identified as electronic to the electronic format.
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 – 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.