The following example is available in the BizTalk SDK, and represents an 850 “Purchase Order Document”, We will be describing some how to read this EDI data in this blog.
{!{code}!}czo2MTk6XCINCklTQSowMCogICAgICAgICAgKjAwKiAgICAgICAgICAqWloqVEhFTSAgICAgICAgICAgKlpaKlVTICAgICAgICAgICB7WyYqJl19ICAqOTkxMjIxKjEyMjYqVSowMDQwMSowMDAwMDAwMjUqMCpUKiZndDsNCkdTKlBPKlRIRU0qVVMqMTk5OTEyMjEqMTIyNioxKlgqMHtbJiomXX0wNDAxMA0KU1QqODUwKjAwMDENCkJFRyowMCpORSozODU5MTk5ODM4Kio5NTA3MjcqKipJQk0NClBFUipBQSpBbmRyZXcgQ2FybHNve1smKiZdfW4qVEUqKDcwOCkgNTU1LTI5MzANCkRUTSowMDIqOTcwNTIzDQpQTzEqMSo5MypCWCoxNDUuMzkqKkNCKktPVy0yMDM5Mi0xMA0KUEl7WyYqJl19RCpGKioqKlVuaW50ZXJydXB0aWJsZSBQb3dlciBTeXN0ZW0NClBFUipBQSpDYW1pbGxhIEFuZGVyc29uKlRFKig3MDgpIDU1NS0yMHtbJiomXX0xMQ0KUE8xKjIqMjUqRUEqMzUuNjgqKkNCKjEwOTMtNDkyNy0wMDENClBJRCpGKioqKkhpZ2ggVm9sdW1lIFByaW50ZXIgU3RhbmQNe1smKiZdfQpQRVIqQUEqTWlyYW5kYSBDYXBwZWxhbipURSooNzA4KSA1NTUtMTExMQ0KUE8xKjMqNCpQQyoyMDAyLjkxKipDQipBQlgtMjAwMQ17WyYqJl19ClBJRCpGKioqKkVsZWN0cm9uaWNzIENhYmluZXQgUGFja2FnZSAoNTZcIiBIaWdoKQ0KQ1RUKjMNClNFKjE0KjAwMDENCkdFKjEqMQ17WyYqJl19CklFQSoxKjAwMDAwMDAyNQ0KXCI7e1smKiZdfQ=={!{/code}!}After installing BizTalk, this file can be found here: “c:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\EDI Interface Developer Tutorial\ProcessEDI_TestLocations\SamplePO.txt”. It is part of the SDK (Software Developers Kit), which includes common usage scenarios of BizTalk.
A list of the common EDI X12 message can be found here on Wikipedia.
I did the following Google search beg03 x12 401, which resulted in several companies providing public PDF descriptions describing their requirements for sending or receiving 850 documents. For example, this 850 document was very useful in describing how to break down the above 850 message.
In the above sample document, the asterisk “*” is used as the primary separator character. Each line begins with a two or three character prefix (for example, ISA, GS, ST, BEG, etc… called a Segment Identifier (thus each line is a “Segment”). One advantage of XML over EDI is that every data value is identified by an name (either an element or attribute). When looking at an EDI document, you have to have the “decoder” ring or past experience to interpret the document by just looking at it.
Here’s a short clip from the above PDF document. That document is an “Implementation Guide” which gives the specifics about how two companies should implement the more general standard.
For example, in the above you see “PO1*2*25*EA*35.68**CB*1093-4927-001”.
Each data value is given a name based on the Segment ID and then followed by a two digit position. So for example, the first field of interest to us is PO102, which is the “Quantity Ordered” which has a value of 25. PO103 is the “Unit or Basis for Measurement Code”. Looking at the EDI values, we see “BX”, “EA”, and “PC” on different P01 segments, with specifically the value of “EA” on the segment we are looking at. It’s not shown in the above clip, but you might guess that is PO104 is the price (value of 35.68), because it has two decimal places.
When you see several asterisks side by side, that means that a field value in between has been omitted.So PO105 is missing or null, and PO106 has the value of “CB” for the “Product/Service ID Qualifier”. Note that in the above PDF, that specific company accepts three values MF, MG, VP, so obviously our document from the BizTalk sample library was not specific to the rules of the specific company providing that PDF.
BizTalk internally treats all messages as XML, allowing them to be mapped with the BizTalk mapper (which is actually XSLT under the cover). It is the BizTalk Adapter specified in the Receive Pipeline that converts the EDI data to XML data. Below is an example of a BizTalk map in the SDK, showing the mapping of the P01 segment to an internal XML format with more meaningful names:
