Acq: EDI omnibus bugfix package

Acq: EDI omnibus bugfix package

EDIReader bugfix - Process misc charges better
    MOA+304 seems to be an encoding peculiar to Ingram for processing fees.

Bubble up errors better from invoice processing
    Errors were getting logged, but weren't linked on the related
    acq.edi_message row in the database like they could have been to make
    debugging easier.

    This incidentally elevates one possible message from warning level to
    error, but even as a warning it was stopping the processing of the
    invoice in question there.  So there's no meaningful difference.

Try harder to associate incoming EDI messages with exact right account
    Sites use many very nearly identical EDI accounts (same host and
    credentials) with different values only for the label and the vendcode.
    This allows mapping of an order to a profile on the vendor side.

    The problem with this is that the edi_fetcher and the processes it
    kicks off did not know how to map incoming messages to the right
    account based on vendcode.  That code simply iterated through
    accounts, using host information and login credentials, and grabbing
    what it can find, as if
    there will be no other Evergreen-side EDI "accounts" with the same
    hostname and loging credentials.

    This should help with that.

Style and whitespace cleanups in O::A::Acq::EDI.pm
    All I could stand before I just couldn't take it anymore.

New PO template created malformed JSON in the INC_COPIES=0 case
    And now it no longer should.

Allow order responses and invoices to omit PO repetition in lineitem refs
    Usually vendor documents have bits of EDI that look like:
    RFF+LI:100/123
    where 100 is a PO number and 123 is a lineitem number.

    Sometimes, for some documents, B&T at least will omit the '100/' part.
    This is fine because we don't really need that number repeated for
    every lineitem.  We do need this change so that our EDI reader code
    can deal with the omission, though.

Be more liberal reading EDIFACT message reference number
    Spec, if I read it correctly, says that this is alphanumeric, not just
    numeric, and ULS is one vendor I've seen taking advantage of letters
    and numbers in that space.

    This commit makes the relevant regex in our EDIReader appropriately
    more tolerant.

Fixes to new vencode parsing for incoming EDI messages

Prevent problem in preventing EDI re-retrieves
    The query we were using before would needlessly transfer large objects,
    potentially hitting Jabber message size limits.

    We're just testing for the existence of such objects, so we need no
    more than a single ID in the result.

Fix EDI invoices for ULS, improve troubleshootability
    1) Taxes appear in different, but still valid way in ULS invoices than
    in invoices from other vendors observed to date.

    2) Invoices from ULS use MOA 203 to indicate unit price instead of the
    usual meaning of whole-lineitem price.

    3) Now abuse acq.invoice.note to leave better troubleshooting
    breadcrumbs.

Invoices from EDI had unsavable invoice_items attached
    Deal with this by letting us create fund_debits a little later than in
    the previous workflow. We have to, because the EDI-level stuff creating
    the invoice doesn't know what fund we want to target for taxes and misc
    charges.

    The problem we're fixing manifested by showing an alert() dialog about
    ACQ_FUND_DEBIT_NOT_FOUND.

Signed-off-by: Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>
Signed-off-by: Bill Erickson <berick@esilibrary.com>