tn.receive creating two transactions

Hello All,

I am using wm6.5 and sending EDIFACT data to TN as an envelope (using wm.b2b.edi.util:addICEnvelopeEDIFACT), using service.

The problem is, in transaction analysis, its creating two transactions for each envelope, one with Processing Status ‘ignored’ and another one with ‘Done W/ Errors’. I am not getting why its creating two transactions.

Instead, if I use ‘’ its not creating two transactions, but in the processing rule I need to specify the document as UNEDIFACT ORDERS 96A ,etc. instead of EANCOM Envelope.

These two problems are not there on wm 6.0.1.

Any idea on this??


Hi Guna,

Please check the pre-Processing actions and processing actions because the status of the processing rule can be changed at applying processing actions and the conditions.

get back to me if you need more info …

The problem is, in transaction analysis, its creating two transactions for each envelope, one with Processing Status ‘ignored’ and another one with ‘Done W/ Errors’. I am not getting why its creating two transactions.

What is your processing rule criteria?? Is the documenttype set to UNEDIFACTEnvelope?? Generally When you post EDIFACT document to TN it should create UNEDIFACT Envelope,UNEDIFACT ORDERS96A (transaction set) and UNEDIFACt Group depends on the data if it has has UNG segment.

So if the Processing rule criter set on Envelope then the process status should show as Done and ORDERS96A as Ignored



Service used : Document type in processing rule


Can u confirm once again this statement made by you?

Service used : Document type in processing rule

R u using in processing rule?


That is not correct in the document type criteria…

Document Type should be either UNEDIFACTEnvelope or UNEDIFACT ORDERS86A etc…You may have to fix this and test it again…


I am monitoring this thread and i am also facing the same issue.
I have set the processing rule as

sender :xxxx
receiver :xxxx
Document Type :EANCOM Envelope

When i submit the data to TN using .The transaction list is showing two transactions

sender receiver documentType status

I understood the second scenario (reason for Done W/Errors).
Is it possible to avoid the second transaction.

Any idea:confused: .Which will help to make our EDI much cleaner way.

I am sorry. This is not fully submitted. My actual reply was this:

Service used to post Document Type in processing rule
receive EANCOM Envelope (Creating 2 trancts)
recognize UNEDIFACT ORDERS 96A (Going fine)

If I interchange the document types or use another document type as UNEDIFACT Envelope or Group in the processing rule, the date is not recognized.
As RMG told, I tried using UNEDIFACT Envelope/Group for both the services as above. But it ignored the data.:sad:


The EDI for TN module performs deenveloping (also known as splitting). The normal behavior is to create TN transactions for each interchange, group and transaction set found within the data submitted to receive. If you submit an EDIFACT/EANCOM document containing one order, you will see the interchange envelope and the ORDERS document in TN. If you submit EANCOM data, say with 1 interchange, 2 groups (not typically used in EDIFACT) with 3 orders each, you’ll see 6 items in TN. You set up rules to process the particular document that you want (e.g. ignore the interchange and groups, process the transaction sets).

A common way to process these is to ignore the envelopes and to process the individual transaction sets. I prefer this approach as TN handles all the deenveloping, acking, etc.

Another way used by some is to configure the TPA(s) to split at the interchange (which is actually no split at all) or group level. Then in the service invoked by the rule you set up, you process the transaction sets as a group. This approach is less common since it is rare that a group of docs must be processeed together–splitting and processing individual documents is usually okay.

What do you mean by a “much cleaner way” to process EDI? Splitting to the transaction set level and tracking progress of each envelope and transaction set seems to me to be the “right way” to process EDI.