Alephino to Alma Migration Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

The purpose of this document is to explain:

The information that you need to supply to Ex Libris regarding each Alephino component that is to be migrated to Alma
The rules that are applied to the information for each Alephino component when this information is migrated to Alma, which is helpful in determining where your data went after it migrates to Alma

This document is intended to be used to complement the Alephino Migration Form that provides further information regarding the migration process and steps required for Alma.

Ex Libris migrates your acquisitions and course data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.

It is recommended that you view the Introduction to Alma Configuration session before completing your migration form, as the mapping and migration of libraries and locations has implications for subsequent configuration.

Prerequisites

Basic knowledge of Alma and Alephino key concepts and architecture, and the requirements (including the migration-related approach) described in Getting Ready for Alma and Discovery Implementation as well as the Electronic Resource Handling in Alma Migration.

Recommendations for Using this Guide

This document is divided into four areas:

Inventory
Fulfillment
Acquisitions
Physical to Electronic

Each area has the following sections:

Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the migration form.
Individual Tabs – Instructions for how to fill out individual tabs on the migration form. (Examples: Alma Libraries Tab, Location Mapping Tab).
Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.

We recommend that you look at the Questionnaire Tab section and the individual tabs in each area to assist in filling out the migration form.

If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanation sections.

Exporting data from Alephino

In order to export your data from Alephino,

Go to Web Services page

Select "Interfaces"

Select "Export Data"

Inventory

Alma requires bibliographic, holdings, and item records.

Alephino supports both MAB and MARC21 bibliographic formats. Bibliographic records in MAB format are converted to MARC21 format during the migration to Alma. If holding records already exist in Alephino, they will be migrated, but if items exist that do not have holding records, they will be generated. See Determining Groups of Holding Records below.

Throughout this guide, all referred bibliographic tag names are in MARC21 format, for example the 852 and the LDR.

Customer Input

Questionnaire Tab

Institution Code, Customer Code, Institution Name, Customer Name, INST_ID

Codes: INST_CODE, CUST_CODE –fill in with values provided by Ex Libris.

INST_NAME, CUST_NAME – fill in these fields with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium). This is for informational purposes only and is not used in Alma.

INST_ID – fill in this field with ID value provided Ex Libris.

Default: N/A

Options: This question is mandatory.

Alephino DB name to migrate

Code: ALEPHINO_DB

Default: N/A

Options: This question is mandatory. Limit to one DB name. This is the name of your database on your Voyager server, for example, yyydb.

Time Zone

Code: TIMEZONE

Default: N/A

Options: This question is mandatory. If your time zone is not listed in the drop-down list, contact your Ex Libris project manager.

List the prefix for SFX or other link resolver system record numbers

Code: SFX_PREFIX

Default: (SFX)

Options: List the string that indicates bibliographic records from an electronic link resolver system. If not indicating a link resolver, leave blank.

Further Information: In order to allow online journal subscriptions to be discoverable in the OPAC, some Alephino customers imported bibliographic records from SFX or another electronic link resolver system into Alephino, with the link resolver system’s unique number denoted in the 035 field. When the link resolver system is SFX, the unique number is prefixed by "(SFX)". Other link resolver systems may have a different prefix.

If the migration also harvests online subscription information from the link resolver system, this may result in duplicate bibliographic records in Alma. That is, you may have bibliographic records in Alma that came directly from your electronic link resolver system like SFX, and also the same bibliographic records in Alma that came by way of Alephino.

The migration programs check for the string listed in the 035 $a field of the bibliographic record. If the bibliographic record has the exact string listed, then:

If the bibliographic record has no orders attached or it has only items in an electronic location, the bibliographic record is not migrated.
If a purchase order is associated with the bibliographic record, the bibliographic record is still migrated, but is automatically suppressed to avoid end-user discovery duplication.
If a non-electronic (physical) item is attached to the bibliographic record, the bibliographic record is migrated as not suppressed. Non-electronic items are items that have a location that is specified as No in the Electronic Location? column in the Locations tab of the Alma Migration Form.

Interaction with bibkey->035 movement: the skipping process described in this section is performed BEFORE the bib key is moved to the 035, so any 035 created from the migrated bib key is not considered.

MARC Organizational Code

Code: MARC_OC

Default: N/A

Options: This question is not mandatory and can be left blank.

Further Information: Fill in your MARC organization code for inclusion in the former system number as it is migrated to Alma. http://www.loc.gov/marc/organizations/. Institutions that have more than a single MARC Organization code should choose one for use in conversion. Typically, there is one that represents the institution as a whole. Any institution that does not have a MARC organization code can apply for one. Ex Libris strongly recommends that all customers use their MARC Organization Code when migrating to Alma, as it helps identify the owner of the record. If you do not have a code or do not want to use one, fill in the word Alephino.

The migration program moves the value in the exported record’s 001 (The Alephino record ID) to the 035:

035 __ $a (MOC)<Alephino record id>-<Alephino library code>

Where:

<MOC> is the MARC Organization code.
<Alephino record ID> is the system number of the Alephino bibliographic record, stored in the 001 on export from the database.
<Alephino library code> is the database code.

Do you use internal system numbers in $w of Linked Entry fields?

Code: LINKED_ENTRY_W

Default: No

Options: Yes/No. Optional

Further Information: Indicate if you use the local system number in $w of the 76x-78x, 800, 810, 811, or 830 linking fields.

When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, Alephino stores the information in bibliographic tags and relies on tag indexing to create a link between the records. Some Alephino customers use the Alephino system number in $w to make a direct link between the two records, while others rely on more general identifiers specified in other subfields such as ISBN ($z) or ISSN ($x).

The linking tags, 760 – 787, 800, 810, 811, and 830, are migrated from Alephino to Alma as they currently exist, but if you answer Yes to this question, $w are converted from the Alephino system number to the Alma system number.

In Alma, the system numbers in $w (along with $z and $x) are used to link two related bibliographic records together using the related records process.

Internal record designation for Linked Entry fields $w

Code: LINKED_ENTRY_PREFIX

Default: N/A

Options: optional

Further Information: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to which we will match to identify the local system number. If the internal system numbers do not have a prefix (or you answered No to the previous question), leave this question blank.

Indicate which 852 subfields to use to determine unique holding records

Code: 852_SUBFIELDS_FOR_HOL

Default: bc (library and location only, not call number)

Options: To group all items on a single bibliographic record by library and location only, select bc here. If you have many items in the same bibliographic record in the same llibrary/ocation but different call numbers WITHIN that library/location and you want each of them to have their own distinct holding record, specify additional call number subfields. Acceptable subfields: bchijklmp.

The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.

Further Information: See Determining Groups of Holding Records and Changing the Holding Record Grouping.

Do you want to use a call number in the generated holdings records?

Code: CALL_NO_IN_HOL

Default: Yes

Options: Yes or No

Further Information: You may choose to generate holding records without any call number, so that the 852 contains only $b (library) and $c (location). Values in the incoming Item Call Number field are placed in the Alma Item Call Number, and AltCallNo is not used when this is set to Yes. Further, customers should only use ‘bc’ for the 852_CALL_NO_FOR_HOL question when this is No.

Limit data exported by location: Unless instructed otherwise by your Ex Libris project manager, leave this as No.

Code: LIMIT_BY_LOCATIONS

Default: No

Options: If your export contains all of the data from a shared database, and you want to only migrate a part of that export to Alma, the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab.

Bib Key Prefix

Code: BIB_KEY_PREFIX

Default: empty

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 former system numbers in Alma after migration. For example, the different systems likely had completely different bibliographic records for system number 12345 and you want to be able to search for the specific bibliographic record from your own institution after go-live. The prefix does not include a hyphen, so if you want a hyphen in the number (for example, PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.

Add institution suffix to Bib ID

Code: BIBID_INST_SUFFIX

Default: No

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

Item Price field as Replacement Cost

Code: REPLACEMENT_COST

Default: No

Options: Yes/No

Further Information: If the price in the item record is an actual replacement cost that will be used to assess a fine for a lost item, answer Yes here. The cost is used in the calculation of fines if the item is lost by a patron. Otherwise, if the item price should not be used in the fine replacement cost and is only kept for historical acquisition purposes, leave this as No.

Alma Library Tab

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

Alma Library Code: Maximum 10 characters. 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.

Alma Library name: Maximum 255 characters, cannot contain a double quote (") or slash (/ or \). 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: An email address is mandatory. The migration process sets the email address provided with all possible email address types in Alma.

Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not 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 higher level of location in Alephino is the sublibrary, and is comparable to the Alma library. Use the Alma Libraries tab in the Alephino Migration Form to indicate your list of Alma libraries. The actual mapping from the Alephino sublibrary to the Alma library is done in conjunction with the location in the Alma Location tab.

If you use an error library (for example EMPTY) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library on the Library Tab.

Alma Location Tab

Use this tab to map your Alephino sublibraries and locations to libraries and locations in Alma. Filling in this tab is mandatory.

Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.

Alephino Sublibrary Code: Value from the sublibrary field in Alephino. The ALMAME_VAL_NOT_FOUND line is required to catch any sublibrary codes you may have missed.

Alephino Collection: Value from Location field in the item extract in Alephino.

Alma Library Code: The library that contains this library/location combination in Alma. You can use the same sublibrary codes that you used in Alephino, 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 collection in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used as collections in Alephino, but this is not required. You may also use this form to collapse collections if desired, for example refa and refb in Alephino both map to ref 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 indicators. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item or holding 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, cannot contain a double quote (") or slash (/ or \).

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, cannot contain a double quote (") or slash (/ or \).

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 want to stop using a location code after migration, map the Alephino code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Alephino database.

The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think that you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left or a stray holding record, etc.

By default, the location code for the ALMAME_VALUE_NOT_FOUND line is UNASSIGNED, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example MAIN as in the example line below. In this case, the items inherit the configurations for the MAIN library.

Alephino SubLibrary code	Alephino Collection Code	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

Post-migration, search for items in the “UNASSIGNED” location and correct the records appropriately.

Alma Location Name and Alma External Location Name

The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:

The following is acceptable:

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

The following is not acceptable since archstk and archref both map to the same Alma Location Name:

Library	Alma Location Code	Alma Location Name	Alma External Location Name
Library A	archstk	Archives	Archives
Library A	archref	Archives	Archives

The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:

The Alma library is placed in the 852‡b field.
The Alma location is placed in the 852‡c field.

Collapsing Locations

This mapping table can be used to collapse location codes – that is, two or more location codes in III can map to a single location code in Alma. The Alma location and library code fields may not be empty. If you want to stop using a location code on migration, map the III code to an easily identifiable code such as XXX if any stray items are still in your III database.

If you collapse location codes, you may have lines in the table such as the following:

Alephino Location Code	Alma Library	Alma Location Code	Alma Location Name	Alma External Loc Name	Suppress from Externalization	Electronic Location
reserves	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesElec	MAIN	RESERVES	Reserves	ReserveElec	Yes	Yes
reservesShort	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesPerm	MAIN	RESERVES	Reserves	Reserve	Yes	No

The two values in bold italic above (ReserveElec as the External Location name, and Yes for Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.

Shelving Scheme Tab

Alma will generate a first indicator for the 852 based on the Shelving Scheme tab.

SHELVING_SCHEME: The values in the Shelving Scheme tab as defined in Alephino. The commonly used values are included in the tab, but you can make additions or changes as necessary.

852 1st Indicator: List the value that should be used in the 852 first indicator field when generating a holding record from the item. For a list of possible values and their description, see http://www.loc.gov/marc/holdings/hd852.html. Note that 7 is not supported on migration. Mandatory.

Description: A description or note for this shelving scheme value, if you need to make a note while deciding the first indicator value. This column is not used in migration.

Further Information: Do not use an ALMAME_VAL_NOT_FOUND line here, because if an item has a shelving scheme that is not listed or does not have a shelving scheme value, the shelving scheme is taken from the Call Number Type column on the Location tab of the Alephino Migration Form.

Item Type Tab

Use this tab to migrate the Alephino Item Type to the Alma Item Policy. This tab is optional. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.

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

Alephino Description: The description of the Alephino 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 itemPolicy 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.

Item Base Status Tab

Use this tab to map your Item Base Status in Alephino to an item status in Alma.

Alephino Item Process Status: The code for the item process status in Alephino.

Description: A short description of the item process status in Alephino if desired, for note purposes while filling out this form. This column is not used for migration.

Base Status: 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, NewBooks is on the shelf (1), but Withdrawn 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 Alephino are given the process type of TECHNICAL and the item status from the Description column of the migration form is written to an Alma item note. This is placed in internal note 1. 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 A – Post-Migration Process Statuses for more information.

Material Type Tab

Use this tab to migrate the Alephino Material type to the Alma Material type.

Alephino material type: The value in the material type field of the item coming from Alephino.

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

Alma Material Type: The Alma value for the material type. Material types in Alma are fixed. You cannot add any new types to the list. Select the appropriate material type from the drop-down list.

If this map is not used, Alma migration assigns the item material type based on the fixed fields in the bib as described in section Material Type from Bib Fixed Fields below.

Further Explanation – Inventory

Alephino has Bibliographic, Holdings, and Item records, and so does Alma. Alma requires a holding record for every item, so if there are item records in Alephino without a holding record, one will be generated based on location and call number information in the item and/or serial subscription record.

Determining Groups of Holding Records

The permanent location and call number in Alma is only stored in the holding record. All items attached to the 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.

Changing the Holding Record Grouping

You may decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped, described in the Library, Location and Call Number sections above, are: $b Library $c Location $h Call Number. By default, the migration programs compare $b and $c, but you may decide to change this based on items in your collection.

When the holding record group is based only on $b (library) and $c (location), some item call number information is not reflected in the holdings record call number if the call numbers differ from each other in the same library/location. However, the differing call number is stored in the item’s Item Call Number field, so the call number is not permanently lost.

For example, if there are four items on the same bibliographic record with the following call numbers, all in location main:

item 1 $b main $c stacks $h PN 567 .M4

item 2 $b main $c stacks $h PN 567 .M457

item 3 $b main $c stacks $h PN 567 .M457

item 4 $b bio $c flr1 $h PN 567 $i .M457

When only $b and $c are used to determine a holding record group, two holding records for the above items are created: Holding record $b main $c stacks $h PN 567 $i .M4

item 1

item 2 (with PN 567 .M457 stored in ItemCallNo)

item 3 (with PN 567 .M457 stored in ItemCallNo)

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

When the holding record group is based on more subfields, for example $b $c $h, three holding records are created: Holding record $b main $c stacks $h PN 567 .M4

item 1

Holding record $b main $c stacks $h PN 567 $i .M457

item 2

item 3

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

Decide which 852 subfields will be used to determine holding record groups by answering the question in the Questionnaire tab of the Generic Migration Form, “Indicate which 852 subfields to use to determine unique holding records”.

Material Type Mapping

Material type in Alma is a description of the type of material of which the item consists, such as book, map, issue, DVD, compact disc, and so forth. It is controlled by the physical resource material type code table in Alma. Each item in Alma must have a material type specified even though the functionality behind it is minimal.

If the Material type tab above is not used, then this chart below is used, which is based on Bibliographic LDR and 007 fields, either in the original MARC21 record, or if the customer is coming from the MAB format, from the converted record in MARC21.

There is no customer input required for getting the material type from the bib record. To see a description of how the material type is determined, see the Resource Type Field description.

Fulfillment

Patron records are required if loans, requests, or fines are migrated. Patron records can be updated post-migration with the patron update routines.

In addition to patrons, Ex Libris migrates active loans, active requests on the hold shelf waiting for pickup, and outstanding fines to Alma.

Customer Input

Questionnaire Tab

Enter a two letter code for the default conversational language for your users and vendors (for example en or de)

Code: PATRON_LANG

Default: en

Options: optional.

Further Information: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. This code is also used as the default conversational language for vendors.

Which identification number should be used by patrons as the primary identifier?

Code: PATRON_PRIMARYID

Default: UNIV_ID (ID2)

Options: UNIV_ID (ID2), BARCODE (ID1), ADDL ID 1 (Primary ID). The Alephino identification type is in parentheses. Mandatory.

Further Information: Select the identifier to be used as the primary identifier for all patrons. For more information, see Further Explanation – Fulfillment.

If you want to use a different field, contact your Ex Libris project team to discuss your request.

Currency for patron fines

Code: CURRENCY

Default: USD

Options: Use the three-letter code (for example, USD, EUR, GBP) for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.

Request Default Destination Library

Code: REQUEST_LIBRARY

Default: None

Options: If the requests file does not contain a destination library/location, the library you enter for this question is used as the default for where patrons pick up requests from the hold shelf. This sublibrary code should be in Alephino, as it will be sent through the Alma Location tab map.

User Group Tab

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, and undergraduate.

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

Alephino patron status: The Alephino patron type code.

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

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

Alma User Group Description: The description of the Alma User Group. This description is loaded into the Alma code table as the description displayed 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 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 community borrowers or alumni. If you select Yes, all of the patrons in the Alma userGroup are categorized as internal. If you select No, all of the patrons in the Alma userGroup are categorized as external.

Notes/Comments: Add any notes or comments for the Alephino User Profile. This column is not used during migration.

Further Information: See also the following question in the Questionnaire tab, regarding internal and external users:

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

See also the section on internal/external patrons.

User Language Tab

Provide the list of available language codes from Alephino and their description, along with the language code as it should be in Alma. Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. This mapping table is not mandatory. If fields are left blank, all patrons are assigned the default patron language as defined on the Questionnaire tab (PATRON_LANG).

Alephino Patron Language: The Alephino language code.

Alephino Language Description: A description of the Alephino patron preferred language, for informational purposes only. This column is not used in the mapping.

Alma Language Code: The language code desired in Alma.

Alma Language Description: The description of the language. This column is not used by the migration programs.

User Block Tab

Alephino stores patron block information in various delinquency fields in the patron, both at the library level and the sublibrary level. Provide the list of delinquency codes from Alephino and their descriptions, along with the block code as it should be in Alma. This mapping table is not mandatory.

Alephino Delinquency code: The Alephino delinquency code, from both the library and sublibrary levels. Do not include statuses that indicate the patron is not blocked, such as OK.

Alephino Delinquency description: A description of the Alephino patron description, for informational purposes only. This column is not used in the mapping.

Alma Block code: The block code desired in Alma.

Alma Block 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 updated after migration.

Comment: Use this field to add any comments about delinquencies to help with the table. This field is not used in migration.

Fine Fee Type

Alephino Fine Transaction Type: List all of the values from the Fine Transaction Type code in Alephino.

Alephino Description: A description of the Fine Transaction Type, for assistance in filling out this form. This column is not used in the mapping routine.

Alma Fine Types: Possible values in Alma are listed in the drop-down list.

Further Information: Outstanding patron bills from Alephino are migrated to Alma Fines and Fees, and paid bills (with a zero balance) are not migrated. Only the currently owed amount is migrated. If any partial payments have been made before conversion, they are not reflected on migration to Alma.

Further Explanation – Fulfillment

Internal/External Patrons

Alma categorizes users as either external or internal. External patrons are managed 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 community borrowers or alumni. Identify patrons as internal or external by user group on the Alephino Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.

Identification Numbers

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 that the patron uses to authenticate via Primo. Internal patrons authenticate with the primary ID and a password using the Alma Identity provider service, and external patrons use the primary ID as the match point with an external authentication system. The following shows the map from Alephino identifier type to Alma identifier type.

ID1 maps to UNIV_ID

ID2 maps to BARCODE

Primary-ID maps to ADDL ID 1

So, for example, if you want the Barcode (ID2) to be used for the primary ID for your users in Alma, select BARCODE for the primary ID question on the Questionnaire tab of the Alephino Migration Form.

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 unique 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. The original identifier is stored in the non-unique userIdentifier field so that the patron can still be retrieved using that identifier.

The primary ID that you select is not also written to the patron identifier section in the Alma patron record. The identifiers that are NOT selected as the primary ID are written to the patron identifier section in Alma.

When an identifier is written to the identifier section and there are multiple instances, the first one found for each type is active and the subsequent ones are inactive. Identifiers that are not used as the primary ID do not need to be unique and are not de-duplicated.

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. Select BARCODE, UNIV_ID, or ADDL ID 1, 2, 3, or 4 as the primary ID type for internal or external patrons in the Questionnaire tab of the Alephino Migration Form.

Gender

Gender is no longer in use in Alma. See an explanation here.

Loans

Active loan transactions are migrated from Alephino to Alma. Completed loan transactions are not included in the migration to Alma.

Requests

Active requests that are trapped and sitting on the hold shelf waiting to be picked up are migrated from Alephino to Alma. Requests which are pending (not yet placed on the hold shelf) are not migrated to Alma.

Acquisitions

Ex Libris migrates vendors, funds, ledgers, purchase orders, invoices, and fund transactions to Alma.

Customer Input

Questionnaire Tab

Has your library contracted with Ex Libris to migrate Acquisitions data?

Code: ACQ_MODE

Default: Full

Options: Mandatory. Full (Full Acquisitions), None (No Acquisitions), Partial (Vendors, Funds, Purchase Orders (no Invoices)

Further information: Select Full/ None /Partial depending on the mode that you have contracted with Ex Libris for the Acquisitions data migration.

If you select None (No Acquisitions), you must still answer the questions on the migration form about the fiscal period (FISCAL_PERIOD, FISCAL_PERIOD_NAME, and CURRENT_FISCAL_PERIOD). Alma requires at least one fiscal period defined even if no orders or vendors are migrated.

Default currency for Ledgers/Funds

Code: ACQ_CURRENCY

Default: USD

Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.

The currency should be a three-letter code as listed in http://en.wikipedia.org/wiki/ISO_4217

Default language of conversation with vendors

Code: VENDOR_LANG

Default: en

Options: Specify the default vendor language for your vendors. Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.

Fiscal Period Cycle Pattern

Code: FISCAL_PERIOD

Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).

Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.

Alma currently supports one-year fiscal period cycles.

Which year do you use to name the fiscal year?

Code: FISCAL_PERIOD_NAME

Default: second

Options: Specify if the fiscal period is named with the first year or the second year.

second – if fiscal period runs July 1 2017 through June 30 2018, the fiscal year is named 2018.
first – if fiscal period runs July 1 2017 through June 30 2018, the fiscal year is named 2017.

If your fiscal period runs from January 1 through December 31, this question is not necessary.

Current Fiscal Year

Code: CURRENT_FISCAL_PERIOD

Default: determine by date of conversion

Options: This question is important around the fiscal period close, depending on whether or not you have run fiscal perio d close in Alephino or if you will run it in Alma after migration. If you do not know how to answer this, select determine by date of conversion. The options are:

Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
2016-2017 – 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, 2017, and the previous fiscal period ended on June 30, 2017, select this to put all of your orders in the fiscal period that ended on June 30, 2014 (previous fiscal year). Select this option if you want to run fiscal period close in Alma instead of in your old system.
2017-2018 – 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, 2017 and the next fiscal period begins on July 1, 2017, 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.

Accrual Accounting

Code: ACCRUAL_ACC_FY

Default: No, do not make an additional fiscal year

Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an a dditional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:

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.

Further Explanation – Acquisitions

If your institution has migrated for full Acquisitions migration, the following entities are migrated: Vendors, Funds, Ledgers, Fund transactions, Purchase Orders, and Invoices.

Vendor Information Rules

Vendors/Users

Alma vendors are also Alma users. Users are the general entity for something that has an identity, addresses, and contacts. Each Alma vendor has one user record and a separate vendor record to hold vendor-specific information.

There is no question for the conversational language specifically for vendors. The migration uses the patron conversational language in the migrated vendor record.

Currency

The migration programs map the existing vendor currencies for each vendor record from Alephino to the currencies in Alma for that vendor.

Vendor Accounts

Vendor accounts are mapped from Alephino vendor accounts where possible. If there is no vendor account in Alephino, then a default vendor account is made in Alma. Alma requires at least one vendor account for each vendor.

Vendor Status

The Alephino vendor status is mapped to Alma as:

AC (active) = Active
NA (not active) = Inactive

Vendor EDI Information

Vendor EDI information and codes are migrated as they are. If multiple EDI connection profiles exist for the same vendor, the most recently updated profile is migrated. Some additional EDI vendor configuration is required to enable the EDI functionality with vendors in Alma.

Vendor Addresses and Contacts

In Alma, a vendor has a set of addresses and contacts. Vendor accounts may choose which of these addresses and contacts the account uses. Each vendor address is assigned all address types (order, claim, payment, etc.) on migration to Alma. All email addresses are also assigned all email address types on migration (orderMail, claimMail, etc.). Similarly, all phone numbers are assigned all phone types (orderPhone, claimPhone, etc.).

Alma attaches all the addresses and phone numbers to the vendor record and to all vendor account records. You can unlink the addresses and phone numbers from accounts that do not use them after the migration is complete.

Fund Transaction Information Rules

Transaction Types

The following table describes how transactions are migrated to Alma.

Alephino Type	Alma
ILC = initial allocation ALC = additional allocation TRN = transfer	Allocation A transfer out (decrease) is migrated as a negative allocation
ENC	Encumbrance
EXP	Expenditure

Purchase Order Transactions

The following chart describes transactions created for different purchase order entry points:

SENT (open) = Encumbrance

CLOSED/CANCELLED = no transaction created

NEW = no transaction created

For how the PO Entry point is determined, see PO Entry Point below.

Invoice transactions

Invoices get a single expenditure transaction linked to a fund.

Transactions of Amount 0.00

Alephino 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.

All expenditures of amount 0.00 are discarded during migration, along with the invoice line. These invoice lines are written to an error log.

Purchase Order (PO) and PO Line Migration

Purchase Order Entry Point

The following map is used to migrate the PO header status from Alephino to Alma:

CLS = CLOSED
IP = SENT
LC = CANCELLED
NEW = NEW
RSV = NEW
SV = SENT
VC = CANCELLED
XXX = SENT

PO Line Type

Alephino order types map to Alma as follows:

M (Monograph) = PRINT_OT
O (Standing Order) = PRINT_SO
S (Serial) = PRINT_CO

PO Line Types for Electronic Orders

The above line types are all descriptions based on a print order. All orders are stored in Alephino 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 transform the order to electronic. In other words, if an order migrates as PRINT_SO is attached to a bibliographic record that 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.

Purchase Order status of 'In Review'

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 view a simplistic flow chart for the workflow process in PO/POL Workflow modifications.

Linked Inventory/Receiving Location for Monographic Orders

Monographic orders in Alma are linked to item records. Orders from Alephino may or may not link to the item record, even though there may be an item on the linked bibliographic record. When an order does not have a linked item record, there is no real place in Alma to put the expected inventory location that migrates from Alephino. To indicate the expected inventory location in lieu of a linked inventory item, the migration programs place the inventory location codes into the PO line receiving note, which appears at the top of the summary screen on the Alma PO line.

After go-live, the receiving operator should do one of the following:

1. In the case that there is no item on the linked bibliographic record, and the expected item arrives, generate an item using the information from the receiving note prior to receiving the order.

2. In the case that there is an existing (migrated) item on the linked bibliographic record: these items do not appear on the Receving workbench. These items will have to be manually received by updating the item receiving date and then link the item to a POL.

Linked inventory for Continuous Orders

Continuous orders (standing orders and subscriptions) are linked to holdings records. Generally there are holdings records for most continuous orders, so an order can be linked to an existing holdings record.

Alma allows only one order to be linked to a holdings record. If multiple orders are linked to a holding record, the first order found links to the holdings record, and subsequent orders are simply linked to the bibliographic record with no linked inventory (holdings).

When an order does not have a linked holdings record, just like described for monographic orders above, the intended location is placed in the receiving note only. After go-live, the receiving operator should either link the order to an existing holdings record or generate a holdings record prior to receiving the order in Alma.

Physical to Electronic (P2E) Processing

This section describes the process of correctly categorizing resources as electronic in Alma. In Alephino, all resources are categorized as physical in the database even if the record represents an electronic item. All records are converted to Alma as physical initially. A second process converts records identified as electronic to the electronic format in Alma.

Many types of e-resources can be in a customer’s Alephino database: e-journals, e-Books, e-Gov docs, e-packages, and others. In order to identify the e-resources, the institution should provide a list of bibliographic keys that identify records that are electronic, in the following format:

bib_key,type

123475,portfolio

12346,DB

The P2E file must be submitted as a csv file.

Customer Input

Questionnaire Tab

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 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.

Which Holding or Bib field stores electronic link information

Code: P2E_LINK

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

Default: 856 u

Which Holding or Bib field stores electronic link public note

Code: P2E_NOTE

Options: Provide a 3 digit Marc field code + subfield: 856z. Only one subfield is allowed.

Default: 856 z

Which Holding or Bib field stores electronic provider name information

Code: P2E_PROVIDER

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

Default: 856 m

Location Mapping Tab

Electronic Location Column

Identify which locations indicate an electronic holding or item record. A single bibliographic record may contain holdings for multiple locations, but only the holdings/items for electronic locations need to be identified. Identify the locations by answering Yes or No in the Electronic Location? column of the Alma Location tab.

Further Information

The conversion process identifies the lowest inventory level resource that indicates an electronic resource: item records, unsuppressed holding records, or bibliographic records. Suppressed holding records are not considered in the p2e process. In addition, any associated order records associated with the item, holding, or bibliographic record is included.

If the bibliographic record will not be migrated because it is duplicated elsewhere, it is removed from the P2E process. For example, SFX bibliographic records duplicated in Alephino are not migrated, because the SFX records will also be loaded into Alma from SFX itself. However, if the duplicate SFX record in Alephino has order information associated with it, it is kept in the P2E process to preserve the migration of the order record. Tools will be provided on the Alma side to optionally move the order record from the Alephino-sourced bibliographic record to the SFX-sourced bibliographic record, post-conversion.

Once the lowest level of inventory resource and associated order record have been identified, the records in Alma are structurally modified to reflect the fact that they are a portfolio, package, or database.

If the bibliographic record is included in the file more than once and with a different e-resource type, the second record is rejected and written to the report file.

For more information on the electronic migration approach to Alma, refer to Electronic Resource Handling in Alma Migration.

Appendix A: Post Migration Process Statuses

The process statuses (the codes) from Alephino are mapped into the indexed internal note 3 field of the Alma item. These items are considered not available after migration when Process = Technical – Migration.

These fields are currently indexed in the item keyword and advanced searches.

When searching for physical items, a staff user can search by item process status code with the general keyword search and then by facet if before searching, Process type = Technical – Migration and with the advanced search filter when Process type = Technical – Migration.

In order to give items real Alma statuses or remove the Technical – Migration status, scan the barcode of the item to various configured departments (via receiving for instance), request a move to various departments/temp locations, or just scan the item for return, which removes the status from the item. You may also use the Scan In API, described here: https://developers.exlibrisgroup.com/blog/Performing-the-Alma-scan-in-API-on-a-file-of-barcodes.

Additionally, it is also possible to configure the GetIt (Primo) services to display or not display items with this process status in the GetIt Item list.