1
Vote

Parsing Edi to Json and back to X12

description

Greetings.

Let me first preface my post that I'm fairly new to working with EDI and the X12 format.

I'm attempting to parse a JSON based version of a previously parsed X12 string BACK into a valid X12 document. The JSON as XML and the EDI as XML both match... But when attempting to use the TransformToX12 library I'm not getting the entire EDI string as X12.

However, when I do the conversion from JSON back to X12 I only get the interchange.

I've attached a sample C# program with my test. The output is below.

Any help is greatly appreciated.

Thanks,

Jon

**** Sample Application Output ****
Welcome to the Edi Conversion Tester
Test Edi : ISA * 00 * *00 * *08 * 6122650000 * 01 * 0130113 * 170130 * 1705 * U * 00401 * 856000361 * 0 * P *> ~GS * SH * 6122650000 * 0130113 * 20170130 * 1705 * 856000361 * X * 004010~ST * 856 * 0001~BSN * 00 * 17063401301700009 * 20170130 * 170528 * 0001~HL * 1 * *S~TD1 * CTN76 * 1 * ***G * 2.4 * LB~TD5 * ****UPS Collect~REF * BM * 0000027747506~DTM * 011 * 20170130~N1 * ST * *92 * 79~HL * 2 * 1 * O~PRF * nbq1 - 79 * **20160802~TD1 * CNT25 * 1 * ***G * 2.4 * LB~HL * 3 * 2 * P~MAN * GM * 00008839053384255627~HL * 4 * 3 * I~LIN * *UP * 190325857165 * VA * W1080BY7 * SZ * 12~SN1 * *1 * EA~CTT * 4~SE * 18 * 0001~GE * 1 * 856000361~IEA * 1 * 856000361~


Edi as XML

<?xml version="1.0"?><Interchange segment-terminator=" " element-separator=" " sub-element-separator="*"><ISA><!--Author Information Qualifier--><ISA01><ISA0101 /><ISA0102 /></ISA01><!--Author Information--><ISA02>00</ISA02><!--Security Information Qualifer--><ISA03><ISA0301 /><ISA0302 /></ISA03><!--Security Information--><ISA04><ISA0401 /><ISA0402>00</ISA0402></ISA04><!--Interchange ID Qualifier--><ISA05><ISA0501 /><ISA0502 /></ISA05><!--Interchange Sender ID--><ISA06><ISA0601 /><ISA0602>08</ISA0602></ISA06><!--Interchange ID Qualifier--><ISA07><ISA0701 /><ISA0702 /></ISA07><!--Interchange Receiver ID--><ISA08>6122650000</ISA08><!--Interchange Date--><ISA09><ISA0901 /><ISA0902 /></ISA09><!--Interchange Time--><ISA10>01</ISA10><!--Inter Control Standards Identifier--><ISA11><ISA1101 /><ISA1102 /></ISA11><!--Inter Control Version Number--><ISA12>0130113</ISA12><!--Inter Control Number--><ISA13><ISA1301 /><ISA1302 /></ISA13><!--Acknowlegment Requested--><ISA14>170130</ISA14><!--Usage Indicator--><ISA15><ISA1501 /><ISA1502 /></ISA15><!--Component Element Separator--><ISA16>1705</ISA16><ISA17><ISA1701 /><ISA1702 /></ISA17><ISA18>U</ISA18><ISA19><ISA1901 /><ISA1902 /></ISA19><ISA20>00401</ISA20><ISA21><ISA2101 /><ISA2102 /></ISA21><ISA22>856000361</ISA22><ISA23><ISA2301 /><ISA2302 /></ISA23><ISA24>0</ISA24><ISA25><ISA2501 /><ISA2502 /></ISA25><ISA26>P</ISA26><ISA27><ISA2701 /><ISA2702>></ISA2702></ISA27><ISA28>~GS</ISA28><ISA29><ISA2901 /><ISA2902 /></ISA29></ISA></Interchange>

Edi Converted from X12 to JSON

{"?xml":{"@version":"1.0"},"Interchange":{"@segment-terminator":" ","@element-separator":" ","@sub-element-separator":"*","ISA":{"#comment":[],"ISA01":{"ISA0101":null,"ISA0102":null},"ISA02":"00","ISA03":{"ISA0301":null,"ISA0302":null},"ISA04":{"ISA0401":null,"ISA0402":"00"},"ISA05":{"ISA0501":null,"ISA0502":null},"ISA06":{"ISA0601":null,"ISA0602":"08"},"ISA07":{"ISA0701":null,"ISA0702":null},"ISA08":"6122650000","ISA09":{"ISA0901":null,"ISA0902":null},"ISA10":"01","ISA11":{"ISA1101":null,"ISA1102":null},"ISA12":"0130113","ISA13":{"ISA1301":null,"ISA1302":null},"ISA14":"170130","ISA15":{"ISA1501":null,"ISA1502":null},"ISA16":"1705","ISA17":{"ISA1701":null,"ISA1702":null},"ISA18":"U","ISA19":{"ISA1901":null,"ISA1902":null},"ISA20":"00401","ISA21":{"ISA2101":null,"ISA2102":null},"ISA22":"856000361","ISA23":{"ISA2301":null,"ISA2302":null},"ISA24":"0","ISA25":{"ISA2501":null,"ISA2502":null},"ISA26":"P","ISA27":{"ISA2701":null,"ISA2702":">"},"ISA28":"~GS","ISA29":{"ISA2901":null,"ISA2902":null}}}}

Edi Converted from Json to X12

ISA * 00 * *00 * *08 * 6122650000 * 01 * 0130113 * 170130 * 1705 * U * 00401 * 856000361 * 0 * P *> ~GS *
Comparing Test Edi with parsed and reconstituted Edi


Edi Match Failure : Conversion and Reconstitution Failed
End of Line

file attachments

comments

dstrubhar wrote Jun 19 at 5:54 PM

This might be more appropriate for the discussion forum, but just from reviewing your comments, I am unsure that you are actually using this parser in your program.

The ISA segment is fixed-width and ends with ISA16. See example here https://x12parser.codeplex.com/wikipage?title=Parsing%20an%20837%20Transaction&referringTitle=Home.

What you are parsing is not recognizing the segment delimiter ~ and is treating your entire file as ISA segments. This is why I doubt this code is generated from the parser.

After the parser inspects the first 106 characters. It uses the last character ~ as the segment delimiter in the rest of the file.

The fact that your ISA segment goes up to ISA29 means that you have ignored all delimiters in your parse.

dstrubhar wrote Jun 19 at 5:56 PM

Also, whitespace is very important in a true X12 transaction, if you have injected any unexpected whitespace in the first 106 characters that may also be affecting your ability to find the delimiters.

jonwmccain wrote Jun 19 at 6:19 PM

Thank you @dstrubhar and yes I realized after I clicked post that I put it into the wrong place. My sincere apologies for that.

I am using version X12Parser 3.0.8.1 from NuGet to parse this EDI. I got the EDI Contents from an example within our system. It is possible that the example had already been manipulated and therefore didn't have all the appropriate information within it.

AFAIK, I'm not injecting any whitespace with the methods I'm using.

I'll review your example and make sure that I'm parsing it correctly.

Regards,

Jon

jonwmccain wrote Jun 19 at 6:42 PM

I grabbed the example EDI from the link above and removed the carriage returns from it. After moving through the various conversions the change appears to be within ISA00..........01SECRET within TransformToX12, the periods are to denote 10 spaces and do not actually exist..

The flow is the document is converted into an XML document using the ParseMultiple() followed by the serialization of the resulting document. It is then passed to the TransformToX12 executable where upon conversion from XML to X12 the spacing seen above denoted by the aforementioned periods is now seen as four spaces.

Original:

ISA
00
01SECRET ZZSUBMITTERS.ID ZZRECEIVERS.ID 0301011253^005010000009051T:~GSHCSENDER CODERECEIVER CODE1999123108021X005010X222~ST8370021005010X222~BHT001900244579200610151023CH~NM1412PREMIER BILLING SERVICE46TGJ23~PERICJERRYTE3055552222EX231~NM1402KEY INSURANCE COMPANY4666783JJT~HL1201~PRVBIPXC203BF0100Y~NM1852BEN KILDARE SERVICEXX9876543210~N3234 SEAWAY ST~N4MIAMIFL33111~REFEI587654321~NM1872~N32345 OCEAN BLVD~N4MAIMIFL33111~HL21221~SBRP2222-SJCI~NM1IL1SMITHJANEMIJS00111223333~DMGD819430501F~NM1PR2KEY INSURANCE COMPANYPI999996666~REFG2KA6663~HL32230~PAT19~NM1QC1SMITHTED~N3236 N MAIN ST~N4MIAMIFL33413~DMGD819730501M~CLM2646377410011:B:1YAYI~REFD917312345600006351~HIBK:0340BF:V7389~LX1~SV1HC:9921340UN11~DTP472D820061003~LX2~SV1HC:8707015UN11~DTP472D820061003~LX3~SV1HC:9921435UN12~DTP472D820061010~LX4~SV1HC:8666310UN12~DTP472D820061010~SE420021~GE11~IEA1000000905~

POST Conversions (X12 -> XML -> X12)

ISA0001SECRET ZZSUBMITTERS.ID ZZRECEIVERS.ID 0301011253^005010000009051T:~GSHCSENDER CODERECEIVER CODE1999123108021
X005010X222~ST8370021005010X222~BHT001900244579200610151023CH~NM1412PREMIER BILLING SERVICE
46TGJ23~PERICJERRYTE3055552222EX231~NM1402KEY INSURANCE COMPANY4666783JJT~HL1201~PRVBIPXC203BF0100Y~NM1852BEN KILDARE SERVICEXX9876543210~N3234 SEAWAY ST~N4MIAMIFL33111~REFEI587654321~NM1872~N32345 OCEAN BLVD~N4MAIMIFL33111~HL21221~SBRP2222-SJCI~NM1IL1SMITHJANEMIJS00111223333~DMGD819430501F~NM1PR2KEY INSURANCE COMPANYPI999996666~REFG2KA6663~HL32230~PAT19~NM1QC1SMITHTED~N3236 N MAIN ST~N4MIAMIFL33413~DMGD819730501M~CLM2646377410011:B:1YAYI~REFD917312345600006351~HIBK:0340BF:V7389~LX1~SV1HC:9921340UN11~DTP472D820061003~LX2~SV1HC:8707015UN11~DTP472D820061003~LX3~SV1HC:9921435UN12~DTP472D820061010~LX4~SV1HC:8666310UN12~DTP472D820061010~SE420021~GE11~IEA1000000905~

jonwmccain wrote Jun 19 at 6:54 PM

QUICK UPDATE:

I believe I may have found the issue. It would appear that the mechanism which is logging this information for us appears to be changing the semi-colon that denotes the end of the interchange, or so I believe, is getting changed to a 'greater than sign' which is likely due to a failure to parse the document within our system and then it is being logged incorrectly.

I'm looking into whether changing that back to a semi-colon resolves the issue. Thank you for guidance and clarification thus far.
  • Jon

jonwmccain wrote Jun 19 at 7:41 PM

I've tried some other EDI documents along with the example provided above and the same issue occurs where the whitespace found in the first two positions of the EDI document is getting modified to either less than it was or remove entirely.

I believe the issue MAY be the conversion from the X12 to JSON which I'm currently doing by taking the resulting XML that is provided from the X12Parser and using Newtonsoft.JsonConvert.SerializeXmlNode() method to convert it to JSON.

I'm not seeing a parameter in any of the methods to preserve whitespace. I do recall another discussion post regarding a suggested change to the parser to handle whitespace...

https://x12parser.codeplex.com/workitem/2811

I plugged that into my example app and it appeared to resolve the initial issue but caused others. So, I'm thinking that there is more to it than that... but maybe that's the right direction.