It is the last hour before the order cut-off at a beverage distributor in Cairo, and dozens of retail and wholesale buyers are submitting next-day orders at once. Each submission asks the ERP the same question: how many cases of this SKU can still be promised? The ERP is also posting the day's deliveries and running the finance team's reports, so it answers slowly. Carts hang at checkout. Some buyers retry and submit twice. Others give up and send the order by WhatsApp to a sales coordinator, who keys it in the next morning against stock that has moved overnight. Nothing here is broken. The stock check was simply built to depend on a system that was never meant to answer buyers.
A live query puts the ERP on the buyer's critical path.
ATP, available-to-promise, answers one question at the moment an order is submitted: can this quantity be promised from stock? The obvious way to answer it is to ask the ERP directly when the buyer presses submit. That sounds like the most accurate option, and in a quiet hour it often is.
The cost is structural. Every submission now depends on the ERP being reachable and responsive at that exact moment. In many Egyptian and Saudi distributors the ERP sits on a server at head office, reached over a network link the ordering channel does not control, and it is also doing the finance and warehouse work it was installed for. Ordering windows rarely fall in the ERP's quiet hours. When the query is slow, the buyer waits. When it times out, the design is left with two bad choices: refuse the order, or accept it without a stock check.
The usual workaround fails in the other direction.
Distributors who have lived with a slow ERP usually stop querying it and export stock instead: a file each night, or a scheduled job every few hours, loaded into whatever the buyers order from. Checkout becomes fast. The figure behind it is now hours old, and nothing on screen says so.
The failure shows up downstream. A buyer confirms 60 cases against a position that was sold through at ten in the morning. The order is accepted, and the shortfall is found at the pick face as an INF. It becomes a short delivery, an adjusted invoice and, often, a dispute with a buyer who was told the stock was there. In Egypt, where error cost is most of what manual ordering loses, this is the expensive half of the trade-off. The problem with the mirror is not that it is a copy. It is that nobody knows how old the copy is.
Every stock figure a buyer sees is a copy of something. The question that matters is whether anyone knows how old it is.
Continuous sync: a copy with a stated freshness.
The pattern that avoids both failures keeps a copy of the ERP's stock position in the ordering layer, but updates it on events rather than on a timer. Every inventory movement the ERP records, whether a goods receipt, a pick confirmation, a transfer or a stock adjustment, propagates to the ordering layer as it happens, with ERP sync latency under 60 seconds. ATP is then confirmed at submission against warehouse stock synchronized continuously from the ERP, fresh within 60 seconds. A routine submission does not wait on the ERP, and the figure it checks against is never older than a known bound.
That bound is a freshness guarantee, not an approximation, and the difference matters. A live query may be a few seconds fresher, but only when the ERP answers. A synced copy is bounded, and it answers whether or not the ERP does. Operations can plan around a stated interval. They cannot plan around a nightly file of unknown age or a query that may not return.
Credit follows the same pattern with a longer bound. Credit exposure is validated at submission against balances synchronized continuously from the ERP, fresh within 5 minutes. The one place a direct ERP call earns its cost is an order that would take an account close to its credit limit. There, one additional live ERP check runs before the order is accepted, because a narrow margin on a limit is exactly where minutes matter.
At submission, the order is checked against the synced copy for stock and credit, alongside pricing and the delivery cut-off. Only orders approaching the credit limit trigger a single additional call to the ERP before acceptance.
When the ERP is unavailable, ordering continues.
A live-query design ties the order window to the ERP's own availability. A planned maintenance window, a failed link to head office or an overloaded server closes the window for every buyer at once, usually at the worst possible time.
With validation running against the synced copy, buyers keep ordering when the ERP is unavailable. The check still runs against the last synchronized position. Orders placed during an extended outage are flagged for operations review and validated before the warehouse releases them, so the warehouse releases nothing that has not been checked. When the ERP returns, it receives those orders as written records, not as a queue of WhatsApp messages to re-key.
Why the stock check belongs in the ordering infrastructure.
Back at the Cairo distributor, the cut-off hour looks different. Submissions validate against the synced copy, so carts do not hang and buyers have no reason to retry or fall back to WhatsApp. 100% of orders are validated before dispatch: pricing, ATP, credit and the delivery cut-off are all checked at submission. The ERP stays the system of record for stock. It is simply no longer asked to answer every buyer during peak load.
The commercial effect is in the errors that stop entering the chain. Fewer orders are accepted against stock that is not there, so there are fewer short deliveries, fewer adjusted invoices and fewer disputes. Where a quantity does change at the pick face, the buyer sees the adjustment with its reason before the invoice is raised. That is the architecture Emdaad is built on. The stock check is current to a stated bound, and the ordering window does not depend on the ERP being reachable.