This document is intended to be used together with the Aleph Migration Form - an Excel spreadsheet that collects available mapping preferences and is read by the migration programs. The form is initially generated by the AutoExtract package.

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

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

Recommendations for Using this Guide

This document is divided into the following areas:

General

Inventory

Fulfillment

Acquisitions

Physical to Electronic

Each area has the following sections:

Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.

Individual Tabs – Instructions for how to fill out individual tabs on the Migration Form. (Examples: Alma Library Tab, User Group Tab, PO Line Type Tab).

Further Explanation – Explanations of migration processes that need more explanation and/or do not need mapping input.

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

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

General

Mapping Input

Questionnaire Tab

A. General

Specify the ADM Library you are migrating

Default: N/A

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.

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: N/A

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.

Inventory

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

Mapping Input

Questionnaire Tab

B. Inventory

List the BIB libraries you wish to migrate?

Default: N/A

Options: This question is mandatory.

Further Information: Provide the list of Aleph bibliographic libraries which should migrate. All denoted bibliographic libraries will be 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.

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

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.

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’s alternative call number (or an item note if the item had a different alternative 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 alternative call number (or an item note if the item had a different alternative 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?

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.

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. It is possible to skip these records in conjunction with this flag indication. When there are Aleph holdings or items related to these bibliographic records, the records are not skipped. 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 Alternative call number field in Alma or the storage location id in Alma (used for remote storage sequential/box numbering). Default is alternative call number and recommended.

Default: alternativeCallNumber

Options: storageLocationID, alternativeCallNumber

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?

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.

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 KORMARC BIB libraries

Default: N

Options: If you are a KORMARC user, this question is mandatory.

Further Information: Only for KORMARC users, abc01, abc03 with comma separation in column D. Bib libraries only, for example: xxx01-xxx09. This determines the KORMARC 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.

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

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

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 fields DELETED and SUPPRESSED are handled automatically and are stored as a tag related to the bibliographic records record in Alma.

9xx Hol Tab

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

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

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.

STA fields. DELETED and SUPPRESSED are handled automatically and are stored as a tag related to the Bib record in Alma.

Item Material Type Tab

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: N/A

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 Explanation – Inventory

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 taken from the definitions in the tab_sub_library.lng and the information in the tab_sub_library_address.lng tables, where the sublibrary definition type is 1, 4, and 5. (Type 5 is migrated as is, unless it is mapped. For more information, refer to the Ordering Units Tab).

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:

Mapping ordering units (type 5) to real libraries

Combining rarely used sub-libraries into other existing sub-libraries. To determine how many items there are in each sublibrary, run the following SQL query:

> > 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 same 852 $$b field as their items library, check the number of holdings records of the ADM library as well, by performing the following:

Run p_ret_01 in XXX60 without parameters in order to retrieve all records.

Run p_print_03 (print only 852 field in Aleph sequential format).

Filter the output file. This can be done in Excel:

Select Data > From Text and select the file.

Define the field separator to be $$.

Add a header column to the data.

Filter the data using the header columns.

Analyze your data by comparing the sub-libraries in the holding records against the sub-libraries defined in tab_sub_library.lng.

Contact your Ex Libris representative for further explanations and recommendations.

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:

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.

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, except in the following case:

Items are linked to an HOL record, but the X852-ITEM-OVERRIDE variable in the ADM library is set to N or is not defined.

When X852-ITEM-OVERRIDE is set to N, the HOL call number will be the Permanent Call Number and the item call number will be set as the Alternative Call Number. If the item has an alternative call number it will be set as a Note.

In the above case, the link between the items and the HOL record is 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.

Aleph depository ID (Z30-DEPOSITORY-ID) is also used as a physical location, when present, overriding the Aleph collection.

Secondary call numbers are migrated and may be optionally mapped to the remote storage field Item Storage ID or by default to the item alternative 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 following acceptable types:

Item Material Types

Code

Description

ARTICLE

Article

ARTORIG

Art Original

ARTREPRO

Art Reproduction

ATLAS

Atlas

AUDIOBOOK

Audio Book

AUDIOCASSETTE

Audio cassette

AUDIORECORDER

Audio Recorder

BACHLORTHESIS

Bachelor Thesis

BLURAY

Blu-Ray

BLURAYDVD

Blu-Ray And DVD

BOOK

Book

BOX

Box

CALC

Calculator

CAMERA

Camera

CAMRECORDER

Camcorder

CASE

Case

CD

Compact Disc

CDROM

CD-ROM

CHARG

Laptop Charger

CHART

Chart

DAT

DAT (Digital Audio Tape)

DIORAMA

Diorama

DISK

Computer Disk

DVD

DVD

DVDRM

DVD-ROM

EPHEMERA

Ephemera

EQUIP

Equipment

EREADER

Ereader

FICHE

Microfiche

FILM

Microfilm

FILMSTRIP

Filmstrip

FILMREEL

Film Reel

FLASHCARD

Flash Card

FLIPV

Flip Video Camera

FLOPPY_DISK

Floppy Disk

FSADT

Flat Screen Adaptor

GAME

Game

GLOBE

Globe

GOVRECORD

Government Document

GRAPHIC

Graphic

HEAD

Headphones

IPAD

iPad

ISSBD

Bound Issue

ISSUE

Issue

ITEM_WITH_AUDIO_CASSETTE

Item with Audio Cassette

ITEM_WITH_CD

Item with CD

ITEM_WITH_FLOPPY_DISK

Item with Floppy Disk

KEYS

Keys

KIT

Kit

LAPTOPACCESSORY

Laptop Accessory

LETTER

Letter

LOOSELEAF

Looseleaf

LP

LP

LPTOP

Laptop

LRDSC

Laserdisc

MANUSCRIPT

Manuscript

MAP

Map

MASTERTHESIS

Master's Thesis

MICROCARD

Microcard

MICROFICHE_MASTER

Microfiche Master

MICROOPAQUE

Microopaque

MICROSLIDE

Microscope Slide

MICROFORM

Microform

MIXED

Mixed material

MMFILM

16 mm Film

MOBILEDEVICE

Mobile Device

MODEL

Model

MOTIONPICTURE

Motion Picture

NEWSPAPER

Newspaper

OTHER

Other

OTHERVM

Other Visual Material

OVERSIZE

Oversize

OVERSIZESCORE

Oversize Score

PAMPHLET

Pamphlet

PHDTHESIS

PhD Thesis

PHONODISC

Record (Phonodisc)

PHOTOGRAPH

Photograph

PICTURE

Picture

PLAYAWAY

Playaway

PROJECTOR

Projector

RARE

Rare

REALIA

Realia

RECORD

Sound Recording

ROOM

Room

SCORE

Music Score

SLIDE

Slide

SPECIALTHESIS

Special Thesis

TABLET

Tablet

TECHDRAWING

Technical Drawing

THESIS

Thesis

TOY

Toy

TRANSPARENCY

Transparency

VIDEOCASSETTE

Video cassette

VIDEODISC

Video Disk

VIDEOGAME

Video Game

VRECORD

Video Recording

VRECORD_OTHER

Video Recording (Other)

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 will be attributed to them so that they can be identified and managed in Alma further to their relevant Alma-side process or department. 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

The following is a more detailed map:

Aleph to Alma 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

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 statistics and maintenance are migrated as statistical notes.

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.

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 which 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, whereby the digital representation is associated with its migrated bibliographic record from Aleph.

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

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: N/A

Options: Optional. Col D – a string including F,L and a delimiter between the F and L.

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

F. Courses

Please list the course libraries you manage courses

Default: N/A

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: N/A

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: N/A

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:

<datafield ind1="" ind2="" tag="987"/>

<datafield tag="987" ind1="" ind2="">

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

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.

Further Explanation – Fulfillment

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.

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.

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 and password) 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 or authenticated via the student information system.

Internal users receive an initial default password based on their Z308 VERIFICATION.

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. Internal patrons authenticate with the primary ID and a password, and external patrons 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.

For customers that manage self check for circulation (SIP2), the PIN number is set according to the match_id_type in tab_sip2.conf only if pin_required is set to Y.

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.

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.

Patron Home Library (Z303-HOME-LIBRARY) – however, for multi-ADM libraries, this is used to determine the correct institution association in Alma

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

Item status, patron status, and sum default sensitivity will be configured via the configuration loader and will not be migrated.

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.

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

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

Acquisitions

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

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: N/A

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: N/A

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.

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

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: N/A

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.

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 =PRINT_OT, O = PRINT_SO and S = PRINT_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.

The following order types behave like serials and receive like serials: PRINTED_BOOK_CO, 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

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: N/A

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.

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.

Further Information – Acquisition

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.

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.

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.

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

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.

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 possible migrated order statuses are: New/In Review, Sent/Waiting for Renewal/Receipt, Cancelled and Closed. It is possible to map your current statuses which are not standard to one of the aforementioned statuses. See the 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.

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)

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

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)

If your 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

Physical to Electronic

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

Default: N/A

Options: Mandatory –select a sublibray 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).

P2E-ItemMT Tab

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

Default: N/A

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

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.

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.

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

Further information - Physical to Electronic (P to E) Processing

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:

Receiving an input file with the relevant Aleph system numbers representing electronic resources and their types (portfolio, package, or database).

Receiving input in migration form for relevant sublibrary, collection and item material types which allow sub-identification within the list received in step 1.

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.

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.

For example:

If you provided the following input file:

ABC0100000200001,Portfolio

ABC0100000200005,Portfolio

ABC0100000300010,Package

ABC0100000400066,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: ONLIN:<any collection=""> – 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. The output portfolio will attain the linking information from the Holding 856 $u– or Bib 856 $u if the holdings does not have an 856. Input provided that the vendor/provider is always stored in 866$a would populate the resulting E-inventory with that information. If we identified all the Bib’s item/s with that pattern, we automatically get rid of the remnant holdings record, too.</any>

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 and package 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 packages (E-collections) 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 SFX 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 SFX 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” SFX version.

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.

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.