Comment 3 for bug 1627373

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.