[OPEN-ILS-DEV] SPAM: Re: Open-ils-dev Digest, Vol 28, Issue 43

[Paul Waak]

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"  
<lori.ayre at galecia.com> 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  
> <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
>>
>>
>>
>

Paul Waak
pwaak at yahoo.com