We are using EDITPAs for quite a few of our outbound X12 partner relationships. Up until now, this was exclusively used to store partner specific delimiters (e.g. Partner A may need *|~ but partner B uses *$|).
Anyway, now we have some partners that would like to be identified differently in the documents that we send to them than the id that they put in the documents that they send to us. For example, lets say that Partner ‘A’ sends us X12 810 documents and identifies themself as:
ISA05=01
ISA06=123456789
But when we send them back X12 820 documents in response, they would like us to identify them as:
ISA07=ZZ
ISA08=SLCPROD
Now, I know that in the EDITPA document, there is a place for alternate outbound sender and receiver ids and qualifiers (e.g. EDITPA/envelopeIdentifier/receiver/id). But, you can only specify one alternate sender id, and one alternate receiver id. What if Trading Partner ‘A’ also receives X12 850 documents from us, and wants to be identified by yet another id:
ISA07=01
ISA08=223344557
How can I store this in the EDITPA?
And this leads me to another, related question. When you build trading partner specific EDITPAs, are you required to point the IS Document Type to wm.b2b.editn.TPA:EDITPA? Or, could I make a copy of the EDITPA document, place it in a custom package, and modify it according to my needs? If so, then I could make envelopeIdentifier/receiver document in my EDITPA a list, and add a document type field underneath it. At runtime, I could then pull the appropriate alternate receiver id from here depending on the document type. But, by pointing to a namespace other than wm.b2b.editn.TPA:EDITPA, does anyone know if I am breaking anything?
Alright, sorry for the length of this post. Please let me know if I need to clarify anything.
Just a quick comment. I had a similar issue with different GS03s that I needed to code around but yes you can copy the EDITPA document to another document and modify. I’ve done it. As for the remainder of you solution I’ll have to think about that.
It’s good to know that you didn’t experience any ill effects from using your own version of the EDITPA document. The documentation is a bit ambiguous about this.
I’m still stumped regarding my originial problem though. I have ideas that would work, but I have yet to come up with a way that feels like the “right” way to handle the issue.
I wish that webMethods TPAs could be sender, receiver, AND document type specific, instead of just sender and receiver specific.
Unfortunately, TN uses EDITPA only at the SenderID/ReceiverID level and not further down to the document type. As suggested by you, you can create duplicate TPAs and define/store all the values. This will work as long as you are accessing the TPA and u know the various AgreementIDs and the fields you have defined. The problem comes when you want to do EDI batching and the webMethods out of the box solution works fine as long as the EDITPA are defined. EDI batching becomes a requirement when we want to send documents to the VAN and hence we need to queue to outgoing EDI documents. It does not know anything about the custom TPAs and hence getting it to work with multiple TPAs will be a problem.
I am also in the same boat like you and I definitely need to resolve this issue with webMethods Tech support. In the meantime please let me know if you come across any great solution.
One other comment. I have made extensive use of the Extended fields in the profiles to solve similar issues in regards to differentiating requirements at the Transaction Set level.
For instance I have a set of Extended Fields for each document that we trade. ie. T810, T850 etc.
That’s where I set my GS08 value in a field called T810GS08.
Your thoughts are correct. You will have to define the IS document type and put it in “IS Document Type” in Agreement Details screen. I don’t think EDI batching will be an issue as Manohar is pointing out. The reason is when you put the EDI envelopes in the queue, EDIs are already created. We had similar situation as yours and crated custom IS document. I copied the EDITPA from WmEDIforTN package and made necessary changes. Make sure that you do not modify/delete any existing fields in the document - just to be in safer side. Also keep the AgreementID as EDITPA.
Here is what I tried and it seems to work without having to change/customise anything on the EDITPA side. I am able to generate EDI documents and send to different ISAs for the same partner based on the document types. Trick is not to use the EDITPA to store the ISA ID values. Instead, make use of EDI batching feature and setup appropriate queues for different document types. While creating the queues, you can set up any ISA/GS Ids as required and voila - you will have EDI files built with new GS/ISA envelopes with new ISA ids when the queue gets executed for a particular partner/doc type. Btw, this method is useful only if you use EDI batching to build GS/ISA segments. If you plan to build your own GS/ISA segments for different doc types at the time of generating the ST, then modifying EDITPA makes sense to extract the ISA info. Also, as Chris Linton mentioned, you can use the extended fields section to store this info which I think is meant for customized values. I have used it for other purposes but not for storing ISA info though.
Ramesh - In EDI batching, the webMethods built-in solution does re-create the GS and ISA envelopes based on the EDI batch inputs and the EDITPA values even though you create envelopes at the time of persisting the ST level documents. However, it does not change the ST segments and anything within it. Infact, it will even regenerate the EDI document for any new delimiter as specified in the batch input even within the already generated ST. Its a cool feature but dangerous if not used properly.