SPAM: Re: [OPEN-ILS-DEV] Thinking about receiving
I'll try again to chime into this thread...I think my last message was blocked. 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 Sun, Jul 27, 2008 at 6:51 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Thursday 24 July 2008 8:54 David J. Fiander 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 seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. I think it would also be good to support using the PO as the receiving entry point. Assuming the PO number is included with the invoice, staff can pull up the PO by ID and mark all items or individual items as received. Dan S. also submitted a work flow at http://open-ils.org/dokuwiki/doku.php?id=acq:scenarios:receiving_monographs -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: SPAM: Re: [OPEN-ILS-DEV] Thinking about receiving
On Tue, 12 Aug 2008 12:34:43 -0400, Lori Bowen Ayre [EMAIL PROTECTED] wrote: I'll try again to chime into this thread...I think my last message was blocked. 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. We (the ESI folks) have spoken to Ingram about their ACQ processes and about ASN in paticular. We agree it's a cool feature and have every intention of making sure Evergreen can process ASN EDI. As we start looking closer at the process, we may take you up on your offer of help ;) Thanks, Lori. Let us know if you have any other thoughts/suggestions. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Thinking about receiving
On Sunday 27 July 2008 11:19 Mike Rylander wrote: On Sun, Jul 27, 2008 at 9:51 AM, Bill Erickson [EMAIL PROTECTED] wrote: On Thursday 24 July 2008 8:54 David J. Fiander wrote: [snip] 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 seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. Learning/stealing from Vandelay, we could add an identifier boolean to acq.lineitem_attr_definition, and simply search all of these attrs as an exact-match from a single search box. Add ISBN, ISSN, UPC, po number (as a vendor attribute), ASN id, etc. We'd also want to search the barcode on lineitem_detail for detecting shelf-ready items. I like this approach. It will certainly make the interface more streamlined. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
RE: [OPEN-ILS-DEV] Thinking about receiving
On Thursday, July 24, 2008 7:55 PM, David J. Fiander wrote: 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. The system would need some way of dealing with duplicate (reused) ISBNs or items with no ISBN. Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses 1-800-323-4241x402 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] Thinking about receiving
Bryan, You're absolutely right, and I'd already thought of dealing with items without ISBNs, at least. But for the initial development, I think we need to focus on the simplest and most common case of items with unique ISBNs. On Mon, Jul 28, 2008 at 10:13 AM, Bryan Baldus [EMAIL PROTECTED] wrote: On Thursday, July 24, 2008 7:55 PM, David J. Fiander wrote: 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. The system would need some way of dealing with duplicate (reused) ISBNs or items with no ISBN. Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses 1-800-323-4241x402 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] Thinking about receiving
David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: [OPEN-ILS-DEV] Thinking about receiving
Carri, The packing slip doesn't have an invoice # on it? If that's the case, perhaps MIke's idea about using the PO # is better. I'm a bit concerned about shipments containing odd mixtures of items from various POs; it seems more likely that a shipment will match an invoice than that it will match a PO. As far your second paragraph about multiple copies, this is exactly why I got fuzzy in my original thinking. Thanks for the suggestions. -David On Mon, Jul 28, 2008 at 10:43 AM, Carri L. Oviatt [EMAIL PROTECTED] wrote: David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: [OPEN-ILS-DEV] Thinking about receiving
David Fiander [EMAIL PROTECTED] 7/28/2008 9:40 AM Carri, The packing slip doesn't have an invoice # on it? --Sometimes, but not always. I do like the idea of tying the receipt to an invoice. Especially since many of our invoices are electronically downloaded. Will there be some way of automatically verifying that all items on an invoice have been received? If that's the case, perhaps MIke's idea about using the PO # is better. I'm a bit concerned about shipments containing odd mixtures of items from various POs; it seems more likely that a shipment will match an invoice than that it will match a PO. --You are right about this. How feasible is it to have a PO, Vendor (for mixed POs), or Invoice option? As far your second paragraph about multiple copies, this is exactly why I got fuzzy in my original thinking. Thanks for the suggestions. -David On Mon, Jul 28, 2008 at 10:43 AM, Carri L. Oviatt [EMAIL PROTECTED] wrote: David, This sounds like a lot of thought has been put into the process. One question about the invoice #. Many times we only receive a packing list with the books/media that are being received. Would we then have to wait for an invoice? If so, that could really slow things down. As far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: [OPEN-ILS-DEV] Thinking about receiving
On Thursday 24 July 2008 8:54 David J. Fiander 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 seems like a reasonable approach. I guess this screen will also have a box for ISSN, etc. I think it would also be good to support using the PO as the receiving entry point. Assuming the PO number is included with the invoice, staff can pull up the PO by ID and mark all items or individual items as received. Dan S. also submitted a work flow at http://open-ils.org/dokuwiki/doku.php?id=acq:scenarios:receiving_monographs -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
SPAM: Re: [OPEN-ILS-DEV] Thinking about receiving
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
