Edi standards and their use.

Different edi standards

In the US, x12 is often used for edi. In the UK, it's often tradacoms. In 'the rest of the world', the prevalent standard is edifact. XML is being used, but not as much as the 'old' edi standards. XML is mostly adopted by 'new' edi communities. It looks like it's very hard to change the big body of existing edi connections. And yet, it's only a syntax - standardisation issues are not resolved by using a different syntax...

Why can't I just implement the xxx edi standard - all of it?

It's not like 'this is the standard, implement it and you're done'. NOBODY implements the whole edi standard. This is because edi standards support so many business practices, sectors, countries etc. - and your company neither wants nor is able to support all of this. And there are more problems:

• Different standards (eg x12, edifact, XML).
• Different versions of standards.
• Trading partners using their own home-baked standards - why use a standard if you can make your own?
• Subsets/MIG's are not always compatible.
• Nobody enforces standard compliance. Each edi partner has their own interpretation - they know they're not doing it right, but...

Subsets/MIG's/interpretations of edi standards.

As the edi standards are so big, everybody uses subsets tailored to their needs. Such a subset is sometimes called a 'Message Implementation Guide' (MIG), companion guide, etc. These subsets can be:

• Per sector: EANCOM, VICS, etc.
• Per retailer.
• Per country. Especially in Europe - think of local trade traditions and language problems.
• Per country/sector; e.g. German CCG standards.
• Etc.

A trading partner will often refer to their specific subset as 'the standard', which is obviously confusing. It is only a subset of the standard, and implementing their subset might not work for other trading partners. See also: Setting up edi in a stable way..

If used correctly, the different subsets are compatible, as they are derived from the same standard. Schematically:

We have been doing business with company X for years - so edi should be quite easy, right?

We hope so. But this is not always true:

• In edi, the information is processed by computers rather than humans, and computers aren't as flexible... Examples: use of codes for partner identification, UPC/EAN code for products, standardised date/time formats etc.
• Trading partners use edi to force their administrative procedures upon your company. These adminstrative procedures are often more strict, and better enforced.
• Edi is often used as a tool in e.g. logistic changes. For example, a supplier should deliver to a DC prepacked per shop, or do daily deliveries. Without edi this leads to an explosion of packing lists, invoices etc, and the administative cost would rise dramatically.
• New business practices. For example, store departments starting to do consignment. This might be new to your organisation.

Are edi standards good?

Well: reasonable.
A lot of business practices are supported, in different sectors, countries, etc. So the standards can be 'big' it might be hard to figure out what you need. That's why all the subsets exist in the first place.

When setting out with edi, the documentation (of standards and subsets) can be quite confusing.
Often, the documentation is written from a very technical point of view. Or just plain bad. Some trading partners are just using example messages and saying 'this is how we want edi'.
Different trading partners each use their own documentation, probably in their own format. So you end end up comparing all of these...