We’re testing EDI with a new partner. They sent us an X12 group of 850 purchase orders and we returned an auto-generated FA from TN. We’ve never had a problem with this but they are telling me that their system is rejecting the FA because of the character used in the subfield delimiter (ISA16) and they want use to use “something else”. My questions are:

1. Is it possible to alter the delimiters used by the auto-generated FA? It appears to use whatever was on the inbound, but if the partner rejects their own delimiter. . .

2. Is it possible that the character is being decoded improperly by TN when it converts the bytes to a string? How can I check the encoding on a standard EDIINT document?

I could roll my own FA generation service for use with this one partner, but this is not desirable for numerous reasons. I’ve requested the partner change their delimiter but I’m not optimistic about their cooperativeness. Thanks,

Tim

Partner did agree to change delimiters. I’d still be interested in any response to the original post. Setting delimiters in the EDITPA also does not seem to have any effect on the delimiters used in the auto-generated FA. Thanks,

Tim

Tim,
You can feed the auto-generated FA into convertToValues and then convert the values to string using the delimiters defined in the EDITPA.

Shubhro

Interesting idea. It also occurred to me that I could queue them up and deliver them in batches, which would also allow me to take advantage of the EDITPA delimiters. To deliver them as they arrived might be a little tricky, as I would want to submit the “transformed” FA to TN also so I could view what actually got sent out in the transaction screen. But I would only want to deliver the transformed FA and not the original version. This would entail some tuning/ordering of the rules, setting statuses or attributes, etc. Thanks for the suggestion,

Tim