EDIWriter problems with FTX and LIN

[Jeff Davis]

We received a report with ULS that there are a couple of problems with EDI messages generated by EDIWriter:

1. The FTX line is missing a field. We are producing FTX+LIN+1+First Nations but should be producing FTX+LIN+1++First Nations (note the extra + sign).

2. We are enumerating lineitems using the internal lineitem ID (e.g. LIN+523964), but they should be enumerated sequentially starting at 1 (e.g. LIN+1).

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1949243-edi-ftx-lin has a potential fix for both issues:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=371196c9

No pullrequest yet because I haven't had a chance to test this with the vendor, and because I don't know if this change would cause problems for other vendors.

[Galen Charlton (gmc)]

I've taken a look at the patch. My findings thus far:

[1] Sending "FTX+LIN+1++$note" appears to be correct, both according to EDItEUR and examination of past JEDII-translator output when there's a note. So that part of the patch looks fine.

[2] While my read of the specs agrees that the line sequence number in the LIN lines should indeed be a sequentially assigned number, not Evergreen line item ID... Evergreen has been passing the LI ID there since at least 2010. Even though RFF+LI is what's supposed to used to match up order lines during EDI transactions, I am still left wondering if _somebody_ is storing the line sequence number from an ORDERS message and sending in back in an order response or an invoice.

If ULS considers this a blocker and needs the line sequence number to be sequentially assigned, I suggest adding a new EDI attribute to turn on that behavior in order to be super-conservative.

[Bill Erickson (berick)]

+1 to Galen's suggestion of adding an EDI attribute to control the behavior. I would not be surprised if some vendors rely on those values as-is in some cases.

[Galen Charlton (gmc)]

Oh, I just noticed something:

+ for (my $i = 1; $i <= $li_count; $i++) {
+ $lis[$i]->{seq_id} = $i;

This looks like it would drop the first line item, as arrays in Perl are zero-indexed. Something like this might be better:

for (my $i = 0; $i <= $#lis; $i++) {
    $lis[$i]->{$seq_id} = $i + 1;
}

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1949243-edi-ftx-lin-2 has an updated fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1949243-edi-ftx-lin-2

The fix consists of 2 commits. The first commit has the uncontroversial FTX fix. The second commit adds a new "LINEITEM_SEQUENTIAL_ID" EDI attribute which determines whether the line sequence number is sequential; when the new attribute is not applied, EG's internal lineitem ID will be used, so the existing behavior is unchanged by default. This commit also fixes the issue Galen noticed in comment #4.

My grasp of EDI is shaky and I'm not sure how to generate EDI output without sending it to a vendor, but I think a test plan would be something like this:

1. Set up an EDI account.
2. Create a PO that includes a lineitem note.
3. Generate EDI output. Verify that the FTX line is missing a field and the LIN line is using the lineitem ID.
4. Apply the fix.
5. Add the LINEITEM_SEQUENTIAL_ID attribute to your EDI account.
6. Generate EDI output. Verify that the FTX line is now correct and that the LIN line uses a sequential ID.
7. Remove the LINEITEM_SEQUENTIAL_ID attribute from your EDI account.
8. Generate EDI output. Verify that the LIN line is using the lineitem ID again.