Order Promising and Available-to-Promise (ATP) Logic

Order promising and Available-to-Promise (ATP) logic answer the question every customer asks before clicking "buy": can I actually get this, and when? Getting this calculation right, in real time, is one of the most technically demanding responsibilities of a modern OMS.

Available-to-Promise is not simply "quantity in stock." It is a forward-looking calculation that nets out current on-hand inventory, existing commitments (orders already allocated against it), and expected future supply (incoming purchase orders, production completions) to determine what can be safely promised to a new order without creating a conflict. A naive system that only checks current stock will happily oversell against inventory that is already spoken for by other pending orders.

Simple ATP gives a single number valid "now." Time-phased ATP goes further, showing availability across future dates — 10 units available today, 40 more available next Tuesday when a purchase order lands. This is essential for businesses with lumpy supply (seasonal production, container shipments) where a flat "in stock / out of stock" binary would either under-promise (rejecting an order that could be filled next week) or over-promise (ignoring the timing mismatch entirely).

For made-to-order or assembled products, availability depends not just on raw component stock but on production or assembly capacity — this extension is often called Capable-to-Promise. It asks: given current component inventory and available production capacity, when could this specific configuration realistically be finished and shipped? This calculation is considerably more complex, since it must model constrained resources (a specific machine, a specific skilled labor pool) in addition to material availability.

Because ATP must respond within checkout-speed timeframes, most OMS platforms precompute and cache an ATP figure per SKU per location, refreshing it on every relevant inventory event (a sale, a receipt, a cancellation) rather than recalculating a live query against every underlying transaction table on every page view. The trade-off is a small window of staleness, mitigated by fast recalculation triggers and safety buffers for high-velocity items.

An ATP that is too optimistic causes overselling, cancellations, and damaged trust. An ATP that is too conservative silently loses sales the business could have fulfilled. Because the calculation sits directly between demand and inventory truth, even small errors compound quickly across a high-volume catalog, making ATP tuning an ongoing operational discipline rather than a "set once" configuration.