X12 - incorrect mapping

[nycbauer]

There is an issue with the L1000A_835Map. It is incorrectly marking the TechnicalContactInformation as required when it is only situational.

As well, all of the PER types segments on this layout should all be SegmentLists as they can repeat up to twice.

[ahives]

@nycbauer Is this still an issue after our chat room discussion?

[nycbauer]

I've investigated this further, and it's a similar but different issue. In the L1000A loop there are two PER sections, the first is the Payer Business Contact Information, which starts as PERCX, and that is an optional segment, while the next one is the Payer Technical Contact Information which comes in as PERBL, which is required.
When the parser gets to the first PER parser, it says it found it, but it found the PERBL, not the PERCX (which is not found, but is OK). It should also be checking the Contact Function Code to determine if it is in fact the correct match.

[ahives]

If BusinessContactInformation is present it must have at least ContactFunctionCode. Everything else can be empty. Do you have some data that is not real to show the issue so that I can create tests with?

[nycbauer]

Right, but my situation is where there is no BusinessContactInformation.

You can try this file
Test835x12.txt

[ahives]

fixed in 1.0.239

[nycbauer]

Issue85_passing.txt
Attached is the same file as above but with an added PERCX line above the PERBL so that it will pass.

[ahives]

If a Layout was defined that has an optional segment of a particular type and the very next property as a required list of segments of the same type the parser gets confused. A good example of this is L1000A_835. It defines a segment BusinessContactInformation that is optional followed by a segment list TechnicalContactInformation that is required. The parser seems to get confused here because if the optional one, BusinessContactInformation, is missing it doesn't understand how to parse the other one. Also, I think this may be a problem moving forward if it confuses these and add BusinessContactInformation into the segment list that is TechnicalContactInformation

[phatboyg]

So, you realize there isn't any way to differentiate between the two different segments at this point, given how the parser is mapping segments right now, right?

With this:

        Segment<PER> BusinessContactInformation { get; }
        
        SegmentList<PER> TechnicalContactInformation { get; }
        
        Segment<PER> PayerWebsite { get; }

There needs to be a way in the mapping to specify a condition beyond just [0] == "PER" - since it depends upon values defined in other elements of the segment.

[ahives]

Now that I think about it, this is similar to the issue in HL7 for orders where you should be able to OR segments (issue #34). This problem is exceptionally difficult for a couple reasons:

• Some segments are optional
• They are of the same type of entity
• There is a segment list involved
• They are defined back-to-back

Would it be wrong to just represent it as:
SegmentList<PER> ContactInformation { get; }

I am assuming there is something in the segment that separates them apart anyway.

[phatboyg]

So, this solves the broker test.

[phatboyg]

Dude, you broke the test by putting an invalid character in the time. Look at your diff, that test worked before

[ahives]

This is fixed in 1.0.241. Waiting confirmation from @nycbauer

[nycbauer]

Confirmed! Thank you very much!