EANCOM vs UNEDIFACT standards

, , ,
#1

Hi All,

I understand EANCOM is a subset of UNEDIFACT EDI Standard, but have a question as below.

I came across EANCOM 2002 standard (when discussing with my external clients who wants to exchange EDI documents following this standard), but can’t see this standard listed in the wm documentation as supported.

Can you please help me understand if EANCOM 2002 has some alias name and if it is supported by wm EDI module?

Also, what need to be done on wm EDI module to support any custom EDI standard (which is accepted among a group of partners).

Kind regards,
Raj

#2

Hi Raj,

According to the documentation for 9-12, EANCOM versions 01B, 1, 2, 3, 93A, 96A. I’m not familiar with EANCOM, but perhaps version 2 includes 2002. Assuming that you will be installing the document type via wM TN, you can probably give it a try and see if it fits your requirements.

My response to the custom EDI document question is on another thread.

-Mary

#3

Hi Raj,

If you are referring to EANCOM 2002 syntax version 3 Software AG webMethods EDI Module supports the same under EANCOM 01B.

regards,
Suresh. G

#4

That’s something of an oxymoron. :slight_smile:

When a group agrees on how to use a particular variation of EDI, it is typically within the scope of the standard. The Implementation Guides you may have seen are “this is how we expect the 850 to be constructed.” They specify which data elements go in which segments, which segments are to be used, which codes are supported, etc. This is a particular usage of the EDI standard, not a customization. E.g. it is a subset. It does not add codes, segments, etc.

You won’t need to import any “custom” EDI definitions. You’ll use the standard documents in a VAN/partner-defined way.

HTH!

#5

Hi Reamon,

I get what you are saying, but I believe these days many companies have their own version of Implementation Guides (which are derived from the standard EDI structures) that they circulate it to their suppliers.

Please see these MIGs for example -

#6

Hi @Suresh_Ganta,

Thanks for the details. May I know where can I find these alias names mapping?

For example, you mentioned EANCOM2002 V3 is supported under EANCOM 01B. Would like to know where can I see such names mapping? The SAG EDI documentation appears to have the supported version only as ‘EANCOM 01B’ (in the documentation file I posted originally).

#7

“…these days…” implies that implementation guides are relatively new. Their use is as old as EDI itself. :slight_smile: They are not a recent thing.

The docs you shared are consistent with the typical implementation guides I’ve seen. “Derived”, “subset” or other term is fine. But these are not “custom EDI” which would need new document types. They are “how to use the standard document definitions in an agreed upon manner.” You can call that “custom” if you’d like, but there is no need to import anything extra – the standard doc types provided will cover what is needed. You follow the implementation guide to implement the transaction set/envelope/segment/field mapping (a document instance) not to define new document types.

#8

Hi @reamon,

When the MIGs are ‘derived’ from a standard EDI version (example: EANCOM D01B), the companies give a different meaning to an existing EDI input attribute, rather than defining a new / updating existing EDI input attribute name. Am I correct?

I’m referring to the below usecase as ‘custom EDI standard’…

For example, on EANCOM 2002 01B INVOICE document, if an attribute is defined to accept a number only, and if the company specific requirement asks to accept string as well for this attribute then that EDI document schema / dictionary need to be updated accordingly, with which it becomes a customised document.

Would like to know if such customisations are encouraged in general?

#9

The don’t give a different meaning. They give refined meaning. Consider the Winning-Appliance_MIG_Invoice implementation guide you shared.

Page 7 it indicates which segments are expected/supported in the heading section. The INVOIC message defines many, many segments. The MIG from Winning Appliances identifies which segments they use.

Page 8 identifies the segments for the detail section. Same note as above.

Page 10 identifies the details for how to use the UNB segment. The Partner identification code qualifier element defines the 2 codes that are specifically supported out of many, many codes that are possible as defined by the standards. The MIG is saying “use this subset.”

They are not defining anything new nor are they changing the definition of anything. Everything in the MIG is within the constraints of the defined standard. The defined standard is what the imported document types in wM IS/TN support.

They cannot do so. The VANs and partners will not accept that. If an element is defined in the standard as a number, then it must always be a number. To do otherwise makes it “non-EDI” not “custom EDI.”

No. Not only are they not encouraged they are not really allowed. If you start placing data into an element that does not conform to the definition within the standard, no one will accept it. The EDI software that everyone uses enforces conformance to the standards. There is no notion of “customizing the standard.”

I’ve never encountered a scenario the EDI docs could not address. If there is a data value that cannot be placed in a particular element due to type, there is most likely another place for that data. Either within the same segment or in another segment. And it is likely that other place is more appropriate. These standards have been vetted and updated extensively by many, many participants. It is highly unlikely that a given company has a scenario so unique that they would need to modify the definition a standard doc.

#10

Many thanks @reamon for the detailed explanation. Much appreciated.

I now understand that there is no such thing as ‘custom EDI’ document. It is only a subset of the EDI Standard document.

Have another question regarding the sub versions of the EDI Standard documents.

In the scenarios where a company needs to maintain atleast two different versions of the same EDI standard document (example: EANCOM 01B INVOICE to support B2B business for two different divisions in the same company), how do we install these sub versions in webMethods and maintain to co-exist in parallel ?

#11

As you’ve seen, there are different versions of the standards. They evolve over the years. The install for all of them is the same. You install the versions you need.

You seem to keep thinking that you’ll need a document type installed for each MIG. That is not the case.

When supporting a particular MIG, the MIG will state which of those standards to use.

Then, you implement the handling and mapping for that specific MIG in your TN and wM IS setup. You don’t define additional doc types. You use the standard doc types. This is not a “sub version”. It is a “populate or read the standard EDI document in this way.”

The INVOIC doc type is the same for both. What may differ is which segments/elements/codes are used. But that doesn’t mean you use a different doc type. You use the same (standard) doc type. There may be an ID of some sort in the envelopes that distinguish these 2. Or some other indicator so you know which is which. The differences will be handled in the TN profile and the wM IS code, not in the document types that are loaded.

HTH

#12

thanks @reamon for the details.

In the package wmEDIforTN, I see the EDI Standard document types installed are EANCOM 01B, V2, V3, V396A so on.

How can I know if they are for EANCOM 2002 or EANCOM 1997 or any other version? Is there any mapping sheet that I can refer to?

Kind regards,