EDI 860 purchase order change request: BCH and POC change codes

BCH states whether this is a change or a cancellation

BCH is the beginning segment for a purchase order change. BCH01 is the transaction set purpose code and separates a change from a cancellation of the whole order, with 04 commonly used for a change and 01 for a cancellation. BCH02 repeats the purchase order type code from the original order. BCH03 carries the purchase order number, and BCH06 a release number when the order is a release against a blanket. Cancelling an order and changing every line to zero are not the same instruction, and suppliers do not treat them the same way.

• BCH01 transaction set purpose code, commonly 01 cancellation or 04 change
• BCH02 purchase order type code, carried over from the original order
• BCH03 purchase order number, matching BEG03 on the original 850
• BCH06 release number when the order is a release against a blanket

POC carries the change, one line at a time

POC is the line item change segment. POC01 is the assigned identification, that is the line number from the original order, and POC02 is the change or response type code that says what is being done to that line. POC03 and POC04 carry quantity ordered and quantity left to receive, POC05 the unit of measure, and POC06 the unit price. Because POC02 and the quantity fields are independent, it is possible to send a code that says quantity decrease alongside a quantity that increased. Validate the two against each other before transmitting.

• AI add item, a line that was not on the original order
• CA changes to line items
• DI delete item
• PC price change
• QD quantity decrease
• QI quantity increase

Send the change with enough context to be applied

An 860 that carries only the changed lines depends entirely on the supplier holding the original correctly. Trading partners differ on whether an 860 replaces the order or amends it, and that single question decides whether an omitted line means unchanged or cancelled. Agree the answer in writing before the first change goes out, record it in the implementation guide for the relationship, and test it with a two line order where one line changes and the other does not.

Expect an 865 and treat the change as unconfirmed until it arrives

A buyer initiated change is a request, not a fact. The supplier replies with an 865 purchase order change acknowledgment, which may accept the change, reject it, or accept part of it. Until that reply arrives, the order is in a state where the buyer believes one thing and the supplier may still be working to another. Reports that show the amended quantity as the current commitment before the 865 arrives are a direct cause of the shortages that surface at receiving.

Never overwrite the original when a change is approved

The most damaging habit in change management is updating the order line in place. Once the ordered quantity, price, or date has been replaced by the changed value, the question of what was originally agreed and who authorised the difference can no longer be answered from the record. Keep the original ordered values, the requested change, the supplier response, and the resulting current commitment as four separate facts with owners and timestamps, whether the change travelled as an 860 or as an email.

The same change, for suppliers with no EDI connection

Buyers change orders with every supplier, not only the ones on X12. For the rest, a change is usually an email asking a supplier to confirm a new date or quantity, and the confirmation arrives as prose in a reply. Pacteva structures that exchange: the buyer issues the change, the supplier responds per line, and the resulting commitment is stored beside the original ordered value with the buyer decision that authorised it. Pacteva does not send an 860 and does not act as an EDI translator.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.