Back a few years ago there was a dilemma regarding whether to send changes electronically or not. Then there was the discussion of how that should be done. Good news is that there is a growing interest in communicating electronically. When I first commented on managing changes electronically, my experience was that only 25 - 30 % of the retailers that sent orders via EDI also sent their changes electronically. A year ago that changes to 35 - 40% however I now see this growing to over 50%.

Much if this has to do with movement to Factory shipments directly to the end consumer. The change comes when retailers implement E-Commerce. The challenge they were faced with was the growth in canceled orders, and the ability to stop the order from shipping. When a consumer shops online, it is more of a challenge to imagine what the product is really like without the touch/feel of the physical product. This means that with an increase in online orders will come an increase in canceled orders as well. With the fact that there is a much shorter lead time expectation with shipments direct from the factory than those delivered to a retailers facility, the need to automate the reporting of the cancelations and confirmation of stopped shipment also becomes more important.

In addition to the automation of changes for E-Commerce orders there is a growing interest in orders shipped to a DC or Store location. In talking with many retailers, the change has to do with the lack of confidence that the suppliers are actually getting information on changed orders. Prior to sending changes electronically, there was an attempt to have staff assigned to follow up with every order change emailed or faxed to a supplier as a method to solve this problem. The outcome of that exercise was that it confirmed the delivery method of sending changes via email or fax was not working, and that partners were not receiving many of the changes. Some of this was lost faxes or lack of an ability to get confirmation the success of a fax and with email. Some missed deliveries had to do with the change in personnel and their email addresses.

That increased the number of people needed to manage this type of follow up, as companies came to realize that there were way too many changes being made against the open orders.  Back then if you talked with a supplier, it would not be uncommon to hear them say "I treat an original PO as a Forecast since so many of my customers make so many updates to their orders." Sounds like the retailers should be collaborating through the use of a forecast; and we'll talk about that another day. With each of the scenarios I've mentioned, the move to sending electronically became an obviously better solution.

How changes should be communicated became the next obstacle. Many retailers did not discuss with their partners the preferred method. Rather, they simply made changes to code and began sending updated PO's, or a replacement, or they canceled the 850. They did automate the process however. They learned that the suppliers were not prepared to see a different code in the 850 to indicate a change or cancelation, so their systems would reject the transmission as a duplicate PO. At least this did bring to the suppliers attention that there was a change being made. However that was not the case with all suppliers.

Many suppliers did not have a "duplicate PO" check when processing electronic orders. What this meant was duplicate shipments. For those suppliers that did catch the duplicates and were able to manage the different 850 types, what they realized was that they had do have so much complexity in their coding for these changes that many times they missed what the retailer was actually changing. They then realized that some of the changes were cancelations which would automatically be managed.

At least when they were getting faxed or emailed changes, the supplier had a chance to discuss or negotiate different terms or pricing to keep the order open. Integrated processing did not allow that. To address that situation, many decided to manually process the updated 850's through reports to the Customer Service Department. As you can image, that too had issues. The primary being the updated 850 did not specify what exactly was changing. To the supplier, that meant adding resources to compare the updated order to the one previously sent in order to determine what change was being communicated.

The 860

"Now, what do we do?" Ah.... EDI Standards support an 860 as a change to the 850. Over the past several months I've seen many retailers switch from the 850 updates to an 860 PO Change. That change did not solve all of the problems but it did start things going in the right direction. It solved that problem with duplicate shipments since we now have another EDI document however, with a new document means the suppliers need to map and test against this new transaction. What we also learned is that some of the retailers that implemented the 860 continued to send a full replacement of order with the changes included. To a supplier this is the same as an updated 850 in that none of the changes were specified, so they were back to manual review.

For those that are not that familiar with the 860, this document was originally designed to report only the information about the PO or items on that order that have changed. Implementing the 860 has helped but there are still areas of improved that I'd recommend either side of the partnership to support -

• An 860 may only contain order level changes, thus suppliers should not expect item information on a given 860
• If item information is changing, the retailer should do their best to use the appropriate item level change code. I've seen too many retailers use a generic (catch all) code "CA" to communicate that there is a change to an item. This code should really only be used if there are more attributes changing against the item than another code in the 2nd element of the POC segment would support.
• If item information is changing, use codes that are standardized. For example use RZ, for SDQ allocation changes verses CA.
• There are still issues with interpretations with how quantity changes are reported on an 860. I've seen some retailers report that the quantity in the 4th element of the POC segment is the quantity change, where another retailer will communicate that the quantity in that same element is the net new quantity (as defined by EDI standards, Quantity left to Receive). I've also seen a retailer send the same Item/part number information more than once; one to remove the item and then another to add it back. For most suppliers this is a duplicate and would be rejected
• For retailers, lets collaborate with your supplier partners or get feedback from peer Retailers on how their 860 works so we can get continuity going,
• Also for Retailers, make sure that you are clear on how you plan to report information.

Another though would be to alert suppliers that many EDI Service providers (SaaS or Managed Services) are very familiar with each partner's implementation or coding of the 860, and perhaps utilize the tools they have to manage PO changes, verses trying to do this yourselves. Many use a browser based application that can be used like a report you would create yourself at a pretty low entry cost.