New code for CR use to communicate to the TDSP that an 810 or 867 file (or both) was not received
Next Step:
Currently this has not proven to be an issue in the Market. TX SET recommends that the issue is closed and if transaction processing produces this issue, it can be readdressed.
Currently this has not proven to be an issue in the Market. TX SET recommends that the issue is closed and if transaction processing produces this issue, it can be readdressed.
There are not specific reject codes in the 824 for a CR to use to communicate the following:
The 867 was received but not the 810
The 810 was received but not the 867
Neither the 867 nor the 810 was received for a particular service period
Reason:
Operational/System Impact: When there is a missing transaction the CR cannot effectively communicate that scenario to the TDSP. They use a generic 824 reject code that may or may not include additional text description Based on how the TDSP interprets this generic code, the CR may or may not get their missing transaction.
Market Impact: 810s and 867s continue to be missing. CRs end up filing DEVs in order to get missing usage. TDSPs may incorrectly interpret the generic reject code currently sent, not realizing that the issue is that the CR did not receive the transaction, and spend manual effort addressing the wrong issue.
