Vendor Data Mapping: Aleph to Alma

Purpose:  This page describes data value crosswalks and data element mapping for the migration of Vendor data from Aleph to Alma.  This video from ExLibris provides instructions to complete the migration form that we need to complete prior to the automated migration of Aleph data to Alma.  The decisions we'll need to make about vendor data migration are outlined on this page.

Page Contents

Alma Vendor 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 (source):

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.
  • Two-level vendor record: Each vendor in Aleph is migrated as a vendor or as an account into Alma when the TWO-LEVEL-VENDOR flag in the data_tab/tab100 table is set to Y.
    • If the vendor record is identified as the parent it creates a new vendor.
    • If it is identified as a 'child' it creates a new vendor account in the parent vendor record. The accounts are created in a manner similar to the description above, but with the addition of the sublibrary defined in the Z70_rec_key.
  • Shared Vendor: If you are migrating a multi-ADM with shared vendors to Alma as a consortium, each of the ADMs (migrated as an institution) are extracted with all the vendors in z70. There is a difference in the extracted vendor account. The two-level accounts are associated by their z70_rec_key to the relevant IZ (according to tab_sub_library.lng). All of the vendors include, in addition, a default vendor account containing the vendor code.
• Vendor payment method: In Alma, the vendor record must have at least one payment method defined. During the migration, the method is set as the default for Accounting department.
• 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.

Crosswalks: Aleph code values to Alma code values

This section describes the crosswalk of Aleph code values for key vendor data elements to the target Alma code value.

• Vendor status: Aleph vendor statuses are all migrated to Alma as Active, except for NA, which is migrated to the status Inactive. 
  • Questions for local Duke team
    • Is there anything we want to ask ExLibris to do for our vendors with a status of GI (gift), such as put a note to indicate that this vendor had a status of GI in Aleph? 
    • There are 1011 vendors that have a null status - these will migrate as Active.  Is that OK or do we need to do any cleanup to make sure those are all active vendors? 

      
      

Data Mapping

This table describes the Alma target field for each Vendor field in Aleph. Note:  Much of this content was copied from Harvard's data mapping guides, last updated in 2018. Please consider this page a draft until the Duke team verifies that this mapping information is current and concurs with Duke's migration decisions.

Data Cleanup Tasks

Currency code values must match ISO standards.  The currency code for Turkey is 'TRY', so the Currency 2 field values of the following vendor records need to be changed prior to migration to Alma or we can set the mapping during migration.

Vendor Status

Current values in use in Aleph as of 10/2/23.  Do we need to look at the 1011 that have a null vendor status?  I've posted a question to the Alma Basecamp to confirm whether null status codes will migrate as Active. 

Vendor Data that doesn't migrate to Alma

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

Aleph Screen Shots