ec-bp's Bloggers

Purchase Order Changes: An “Op-Ed” View

Written by Ken Kinlock
Published on Monday, 21 November 2011

global-search-iconI am calling this an “Op-Ed” View because my usual stomping grounds is the land of Material Releases, JIT Schedules, etc. where you have a different (easier?) change process. I am also going to try and paint a Global picture of how the purchase order change process occurs outside of North America. So here goes a different prospective than you might get from an “expert”:

The X12 860 EDI document type is used provide information required for the established business and industry practices relating to a purchase order change. The transaction can be used by the buyer to request a change to a previous purchase order, or by a buyer to confirm acceptance of a purchase order change sent by the seller or by mutual agreement of both parties.

What it is really is the information required for the support of long-standing practices relative to a purchase order change. This type of transaction is typically sent to the supplier from their trading partner(s) when a revision to the original purchase order is needed. There are an infinite number of possibilities available for a company to include all kinds of data on an 860 Purchase Order Change Request.

The typical response from an 860 is the 865 (Purchase Order Change Acknowledgment ) which basically confirms or denies that you, the supplier, can meet these demands from your customer. It gives the supplier an open window to incorporate these changes into their in-house (or Cloud-based) systems. Unfortunately, many suppliers just take the 860 and text it to the buyers or customer services people and then manually generate the mandated 865.

EDI around the world (for those who sell and supply globally):

EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport: “UN/EDIFACT” is the international EDI standard developed under the United Nations and knows no geographic boundaries. It too offers several opportunities:

  • ORDCHG is Purchase order change request message     ANSI 860 is ORDCHG in EDIFACT
  • ORDERS is Purchase order message
  • ORDRSP Purchase order response message
  • OSTENQ is Order status inquiry message
  • OSTRPT is Order status report message

The TRADACOMS standard developed by the ANA (Article Numbering Association) is predominant in the United Kingdom retail industry. I would avoid the use of Tradacoms invoices for international use if you can - they are only mandated for internal UK use (there is,  for example, no way of specifying different currencies). Message types are as follows:

  • ORDHDR is the purchase order but the others do not directly correlate to ANSI or EDIFACT
  • SORDET  is Supply and Returns Details
  • SORDAY  is Supply and Returns Summary
  • SRSHDR is Supply and Returns Summary
  • RIFHDR is Retail Issues File

This is mostly as it is because the business practices are different than U.S.

EANCOM  is a subset of EDIFACT with expanded code lists covering specific vertical industries and is maintained by the folks at GS1.

  • ORDCHG    Purchase Order Change Request
  • ORDERS     Purchase Order
  • ORDRSP      Purchase Order Response

RosettaNet member companies represent $1.2 trillion dollars in annual revenue, and transact billions of dollars in transactions within their trading networks using RosettaNet Partner Interface Processes (PIPs). RosettaNet PIPs allow trading partners of all sizes to connect electronically to process transactions and move information within their extended supply chains.

RosettaNet PIP Message Types:

  • 3A4 - Request Purchase Order
  • 3A5 - Query Order Status
  • 3A6 - Distribute Order Status
  • 3A7 - Notify of Purchase Order Update
  • 3A8 - Request Purchase Order Change
  • 3A9 - Request Purchase Order Cancellation


The ODETTE standard used within the European automotive industry offers these possibilities:

  • ORDERR - Purchase Order
  • ORDCHG - Order Change
  • REPORD - Order Response

But European automotive is like U.S. automotive (and appliances too): the production line utilizes Releases, JIT, KANBAN, etc. while only things like machine tools are P/O's.

Grocery (in the U.S.) is it's own little world because it grew up as a separate set of Standards and then merged into ANSI. Similar processes are possible here too.

Just because your customer is not in U.S., do not discount that they cannot accept X12. Best example is Carrefour (the French counterpart to Wal*Mart and also into groceries). They accept X12 or no excuses with them. However, they DO NOT support the 860 or ORDCHG. French retailer Auchan backed out of retail in U.S; but buys a lot of U.S. Products for its stores. They are in Europe, Russia and China; but, sorry, only EDIFACT. German retailer giant Schlecker, another big buyer of U.S. products,  has signed a supply chain agreement with Eurauchan, the purchasing division of Auchan.

I would say your key challenge is agreeing with your vendor(s) and coming up with a well-defined set of rules for what kinds of changes can be accepted, how long after the initial order date, or how soon before the scheduled ship date. As you well know, if you receive a change after you ship, you cannot just turn a ship around, like you might be able to turn a truck around (and then get fined for being late). The only thing you can, and MUST do, is ensure that an 860 or ORDCHG is processed throughout your systems as quickly as possible. Again, being in a Cloud environment, will be able to outrun the traditional EDI/VAN system. Best explanation of the P/O change process, including what to do if you have already shipped the order, is JC Penney. As far as manufacturers who buy tools and related items, Chrysler has the best process.

Enhanced by Zemanta

You have no rights to post comments

eC-BP Bloggers

eC-BP's bloggers offer their opinions and experiences in this series of (usually) short articles.

Supply Chain Buzz




Fields marked with an asterisk (*) are required.