Customer Order Change Control for Manufacturers: Implementation Guide

When a manufacturer implements an order change control system, a customer’s request to increase quantity, accelerate delivery, or revise a specification cannot simply overwrite a sales order. The team must preserve the previous commitment, assess the effect on materials and production, approve a feasible proposal, confirm the new terms with the customer, and update ERP and MES from the same effective revision. This guide covers the workflow, data model, RFP, FAT, and SAT for a factory in Thailand.

Scope: a change after order agreement

An order change is a request to alter an agreed quantity, delivery date or destination, split shipment, product specification, or packing condition. It starts at a different point from initial quotation or purchasing and has different decision owners. Our order and purchasing management guide explains the wider order, purchasing, and MRP boundary. Our factory duplicate-entry guide covers MES, ERP, and WMS events. Here the question is which revised customer terms become effective, and when.

An order number can have several business decisions over time. If sales changes only the ERP date after an email arrives, production instructions and material commitments may still reflect the old promise. If production changes only its schedule, the factory may act before the customer accepts a revised offer. The target process receives the request, freezes the prior revision, evaluates consequences, approves a proposal, records the customer response, and releases only the agreed revision downstream.

Define the authoritative order record before selecting software

Identify an order by customer, order number, line, item or customer part number, ship-to location, delivery-schedule line, and revision. Increasing 100 units to 120 can mean revising the original line or placing a separate order for 20; the choice affects billing, shipment, and traceability. Keep the customer’s change-order number distinct from the internal order revision, with a cross-reference between them.

Capture a request as its own case instead of editing the live order directly. Record case ID, receipt time and time zone, requester, channel, original message and attachments, affected lines, requested changes, desired effective date, reply deadline, and owner. Confirm a request first received by phone with the customer, and distinguish the unconfirmed note from the confirmed instruction. Normalize email, EDI, and portal inputs into the same case model while preserving the source evidence.

Define the meaning of the previous, proposed, approved, and effective revisions. If V3 is the customer-confirmed order and V4 is under evaluation, the shop floor still uses V3. Internal approval of V4 does not prove that the customer has accepted it. Where the contract requires explicit customer assent, retain that evidence before making V4 effective. A revision number expresses sequence; a status expresses business authority. They are different fields.

Store before-and-after values, not just a list of edited field names. Snapshot relevant price, currency, transport, tax, and payment conditions even if they are outside the immediate request. For specification changes, link the drawing number and revision, effective BOM, inspection criteria, and customer approval. “Latest attachment” is not an adequate production reference. Retain the received file ID, content hash when practical, and storage location rather than depending only on a shared link that can later change.

Use one workflow for quantity, dates, and specifications, with different checks

Quantity increases may require additional material, capacity, inspection time, and shipping space. Decreases raise questions about purchased components, work in process, finished goods, cancellation rights, and who pays for unusable stock. Before promising a new date, assess available inventory after allocations, incoming supply, minimum lots, yield, and actual machine capacity. A lower quantity is not automatically a simpler change.

Keep the customer’s requested delivery date, the calculated feasible date, and the confirmed promise as separate fields. Microsoft’s order promising documentation describes ATP in terms of available supply and CTP in terms of material and capacity. It also illustrates that an update need not recalculate a promise while the existing date remains feasible. This describes a particular product, not a universal ERP behavior. Specify when your system must recalculate both earlier and later requests and who approves the response.

A specification change needs additional gates. Identify whether the drawing, material, process setting, inspection method, or label changes. Decide whether the new specification applies retrospectively, from a lot boundary, or from a future date only after evaluating identification of old and new stock, WIP segregation, rework or scrap, and customer approval. Issuing a new drawing alone does not complete the change if old materials or inspection fixtures remain on the line.

Split deliveries need more than a single quantity and date on the order line. Microsoft’s delivery schedules documentation describes separate quantity and date entries for multiple shipments. The requirements should distinguish total order quantity, each delivery line, already shipped quantities, and the remaining quantity that may still be changed. Swapping the first and second shipment can alter production even when the total remains equal.

Impact assessment must show the figures and their evidence

Put the prior agreement, requested change, and feasible alternatives side by side. For each alternative show the customer reply deadline, expected shipment and arrival, material shortages, equipment and labor load, subcontracted steps, quality approvals, incremental costs, and contractual conditions using data from a stated time. Support conditional options such as split delivery or another approved line; do not present them as commitments before the required quality, commercial, and customer approvals.

On-hand inventory is different from inventory available for this order. Exclude allocated, quality-held, dispatch-pending, or disputed stock as required by policy. For purchased materials show supplier response deadlines, cancellation rights, and transport time. For capacity include setup, inspection, packing, maintenance downtime, and the plant calendar, not just an empty machine slot. Make a subcontractor response an explicit pending state.

Microsoft’s action messages explain how changed sales demand can lead to proposed changes to existing supply orders. Its production planning guidance notes that manual planned-order changes may require another planning run before related material requirements reflect them. Treat these as prompts to test your own implementation: what triggers replanning, when are results read, and how does the screen prevent a reply based on stale data?

Adapt the columns to the industry and contract. Food and chemicals may need lot, shelf-life, or formulation checks; machining may need tooling and first-article inspection; electronics may need alternative-part approval. Review a small sample of recent change cases to find missed assessments and slow approvals before fixing the template. Ten cases is an illustrative practical starting point, not an official standard.

Separate authority to reply from authority to execute

Route requests by impact. A spelling correction to a destination before work starts should not follow the same path as a material change after production begins. Useful conditions include specification impact, production status, customer approval requirement, cost, delivery impact, and disposition of old stock. Set monetary thresholds from company policy and contracts, not from a generic article.

Distinguish intake, assessment, internal approval, customer proposal, customer acceptance, activation, downstream update, and closure. One person may hold several roles, but each decision needs its own timestamp and evidence. Whether an informal verbal answer is binding depends on the contract. The system should distinguish “being discussed,” “formally proposed,” “awaiting customer,” “confirmed,” and “cancelled,” and block unconfirmed terms from automatic release to the floor.

Show overdue cases and who owns the next response. A pending purchasing, quality, or customer answer requires a different follow-up. At the reply deadline, an owner can offer an alternative or issue an interim response. Automatically extending a promised date without approval changes the commercial commitment; record any extension and its authorizer.

Release the confirmed revision to ERP and MES

After confirmation, update the ERP order line, check the replanning result, and revise production or purchasing instructions where necessary. MES needs the item, quantity, route, and effective drawings and work standards. Do not silently overwrite an instruction already in progress. Record the stop of the old instruction, WIP disposition, and issue of the new one. Query WMS or shipping for picked, packed, and dispatched quantities before changing logistics instructions.

The OPC Foundation overview of ISA-95 describes an information model between enterprise planning and manufacturing operations. It does not prescribe this particular order-change workflow. It is useful when defining system boundaries and IDs: order, line, revision, work order, lot or serial, event time, and source system. Give each change an idempotency key so retries cannot apply the same quantity change twice; keep failed messages in a recoverable exception queue.

Define update order. If ERP confirms V4 while MES later reports work against V3, “last message wins” is unsafe. Compare expected prior and incoming revisions and route mismatches to an exception owner. Record the person, reason, source event, and result of any manual repair. Translate interface status text for local users while keeping event codes and identifiers independent of language.

Manage the customer commitment separately from technical delivery. Sales might confirm October 20 while the MES update fails. Conversely, the plant must not run a new specification before required customer assent. A release gate can check customer agreement, ERP application, MES receipt, and stop of the obsolete instruction. Use a change-type matrix to decide which gates apply rather than forcing every minor correction through all four.

Preserve a reconstructable audit trail

A timestamped edit list is insufficient. From one case, retrieve the original request, revision differences, age of planning inputs, alternative proposals, approval decisions, message sent to the customer, customer response, ERP and MES results, and exception handling. Set retention and access rights by contract and industry. A screen audit log is of little use if the referenced customer drawing can no longer be retrieved.

ISO’s ISO 10013:2021 announcement discusses guidance for documented information in a digital setting. ISO’s ISO 9001:2026 overview emphasizes customer focus, process approach, risk-based thinking, and improvement. Neither source mandates the specific screens described here. The proposed revision, evidence, approval, and tracking fields are an implementation design for reconstructing decisions.

Where physical-product linkage is required, relate the dispatched lot or serial number to the effective order revision. GS1 EPCIS 2.0.1 defines a TransactionEvent relating physical or digital objects to business transactions. That is a possible standard reference for cross-company traceability, not a requirement that every factory deploy EPCIS.

What to put in the RFP

“Supports order changes” is too vague. Provide scenarios for increased quantity, decreased quantity, accelerated date, split delivery, changed specification, and cancellation. For each, state the starting revision, input channel, approvers, constraints, expected customer response, ERP/MES/logistics result, and recovery from failure. Ask vendors to mark each requirement as standard configuration, setup, customization, or change to another system.

Group functional requirements into intake and revision control; assessment of materials, capacity, WIP, quality, cost, and transport; approval and customer communication; and ERP/MES application with retry and audit export. Include original evidence, before/after comparison, competing requests, data freshness, delegation of approval, deadlines, response documents, customer assent, and exception handling.

Nonfunctional requirements should cover concurrent editing, role separation, tamper-resistant logs, attachment limits, language and time zones, backup and recovery, API retries, and data migration. Test two people opening different revisions of the same case and one approving first. Between a Thai plant and a Japanese head office, distinguish local display time from stored UTC and destination arrival date from factory ship date.

Compare total implementation cost, not only licenses: ERP modification, MES mapping, historical data migration, forms, training, maintenance, and later specification changes. No universal cost figure follows from these sources. Give vendors case volume, sites, approvers, interfaces, and retention requirements, then request separate initial, subscription, development, and operating estimates. Clarify who supports customization after product upgrades.

When comparing proposals, do not use the attractive sample orders prepared by the vendor; instead, provide an anonymized, identical case from your own company. If a second change request from the customer arrives before the first evaluation is complete, have the vendor demonstrate which request to process first and how to invalidate the older proposal. For cases where only the delivery date changes versus cases where specifications change and customer approval is pending, both the screens and approval workflows will differ. For any part of the demo explained as “handled by operations,” record who will perform what tasks manually and whether the process can handle increased order volumes. Even if a feature appears standard, if necessary permission settings or master data preparation are not included, you may misjudge the implementation cost and timeline.

In addition to the method for entering order changes, require the documents to be sent back to the counterpart. Decide how to display the quantities, items, specification versions, shipping and arrival dates, effective start, and unresolved items before and after the change on the response document. If numbers are manually transcribed into the email body, there is a risk of sending conditions that differ from the system-approved version. When auto-generating response documents, ensure that only approved data is included, that the version increments upon re-issuance, and that sent documents cannot be altered afterward. If the customer uses their own purchase order format, link the response document to the customer’s change order number.

Also, clearly specify the behavior when a change request is canceled. Canceling an unapproved proposal is different from canceling after a confirmed response has been sent to the customer. In the latter case, it may not be possible to simply revert to the original conditions. If materials have already been ordered, manufacturing has started, or shipping slots have been reserved, the cancellation must be evaluated as a new change request with associated costs and actions. If the “Cancel” button simply deletes the history row, it cannot be audited. Design the system to retain the reason for cancellation, requester, approval, original commitment, and completed tasks, while only stopping subsequent unexecuted processes.

How to Handle Simultaneous Change Requests

There are cases where a customer’s purchasing representative sends a request to “increase the quantity,” and while that is being evaluated, another representative requests to “move up the delivery date.” When creating proposal A (V4) from the original confirmed version V3, and then proposal B (V4), A and B are not merely sequential versions but different candidates. Do not combine them into one without confirming with the customer whether B includes the quantity increase from A or only changes the delivery date. The order screen should indicate which confirmed version each candidate is based on, which customer request it corresponds to, and whether it is mutually exclusive or can be combined with other candidates.

If one staff member approves proposal A while another edits proposal B, there is a risk that the approved conditions will be lost when the later screen is saved. Upon saving, compare the “version you loaded” with the “current latest version,” and if there is a discrepancy, require a reload and re-evaluation. There may also be cases where inventory used in the impact assessment for proposal A has already been allocated to another order by the time proposal B is created. Attach the calculation timestamp and input data version to the evaluation results to prevent confirmed responses from being created based on outdated results. Records of detected conflicts, rejected candidates, and reasons for re-evaluation should also be retained in the audit log.

Determining Exceptions Across Effective Boundaries

“From when to apply the new conditions” should not be determined solely by the order date. Even if the new specification is to be applied to shipments after October 20, products shipped on October 20 may have already completed material input and inspection before that date. Clearly define the effective boundary in units appropriate to the product and process, such as manufacturing instruction number, lot, serial number, process start time, or shipping line. Decide whether to allow starting with the old version and completing with the new version, and if so, who will approve any additional inspections. If work-in-process items at the boundary are lumped into “other,” the quality department will not be able to track them.

The date of confirmed response to the customer and the date the new conditions become effective on the manufacturing side may differ. The safest sequence is to first obtain evidence of agreement for changes requiring customer consent, record the internally approved version as the confirmed response, update the ERP order and plan linked to that version, confirm receipt of the new version and suspension of old instructions in the MES, and finally permit effectiveness at the set lot or process boundary. If operations require parallel processing of responses and implementation due to urgency, clearly indicate any incomplete gates and hold off on starting manufacturing. In the event of a system failure where only the ERP is at V4 and the MES remains at V3, do not forcibly overwrite the order back to V3; instead, compare the customer response, completed tasks, and unexecuted instructions, and have the responsible person approve the recovery method.

Acceptance Data Set to Attach to the RFP

The test data set provided to the vendor should include customer and delivery destination, order number, order line, V3 conditions, the original customer change request, V4 proposals A and B, material inventory and allocations, scheduled receipts, capacity calendar, issued manufacturing instructions, work-in-process, shipped items, quality holds, and drawing versions. Amounts and customer names can be anonymized, but the keys for orders, materials, and manufacturing instructions must be consistent. Pair input data with expected outputs, and clearly specify judgments such as “proposal A results in material shortage,” “proposal B results in capacity shortage,” and “combining both requires a new delivery proposal.” Note that this is an illustrative example and does not claim that all factories will encounter the same shortages.

Furthermore, include not only normal cases but also abnormal cases such as sending the same change event twice, delivering a V3 message after V4 is confirmed, canceling customer approval, requesting a quantity reduction after shipment, or replacing only the drawing file. For each case, list the expected screen state, response document version, ERP and MES values, exception queue, and audit log. If you also save the settings and data versions used in testing, they can be reused for vendor comparison and regression testing after implementation. This will help reduce situations where “it worked in the demo” but cannot be reproduced in production.

FAT and SAT: test changes in the middle of work

For FAT, anonymize real cases and test creation of V4 from a confirmed V3, impact calculation, approval, customer-response generation, and simulated ERP/MES messages. A quantity increase should expose material shortage; an accelerated date should expose capacity constraints. Verify that an unapproved proposal cannot reach MES, approvers can read its evidence, and a rejected revision never becomes effective.

For SAT, connect the real ERP, MES, logistics, and email or EDI flows under actual user permissions. Test interrupted communications and retries, duplicate and out-of-order events, an edit from an obsolete screen, a specification change before customer agreement, and cancellation after production starts. Keep test orders and work orders out of live customer operations. At cutover, count unresolved cases and migrate them explicitly.

Write observable acceptance criteria: unapproved revisions are never dispatched to MES; an old-revision event remains in the exception queue; replaying one event changes quantity only once; and the customer reply contains only approved quantity and date. Derive response-time thresholds from measured system load and case volume rather than an arbitrary number in an article.

The data used for testing should include not only simple cases such as “one new order,” but also cases where there are two consecutive customer change requests, partial shipments where only the first delivery has been shipped, inventory on quality hold, components that have been ordered but not yet received, and manufacturing instructions that have already been started. For each case, fill in the expected version, status, approver, output documents, integration messages, and exception destinations in advance. If you decide pass/fail by looking at the screen after execution, the judgment may change later. It is important to determine the expected values beforehand and keep test evidence.

The switchover procedure should also be rehearsed as part of the SAT. Decide at what point the last change request received in the old system will be frozen, who will register it in the new system, who will keep provisional records if an urgent customer contact is received during the switchover, and to which version the system can be reverted if integration fails. Simply writing “previous database” as the rollback destination does not revert confirmed responses sent to customers or work that has already started in the factory. Separate the procedures for technical rollback from the business recovery actions performed by sales and manufacturing.

Phased rollout and measurement

Start with one product family where order-to-production links can be traced and changes occur often enough to learn. Before launch, measure elapsed time from intake to confirmed reply, revisions needed after the reply, ERP/MES mismatches, overdue cases, and time spent gathering audit evidence. Use the same definitions afterward and record changes in seasonality, volume, and customer mix. Base benefits on a measured baseline, not an invented reduction percentage.

Assign representatives from sales, planning, quality, and IT. Sales provides genuine customer requests; planning defines the boundary with released instructions; quality sets specification-change conditions; IT owns the data authority and integration exceptions. Review unanswered cases, approval backlog, exception messages, and use of obsolete revisions, not only how polished the screen looks. Train approvers and exception handlers as well as data-entry users.

Treat later change requests for the system itself as controlled cases. Customer-specific reply formats, recalculation after a destination change, or quality approval only for specification changes may be common rules, contract-specific exceptions, or one-off decisions. Separate these before hard-coding them. An auditor should be able to see why a particular case followed a different route.

At go-live, identify the authoritative version of each open order, list unresolved customer requests, and migrate unconfirmed cases. Importing every historical email does not reveal which message was finally approved. Choose a migration period and owner, and separate confirmed terms from pending proposals. Review the exception queue daily immediately after cutover, and confirm sales, planning, quality, and IT are looking at the same revision.

How should the return on investment be calculated?

Input time is only one component. Wrong-revision production, excess procurement, expedited transport, repeat inspection, repeated customer replies, and audit searches may also matter. Separate routine handling time from exceptional losses; preserve event counts, impact, and cost evidence. Label any benefit estimate as a calculation from your own data, never as a result achieved by another company.

Is the existing ERP change function sufficient?

If one ERP can capture the request, compare revisions, assess materials and capacity, approve, document customer agreement, update MES, and preserve evidence, an additional standalone product may be unnecessary. A workflow or integration can fill narrower gaps. Recreate a real case in the current ERP and check whether you can later identify exactly which version the customer accepted and the factory produced. A feature-list entry saying “change history” does not answer that question.

When should a production instruction be revised?

Apply the effective date or lot boundary after the necessary internal and customer decisions, old/new material identification, and WIP disposition are clear. Stop the obsolete instruction and confirm receipt of its replacement even for an urgent case. Exchanging a paper document while MES retains the old version leaves two authorities. If work has begun, use an exception process that explicitly decides what happens to WIP.

Conclusion

An order change control system should preserve the customer’s request separately from the accepted order, compare prior and candidate revisions, assess materials, capacity, quality, and commercial effects, obtain approval, and release only the customer-confirmed revision to ERP, MES, and logistics. A reconstructable history and FAT/SAT cases that include mid-process change and integration failure keep the factory’s execution aligned with the commercial promise.

If you are defining the intake, approval, and ERP/MES application process for a Thai factory, contact TOMAS TECH. We can review a current order and actual change case with you while the scope is still being decided.

Sources

• Microsoft Learn: Order promising
• Microsoft Learn: Action messages
• Microsoft Learn: Production planning
• Microsoft Learn: Delivery schedules
• OPC Foundation: ISA-95
• ISO: ISO 9001:2026
• ISO: ISO 10013:2021
• GS1: EPCIS 2.0.1

The workflow, RFP, tests, and measurement recommendations are TOMAS TECH’s implementation guidance. Vendor documentation describes the cited products; it is not presented as a universal software specification.