Manufacturing Delivery Promise System: ATP, CTP and Approval Design

A manufacturing delivery promise system should do more than show a salesperson an “earliest date.” It should compare the customer’s requested date with uncommitted finished goods, incoming materials, finite production capacity, warehouse handling and transport, using data from the same point in time. It must also preserve who promised which quantity for which date. This guide explains how a Thai factory can design customer-facing available-to-promise (ATP), capable-to-promise (CTP), approval, response versions, integration, an RFP and acceptance tests.

All quantities, dates and time savings in the worked examples are assumptions for design discussion. They are not TOMAS TECH project results or guarantees about any software product. Check current product features, transport arrangements and customer contracts before implementation.

Why delivery promises become inconsistent

A customer asks for 800 units next Friday. Sales reads an inventory report, planning uses another spreadsheet for machine load, and purchasing has a supplier’s latest promise in email. If those records were refreshed at different times, one team may say “yes” while another says “no.” A stock balance is also not automatically available for a new order: some stock may already be reserved, on quality hold or unsuitable for that customer’s specification.

Investigating a delay on the shipping day will not reveal why the original date was promised unless the data and decision at the time were retained. The central design issue is to distinguish an internal calculated option from a commitment communicated to a customer. A date may have been feasible when displayed, yet no longer be feasible after another order receives the inventory. Displaying a candidate must not silently reserve the supply.

Microsoft’s order-promising documentation distinguishes a simple sales lead time, which ignores inventory and planned supply, from ATP, which considers uncommitted inventory and planned receipts and issues, and CTP, which also considers capacity. Oracle Global Order Promising describes possible supply through stock, transfers, purchases and manufacturing. These are examples of vendor implementations. The approval and audit workflow below is a business requirement to define, not a claim that every product provides the same standard workflow.

What do ATP and CTP actually answer?

ATP asks how much can still be committed by a particular date. The rules must define whether planned receipts count, how existing commitments are deducted, whether a quality-held lot is excluded, and what outbound handling margin applies. CTP asks when missing product could be made, purchased or transferred under relevant material and capacity constraints. Its result depends on routing, machine calendars, changeovers, yield, subcontract operations and the credibility of incoming materials.

CTP does not automatically make a promise correct. Microsoft notes that CTP scenario coverage differs by planning engine; Oracle’s outcome depends on configured sourcing and promising rules. Select a product by testing your own orders and inspecting which constraint actually entered the calculation. If material dates and capacity cannot be maintained, beginning with ATP and human approval may be a better first phase.

Separate factory shipment from customer arrival

Completion on 20 October is not the same as arrival after inspection, packing, warehouse dispatch, customs and transport. Store at least a feasible completion date, earliest ship date, estimated arrival date, customer requested date and committed date as separate fields. The Microsoft Business Central explanation illustrates how warehouse handling and shipping time turn availability into a planned delivery date. One API field named delivery_date is ambiguous unless its location and time zone are specified.

Domestic deliveries in Thailand still depend on warehouse cutoffs, weekends and the customer’s receiving window. Exports also need a defined handover point and contract terms. Whether the factory guarantees carrier performance after dispatch is a contractual matter. In this article, “arrival” means the agreed location and time window used in the business response.

Decide the source of truth and data freshness first

The promise screen combines data held by several functions. A possible ownership split is: sales order, requested date and customer priority in ERP; sellable inventory and quality holds in WMS; work-in-progress in MES; capacity and downtime in planning; purchase order and supplier updates in purchasing; dispatch cutoff and transit time in logistics. The actual systems vary, but independent edits of the same field in several places create conflicting answers.

Record the calculation time and versions of both input data and rules with each candidate. If stock was refreshed at 03:00, the supplier replied yesterday at 16:00 and machine load is current, display that freshness. If a critical input has aged beyond its agreed limit, change the result from “auto-committable” to “review required.” Set the allowed age from the product risk, integration frequency and plant operations; there is no universal number.

Even the same item number may have customer-specific inspection, packaging or label rules. Filter eligible lots and routes by order attributes. Substitution, split deliveries and another factory can be useful options, but only within the customer’s contract and quality approvals. Oracle describes such alternatives as configurable possibilities; that does not authorize automatic substitutions at your plant.

Forecasts are not firm orders

Treating every customer forecast as committed demand may reserve too much; ignoring it can delay material procurement. Define forecast versions, variance against firm orders and the frozen horizon before feeding it into order promising. Our customer forecast management guide covers those decisions. Here, the final unit of accountability is the customer-facing response to a firm order line.

Model the journey from requested date to commitment

A single “planned date” field loses the difference between a draft answer and what was sent. A useful state model is REQUESTED, CALCULATED, REVIEW, APPROVED, SENT, ACKNOWLEDGED and REVISED. These are suggested business states, not mandatory industry codes. A calculation is not a commitment. An expedited order, overtime, uncertain incoming material, priority change, split delivery or substitution should be routed to the authority defined for that exception.

Approval is still an internal decision until the customer-facing message is sent. Record its time and channel; distinguish successful EDI receipt from merely generating an email draft. If the line changes twice, retain v1, v2 and v3, with old and new dates, quantities, reasons, data versions, approvers and notification times. Do not erase the old promise. Whether the customer must accept a revision is governed by the contract and business procedure, not by which version appears on a screen.

Handle simultaneous changes and competing reservations

Quantity changes and supplier delays may arrive at the same time. Recalculating every order every minute and emailing each result would create unstable promises. Instead, identify affected lines, refresh internal candidates and send already committed lines to a change-review queue. Send a customer revision once it has been approved. Use order ID, line ID and response version as idempotency keys so an API retry does not issue the same promise twice.

Two salespeople may view the same 100 available units and each try to promise 80. At commitment, recheck availability and perform an atomic reservation or other controlled allocation. Define how to recover if reservation succeeds but customer notification fails. SAP’s aATP documentation describes confirmation proposals based on stock, expected receipts and concurrent demand. Verify the transaction boundary of the chosen product in the RFP and actual test.

Worked example: answering an 800-unit request

This example is entirely hypothetical. A customer requests 800 units of item A for arrival on 30 October. There are 500 finished units, but 200 are promised to another customer and 50 are on quality hold. A simple available balance is 500 − 200 − 50 = 250 units. Another 300 units are due next week, but the supplier’s date is tentative. Whether to count them as firm supply is a policy decision, not a calculation trick.

Assume critical material for the remaining 550 units may arrive on 24 October and the bottleneck can process 200 units per day from 25 October. There is also half a day of setup, a day of inspection and two days of shipping and transport. Multiplying 200 units by three days and promising arrival on 28 October would omit setup and downstream work. Holidays, maintenance and existing load can extend the date. A CTP candidate needs the confidence of material receipt and actual capacity calendar.

Show business alternatives: 250 units early and 550 later; all 800 on a later date; or an approved substitute. For each, show factory ship date, customer arrival, incremental cost and required quality approval. If the contract prohibits split delivery, the first option cannot be confirmed merely because it appears on a screen. The approval matrix should define when sales, planning, quality, purchasing and logistics must participate.

The system can automate deductions, resource checks, candidate dates and evidence capture. People still decide contract exceptions and customer negotiation. The point of automation is to let approvers act on the same facts and trace the decision.

Connect ERP, MES, purchasing and logistics

A minimal architecture starts from the ERP sales order line. An order-promising service reads inventory, purchasing and planning data, returns candidates, and after approval updates the committed ERP field and customer communication. MES normally receives an approved plan or work-order change rather than an unapproved salesperson’s date. Your architecture may differ if ERP also owns planning, but the source of truth and change authority must be explicit.

Require order-line ID, item revision, plant, warehouse, unit of measure, time zone, response version and event timestamp in interfaces. For a Thai plant serving another country, “30 October arrival” must identify the customer’s local date and receiving window. Units such as pieces, cartons and pallets need defined conversion and rounding. Old events must not overwrite a newer promise if messages arrive out of order.

If overnight integration fails, the screen must not show a green “available” signal based on stale stock. Show the last refresh, hold automatic confirmation and route the case to manual checking. After recovery, recalculate affected lines and compare with already sent versions. Capture telephone promises made during the outage as manual response versions; otherwise the recovered system may resend an older candidate.

Respect the production freeze window

Inserting an urgent order into today’s machine slot may delay an earlier commitment. A production-plan freeze window sets approval rules for such changes. Order promising must know which apparent capacity is actually movable. CTP that ignores the freeze can look feasible to sales while being impossible to execute on the shop floor.

Material minimum order quantities and order multiples can also alter supply dates and costs; see our manufacturing MOQ guide. Approving extra material stock is a different decision from promising a customer date.

What belongs in the RFP?

“Supports ATP and CTP” is too vague. Ask how the solution deducts reservations and quality holds, what material and resource detail CTP uses, when splits or substitutions are allowed, where the delivery date is measured, how candidates and sent versions are retained, how approval and customer notification work, and what happens when input data is stale. Include your scenarios with each question.

Test with anonymized real orders: standard goods, make-to-order goods, quality hold, supplier delay, expedited insertion, no-split contract, frozen schedule and export cutoff. Require the vendor to mark each outcome as standard configuration, extra configuration, custom development or unsupported. Score the explanation of a candidate date as well as the date itself.

Compare total project cost, not just licenses: ERP/MES connections, master-data cleanup, history migration, Thai and English screens, approval workflow, customer EDI/email, monitoring, training and support. CTP especially needs reliable resource data. A powerful engine with no accurate capacity calendar will not rescue the project. Obtain comparable quotes using your order volume, plant count, connections and exception volume, rather than assuming an unsupported market price.

FAT and SAT: test failure paths

FAT checks logic and integration in the vendor environment; SAT checks plant data, terminals, network and actual roles. Seeing a date on a screen is not sufficient. If two users simultaneously try to commit 80 units from a balance of 100, one transaction should be rejected or recalculated so 160 is never promised. Held stock must stay excluded. A late supplier update must place affected committed lines in the review queue.

Send v1 to a customer, change the order quantity, and verify that v2 is not automatically sent before approval. Simulate send failure; the system should not confuse “approved” with “sent,” and a retry should not generate contradictory messages. Include Thai weekends and plant holidays, another customer time zone, and the instant after warehouse cutoff. Within a frozen plan, urgent orders must not displace earlier promises without the required approval.

Set performance targets from your own workflow. Rough quotation and firm order confirmation may tolerate different wait times. Measure calculation time, input-data lag, approval wait and notification delay separately. A single “response time” number hides the bottleneck.

Measure promises, not just shipments

Useful indicators include requested-date acceptance, time to answer, on-time performance against the original commitment, revision frequency and reason, unauthorized exceptions, freshness breaches, concurrent conflicts and customer re-queries. Define whether on-time performance is by shipment, order or order line. For split deliveries, retain both order and line views. Preserve original and revised promise dates separately; otherwise simply moving the promised date could make the metric look better.

For a hypothetical labor calculation, assume 100 lines daily required 12 minutes each before implementation. Afterwards 70 routine lines take four minutes each and 30 exceptions take 15 minutes each. Before: 100 × 12 = 1,200 minutes; after: 70 × 4 + 30 × 15 = 730 minutes; difference: 470 minutes. This is an illustrative workload model, not a measured saving. Include master-data upkeep and incident handling, and measure before and after using the same method.

A practical rollout sequence

Start with one plant, product family and order desk. Clean the order-line and stock/reservation data. Store candidates separately from commitments, and create response versions through manual approval. This exposes why stock is unavailable and why candidate dates change before introducing complex CTP.

Next, bring in expected materials and finite operations. Compare CTP suggestions alongside the planner’s decision rather than automatically committing them. Classify differences as stock, supplier date, resource load, transit or contract rules. Fix unexplained differences before widening scope. Only then add customer EDI, splits, alternative plants and priority changes while preserving approval and revision rules.

The owner cannot be sales alone. Sales owns the customer promise; planning owns capacity, purchasing owns incoming dates, quality owns released lots, logistics owns arrival conversion, and IT owns integration and monitoring. Name an exception approver and deputy for nights and holidays.

Documents and controls needed at launch

Create a process map from order intake through commitment, revision and dispatch, showing entry conditions, approvers and communication channels. Classify items by response method: stock items by ATP, make-to-order items by CTP candidate and planner approval, engineering-change items by manual review. Document the owner and review trigger for exceptions.

A data dictionary must define “available inventory,” “firm receipt,” “arrival” and “reservation.” ERP and WMS may use identical names for different stock populations. Preserve links from master-data changes to affected committed orders. During an outage, define who detects it, when automatic confirmation stops, the customer-facing “checking” message, recovery reconciliation and duplicate-send prevention. A promise made by telephone during the outage still needs a manual version.

Review the rules monthly. Look separately at missed requested dates, overly conservative answers and commitments later revised. Raising every safety margin may improve on-time performance while losing sales. Compare requested-date acceptance with promise reliability. Supplier reliability should be checked by item and procurement route; a global “two-day delay” average is misleading for imported, local and long-lead materials. When a new machine is added, verify tooling, qualified operators, quality release and adjacent operations before accepting shorter CTP dates.

Do not turn a calculated date directly into a customer message

Even when the system calculates the right date, an ambiguous message can change the meaning of the commitment. “We may ship near the end of October” is different from “We will deliver to your warehouse by 30 October.” A response template should include order and line ID, item and revision, quantity, whether delivery is split, expected factory ship date, estimated arrival at the agreed handover point, how long the response is valid, and any conditions. An internal candidate should be visibly labeled as such so that the customer cannot mistake it for a firm commitment.

If a salesperson can manually move a date earlier than the calculated option, retain the original result and require a reason and approver. An unrestricted free-text date field would turn the new system into another spreadsheet. Conversely, if the customer can negotiate a different delivery place or quantity and the screen cannot express that, staff will fall back to email or telephone outside the system. Define which fields can be adjusted, which changes trigger recalculation, and which require fresh approval.

A customer may ask for both a fast and a low-cost option. If premium transport could bring arrival forward by two days, show the extra cost, whether the carrier is actually booked, and whether quality inspection remains intact. Multiple options may be presented, but mark the selected commitment clearly, or split it into distinct delivery lines. If a customer later refers to an old quotation, the team must be able to identify which option in which version was approved and sent.

Align fields across languages

In a Thai plant, production confirmation may be in Thai, a Japanese customer response in Japanese, and other responses in English or Vietnamese. Instead of translating arbitrary prose every time, structure quantity, unit, location, date, time window, condition and approval state. Generate each language from the same values. Translate controlled phrases and reason codes while retaining common numeric and date source data. This reduces the risk of notifying different quantities in different languages.

Some terms still need human review. “Planned dispatch,” “committed delivery,” “estimated arrival” and “customer receipt” represent different states. Sales, logistics and contract owners should validate wording in each language and agree which term constitutes a contractual promise. Avoid date formats where month and day can be swapped. If a time is shown, state whether it is the plant’s or customer’s local time.

How should confidence in a delivery answer be displayed?

Some answers cannot be reduced to “certain” or “impossible.” Material may be ordered without supplier confirmation; a machine may appear free while maintenance downtime is unsettled; a transport service may have a regular schedule but no booking. Before converting such uncertainty into a single probability for the customer, show internally which conditions remain unconfirmed. If a key supply condition is open, it can be more useful to hold automatic commitment and list the checks a person must complete.

Reason codes might include “awaiting material confirmation,” “awaiting quality release,” “capacity approval pending” and “transport booking pending.” Assign an owner, next checking time and policy for whether a provisional customer response is permitted to each code. If the hold continues, tell the customer when a firm response will be given and retain that response deadline. Putting an unconfirmed date in the commitment field risks a silent date shift after planning changes.

If confidence is color-coded, also display the reason and next action in words. A green indicator based on stale supply data has a weak foundation. A red indicator may still leave an option if the customer accepts a split delivery or approved capacity at another plant. The color should help the employee find the responsible person and affected scope, not replace judgment.

Trace the impact of a single delay

When a material is delayed three days, a mass email from purchasing to sales does not identify which customers need a response. Trace the material lot to linked work orders and sales order lines. Separate lines already promised, lines still at candidate stage, and lines that can use an approved substitute. For promised lines, show the difference between the old version and new candidate and assign a change review to the responsible salesperson. Prioritize customer communication by the contract and size of the impact.

Do not over-automate this impact analysis. A delayed material may not change a customer promise if finished stock or another source is sufficient. Conversely, one small critical component may affect several orders. The system should first find potentially related orders, narrow them through recalculation, and let a person approve the final customer explanation. This prevents both unnecessary delay notices and missed notices to customers who truly are affected.

Frequently asked questions

How is a delivery promise system different from a production scheduler?

A scheduler plans operation sequence and resource loading. Order promising translates that plan, inventory, materials and transit into a customer-facing candidate, then manages approval and communication history. A software product may combine both, but internal plan and external commitment remain separate business states.

Can ATP alone commit a make-to-order delivery date?

ATP focused on finished goods and receipts may miss the capacity required to make more. Combine CTP or planner review when materials and resources matter. CTP itself depends on accurate master data and on which constraints the chosen product actually supports; verify these in acceptance testing.

Does automation remove sales approval?

Rules may allow auto-approval for standard products with reservable stock and clear transit terms. Urgent orders, splits, substitutes, contract deviations and changes that affect earlier commitments need the designated authority. The contract and risk class determine the boundary.

Can we overwrite a promise when a delay is discovered?

Keep the old sent version. Record the new candidate, reason, approval and customer notification as another version. The contract and procedure determine whether customer acceptance is required and when a revision takes effect.

Conclusion

A manufacturing delivery promise system needs more than an ATP or CTP engine. It needs fresh material, capacity and logistics data; a clear boundary between candidate and customer commitment; and retained versions and approvals for changes. Test duplicate allocation, quality holds, supplier delays, frozen schedules and notification failure with one plant’s real scenarios before choosing a product.

TOMAS TECH can discuss the business design and ERP, MES, purchasing and logistics interfaces for a Thai plant. If you are still writing an RFP or testing just one product family, share your current order-response workflow through our contact page.

Primary references

• Microsoft Learn: Order promising
• Microsoft Learn: Calculate order promising dates
• Microsoft Learn: Delivery alternatives
• Oracle: Overview of Global Order Promising
• Oracle: Specify lead times for assembly operations
• SAP Help: Advanced Available-to-Promise
• SAP Help: Supply Creation-Based Confirmation