Hi,
I’m sending an X12 to TN as individual 850 transactions (in an ISA/GS envelope) which is split at transaction level. Rule is on the 850 itself to queue - docs are then queued and batched using the built-in EDI batch service (batchProcess). The individual 850 uses a TPA to build the ISA envelope,etc. This batching resends a batch of 850s in an ISA to TN which I need to reconcile against an inbound 850.

The batch file in TN is not displaying a DocumentID which comes from the control number at the group level. The control number is in the batch file correctly. Assuming I need another TPA to split this at the group level, how do I differentiate the TPA between the individual transactions (which have an ISA/GS and ST segment) and the batch (which also has ISA/GS/ST segments) and the same sender/receiver pair?

Thanks!

Hi,
Not sure if I understand your requirement completely as i have no working knowledge on X12. The below info might help,

You need two TPA for same sender receiver pair with different agreement id. Differentiating the agreement id has to be done in processing service in IS, you will be having some way to identify the individual and batch transactions, depending on the type of transaction get the TPA for specific agreement id. Use hard coding of agreement id or some kind of configuration file/tables.

-regards
DC

Thanks. I see how one could grab 2 different TPAs based on what you said, but I am not using the TPA in code so I’m not sure what would be done with it in the code. Rob Eamon suggested a 2nd TPA for the batch file which would cause TN to extract the txn id (currently TN is not doing this). The batch submission to TN is happened automatically via a built-in function that I have no control over.

So the main issue is the txn id is not being extracted from the batch file (TN uses the control number), since this happens automatically (builds batch from queued docs) Rob said when it was sent to TN the TPA at group level would cause the txn id to appear. Right now it’s set for the sender/receiver at transaction level so it’s interesting that the batch file is not being split, just the individual transactions.

Perhaps this is a bug or a workaround might be a pre-processing service that tries to extract it.

Actually, I did not suggest a 2nd TPA. I mentioned the batch X12 needs to be split at least to the group level.

I’ll see if I can figure out/recall what I’ve done in the past for this.

Try the option batch X12 split at Group level as it should work:

HTH,
RMG

Thanks Rob. I looked at the TPA and also the batchProcess inputs and don’t see that option. Can you be more specific please?

I looked at the batchProcess service (for the EDI Batch delivery service) and there is a processOutput flag that is used to split the envelope into 3 docs. I don’t really want this because it produces all the 850s in the batch again, but I noticed it does extract the control numbers and also creates a conversation id, whereas the non-split batch doesn’t have docid or conversation id.

In the EDITPA you should see the variable splitOption = Group or Transaction or Interchange.

Did you set processOutput flag to true or false? It should be false

Also other configs like
mode=IC&GP and oneBatchQueue=MULTIPLEOUTPUTS?

HTH,
RMG

Rob,
OneBatch queue is single output, with IC&GS (all 850s in one group inside one ISA). processoutput = false.
I have a TPA for a sender/receiver pair that splits at transaction, the individual 850 goes into queue and gets batched using ‘batchProcess’ and sent to TN. The batch shows up as X12, doesn’t get split but doesn’t extract the doc id or conversation id. I have a rule on the batch that delivers fine via AS2.

Attached a screenshot showing batch with no conversation or doc id.

Why do you need batch X12 to split as X12Envelope (batched for sender/receiver) should suffice and trigger a rule for AS2 send?

I’m fine with X12 envelope for batch. The problem is as shown in diagram there is no document id or conversation id (to relate to individual POs).

As far i know normally those batch docs won’t have those details per standard:

when I split the batch using processoutput (which I don’t want) it extracts the doc id and conversation id. It would be nice to have the conversation id to relate it to the individual POs.

It’s the processOutput=false that is the trouble. It needs to be true for extraction of values, splitting, etc. As you note, this will split to the transaction set level due to the TPA settings.

We avoided “duplicate” 850 (before and after batch) entries in the past via custom approach. Unfortunately, I don’t think there is a way to avoid this with the out-of-the-box facilities.

One of the things I think is a big oversight in the product is that the transaction sets that are put into the batch document do not get related to the batch document.

Interesting read, this should go on brainstorm.softwareag.com- then perhaps we could get this in a later release?

The batch is working and reconciling with 997 although there is nothing extracted from the batch in TN.
We had to separate the control number for the batch from the individual 850s at the group level because we were getting ‘Duplicate’ statuses (same group number for batch as some 850s due to similar range in numbers). The control number area in IS admin is a little strange to say the least.

The batch is working and reconciling with 997 although there is nothing extracted from the batch in TN. → Yes you got it and thats by default :(:

Well that’s a problem for a few reasons:
-the EDI reporting doesn’t have HTML links on the batch file (probably because doc id is null) and the report flow service internal doc ids can’t be used to look up the bizdoc (doesn’t work I tried it)
-We can’t query for batch files in TN using the txn id or relate it to the individual 850s that went into the batch

I don’t think that’s the default. The default is for the batch document to be processed (extract IDs and split).

What I’ve done in the past is “hide” the original transaction sets from the TN EDI processor by treating them as plain flat file docs. That way TN doesn’t split them. Then we had a custom process to gather those and submit them to the TN batch service, which created the batch X12 and processed it to extract the identifiers and do the split to the group level.

I meant default for batch document itself: Sorry if got confused:

We followed earlier the same custom approach that Rob as mentioned and it works fine.Ofcourse its good to have EDI built-in functionality as a whole for batching support:

HTH,
RMG

Yes Rob that makes sense and might be the way to go in the future. I was trying to use built in EDI functionality as much as possible.

I’m with you on that. Alas, the out-of-the-box facilities more or less make you choose which set of pain you want to deal with.