SPAM: Re: [OPEN-ILS-DEV] Thinking about receiving

[Lori Bowen Ayre]

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 <david at fiander.info> 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
>
>
>