none
Party resolution RRS feed

  • Question

  • We have several partners which send the EDI docs with the same ISA5-6. They are differentiated by GS2 fields (here it is a Canada Customs Code).
    (Not sure it is a standard, but anyway.)
     
    Now when I create a second party with the existed ISA5-6, I've got an error:
    "
    Hatsu as Interchange Sender - X12 Interchange Processing Properties
     
    ISA6: Sender and Receiver ID/Qualifier values should be unique. <ISA5=ZZ, ISA6=EVERGREEN, ISA7=, ISA8=> already exists for party 'EVER', specify different values.
    "
    I've tried to create the EDI properties only with GS2 (no ISA5-6) without luck.
     
    Is there a way to create several parties with same ISA5-6?
     
    Thanks,
     
     
    Friday, April 20, 2007 6:39 PM

Answers

  • Leonid,

     

    You should still be able to handle inbound documents. Just set up one party. All documents will be received correctly and acknowledgments will be generated correctly. For outbound documents you can specify different GS level envelopes by GS ID and Doc type. You just need to specify a different schema namespace for unique GS ID and doc type combination. That will require a schema for each party where this is an issue and if you are employing maps then a separate map.

    Sunday, April 22, 2007 8:19 PM

All replies

  • ISA5-6 should be unique across all parties in "Party as Interchange Receiver". Your error is by design

    On a side note, when you initially create a party, you can leave ISA5-6 blank and this setting will be accepted. However a document that resolves to this party during serialization will be suspended since you need ISA5-6 for the ISA headers. Furthermore once you have filled in some values for ISA5-6, you cannot make it non-blank again.

     

    Thanks 

    Friday, April 20, 2007 7:34 PM
  • I'm sure you are right about an error, and only two fields (not three) should form the sender/receiver address.
    But that's how it works with my partners! It is out of my control.
    And I am sure this is not only my problem. Otherway why Covast adapter forms addresses from those three (not two) fields?
    As I understand the EDI standard is too big standard and the real life works not so standard. I cannot forse my partners to follow the standards. I'd rather let my tools to be flexible enough to to work with they unstandard EDI documents.
     
    BTW it is interesting. Is somebody stay with the same problem (not flexible enough method to form the sender/receiver address)?
     
    Sunday, April 22, 2007 6:18 PM
  • Leonid,

     

    You should still be able to handle inbound documents. Just set up one party. All documents will be received correctly and acknowledgments will be generated correctly. For outbound documents you can specify different GS level envelopes by GS ID and Doc type. You just need to specify a different schema namespace for unique GS ID and doc type combination. That will require a schema for each party where this is an issue and if you are employing maps then a separate map.

    Sunday, April 22, 2007 8:19 PM
  • Tony, of course.
     
    I just like to use the PartyName as a context property in my orchestration.
    It's not about routing.
     
    Thanks anyway.
     
    Monday, April 23, 2007 12:59 AM
  • I am also somewhat confused by this.  We have an exisiting 2002 solution which has > 500 partners and we act as a hub.  Currently, we have a custom AIC preprocess for EDI documents where we overwrite the GS receiverID of incoming document with our identifier such that the reciever organization always resolves to us. 

     

    We obtain the real receiver further in processing once the message is in the system.

     

    We basically did not want to create an organization to represent every trading agreement between partners so by having us hardcoded in as the receiver organization it made things easier.  As you can imagine, having ot create an organization, map ect for every possible combination of partner to partner transactiopn would get really messy.

    The result of this replacement at the GS receiverID level was every inbound EDI is essentialy trading with us and mapped to our canonical schema as BT 02 apparently used the GS level receiver ID to determine the receiving organanization, schema and map. Downstream in code, we determine through the content of the canonical document or a snapshot of the EDI document before the replacement, who the true recipient is for outbound processing.

     

     In 06, it looks like only the ISA level stuff is used for party resolution so I'm confused as to how I'll be able to duplicate the "hub" like behavior we had in 02.  I'm puzzled why GS2 level cannot be chosen for party resolution or perhaps I'm just misunderstanding how this works

    Monday, April 23, 2007 8:19 PM