In EDI there is a construct called a Loop. But this is not like you…
When we are dealing with supply chain or e-commerce related EDI, we probably will deal with line item data. On a Purchase Order, (PO) or 850, the line item data is contained on the PO1 segment or the PO1 group. (PO1 is a group or loop so it is more than just a segment.) In this article we will discuss what data is found on the PO1 segment, and how it should be handled on both inbound and outbound document. For clarity, we are going to use the 4010 x12 standard. The PO1 hasn’t changed in content for a while, but it has gotten longer, (you will see how this works when we talk about the PO1 elements).
Parts of the PO1
Here is a diagram of a sample PO1 segment:
Like any other segment in EDI, the PO1 segment is composed of elements. Here is a list, element by element and what it contains.
|PO1_01||This is the Line Identifier, or Line Number. This is a value that must be unique among the lines or PO1 segments of a purchase order. There is no rule that these must be incrementing integers starting at 1. But it is normal for these to be Numeric even if the type is Alpha-Numeric. And it is general practice to have them increment in some fashion. Thus having the first line item number as 1. The second as 2, and so forth. I have also seen the first line item being 10 , the second 20 and so forth. As well as 001 and 002.|
In any case, I would discourage using random numbers. And I would discourage using Alpha-Numerics. These may confuse your trading partners and cause them to have exceptions that there is no need to have. On the other hand, when planning on handling line numbers from other parties, you should expect that they might not be using nice incrementing numbers. This will prevent getting exceptions in your system when your trading partner does something odd.PO1_02 This is the quantity ordered. Most of the time people will just call this the quantity, but there are places and times, (like in order responses, invoices and shipping notices) that quantity ordered and other quantities have a distinction. The quantity is Numeric integers only. Ordering fractions of something is not supported. The PO1_02 is conditional with the PO1_03, if one exists the other is required.PO1_03 This is the Unit of Measure. It is a 2 character, Alpha-Numeric value. It is also an encoded value. Being “encoded” means that there is a list of acceptable values for this element, any value outside of that set is invalid and will cause an exception.
When the PO1_02 and PO1_03 are used together, we can tell how much of something is being ordered. 1 CA (1 case) is not the same as ordering 1 EA (1 each) of an item. Generally this is not a problem. The data in the catalog is accurate. When there is a problem, it is important to go back to the PO to find out exactly how many items were ordered and in what UOM.PO1_04 This is the Price. It is optional, but most of the time is present. It is required if the PO1_05 is present. This is a Numeric, but can be decimal it is not strictly currency formatted, so it is possible to have item prices that precise past .01. This is the price of a single item, so we would multiply the PO1_02 and the PO1_04 to arrive at the cost of the line item.PO1_05 This is the Price Basis Code. This is optional, and most of the time is not used. If it is used, it denotes where the PO1_04 price was derived from.PO1_06 Is a Product or Service Qualifier. This element is a 2 character, encoded value. All of the “Qualifier” defined elements are encoded values. This, again, means that there is a list of acceptable values for this element, any value outside of that set is invalid and will cause an exception.
This qualifier defines what type of value is found in the next element, the PO1_07. So if the PO1_06 has a “VC”, then the PO1_07 contains a Vendor’s Catalog Number. (This means it is a part number as found in the Vendor Catalog.)PO1_07 This is a Product or Service ID. It is Alpha-Numeric, and can be from 1 to 48 characters in length. It is conditional with the PO1_06, if one is present, the other must be present. This value is an identifier like a part number or other type of line item data.PO1_08 The PO1_08 has the exact same definition as the PO1_06 with the exception that it defines the type of value is found in the PO1_09.PO1_09 The PO1_09 has the exact same definition as the PO1_07. This is a Product or Service ID. It is Alpha-Numeric, and can be from 1 to 48 characters in length. It is conditional with the PO1_08, if one is present, the other must be present. This value is an identifier like a part number or other type of line item data.PO1_06 to PO1_25This pattern continues all way to PO1_24 and PO1_25. All of the segment pairs from PO1_06 t PO1_25 that have the same potential values for each pair. In earlier version of EDI, like 3010, the PO1 segment only had 23 elements. Or in other words it was one Product or Service pair shorter that what we have in 4010.
Good Form on PO1 line
EDI in Good Form is both style and best practice tips to avoid common exceptions. Paying attention to good form tips and best practices helps you create an integration solution that is not only complies to the standard, but functions to help you and your trading partner have an unnecessary support burden due to the avoidable unexpected.
1. It is bad from to have PO1 Product and Service pairs that are empty. This relates to not having any trailing element delimiters. It also goes along with not having empty pairs in the line with populated Product and Service element pairs following. Thus it is best to build your mapping so that optional data doesn’t create empty elements when it opts out.
2. When reading a PO1 line, it is best to assume that an expected Product and Service value could be in any pair. So the map needs to walk down the pairs of elements until it finds the qualifier that indicates the value you are looking for. This allows you to use the same input map with multiple EDI producing trading partners that may have interpreted the priority of data in different ways, and avoid exceptions.
3. When producing EDI with a PO1 line, it is best to be as consistent as possible with your placement of the Product and Service data. Create your logic and mapping so that mandatory data occurs early in the PO1 line, and optional data is moved to the end. This will keep your required data from hopping around positionally. This will help your trading partners that may not have had the foresight to follow Good Form Tip number 2 from having exceptions that slow down you process.
PO1 Loop Segments
As we said in the beginning, the PO1 is a segment, and a loop/group. And as you may have noticed, there is data that you may need that is not covered in the elements available in the PO1 Segment that belong to the line item. Values like Item Description, found in the PID segment. Or Tax information, found in the TAX and TXI segments. These and other values are found on the line item, but are not on the PO1 segment. We will have talk about some of these other segments and where to find other common data on another day.