imsweb/x12-parser

X12Reader - getMatchedLoop unable to handle 271 LS and LE segments

nddipiazza opened this issue · 1 comments

Steps to reproduce: from https://github.com/nddipiazza/x12-parser/tree/issue_48_add_271_5010_support

Run the test com.imsweb.x12.reader.X12ReaderTest#test271_5010

This code in

com.imsweb.x12.reader.X12Reader#getMatchedLoop

                // starting a new loop but we aren't quite sure which one yet. Remove loops where the segment is known to be the last segment of that loop - clearly we aren't in a new loop then
                matchedLoops = matchedLoops.stream().filter(lc -> lc.getLastSegmentXid() == null || !(lc.getLastSegmentXid().getXid().equals(tokens[0]) && codesValidatedForLoopId(tokens, lc.getLastSegmentXid()))).collect(
                        Collectors.toList());
                result = matchedLoops.isEmpty() ? null : (matchedLoops.size() == 1 ? matchedLoops.get(0) : getFinalizedMatch(previousLoopID, matchedLoops));

Does not work for the segment LE. It will pick the wrong value in this situation.

I have put in a hack locally and it fixes my problem:

                if ("LE".equals(tokens[0])) {
                    // the below logic doesn't work for the LE segment.
                    // in this case we will just hack around the issue. if the previous loop ID ends with a C such as 
                    // with 2120C, then return the 2110C loop config (index 0). Otherwise return 2110D loop config (index 1).
                    return previousLoopID != null && previousLoopID.endsWith("C") ? matchedLoops.get(0) : matchedLoops.get(1);
                }

what is the intention for that logic? why doesn't it work for this one situation?

I will take a look.