I would also like to point out that shipments, at least for us, are
normally based on inventory rather than invoice. An invoice is filled
in slowly over the course of 3-6 months. With each department opening
at least one invoice each month, we typically apply each shipment to
5 to 7 invoices. I agree that EDI is the real solution. Where that is
not an option, I ask that we can enter/select all the relevant order
numbers at the start, rather than just one. This way, we do not have
to presort the material before processing. Each order should already
have its own list of relevant ISBNs to match against.
Something close to the "flag an acqlid as received, and the staff can
just keep scanning duplicate barcodes as they pull items out of the
box" scenario has some additional virtue. This approach simplifies
holding record maintenance as item barcodes can be assigned as part
of the receiving process. Sometimes, multiple copies are ordered
through multiple orders (and hence invoices).
Perhaps the outstanding ISBNs could be indexed, pointing to order
numbers. As each ISBN is scanned, the relevant order is found and
updated and the expected quantity reduced by one, deleting the entry
at zero. If a collision is found, an option list is presented so the
receiver can select which order to receive on.
Just a thought.
On Fri, 25 Jul 2008 09:24:47 -0700, "Lori Bowen Ayre"
<[EMAIL PROTECTED]> wrote:
I'm going to jump in here and suggest that someone needs to get
familiar with ASN (advanced shipment notificiation) which allows the
libraries to electronically receive their materials rather than having
to check in each item one at a time. Essentially, once the shipment
contents is verified (one order or partial orders), the items
represented on the packing slip can be uploaded using the ASN process.
Ingram can do this and I don't know about others. The problem, as
usual, is on the ILS side.
I don't know much more than that but I can refer you to a document at
http://www.pubnet.org/community/EDI.pdf
that may help. I can also refer you to at least one person I know of
(on the front lines) who has been watching this for some time and may
have some insights.
Let me know if I can help further.
Lori Ayre
The Galecia Group
On Thu, Jul 24, 2008 at 5:54 PM, David J. Fiander
<[EMAIL PROTECTED]> wrote:
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
Paul Waak
[EMAIL PROTECTED]
