When a Thailand factory evaluates a delivery-date management system, a polished dashboard and a long feature list are not enough. The system must connect a customer’s requested date with inventory, incoming supply, production capacity, shop-floor progress, warehouse handling and transport time, then return a date the business can defend. After the promise is made, it must identify affected orders when material is late or a machine stops, show alternatives, and preserve who approved any change.
This is not another general list of delivery-delay prevention measures. It is a procurement and implementation guide for factories that need a vendor-neutral RFP, a 90-day proof of concept (PoC), and auditable acceptance tests. It covers ATP and CTP, four separate date concepts, master data, operational events, exception control, multilingual work in Thailand, ERP/MES/WMS integration, and an illustrative ROI/TCO model.
Search intent: what buyers actually need to decide
People searching for a delivery-date management system usually represent several interests. Sales wants a fast, credible customer response. Production control wants promises that respect materials and finite load. IT and management want a maintainable solution that works with existing systems and removes person-dependent spreadsheets. If all three are reduced to “progress visibility,” the RFP becomes vague and a strong-looking demo can conceal an unworkable operating model.
Evaluate reproducible outcomes, not feature labels.
| Decision area | RFP question | Evidence of acceptance |
|---|---|---|
| Promise feasibility | Can the system answer a requested date using ATP or CTP? | Inputs, rule version, result and calculation timestamp |
| Constraints | Which material, capacity, tooling, labour, subcontract and transport limits are used? | Recalculation after changing one constraint at a time |
| Change control | Who changed a customer promise, why and when? | Before/after values, reason, approver and notification log |
| Exceptions | Can users focus on risky orders instead of watching every order? | Trigger, owner, due time and escalation trail |
| Multilingual use | Do Thai, Japanese and English users share the same meaning? | Approved glossary, common reason codes and calendar tests |
| Integration | Is ownership across ERP, MES and WMS explicit? | API/event contract, retry, deduplication and reconciliation |
| Operations | Can stale data, failure and recovery be managed? | Monitoring, logs, backup, runbook and service levels |
| Economics | Can benefits and costs be recalculated from stated assumptions? | Baseline, formula, sensitivity cases and TCO breakdown |
ATP versus CTP: from available supply to feasible production
Available to Promise (ATP) estimates the quantity that can be committed on a date from unallocated inventory, known receipts and existing demand. Microsoft describes ATP using uncommitted inventory, lead times, planned receipts and issues. Oracle Global Order Promising can consider configured sources across the supply chain, including on-hand and in-transit stock, purchase and transfer orders, planned supply and manufacturing work orders.
Capable to Promise (CTP) addresses the next question: if current supply is not enough, when could the factory make, buy or transfer the balance? Microsoft distinguishes CTP by its use of material and capacity, whereas ATP focuses on material availability and assumes infinite capacity. Yet vendors differ in the constraints, planning engine, granularity and runtime behind the label “CTP.” A checkbox is not evidence.
| Situation | Is ATP normally sufficient? | Is CTP needed? | Rule to test |
|---|---|---|---|
| Unallocated finished goods exist | Usually | Usually not | Lot status, hold stock, customer allocation, warehouse |
| Confirmed receipts exist | Depends on configuration | Usually not | Receipt reliability, late supply, time fences |
| Components exist but finished goods do not | Sometimes not | Yes | BOM, routing, capacity, calendars and setup |
| Material and capacity are short | No, or only a later date | Yes | Substitute, subcontract, extra shift and purchase authority |
| One site cannot supply the full line | Depends on split rules | Sometimes | Source priority, split shipment, transport and customer consent |
A useful RFP asks which supply types are eligible, when a receipt becomes trustworthy, which resources are finite, and at what granularity the engine recalculates. Running a complete planning cycle for every customer inquiry may be too slow. Using only last night’s snapshot may miss today’s breakdown. A practical design separates fast ATP, conditional CTP, and periodic network replanning.
Keep requested, promised, planned and actual dates separate
Delivery control often fails because one field called “delivery date” is overwritten with several meanings. At minimum, preserve four dates independently.
| Date | Meaning | Business owner | Change rule |
|---|---|---|---|
| Requested | Arrival date requested by the customer | Customer / sales | Record each changed request as history |
| Promised | Arrival date formally committed by the company | Sales plus authorised approver | Do not change without reason and approval |
| Planned | Current expected date from supply and capacity plans | Production control / planning engine | Replanning may update it; do not overwrite the promise |
| Actual | Defined completion, shipment or customer-receipt event | MES, WMS, logistics or receipt feed | Correct through reversal/adjustment events, not silent edits |
Microsoft Business Central documents the backward calculation from a requested delivery date through shipping and outbound warehouse handling time, and the forward calculation from an available shipment date. That distinction matters: factory completion, goods issue and customer arrival are not the same milestone. A Thailand implementation may need separate factory, warehouse, carrier and customer calendars, plus cross-border or customs time where relevant.
Define the on-time KPI just as carefully. Is its denominator an order or an order line? Does a partial shipment pass? Is the target a date or a timestamp? If customer receipt is unavailable, may shipment confirmation serve as a proxy? Put the agreed answer in the data dictionary. Two dashboards with different denominators do not form a management system.
Master data is part of the promise engine
Accuracy depends as much on realistic master data as on the algorithm. Audit not only whether data exists, but who owns it, how often it changes, who approves changes, and what the engine does when it is missing.
| Master | Minimum content | Frequent Thailand-factory issue |
|---|---|---|
| Item and unit | Item ID, base unit, conversions, lot and shelf-life rules | Piece/pack/weight conversions, duplicate local and customer codes |
| BOM and substitute | Effective dates, quantity, yield and substitution conditions | Engineering change dates and customer approval for substitutes |
| Routing and capacity | Sequence, standard time, equipment/labour capacity, setup | Breaks, skilled labour, tooling, shared equipment and extra shifts |
| Calendar | Plant, warehouse, supplier, carrier and customer working days | Thai holidays, company holidays and Japan-head-office timing |
| Procurement | Supplier, lead time, minimum lot, incoming inspection | Customs, quality hold and forecast versus confirmed supply |
| Logistics | Outbound handling, route, transport time and cutoff | Collection cutoff, border movements and customer gate windows |
| Customer/order | Priority, split and substitute permission, service policy | Verbal expedite requests, special labels and delivery responsibility |
Never treat a missing transport time as zero. It should block or flag the answer and assign the issue to the master-data owner. Keep a governed standard lead time distinct from observed performance. Actual distributions are valuable for improvement, but automatically rewriting the standard because of an outlier makes the promise rule impossible to explain.
An event model for auditable progress visibility
Synchronising only the latest status prevents the team from explaining why yesterday’s order looked safe. Prefer append-only business events and derive the current state from them. GS1 EPCIS structures visibility events around dimensions such as what, when, where, why and how. A factory does not need to adopt the entire standard to use those questions as a sound event-design checklist.
| Example event | Key and time | Required context | Effect on delivery promise |
|---|---|---|---|
| ORDER_ACCEPTED | Order line, receipt time | Quantity, request, customer and priority | Trigger initial ATP/CTP |
| SUPPLY_CONFIRMED | Supply line, confirmation time | Item, quantity, expected receipt and confidence class | Increase or reduce eligible ATP supply |
| OPERATION_STARTED | Production order/operation, start time | Resource, operator and quantity | Refresh plan-versus-actual |
| PROGRESS_REPORTED | Production order/operation, report time | Good, scrap, remaining and state | Reforecast completion |
| DOWNTIME_OPENED | Asset, occurrence time | Reason, affected operation and recovery estimate | Reduce capacity and identify affected orders |
| SHIPMENT_CONFIRMED | Shipment, confirmation time | Quantity, lot, carrier and departure | Record actual and update arrival estimate |
| PROMISE_CHANGED | Order line, change time | Before/after, reason, requester and approver | Commit the customer-facing history |
Microsoft’s current production-floor execution documentation includes job state, requested, started, completed, scrapped and remaining quantities, and progress reporting. The important requirement is not a decorative screen; it is an input flow that operators can use accurately and promptly. Where devices may lose connectivity, issue event IDs locally and make retries idempotent so a reconnection does not double-count production.
Exception workflows: a red row is not a resolution
A screen filled with red orders sends users back to phone calls and spreadsheets. Model each exception as a work item with cause, impact, owner, next action, deadline and approval status.
- Detect late material, overload, stalled progress, quality hold or logistics risk.
- Determine affected order lines, promises, customer priority and feasible alternatives.
- Assign the exception to a role and establish a response deadline.
- Compare expedite, substitution, split, overtime, subcontract and date-change options.
- Route cost, quality and customer decisions to the correct authority.
- Commit the plan and send consistent notifications.
- Monitor until closure and feed the result and reason code into improvement analysis.
Approval is more than an electronic signature. The authority to change a promise, spend expedite cost, or use a substitute material may belong to different people. Ask whether approval matrices can vary by organisation, customer, item group and impact—not just whether “workflow” exists.
Multilingual operating design for Thailand factories
Translating menu labels does not make a system multilingual. The larger risk is that reason codes and dates acquire different meanings in Thai, Japanese and English. “Delivery date,” for example, must identify factory completion, shipment or customer arrival.
- Maintain a business-owner-approved glossary used by screens, reports, training and API fields.
- Give every reason one common code with translated labels; do not rely only on free text.
- Store timestamps in UTC and display an explicit user timezone such as ICT.
- Test date format, start of week, holidays, shift boundaries and order cutoffs.
- Allow Thai-script, Latin-script and Japanese aliases for names and searches.
- Keep operator actions short; combine wording and symbols rather than colour alone.
Language acceptance testing belongs to real order-entry, planning, production and warehouse users, not only translators. Linguistically correct wording can still be operationally wrong.
Define ownership across ERP, MES and WMS
ISA-95 provides a useful frame for the interface between business planning such as ERP and manufacturing operations such as MES. The goal is not to move everything into a new application. Give each datum one authoritative source.
| Information | Recommended system of record | Direction | Control point |
|---|---|---|---|
| Customer, order and commercial terms | ERP / order management | ERP → promise layer | Cancellation, amendment, line split and priority |
| Inventory, allocation and movements | ERP or WMS | Bidirectional or event-based | Hold, lot, warehouse and freshness |
| Production order and baseline plan | ERP / planning | Planning → MES | Version, frozen zone and instruction change |
| Progress, downtime and scrap | MES | MES → promise layer | Timestamp, quantity, reason and correction |
| Shipment actual | WMS / ERP | WMS → ERP and promise layer | Partial, reversal and carrier ID |
| Promised date and change history | Promise layer or ERP | Controlled bidirectional | Formal commitment, approval and conflict resolution |
Integration requirements must cover delay, out-of-order messages, duplicates, missing data, correction and replay. An API may return success while the receiving business transaction later fails. Require a reconciliation view with business key, event ID, sent time, processing state and error reason. For the broader transaction model, see the language-matched guide to an order and purchasing management system.
RFP requirements for a delivery-date management system
Turn each requirement into a testable statement with scenario, volume, performance point, exception, evidence and responsibility.
Business and calculation requirements
- Preserve requested, promised, planned and actual timestamps per order line and retain history.
- Configure ATP supply/demand elements, allocation, time fence, customer priority, split and substitution.
- State which BOM, routing, material, finite capacity, calendar, purchase and transport data CTP uses.
- Explain the result through consumed supply, limiting constraint, excluded supply and next feasible date.
- Trace backward from material delay, capacity shortage, stalled operation, quality hold or shipment delay to affected orders.
- Reject or route an unauthorised promise change and retain reason, impact, requester, approver and time.
Data and integration requirements
- Agree a field-level source of truth and update direction for ERP, MES and WMS.
- Define authentication, encryption, idempotency, retry, order, monitoring and retention for APIs/events.
- Detect missing master data or stale progress and never continue silently.
- Reproduce a historical promise with the master, input snapshot and rule version used at that time.
- Include record-count, quantity, value, sample and exception reconciliation in migration.
Non-functional and operational requirements
- Measure response at screen, API and batch levels using representative scenarios and peak load.
- Implement roles, least privilege, segregation of duties, access history and prompt deprovisioning.
- Let actual Thai, Japanese and English users validate terminology, search, report and notification.
- Put backup, recovery objective, incident communication, maintenance and change control into the contract.
- Name the owner of master quality, ageing exceptions, calculation failures and integration latency after go-live.
A 90-day PoC using production-like rules
The 90-day structure below is an editorial implementation framework, not an industry benchmark. Adjust it for product, site, seasonality and integration scope. Use imperfect company data and real exceptions, not only a clean vendor sample.
| Period | Objective | Main work | Gate evidence |
|---|---|---|---|
| Days 1–15 | Definitions and baseline | Scope, four dates, KPI, current flow and owners | Glossary, data register and baseline |
| Days 16–30 | Data viability | Load items, BOM, routing, capacity, calendars, orders and supply | Missing-data and reconciliation report |
| Days 31–50 | Promise logic | Configure ATP, CTP, priority, split, substitute and transport | Expected results and explanation logs |
| Days 51–65 | Exception and approval | Simulate late supply, downtime, quality, expedite and change | Workflow, notification and authority evidence |
| Days 66–80 | Integration and users | ERP/MES/WMS, retry, offline and three-language UAT | Reconciliation, runbook and training result |
| Days 81–90 | Parallel run and decision | Compare current answers with PoC answers and classify gaps | Acceptance result, open risk, TCO and decision |
Even if the PoC covers one product family, include normal demand, stockout, material delay, overload, downtime, quality hold, split, substitute, customer change and cancellation. Do not dismiss an inaccurate answer as user unfamiliarity. Classify the cause as master data, event latency, rule, calculation or business approval.
Acceptance tests that validate the promise
Every threshold below is an illustrative assumption. Replace it with the factory’s baseline, volume, critical-customer policy and infrastructure before contracting.
| Test | Input/action | Expected result | Illustrative acceptance assumption |
|---|---|---|---|
| Competing ATP demand | Several orders request the same inventory | Follow allocation without double promise | All known cases match expected allocation |
| Finite CTP | Reduce bottleneck capacity | Promise moves later and constraint is shown | Expected date and explanation match |
| Late receipt | Move a planned receipt later | Identify affected orders and alternatives | Exception within five minutes of event |
| Downtime | Send stop and estimated recovery from MES | Re-evaluate capacity and plan dates | No affected order omitted |
| Promise approval | Unauthorised user changes promised date | Reject or create approval request | All before/after values and actors logged |
| Duplicate event | Replay the same event ID | Do not double-count quantity | Zero inventory/progress difference after replay |
| Out-of-order event | Start event arrives after completion | Apply defined rule and flag anomaly | No state corruption and audit log exists |
| Three-language UAT | Process the same exception in each language | Same common code and outcome | Zero critical meaning differences |
| Peak performance | Simulate peak concurrent requests | Return results without timeout | 95th percentile within three seconds |
| Recovery | Restore a stopped interface and replay | Catch up without loss and reconcile | Zero business-key differences after recovery |
Promise accuracy cannot be fully assessed until actual outcomes occur. Use historical backtesting and parallel answers during the PoC, then continue comparing promised and actual dates after go-live. Broader manufacturing lead-time reduction supports delivery performance, but it is not the same KPI as the accuracy of today’s promise. Aggressive compression can produce less reliable commitments.
An illustrative ROI and TCO model
Do not calculate ROI from an unsourced claim that on-time delivery “should improve.” Identify avoidable work and loss, measure the current baseline, and assign only the portion the system can influence. All inputs and outputs below are illustrative assumptions, not TOMAS TECH results, market prices or guaranteed savings.
Illustrative assumptions
- Monthly order lines: 4,000
- Lines requiring date inquiry or re-answer: 20%
- Investigation and coordination per case: 15 minutes
- Fully loaded labour cost: THB 600 per hour
- Investigation time reduced by the system: 50%
- Current expedite transport, overtime and rush purchasing: THB 600,000 per month
- Portion avoidable through earlier exception detection: 10%
- Initial cost: THB 3,000,000
- Annual licence, support, cloud, operations and improvement: THB 1,800,000
| Item | Formula | Illustrative result |
|---|---|---|
| Monthly coordination time saved | 4,000 × 20% × 15 min × 50% | 100 hours |
| Monthly labour value | 100 hours × THB 600 | THB 60,000 |
| Monthly emergency cost avoided | THB 600,000 × 10% | THB 60,000 |
| Annual benefit | (THB 60,000 + THB 60,000) × 12 | THB 1,440,000 |
| First-year TCO | THB 3,000,000 + THB 1,800,000 | THB 4,800,000 |
| First-year net effect | THB 1,440,000 − THB 4,800,000 | −THB 3,360,000 |
This illustrative case does not pay back in year one. The response should not be to inflate benefit percentages. Model multiple years and separate retained sales, penalties, inventory, emergency cost and labour. If retained revenue is included, require order-level evidence that a risk was detected and an intervention plausibly prevented loss.
TCO also includes data remediation, interfaces, devices, training, translation, monitoring, upgrades, reports, vendor support, internal labour and future exit/data-export cost. Separate initial from recurring, mandatory from optional, and fixed from usage-based charges. Compare vendors using the same volume assumptions.
Common failure modes
Mistaking a dashboard for delivery management
Visibility is an output. Definitions, calculation, exception handling and approval come first. A red order without an assigned response adds workload.
Trusting every planned receipt in ATP
A late purchase order or quality-held stock can inflate apparent supply. Define confidence, time-fence and exclusion rules by supply type.
Treating CTP as a black box
A date alone is not actionable. Users need the BOM/routing version, capacity, calendar, limiting constraint and alternatives behind it.
Overwriting the customer promise during replanning
Internal expectations and external commitment are different. Replanning should raise an exception; only an authorised decision changes the promise.
Treating master cleansing as a one-off migration
New products, suppliers, equipment and holidays continue after go-live. Monitor missing, stale, duplicate and abnormal values with an owner and due date.
Ignoring operator burden
Late progress input creates late forecasts. Test scanning, defaults, short reasons and offline retry on real devices and at the real workplace.
Leaving multilingual meaning uncontrolled
Correct translations can still create different actions. Govern common codes and let real users run the same scenario in each language.
Selecting from vendor-demo data
Clean data hides the hard cases. Use anonymised duplicate items, stale lead times, out-of-order events, splits, cancellations and verbal expedites from your operation.
FAQ about delivery-date management systems
How is a delivery-date system different from an order management system?
Order management holds the transaction: customer, item, price, quantity, shipment and billing. Delivery-date management determines when the order can be promised from supply, capacity, progress and logistics, then controls risk and changes. They may be one product, but the RFP should test the responsibilities separately.
Is ERP alone sufficient for delivery-delay prevention?
It can be, if the ERP provides usable ATP, finite planning, timely progress, exceptions, approval and history. If progress is late, capacity is ignored, results cannot be explained or exceptions live in email, combine it with MES, planning or a promise-management layer.
Must shop-floor progress visibility be real time?
Not every event needs second-level latency. Match freshness to the speed at which a promise decision changes. A major breakdown or critical-operation completion benefits from fast capture; stable operations may be periodic. Specify permitted latency and show data age instead of asking vaguely for “real time.”
Is a production planning system the same as CTP?
No. Production planning balances broader demand and supply. CTP calculates a feasible date for specific demand using material and capacity. They may share an engine, so test scope, frozen plans, priorities and response time.
How should delivery-promise accuracy be measured?
Store the promise as it stood at the time of response and compare it with a defined actual milestone per order line. Analyse not only pass/fail but promise horizon, change count, days early/late, partials and reason. Freeze the denominator and actual-event definition.
Can a 90-day PoC prove the business benefit?
Not completely. Seasonal patterns and long procurement cycles need a longer observation. Use the PoC to establish data viability, reproducibility, exceptions, approval, integration and usability. Validate long-term effects against the baseline after go-live.
Which master data should a Thailand factory fix first?
Choose the PoC product family and prioritise item/unit, BOM, routing, capacity, calendars, purchase lead time, transport lead time and customer conditions. Do not wait for perfect enterprise-wide data; make missing data and ownership visible within scope and create ongoing controls.
Conclusion
A delivery-date management system is not a list of dates. It is a controlled method for turning a customer request into a defensible promise, observing plan-versus-actual events, routing risky orders as exceptions, and approving any promise change. Put ATP/CTP, the four dates, master data and ERP/MES/WMS ownership into testable RFP language. Then use company data in a 90-day PoC and acceptance tests to collect evidence rather than buying from a product name or a demo impression.
TOMAS TECH can help translate your Thailand factory’s promise rules into an RFP, PoC scenarios and integration boundaries around the systems you already operate. You can contact us while requirements are still being evaluated.
Primary sources
- Oracle: Overview of Global Order Promising
- Oracle: Try Different Availability Options
- Microsoft Learn: Order promising
- Microsoft Learn: Calculate order promising dates
- Microsoft Learn: Production floor execution
- ISA: ISA-95 Series of Standards
- GS1: EPCIS and CBV 2.0.1
- GS1: Global Traceability Standard
- Thailand BOI: 1H 2026 investment release
*Facts were checked as of 1 September 2026. Reconfirm product capabilities, contractual terms, regulation and service availability from official sources immediately before a purchasing decision.*
