Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 42 Next »

Online Training Resources

Check out these online training videos from Ex Libris's Knowledge Center. (We will not be implementing Primo as a discovery layer, so you can ignore references to Primo in these videos.)

We also have a growing list of resources being collated from other institutions that have gone live with Alma: Alma resources from other institutions

Changes from Aleph to Alma

This list is not complete!

As project staff continue to learn more about Alma, we will begin listing information here about changes from Aleph to Alma that we think it is important for library staff to know. This list should not be considered a complete inventory of what will be different - just things that we think will be worthwhile to remember, especially in Spring '24.

General / System Changes

  • Because Alma is web based, the system will enforce a logout when there has not been any activity. It is set to 60 minutes and is not configurable. Alma will give a warning message 60 seconds prior to timing you out. (link)
    • There is also a separate, configurable timeout specifically for the Patron Services page that defaults to two minutes before timing out that page. 
  • In Aleph, we have a production server and a development server. With Alma, we will have a production site and a premium sandbox site.
    • The premium sandbox site will have a copy of our production data, refreshed by Ex Libris twice a year. 
  • Permissions in Aleph are referred to as privileges in Alma. Ex Libris packages individual privileges into roles - there are ~75 different roles. We will assign roles to library staff, not privileges.
    • In addition, some roles have an optional or required scope. Scope can generally be set to an institution, library, circulation desk, or operational unit depending on what the role actually does.
    • Privileges that are part of a role can be enabled or disabled by Ex Libris if we request it, but they cannot be repackaged into new roles. That will mean that some staff will get roles that give them access to areas of Alma that they do not otherwise need access to.
    • We will use a workflow in Alma that allows us to define job categories and associate them to roles. When a new employee is hired, an appropriate person will edit their Alma user record to add a job category, and an automated workflow within Alma will assign that user the appropriate role(s) for the job category.
    • Many administrator roles can be granted as read-only, where users can be allowed to view administrative settings but not change them. We will explore how to best use that function to allow people to see "under the hood" with Alma in ways that were not easy with Aleph.

Users

  • All users who need to be able to borrow books will have a special role of Patron. 
  • Open requests will not stop a user from being deleted like they do in Aleph. Open loans and unpaid fines will still stop a user deletion. If the user only has open requests, the user can be deleted and the request(s) will be cancelled.

Fulfillment

Course reserves

  • Records for Faculty personal copies will be stored in Alma in their own library, rather than just in a reserves collection code. Alma will do it automatically when the personal copy record is created. There will be a location for each instructor that puts personal copies on reserve.

Fines

  • If an item has associated overdue fines (even regular overdues), and the item then goes lost, Alma can either charge the overdue fine at the time it goes lost, or not charge the overdue fine, but the overdue fine will continue to accrue. There is no option to drop the overdue fine when the item ages to lost. It will have to be waived manually.

  • Alma offers the ability to "dispute" fines. If a fine is marked as disputed, it will not count towards blocking based on a fine amount, and it won't be considered as part of a patron's "active" fines. A disputed fine can then be waived, or restored and then charged/paid.

  • Fine exports will be scheduled and automated, with no manual option to delay sending the fine. E.g., in Aleph we run a report that marks the fine as "sent to bursar", and that's done manually at the discretion of the library. In Alma, that report will be scheduled and done automatically each week.

Loans

  • We will be able to configure a "renewable" period - e.g., the number of days before a due date that a loan can actually be renewed.
  • Alma does not keep count of the number of times an item has been renewed. Instead, it maintains a "maximum renewal period". E.g., if the item loans for 28 days now and we allow it to be renewed two times, the maximum renewal period in Alma will be 84 days. 
  • Loan fixed due dates for graduate students and faculty will be managed through the library calendar, which is an additional layer than the Aleph workflow. Library  calendars will create an "event" for the fixed due date, and then the due date term of use policy will use the library calendar "event" to set the due date. 
  • If a patron cancels a recall, the initial due date will be re-instated for the recalled item, and the person who has the book will get a notice letting them know that the due date has been changed back.
  • Calendars have a different structure. There will be an institutional calendar that will have events and exceptions that each library will inherit. Then the library itself schedules opening hours. You define one set of standard hours - a set for each day - and then exceptions for hour changes. We will decide if we want to use events, as they are essentially just notifications for calendars within Alma. Exceptions are what they sound like - changes to a library's standard hours, either open or closed.

Requests

  • Alma will implement title-level requesting for all DUL libraries - title-level is the default behavior.
  • We will have limited ability to restrict where requests can be picked up from. There are available control options, but they are not as expansive as with Aleph, and we need to explore what might work best.
    • We can completely prohibit the ability of a library to handle requests for another - e.g., Library A cannot handle requests for Library B. That would prevent patrons from asking for items from Library B to be requested for pickup at Library A. This would be done at the library configuration and would apply to all items in Library B. This could potentially allow a library to decide it does not want to deliver to a non-library-but-still-staffed pickup location if that was something that library wanted to do.
    • We can prohibit paging - e.g., requesting items from Library A for pickup at Library A - while allowing those items to be delivered to other libraries. (This is a use case for graduate student support at some libraries.)

Resource sharing

  • When an item goes out on a lending request to another library, instead of having a "process" on the item, Alma will move it to a temporary location within the resource sharing library. 

Acquisitions

General

The Aleph "Ordering unit" doesn't exist in Alma.  Instead, acquisitions records are associated with an Alma "Library" which aligns more closely to the Aleph sublibrary, though the list of Alma Libraries likely won't include all of the sublibraries from Aleph. 

Vendors

There aren't significant changes in how vendors are set up in Alma.  Some Aleph vendor fields won't migrate from Aleph. To see more information about the data migration for Vendors see this Data Mapping Guide for Vendors which includes the list of fields that won't migrate.

Funds/Budgets

  • Alma's fund structure differs from Aleph and includes new concepts: Ledgers and Summary Funds. 

  • There are three types of Fund records in Alma:

    • Ledger(s): top-level record; you can have a single ledger for the entire campus, or separate out ledgers for schools or departments to mirror your actual financial structure
      • A Ledger in Alma represents a collection of Funds, while a Fund represents actual money in an account
      • A Ledger is a collection of Funds.
      • You can have a Ledger without a Fund but you can’t have a Fund without a Ledger.
    • Summary funds: used to group funds together for reporting purposes; if you are using a very simple fund structure, you do not need to have summary funds. 
      • A Summary Fund is not used for ordering or invoicing. Instead, a summary fund allows you to group similar allocated funds together so that you can track them more easily.
      • You cannot add money or perform transfers with a summary fund, and summary funds are optional
    • Allocated funds: these records have money associated with them, and are the funds used for placing orders and paying invoices.  This is what we called a "budget" in Aleph.
  • The Aleph budget department code (containing the selector initials for DUL budgets) don’t migrate to a dedicated field in Alma, so we'll need to determine how to enable selectors to track spending for their budgets.

  • Alma offers the ability to upload allocation amounts from a spreadsheet.

  • To see more information about the data migration for Budgets, see this Data Mapping Guide for Budgets which includes the list of fields that won't migrate.

Orders

Several key fields on the Aleph order are different in Alma.  For example, there isn't a direct parallel to the Aleph Order Type in Alma.  In Alma, the order type is stored at the PO Line and there are 38 PO Line Type values available in Alma, where there were only 3 order types in Aleph (M, O, S).  The Alma PO Line Type merges order type with material type.  Example Alma PO Line types are "Physical - One Time" or "Electronic Journal - Subscription." 

We need to decide 1) which Alma PO Line Types we want to use and 2) how to populate the Alma PO Line Type on our Aleph migrated orders for each combination of Aleph Order Type and Order Material Type.  See Order Type and Order Material Type for the list of Alma values and analysis of next steps on this crosswalk.

Detailed info about these differences and the decisions we'll make about migrating order data at the links below which live in this Data Mapping Guide for Orders

Order Data that won't migrate from Aleph to Alma:

  • Order log notes do not migrate from Aleph to Alma and these contain very useful historical information for acquisitions staff.  We will ask ExLibris whether it would be possible to migrate specific types of order log notes.  If this isn't possible, we'll likely need to store the notes in an external Library Data Service Center.  See Order Data that doesn't migrate to Alma for the list of order log notes that we'd like to migrate.
  • Routing lists will not migrate from Aleph to Alma, but there does appear to be a routing list function in Alma.
  • To see the full list of order fields that won't migrate, see this Data Mapping Guide for Orders

Invoices

The structure of invoices in Alma matches Aleph: an invoice header with associated invoice lines.  There are slight differences in the name and controlled vocabularies of two fields:

There aren't dedicated fields in Alma to capture the invoice barcode or instructions such as "Pay Immediately" or "Pickup check", so the ExLibris advisors recommend that we continue to code those instructions into the notes field as we currently do in Aleph.

The process of exporting "Ready to be paid" invoices to an external Accounts Payable system is described in detail on this page: Invoice Export.  Note:  In Aleph, we currently use several custom services to manage the invoice export to Duke AP.  An initial assessment of ExLibris' documentation indicates that there isn't a way to handle two aspects of our Aleph customization:

1) The invoice export job extracts all invoices that are ready for payment and there isn't a way to run it only for invoices from a specific library, as we do currently in our custom Aleph service.  We can indicate that the output be split by owner library, so we'll need to explore how this will impact workflows.

2) There isn't a way to run a preview of the invoice export before actually running it (that's also a custom service in Aleph.  The ExLibris team suggests the following:

"In Alma you can make sure invoices are ready for export by requiring either Invoice Review or Invoice Approval before they are flagged for export. You can configure rules for determining when Review and/or Approval are required to keep the process as strreamlined as possible. If you prefer, you should be able to reproduce the Alma workflow using Alma Analytics. You would then, however, need to use the API to mark the invoices as either Waiting for Payment or Closed depending on whether you plan on importing updated invoice payment statuses from finance system."  

Additionally, we are exploring how to indicate that an invoice fund whould be assigned a DKU company code in the feed to AP since this isn't something we can currently handle in the feed from Aleph.

Serials

Prediction patterns and predicted items can migrate to Alma.

Note: Item History data will not migrate to Alma from Aleph, so plans are underway to store that data in a Library Data Service Center outside of Alma.


Electronic Resource Management (ERM)

Licenses

Alma includes functionality to manage e-resource licenses and we plan to migrate FOLIO Licenses to Alma.  There are Terms of Use values available out of the box and we can add new ones if needed. To learn more about Licenses in Alma, check out this short intro video: Licenses overview.  There are a few differences between FOLIO and Alma Licenses:

  • Alma offers a template feature for quick license creation based on a template.  Alma also offers a duplicate function (which is also available in FOLIO).
  • We can assign an Alma License directly to an e-resource in Inventory.  In FOLIO, this connection occurred via the Agreement and Duke has not yet created Agreement records in FOLIO.
  • We can assign an Alma License directly to a PO Line.  In FOLIO, this connection occurred via the Agreement and Duke has not yet created Agreement records in FOLIO.

Usage Reports (COUNTER via SUSHI)

Both FOLIO and Alma offer very similar functionality, though the user interface design is more tabular in Alma.  One key difference is that SUSHI credentials are managed on the vendor account in Alma, whereas in FOLIO they are managed on a separate eUsage provider record. Both systems support harvesting various COUNTER report types and uploading.


  • No labels