Introduction
The University of Northern Colorado bills approximately $120,000 annually in lost book and fine charges. These charges are processed through the University’s Accounts Receivable office onto student accounts.
Students receive a single bill that includes tuition as well as all other university charges. This offers several benefits. First, the library doesn’t collect large amounts of money over the counter. Second, it eliminates the need to have an accounting office within the library. Third, and perhaps the best reason for using this process, is that it forces students to resolve outstanding charges BEFORE they are allowed to register, receive their diploma or obtain transcripts. It is also an incentive for students to return books in the lost category. The library has been using this process for over 15 years.
Library fines are assessed at the rate of 50 cents per day per book up to a maximum of $10. When a book is 28 days or more overdue books are declared “lost” and a charge of $80 per book is levied. The lost book charge breaks down to $60 for replacement costs and $20 for a combination late fine and processing fee. If the “lost” book is returned within one year of its due date the $60 is credited back to the student’s account. Faculty and staff are not charged for late fines but they are charged for lost books.
So now that we have the charges established, how does this information interface to the Accounts Receivable Office? With the migration to INNOPAC in September 1997 the processes had to be redesigned in the INNOPAC environment.
THIS WAS NO PIECE OF CAKE!
INNOPAC outputs data in a standard INNOPAC format. The institution has to build the interface to its own BRS (Billing Receivable System). For us this was a multi-phase process.
INNOPAC outputs the patron number, an invoice number, date of transaction, item barcode, call number, title, patron barcode, name, address) etc. INNOPAC data is in a string of variable length fields. INNOPAC inserts dollar signs ($) between address elements and it separates fields with the pipe character (or vertical bar), This is more data than we wanted written into the BRS system. So data elements had to first be identified for capture from the INNOPAC file.
For confidentiality reasons we do not want people outside of Circulation to know titles and call numbers of materials patrons have used. BRS didn’t the need student address because they already have it; INNOPAC patron number and the INNOPAC invoice number would mean nothing to them.
Once the data was identified, Information Services staff had to manipulate the data file. Information Service’s Center staff had difficulty with the use of the vertical bar to separate fields. Further, the field sequence does not match their BRS format. It was also difficult to distinguish one record from another because there’s no end of record delimiter to identify the end of one record and the beginning of the next. The listserv archive reveals that many institutions have had similar problems.
Another obstacle to overcome in the file transfer process was transferring across platforms and the file types they support. We are going from UNIX on INNOPAC to an IBM mainframe for BRS with an intermediate machine, which is DOS-based.
So you can imagine the headaches. The difference in file formats is an issue. One file has records ending with carriage return line feed and in the other it is just a line feed.
The library was extremely fortunate to have a good relationship with staff at the Information Services Center. The I.S. staff was diligent in their efforts to make this program work. They even went so far as to call colleagues at other institutions. Essentially they had to figure out a way to unstring the data, identify discrete records, and then strip out the non-essential data. Once these obstacles were overcome, the actual task of transmitting the data from the library’s INNOPAC server to the BRS was easy to do manually, meaning the file is written out from INNOPAC to a library server.
I.S. folks then fetch the file and transfer it to their machine. The file cannot be transferred directly because there are security issues with the INNOPAC server and the University’s mainframe. Neither party wants “outsiders” to have access to their machine.
The Library is currently working with Information Services staff to try and automate the transmittal process more. The manual process forces us to rely on human intervention. Having to depend on an individual poses problems when the person needs to be gone.
Once the Bursar output file has been created there is a screen that gives you a summary of the number of transactions involved and the total dollar amount involved. A copy of this screen is made and it is used as a checkpoint to be sure the same number of transactions, etc. transferred over to the BRS. The file is sent once a week.
After each bursar output is processed a summary report is received from the Information Services Center. Because INNOPAC does not have a fine archive these reports are invaluable. Students, as you know, are notorious about waiting until their backs are to the wall before they resolve their charges. Sometimes students can be gone from campus for a year or more before they attempt to resolve their charges. These reports provide us with a means of knowing who had what charges when. In addition the reports provide us with a sub-code summary – a feature that we expect will satisfy the auditors.
Recommendations
Do I recommend the Bursar Output product? DEFINITELY. Even with all the frustrations we experienced, I would still highly recommend using it. I truly cannot imagine life without it. I would further recommend that you allow several weeks to work out the details of getting the data formatted to your particular BRS system.
Possible Future Enhancements
To improve the process, we would recommend that Innovative develop a more standard way to delimit fields in the records and more importantly to identify the end of one record and the beginning of the next.
We would also recommend having the ability for local control of a neutral place for Circulation to send the file on INNOPAC where an outsider (i.e., I.S. staff) could pick it up – hopefully eliminating this intermediate process.
Having the ability to view a bursar output file BEFORE sending it would be most helpful. It would allow Circulation to do some troubleshooting ahead of time, As it is now we don’t know a problem exists until after the transactions have interfaced on to the individual accounts.
Bursar In
We did purchase this product but have not used it yet. We’ve been too involved in getting the Bursar Output to work. We anticipate that we will investigate the use of the Bursar In in more depth.