Estimated reading time: 4 minutes, 45 seconds

Purchase Order Acknowledgment - follow the EDI Standards or used in practice

received stampAs electronic trading continues to evolve, one of the areas of interest is with buying organizations wanting to get confirmation of the receipt of orders, on-going alerts on the order status and managing requested changes. What I'm talking about here is the use of the 855 Purchase Order Acknowledgement transaction and the confusion on the expected use or interpretation of this transaction.

EDI Standards definition/Usage - X12 EDI Standards defines the use of the 855 transaction in two ways -
  1. The transaction set can be used to provide for customary and established business and industry practice relative to a seller's acknowledgment of a buyer's purchase order.
  2. This transaction set can also be used as notification of a vendor generated order. This usage advises a buyer that a vendor has or will ship merchandise as prearranged in their partnership.
 Usage in Practice - 
  • 855 POA - Receipt confirmation - in this use the 855 is primarily used in the Direct to Consumer (Drop Ship) order cycle where a supplier receives an 850 and the Retailer/Etailer wants confirmation on the receipt of the order within their supplier's Order Processing system. There is some similar use with Store or DC orders, however they are not currently widely used for these orders. For the B2C orders this 855 is pretty much an "Accept" or "Reject" concept based on the assumption that most online consumer orders are one item per order. So the assumption may be well founded as certainly with many website orders the average consumer purchases one item per order, However what's interesting is that many Retailers/Etailers have the suppliers acknowledge at the item level. This seems redundant if the header level of the 855 indicates Accepted; what's the need for the detail confirmation? There are some Retailer/Etailers that do include item level acknowledgement - not only confirmation, but provide Estimated Ship Dates. The primary reason then is to be able to report to the consumer orders statuses. Regardless of the nature or detail being provided, the usage in practice appears to match the X12 Standards definition #1 above. So far so good. 
  • 855 Suggested PO - in this use case the suppliers typically are provided POS (852) EDI data representing either what was sold daily or weekly and/or in some cases on hand inventory. The suppliers are then required to provide an 855 PO Acknowledgment that many refer to as a Supplier Suggested PO for what they believe the location should receive. Within the data the suppliers provide a Retailer's PO number (provided in blocks as part of a VMI (Vendor Managed Inventory) Model. Prior to the VMI relationship beginning, the retailers would have created a shell of the PO (excluding item details) and the 855 Suggested PO is received and the details updated to the Retailers order system. In some cases the retailer confirms acceptance by transmitting an 850, but not always. In any event, from that point the supply chain then looks like any other Store or DC model, and ASN's and Invoice are provided by the suppliers. Again, usage in practice matches the X12 Standards definition, this time #2 above. And again, so far so good. 
  • 855 Receipt and Request for Change - This usage is where the confusion tends to come into play. What I'm seeing is that, primarily with store or DC shipments, not only is the 855 used as a Receipt confirmation but is also used or expected to indicate the supplier's intent to ship the order. It is also used to request changes to the original order. This Requested Change concept does not seem to match the X12 EDI standards usage. However, as you look into the details that the 855 transaction supports, there are segments, elements and qualifiers that reinforce that even though the X12 Standard has not defined this usage, the transaction details actually function. As I continue to work with EDI standards I've learned that the correct transaction for a "Supplier Requested" order change should probably be the 865 Purchase Order Change Acknowledgement. In the past, most companies that use the 865 (less than 1% two years ago now up to 10%) use it for Receipt and Acceptance Confirmation of the 860 Purchase Order Change. However, based on the X12 EDI Standards definition below, there's another use - 
    1. The transaction set can be used to convey acceptance or rejection of changes to a previously submitted purchase order by the seller or
    2. to notify the buyer of changes initiated by the seller to a previously submitted purchase order by the seller. 
To add further color to the 865, the more common use, thus why the growth in interest of this transaction, is with B2C order fulfillment. Those that use this transaction for B2C are really only using this for Confirmation that a Canceled order has been kept from being shipped or not. I have yet to seen any retailers that I've worked with that are using the 865 as indicated in #a above.
So, what is the correct usage of the 855 as a Purchase Order knowledge vs. the 865 POC acknowledgement? Maybe they both are? I'd love to have feedback on your experience with these. However, at this point, the usage I've explained above is in practice. Thus Standards may be getting redefined. Some of what is happening in practice may be that the 855 is more established, and it's easier to go with what is in place verses using a new transaction.
Lastly, regardless of whether the 855 or the 865 are used as a Supplier's Request for "Change" or "Provide order statuses" there is value to trading partners exchanging data to automate this process that had in the past been manual (something about an "Audit Trail" or holding partners "accountable").
Read 4428 times
Rate this item
(0 votes)

Visit other PMG Sites:

PMG360 is committed to protecting the privacy of the personal data we collect from our subscribers/agents/customers/exhibitors and sponsors. On May 25th, the European's GDPR policy will be enforced. Nothing is changing about your current settings or how your information is processed, however, we have made a few changes. We have updated our Privacy Policy and Cookie Policy to make it easier for you to understand what information we collect, how and why we collect it.