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
[OPEN-ILS-DEV] Debian Vmware Image
Is there a Vmware image available for download with out the guttenberg records on debian?
Re: [OPEN-ILS-DEV] XULRunner 1.9
How much work would be needed to get the staff client code to run on XULRunner 1.9? My reason for asking is two-fold: Hi Brandon, I don't know. We just have to try it and work through each issue that comes up. I'm glad 1.9 is deemed a stable release now; and I'm all for working on this. Previously the 1.9pre series seemed to change too rapidly for me. (1) it would be incredibly convenient to package up the staff client application with a copy of Portable Firefox 3 for Windows users, and distribute that instead of an installer. Also, if we're developing on the same (or similar) runtime as FF3, it'd be feasible to make a Firefox extension version of the staff client (the original prototype used to be a Mozilla plugin and Firefox extension). My only concern with this is that extensions aren't able to prevent or warn users from upgrading Firefox out from underneath the installed extensions. I'm still hoping for the day Firefox will run on an independent xulrunner. (2) Neither of Ubuntu Hardy's XULRunners (for example) completely support the staff client - the patron editing interface fails with a security error, the precise details of which escape me at this moment -- though I see there was some discussion about 1.9 in #openils back in May. Yeah, Mozilla is getting a lot more strict in the name of security (so if you're using self-signed SSL certificates, for example, then beware). This might also present special challenges for remote xul. -- Jason Etheridge | VP, Community Support and Advocacy | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
