Available stock in an online store: how to confirm ATP

Available stock in an online store is more than the quantity recorded in an inventory management system. Customers need to know how much you can actually accept in an order and when you will dispatch it. This requires reconciling physical inventory, reservations and warehouse constraints, then checking whether a particular order can be fulfilled.

Available-to-promise, or ATP, means the availability you can promise a customer, taking into account inventory, expected receipts and demand already accepted. It is not the name of a particular mandatory application. Below is a practical approach to integrating an existing store with its inventory management system: what to exchange, where to confirm reservations and how to avoid turning an approximate forecast into a firm delivery date.

Available stock: from warehouse records to a commitment

Inventory records answer the question ‘what is in the warehouse’, while commercial availability answers ‘what can be sold to this customer under these conditions’. A product may physically be on a shelf but be reserved, damaged or allocated to another channel. The total across all warehouses does not mean the entire batch can be dispatched from a single location either.

Distinguish three outcomes of integration. The first is the quantity that can be sold in a new sale now. The second is future availability on a specific date. The third is a confirmed commitment for a particular order. Displaying stock on a product page does not create a reservation, and calculating ATP does not in itself confirm a carrier booking.

The Microsoft Inventory Visibility documentation distinguishes soft reservations from forecasting future availability. A reservation reduces the quantity that can still be promised without changing physical inventory. This principle is useful in system design, but the specific fields and rules depend on your system.

Agree on what the data means before setting exchange frequency

Determine which system is responsible for each metric: ERP maintains resource records, WMS manages warehouse operations and the store accepts online orders. Each metric must have a defined source of truth. Otherwise, the website may subtract a reservation that the ERP has already accounted for, or return a product to sale before it has been inspected following a return.

Consistent units and statuses

The exchange key must unambiguously identify the SKU and product variant, warehouse and sales unit. If inventory records provide individual units while the website sells boxes, you need an agreed conversion and rounding rule. A bundle requires its components to be checked separately: the availability of a complete set cannot be equated with the stock of its most common component.

A formula without double subtraction

For an initial model, you can take the eligible physical inventory and subtract non-overlapping reservations, blocked quantities and a safety buffer. This is a framework for discussion, not a universal formula. If the source already sends free stock, subtracting its components again would be an error. Document separately whether blocks and reservations can apply to the same units.

Confirm reservations where sales decisions are made

Even an up-to-date product page does not rule out a simultaneous purchase through another channel. That is why stock reservations must be part of order acceptance: the system checks availability and records the reservation as one coordinated operation. The sequence ‘read the stock, wait a little, record the order’ leaves a window for conflict.

Assign a component responsible for reservations: the existing inventory management system or a separate service. All channels must take shared commitments into account. A reservation on the website alone will not protect against a parallel sale by a sales representative.

Adobe Commerce describes reservations as holding a quantity until shipment or cancellation, rather than immediately deducting physical inventory. This is an example of separating states, not a Drupal configuration guide. In your project, define separately when a reservation is made, how long it lasts and how it moves into warehouse fulfillment.

If your question is specifically about choosing an additional system, read about when a store needs an OMS. Here, the focus is on the correctness of availability and commitments within the existing system landscape.

Connect reservations, payments and cancellations in one process

Define the initiator and outcome of every transition. After making a reservation, the store proceeds with payment according to the agreed scenario. A failed payment must release the reservation. If payment is confirmed after the reservation has expired, availability must be checked again.

Repeated messages and an unknown response

An API, the interface for exchanging data between systems, may fail to respond in time even though the operation has already been completed. Before attempting another reservation, check the result using the request identifier. A repeated message with the same key must return the same result rather than create another reservation. This property is called idempotency; it must be implemented and tested, not assumed.

The Microsoft documentation on reservations describes their creation, adjustment and release separately. Draw up the same lifecycle map for your own integration. Test partial cancellations, quantity changes and split shipments, not just the successful purchase of a single product.

Cancellation before dispatch releases the corresponding commitment, but a return after delivery follows a different path. A refund alone does not prove that the product is fit for sale again. The returned unit must go through warehouse receipt and the necessary condition checks. The website, inventory management system and support team must all understand this rule in the same way.

Turn availability into an honest customer promise

The dispatch date depends on more than quantity. You need the fulfillment warehouse, order cutoff time, working calendar, picking capacity and rules for splitting shipments. Delivery is added separately, taking the available carrier service into account. Do not substitute the date a parcel is handed over for the date the customer receives it.

ATP for a future date must be based on agreed receipts and demand already accepted. Do not describe a planned purchase as guaranteed stock. If the supplier has not confirmed a date, it is more appropriate to display ‘timing to be confirmed’ than to automatically add an assumed lead time to today's date. Define a manual confirmation step by the responsible person for critical orders.

A hypothetical scenario: part of a batch is in the local warehouse and the rest is expected from another warehouse. Offer dispatch in parts or once the entire batch has been assembled. An ‘in stock’ label will not explain the difference in delivery times and costs.

Store the original promise shown to the customer in the order, along with the basis of its calculation: warehouse, availability version and confirmation time. Record a new forecast date separately. If you simply overwrite the old date, reporting will no longer show breaches of the original agreement. A change notification should explain the customer's available options, not merely state that there is a delay.

Test integration conflicts before launch

Limit the pilot to a group of SKUs and channels, but include complex scenarios. Record the expected outcome in the store, inventory management system and reservation service so that teams assess success in the same way.

1. Match product keys, units and eligible warehouses. Reject an unknown SKU instead of silently creating an incorrect stock record.
2. Place parallel orders for the last available quantity through different channels. Make sure the system does not confirm incompatible reservations.
3. Repeat a request after losing its response. Check that only one commitment exists and that it can be found using the original key.
4. Change the order of inventory messages. An older version must not make an already sold product available again.
5. Test late payment, partial cancellation and shipment. Each change must release or consume the correct quantity.
6. Disconnect the source. Check the agreed store behavior, notification of the responsible person and recovery after the failure.

After testing, reconcile stock, reservations and the fulfillment status of each order. A technical failure must not leave a customer who has paid without a clear status and a way to get help.

Risks and controls after activation

The most important limitation is the accuracy of physical warehouse records. Integration will not find a lost box or fix a receiving error. Regular reconciliation and someone responsible for correcting discrepancies are needed. For occasional manually handled sales from one warehouse, a simpler exchange with confirmation by a sales representative may be sufficient, provided customers are not promised an instant reservation.

Agree on data freshness monitoring: track the time of the event at the source separately from the time the website receives it. A successful connection does not prove that new changes have arrived. Once the acceptable delay is exceeded, the store must switch to a defined mode: limit the quantity, remove the firm date or accept an inquiry for confirmation. The decision depends on the cost of an error, not the developer's convenience.

Monitor exchange errors, stuck reservations and breaches of the original promise. Distinguish the causes: missing stock, picking delays or delivery delays. Set thresholds according to your own process, without borrowing someone else's ‘accuracy standards’.

Timelines, cost components and the scope of the first stage

Timelines are determined not by the number of fields alone, but by the availability of the necessary operations in the systems. The sequence is: agree on rules, check interfaces and data, implement reservations and exchange, test conflicts, run a controlled pilot and expand. Estimate the schedule after checking access to the test environment and the involvement of the inventory system vendor.

Break down integration costs into business analysis, master data cleanup, exchange adapters, availability calculation, checkout changes, monitoring and failure testing. Operating costs include infrastructure, possible third-party service fees, support and reconciliation. Estimate recovery after a failure separately: it must not be left as an undefined manual task.

Start with verified sales of current stock and a transparent failure mode. Add receipt forecasts when reliable data is available. The result is an explainable decision for every order, not another counter on the website.

If you need to connect these rules to your store, discuss web system development and integrations with GL.ua (Glyanets). Prepare a map of inventory sources, a list of sales channels and examples of conflicting orders: this will help define the pilot scope and work involved without prematurely replacing the entire inventory management landscape.