Issue: the sub ID has been changed on the processing system & contains a ":'. During the 835 build process the system is reports a corrected sub ID but the correct sub ID contains the same character that is being used as the Component Element Separator. Example:
ISA16 = :
Corrected Sub ID - NM1*74*1**SMITH*R***C*:99988877~
The IG doesn’t say a character used for the Data Element Separator cannot be used in Non-composite data elements.
The question is: If a data element that is NOT a delineated field, 835 NM109, can it have the same character that is being used as the Component Element Separator or should the transaction reject 999? If rejected, how should the corrected sub ID be reported so it will not reject?
X12.6, paragraph 3.4 states in part: "Delimiters are specified in the interchange header and shall not be used in a data element value elsewhere in the interchange with the exception of their possible appearance in the binary data element."
If the delimiter specified in the ISA also appears in the value of any subsequent data element, it will not be possible to successfully parse the data. Therefore, a character identified in the ISA16 as the Component Element Separator must not be used elsewhere in the interchange as a data element character. The obligation to adhere to this X12 requirement is solely with the sender of the transaction.
Additionally, this issue is explicitly addressed in the ASC X12N 005010X221 835 TR3. Appendix B, Section B.1.1.2.5 Delimiters, reads in part “Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange.”
The response based on the ASC X12C 005010X231A1 999 TR3 is a valid mechanism for rejecting a transaction that uses a delimiter as part of the data. The correct response would be IK403 with either of the following codes:
6 - Invalid Character in Data Element
13 - Too Many Components
Additionally, no data would be sent in IK404, per the instructions in the implementation guide.