better handling of partners in x12 (edifact)

[GoogleCodeExporter]

In x12 edi-partner ID's are more elaborate than in edifact. 
(in edifact often a GLN is used - simple and unique)
X12 has:
- ISA ID
- ISA qualifier: indicate the type of ISA ID: GLN, DUNS, phone number etc.
- GS ID
Most of the time the ISA ID == GS ID.
To make the ISA ID unique, the ISA qualifier is needed.
But to is possible that same ISA ID/ISA qualifier has more GS ID 9more internal 
partners in same holding.
There are 2 ways to handle this correctly:
1. partnerID is a combination of ISA ID/qualifier/GS ID. Can be picked up from 
incoming X12; extract these values in enveloping.
2. Use internal partnerID. Convert this from/to ISAID/qual/GSID.

Original issue reported on code.google.com by hjebb...@gmail.com on 17 Apr 2015 at 4:13

[djfurman]

@eppye,

I think that your methods above will work, but I'd offer a different possibility.

For each X12 file, we can uniquely identify it by concatenating ISA05 + ISA06 + ISA07 + ISA08 + ISA13. For each group within the unique X12 file, we can identify it by simply referencing the GS06 with the above unique ID. The GS02 and GS03 values should always match ISA06 and ISA08 respectively since they just restate the interface that the file is set within and hold one type of transaction.

X12 provides:

• Sender qual (ISA05) sender ID (ISA06)
• Destination qual (ISA07) destination ID (ISA08)
• Interface ID (ISA13)

The GS envelope provides an internal packaging for each ISA outer envelope, but really only exists to hold the differences between things like 810, 850, 860 all being sent to the same location in a merged document. The GS08 is unique only to the concatenation above, and could restart at 0001 for each new file legitimately.

So in this method the full hash would be to concatenate ISA05 + ISA06 + ISA07 + ISA08 + ISA13 + GS08 + ST02.

I hope this helps, and please let me know if I can help implement when assigned to a milestone.

[eppye]

hi Daniel,

wrote that some time ago.

better solution is to have sender: ISA5 + ISA6 + GS02 ->GS02 is
needed! 
than to make this work with edifact (I am Europe-based) one needs a
seperator (as equivalent fields in edifact are not fixed length.
same for receiver.

in dev I have this working.

It is not possible to uniqely identify an x12 file that way.
There is an error in your thinking (do not want to be unfriendly,
but want to state it clear)
The internal working of your system can (in the edi layer) not
depend upon what the other site sends.

kind regards,

Henk-Jan Ebbers www.ebbersconsult.com t: 0031 30 2888358

Bots Open Source EDI Translator: http://bots.sourceforge.net Connect edi-partners at lower costs by smarter testing: www.edi-testrobot.com

On 02/17/2016 07:16 PM, Daniel J.
  Furman wrote:

  @eppye,
  I think that your methods above will work, but I'd offer a
    different possibility.
  For each X12 file, we can uniquely identify it by concatenating
    ISA05 + ISA06 + ISA07 + ISA08 + ISA13.
    For each group within the unique X12 file, we can identify it by
    simply referencing the GS06 with the above unique ID. The GS02
    and GS03 values should always match ISA06 and ISA08 respectively
    since they just restate the interface that the file is set
    within and hold one type of transaction.
  X12 provides:

    Sender qual (ISA05) sender ID (ISA06)
    Destination qual (ISA07) destination ID (ISA08)
    Interface ID (ISA13)

  The GS envelope provides an internal packaging for each ISA
    outer envelope, but really only exists to hold the differences
    between things like 810, 850, 860 all being sent to the same
    location in a merged document. The GS08 is unique only to the
    concatenation above, and could restart at 0001 for each new file
    legitimately.
  So in this method the full hash would be to concatenate ISA05 +
    ISA06 + ISA07 + ISA08 + ISA13 + GS08 + ST02. 
  I hope this helps, and please let me know if I can help
    implement when assigned to a milestone.
  —
    Reply to this email directly or view
      it on GitHub.

[djfurman]

I see where you're coming from, @eppye.

It makes a lot of sense to not create a method that fails to transfer between format.

Not unfriendly at all! I'm really enjoying working with BOTS & I'm hoping I can add value to the the project.

Thanks for the prompt reply!

[eppye]

thank you for helping think about this.
not a lot of people understand the issues.

kind regards,

Henk-Jan Ebbers www.ebbersconsult.com t: 0031 30 2888358

Bots Open Source EDI Translator: http://bots.sourceforge.net Connect edi-partners at lower costs by smarter testing: www.edi-testrobot.com

On 02/17/2016 09:02 PM, Daniel J.
  Furman wrote:

  I see where you're coming from, @eppye.
  It makes a lot of sense to not create a method that fails to
    transfer between format.
  Not unfriendly at all! I'm really enjoying working with BOTS
    & I'm hoping I can add value to the the project. 
  Thanks for the prompt reply!
  —
    Reply to this email directly or view
      it on GitHub.