Budget Data Mapping: Aleph to Alma
Purpose: This page describes data value crosswalks and data element mapping for the migration of Budget 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 fund/budget data migration are outlined on this page.
Page Contents
Alma Budget Overview and Structure
Alma Terminology
A fund represents money in an account. A fund can be a Ledger, an Allocated Fund, or a Summary Fund.
- Allocated Funds
- An allocated fund contains money that has been paid out or has been encumbered for open orders.
- A specific Allocated Fund can only be associated with only one Ledger or Summary Fund, but not both.
- Summary Funds
- A summary fund is not used for ordering and invoicing, but provides aggregate reporting on subordinate funds. You can add other funds to this type of fund.
- A summary Fund can only be associated with an allocated Fund.
- A Ledger is a collection of funds.
- Ledgers are defined for a specific date range, such as September 1 of this year to August 31 of next year.
- A Ledger Fund can be associated with a Summary or Allocated Fund.
Ledger and Fund Ownership and Availability
A ledger is owned by either the institution or a library. Any funds added to the ledger are owned by the same entity that owns the ledger.
- If a fund is owned by a library, it is available only to that library.
- If a fund is owned by an institution, it can be made available to all libraries at the institution, a group of libraries at the institution, or a single library at the institution.
When creating the ledger, you can set the ownership of the ledger to a library (the institution is selected by default). Changing the ownership of the ledger changes the availability scope of the ledger and the ownership of all of its funds, but does not change the availability scope of the funds.
When creating the ledger, you can restrict the availability of the ledger to one or more libraries within the institution.
- The availability of the Fund must be within the Ledger's availability (It is highly recommended to save the ledger before adding its funds - in this way the Fund's availability is taken from the ledger's).
- To view or manage a ledger or fund available to a particular library, a user must have the relevant role with a scope of an institution or that library.
A user with a role with an institution scope can change the availability of a ledger or fund to include more or less libraries. When you remove the availability of a ledger from one or more libraries, the associated funds are also made unavailable to these libraries. When you add availability to a ledger for one or more libraries, the funds remain unavailable to the libraries unless you add them as well.
When transferring funds between ledgers, you can only move the fund to a ledger with the exact same availability as the one from which you are moving the fund.
Migrated Budget Structure
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 retrieving the Aleph 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.
- Budget currency: In Alma, budgets require a currency. In Aleph, budgets are not directly related to currencies, so the migration sets currency according to the local currency defined for the institution.
- Funds and ledgers: In Aleph, there is no parallel to the Alma ledger structure that is required for Alma fund management. The ledger groups a number of funds according to the fiscal period. The ledger record also points to the currency, which in Alma is common to the group of funds under the ledger. The detailed ledger information is created as follows by the migration:
- After creating fiscal periods, the same logic is used per budget to associate it with its fiscal period – one LEDGER per fiscal period (GENERAL_LEDGER) which will sometimes be split into multiple ledgers for the same fiscal year if there are hierarchical grandparent funds (see below regarding grandparent fund structures).
- The status – Active or Inactive – is set according to the status of the matching fiscal period.
- All ledgers and funds must be owned at the institution level for migration purposes.
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.
- If Z76_BUDGET_NUMBER does not have the –YYYY suffix, it is linked to an existing fiscal period based on the year of its Z76-VALID-DATE-TO. If that year was not created (for example, future fiscal year2099), the budget is linked/associated to the maximum annual YYYY fiscal period created based on the –YYYY suffix. If the budget code does not have a numeric suffix -YYYY (for example, ABC or ABC-abcd), the suffix -FUND is added to the budget in Alma to avoid duplications in the budget codes.
- Local data analysis 8/1/23: There is only one budget record at Duke that doesn't contain the -YYYY suffix: PGIFT which is contains a Z76-VALID-DATE-TO of '20050630.'
Recommendation: 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.
Crosswalks: Aleph code values to Alma code values
Aleph Budget Type to Alma Fund type
We can configure custom fund types in Alma. This is the list available in the sandbox, but we can add/edit/delete as needed. Per Chana at ExLibris on 10/9: Our current list of budget types will be brought over automatically into Alma as custom types. It’s a one-to-one mapping, so Aleph budget codes/descriptions migrate to Alma fund types without changes.
This is the current set of budget types in use in Aleph (10/3/23)
Z76_BUDGET_TYPE | Count |
BIUTL | 1 |
ENDOW | 234 |
GIFT | 2 |
GRANT | 11 |
REG | 1 |
RESTR | 31 |
UNALL | 1 |
UNIVA | 312 |
Data Cleanup
Per the migration guide, 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. They recommend running this job prior to the Test Load and prior to cutover so that the amounts will match, unless there is a business need not to run this before TL.
Budget 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.
Aleph Field | Alma Allocated Fund Field | Alma Navigation to the field | Additional Information |
Open Date | Created on | More Information | |
Department | doesn't migrate to Alma | This is where we currently store the selector initials, so we need to find an alternate way to track. 8/2/23 - Looking at Alma, the description field or notes seem to be the only available text field. 10/3 Chana at EL suggested consideration of templates and object codes (but those are at the POL level, so that seems unwieldy). Discuss options with the team. | |
External Name | External ID | This is the SAP budget number | |
Budget Code | Code | Summary > General | |
Budget Parent | Path | Summary > General | In Duke's data there are 299 inactive Law budgets that contain a budget parent value. We asked EL about this - see question log #38. Response from EL: We don't need to be to concerned about these since they're inactive funds. We could spot check how some of these look after migration. From looking at the guide, the parent budget will be migrated to a standard allocated fund which would also be set to inactive. |
Use Parent Budget for Invoice Report | NA | NA | |
Budget Type | Fund Type | Summary > General | |
Name | Name | Summary > General | |
Valid From/Valid To | Fiscal Period Dates | Summary > General | |
Budget Group | doesn't migrate to Alma | ||
Budget Status | Status | Status | |
Note 1 | Notes | Notes | |
Note 2 | Notes | Notes | |
Note 3 | Notes | Notes | |
Note 4 | Notes | Notes | |
Object Code | NA | NA | |
Expressed as Percentage | NA | NA | |
Limit to 'Under' Exp./Enc. | Overencumbrance allowed | Rules. Overencumbrance allowed | |
Annual Budget | doesn't migrate to Alma | This checkbox doesn't migrate since all Alma funds are annually managed. | |
Max. Over/Under Encumbrance | Overencumbrance limit percent | Rules | |
Max. Over/Under Expenditure | Overexpenditure limit sum | Rules |
Budget Data that doesn't migrate to Alma
- 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)
Note: For Aleph budget transactions (Z601), all fields are migrated