Difference between the X12 Standard, Implementation Guides and TR3s
-
Hello,
I am having trouble understanding the difference between the definition of a transaction set as specified in the standard versus an implementation guide and a TR3.
I understand that an implementation guide is a particular implementation of the transaction set but isn't TR3 supposed to be the industry-specific guideline about how a transaction set is used?
-
Each of these serves a different purpose – I think it's helpful to start at the top and work your way down.
ASC X12, aka the X12 Standard, or just 'X12'
The Accredited Standards Committee (ASC) X12 is an ANSI-chartered standards body that has developed uniform standards for electronic interchange of business transactions – all in all, 321 transaction sets spanning 30+ releases, or versions, dating back to the 1980s.
The X12 Standard is a closed standard – you have to license the data in order to get raw access. It outlines all of the possible values available in all of the various transaction sets. In other words, it’s a form of schema.
Stedi provides a viewer for a human-readable version of this data in EDI Reference.
Implementation Guides, aka 'Business Rules' or 'Operating Rules'
An Implementation Guide is effectively a schema, too. It can either be a subset or a superset of the X12 Standard. Technically, it should be a subset, but some companies ‘break’ the standard by including values that don’t exist, misappropriating values that do exist, and so on.
You can see Walmart referencing its implementation guides – which it calls Business Rules – in its Getting Started with EDI document.
Uploaded files will be checked against EDI standards as well as an assortment of Walmart’s Business Rules for the document.
What Walmart means is that when you send an EDI file to Walmart, it will first make sure that your EDI file conforms to the X12 specification, and then it will do an additional check to ensure that it conforms to Walmart's subset of allowed segments and elements.
Types of Implementation Guides
There are two types of Implementation Guides – those provided by companies (e.g. Amazon or Walmart) and those provided by X12 itself (which are called TR3s).
Provided by companies
A company like Amazon creates an Implementation Guide (typically as a PDF) in order to constrain the set of values that they expect to send or receive in a given transaction set. For example, the 004010 X12 850 has a segment called ‘Advertising Demographic Information,’ which Amazon does not include in their 850 Implementation Guide.
These PDFs are sometimes produced with a tool such as Edifecs Specbuilder, though sometimes companies just produce their own using Word or Excel.
Instead of using these desktop tools or rolling their own, customers can use Stedi's Guide Builder to recreate PDF Implementation Guides – either to recreate guides that their trading partners have sent them, or to can create brand new guides to send to their trading partners.
Provided by X12: The Technical Report Type 3 (TR3)
From X12:
A [TR3 is] technical report that addresses the use of one or more transaction sets for one specific business purpose in order to facilitate consistent transaction set implementation within an industry or sub-industry. Each implementation guide is specific to one version of the EDI Standard.
In other words, a TR3 represents an industry-specific, 'official' implementation of a given transaction set. One example on an industry that has adopted an industry-wide convention is the healthcare industry – these are called X12 HIPAA guides.
As a general rule of thumb, if you’re in the healthcare industry, you use the official X12 HIPAA TR3s as a starting point; if you’re in any other industry, you use company-specific Implementation Guides.
Sample files
Along with PDF Implementation Guides, sample files are often provided. Whereas the PDF outlines the ‘schema,’ the sample files represent the payload. These are hand-rolled sample files that (ideally) provide representative data – as opposed to lorem ipsum dummy data.
These files are valuable for testing and comprehension (they are also often broken or out of date, but that’s another story).
In the case of Amazon, a sample file has realistic SKUs, prices, addresses, and more. A user can use an implementation guide to visually ‘validate’ a sample file – or they can paste a sample file into a Stedi Guide's Inspector tab to do it programmatically.