Jeanne,
Is this integration an X12 270 to X12 270?
In other words ar you just passing the 270 along to anothre trading partner?
If so, it would typically be the Receiving Trading Partner that would provide the TA1. This is because some of the verification of the envelope is dependent upon the receiving system’s rules. Not to say those rules could not be in Cloverleaf but rather the receiving trading partner could change those rules and Cloverleaf would be unaware thus potentially causing issues.
If this is the case then you can just do an end-to-end acknowledgment handling by passing the TA1 received from the Receiving Trading partner back to the sending Trading partner.
If the Receiving Trading partner is not returning a TA1 (they should for a 270) then it will have to be done in Cloverleaf.
I do not have a Tcl proc to do this. The last time I needed to do this (actually create the TA1 within Cloverleaf), I did it using Xlates, routing, and some reply handling Tcl. I did not actually create the TA1 with Tcl. Now this was at least 11 to 12 years ago and Cloverleaf’s handling of the envelopes in X12 messages has changed since then so I am not even sure this is possible today. For example the IEA envelope information is not exposed to the Xlate in current Cloverelaf releases (although the ISA information is). However, I think with some work the method I used could be done.
The best bet is to simply return the TA1 from the Receiving Trading Partner. This does mean waiting for the TA1 from the Receiving Trading Partner before the next 270 can be sent by the Sending Trading Partner.
If you can also get the Receiving Trading partner to return the 271 over a different connection (asynchronous message exchange), that would also simplify things (assuming returning the Receiving System Trading partner’s TA1).
All of the above is assuming a real-time not batch exchange of 270/271.
email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.