Ansi-837 5010 file with newline (LF) as a segment delimiter.

Oct 22, 2013 at 7:40 PM
I have a company sending files with what appears to be a line feed as the segment delimiter.

The first character begins with an "R" as in "RISA" When I strip the "R" from the beginning character position 106 seems to be a line feed. And from a brief look at the file, there appear to be new lines where the delimiters should be.

Unfortunately the program will bomb later with the following;

Segment '' in segment position 1707 within transaction '0001' cannot be identified within the supplied specification for transaction set 835 in any of the expected loops: . To change this to a warning, pass throwExceptionOnSyntaxErrors = false to the X12Parser constructor.
Parameter name: 835.

First do "Line Feeds" work as a segment separator?

If so how can I trouble shoot the subsequent message?
Oct 22, 2013 at 9:26 PM
Edited Oct 22, 2013 at 9:28 PM
To answer my own question;

Yes Line feeds work as segment Separators.

To make an enhancement request/bug-fix;
> It appears that when this particular submitter creates their files not only do they add an "R" to the beginning as in "RISA" they also do not provide the last line feed so the last segment looks like "IEA*1*000000363" without a segment separator at the end. I have modified my program to look to see if the last character matches the character in position 105 of the file. If it does not match I append the character from 105 to the end of the file.
My request would be to either do the same, or treat "end of file" as segment terminator.
Oct 22, 2013 at 11:52 PM
Well, the operation was a success, but the patient died.

In my last post I indicated there was no segment separator at the end. That wasn't true. There was a segment separator, but it was followed by a chr(26) (End of File in some OSes). Dannie, you may wish to check for that.

So now my program removed the "R" at the beginning, and the chr(26) at the end, and the file processed without any errors. But no data was extracted. I ran it on about 20 similarly defined files from the same vendor, and I get the same results, no errors, but no claims inserted into the DB.

So I am at a total loss, because I am getting no errors. I tested on a file from a different vendor that was a known working file, and it worked.

The files that have a chr(13) at position 106 and a chr(10) at position 107 and use both as a segment separator do not report an any errors, but no data is inserted into the DB.
Oct 22, 2013 at 11:57 PM
You can have a line feed chr(13) as your separator, but it must be exactly one character. The chr(13) followed by chr(10) CRLF will not work. You might have your pre-processor change all CRLF to just CR.
Oct 23, 2013 at 12:25 AM
Dannie not to be particular, but CHR(13) is CR and chr(10) is LF, can I have either? If not should I get rid of chr(10) (LF) or chr(13) (CR)?
Oct 23, 2013 at 12:35 AM
Actually I tried both removing the CR then tried removing the LF. I got the same results, the file processed with no errors, and no data got into the DB.
Oct 24, 2013 at 7:39 PM
I have tracked the problem down to a line in "public ClaimDocument Transform837ToClaimDocument(Interchange interchange)";
 return ClaimDocument.Deserialize(xml);
The xml looks reasonable, but it returns a document with no children.

I stepped into the ClaimDocument.Deserialize routine which is two lines long, and tried to step into the routine it called, but it provided nothing I could understand.

I need help from a person that can guide me to the solution on this one.
Oct 25, 2013 at 4:14 PM
At this point I would suggest that you replace the CRLF combo with a single not white space character. This should be any character that will not appear within the content of any segments. Usually a ~ or ^ will work if those aren't already being used as element or component separators.
Oct 25, 2013 at 8:36 PM
Edited Oct 25, 2013 at 8:43 PM
What I propose is the following for my preprocessor, where strTemp is a string that contains the entire file.
If strSegmentSeparator = vbCr Or _
   strSegmentSeparator = vbLf _
    Dim strReplaceSegmentSeparator As String
    Dim intTildeFound As Integer = InStr(strTemp, "~")
    If intTildeFound = 0 _
        strReplaceSegmentSeparator = "~"
        Dim intCarretFound As Integer = InStr(strTemp, "^")
        If intCarretFound = 0 _
            strReplaceSegmentSeparator = "^"
            strReplaceSegmentSeparator = vbCr
        End If
    End If
    strTemp = Replace(strTemp, strSegmentSeparator, strReplaceSegmentSeparator)
    strTemp = Replace(strTemp, vbCr, "")
    strTemp = Replace(strTemp, vbLf, "")
End If
Oct 25, 2013 at 9:08 PM
After implementing the code above, the preprocessor successfully replaces the line terminators with "~" but I get the same results. It appears that they are using an angle bracket as one of the sub-segment separators. Could this be causing the problem?

After my preprocessor runs this is the first 106 bytes;
ISA*00*          *00*          *ZZ*111111111      *ZZ*222222222      *111111*1111*U*00401*000092546*0*P*<~
I changed the values that that show as multiple 1s and 2s because I was too lazy to see if they contained any identifying info.

Using a program called EDI File Editor V when I open the file created from the preprocessor, it does not see any errors, it says the element separator is * (2A), Segment Separator is ~ (7E), and the Sub Element Separator is < (3C).
Oct 25, 2013 at 9:23 PM
It appears that you need to strip out all of your whitespace.
Since the file was already using the < as the segment separator, it was treating the whitespace as the beginning of the segment and not recognzing the segment identifiers.
Sometime systems add this whitespace after a parse so that it can viewed by humans easily, but it is no longer valid X12.
Oct 25, 2013 at 10:26 PM
Edited Oct 25, 2013 at 10:31 PM

I'm not sure what you mean. If I find either a CR or LF at 106, I replace that character with a "~" throughout the entire file, and then I remove all CR and LF in the entire file. When I am done (before I convert to stream and send to ParseMultiple), there are no CR or LF in the file. For giggles, I also removed chr(0), with no positive effect.

Th "<" character is used as a "Sub Element Separator" not a "Segment Separator", as far as I can tell. The "<" is in position 105, the "~" is in 106.
Oct 25, 2013 at 10:44 PM
I would need to see more of your file after the ISA segment.
Basically, the ISA segment should be immediately followed by the GS segment without any white spaces.
If it doesn't see all the control segments it expects it won't even see the transactions.

Can you post up to the end of the ST segment?
Oct 25, 2013 at 11:41 PM
After Preprocessing;
ISA*00*          *00*          *ZZ*133052274      *ZZ*650753936      *131003*0700*U*00401*000092546*0*P*<~GS*HP*133052274*650753936*20131003*0700*1*X*004010X091~ST*835*0001~
Before Preprocessing;
RISA*00*          *00*          *ZZ*133052274      *ZZ*650753936      *131003*0700*U*00401*000092546*0*P*<
Oct 26, 2013 at 1:21 AM
Your problem is that this is not an 837 claim file. It is an 835 claim payment advice file.

The plain jane X2 parser will parse this into the 835 format, but the ClaimDocument will not find the necessary 837 elements thus is parsing blank Claims.

the number after ST* indicates the format. You should have your pre-processor check for that and reject unexpected files.
Oct 28, 2013 at 3:12 PM
Thanks for pointing that out. I can certainly update the preprocessor section of my program to find the ST segment and check this.

Would this be a beneficial enhancement to X12parser, to check this and report an error when it was not an ansi 837 format?

Also, are there other things I should look for, that might define problems, such as an indicator indicating that it is a 5010 format file?