Comment 2 for bug 1373690

Code is still unsquashed and in progress, but much testing has occurred as a result of the hackfest (and beyond). It's not ready for a pullrequest yet, but I'd like to encourage anyone who can to test.

Testing by comparing new EDI to existing EDI for the same order:

 * Install the branch and run the DB upgrade (XXXX.data.acq-order-edi.sql).

 * Reset an activated PO so it can be re-activated. For this example, assume PO ID is 3.

UPDATE acq.purchase_order SET order_date = null, state = 'pending' WHERE id = 3

 * Load PO #3 in the interface and activate it.

 * Wait for action_trigger_runner.pl to process the event or run it manually. This will result in EDI output for the action/trigger event.

 * Locate the EDI output for the re-activated PO.

SELECT out.data FROM action_trigger.event_output out JOIN action_trigger.event evt ON (evt.template_output = out.id) WHERE evt.event_def = 54 AND evt.target = 3;

* Compare the old EDI (from acq.edi_message) with the new EDI (from above) OR paste the values somewhere and point me at them.

* If you run edi_pusher.pl on the test machine, avoid any unexpected behavior (trying to re-send the order -- which would fail for parsing reasons), set the state of the new event to 'error':

UPDATE action_trigger.event SET state = 'error' WHERE event_def = 54 AND target = 3;

Caveats:

 * The template is based on the stock seed JEDI template (event_def 23), which may have settings that differ from your local template (e.g. INC_COPIES = true/false).

 * This code does not disable the JEDI template. It will still operate as before.

 * Some fields contain dates and will generally differ across versions if comparing via 'diff', etc.