Interchange requires repetition element separator

Feb 12, 2015 at 2:23 PM
Edited Feb 12, 2015 at 5:21 PM
I have my fork disconnected from the main.
I now have a working 5010 270 / 271 implementation of this parser.
I would like to share some of my experience with all of you.

I can't say that the 999 completely works because what I've experienced is that the information source (IS) I send requests to has improperly hardcoded the 999 reject and it's not properly formed. I get back a rudimentary reject and a lot of garbage that never validates. They also don't send AK3 or AK4 segments that would have prevented a LOT of back and forth.

The 270 and 271 work perfectly once I added the repetition separator character (RSC), via addition to the enum, and expanding all constructors to include it. You might think this is a wasted effort, as this is a 'sending source' (the receiver) defined field. The problems are this:
  1. This library has hard-coded an upper case 'U', which is illegal as a it's a plain text character.
    Well, ok, so just pick another non plain text, say ']', right? ...4 days later...
  2. The IS hard coded '%' as the only acceptable character for this field, and summarily rejects any 270 without it.
So from the above, I needed to instantiate the Interchange element with a specific repetition character and expanded the library to include it.

Note: When you parse your data, don't forget to HTML Decode the string, in case the Payor sent something like '>' as a separator character, which might be HTML encoded over the wire...

There needs to be an 'orchestration class' above the parser, with 'situational flags' to fire off when to add loops & segments, portions of a segment, or to not include loops and segments. I am working on this now.

Feb 17, 2015 at 6:46 PM
I'm sure the hard coded 'U' comes from 3051/4010 usage where ISA11 was a standards identifier vs a repition separator. Did you extend X12DelimiterSet to house the repitition character? I would be very interested to see your branch/patch for this as it's a problem we'll all encounter.
Feb 18, 2015 at 2:19 PM
Edited Feb 18, 2015 at 2:22 PM
I updated it, rather than extend, as my sole purpose was using this library for 5010. Perhaps you're right; I'll extend instead.

I also updated the constructors of the Interchange to allow its specification. I think that should be a permanent change, with defaulted parameter values.

I'm still not getting the 2100C EB segment to properly break out when EB03 is the repetition element (when all other 2100C info is the same for each service type code). I thought the proper repetition character would have jump started that. Perhaps the xslt doesn't know what to do with it? I need to debug that to see why.

I'd be happy to share, once I get it working correctly.
Feb 18, 2015 at 3:25 PM
Interesting... If you want a parser to at least see what you have for testing your request or response... Here's a jave applet...
Dec 30, 2015 at 5:27 PM
Any updates? I'm very interested in your work since I'm encountering the same issue. Thanks!