Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Aleph to Alma Migration Guide

    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.

    Related Documentation

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

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

    Default: N/A
    Options: This question is mandatory. Insert your institution ID (Sent to you by your PS).

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

    Default: N/A
    Options: This question is mandatory. Insert your institution ID (Sent to you by your PS).

    Further Explanation – General

    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

    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

    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)

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

    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 not indicating a link resolver, leave blank.
    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?

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

    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.

    9XX Bib Tab

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

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

    Suppress Bib Tab

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

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

    9xx Hol Tab

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

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

    Suppress Hol Tab

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

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

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

    Default: N/A
    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:
      1. Run p_ret_01 in XXX60 without parameters in order to retrieve all records.
      2. Run p_print_03 (print only 852 field in Aleph sequential format).
      3. Filter the output file. This can be done in Excel:
        1. Select Data > From Text and select the file.
        2. Define the field separator to be $$.
        3. Add a header column to the data.
        4. Filter the data using the header columns.
      4. Analyze your data by comparing the sub-libraries in the holding records against the sub-libraries defined in tab_sub_library.lng.
      5. 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:
    • 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.
    • 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 migrated 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.
    • 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)
    • 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.
      No mapping input is required for ADAM migration to Alma.

    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.

    Fulfillment

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

    Default: N/A
    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 system (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.
    • 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. 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.
    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

    • Z303-PROXY-FOR-ID, Z303-PROXY-ID-TYPE, and Z303-PRIMARY-ID
    • Patron Budget (Z303-BUDGET)
    • Patron Profile ID (Z303-PROFILE-ID)
    • Salutation (Z303-SALUTATION)
    • 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)
    • Shared User Patron Architecture
    • 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

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

    Default: N/A
    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 to this library in Alma.

    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.

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

    Default: N/A
    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.
    • When your budget names match the real fiscal year:
      AABBCC-2014 is related to the 2014 fiscal year which ends in 2014
      Answer YYYY = 2014
    • When your budgets are named one year prior the real fiscal year:
      AABBCC-2014 is related to the 2015 fiscal year
      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.

    Default: N/A
    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 =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.
    • By default: M =PRINT_OT, O = PRINT_SO, S = PRINT_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: 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.
    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.
    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 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.
    For those Z76_BUDGET_NUMBER that do not have the –YYYY suffix, it is either linked to an existing fiscal period based on the year of its Z76-VALID-DATE-TO. If that year was not created in #1 already, it is created and the budget is linked to it if the year is in the past. If the year is in the future, it is associated to the maximum annual YYYY fiscal period created based on the –YYYY suffix.
    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.
    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).
    • 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 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
    • 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)
    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

    Default: 856 u
    Options: Provide a 3 digit MARC field code + subfield: 856u. Only one subfield is allowed (Column D).

    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: 856m. 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: 856z. 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: 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.
    For example:
    ABC0100000200001,Portfolio
    ABC0100000200005,Portfolio
    ABC0100000300010,Package
    ABC0100000400066,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. See Further information - Physical to Electronic (P to E) Processing for more details.
    • 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

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

    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/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.
    • Was this article helpful?