I’ll be receiving an individual PO and will be mapping it to an 850 ST transaction. These will be sent to a VAN. I’m unsure of what the flow should be after that regarding enveloping and delivery.
Do I send the ST segment to TN, put them in queue, have the built in service batch and send?
If I add a GS and/or ISA segment to each transaction doesn’t the batching have to remove most of the control numbers and regenerate them for the batch?
If I do a batch, does it get delivered in the service that grabs the queue tasks or does it get resent to TN?
If the batch is sent to TN for delivery how does TN differentiate between the individual 850 txn and the batch of 850s?
Does the batching and sending to VAN built in service work properly or do you have to write your own custom service?
If someone could help with the logic and orderly steps that would be helpful.
The document will need to have the envelopes added–it cannot be just the transaction set (ST - SE).
Yes, though there was an option added that batching can be configured to leave the assigned numbers alone.
The resulting batch document is submitted to TN for logging and action. Typically you configure a rule to deliver the document.
The batch process adds an attribute to the batch document that can be used to identify the batch X12. Keep in mind, the rules will be looking at X12 envelope, not 850s.
Define “properly?” The out of the box facilities work, but if there are any variations to behavior that you’d like you may need to customize some parts. For example, in previous projects we’ve customized the batching itself (avoided use of queues due to various issues) and the delivery service (to log additional data and provide additional file handling controls in the put).
That depends on the split level defined by the applicable TPA. If split is to transaction level, then you’ll see X12 Envelope, GS Envelope and the 850. If split is not to transaction level, then you’ll only see to the level of the split.
So yes I’m slightly confused if I send a full ISA/GS for the transaction, and then the batch is also sent back to TN with an ISA how does TN differentiate since they would basically look the same (what is flag, etc)?
Another problem is that since we are using DUNS in the ISA segment, I tried to enter the DUNS number in TN profile for the sender but it is already being used in another profile (that I can’t use, different business unit and we use a new user defined 1 for other routing purposes)
Basically for this problem, you can setup a dummy flat file doc type (for ex: Outbound batch 810) and create a batching rule for this (doc type/sender-any/receiver) and in the batch config specify the sender duns/receiver Test (profile) and the required settings…The flat file will have the wrapper EDIdata and use the flatfile gateway service to route to TN which will be Queued.Finally your batch processing send service will retrieve the docs and routes the EDIdata (X12 Envelope) to TN and does the outbound transport (sent to VAN or AS2 or FTP file) etc…
I still have questions - my rule for batching is based on the 850 not the X12 envelope, which I thought would be too generic. So I split the EDI doc at transaction level. When the batch is sent back to TN do I set a rule just on the X12 to deliver it, and base the rule on the sender/receiver since the envelope is not document specific, just an X12?
Hello,
I dont know that I am wrong or right, but till my knowledge, batching process works on the X12 Envelope only, dont worry that you have 850, or 864, etc…
It will work fine and correctly, as I have done this, and seen the transactions working.
DO try and follow up.
And RMG and Rob, please say if I am wrong somewhere…:happy:
Ok but when I send the individual 850 with ISA/GS it splits into 850, Group and X12 Envelope so how does TN know this isn’t the file to be batched? In other words, when the actual batch is sent to TN how will it differentiate the batch from the X12 for the individual 850?
It’s nothing to do with single/multiple ST’s (the Batch queue configuration/X12 Envelope partner specific or generic in case would help) What’s your current setup for batching so far,that way would be easier for anyone to suggest.
Did you tried my previous suggestion:
Setup a dummy flat file doc type (for ex: Outbound batch 810 or 850) and create a batching rule for this (doc type/sender-any/receiver) and in the batch config specify the sender duns/receiver Test (profile) and the required settings…The flat file will have the wrapper EDIdata and use the flatfile gateway service to route to TN which will be Queued.Finally your batch processing send service will retrieve the docs and routes the EDIdata (X12 Envelope) to TN and does the outbound transport (sent to VAN or AS2 or FTP file) etc…
I don’t want to do custom functionality if I can avoid it. As Rob Eamon said to do I send the 850 to TN with an ISA/GS and it’s going into a public queue. From there it should trigger the batch service and resend to TN. The scheduled delivery is being suspended and it’s complain about the input parameter version. I was hoping the inputs to the batch service would be automatically populated since it’s a public (generic) queue.
So assuming I get the batch to submit to TN, I’m wondering how the batch would be differentiated from the individual 850 (which also has an ISA/GS segment).
If Rob or others can chime it please do. And only if you’ve actually used the built in batching services.
When the batch service creates the batched X12, it adds an attribute to the TN document. I don’t recall the specific name and value, but the EDI docs have that. That’s how the rules can distinguish between the individual docs and the batched doc.
The attribute name is EDI Batch and values are None/Interchange…
For a batch EDI document, the EDI Batch custom attribute is set to Interchange. You can use the EDI Batch custom attribute in the extended criteria of the
processing rule, so the processing rule is only used for a batch EDI document.
The out of the box facilities work, but if there are any variations to behavior that you’d like you may need to customize some parts. For example, in previous projects we’ve customized the batching itself (avoided use of queues due to various issues) and the delivery service (to log additional data and provide additional file handling controls in the put).