Hi,

When I submit an EDI(X12) file via Admin console I get three rows corresponding to the same in the transaction analysis:
1.X12-Envelope
2.X12-Group
3.X12- 4010 856
What does these three rows signify? Moreover I get Done W/ Errors against these three rows. When I check the activity log the error shown is Invalid Sender and Receiver Id?

How to solve this?

Regs,
Venkidi.

The three rows are normal behavior if the split option of your EDITPA is set to ‘transaction’.

The three rows specify the Interchange, Group, and Transaction Set level processing respectively. ( They also demonstrate that it can make sense to resubmit a document (or parts thereof) to Trading Networks multiple times during its processing lifecycle )

The sender and receiver id’s are validated by comparing the ISA sender/reciever ids ( and qualifiers ) to the external ids ( and external id types ) configured for Trading Partners in TN.

This is basic stuff, so I would recommend you spend some time with both the Trading Networks and EDI module documentation.

Hi Mark,

Thanks for the info.

But the Done W/Errors is shown only for X12-Group and X12 4010 856 rows. The X12 - envelope row doesn’t show any error.
As per your comments the ISA sender and receiver id is matched against the external ids configured in the TN console. Can you let me know against which field is the GS sender and Receiver ids checked against.

TIA,
Venkidi.

Venkidi,

There is only place to define external ids in the partner profile.

What is the structure of the interchanges you are receiving? Do all transaction sets in the interchange belong to the same sender/receiver?

Hi Mark,

I am receiving 856, X12 4010. Yes all the transaction sets in the interchange belong to the same sender/receiver.

regs,
venkidi

Venkat,

GS02/GS03 are the sender and Receiver fields checked against the ExternalId’s in the TN.So please make sure those above fields are coming with correct ids(including their lenght’s)in the GS segment.Then only X12Group will be persisted with out any Errors.

HTH,
RMG.

Did Ram’s post solve it?

If not…

Are all of the transaction sets in the interchange of the same type?
I.E., are they all 850s, or all 810s, etc?

Hi Mark and RMG,

The ISA and GS sender id matches with the External id values of TP. Moreover the receiver id matches with that of the enterprise’s. But I still get the Done W/error in the X12 group and x12 4010 856 rows of transaction analysis.

The X12 file has a single ST and there are no other transaction sets.

Rgs,
venkidi

Hi,

Moreover in the activity log I can see the value of sender id and receiver id as ISA05:ISA06:GS03 and ISA07:ISA08:GS04.

In the TPA I have GSRouting/routing mode as OFF. In the EDI module users guide it says that only when the value of GSRouting/routing mode is given as GS&ISA should the above mentioned case occur (ie ISA05:ISA06:GS03 and ISA07:ISA08:GS04).

The issue is still unresolved.

Regs,
Venkidi

Venkidi,

Can you tell us how your EDITPA is configured?

Also, be careful about matching the external id type and the qualifier. What is the ISA qualifier you are receiving, and what have you chosen for the corresponding external id type?

Regards

Hi Mark,

The problem is solved when i add the interchange info in administration server. Can you explain the logic behind this?

But my doubt is does one need to add the interchange info for all the trading partner which has an entry in TN console.

I have chosen DUNS as the external id qualifier.

Regs,
Venkidi

Yes, you need to add to the profile all the possible identifiers you will receive in EDI documents (DUNS, UCC, Phone, Mutually Defined, etc.) How the identifiers within the EDI document (01, 08, 12, ZZ, etc) are matched against profile external IDs is described in the EDI module documentation. As you mentioned, whether or not the GS identifiers are used depend on the settings in the applicable EDITPA. The out-of-the-box setting is to use the interchange identifiers, even for the X12 Group document (which is really a full interchange as can be seen by reviewing the contents).

Right. My understanding was that the Interchange data in Administrator only comes into play when you are doing custom GS routing.

I was hoping we could confirm this as the issue by seeing what the EDITPA settings were.

Venkidi… can you provide the EDITPA settings I asked for?

Hi Mark,

I suppose you need the details of the TPA.

1. Sender and Receiver ID as set in the Trading partner.
2. IS doc type :wm.b2b.editn.TPA:EDITPA

The inputs for the IS doc type :

GS routing/routing mode : OFF
Sender/Receiver qual : *
Processing mode : Testing
Split option : transaction
FA reconciliation : false
validate interchange and group control numbers : yes

The rest of tha variables have the default values.

Hope this is what you wanted. Please let me know if i have to give some other details.

Regs,
venkidi

Your EDITPA seems to match the data as you have described it. Since you said you are getting the id and qualifier in the ISA segment, I don’t see why you must resort to non-standard processing to drive partner identification from the GSA segment.

If you would like to post a small EDI document sample that demonstrates the problem, I will take a look at it.

-Mark

What are the settings for the default EDITPA (Unknown sender/receiver)? When you were getting “DONE W/ ERRORS”, what did the activity log indicate the error was?

Hi Mark,

PFA the EDI doc.

Regs,
venkidi

Hi Rob,

The settings for the default EDITPA are :

1. Sender and Receiver ID are Unknown
2. IS doc type :wm.b2b.editn.TPA:EDITPA

The inputs for the IS doc type :

GS routing/routing mode : GS/ISA
Sender/Receiver qual : *
Processing mode : Production
Split option : transaction
FA reconciliation : false
validate interchange and group control numbers : yes

But I have disabled the default TPA .

Error in Activity log :
For the Group and Transaction rows I get Invalid Sender Id as the error in activity log. Moreover it shows the sender and receiver id as
ISA05:ISA06:GS02 and ISA07:ISA08:GS03.

Regs,
Venkidi

The docs indicate that even if the default EDITPA is disabled (and the docs note that it should not be disabled), it will still be used. Since the default has GS&ISA it is trying to use GS data for identification. Would suggest enabling the default EDITPA and setting the routingMode to OFF (which I assume is the routing mode you want to use). Then we can chase why your partner-specific EDITPA may not be getting used.

I’ll try processing the document later today if there is no resolution by then.

-Mark

Venkidi,

It was definitely the GS routing mode. When I tried your setting, I saw the same behavior.

As Rob suggested, in your situation it needs to be set to off.
I would also follow his advice to leave the default EDITPA enabled.

By the way, the GS06 and GE02 segments in the sample doc you sent have leading zeros. This violates the X12 spec, so if anyone in the loop actually validates for compliance, it will fail.

Regards,
-Mark

Hi Mark and Rob,

I did the changes suggested by Rob. Its now working fine.

Before I close this thread, I have some more doubts:

1. Does the default TPA gets created automatically.
2. What is the order of processing in the TPA.(My first entry in the TPA is the Unknown- will it match one by in the order it appears in TPA)
3. Why did it work when the default TPA’s setting was turned off(GS routing) even though it was disabled.

Regs,
Venkidi.

Venkidi,

The default TPA is indeed created automatically on install.

I think webMethods expects no duplicates for any specific combination of sender and receiver in a TPA, so order of processing should not be an issue. TPAs are not like processing rules in that regard. Since (as you said from the start) you had a TPA that corresponded to valid partner ids, only the custom TPA should take effect.

When I tested it, leaving the default TPA disabled did not prevent things from working correctly using my custom TPA. ( At least apparently ). So that would explain why the GS routing setting for the default TPA had no effect.

Nevertheless I agree with Rob that if the docs say you shouln’t disable the default TPA, it would be wise to conform.

Regards
-Mark

Hi Mark and Rob,

When i test by disabling the default TPA i get the done w/errors.

One more doubt if the WM expects the sender and receiver in TPA why the error occurs when i disable the default TPA.

Moreover if there is no match in TPA what happens.

Regs,
Venkidi.

That is not what happened for me once GS Routing was set properly in the custom TPA. Maybe Rob can explain that.

The default TPA (with sender and receiver as unknown) is what would be used if there is no match.

“…when i add the interchange info in administration server.”

I had misread that when I had first responded. I thought you meant in the TN Console. Sorry.

Are you using non-standard processing? Do you need to? I ask because if you don’t need to use non-standard processing then you can remove all the config you put into the EDI config in Administrator. If that config is still set up, it may be playing a factor here.

Hi Rob,

I am not using the non-standard processing any more. As per ur comments in previous mails i had enabled the default TPA and set the GSrouting to off.Then it was working. Actually my doubt how will the default TPA come into picture when i have defined a TPA for my sender and receiver with the same properties of default TPA.

Regs,
venkidi.

The default EDITPA is used when values are not set in the partner-specific EDITPA. So if you leave a field unset in the partner-specific EDITPA, it will use the value from the default.