Partner does http post to the gateway service, which submits EDI to TN using wm.tn:receive.
Yes there are rules for all other EDI
-Process X12Envelop ( Action: change User Status) - Fails
-Proces X12Group ( Action: change User Status) - Works fine.
Custom Processing rule (Action: invokes service and change status) - Works fine.
Trading Networks does require partners to have a B2B user account that is a member of the TNPartners group. Before exchanging documents, the B2B user account does have to match with the DUNS value of the External ID in TN in order to recognize its partners. Also we need to keep in mind, the user name and password are case sensitive. Therefore, if your customer is RichProd, and the B2B user account is username = RICHPROD & password = popo, the SenderID and DUNS cannot be something else.
In short, the DUNS and SenderID has to match with the B2B user account to give partner authority.
If we invoke wm.tn:receive service as part of your EDIINT transaction. This receive service calls submit which calls checkUser. This checkUser service was causing the problem.
Either you can disable the checkUser call within submit service in order to have your transaction to go through. For a cleaner and recommended solution it is recommended to use routeXML instead of receive.
In that case of not external TP,you may have to try alternatives to use routeXML or set the receive to Anonymous or disable checkUser suggested above and either of these changes should help:
look into your error:
“The user that posted this document (Default) could not be associated with a partner to check their identity.”
The user “Default” is used when the client is not doing proper authentication. To avoid going to the business of create your own service, you can create a username that matches with one of the TN ID of this sender (DUNS number for example), then ask the client try to authenticate with this user.