Superscript character as field delimiter in EDI

We have a trading partner using version X12 3020 docs with superscript character as the field delimiter.I will post a sample segment here:

ISA³00³ ³00³ ³zz³1014663322 ³01³1122334455 ³040805³0432³U³00300³000000111³0³P³>

So, we are not able to process the EDI Documents of this type.TN is able to recognise this document but the processing service fails

Any help/ideas greatly appreciated.

Why does the service fail? What are the error messages?
Remember the character is displayed differently depending on the system you’re on and the viewer you are using. All TN and EDI care about is the hex value of the Element Separator.
Provide some more details.

We are able to submit data to TN web console-WmTNforEDI.
Submission of one single transaction set passes thru but when we try to submit multiple data the processing fails.

When we do the same operation of submitting the data to the TN through a flow servce it fails again.

Kindly let us know if there are any details relating to setting that needs to be taken care of.

What content-type are you using?
Try Application/EDIStream.

I believe that submitting content with content-type of application/edistream is not supported by TN (see discussion [url=“wmusers.com”]wmusers.com).

A project I’m working on has a partner that is using that same value for the sub-element delimiter. Try setting the content-encoding to ISO-8859-1, either on the submission side or if you have the bytes in your flow, set it in the bytesToString call.

Hi Rob,

application/EDIStream does work. I’ve been using it successfully since 4.6.

Chris

Cool. Thanks for the info Chris.

Thanks Rob & Chris,

Now we are able to submit multiple transactions through flow service by setting Content-type Application/EDIStream.But it fails whenever we tried to process document using wm.b2b.edi:envelopeProcess flow Service.

Any suggetions.

Dude,
What’s the error?

Chris,

wm.b2b.edi:envelopeProcess flow service generating “errorArray” output with the following messages.

<?xml>
<pathname>/ISA/ISA01/code</pathname>
<errorcode>DT-STR001</errorcode>
<errormessage>[B2BCORE.0082.9293] No matching choice value</errormessage>

and generating “Values” output like this:

<?xml>
<isa>>>BasicData:record=0,field=Â,subfield=0,release= <<<">
<isa01>
<code>³</code>
</isa01>
<isa16>0</isa16>
<undefdata>³ ³0³ ³zz³1014663322 ³01³1122334455 ³040805³0433³U³030³0322³0³T³>
GS³IN³1014663322³1122334455³040805³0433³0322³X³03050</undefdata>

Hope this information clarify my situation

Vikram,

You document seems to error on the ISA01 which is usually 00.
However I see that your output is in XML format. The output from envelopeProcess Values, is a record (4.6) or document (6.0).
What exactly are you mapping into edidata?
You should be doing a bytesToString and map that output to edidata.
Maybe you can share the sequence of steps you are following after you document gets to TN.

Yes i am doing a bytesToString and map that output to edidata.Values, is a record(4.6), I am using recordTodocument to convert Values record into XML.This step i used for debugging purpose.

Here is the sequence of steps that execute after document gets to TN:

1.bytesToString
2.envelopeProcess
3.recordTodocument
4.smtp

steps 3 and 4 used for debugging purpose and here is the ISA segment of the EDI document that i submitted to TN.

ISA³00³ ³00³ ³zz³1014663322 ³01³1122334455 ³040805³0432³U³00300³000000111³0³P³>

regards
Vikram

I see “³” in the data of the error message. So your ISA looks to IS to be something like:

ISA³00³ ³00³…

Thus it thinks that  is your element delimiter and ³ is the value of ISA01, which is not a valid value. You need to set the encoding correctly in your bytesToString call. Set it to ISO-8859-1 and ³ won’t be turned into 2 characters during the conversion from bytes to string.

Rob,

Eventhough we set the encoding to ISO-8859-1, it is turning to 2 characters. Could you tell me what may be the reason for this.

Hi

It is working fine. We set the encoding to UTF-8. It is converting Properly and EDI processed successfully.

Thanks Rob & Chris.

regards
Vikram