[748] in ad-lib
Of Circ and Tables and things...
daemon@ATHENA.MIT.EDU (gyoung@MIT.EDU)
Sun Jun 4 18:38:20 1995
From: gyoung@MIT.EDU
To: advancecirc-lib@MIT.EDU
Date: Sun, 04 Jun 1995 18:38:09 EDT
Now that Circ notices are printing a couple of problems that have come
up in several disguises are becoming more identifiable. Generally they
fall into the category of fines not being charged or being charged
irregularly. We have several interlocking problems here.
1. Apparently, the migration did not migrate some of the transactions
appropriately. This seems to be the root of the faculty not charged
fines problem.
2. There were some minor problems with the way fines were set up in the
tables. This has influenced some test cases with fines being created
improperly.
3. The changes we've put into the tables have created some potential
problems.
Last week I sent you a copy of Doug Chafe's explanation of how Advance
figures out what loan policy to use. In an over-simplified nutshell,
when you create a charge-out record the system stores a record of the
Circ Code used and the Patron Group in the transaction, e.g.,
CO*P1*GEN1.
This is used when the book is charged back in to help calculate the
fines. Apparently, it'll also go back into a history file to see what
the policy was when the record was created. While I'm not entirely
convinced of this, it is something to keep in mind as you're testing.
I went through the tables this weekend and basically fixed the
periodicity with which the fines were being charged. For example, on
some of the monthly loans the period for charging the fines was set for
28 days. So, if a book was 28 days late is was only charged $1.25, the
minimum. The fines periods are now set for 1 hour or 1 day, whichever
is appropriate. They should now work, especially with new transactions.
The faculty not being charged fines problem seems to be a mis-migration
of a subtle but potentially serious kind. The transactions for the
faculty in question has a P3 group code in them. Not only that, they
seem to have a notice sequence which is quite bizarre. My sense is that
they were improperly migrated with a patron group from a default setup
and table history. This could be a problem for us on two levels. One
is our own doing, the other might be a flaw from Geac's GMA.
When Geac started our migration they took a copy of our tables. That's
why we were scrambling to get stuff into the tables before we sent the
original tapes off. On the positive side, we think we got all the
appropriate codes into the system before the they took it. There should
be no problem linking the patrons to the correct patron groups. On the
negative side the errors that we've since discovered in our tables may
be part of the history of the transactions we migrated. When we get the
data back we need to be able to tell the difference. If the
transactions get migrated with the incorrect patron group then Geac has
a GMA problem. If they migrate with the correct patron group we may be
stuck with a temporary fines problem until those transactions have been
cycled through the system.
Also, over the weekend, I added about 36 people to access Circulation.
I tuned access levels for the various menu selections and hopefully
cleaned up access in general. I almost certainly missed some people who
should have access to emmy. I'd like to add all Circ and Processing
staff who should have access as soon as possible. Please let me know
who they are. I can now add people fairly quickly in Circulation.
Also, if there are problems with access to functions let me know and
I'll fine tune it. I still have to add local printing to the majority
of users.
This week I'd like to get notices worked out and start designing Menus
for various levels of Circ staff.
-- Grant Young, Libraries Systems Office
