Segment 'NM1*QD*1*CLAY*MARTONN*C' in segment position 26 within transaction '681560001' cannot be identified within the supplied specification for transaction set 837 in any of the expected loops: 2000A[1],2000B[2],2010BB. To change this to a warning, pass throwExceptionOnSyntaxErrors = false to the X12Parser constructor. Parameter name: 837

[mamohanma]

Hello,
When i am using OopFactory.X12.UnbundleX12, i am getting an error in Segment 'NM1QD1CLAYDEQUINTON*C' in segment position 26 within transaction '681560001' cannot be identified within the supplied specification for transaction set 837 in any of the expected loops: 2000A[1],2000B[2],2010BB. To change this to a warning, pass throwExceptionOnSyntaxErrors = false to the X12Parser constructor. Parameter name: 837 in X12Parser.cs.

can anyone advice this how to resolve this issue.

[JeffreyZolaVisibilEdi]

It does not appear that you have a complete set of delimiters in this segment. It is not properly formed X12!

There is one asterisk before the "C" - which looks like this individual's middle initial - but that's it.

There should be an asterisk after the NM1 segment identifier.

It appears that the NM101 & NM102 are some combination of the "QD1" sequence. But there's nothing that defines "QD" as an Entity ID code. "1" means "Individual." There should be asterisks between the elements.

It appears that NM103 - NM105 (the name elements) define the referenced individual as "Quinton C. Clayde." But there is no asterisk between the last & first names - just the sole one before the MI.

[mamohanma]

Thanks Jeff Zola.

and, I have one more question in Unbundle.X12 process. In this case can we do skip the error and process next ST* segment.
It's possible to do?

[JeffreyZolaVisibilEdi]

Without knowing what you are specifically doing, I cannot give a specific answer.

It appears that you are parsing an X12 837 claim file. If the sender of the file is expecting an acknowledgement of sorts (997, 999 or TA1), I suppose the "protocol" would be to create and return as complete of a response as possible, and include all nonconformities that are present and identifiable. This, to me, would mean reporting the nonconforming NM1 segment within this response, and continuing to parse the rest of the document in order to identify whether the rest is compliant or nonconforming.

Do you want to skip this error, ignoring it, while processing and "accepting" the rest of the file?

• Does the rest of the data lose its context if this name segment cannot provide its intended information in its current state?
• Do you owe it to the upstream party to notify them that they have transmitted nonconforming data?
• Do aspects of your business model allow or require or suggest that you should accept non-conforming files - and possibly correct simple, identifiable deficiencies?