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).
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.
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.
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.
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).
“…these days…” implies that implementation guides are relatively new. Their use is as old as EDI itself. 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.
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?
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.
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 ?
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.
Just to add here: may be exact answer reamon can provide
There are few properties files available under WmEDI package,
IntegrationServer/instances/default/packages/WmEDI/config
under that I can see some of EDI document mapping under “sefparse.cnf” file but I don’t see here EANCOM related mapping may be internally fetching details from individual package.
I don’t see these packages in designer but able to see via Admin page and these contains specific edi documents and schema in zip folder which you can give a try to copy in WmEDI_EANCOM/data directory which already has EDI documents registered with TN.
Just for reference adding link to EDI installation guide
One of the fun parts about standards is there are so many to choose from.
With EANCOM you’ll want to review any and all docs you can find on the web related to version designations. As an example, I came across a site with: “Edition 2016 EANCOM® Syntax 3 (based on UN/EDIFACT D.01B Syntax 3)” and later indicated “EANCOM® 2002 (2016 Edition)”.-- which may be listing standards versioning with software package versioning. So adding to the fun in this case are multiple standards in play, both with their own versioning scheme.
I wish I could provide more clarity or point you to the “source of truth” for these. Hopefully you’ll be able to locate the specific versions you need.
Yes, company groups often agree on a “subset” of a transaction sets implementation guide.
What that means is they take the industry implementation guide and make it smaller. For instance the industry guide may have a segment that is marked situation, but the company group decides they never need it, so they mark it as “NOT USED”, and they all agree they will not send it, or it will be ignored if it is sent.
I guess easier to understand wording for what they do is they agree to ONLY use part of the entire document spec, and that many of the “optional” segments in the industry spec will NOT be used.
NOTE that the company group should NEVER break the industry guide specs for that transaction set to you would still use the standard group to define new document types
