Existing
Patron/User Load Banner -> Sierra via FTP
- Nightly load from Banner with all active students, faculty and staff, picked up by library-created script to transform csv file. Manually loaded into Sierra daily, overwriting every user in file. Users not in Banner file are untouched. This creates a few issues: Changes made locally in Sierra are overwritten every night. Employees who leave Colgate remain active in Sierra until the default expiration date (typically some time in June).
- STATUS - information gathering
Meescan Self Checkout Vendor server <-> Sierra via SIP2 protocol
- SIP2 is a widely supported standard for self checkout systems. Supported by Alma, Sierra and the vendor. Vendor informed of migration, will touch base in June for config (they said it’s straightforward).
- STATUS - Meescan vendor is aware of our implementation and is ready to assist with the integration once we are in the testing server. Per the vendor, this is straightforward.
LASR Local Dematic server -> Sierra via API?
- Adding and removing books (barcodes) from the LASR system (staff only)
- Patron requests transferred from Sierra to LASR server, which initiates pick request.
- STATUS - Gathering information. Looks like this will just require some configuration changes made on our local Dematic Server.
GOBI book vendor - placing orders Vendor FTP -> Sierra -> Vendor FTP
- This will change in Alma and be API based.
- STATUS GOBI is aware of our planned implementation and has indicated that this should be straightforward. Work will begin once we are in the test server.
GOBI book vendor - retrieving invoices Third party vendor (OCLC) FTP -> Sierra
- For each physical shipment, GOBI provides the order information to OCLC (where we get most of our MARC records from). OCLC adds the invoice information to the MARC record and generates a file for all items shipped that day. We pick that up manually in Sierra and process the invoices.
- STATUS GOBI is aware of our planned implementation and has indicated that this should be straightforward. Work will begin once we are in the test server.
Invoices to accounting Sierra -> Banner via FTP (EDI?)
- Library staff generates invoice file in Sierra, sends via SFTP
- Library staff log into Banner and runs FWRLIB process, followed by FWRLIB2 process, which generates the invoice document in Banner. Library staff then upload PDFs of vendor invoices into Onbase.
- STATUS Gathering information. Waiting to hear back from accounting about who we will work with on their side. ITS is looking into the API for data transfer. Library staff will need to work with accounting to ensure workflows meet their needs.
Panorama
- Nightly SQL query run for current circ transactions, output CSV sent via SFTP
- Additional information about circ transaction (title info, etc) gathered by Panorama via API
- STATUS Alma integration was negotiated as part of the Panorama contract. Work won't begin until we are in the test server.
Email
SSO
- Authentication
- STATUS Basic authentication via SSO is working in the sandbox
Wish List (not implemented in Sierra but supported by Alma)
Fees to Student Accounts Alma --> Banner
Illiad III software Illiad server <-> Alma
- Several processes need to be duplicated in both Illiad and Sierra when Interlibrary Loan materials are borrowed or lent. NCIP protocol is used to automate. Users will be able to see both ILL and Colgate books checked out to them.
Future Considerations not currently a part of the implementation plan, but worth investigating later
Alma replacing Illiad
- It may be possible to configure Alma Resource Sharing to eliminate the need for Illiad, but we need to fully investigate the implications of that. The IDS logic currently running in Illiad has created a lot of efficiencies for ILL staff and we need to investigate what, if anything, would be lost if we moved off of Illiad.
Moodle
- Alma offers way to integrate into a CMS. It is worth investigating what options are available and if they would provide better tools to Borrowing Services for managing course reserves.