X12Reader - getMatchedLoop unable to handle 271 LS and LE segments
nddipiazza opened this issue · 1 comments
nddipiazza commented
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?
angelaszek commented
I will take a look.