Aleph 19 Upgrade: The Final Week

On Tuesday, July 21 FCLA will upgrade our Aleph Library System from version 18 to version 19. Our system will be down from approximately 5:45AM to 10:00AM. The library OPAC will work but the patron empowerment features, like holds and renewals, will not. Here is how the upgrade process should proceed.

Some of you have been asked to to assist with the testing in preparation for this conversion and department heads of affected areas have been given a checklist to verify functionality using the test client. If you were given a checklist, please review the operations and let me know if you have any questions or concerns. I will be coming by this week to install the Aleph 19 Production client on your machines. It will not work until the new system is brought online Tuesday.

On Monday, July 20 I will install the new offline circulation module on to the circ desk. In the highly unlikely event that Aleph goes down Monday evening, circulation events should be recorded manually. Please insure that all student workers understand this or library transactions will be lost.

On Tuesday, July 21 all circulation should be handled through the Al500 Offline client until we are given the go ahead to switch over to production. Once that happens, I will share through a lib-all email. At that point I will be at the circ desk ensuring that the morning’s data is loaded properly. If you have any issues with the new client, please email me and I will do my best to find a solution as soon as possible. I am setting the circ desk and the OPAC as my first priorities.

I do not expect this process to be difficult or painful. FCLA has put a great deal of effort into preparing for this and we have been testing for quite some time as well.

Again, if you have any questions or concerns, please let me know as soon as possible.

Aleph 19 Offline Circ Client

In testing for the Aleph 19 upgrade, we made a couple of discoveries. First, the version 19 offline client is different and must be installed. I was hoping to use the v18 client but FCLA says no. Second, the path to the dat file created by the client is slightly different. Instead of going to T:\AL500\OFFCIRC\FILES\NFU50\OFFCIRC.DAT we need to go to T:\AL500\OFFCIRC\FILES\USM50\OFFCIRC.DAT Not much of a change but certainly enough to throw people off if they are not comfortable with the process.

Aleph to Banner Data Transmission

This week we met with UNF ITS and Finance to go over the progress of our Aleph to Banner export project. The news was very good. FCLA sent over the data from Aleph and ITS successfully imported it into our Banner Financial System. The process appears to match what I envisioned from the outset. When the data is imported into Banner, all of the fields will be filled an our business office will simply need to approve the transaction without entering much, if any, data.

Our next steps will require ITS to automate the ingestion of our index number. This number is the same 99% of the time so that will be part of the approval process for our business office. We will also have an "accuracy report" produced, again by ITS, to tell us what was entered into banner and what was left out. Finally, we decided to ask ITS to script the import process to run nightly which is, of course, much faster than our current manual process which is only done once a week.

We are going to retest the rejection process of PCARD transactions. The initial thought was to automatically reject any invoice without the proper n-number and ingest any invoice with an n-number but we must also reject invoices that contain the text PCARD even if it has a legitimate n-number. We will perform one more export to validate the process and then go live. Hopefully this will all be wrapped up before Fall.