In doing some learning in the way Trading Networks works, it appears that the ID a partner uses to signon to TN needs to match the required external ID in trading networks. In our case we may be using multiple ID types with partners, some “mutually defined” (ZZ qualifier) and some “User Defined 1” (08 and 01 qual). In cases like this, what is typically used as the required ID type. We could use DUNS, but not all entities we trade with use a single DUNS. I see there is also a service to use to add external ID types. Has anyone used this to add an ID type and then make it the required ID type?

You are absolutely correct. tn:receive does this as a security check. Take a look at the eZine article by Sonam Chauhan. [url=“wmusers.com”]wmusers.com

It describes the situation and a solution.

Mutually Defined is a good ID to use as the required ID type. You should probably avoid using a custom ID type as the required ID type.

Multiple DUNS (or any type of identifier) is indeed an issue that TN doesn’t address very well out of the box. You can either assign the use of the User Defined X IDs or add your own.

The main issue for EDI is that the mapping of qualifiers to ID types is grossly limited. As you stated: 01 = DUNS, ZZ= Mutually Defined and all other qualifiers are assumed to be User Defined 1 external IDs. What’s needed is the ability to associate multiple identifiers of a given type with a single profile, including the “My Enterprise” profile.

The project I’m working on is trying to address this right now. I’ll post what I can. If you come up with something please share if you can.

“What’s needed is the ability to associate multiple identifiers of a given type with a single profile…”

Actually, you can. You can define any number of IDs of a given type. The challenge is getting the right one for a particular document when you’re putting the document together (e.g. you have the Mutually Defined ID and need to get a DUNS–which DUNS entry do you choose?).

What about the user side of this issue? We created a DUNS user that has to match the DUNS in the doc. It’d be nice if we could have a choice of various IDs in the doc (rather than just the DUNS) but only one user the DUNS - so that TN can match the user with the sender from the doc. From what I can figure, the required type, since it’s set to DUNS, has to be DUNS in the doc and DUNS as a user.

This is one of the topics in Sonam’s article mentioned earlier in the thread. Instead of submitting the doc to tn:receive you “front-end” that service with your own, do whatever validation you want and then pass the doc to wm.tn.doc.xml:routeXml to bypass the TN sender/doc sender ID validation.

Also, one can change the required ID type. The setting is in the TN Console (can’t remember where offhand).

do anyone know how to make the TN able to recognize a Sender or Receiver in a EDIFACT document when the Sender and Receiver Qualifier don’t exist?

or better, do anyone know wich ID Type I have to use when I add a external ID in the TN profile to set up a Mailbox without the qualifier.
according to the UNEDIFACT standard, the sender and receiver qualifiers are not mandatory fields, and we have to manage some of these cases.

we are using different values for these qualifiers, like 01, 04, 09, 14, ZZ… and for all of them I’m able to recognize the partner.
in the partner profile I add an external ID setting the ID type according the qualifier.
but I don’t know what to do if the qualifier don’t exist.

I tried to use the “User Defined 1”, becouse it’s the default value for the service wm.b2b.editn:ediPartnerIDToTNPartnerID, but it doesn’t work, and if I submit a EDI document to the TN, the Sender or the Receiver is “unknown”

thanks

As you are probably aware, the TN for EDI manual has this table for how EDIFACT qualifiers are mapped to ID types:

1–DUNS
ZZZ–Mutually Defined
Any qualifier other than 1 or ZZZ – User Defined 1

It would seem to make sense that in the absence of a qualifier the ID would be mapped to User Defined 1, but perhaps that’s a bug? Maybe touching base with wM support is the way to go here.

Hariene,

looks the same ExternalID (SCRP)already exists in the TN DB which this should be unique with no duplicates,so you are getting that error.

So please make sure that someother partner profile in your TN is using the same External ID.

HTH,
RMG.

Hello,
Our partners use ZZ, 01, and 14 as the qual. The ZZ == ZZZ to WM. Also, when you you are working with 6.0.1 in Developer and you use services like wm.tn.profile:getInternalID, you have to convert the ZZ qual that you have to 99 so that you get the proper result. This service does not take non numbers out of the box. I just make a wrapper that takes ZZ or ZZZ and makes them 99. Just a tip for the future.