This could be equally at home in the EDI section, but it is concerning partner management and relationships specifically. We have a 4 year old solution to this issue, but it is clunky and wasteful of resources. This appears to be the case for both 6.1 and 6.5 Although we did create profile groups in 6.1 as a way of maintaining delivery info in a central location.

Problem: Multiple group envelope/receivers using the same ISA sender/receiver combination. Gentran allows a user to create an interchange (ISA) configuration and make children of the Group (GS) then build child (ST) transactions under the respective groups. This way, you can send to a VAN or VAS and allow the partner to break up their partner load by group ID. they can also send back 997s as they are generated by each of their partners.

TN doesnt allow that level of organization as far as I can tell. We have a few partners who share an interchange with others. One in particular is very large and getting bigger. This functionality was a critical requirement.

What we did was create an internal ID that is transaction specific. (in place of DUNS) and also the Mutually defined(or SCAC/DUNS/whatever). when building the transaction and envelope, we use the internal ID instead of the actual ISA receiver. This allows batching and unique interchanges. In the delivery step, we branch off of the internal ID = Mutually defined(eg) and do a string replace using values we have stored in extended fields.

The returning 997 loops over the partner profiles and also does a replace on the ISA06 and right pads to 15 before the TNReceive step.

This is a simplified explanation, but the solution gets more cumbersome as we add additional partners. Nearly 2/3 of our partner profiles need this transformation where it was only 1/3 a few years ago.

What have others done to account for a 1 to many relationship with groups to interchanges? and is it any better?

Can you elaborate on where exactly using different IDs in the interchange and group envelopes is stymied?

When enveloping the transaction set you can specify different ISA and GS IDs. The ISA can be one set of sender/receiver values for any number of GS sender/receiver values. Since you control the enveloping when working on the transaction set, I’m not sure where TN limits you here. Are you retrieving envelope values to use from the TPA?

After submitting the enveloped tset to TN, it gets queued for batching, correct? Batching handles the proper sorting of groups into interchanges.

On inbound, you’ll want to configure the TPA to route on GS instead of on the interchange. That will split things the way you need, I think.

I think what you want to do is doable with standard EDI for TN stuff. What piece am I missing?

I had a long reply typed out which I scrapped.

It is the external ID types that dictate our shell game. Since WmEDIforTN uses these to determine the appropriate qualifiers for inbound and outbound X12 envelopes, each must be unique.

I suppose, without giving up too much wiggle room, we may have been able to put the ISA into the agreement which we do, but instead use the external ID type with the GS ID in the profile. I don’t recall why we didn’t or couldn’t. I remember there being recognition issues with inbound transaction or 997s. I think TN was recognizing each common ISA ID as a single profile and not able to drill down to the GS as the true identifier.

What is the nature of the IS document type in the agreement (wm.b2b.editn.TPA:EDITPA) what are the implications of making multiple copies? One per partnership?

“It is the external ID types that dictate our shell game. Since WmEDIforTN uses these to determine the appropriate qualifiers for inbound and outbound X12 envelopes, each must be unique.”

Yes, that is a limiting factor.

“I think TN was recognizing each common ISA ID as a single profile and not able to drill down to the GS as the true identifier.”

I haven’t done this myself, but it is indeed supposed to be possible to route/process based on the GS identifiers instead of the ISA.

As for the TPA (just to make sure we’re on the same page and for other readers that may not be familiar with TPAs), there can be one TPA instance per partner connection per direction. For example, ABC to XYZ and XYZ to ABC. If one doesn’t exist and an interchange for ABC to QRS comes in, the Default TPA is used.

During enveloping, if you want to use the values from the TPA you have to get them yourself. There isn’t any automatic use of TPAs in the enveloping services. They are used by EDI for TN when an interchange is presented to TN for processing to determine splitting, FA generation, etc.

What I’ve done in a couple of places is to “reserve” the Default TPA for “inbound” traffic only. E.g. same TPA used for docs from the 50-100 partners to me. Then use partner specific TPAs for docs to be sent to the partners. This cuts down on the number of TPAs needed (half as many, ideally). If a particular interaction for inbound docs needs to behave differently from the Default TPA, then I created the partner-specific TPA as needed.

If you’re talking about creating your IS doc type that extends wm.b2b.editn.TPA:EDITPA, that’s a bigger monster. EDI for TN won’t be able to use any custom TPA (I think the doc type used is hard-coded but I may be wrong). Is that what your question is about?