Aleph 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 following:

The input or information that you will need to supply to Ex Libris regarding each Aleph area being migrated to Alma, including a step-by-step guide to filling out the migration form.
The migration rules for Aleph to Alma that do not require any mapping input.

Recommendations for Using this Guide

This document is divided into the following areas:

General
Inventory
Physical to Electronic
Fulfillment
Acquisitions

Each area has the following sections:

Overview – Explanations of migration processes
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 Library Tab, User Group Tab, PO Line Type Tab).

We recommend that you review the Questionnaire Tab section and the individual tabs in each area to assist in filling out the Migration Form.

General

Mapping Input

Questionnaire Tab

A. General

Specify the ADM Library you are migrating

Default: No default

Options: This question is mandatory.

Further Information: Fill this field in with the ADM library such as abc50. Note that for each ADM you want to migrate, you must generate and fill a separate migration form. ADM libraries always end with 50-59. Note that all BIB records related to the defined ADM library are extracted.

Have you contracted with Ex Libris to migrate Acquisitions data?

Default: Yes

Options: This question is mandatory. Acceptable values: Y or N

Further Information: If you have purchased this service, fill in Y. If you have not purchased this service, fill in N.

What is your regional time zone?

Default: No default

Options: This question is mandatory. Select you time zone from the drop-down list.

Further Information: This information is used for setting the time data to GMT. Set column D with your regional time zone.

Please specify your institution ID (as determined by the Ex Libris Migration Team)

Default: No default

Options: This question is mandatory. Insert your institution ID (Provided by Ex Libris).

Please specify your Institution Code (as determined by Ex Libris Migration Team).

Default: No default

Options: This question is mandatory. Insert your institution ID (Provided by Ex Libris).

Language Codes: Alma supports ISO 639-1 language codes. Aleph language codes, such as Patron Language (Z303-CON-LNG) and Vendor Language (Z70-CON-LNG) are converted to this ISO standard by the migration.

Inventory

Overview

Alma manages bibliographic, holdings, and item records. Items cannot exist without holdings. Holdings cannot exist without bibliographic records.

Aleph manages bibliographic records and item records. In some cases, Aleph also manages holdings records. The migration process ensures that all Aleph items are associated with a holdings record in Alma.

Alma migration supports the following standards of bibliographic and related information in machine-readable form coming from Aleph:

MARC21
UNIMARC
MAB > MARC21
KORMARC
CNMARC

Alma Structure

The main inventory structure in Aleph is based on the Bibliographic record, ADM record, Holdings record, and the Item record (Z30). The following diagram represents the migrated inventory structure according to the Alma design:

Mapping Rules and Assumptions

Aleph sublibraries and Alma libraries: The parallel to the Aleph sublibrary in Alma is the library. For migration purposes, Alma libraries are created from sub-libraries types 1, 4, and 5 defined in the tab_sub_library.lng configuration table. The address information is taken from the tab_sub_library_address.lng configuration table.

To make the Alma migration simpler, it is recommended to eliminate any unnecessary sub-libraries in Aleph before migration to minimize the number of libraries migrating to Alma. This can be done by performing the following:

Remove punctuation: the only valid characters for library codes are alphanumeric, -, and _ (hyphen and underscore). If your codes have these in them, remove them prior to migration.
Map ordering units: Sub-libraries type 5 migrate to Alma libraries unless they are mapped. Thus, you can map them into existing libraries using Ordering Units tab.
Combine rarely used sub-libraries into other existing sub-libraries, and identify which of your sub-libraries in Aleph (tab_sub_library types 1 and 4) are not actual active libraries. (For information on how to do this, contact your Ex Libris representative.)
To determine how many items there are in each sublibrary, run the following SQL query on the ADM library:

> > select count(Z30_SUB_LIBRARY), Z30_SUB_LIBRARY from z30 group by Z30_SUB_LIBRARY;
If you have holdings records that do not have items or the have the same information in the 852 $$b field as their items library, check the number of holdings records of the ADM library as well, by performing the following:
1. Run p_ret_01 in XXX60 without parameters to retrieve all records.
2. Run p_print_03 (print only 852 field in Aleph sequential format).
3. Analyze your data by comparing the sub-libraries in the holding records against the sub-libraries defined in tab_sub_library.lng and the sub-libraries from the Z30 table from the command above.
Contact your Ex Libris representative for further explanations and recommendations.

If a holdings record contains more than one $$b subfield in the 852 field, only one of these subfields are taken into consideration, and the rest of the data is copied to 852$$k.

Aleph Collections: Aleph collections = Alma physical locations. To simplify migration, create unique collections for each sub-library. Review configuration in $data_tab/tab40.lng in the ADM library. In case it is configured with the use of # in the sub-library code, make sure each entry is relevant for all sub-libraries in the system. Also, remove punctuation: the only valid characters for library codes are alphanumeric, -, and _ (hyphen and underscore). If your codes have these in them, remove them prior to migration.

Library addresses: Library contact information in the form of addresses are taken from the tab_sub_library_address.lng table. In Alma, this information is formatted in dedicated fields (such as country and postal code), while in Aleph the format is free and each site has its own convention and type of data. For this reason, the migration does not populate the Alma dedicated fields. The information is migrated into the non-formatted field of the Alma address.

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

Suppressed Bibs as described above in the Suppressed Bib Tab of the migration form
Australian customers have ALL Bibs marked for Libraries of Australia Publish, if relevant.
BIBs Marked as deleted by position 05 of the LDR, which is set to d (deleted). These records are migrated as suppressed.
OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.
Field 001 is populated by the Alma MMSID. The original 001 is compared to the Aleph system number. If they are not the same or if the 003 field exists, an additional 035 with the original 001 content is created (if 003 exists, 003 is added as a prefix).

HOL records: Alma is designed to work with items linked to HOL records. For sites that partially maintained holdings or did not work with holding at all (XXX6X library), the migration creates holdings for grouped items based on item information (Z30-sub-library/Z30-collection). The migration from Aleph to Alma keeps this structure in a similar way when items are linked to HOL records.

If items are linked to a HOL record, but the X852-ITEM-OVERRIDE variable in the ADM library is set to N, the HOL call number will be the Permanent Call Number and the item call number will be set as the Item Call Number. If the item has an Item Call Number already, it will be set as a Note. When the holding record has no 852 $$b (no library), if there was a link between the items and the HOL it will not kept, as shown in the following diagram:

Location information and HOL records: When there is no HOL record or items are not linked to the HOL records associated with the BIB records, the sub-library, location, and item call number information is used to create a basic holdings record in Alma with this information.
Deleted bibliographic records: In Aleph, there are three types of deleted records. The migration for each is performed as follows:
- Marked as deleted by the DEL field in the record $$aY. These records are not migrated to Alma.
- Marked as deleted by position 05 of the LDR, which is set to d (deleted). These records are marked as suppressed to Alma with the whole inventory structure.
- Marked as deleted by the STA field being set to DELETED. These records are migrated to Alma with the whole inventory structure and position 05 of the LDR is set d (deleted).
Aleph collections = Alma Physical Locations: The parallel to Aleph collections in Alma is the physical locations. Physical locations are migrated to Alma from the tab40.lng table.
Secondary call numbers are migrated and may be optionally mapped to the remote storage field Item Storage ID or by default to the item call number field.
Item description field for serials: In Aleph, the Item Descriptions field (Z30-DESCRIPTION) for serials and multi-volumes contains both the enumeration and chronological description of the item. This field is migrated to an analogous field in Alma. Enum and Chron information of the items are mapped to Alma item Enum and Chron. See Appendix B – Optional Use of Aleph Fix Routines During Migration for additional possibilities related to serial summary holdings and Aleph routines.
Item Material Types in Alma are optional and represent a fixed list based on the Item Material Types table.

Item material type associations as magnetic, based on Aleph’s tab25 setup parameters, are consulted when migrating and will determine if an item is set as magnetic or not.

Item process statuses: These will be migrated to an item note in Alma. In addition, they are assumed to be not in place in Alma and a TECHNICAL status is attributed to them so that they can be identified and managed in Alma further to their relevant Alma-side process or department. There is an option to map the process status with the migration form to indicate that an item has not yet arrived. In this case, the item is assigned TECHNICAL status. The only situation in which an item can receive ACQ status in Alma is when an item is a future serial with prediction and it is connected to an active order.
Loan, On hold shelf, and On Order inventory records have exact analogous statuses in Alma and attain those process statuses when related loans and orders link to them. See Appendix A – Post-Migration Process Statuses for dealing with these item process statuses after migration in Alma.
Bibliographic records with missing subfields: In some cases, there may be a number of records (probably from an ILS system prior to Aleph) in which the MARC is not standard or contains incorrect data. An example of such a case is the existence of a field that must have a subfield according to the standard but the subfield is missing. Since Alma requires standard MARC records, during the migration process, subfield $a is added to the field. All other information is not modified (such as the content of the field or the tag itself).
There are certain cases of invalid MARC records that result in rejected inventory records that are NOT migrated. These cases are most commonly related to invalid MARC datafields or controlfields that Aleph allows. For instance, 007 a – this is a 007 datafield in Aleph. Such a datafield is invalid per MARC standards and causes the entire record to be rejected. The correct field is 007 – thus indicating a valid MARC controlfield. In such cases, a full reject report is provided as part of your migration test load.
LKR fields: Links between records in Aleph (PAR, UP, DN, ANA, ITM). Each LKR type is handled by creating standard 76X-78X and 8XX links pointing to its related Bib record in order to achieve these Marc-level record relationships in a standardized way. The 76X-78X and 8XX |w links reference the structured MMS ID in Alma.
PAR > 775
UP > 773
DN > 774
ITM > 773
ANA > 773

See Appendix C - Aleph to Alma LKR Mapping for a detailed map.

Indicate in the migration form if your site uses 76X-78X , 8XX $w fields to create relationships in addition or instead of Aleph LKR in order to switch the Aleph system number and ensure that these relationships are retained in Alma. This question is not relevant for UNIMARC or MAB libraries.
Item loan history fields – The number of loans and last loan date are migrated to Alma and are reportable in analytics. The item’s maintenance count is migrated as statistical note.
Holding's OWN field – The OWN field populates the item provenance in Alma. The Provenance code table (configuration table) will be created based on tab_exp_own.lng.
Future serial issues/items opened in Aleph and not yet received are migrated to Alma if you answered Y to question "Do you want the Aleph prediction pattern to be migrated to Alma?" Otherwise, only prediction patterns cataloged in the Holding record are migrated.
Course items – Items and their related Holdings and Bibs from XXX3X course libraries (as suppressed by default)
ILL items – Items and Bibs from XXX4X ILL libraries (as suppressed)

Areas/Fields Not In Scope

Cataloging history tracking (Z00T)
Cataloging triggers
Local information added to the ADM record
Temporary material type, temporary item process status, and temporary 2nd call number
CAT fields
Item history records (Z30H)
Loan IP station.

Mapping Input

Questionnaire Tab

B. Inventory

List the BIB libraries you wish to migrate?

Default: No default

Options: This question is mandatory.

Further Information: Provide the list of Aleph bibliographic libraries that should be migrated. All denoted bibliographic libraries are managed in one Alma institution based on its associations to one Aleph ADM library. Fill this field in with the bibliographic library such as abc01. If multiple bibliographic libraries are desired, provide a comma-separated list in column D for example: abc01, abc02, def01, abc30. The bibliographic libraries to note here should end with 01-09 or 30-39. Other Aleph libraries such as abc10-abc19 (Authority libraries) are not included in migration. Note that this definition of bibliographic libraries is for extracting bibliographic records that do not have a connection to the extracted ADM (orders, items, etc.). Bibliographic records related to the defined ADM are extracted, although their bibliographic library is not defined in this question.

Call number subfields for matching items without holdings (Default is bc and recommended)

Default: bc

Options: bchijkmp (or any combination including bc – e.g. bch, bchi, bchijk, etc.)

Further Information: This parameter determines the unique string in Z30-CALL-NO among multiple items of the same ADM/BIB without a real MARC Holdings record in order to determine if a separate holdings should be created or not. If there are no $$ subfield indicators in your Z30, the whole string is presumed to be 852 $h.

Example: Item 1: Z30-SUB-LIBRARY= ABC01, Z30-COLLECTION=STACKS,Z30-CALL-NO = $$hCN1 $$i789

Item 2: Z30-CALL-NO = Z30-SUB-LIBRARY= ABC01, Z30-COLLECTION=STACKS,$$hCN1 $$i789 $$kabc

Item 3: Z30-CALL-NO = Z30-SUB-LIBRARY= ABC01, Z30-COLLECTION=STACKS,$$hCN123 $$i789 $$kabc

Providing the default: bc indicates that one holding is created for all three items. The additional non-matching subfield content from the call number subfields in this case is stored on each item call number (or an item note if the item had a different item call number already).

Providing bch indicates that two holdings records should be created: One for item 1 and 2 and a second holding for item 3. The additional non-matching subfield content from the call number subfields in this case is stored on each item’s item call number (or an item note if the item had a different item call number already).

Providing bchijkmp: indicates that three separate holdings are created here – one for item 1, one for item 2, and one for item 3.

What is your Marc standard organization code for 035 $a setting the original Aleph system number?

Default: No default

Options: MARC organization code (or Aleph if your organization has no Marc org code)

Further Information: Fill in the Marc code (this is relevant for UNIMARC libraries, as well) to be used in 035 and LKR extracted fields. If you do not have a MARC org code, set the string to Aleph and answer question 4 with N or leave it blank. Each bibliographic record extracted contains a 035 field with the Aleph Bib ID in the format:

035 $a(OrgCode)BibNoBibLibCode-Aleph. If you answer question 6 the 77X18$w field is extracted also with the same format: 77X18 $w(MarcCode)BibNoLibCode-Aleph.

When the original system number is built for Bib records, should it include an -Aleph suffix? E.g. (orgCode)002030401-ABC01-Aleph

Default: N

Options: Y, N

Further Information: Enter Y in order to add the -Aleph suffix to 035/LKR fields. Enter N or leave blank if you do not want the suffix added.

What textual marking in 035 |a indicates that your records are copies of Link resolver records. Default: SFX

Default: SFX

Options: Optional string. If nothing is specified, SFX is assumed.

Further Information: Provide the textual content stored in the 035 subfield ‘a’ which indicates the record originated in your link resolver system (when it is not SFX). This sign/string is searched in the 035 field subfield "a" of the bibliographic records in order to attempt to skip these bibliographic records and not migrate them when possible. When the bibliographic record has this string and there are no holdings or items or orders, the bibliographic record is skipped. When there are Aleph holdings or items related to these bibliographic records, the records are not skipped. Note that the definition of electronic holdings and items is handled by P2E-Libs_Cols. If this tab is left empty, all holdings or items under the Link Resolver records are assumed to be electronic and are therefore skipped. An additional check is done for physical items by the mapping of P2E-ItemMT tab. If the LR BIBs have items with material types and the P2E-ItemMT is not defined, the items are considered as physical. When there is an order record related to the bibliographic record, the record is not skipped and migrates as suppressed.

Do you use your Aleph system number in subfield w of Marc Bib linked entry fields 760-787 and 80X-83X?

Default: N

Options: Y, N

Further Information: Enter Y when 760-787 and 80X-83X subfield "w" is used for linking via the Aleph system number alone. If the w subfield of this field's range contains only a numeric string up to 9 digits, it will be extracted with the MMSID.

Enter N or leave blank when 760-787and 80X-83X subfield w is NOT used for linking via the Aleph system number.

This question is not relevant for UNIMARC libraries.

If you use the item secondary call number, do you prefer this field go to the Item call number field in Alma or the storage location id in Alma (used for remote storage sequential/box numbering). Default is item call number and recommended.

Default: alternativeCallNumber (item call number)

Options: storageLocationID, alternativeCallNumber (item call number)

Further Information: Enter the item field to which you would like Z30-CALL-NO-2 mapped into Alma.

Library is a mandatory field in Alma. What default sublibrary code should be applied in case no sublibrary or 852| b holdings value is defined in Aleph?

Default: No default

Options: Mandatory. Select from the fixed input list based on your valid sublibrary codes(col D).

Further Information: This applies only for a library in the resulting 852 |b of the holdings migrated to Alma. This is intended only as a safeguard to ensure that every entity has a library definition, which is mandatory in Alma and which was not always mandatory in Aleph.

Would you like all of your Z30-PRICE data used in Alma as the item's replacement cost?

Default: N

Options: Y, N

Further Information: Answer Y in column D to indicate that the item with the value provided in Z30-PRICE is the price that to be used to determine the replacement cost of the item if the patron loses it. Answer N or leave blank if you do not want the Z30-PRICE information to be used for calculating patron replacement cost fines. Note that only a valid numeric price will be populated. For example, entering symbols or negative values in this field causes the price to become a note and the replacement cost will not be populated.

Which field (Holdings or Bib field) is used for linking in the electronic records?

Default: N

Options: Relevant field

Further Information: Indicate the relevant field, indicators, and subfield in col D. This field is reflected in Alma as a URL tag in the converted electronic record.

Which field (Holdings or Bib field) is used for determining the vendor/provider name of the electronic resource?

Default: N

Options: Relevant Field

Further Information: Indicate the relevant field, indicators, and subfield in col D. This field is reflected in Alma as the vendor of the electronic record.

Which field (Holdings or Bib field) is used for determining an electronic access note?

Default: N

Options: Relevant field

Further Information: Indicate the relevant field, indicators, and subfield in col D. This field is reflected in Alma as the access note of the electronic record.

List your special MARC type BIB libraries (that have no definition in tab100.MARC-TYPE)

Default: N

Options: Only for abc01, abc03 users, with comma separation in column D. Bib libraries only, for example: xxx01-xxx09. Define the MARC type in column E.

Further Information: If you have a special MARC type that is not defined in tab10,0 for instance KORMARC or CNMARC, this question is mandatory. This determines the special MARC type Libraries.

Do you want the Aleph prediction pattern to be migrated to Alma?

Default: N

Options: Y, N

Further Information: Answering Y in column D indicates that future predicted items will be migrated to Alma. Prediction patterns that are defined under the holding or ADM records are extracted with their future items. Note that for migrating predictions created in Aleph by the scheduling mechanism (Z08/Z09) you must answer the next question.

Do you work with "Schedule" functionality in Aleph?

Default: N

Options: Y, N

Further Information: If you answer 'Y' to this question and the previous question, the migration converts the schedule pattern to a prediction pattern in the holding record.

Do you want the cataloger's level of the bibliographic record to be migrated?

Default: N

Options: Y, N

Further Information: Indicate if you want the cataloger's level to be migrated. Note that only the cataloger level is migrated, not the cataloger; therefore, if you answer Y, you are not able to update the bibliographic record until the staff users is set up.

Indicate LKR fields (mapped to linking fields) as local?

Default: N

Options: Y, N

Further Information: Indicate if you want to add $9LOCAL to the LKR fields, which are mapped to MARC 7XX-83X fields by the migration. Note that this is relevant for institutions that link to an network zone and would like to save their Aleph original LKR to be locally managed in the institution zone.

Do you want that a generated holding, will contain a call number (852$h) populated from its item?

Default: Y

Options: Y, N

Further Information: Answering Y in column D populates a 852$h call number field for each generated holding (if there are other subfields such as ijkmp they are generated as well). When selecting N, the call number is created on the items related to these generated holdings. Customers that do not manage holdings in Alma and want to handle the call number on the item level (not the holding), should answer N.

9XX Bib Tab

Which standard 9XX Marc bibliographic field should your Bibliographic non-standard Alpha numeric fields be mapped to?

Default: No default

Options: Optional. Col D - Aleph fields. Col E – 9XX Standard MARC fields.

Further Information: Any non-standard alphanumeric field (for example, STA, OWN, etc.) may be indicated in order to map these non-standard MARC fields to a 9XX standard equivalent.

The first 6 characters of col D reflect the field, ind1, ind2, and subfield, and the rest of the fields reflect the data value (note that is case sensitive). Only the first subfield is compared. If matched, the other subfields are not extracted. If not matched, the field is extracted as it was in Aleph. This mapping is used for fields known as having only one single subfield. Only data fields can be mapped here. Not in use for control fields.

For example:

col D - STA###,DataExample col E 951 c

If there is a bibliographic record that contains the following field: STA12a DataExample, this bibliographic field is migrated to Alma : 951 c DataExample

For more complex cases of mult-subfielded non-standard MARC fields that are not met by the mapping options in the migration form, refer to Appendix B – Optional Use of Aleph Fix Routines During Migration.

The following alphanumeric fields are not supported: FMT, CAT, and LKR.
STA with content SUPPRESSED cannot be mapped to a 9XX field.
Non Alpha Numeric characters are not supported in the mapping (9XX Bib Tab and 9XX Hol Tab)

Suppress Bib Tab

If you have other Alpha fields in Aleph which indicate that the BIB record should be suppressed (in addition to STA=SUPPRESSED), please denote them here

Default: No default

Options: Optional. Optional. Col. D - Alpha Fields. Col. E- content of the Alpha Fields (Column E).

Further Information: Use this mapping in order to migrate bibliographic records as suppressed (this is in addition to the STA=SUPPRESSED cases that are automatically migrated to Alma as suppressed). Col. D should include your Aleph fields that are letters only (not numbers). Enter the string in Col E to be matched for suppressing the bibliographic record.

For example:

Col. D - STA , Col. E- CIRC-CREATED

STA field SUPPRESSED is handled automatically and is stored as a tag related to the bibliographic records in Alma. The STA field DELETED should be mapped as suppressed, so that it is suppressed.

9xx Hol Tab

Which standard 9XX Marc holdings field should your non-standard Alpha numeric Holdings fields be mapped to?

Default: No default

Options: Optional. Col D - Aleph fields. Col E – 9XX Standard MARC fields.

Further Information: Indicate any non-standard alphanumeric fields (e.g. STA, OWN, etc.) in order to map these non-standard MARC fields to a 9XX standard equivalent.

The first 6 characters of col D reflect the field, ind1, ind2, and subfield, and the rest of the characters reflect the data value (note that is case sensitive). Only the first subfield is compared. If matched, the other subfields are not extracted. If not matched, the field is extracted as it is in Aleph. This mapping is used for fields known for having only one single subfield. Only data-fields can be mapped here. Not in use for control fields. The # sign can be used as a wildcard for all subfields, Indicator1, and Indicator2 of the input field. CAT fields are NOT supported.

For example:

Col D - OWN###,MYLIBRARY col E 991 a

If there is a BIB record that contains the following filed: OWN a MYLIBRARY

This bibliographic record will be migrated to Alma : 991 a MYLIBRARY

Additionally, as with any non-standard alphanumeric field, the OWN may be mapped to 9XX. This presumes that the alphanumeric non-standard field has only one subfield. If the non-standard field has more than one subfield, do not use the migration mapping for these fields.

Suppress Hol Tab

If you have other STA fields in Aleph which indicate that the HOL record should be suppressed (in addition to STA=SUPPRESSED), please denote them here

Default: No default

Options: Optional. Optional. Col. D - Alpha Fields. Col. E- content of the Alpha Fields (Column E).

Further Information: Use this mapping in order to migrate the holdings as suppressed (this is in addition to the STA=SUPPRESSED cases that are automatically migrated to Alma as suppressed). Col. D should include your Aleph fields that are letters only (not numbers). Insert in Col E the string to be matched for suppressing the bibliographic record.

For example:

Col. D - STA , Col. E- CIRC-CREATED.

The STA field SUPPRESSED is handled automatically and is stored as a tag related to the Hol record in Alma. The STA field DELETED should be mapped as suppressed, so that it is suppressed.

Item Material Type Tab

Map your Z30 item material types to one of Alma's acceptable item material type values

Default: No default

Options: Optional. Select from a fixed input list based on your data (column D) and map it by using the fixed input list based on Alma's fixed acceptable values (Column E).

Further Information: Map Z30-MATERIAL to a valid Alma item material type. See information about Alma-acceptable material types. Migration attempts to preserve the four Aleph materials types to their equivalent in Alma: BOOK, ISSBD, ISSUE, and CDROM.

Item Arrival Status Tab

List your Z30 item process statuses which indicate that an item or issue has not yet arrived

Default: No default

Options: Optional. Select from a fixed input list based on your data (column D). An item with a process status listed here is not assigned a receiving date.

Further Information: Items with process statuses in Aleph are assumed to be not in place in Alma and TECHNICAL status is assigned to them. If you set the process status in this tab, the Item is assigned TECHNICAL status, but the item itself will not be received.

Item Process Status Type

List the item process status type which indicates if an item is not in process.

Default: No default

Options: Optional. Select from a fixed input list based on your data (column D). If a process status type is listed in this tab, an item with this process status type is not assigned in Alma with the TECHNICAL process status type .

Further Information: Items with process status types in Aleph are assigned the TECHNICAL process status type in Alma. You may use this to list the item's process status types that should be ignored, so the item will be considered in place in Alma. Note that the Item Arrival Status tab might reflect the opposite of this tab, but not necessarily, so if a process status type is defined in the Item Arrival Status tab, it cannot be assigned here.

Physical to Electronic

Physical to Electronic (P2E) Processing Overview

Process and Goal

One of Alma’s goals is unification. In order to do so, a certain amount of re-categorization of Aleph-originated records that are not actually physical in nature needs to be done. Identifying these will allow us to start this unification process:

Categorizing records correctly as electronic inventory in Alma and setting their associated orders as Electronic rather than Physical.
This is achieved by:
1. Receiving an input file with the relevant Aleph system numbers representing electronic resources and their types (portfolio, package, or database).
2. Receiving input in migration form for relevant sublibrary, collection and item material types which allow sub-identification within the list received in step 1.
3. Migration processing identifying the lowest inventory level matching the input provided in step 1 and step 2 – as well as any related order - and converts those records to electronic.
The converted electronic resource may contain linking information usually populated based on the originating holding record’s 856 $u field or the originating Bib record’s 856$u field. Note that for every BIB in the p2e file, an electronic resource is created, even if a link is not available.
The converted electronic resource may contain a field which describes the vendor name/provider – if so, this can also be provided as additional input in the migration form.
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. The active and most recent order will be associated to the related Electronic Inventory. For order types mapping, see Order Types.

P2E File

Provide a file representing the Aleph BIB system numbers for records containing electronic resources. Indicate if any of these system numbers represent e-packages or e-databases.

Following is the file structure (where X is a character and N is a number):

XXX0NNNNNNNNNN,<type>

XXX0N – the bibliographic Aleph library.

NNNNNNNNNNN – the Aleph system number.

The type can be: Portfolio or DB

This file serves as the input for making the appropriate electronic identifications /determinations when migrating these records to Alma as E inventory rather than P inventory.

During the P2E process, all resources must either be categorized as a portfolio or a database (DB). It is not possible to generate packages during P2E processing, since packages require at least one portfolio. A database is essentially a zero-title package. Post migration, when you add portfolios to the db, you can change them to type 'package'.

E libraries and location indication codes (Provide sub-library and optionally collection/location codes of that sub-library). These are used to identify such inventory as electronic rather than physical during the migration processing within the BIB identifiers provided – for instance when an electronic and physical record are represented by one bibliographic record. For cases where all collections of a specific library are needed – indicate in column E with an asterisk.
E item material types (Provide Z30 item material types which provide indication that a resource is electronic).
Where the link is stored for e-access in the Holdings or Bib record (e.g. 856$ u – default)
Where the vendor/provider name is stored in the Holdings or BIB record (e.g. 856 $m

For example:

If you provided the following input file:

ABC01000002001,Portfolio

ABC01000002005,Portfolio

ABC01000004066,DB

And, designated the following in the migration form:

Sublibrary = ONLIN

Collection = <empty/>

Item Material Type = <empty/>

We check if each Bib has any items in the following sublibrary:collection pattern ABC:ONLINE – if it does, we designate each item matched with that pattern for conversion to a portfolio – we also check if any order is associated and convert the order to electronic as well. When there is more than one order, the most recent and active order will be assigned to the e-resource inventory. The output portfolio will attain the linking information from either the 856 $u of the holdings record or the 856 $u field of the bibliographic record. If migration process identifies all of the bibliographic record’s items with that pattern, it automatically removes the remnant holdings record, too.

If there were no items matched to that sublibary:collection pattern or no items existed at all for that Bib id– we’d move on to its holdings and check the Holdings 852 $b and $c against the sublibrary:collection pattern. A match would be converted to portfolio as described in the item scenario.

If no match or no holdings exist, we would set the Bib level for conversion. In that case, we simply leave the Bib in place, create a new e-inventory record (based on the type provided in the input file) and populate the linking and vendor/provider information based on the migration form input.

The logic for DB is identical to portfolios, only in those cases the inventory type output and related order types would be a different type, as in Alma databases and their orders have different functional behavior than portfolios/stand-alones.

Managing duplication:
Since most MarcIT records (based on the existence of 035$a with a starting field content of (SFX)) are not migrated from Aleph (unless order information is associated – as described above), much of the SFX<>Aleph duplication for serial records is eliminated.

However, inevitably, when moving from a multi-system environment to a uniform and consolidated environment there will remain some duplicates.

The approach being taken to manage the remaining inventory duplication is the following:
- Ensure the end-user discovery experience is not affected by any remaining duplication. This is achieved by preferring Community Zone versions of resources for linking over an Aleph version of the same resource and relying on Primo’s robust de-duplication algorithm.
- Ensure no data loss by making sure the relevant order/back-office information, which is generally managed in Aleph, remains. The result will mean that the Community Zone version is the master for linking/delivery/discovery and the Aleph version for back-office tracking and management.
- Offer functions for ongoing purposes that will allow manual (and in the future automatic) back-office cleanup. For now, this should include the ability to remove order or license linkages from the duplicate e-inventory record from Aleph, delete the duplicate Aleph e-resource and re-add the order/license linkages to the “master” Community Zone version.
Identify E resources for ERM enrichment (when relevant based on your scope agreement with Ex Libris):
- License association based on ERM
- Enriching resources with key localized administrative and access information based on ERM
- Enriching order information based on ERM
- Access Interface and Vendor associations based on ERM

This step is dependent on your agreement with Ex Libris and which ERM you are using. Contact your Ex Libris project manager with any questions. Also refer to Electronic Resource Handling in Alma Migration.

Mapping 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: 85641$u – only tags with 41 as the indicator is used.
No indicator (# or a space, 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.

If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator which does not match the specific indicator in the question P2E_LINK, below. For example, if you say that we use 85641$u for the P2E_LINK, and you provide a bib record *without* a 85641$u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource). Be careful which bibs are placed in the P2E file.

Which field (Holdings or Bib field) is used for linking in the electronic records

Default: 856 $u

Options: Provide a 3 digit MARC field code + subfield: 856$u. Only one subfield is allowed (Column D). Note that for every BIB in the p2e file, an electronic resource is created, even if a link is not available.

Which field (Holdings or Bib field) is used for determining the vendor/provider

Default: 856 $m

Options: Provide a 3 digit Marc field code + subfield: 856$m. Only one subfield is allowed (Column D).

Which field (Holdings or Bib field) is used for determining an electronic access note

Default: 856 $z

Options: Provide a 3 digit Marc field code + subfield: 856$z. Only one subfield is allowed. (Column D).

P2E-Libs_Cols Tab

List the sublibraries and locations for where the electronic resources are stored. (Note: For all collections of a specific sublibrary, please fill in column E with asterisk)

Default: No default

Options: Mandatory –select a sublibrary from the fixed input list based on your data (Column D).

Select the relevant collection from the fixed input list based on your data (Column E).

This tab also determines whether a BIB record with electronic Link Resolver holdings or items is skipped. If you do not map any library or collection in P2E-Libs_Cols tabs, items under Link Resolver records are assumed to be electronic and are therefore skipped.

P2E-ItemMT Tab

List the item material types which designate that an item is an electronic resource, if applicable.

Default: No default

Options: List the item material types which designate that an item is an electronic resource, if applicable (Column D). If any material type is listed in this tab, an electronic item will only be considered electronic if it is in one of the sublibraries/collections listed in the P2E-Libs_Cols tab AND matches one of the codes in this list. If this tab is left empty, any item in the sublibraries/collections listed in the P2E-Libs_Cols tab will be considered electronic regardless of its material type.

Fulfillment

Overview

Patron Migration Rules

Alma Structure

The main patron structure in Aleph is based on the Global Patron Information (Z303), the Local Patron Information (Z305 – partially ready for first and second migration releases in Alma), the Patron Address (Z304), and the Patron ID (Z308) entities. The following diagram represents the migrated patron structure according to the Alma patron design:

Mapping Rules and Assumptions

Preferred email, address and phone number: In Alma, the patron address and phone number used by the system are defined by marking these entities as preferred. The migration from Aleph to Alma is performed as follows:

In Aleph, there is a function that returns the active type for addresses and related phone numbers. The migration process retrieves this address and marks it as the preferred address and phone number. Since in Alma only one phone number can be marked as preferred, the migration marks the relevant phone number from the Z304-TELEPHONE field as preferred (not for Z304-TELEPHONE-2 to 4).

The email, address, and phone number types are set as follows by the migration:

All Aleph Z304 e-mails are migrated to personal (Please note: All email addresses are scrubbed to ensure real emails do not get sent to patrons in implementation testing.) Patron emails will be unscrubbed upon Go-Live.
All Aleph Z304 addresses are migrated to home
All Aleph Z304 phone numbers are migrated to home

To keep the information previously held in Aleph, the textual description (col.3) under the USER_ADDRESS_TYPE section in pc_tab_exp_field.lng is copied to the note of the Alma address record. If the entry is not present in the Aleph table, the numeric value in the Z304-ADDRESS-TYPE field will be migrated to the note attribute.

Patron address information: In Aleph, there are no dedicated fields such as state, city and country. This information is held as part of the address general information and currently migrated as such to Alma. This is due to the fact that in Aleph this information is held in a free format and cannot be identified in order to migrate it to the Alma dedicated fields.

Patron status: This implies the overall status of the patron as to whether they are active or inactive In Aleph, there is no analogous status. For this reason, all migrated patrons are set as Active in Alma. This is not to be confused with the Aleph patron status which is being migrated to the Alma user group.

Patron Group: The Aleph Z305-BOR-STATUS is mapped to the Alma user group. The corresponding BOR-STATUS in pc_tab_exp_field_extended.lng or pc_tab_exp_field.eng is migrated to the user group code table in Alma.

A patron can only have one patron group in Alma.The migration process will migrate the patron group according to the local record on the ADM/Aleph level. Make sure this record has the correct patron group.

Borrower Type: The Aleph Z305-BOR-TYPE is mapped to Alma’s user statistics. The corresponding BOR-TYPE in pc_tab_exp_field_extended.lng or pc_tab_exp_field.eng is migrated to the user statistical category code table in Alma.

Patron SMS data: In Alma, only one SMS number can be defined. If there is more than one Z304-SMS-NUMBER, only the one stored at the level of the address record returned as preferred is migrated. The Alma mobile number will be marked as preferred SMS if the flag Z303_WANT_SMS is set to 'Y'.This is needed only if SMS communication is used. Note that it can also be updated by the SIS loader if that's relevant.

Patron name: In Aleph, both the patron’s first and last name are stored in a single field, Z303-NAME. In Alma, this information is stored in separate dedicated fields. The migration questionnaire contains a question regarding the structure used for patron names. The following information is required: the positioning of the last and first name and a delimiter between them. For example:

First: Last name first
Delimiter: comma
Last: First name after the comma.

Based on this, the migration maps the Aleph information (last name and then first name) to the dedicated field in Alma.

If this positioning cannot be provided or the site does not have a clear pattern for storing the patron names, the migration stores the information from the Z303-NAME field, as is, under Last Name in Alma.

Type: The migration sets the patron account type to external by default. That is, patrons are handled externally and loaded into Alma. In this case, the core patron information (for example, user name) will be managed outside of Alma and will not be editable through the Alma interface (though, additional information may be added as locally managed for this patron in Alma). Accordingly, the verification information from the IDs (Z308-VERIFICATION) is not migrated. It is possible, based on Z305-BOR-STATUS, to identify specific patrons (such as community borrowers or alumni) as internal types which means they will be managed only within Alma and not updated via the student information system.

Patron title: Z303_TITLE is set to be the patron's title

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

Patron Identifiers: The migration program allows additional types of user identifiers, migrated from the Z308 table. One of these identifier types should be selected as the primary ID – the primary unique identifier that the patron uses to authenticate via Primo. Users use the primary ID as the match point with an external authentication system.

The identifier selected as the primary ID 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 duplicate instances, the first one found for each patron is written and the subsequent ones are not written.

Note that all passwords are managed outside of Alma. For more information regarding password management, refer to the Developer's Network.

Patron expiration date: The expiryDate is migrated to the patron’s core user record.

Patron ILL Library: The patron’s Ill library is migrated to the patron's notes.

Proxy Patron: The Aleph Z303-PROXY-FOR-ID is mapped to proxy. When a loan is performed, the loan may be done by a proxy for a sponsor. In this case, the item loan is connected to the sponsor user and a Borrowed by proxy note is added. The Z303-PROXY-ID-TYPE is migrated as note.

Patron delinquency: Z303/5_delinq_1-3 fields are migrated as user blocks. In addition, an overdue block will be created in Alma if Z305_END_BLOCK_DATE is populated with a future valid date.

Shared User Patron Architecture: For Multi-ADM customers that share users (z303), it is possible to migrate patrons by their z305. If Z305 is only defined as an ALEPH to the extracted ADM (it cannot be associated by sub-library/ADM) and the Z303_HOME_LIBRARY is empty, the patron will be migrated.

Aleph patrons representing ILL organizations and their related active circulation activity are migrated as standard users and activity. After moving to Alma, it is recommended that all new ILL activity leverage Alma's Resource sharing workflows and infrastructure, while phasing out existing ILL patrons as their active circulation activity eventually completes.

Areas/Fields Not In Scope

Patron Budget (Z303-BUDGET)
Patron Profile ID (Z303-PROFILE-ID)
Place of Birth (Z303-BIRTHPLACE)
Data Export Consent (Z303-EXPORT-CONSENT)
Title Request Limit (Z303-TITLE-REQ-LIMIT)
Patron Loader Protected Fields (Z303-PLIF-MODIFICATION)
Registration Date (Z305-REGISTRATION-DATE)
ID verification information (Z308-VERIFICATION)
ILL-related ILL Total Limit (Z303-ILL-TOTAL-LIMIT), and ILL Active Limit (Z303-ILL-ACTIVE-LIMIT)
Patron privileges/permissions, such as Photocopy Request, Hold Request, Renewal, and so forth (will be managed via configuration loader of fulfillment policies)
Dispatch Library (Z303-DISPATCH-LIBRARY)
Send All Letters to Patron (Z303-SEND-ALL-LETTERS)
Mail Attachment (Z303-PLAIN-HTML)
Patron Home Library (Z303-HOME-LIBRARY) – however, for multi-ADM libraries, this is used to determine the correct institution association in Alma
Staff permissions and passwords (Z66/Z67)

Fines and Fees (Cash) Migration Rules

Alma Structure

Unlike in Aleph, where each transaction is reflected by a Z31 record, in Alma there is a distinction between the main cash record (fine) and the transactions attached to it. The following diagram represents the migrated cash structure according to the Alma fines and fees design related to patrons:

Mapping Rules and Assumptions

Partial transactions: For cases such as partial payment and partial waive, only the active owed/paid sum is migrated. These means that partial transactions are not recorded as such and only the active sum is migrated. For example, if a patron owes 100 dollars due to a fine in Aleph and has performed two separate partial payments in Aleph each of 20 dollars, only the active 60 dollars that is still owed is migrated to Alma.
Only Open fines and fees (z31-status) are migrated.

Types of fines and fees: If the Fine Fee is in Credit (Z31-CREDIT-DEBIT = 'C') the type is set to Credit. If it is not, the type is set by fine and fee types which are stored in Aleph in the Z31-TYPE field. Aleph values that match the Alma out-of-the-box values are migrated to the new Alma values. All other values are migrated to Other. The information stored in the Z31-DESCRIPTION field, which is migrated to the transaction comments, will enable the user to understand the origin of the migrated fine and fee. Information has been added to link the user fee to originating loan and item. The following table contains the mapping used during the migration:

Fines and Fees Mapping
Aleph Cash Transactions	Aleph Description	Aleph Fine and Fee Type
0000	General	Other
0001 , 0006, 0007and 0009	Photocopy request	Photocopy service
0003	Late return	Overdue Fine
0005	Renewal	Renew Fee
0008	Photocopy request home delivery	Document Delivery Service
0010	Claim return	Claim Return Fee
0011, 0015 and 0016	ILL request, ILL material arrival and Incoming ILL request	Resource Sharing Fee
0017	Issuing library card	Issue Library Card
0021	Borrower registration	Patron Registration
0022	Borrower renewal	Card Renewal
0023	New user	New User Fee
0040 and 42	Lost material – Handling	Lost Item Process Fee
0041	Lost material – Replacement	Lost Item Replacement Fee
0050	Recall late return fine	Recalled Overdue Fine
9997	Damaged material	Damaged Item Fine
0080	1st warning - Overdue	Overdue Notification Fine
0081	2nd warning - Overdue	Overdue Notification Fine
0082	3rd warning - Overdue	Overdue Notification Fine
0083	4th warning - Overdue	Overdue Notification Fine
0085	5th warning - Overdue	Overdue Notification Fine
0090	Overdue summary letter	Overdue Notification Fine
From 9000 and onwards + any other value not contained in this table (for example, 0002 or 0011)	User defined/no parallel in Alma (for example, 0002 – Hold request)	Other

Fine/Fee relation to loan and item: The connection from the fine/fee to the original item is made as part of the migration. The open fines and fees are not linked to their original loan transaction, since historical loan transactions are not migrated – only active loans are migrated.

Areas/Fields Not In Scope

Transfer information (Z31-TRANSFER-DEPARTMENT, Z31-RECALL-TRANSFER-STATUS, Z31-RECALL-TRANSFER-DATE, and Z31-RECALL-TRANSFER-NUMBER)
Payment information related to the following fields are currently not in scope: Z31-PAYMENT-CATALOGER, Z31-PAYMENT-TARGET, Z31-PAYMENT-IP, Z31-PAYMENT-RECEIPT-NUMBER, Z31-PAYMENT-MODE, and Z31-PAYMENT-IDENTIFIER.

Loan Migration Rules

Alma Structure

In Alma, item loans are qualified by a loan status (Active or Inactive).

The loan structure in Aleph is based on Z36 (Active loan records): the active loan record is deleted from the Z36 table when an item is returned. Completed loan transactions are stored in Z36H (Loans history) and are not included in the migration to Alma. However, the Z36H table is provided in an Excel report at the time of the final load migration to Alma.

Based on this structure, the migration creates an Item Loan line with the Active loan status for each active Aleph loan (Z36).

ILL loans are migrated as regular loans to Alma. On Cutover, you should stop Aleph activities except for fulfillment. If there are new ILL items after the cataloging freeze, they are not migrated and on fulfillment cutover the loans are rejected. In this, case when a loan is rejected due to missing items in Alma (Statistic report), check the Aleph loan. If it is an ILL item created after cutover, you have to manually add the item and its loan to Alma.

The reading room item, loan records (z310), is not in the migration scope. Usually these records have an associated loan in z36 (loans) that is migrated. The item's Internal note 2 field is populated with Reading Room when the ADM record has an R30 field.

Mapping Rules and Assumptions

In Alma, the status of the loaned item is populated based on various conditions set in the Aleph loan status (Z36_STATUS), recall date (Z36_RECALL_DATE), and number of renewals (Z36_NO_RENEWAL).

Historical loan information is not migrated to Alma, but is provided as a csv report at cutover to Alma.

Areas/Fields Not In Scope

Z36-MATERIAL
Z36-EFFECTIVE-DUE-DATE
Z36-RETURNED-DATE
Z36-RETURNED-HOUR
Z36-ITEM-STATUS
Z36-BOR-STATUS
Z36-RETURN-CATALOGER-NAME
Z36-RETURN-CATALOGER-IP
Z36-NO-RENEWAL
Z36-RENEW-CATALOGER-NAME
Z36-RENEW-CATALOGER-IP
Z36-RENEW-MODE
Z36-BOR-TYPE
Z36-NOTE-ALPHA
36-RECALL-DATE
Z36-LAST-RENEW-DATE
Z36-PROCESS-STATUS
Z36-LOAN-TYPE
Z36-RECALL-TYPE

Overdue notices:

Z36-LETTER-NUMBER
Z36-LETTER-DATE

Circulation desk:

Z36-LOAN-CATALOGER-IP

Proxy patron ID:

Z36-PROXY-ID

Booking requests:

Z36-RETURN-LOCATION
Z36-RETURN-SUB-LOCATION
Z36-SOURCE
Z36-DELIVERY-TIME
Z36-TAIL-TIME

Hold Request (on hold-shelf) Migration Rules

Alma Structure

Patron level requests in Alma are managed only at the BIB/Title level before being processed. Once on the hold-shelf, they are tied to a specific item/barcode and patron.

Mapping Rules and Assumptions

The hold requests that are already tied to a specific item and are on a hold shelf (or were in transit on their way to a specific library/hold shelf and are assumed to be on the hold shelf) are the ones that are migrated (Z37_STATUS=’S’)

Requests that have not yet been processed are not in the migration scope. However, such unprocessed requests are provided in a csv report at cutover that library staff can use to either contact patrons so that they can recreate the hold request in Alma or manually recreate the requests themselves for the patrons manually in Alma.

Areas/Fields Not In Scope

All requests which have not been filled.
Request history
Z37-EXPAND
Z37-OPEN-HOUR
Z37-END-REQUEST-DATE
Z37-LETTER-STATUS
Z37-LETTER-DATE
Z37-ALPHA
Z37-PRINT-STATUS
Z37-REQUESTER-ID
Z37-CATALOGER-IP
Z37-HOLD-SEQUENCE
Z37-RECALL-TYPE
Z37-RUSH-REQUEST
Z37-FILTER-SUB-LIBRARY
Z37-FILTER-ITEM-STATUS
Z37-FILTER-PROCESS-STATUS
Z37-FILTER-COLLECTION
Z37-FILTER-COPY
Z37-ENUMERATION-A
Z37-ENUMERATION-B
Z37-ENUMERATION-C
Z37-CHRONOLOGICAL-I
Z37-CHRONOLOGICAL-J
Z37-CHRONOLOGICAL-K
Z37-REQUEST-NUMBER
Z37-GROUP-ID
Z37-GROUP-SEQUENCE
Z37-BALANCER-STATUS
Z37-BALANCER-DATE
Z37-REQUEST-IDENTIFIER

Course Reserve Migration Rules

Alma Structure

Courses in Alma group together one or more reading lists that list the BIB/Title level resources that are part of that reading list. Each course may be associated with a course department. Each course may have an optional section definition. There are no shared reading lists in Alma, although resources/titles may be part of more than one reading list and BIBS that reference a shared reading list in Aleph will migrate those course references to each reading list.

Mapping Rules and Assumptions

Each distinct Z108 course code will become an individual course. Optionally, section information may be deduced based on the migration input.
Each distinct Z108 course code will also become a reading list and associate with its relevant course.
Each BIB citation from the XXX3X library will reference its relevant reading list. Shared citations will associate with all reading lists that relate to the course.
The Bibs in each relevant XXX3X library are migrated based on migration input. Items related to XXX3X are migrated by default to be suppressed from publish, unless you answered otherwise (N) in the Migration Form Questionnaire.
Some course and reading list information will be migrated to the course and reading list notes: instructor, term, etc.

Instructor in Aleph is a free text field, whereas in Alma it is a named user. Therefore, no match can be determined and the instructor information is migrated to a note of the course and reading list.

Areas/Fields Not In Scope

Z108-COURSE-NAME-KEY
Z108-INSTRUCTOR-NAME-KEY
Z108-DEPARTMENT-KEY
Z108-UNIT-KEY

Mapping Input

Questionnaire Tab

C. Patrons

Which identification number key (from tab_bor_id) should be used as the patron’s Primary ID definition?

Default: No default

Options: Mandatory. Col D - Select from the fixed input list based on your tab_bor_id accepted values.

Further Information: Provide the primary identification type (Z308_key_type) that is usually used by the patrons when logging into Primo/discovery (for example, type 02). All patrons must use the same identifier type as the primary ID. If the identifier type is empty for a particular patron, the migration program creates a primary ID for the patron based on the patron identifier (z308_ID), prefixed with ID. The migration program does not fill in the primary identifier with a non-selected identifier. See also Patron Identifiers in the Further Explanation – Fulfillment section.

Aleph stores patron first name and last name in one field. In Alma, they are stored in two fields. Do you use a separator that can allow these to be split automatically?

Default: No default

Options: Optional. Col D – a string including F,L and a delimiter between the F and L. (A space is not considered a delimiter/separator).

Further Information: Provide the structure used for the storage of the Aleph patron names (Z303-NAME). Since Aleph stores the name in one field and Alma stores first and last name in two fields, the following information can be supplied so that Alma can split the name into two fields: Place a delimiter between the last and first names within the Z303-NAME field. For example:

For data such as: Smith, John, provide: L,F

For data such as: John|Smith, provide: F|L

If no input is provided or data does not adhere to the structure indicated, the default is to use the Z303-NAME and map the entire contents to LAST NAME and leave the FIRST NAME blank

Do you want Patron's Home Library and ILL Information to be migrated as User notes?

Default: All

Options: Optional Col D. All/None/Z303_HOME_LIBRARY only.

Further Information: The following Z303 fields are migrated as user notes and not to their comparable Alma field: Z303_HOME_LIBRARY, Z303_ILL_LIBRARY, Z303_ILL_TOTAL_LIMIT, and Z303_ILL_ACTIVE_LIMIT. You can either choose to migrate all the fields, none of them, or only the Z303_HOME_LIBRARY field.

Extract patrons to your institution also by the existence of Z305-SUB-LIBRARY?

Default: N

Options: Optional Col D. Y/N

Further Information: Relevant for customers who have a Shared Patron library and want the patrons to be extracted when a z305 exists in their ADM (Z305-SUB-LIBRARY). Set this parameter to Y. If the extracted ADM has a Z303 record without an associated Z305 record, the Z303 record is not migrated.

For a Z305 with ALEPH, if there is no other Z305 record associated with the extracted ADM, the patron is extracted if the Z303_HOME_LIBRARY is empty.

Populate the Alma User's Preferred Name with Z303-SALUTATION??

Default: N

Options: Optional Col D- a string including F,L and a delimiter between the F and L. (A space is not considered a delimiter/separator).

Further Information: If you have stored the preferred patron’s name in the salutation Aleph field and you want to migrate it, indicate the form of the string and how it should be parsed. To separate the field to "Preferred First name" and "Preferred Last name", use the following pattern: L to indicate the last name, F for first name, and a separator of 1 character between them. For example: L,F or F|L. If you do not have a separator, use only L or F.

F. Courses

Please list the course libraries you manage courses

Default: No default

Options: Mandatory if migrating courses. Course library XXX3X.

Further Information: Indicate from which XXX3X libraries to migrate bibliographic records. If you filled in this question, make sure to indicate the XXX3X library in section B. (List the BIB libraries you wish to migrate?)

Do you want the migrated Course BIBs to be suppressed in Alma?

Default: N

Options: Optional. Y/N

Further Information: Course library bibliographic records, by default, are migrated as not suppressed to Alma.

Do you manage a course section within your course code (Z108_REC_KEY)? If so, what delimiter do you use?

Default: No default

Options: Optional.

Further Information: Provide the structure used for the Aleph course code (Z108-REC-KEY). Since Aleph does not maintain a course section number separately from the course code itself, the positioning of the course’s section code can reside in the Z108-REC-KEY. For example:

Course Code
Delimiter: period/pipe/comma
Section

If no input is provided or data does not adhere to the structure indicated, the course code is populated with then entire course code portion of the Z108-REC-KEY.

If you would like your course Bibs optionally tagged with a 9XX field and default value, please set the field code here otherwise leave blank.

Default: No default

Options: Optional

Further Information: Used to extract bibliographic records related to course libraries with an additional local 9XX field with a default fixed value. The relevant list of course libraries is set by the COURSE LIBS flag. If this field is not set, or no course libraries are set, no additional field is extracted to the courses’ bibliographic records. This is most commonly used if there is a need to easily identify a course’s bibliographic records to potentially restrict their being viewed via Primo.

For example:

COURSE-BIB-TAG 987 CR_RESTRICTED

The XML of every bibliographic record related to a course library contains:

<subfield code="a">CR_RESTRICTED>

</datafield>

Would you like all of the courses to be also separated by their sequence (Z108-COURSE-SEQUENCE)?

Default: N

Options: Optional

Further Information: There are libraries that manage the same courses by different departments/instructors and want to continue managing them separately in Alma. If you want to create for each entry in the z108 Aleph table a corresponding course in Alma answer Y

Patron Group Tab

Which bor status/es are used to indicate that a patron is internally managed and not externally managed by a student information system?

Default: No default

Options: Optional. Col D - Select from the fixed input list based on your bor statuses

Further Information: Provide the BOR-STATUS (Alma patron group) to indicate that a user is one of the minority internally managed users (for example, community borrowers and alumni) and not managed in the external user management (not providing an indication implies that the user information is managed externally). This indication applies to any patron belonging to that BOR-STATUS and these users will not be updateable from the student information system and instead are managed within Alma only.

Acquisitions

Overview

Vendor Migration Rules

Alma Structure

The main vendor structure in Aleph is based on the Vendor Information (Z70), Vendor Address (Z72), and the related permitted library/ordering unit entities (Z602). The following diagram represents the migrated vendor structure according to the Alma vendor design which contains a hierarchical structure whereby vendors contain one or more accounts:

Mapping Rules and Assumptions

Vendor details and vendor account: In Alma, general vendor details, such as vendor code and name, are held in the vendor details entity, while account information is held in a separate entity (Vendor Account). Aleph performs the migration as follows:

A Vendor Account record is created for each Aleph account: Account No. (M), Account No. (S), and Vendor’s Bank Account. Since in Aleph, the related account information, such as added charge or discount values, is relevant for all of the above account numbers, the Alma account information is duplicated for each. If the Aleph fields contain duplicate information, one Alma vendor account is created per unique Aleph account information.
To retain the source information regarding the accounts usage, the migration sets the description field of the Alma account as follows:
- For Account No. (M), the description contains Account (M).
- For Account No. (S), the description contains Account (S).
- If both Account No. (M) and Account No. (S) are the same, one account is created and the description contains Account (M/S).
- For the Vendor’s Bank Account, the description contains General Account.
In Alma, each vendor has at least one vendor account defined. If there is no information in the Aleph account fields, the vendor account is created with the account code set to the vendor code. In this case, the description contains Default Account.

Contact information: Aleph vendor contact information (Contact 1 -5) is migrated to Notes related to the vendor.

Vendor status: Aleph vendor statuses are all migrated to Alma as Active, except for NA, which is migrated to the status Inactive.

Vendor currency: Alma requires at least one currency for the vendor. If no currency was found in Aleph, the currency for the migrated Alma vendor contains the Aleph local currency defined for the local_currency parameter in the aleph_start file.

Two-level vendor record: Each vendor in Aleph is migrated as a vendor or as an account into Alma when the TWO-LEVEL-VENDOR flag in the data_tab/tab100 table is set to Y. If the vendor record is identified as the parent it creates a new vendor. If it is identified as a 'child' it creates a new vendor account in the parent vendor record. The accounts are created in a manner similar to the description above, but with the addition of the sublibrary defined in the Z70_rec_key.

Shared Vendor: If you are migrating a multi-ADM with shared vendors to Alma as a consortium, each of the ADMs (migrated as an institution) are extracted with all the vendors in z70. There is a difference in the extracted vendor account. The two level accounts are associated by their z70_rec_key to the relevant IZ (according to tab_sub_library.lng). All of the vendors include, in addition, a default vendor account containing the vendor code.

Vendor payment method: In Alma, the vendor record must have at least one payment method defined. During the migration, the method is set as the default for Accounting department.

Account level expected receiving interval: The Z70 delivery delay 1 will determine the receiving interval for that vendor account in Alma when ordering material from that vendor/vendor account.

EDI-related information, such as Vendor EDI Code, Vendor EDI Type, and Vendor Address of Type EDI (type 5). Note: All ftp addresses are scrubbed to ensure real EDI does not get sent to vendors during implementation testing. These will be unscrubbed upon Go-Live to Alma.

Emails: All vendor email addresses are scrubbed to ensure real emails do not get sent to vendors in implementation testing.

Ordering units: Ordering units are treated by the migration as regular Alma libraries (sublibraries). It is additionally recommended to consolidate them into existing libraries by using the order unit >sub-library mapping input as noted above. Relationships can be determined in Alma configuration to set the relevant libraries those libraries (formerly ordering units) serve.

Areas/Fields Not In Scope

Vendor Country (Z70-COUNTRY). In Alma the country information is held as part of the addresses only (this information is migrated from the Aleph Z72-VENDOR-COUNTRY field).
Vendor Material Type (Z70-MATERIAL-TYPE)
Vendor Delivery (Z70-DELIVERY-TYPE-n)
Vendor Delivery Delay (Z70-DELIVERY-DELAY-2 – 5)
Vendor Order Delivery (Z70-DEFAULT-ORDER-DELIVERY)
Templates and letters including: Z70-LE-LETTER-TYPE and Z70-LI-LETTER-TYPE. This includes send method details. The following fields will not currently be migrated: Z70-LE-SEND-METHOD and Z70-LI-SEND-METHOD.
Vendor type (Z70-PROVIDER-TYPE). This information is not migrated to Alma; however, for Aleph versions higher than 18, the vendor is not migrated if the type is ILL.

Budget (Fund) Migration Rules

Alma Structure

Basic fund information is stored in Aleph in the Budgets (Z76) table and the related permitted library/ordering unit entities (Z602). The permitted libraries/ordering units are used for determining the fund's availability for certain libraries.

The following diagram represents the migrated budget structure according to Alma’s funds design:

Mapping Rules and Assumptions

Fiscal period and funds: In Alma, funds are related to a fiscal period. The first step in the budget migration from Aleph to Alma is to determine the fiscal period association for each budget managed in Aleph based on the pattern cycle. This is done by (1) retrieving the Z76_BUDGET_NUMBER, which for most budgets that are annually rolled over includes the year in the suffix format. For every YYYY retrieved, a fiscal period for that year is created.

If Z76_BUDGET_NUMBER does not have the –YYYY suffix, it is linked to an existing fiscal period based on the year of its Z76-VALID-DATE-TO. If that year was not created (for example, future fiscal year2099), the budget is linked/associated to the maximum annual YYYY fiscal period created based on the –YYYY suffix. If the budget code does not have a numeric suffix -YYYY (for example, ABC or ABC-abcd), the suffix -FUND is added to the budget in Alma to avoid duplications in the budget codes.

Budget currency: In Alma, budgets require a currency. Since in Aleph, budgets are not directly related to currencies, the migration sets this currency according to the local currency defined for the institution.

Funds and ledgers: In Aleph, there is no parallel to the Alma ledger structure that is required for Alma fund management. The ledger groups a number of funds according to the fiscal period. The ledger record also points to the currency, which in Alma is common to the group of funds under the ledger. The detailed ledger information is created as follows by the migration:

After creating fiscal periods, the same logic is used per budget to associate it with its fiscal period – one LEDGER per fiscal period (GENERAL_LEDGER) which will sometimes be split into multiple ledgers for the same fiscal year if there are hierarchical grandparent funds (see below regarding grandparent fund structures). The status – Active or Inactive – is set according to the status of the matching fiscal period.

All ledgers and funds must be owned at the institution level for migration purposes.

Funds and hierarchy: Hierarchically structured parent record budgets in Aleph can have transactions related to them. Since this does not suit the Alma model, in this case, the hierarchy will not be kept and the parent budget will be migrated to a standard allocated fund, as shown in the diagram below:

In more common cases in which the parent fund is not an allocated fund, the migration to Alma is performed as shown in the following diagram:

Budget hierarchy and fiscal periods: When there is a mismatch between the parent and child budget based on their dates, the migration does not break the hierarchy, as it is deemed to be the primary consideration, but rather keeps the hierarchy intact while transferring the fiscal period assigned by the highest level in the hierarchy (parent budget) to the child budget.

There are two cases of mismatch:

The from-to period of the child budget is longer than that of its parent budget. In this case, the Alma grace period fields are calculated in order to reflect the actual dates of the child budget. This means that the number of extra days is calculated and migrated to the Alma dedicated grace period fields.
The from-to period of the child budget is shorter than that of its parent budget. In this case, the reduced number of days is calculated and the information is migrated to the Alma dedicated grace period fields as a negative value in order to reflect the actual usage date without breaking the hierarchy.

Budget hierarchy and grandparent budgets: The Aleph system supports grandparent budgets. In this case the migration is performed as follows:

If both the parent and the grandparent records do not have allocations, the migration removes that grandparent budget and its children/ related summary fund/s and allocated funds from the core fiscal period GENERAL_LEDGER, and instead create the grandparent fund as its own ledger named by the grandparent budget’s Z76_BUDGET_NUMBER same fiscal period.
If both the grandparent and the parent funds have any allocations in Z601, both budget records are migrated as standard allocated budgets under the core fiscal period GENERAL ledger and the hierarchy is lost:
If the grandparent fund has allocations but the parent fund does not, the grandparent fund is migrated as an allocated budget and the parent will be a summary fund at the same level:
If the parent fund has allocations but the grandparent does not, the parent is migrated as an allocated budget of the grandparent which should be set as a ledger:

Over-encumbrance: In Alma, over-encumbrance values are always given in percent, while in Aleph both percent and absolute options are available. If the Z76-SW-ABSOLUTE-PERCENT is set to A (absolute), the over-encumbrance (Z76-MAX-OVER-COMMITTED) is calculated and transferred to percent. This is calculated out of the estimated budget balance. The calculation is based on the following transaction types: initial allocation, allocation, carry over and transfer.

Over-expenditure: In Alma, over-expenditure values are always given in absolute numbers, while in Aleph both percent and absolute options are available. If the Z76-SW-ABSOLUTE-PERCENT is set to P (percent), the over-expenditure (Z76-MAX-OVER-EXPENDITURE) is calculated and transferred to an absolute value. The calculation is based on the following transaction types: initial allocation, allocation, carry over and transfer.

Budget notes handling (Z76-NOTE-1 - Z76-NOTE-4) are mapped to fund notes.

Areas/Fields Not In Scope

Budget Department (Z76-DEPARTMENT)
Annual Budget check box information (Z76-ANNUAL). All Alma funds are annually managed.
Budget Group (Z76-SUB-KEY-1 – 5 – Reporting groups)

Fund Transactions Migration Rules

Alma Structure

Basic fund transaction information is stored in Aleph in the Budget Transactions (Z601) table. The following diagram represents the migrated fund transactions structure according to Alma’s design:

Mapping Rules and Assumptions

Initial and regular allocations: In Aleph there is a distinction between regular allocations and initial allocations. This distinction does not exist in Alma and all allocations are migrated to the type ALLOCATION. The first allocation transaction is the initial allocation.
Carry-over transactions: CRO transactions (carry-overs) are migrated to the transaction type ALLOCATION. The Note field is set to CARRY-OVER to indicate this.
Encumbrance transactions: Aleph ENC transactions are migrated as Alma encumbrance transactions. When expended upon, they are paired with a generated Alma DISENCUMBRANCE transaction. The amounts for any disencumbrance transaction are the result of subtracting the Z601-ACTVE-SUM from the Z601-ORIGINAL-SUM. Encumbrance transactions are linked to orders. Only the most recent encumbrance transaction will be retained for orders (Encumbrances associated to the same order, only the most recent is migrated to Alma).
Encumbrances Transactions of amount 0.00: If the transaction sum is zero and its related order is a Gift or Deposit, the transaction does not migrate to Alma. If the transaction sum is zero and its related order is NOT Gift or Deposit, the transaction amount is changed to 1.00.
Expenditures: Expenditure transactions are migrated and are linked to invoice lines and may be linked to order lines.
Object Codes: These are mapped to Alma reporting codes that match fund transactions and are associated with related invoice lines and their analogous expenditure transactions in Alma. Optionally, encumbrance transactions and their related order lines may be linked with reporting codes as well (based on mapping the Z68 order material type to an object code, which is mapped to an Alma reporting code via the Aleph Migration Form).
Payment status: This information, stored in the Z601-PAID field of INV (invoice) transactions, is not taken directly from the Aleph transaction record. The information regarding the payment status is taken from the Aleph invoice record and stored in the parallel Alma invoice details entity. See the Invoice/Invoice line Migration Rules section for more information.
VAT amount: In Aleph, this value is provided in the original currency of the transaction. The local amount does not include the VAT. If the currency of the transaction is not the local currency, the value in the Aleph VAT field is mapped to the Alma foreign VAT amount and the local amount is calculated based on the Z601-CURRENCY-RATIO for the local Alma VAT amount.

In order to avoid any currency exchange rate-related discrepancies between Aleph budgets and Alma funds, it is recommended to run the Aleph Update Local Price of Budget Transaction (acq-08) service before migration.

Areas/Fields Not In Scope

All areas/fields are migrated for the Aleph budget transactions.

Purchase Order Migration Rules

Alma Structure

The main purchase order structure in Aleph is based on the Z68 (Order) table. In Alma, all orders (PO line/s) are grouped into a PO (purchase order). In Aleph, there may be one (or more) orders per bibliographic record. Based on this structure, the migration creates a PO and a PO line for each Aleph order (Z68) and enriches the order with any Z16 subscription linked to it.

In addition, subscriptions from Aleph's Z16 (subscriptions) with no order reference and still active will be migrated as basic Alma orders since subscriptions are implemented as orders in Alma. It is recommended that Z16 active subscriptions are linked to Z68 orders prior to migration in Aleph as not doing so will yield Alma orders which, although will be waiting for renewal status upon migration, will require additional manual handling post-migration in order to continue working with those orders (for instance requiring adding mandatory funding and copies information which isn't managed on the Z16-level in Aleph, but is mandatory in Alma).

Mapping Rules and Assumptions

Vendor account algorithm: In Alma, the PO contains the vendor account together with the order details. Since Aleph does not have this information at the order level, the vendor account is populated using the most relevant existing vendor account (for example, trying to match serial orders with serial vendor accounts and monograph with monographic vendor accounts, if defined). Details for vendors can be found under Mapping Rules and Assumptions in the Vendor Migration Rules section.
Order types: Three order type outputs are created from Aleph orders– all are assumed initially to be for Physical material (until the electronic identification processing ensues as part of the end-to-end migration processing):
- One-time monographic orders
- Journal subscriptions (continuous)
- Monographic standing orders (continuous)
  When P inventory is identified as E inventory, related orders are automatically adjusted to the E equivalents for each order noted, as part of the migration processing.
- One-time monographic orders: Orders of type ‘M’ are linked to items in Alma.
- Journal subscriptions (ongoing): Orders of type ‘S’ (subscriptions). Subscription orders are linked to holdings records in Alma.
- Subscriptions with no orders: Aleph subscriptions (Z16) not linked to any purchase order (Z68) record will be converted to physical subscription orders in Alma.
- Monographic standing orders: Orders of type ‘O’ are not linked to inventory, but are related to a “series” Bibliographic record. Each receipt based on the order will generally represent a new Bibliographic record and inventory for that series.
Old order handling: As part of the input to the migration, it can be set to automatically close/clean older orders which have had no recent activity or received items in order not to overload the Alma active order task lists with non-active orders. See the Close purchase orders that are NEW and older than x months and Close ongoing purchase orders that are SENT and older than x months questions on the Questionnaire Tab.

Order statuses: The Aleph order status populates the Alma PO status and PO line status. Since the setting of the order status in Alma can be changed after the order is in Alma, the table below includes the Alma Entry Point:

Aleph Code	Aleph Description	Alma Entry Point
NEW	New	NEW
WP	Waiting for Processing	NEW
PS	Processing started	NEW
WB	Need budget confirmation	NEW
QSV	Query before sending	NEW
CNB	Cancelled - no budget	CANCELLED
DNB	Delayed, no budget	NEW
RSV	Ready to send to vendor	NEW
SV	Sent to vendor	SENT
VC	Vendor cancelled	CANCELLED
LC	Library cancelled	CANCELLED
REJ	Rejected	CANCELLED
RET	Returned	CANCELLED
CLS	Order closed	CLOSED
ONW	OPAC new order	NEW

It is possible to map your current statuses that are not standard to one of the aforementioned statuses. See Local Order Status Tab.

Object codes/reporting codes: As noted in the fund transaction migration, object codes may be applied via optional mapping for encumbrance orders based on the Z68 acquisition material type.
Funding information: The fund association to orders is based on encumbrance transactions.
Additional order no. 2: This is migrated as a note attached to the purchase order.
Order group: Order group is migrated as a note, attached to the purchase order.
Arrival status (Z68-ARRIVAL-STATUS) - This information will come from the item inventory relationship to the order.
Interested Users – This information is populated by Z68-TARGET-ID or Z16-ID.
Order Locations - Aleph orders (Z68) have no locations (only z68_sub_library) unless it is connected to an item. So, if there is no linked item, then the expected receiving location for the order maps as UNASSIGNED.

Acquisition Method Mapping – The Alma ACQ method of the purchase order line is populated by the Z68-METHOD-OF-ACQUISITION from Aleph. The following table describes the basic mapping if the mapping is not indicated in the migration form:

Aleph Code	Aleph Description	Alma Acquisition Method
P, PF	Purchase /Purchase free	PURCHASE
G	Gift	GIFT
A	Approval	APPROVAL
D	Depository item	DEPOSITORY
E	Purchased for exchange	EXCHANGE
Other Aleph Method		VENDOR_SYSTEM
For subscription records (Z16) not linked to any order		TECHNICAL

Alma does not allow a zero amount for an order unless it is defined as Z68-METHOD-OF-AQUISITION = "G" or "D" or if the ACQ method is mapped in the Migration Form to GIFT/DEPOSITORY/LEGAL_DEPOSIT. If the amount is zero and the ACQ method is not mapped to GIFT/DEPOSITORY/LEGAL_DEPOSIT, the order amount is changed to 1.00.

Areas/Fields Not In Scope

Letter type (Z68-LETTER-TYPE)
Order delivery type (Z68-ORDER-DELIVERY-TYPE)
Send letter by (Z68-SEND-METHOD)
Initiator ID (Z68-TARGET-ID)
Initiator name (Z68-TARGET-TEXT)
Action (Z68-TARGET-FLAG)
Batch claiming (Z68-AUTO-CLAIM)
Status date (Z68-ORDER-STATUS-DATE)
Original claim date (Z68-ORIGINAL-EDA)
Unit price (Z68-UNIT-PRICE)
Total price (Z68-TOTAL-PRICE)
List price (Z68-E-LISTED-PRICE)
Local price (Z68-E-LOCAL-PRICE)
Z68-ERM-TYPE
Z68-ERM-ID
Z20 or any other Aleph claim information
Z71 (Order, subscription and Invoice Log)
Z18 (Routing List)

Invoice/Invoice line Migration Rules

Alma Structure

In Alma invoices are described by invoice_details (mandatory) and invoice_lines (not mandatory).

The invoice structure in Aleph is based on Z77 records (Invoice header or general invoice) and Z75 records (invoice payment or line item).

There may be Z77 records without related Z75 records, but a Z75 record must have an associated Z77 record. Connection between Z77 and Z75 records is a match between VENDOR-CODE and INVOICE-NUMBER fields available in both record types.

Based on this structure, the migration creates:

One Alma Invoice for each Aleph invoice header (Z77) : Aleph invoice headers without attached invoice line item should not be migrated
One Alma Invoice Line for each Aleph invoice line item (Z75) matching an invoice header (Z77).
Invoice migration ensures the total invoice amounts are correct, not necessarily the net breakdowns.

Mapping Rules and Assumptions

Invoice lines may be linked for payment to particular orders
Aleph invoice headers with empty Z77-P-STATUS and Z77-I-DATE equals to 0 are not migrated to Alma
Aleph Z77 records and Z75 records with Z77-CREDIT-DEBIT and Z75-CREDIT-DEBIT equal to ‘C’ (credit invoices) are migrated with negative prices
In Alma, Payment Status and Invoice Status elements of the Invoice Details are populated based on various conditions set on Aleph invoice payment status, dates (invoice date, invoice payment date), approval department and notes. The total price of both the invoice as a whole and each line are the price details passed from Aleph to Alma.
Migrated invoice statuses in Alma include New/In Review, Sent for payment and Closed/Paid
Subscription details - starting and ending date of the subscription coverage period (Z75-I-DATE-FROM, Z75-I-DATE-TO.
Z77-I-TYPE is mapped to the Alma Payment Method field. Mapping Z77-I-TYPE to the payment method is provided by the customer when filling in the Aleph to Alma migration form (INV-PAY-METHOD parameter). If the Z77-I-TYPE of the invoice is not mapped, the field is set to ACCOUNTINGDEPARTMENT by default. The following values are valid for this field:
VAT is included in the total invoice amount. VAT details are mapped to Alma invoice and invoice lines notes (Z77_VAT_CODE, Z77_VAT_AMOUNT, 77_VAT_RECEIVER, Z75_VAT_CODE, and Z75_VAT_AMOUNT).
- ACCOUNTINGDEPARTMENT
- CASH
- CREDITCARD
- BANKTRANSFERS
- DEPOSITACCOUNT)
- PREPAYMENT
- SPECIALPAYMENT
- ATTACHMENT

Invoices with a payment status other than Paid

If you generally did not include the payment status of the invoice in Aleph, it is highly recommended that you update the relevant payment statuses for all invoices before migration. Invoices with a payment status other than Paid migrate to Alma with InReview status. Having large amounts of invoices with this status makes it difficult to manage the workflow of invoices in Alma.

Areas/Fields Not In Scope

Invoice header:

Z77-CREDIT-DEBIT
Z77-I-CURRENCY-RATIO
Z77-I-REC-DATE
Z77-I-SHIP-DATE
Z77-I-NO-ITEMS
Z77-I-NET-AMOUNT (Net amount of invoice)
Z77-I-SHIP-AMOUNT (Added charges)
Z77-I-OVER-AMOUNT (Added charges)
Z77-I-INSU-AMOUNT (Added charges)
Z77-I-DISC-AMOUNT (Amount discounted)

Invoice line:

Z75-DOC-NUMBER
Z75-SEQUENCE
Z75-VENDOR-CODE
Z75-INVOICE-NUMBER
Z75-I-CREDIT-DEBIT
Z75-I-DATE-RANGE
Z75-I-NET-AMOUNT

Mapping Input

Questionnaire Tab

D. Purchase Orders

If you order centrally in your institution and all purchase orders should be owned/managed by one library, please indicate that library

Default: No default

Options: Optional – Select a sub-library from the input list, based on your sublibrary codes (column D).

Further Information: Providing a sub-library ensures that all orders are associated with this library in Alma. When this question is answered, all the funds are available at the institution level..

Close purchase orders that are NEW and older than x months

Default: 500

Options: Mandatory. Number of months to be decreased from the running date (Column D)

Further Information: The migration processing allows you to close purchase orders that have been inactive for a period of time, such as new orders and those older than x months. This may be useful for closing old orders that were never processed or were otherwise never updated in Aleph. This is useful since the Alma task list shows all orders in each status – as opposed to Aleph where the task list is only based on searches and these records may have not been noticed until now. If you do not want any purchase orders closed, set a high number, for example – 500. Edit here the number of months to be decreased from the running date.

Close ongoing purchase orders that are SENT and older than x months?

Default: 500

Options: Mandatory. Number of months to be decreased from the running date ( Column D)

Further Information: The migration processing allows you to close purchase orders that have been inactive for a period of time, such as Sent to Vendor ("SV") that are older than x months.

The assumption is that they were either received or will never be received. If you do not want any purchase orders closed, set a high number, for example – 500.

We recommend setting the value to 500 in order not to close ongoing orders that should stay open.

What is your Acquisition arrival status code used to indicate complete arrival?

Default: C

Options: Mandatory – any code that may be defined in ACQ_ARRIVAL_STATUS indicating a complete arrival (column D)

Further Information: Provide the acquisition arrival status code used to indicate complete arrival.

The order in Alma will be set to ACQ-ARRIVAL-STATUS, with an indication of fully arrived, if it is in "Sent to Vendor" status (Z68-ORDER-STATUS = "SV") and it is a Monograph Order (Z68-ORDER-TYPE = "M")

Indicate the date that a purchase order with no renewal date should be renewed (yyyymmdd).

Default: Current date + 1 year

Options: Optional – yyyymmdd format (column D)

Further Information: Provide the date that your library renews its orders. This is to set a renewal date for orders that are missing the renewal date.

E. Funds

Fiscal Period Cycle Pattern (DD-MM-C)

Default: No default

Options: Mandatory– DD-MM-C (Day-Month-Cycle).

Further Information: Provide the Fiscal period cycle pattern used by the institution: DD-MM-C (Day-Month-Cycle)

For instance, a one year fiscal period starting July 1 and ending June 30: 1-7-1

The cycle must equal 1. This is an Alma functional requirement that fiscal years be one year.

In your budget codes, a YYYY suffix may be used for yearly rollover purposes. Please indicate your active/maximum '-YYYY' value stored in the Aleph budget codes for annual cycle-managed budgets?

Default: No default

Options: Mandatory. Select a year (YYYY) from fixed input list.

Further Information: Should be in YYYY format. This represents the maximum fiscal year in use in the Aleph budget codes. For instance for BUDGET-CODE, if the most future code is BUDGET-CODE-2014, the answer here is 2014.

What year (YYYY) does your active annual fiscal year/budget cycle end?

Default: No default

Options: Mandatory. Select a year (YYYY) from fixed input list.

Further Information: This represents the maximum fiscal year (the year that the maximum fiscal year ends) that is created in Alma. In most cases, the answer here is the same as the previous answer for active/maximum '-YYYY' value stored in the Aleph budget codes for annual cycle-managed budgets. The only case in which the YYYY answer is different than the previous answer is in the following case:

The typical accounting standard has the fiscal year being indicative of the end year of the fiscal year, not the start year. In other words, typically FY-14 indicates that the fiscal year ends in 2014. Some specific sites indicate FY-14 as the fiscal year starting in 2014 and ending in 2015. To accommodate this scenario, set this field to the current/maximum year +1. Note that in this case, the active fiscal year created in Alma is named FY-15. This can be changed in Alma by updating the Fiscal Periods mapping table.

When your budgets are named according to the year in which they end:
AABBCC-2014 is related to the 2014 fiscal year which ends in 2014

Answer YYYY = 2014
When your budgets are named according to the year in which they start:
AABBCC-2014 is related to the fiscal year that ends in 2015

Answer YYYY+1 = 2015

For customers that are not migrating ACQ or have old fiscal budgets, this definition together with the definition of the fiscal period cycle pattern is used to create an active fiscal period in Alma.

What is your local currency used in Aleph Acquisitions transactions?

Default: No default

Options: Mandatory. Select your local currency from the list.

Further Information: Select the three letter code in column D representing the local currency used in Aleph Acquisitions transactions. If you used a non-ISO code in Aleph, select it from the list here, and map it to the ISO code in the Local Currency tab.

Please indicate a suffix to be added to fund codes

Default: No default

Options: Optional.

Further Information: Use this definition when combining several Aleph ADM Libraries into one Alma Institution. If defined, a suffix is added to distinguish between two identical fund codes coming from two different ADM Libraries. The same suffix is added to all funds related to the ADM extracted.

Ordering Units Tab

If you use ordering units, it is strongly recommended, but not required, that each ordering unit code be mapped to a standard library (sub-library) code in Alma.

Default: No default

Options: Optional - Select ordering unit codes from a fixed input list, based on your data (column D), and map to it a sub-library from a fixed input list, based on your data (column E)

Further Information: Ordering units are currently treated by the migration as regular libraries (sublibraries). Relationships can be determined in Alma configuration to set the relevant libraries these ordering units serve. This mapping enables us to migrate your ordering units by their associated sub-libraries.

If an ordering unit is not mapped here, it is used as is and becomes an Alma library, like all other Alma libraries.

Local Currency Tab

Please list any non-standard ISO currencies you may manage for your orders and fund transactions and the standard ISO currency they should map to, if relevant.

Default: No default

Options: Optional - Select your non-ISO currency from a fixed input list, based on your data (col D), and map it to a standard ISO currency (col E)

Further Information: If your site does not work with ISO 4217 currency codes, map the code used in Aleph to the appropriate ISO currency code. This is currently applicable for both vendor and fund currency related information. Empty currencies map to your default currency. For empty currencies that need to map to a different currency other than the default, fill in column D with <empty> and column E with an appropriate 3-letter ISO currency code.</empty>

For example:

Col D: <empty> Col E: AUD</empty>

Local Order Status Tab

Please list any non-standard or local order statuses and which status you'd like to migrate them to

Default: Unrecognized order statuses = CLOSED

Options: Optional – Select the status from a fixed input list, based on your Z68-ORDER-STATUS (col D), and map it (Column E).

Further Information: If your site has modified or added to the out-of–the-box Aleph order statuses, provide the mapping to the available Alma order status options. Provide a mapping for all the Z68-ORDER-STATUS as appear in the DB if it is not one of the following: "NEW","WP","PS","WB","QSV","RSV","ONW","CNB","VC","LC","REJ","RET","DNB","SV","CLS".

The corresponding values to be used in Alma are: "CLOSED","NEW","CANCELLED", "RECEIVED","SENT","WAITING_FOR_INVOICE".

Order Type Tab

You may optionally map to certain of Alma's POL types based on Z68-ORDER-TYPE and Z68-MATERIAL-TYPE

Default: M = PRINTED_BOOK_OT, O = PRINT_SO and S = PRINTED_JOURNAL_CO

Options: Optional - Column D indicate the Z68-ORDER-TYPE code (M S or O) followed by a comma followed by your local Z68-MATERIAL-TYPE and one of the valid values for the POL type in Alma. The combination outputs in Column E.

Further Information: It is possible to combine your order type and order material type to achieve different Alma order types. You can combine the Z68-ORDER-TYPE code (M S or O), followed by comma, followed by your local Z68-MATERIAL-TYPE, and one of the valid values for the POL type in Alma. The combination outputs in Column E. Enter all combinations when using this mapping or the default values are applied.

By default: M = PRINTED_BOOK_OT, O = PRINT_SO, S = PRINTED_JOURNAL_CO. To map M S or O, when there is no Z68-MATERIAL-TYPE, add a comma (,) in col D after M/S/O. for example: Col D = O, Col E = PRINTED_BOOK_OT
The following order types behave like serials and receive like serials: PRINT_CO, PRINT_SO_NONMON
The following order types behave like one time orders and receive like one time orders: PRINTED_BOOK_OT,PRINT_OT
The following order types behave like monographic series standing orders and do not receive via Alma's receiving workbench: PRINTED_BOOK_SO, PRINT_SO
PRINTED_JOURNAL_CO stands for 'Print Journal - Subscription'. Use for journal subscriptions. A continuous order may be received and invoiced on many times; it remains open until actively closed. A continuous order is attached to a holding record.
PRINTED_JOURNAL_OT - stands for 'Print Journal - One Time'. One time purchase of a physical journal issue.
The following order types are intended for one time and ongoing services - not related to inventory: OTHER_SERVICES_OT,OTHER_SERVICES_CO

If you plan to report on encumbrances, you can optionally define a map between your Aleph order ACQ material types and your object codes.

The Z68-MATERIAL-TYPE isn’t mapped directly to the Alma order material type. In Alma, the order material type is used as the default material type to apply to items when they are first ordered. From then on, it has no function.
Each order type has an analogous electronic type if the order is determined to be electronic via the P2E process. Refer to Alma > Migration > Electronic > Electronic Resource Handling in Alma for more details.

Order Reporting Tab

If you plan to report on encumbrances, you may optionally define a map between your Aleph order ACQ material type codes to your Object codes.

Default: No default

Options: Optional – Select the material type from the fixed input list based on your data (Column D) and map it by the fixed input list of related object codes based on your data ( Column E).

Further Information: Map the existing distinct order material type values Z68-MATERIAL-TYPE to the OBJECT_CODE of the respective material-type. These values are used as the order reporting codes.

Only relevant for sites needing reporting on encumbrances in Alma and that are using both Aleph order material types and Aleph object codes.

Acquisition Method Tab

Map the values from Z68_method_of_acquisition to one of Alma's supported acquisition method types. (Any value not mapped is mapped using the default settings).

Default: VENDOR_SYSTEM

Options: Optional – Select the method from a fixed input list based on your Z68-METHOD-OF-ACQUISITION table (col D), and map it to the Alma fixed list (Column E).

Further Information: For an empty Z68_method_of_acquisition table, fill in column D with <Empty> and column E with the appropriate Alma value.

Invoice Payment Method Tab

You may optionally map the invoice payment method to use on Alma invoices based on Aleph's ACQ_INVOICE_TYPE in pc_tab_exp_field.lng

Default: ACCOUNTINGDEPARTMENT

Options: Optional – select Acq Inv Type code from the fixed input list based on your data (Column D), and map it to one of Alma's listed invoice payment methods in (Column E).

Further Information: Map your Z77-I-TYPE to one of the Alma payment methods.

If Z77-I-TYPE of the invoice is not matched, it is set to ACCOUNTINGDEPARTMENT.

ADAM Digital Materials

Overview

ADAM migrations include the core digital metadata fields stored in Aleph's Z403 table as well as their related file streams stored locally in Aleph. The file streams that were stored in Aleph are moved to the Alma-supported digital storage solution, contingent on your library's Alma contractual agreement with Ex Libris.

The migration outcome in Alma is a digital representation for each file stream or for groups of files (depending on the migration form configuration), whereby the digital representation is associated with its migrated bibliographic record from Aleph.

Mapping Input

Questionnaire Tab

Adam Bib library

Default: No Default

Options: Mandatory if migrating ADAM.

Further Information: (Col D.) Indicates the bibliographic library that is used for ADAM digital asset management. If ADAM is not in use, leave these cells empty.

What should be the default library (Aleph sublibrary) for your digital materials?

Default: No Default

Options: Mandatory if migrating ADAM.

Further Information: Provide default sublibrary code in column D to be applied for digital inventory in Alma.

Do you want to extract Items and Holdings related to Bibs with digital objects?

Default: Y

Options: Optional

Further Information: Indicates if you have maintained digital items and holdings in addition to Adam objects in Aleph and you would like to extract them as well. In certain cases it might create duplication in Alma.

Do you want to group files to one representation?

Default: N

Options: Optional. Indicate N to give each file its own representation. Indicate Y to group files of the same bibliographic record under one representation.

Further Information: Alma enables grouping digital files into one representation and viewing the files in one editor. The grouping is done for all files under the same bibliographic record having the same file type (extension). If you have Aleph digital data, it should be closely reviewed before deciding which approach to choose.

Appendix A – Post-Migration Process Statuses

The process statuses (the codes) from Aleph 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, the 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 batch 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.

Appendix B – Optional Use of Aleph Fix Routines During Migration

Aleph’s fix routines may be set up and invoked (for bibliographic libraries and/or holdings libraries) and used during migration. This is useful if more sophisticated field update option are needed when migrating to Alma.

For example:

In your Aleph library’s $data_tab/tab_fix:

tab_fix:URM fix_doc_do_file_08 fix_alma_bib

And a fix routine using Aleph standard fix syntax under $data_tab/import, with the name listed as a parameter in $data_tab/tab_fix:

fix_alma_bib

This may be useful when requiring certain non-standard Marc fields to adhere to Marc standards better.

It can also be used for instance, to generate and instantiate summary holdings statements for serial holdings in case they are not already present (in addition to the item-level description and enum/chron info from the item records which are automatically mapped from Aleph). That is, 866$a (Public note) from Holdings records, when present, is displayed in the GetIt services menu and offered to patrons. It is, therefore, optionally possible to use 866$a in Holdings records with an appropriate description that reflects the item-level descriptions, where necessary. This would be additional general information displayed to end users beyond the item-specific description and specific enum/chronology information. Sites might consider the option to expand z30 description into holdings field 866$a, in case it is not already populated, via Aleph's expand_doc_hol_z30_86x expand routine in conjunction with the migration routines.

Fix routines as pre-processes may impact the running time of the extract, depending on the amount of data and the specific fix routines. This should be taken into consideration when applying the fix routines. It is recommended to run data changes prior to testload/cutover and not as part of the extract.

Appendix C – Aleph to Alma LKR Mapping

The following table describes the Aleph to Alma LKR mapping:

Aleph to Alma LKR Mapping
Aleph Source Field	Aleph Source Subfield	Aleph Source Field Content	Alma Target
LKR	a	UP	77318 (When $r does not exist or is not in the range of MARC linking fields)
LKR	b,l	DocNO,LibCode	77318$wMMS-ID or (MarcOrgCode)BibNOBibCode In special cases, instead of MMSID, the Aleph system number with the format as described in question 4 (What is your MARC standard organization code for 035 $a setting the original Aleph system number?).
LKR	n	UpLinkNote	77318$t
LKR	y	Year	77318$g yr:
LKR	v	Volume#	77318$g no:
LKR	p	Part	77318$g pt:
LKR	i	Issue #	77318$g iss:
LKR	k	Pages	77318$g p:
LKR	r		77318$4
LKR	a	PAR	77518 (When $r does not exist or is not in the range of MARC linking fields)
LKR	b,l	DocNO,LibCode	77518$ wMMS-ID or (MarcOrgCode)BibNOLibCode In special cases, instead of MMSID, the Aleph system number with the format as described in question 4 (What is your MARC standard organization code for 035 $a setting the original Aleph system number?).
LKR	n	Note	77518$n
LKR	y	Year	77518$g yr:
LKR	v	Volume#	77518$g no:
LKR	p	Part	77518$g pt:
LKR	i	Issue #	77518$g iss:
LKR	k	Pages	77518$g p:
LKR	r		77518$4
LKR	a	ITM	77318 (When $r does not exist or is not in the range of MARC linking fields)
LKR	b,l	AdmNO,AdmLib	77318$ wMMS-ID or (MarcOrgCode)BibNOLibCode In special cases, instead of MMSID, the Aleph system number with the format as described in question 4 (What is your MARC standard organization code for 035 $a setting the original Aleph system number?).
LKR	n	Note	77318$t
LKR	y	Year	77318$g yr:
LKR	v	Volume#	77318$g no:
LKR	p	Part	77318$g pt:
LKR	i	Issue #	77318$g iss:
LKR	k	Pages	77318$g p:
LKR	r		77318$4
LKR	a	ANA	77318 (When $r does not exist or is not in the range of MARC linking fields)
LKR	b,l	DocNO,LibCode	77318$w(MarcOrgCode)BibNOLibCode* In special cases, instead of MMSID, the Aleph system number with the format as described in question 4 (What is your MARC standard organization code for 035 $a setting the original Aleph system number?).
LKR	n	Note	77318$t
LKR	y	Year	77318$g yr:
LKR	v	Volume#	77318$g no:
LKR	p	Part	77318$g pt:
LKR	i	Issue #	77318$g iss:
LKR	k	Pages	77318$g p:
LKR	r		77318$4
LKR	a	DN	77418 (When $r does not exist or is not in the range of MARC linking fields)
LKR	b,l	DocNO,LibCode	77418$ wMMS-ID or (MarcOrgCode)BibNOLibCode In special cases, instead of MMSID, the Aleph system number with the format as described in question 4 (What is your MARC standard organization code for 035 $a setting the original Aleph system number?).
LKR	m	Note	77418$t
LKR	y	Year	77418$g yr:
LKR	v	Volume#	77418$g no:
LKR	p	Part	77418$g pt:
LKR	i	Issue #	77418$g iss:
LKR	k	Pages	77418$g p:
LKR	r		77418$4

Appendix D - Preparing for migration

Customers may wish to clean up their data prior to or during the migration process. The following recommendations are not mandatory.

1. Standardize statuses, such as item status, patron status, etc. Remove obsolete statuses, consolidate statuses to fewer options, if relevant. Standardizing the codes and reducing them into fewer options will help with mapping to Alma codes and creating configuration in Alma.

2. Sublibraries and collections. Consolidate and/or remove non-active sublibraries and collections. See recommendations in Aleph Sublibraries and Aleph Collections.

3. Review non-standard MARC fields (alphanumeric, for instance). See the 9XX Bib Tab.

4. Holdings and Items

Identify and correct any location mismatches between holdings and item records. Location of the items in Alma will be determined by the holding record. Any location on the item level will be lost.
Identify and correct any faulty temporary location on the item level. This is especially important if the temporary and permanent locations are not the same and the temporary location should be the permanent one. This situation can also be corrected in Alma in bulk if the call number does not need to change.
Assign a value for empty collection/location for items/holdings, if applicable. Location information in Alma is mandatory. Any physical inventory without location is assigned to a default location called in Alma UNASSIGNED. Having large percentage of the catalog in UNASSIGNED location will be difficult to maintain in Alma.

5. Patron information

Patron group: A patron can only have one patron group in Alma. See Patron Group section in the patron Mapping Rules and Assumptions.
Mobile/SMS: if you use SMS to send messages to patrons, review the Patron SMS data section in the patron Mapping Rules and Assumptions.

6. Invoice payment status: See Invoices with payment status other than Paid

7. ADAM: For institutions with ADAM migration: fix records that do not have a 245/title or it is duplicated. This is important when the Bibliographic data for the digital records is not according to the MARC standard. Records without 245/title (or it is duplicated) will be rejected by the process that loads the digital data. Thus, the digital object will not migrate to Alma.

Related Documentation

Recommendations for Using this Guide

General

Mapping Input

Questionnaire Tab

A. General

Specify the ADM Library you are migrating

Have you contracted with Ex Libris to migrate Acquisitions data?

What is your regional time zone?

Please specify your institution ID (as determined by the Ex Libris Migration Team)

Please specify your Institution Code (as determined by Ex Libris Migration Team).

Inventory

Overview

Alma Structure

Mapping Rules and Assumptions

Areas/Fields Not In Scope

Mapping Input

Questionnaire Tab

B. Inventory

List the BIB libraries you wish to migrate?

Call number subfields for matching items without holdings (Default is bc and recommended)

What is your Marc standard organization code for 035 $a setting the original Aleph system number?

When the original system number is built for Bib records, should it include an -Aleph suffix? E.g. (orgCode)002030401-ABC01-Aleph

What textual marking in 035 |a indicates that your records are copies of Link resolver records. Default: SFX

Do you use your Aleph system number in subfield w of Marc Bib linked entry fields 760-787 and 80X-83X?

If you use the item secondary call number, do you prefer this field go to the Item call number field in Alma or the storage location id in Alma (used for remote storage sequential/box numbering). Default is item call number and recommended.

Library is a mandatory field in Alma. What default sublibrary code should be applied in case no sublibrary or 852| b holdings value is defined in Aleph?

Would you like all of your Z30-PRICE data used in Alma as the item's replacement cost?

Which field (Holdings or Bib field) is used for linking in the electronic records?

Which field (Holdings or Bib field) is used for determining the vendor/provider name of the electronic resource?

Which field (Holdings or Bib field) is used for determining an electronic access note?

List your special MARC type BIB libraries (that have no definition in tab100.MARC-TYPE)

Do you want the Aleph prediction pattern to be migrated to Alma?

Do you work with "Schedule" functionality in Aleph?

Do you want the cataloger's level of the bibliographic record to be migrated?

Indicate LKR fields (mapped to linking fields) as local?

Do you want that a generated holding, will contain a call number (852$h) populated from its item?

9XX Bib Tab

Which standard 9XX Marc bibliographic field should your Bibliographic non-standard Alpha numeric fields be mapped to?

Suppress Bib Tab

If you have other Alpha fields in Aleph which indicate that the BIB record should be suppressed (in addition to STA=SUPPRESSED), please denote them here

9xx Hol Tab

Which standard 9XX Marc holdings field should your non-standard Alpha numeric Holdings fields be mapped to?

Suppress Hol Tab

If you have other STA fields in Aleph which indicate that the HOL record should be suppressed (in addition to STA=SUPPRESSED), please denote them here

Item Material Type Tab

Map your Z30 item material types to one of Alma's acceptable item material type values

Item Arrival Status Tab

List your Z30 item process statuses which indicate that an item or issue has not yet arrived

Item Process Status Type

Physical to Electronic

Physical to Electronic (P2E) Processing Overview

Process and Goal

P2E File

Mapping Input

Questionnaire Tab

Which field (Holdings or Bib field) is used for linking in the electronic records

Which field (Holdings or Bib field) is used for determining the vendor/provider

Which field (Holdings or Bib field) is used for determining an electronic access note

P2E-Libs_Cols Tab

List the sublibraries and locations for where the electronic resources are stored. (Note: For all collections of a specific sublibrary, please fill in column E with asterisk)

P2E-ItemMT Tab

List the item material types which designate that an item is an electronic resource, if applicable.

Fulfillment

Overview

Patron Migration Rules

Alma Structure

Mapping Rules and Assumptions

Areas/Fields Not In Scope

Fines and Fees (Cash) Migration Rules

Alma Structure

Mapping Rules and Assumptions

Areas/Fields Not In Scope

Loan Migration Rules

Alma Structure

Mapping Rules and Assumptions

Areas/Fields Not In Scope

Hold Request (on hold-shelf) Migration Rules

Alma Structure

Mapping Rules and Assumptions