What is an ANSI X12 EDI 860 Message?

An ANSI X12 EDI 860 message is used to update and amend a previously sent EDI 850 message. If amendments to previous purchase orders are required, the EDI 860 Purchase order change is generated, references the past purchase order number, and details the required changes. This message follows the EDI message standard ANSI X12 and is used in conjunction with EDI 850 messages.

The buying organization would first create an EDI 850 purchase order to place the initial request with their supplier. The EDI 860 message can then be used to change or cancel one or more items/goods from a previously sent order. They can also relate to one or many different delivery schedules. They are also used to update the supplier with previously unknown details specific to the order, such as customs, transport, and delivery details.

The supplier than can answer with a purchase order acknowledgement ANSI X12 EDI 855. In this, he can either confirm receiving the EDI 860 or he from his side requests now changes.

The EDI 860 message is wide-spread in CPG and retail. Due to fresh food considerations the grocery retail has its own purchase order change message triggered by the buyer, the EDI 876.

Purchase order change messages follow a set structure of segments and elements specific to the ANSI X12 standard. The buyer’s own in house ERP system would create a message containing all the required order change information, such as SAP IDoc relating to an EDI 860, which is then translated according to the EDI 860 mapping document via the EDI solution in place. The answer is an EDI software for in-house usage or an EDI Cloud Service.

A typical ANSI X12 EDI 860 message contains:

• Buyer and seller information
• Previous Purchase Order details
• Ordered material details, with required quantity’s and dates
• Details on whether the material details requested are to be added, removed or changed
• Delivery details, both when and where

Using EDI suffers from unknown or wrong master data. Referrals that the supplier can’t interpret correctly lead to EDI 860 that is not accepted. For instance

• Goods requested may not be available in the supplier’s ERP system, or under another code
• Specific location codes, such as gate, warehouse or dock are unknown by the supplier

EDIFACT is widespread in Europe and most parts of Asia, and the current standard defined by the UN. UN/EDIFACT uses a single ORDCHG document to cover all purchase order change types. TRADACOMS has often been seen in the UK CPG retail industry: With TRADCOMS the ORDHDR works as both the initial Order and any subsequent Order Change after that if needed.

Operating EDI can be complicated and time-consuming while EDI processes need to be flexible, run stable, and cost-effectively to automate the purchasing process. The SEEBURGER BIS Platform provides precisely this as a Fully Managed EDI Cloud Service in the SEEBURGER Cloud or a public cloud environment (e.g. Google, Azure, AWS, etc.) or as an on-premises software solution.

Fully Managed EDI Clouds deliver EDI technology and the needed expertise responsible for running your EDI solution. SEEBURGER, has the expert team which provides the ongoing management of your EDI solution, so you don’t need to worry about EDI errors and chargebacks.