Greetings,

Does ASC X12 standard explicitly state that a document resubmitted due to the 997 rejection should use a new ISA control number instead of the original one?

Any information would be appreciated.

Thank you,
Justin

Do you have any duplicate check defined for control numbers in EDITPA? it might fail if there is validation turned on for control number. Otherwise should be ok as far as i know.

How is your FA process setup is it generating 997 via TPA auto FA ON or customer service FA that uses same inbound control numbers?

What is the reason for 997 rejection and is your TP requested for resubmission of 850 or 810 transaction etc… to send with new control#?

HTH,
RMG

In general, EDI standards don’t define process. The controls surrounding EDI tracking and such are generally just by convention–someone figured out a good way to do things and that’s what everyone else generally does.

As shahid notes, whether or not to reuse the existing IC control number will depend largely on what your partner expects. I may be wrong, but I believe the convention in this case would be to use a new IC number. If you’re sending a corrected group/transaction set(s) then you’re sending a new doc and the group and IC numbers should be new.

Thank you very much for the reply.

I asked this question because I’m curious about how the correlated transactions are handled. Since the X12 doesn’t concern the semantics of the transactions, the transactions are independent and stateless from its point view. So in this sense, the sequence of the correlated transactions are not guaranteed as well as the logical relationships are not reflected.

Consider this scenario: a retailer creates purchase orders using 850 and expects order to be acknowledged by 855 from its vendor; the retailer also changes the previous orders using 860 and expects the order change request to be acknowledged too. Now the retailer sends a 850 to the vendor and before it receives the corresponding 997 from the vendor, it again sends a 860 to change the order in the 850. On the vendor’s side, however, after receiving the 850 it turns out the document is not processable, so it sends a 997 back to the retailer to rejected the 850. Then the vendor processes next transaction which is a valid 860, and finds that the original order this 860 wants to change doesn’t exist…

Things could be more complicated: even the vendor knows the previous 850 could be lost or rejected and processes the 860 without any problem. What should it do after it receives a resubmitted 850 from the retailer? Should it send a 855 indicating the acceptance or the rejection? It already accepted the 860 which replaces the 850, so it shouldn’t accept the resubmitted 850 again. Should it reject it? Where are the chicken from if there were no eggs?

Its all depends on your EDI processes and architecture defined based on the inputs from your OM/supply chain functional team how they want to handle the various scenarios/situations in case the TP rejects the original 850 PO by 855 ack or 997 (transaction reject or envelope reject due to compliance errors etc…)…But can you check with your TP folks also how they want you to deal the PO and PO Ack and PO Change transmissions flow?

Here you are inquiring about how 997 resubmit works or handling your PO rejects?

HTH,
RMG

These are process agreements that that 2 parties need to put in place. When the 860 arrives without a previously accepted 850, the 860, while possibly syntactically valid, is “out of order” for the process and should probably be rejected. The original 850 which was rejected should probably be considered dead and a new 850 created and sent.

Knowing the difference between lost and rejected is why the control numbers, and tracking the sequence, is important.

The scenarios you describe are “application level” concerns. X12 doesn’t address those. The 2 partners need to define the process.

Thank you for the clarification!