The ISA segment that starts each file is fixed width. The 106th character of the file always represents the segment terminator. This is typically a ~ in most of the specs that I have seen, but there is no requirement for it to be a tilde. Since a separator
character cannot also be used in the content of the x12 message, many systems will choose other delimiter characters that they know will not cause conflicts.

If you wanted a pre-step to inspect the 106th character to make sure it's not '\r' or '\n', then you could then use the ignoredChars parameter safely to compensate for your scenario.

I do not believe what you are receiving is a valid X12 file at all, since the ISA segment which is the first 105 characters should be fixed width, you obviously have a line break within this segment which already breaks the X12 standard. So I am not sure
you will even be looking at the segment separator in position 106 without normalizing this file first.

If it were a valid file it wouldn't have these returns every 80 characters and allow it to be a delimter. Per the 837P spec:

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange.

What they have done may have been some post processing for some other downstream internal process that can only read the file 80 characters at a time.

Based on this, it would appear that either I do not have the transformationService line coded properly, or, the OopFactory routines are not throwing away the carriage return/line feed at positions 81/82 prior to looking for the delimiter at position 105 (0
based).