Receiving needs to be efficient, since it's most definitely a
materials handling process above everything else.
Imagine that the staff have opened a box and dug out the packing
slip / invoice.
Once they've checked that against the contents of the box against the
slip, they're ready to start checking materials into the system.
They go to the receiving screen, which comes up with today's date,
which will be used as the "actual received date" in the acqlids that
are updated.
In order to properly track things, the acqlid should probably have an
invoice # field. On the receiving screen, there will be a field at
the top into which the staff member enters the current invoice
number, which will then be applied to all the acqlids that are updated.
The primary field on the receiving screen is an ISBN input field. The
staff scan the ISBN barcode on each item, which pulls up the
corresponding JUB.
This is where I get fuzzy. At this point, we can either flag an
acqlid as received, and the staff can just keep scanning duplicate
barcodes as they pull items out of the box, or they can switch to the
keyboard to mark the number of copies that arrived.
The first case makes it simpler to burn through a box of books
regardless of the number of copies of each that have arrived. In
fact, if the normal case is "only ever one copy", as it usually is in
academic libraries, this completely eliminates the need to used
anything on the keyboard beyond the return key (assuming that the
barcode reader doesn't transmit a return at the end of the number
scanned).
The second case gives the staff more control over accepting _which_
copies have been received, which is useful when we normally order
multiple copies, but not all copies arrive together: the staff can
explicitly route copies to the appropriate locations. It probably
will also work better for larger public libraries that almost always
order multiple copies of everything.
How does that sound as a starting point?
- David
--
David J. Fiander
Library Software Development
