Acq: We need to fully implement EDI availability codes

[Chris Sharp]

Evergreen's acq implementation reads and stores lineitem availability codes from EDI order response (ORDRSP) messages, but doesn't really do anything with them. Since at least one vendor that PINES libraries order from uses these codes to automatically cancel or otherwise indicate a delay (such as a backorder), we should use them to do so. They are documented in EDItEUR's EDI documentation for the ORDSRP message:

http://www.editeur.org/files/EDIfact%20eancom%20pdfs/EDIfact%20library%20supply/L5ordrsp%20(library%20supply).pdf - pages L-5-40 and L-5-41.

[Chris Sharp (chrissharp123)]

Untested working branch available here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1627373_edi_availability_codes

I decided to limit this to codes that we need for libraries that use Brodart, who provided me a list of codes and how they treat them on their end. My implementation does not add any cancel_reasons, but uses either "Delayed: Backordered" or "Canceled: By Vendor", depending on how Brodart handles them. I'm very interested in further use cases for this, but since this is the first bug report I've seen on this issue, I'm guessing we're the first to run into the problem.

[Chris Sharp (chrissharp123)]

Bill Erickson kindly pointed out an error in my Perl code. The corrected version is available at the above link.

[Chris Sharp (chrissharp123)]

Okay, after reviewing the way EDI gets processed for item statuses in Evergreen right now, I'm pretty sure my branch isn't going to do much. The code block that processes EDI availability (8B) statuses only runs if the incoming EDI file doesn't account for all ordered copies in the quantity type codes (6063 - see http://www.unece.org/fileadmin/DAM/trade/untdid/d16a/tred/tred6063.htm) or the 12B order status codes (http://www.editeur.org/files/EDIfact%20eancom%20pdfs/EDIfact%20library%20supply/L5ordrsp%20(library%20supply).pdf pages L-5-42 and L-5-43). This means that a lot of relevant data is being ignored/effectively discarded.

I've begun a second branch that stores the 12B and 8B codes in database tables with the idea that we would map them to acq.providers and to acq.cancel_reasons that need to be applied: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1627373_edi_status_codes_db

Even with that, though, I wonder if it wouldn't be better to stop using the acq.cancel_reason mechanism and start recording availability and/or order status codes and just deciding what state the item should land in with each one. It would mean re-writing the business logic within the process_parsed_msg subroutine in Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/EDI.pm, but it seems like an achievable goal if others agree.

[Jane Sandberg (sandbergja)]

We've been getting OP (out of print) statuses from our main vendor, and Evergreen isn't cancelling those line items due to this bug. Very frustrating! Our library is missing out on a lot of information due to this bug (for the 8B statuses) and bug 1770202 (for the 12B statuses).

Chris -- what do you think are our next steps? Start testing your branch, look into the EDI.pm re-write as you mentioned, or something else?