Page Comparison

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.

...

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

...

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.

...