Inventory Synchronisation: Where Should Available Stock Be Calculated?

Only one item remains. A website customer proceeds to payment while a physical-store employee sells the same unit. Both screens may have displayed a correct quantity a few seconds earlier, yet two orders now rely on one physical product. Inventory synchronisation is not simply sending an identical number to several screens. Faster transmission cannot independently resolve an undefined decision about where availability changes and which event controls it.

This guide uses a hypothetical business with two sales channels and one warehouse. Quantities and events illustrate design decisions. A real implementation needs agreed reservation, payment and fulfilment rules. The objective is a useful set of questions and verification scenarios rather than a ready-made integration recipe for every system.

Name the quantity being synchronised

Physical stock, stock available to sell and stock reserved for orders are different quantities. Damaged items and goods awaiting inspection may remain on site without being available for a new purchase. Incoming items have not yet been received. Combining these states in one field can cause channels to use the same number with different meanings.

A data dictionary should explain each quantity. Availability might be calculated from on-hand stock minus reservations and unavailable units, but the actual formula follows the business model. Preorders or supplier fulfilment may require different rules. Do not assume an interface label proves every connected system uses the same definition. Trace a sample record to establish how the displayed number relates to the operation.

Assign authority for the relevant record

Which system makes the final decision about available quantity? A warehouse application, commerce platform or dedicated inventory service may perform that role. Several systems independently changing the same value can create conflicts. When drawing data flows, state what each arrow carries and what its destination does with the information.

Authority does not require every copy to live in one place. Channels may hold replicas; the essential questions concern the authorised change and conflict policy. One system can own catalogue data while another owns inventory. Define responsibility by field and event. Calling an ERP the main system does not independently explain where order reservations happen or which component can accept the last available unit.

Connect reservation timing with payment

Will the item be reserved when added to a basket, when payment begins or when an order is accepted? Each choice has consequences. Early reservations can hold stock in abandoned journeys, while late reservations can expose the same quantity to another channel. Evaluate the business model and actual technical flow instead of selecting one universal point.

Define how a reservation ends

Once created, the reservation needs release conditions. Failed payment, abandonment and expiry may be distinct events. A late payment confirmation can arrive after released stock has been allocated elsewhere. Decide how that situation is handled before it becomes a live exception. A diagram containing only successful transactions leaves the team improvising when the more difficult event occurs.

Test concurrent requests together

Placing two orders sequentially may not expose a concurrency problem. Prepare a scenario with two near-simultaneous requests for the final unit. The approved rule may allow one reservation while stopping the other with an appropriate message. How that outcome is guaranteed belongs in the technical design rather than the visual stock label.

Atomic operations or updates that check an expected current value may be relevant methods. Verify the supported mechanism in current implementation documentation. A final screen showing zero does not establish correct behaviour: inspect how many orders were accepted. One request may have silently overwritten another change. The test record should connect the requests, inventory effects and resulting orders so the observed outcome is explainable.

Distinguish an absolute value from an adjustment

“Set stock to seven” differs from “subtract one”. The first supplies a target quantity; the second describes a change. Identify which source sends which operation. An old file containing an absolute value can overwrite a newer order effect. Repeating an adjustment can reduce the same quantity twice.

A physical-count correction and an ordinary sale therefore need deliberate handling. Establish the point in time covered by the correction and its relationship with pending events. Version, expected-state or other consistency checks may help, depending on the infrastructure. Adding a field does not prove the problem is solved. Reproduce a conflicting update and inspect whether the approved rule survives the interaction.

Control the effect of repeated notifications

After a connection failure, an operation may be sent again. The earlier attempt might already have succeeded while its response was lost. Applying the same sale twice creates an inventory discrepancy. Stable operation identity and a record of processing are among the mechanisms that may be evaluated.

The intended behaviour is often called idempotency: repeating the same business request should not repeatedly produce the intended effect. Define which operation an identifier represents and when it can be reused. Accidentally treating two distinct sales as one is also wrong. Send the same event again during testing and inspect both quantity and history. In ecommerce integration development, repeated delivery deserves explicit acceptance criteria alongside the ordinary purchase.

Consider delayed and reordered events

An event created earlier can arrive later. Treating arrival order as business order can lead to an incorrect final state. A stale quantity update arriving after a receipt is one possible example. Define which events replace prior state and which represent independent changes that still need application.

A single timestamp does not automatically resolve every situation. Source versions, event relationships or another consistency approach may be needed. The technical team should explain the guarantees and limitations of its design. A visible last-updated time is useful, but does not prove the events were applied correctly. For a selected scenario, calculate the expected result and compare it with the actual record.

Choose the outage policy before an outage

If the authoritative stock source is unavailable, what should channels do? Continuing with the last known quantity, temporarily disabling particular products or holding requests are different business decisions. Each affects both customers and overselling risk. The implementation team should not make this policy silently on the retailer’s behalf.

Plan staff warnings and customer communication as well. Can the manager identify products whose updates failed? How are accumulated events handled when the connection returns? A normal-looking interface backed by stale data can be particularly misleading. Define failure records, retries and escalation where needed. Testing recovery provides stronger evidence than checking only the moment when the connection indicator is green.

Evaluate buffers and channel allocations explicitly

Some businesses with delayed updates may withhold a quantity or allocate units by channel. This is an operating policy, not a technical guarantee eliminating every concurrency problem. It may reduce one risk while also hiding stock that could otherwise be sold. Discuss the trade-off rather than adopting a fixed buffer without a reason.

Product type, demand and observed delay can inform the decision. Avoid assigning an arbitrary percentage to the entire catalogue as though it were universally correct. Low-quantity goods may require different handling from products with abundant stock. If channels receive allocations, redistribution of unused quantities also needs a rule. The number displayed is part of how the business chooses to sell, not merely an integration setting.

Include regular reconciliation

Even an event-based integration can accumulate discrepancies. A periodic comparison can identify differences between the authoritative source and channel copies. Define the quantity and reference point used. Comparing values from different moments while transactions continue can produce apparent discrepancies that are only timing differences.

Assess corrections before automatically overwriting records. An old count can erase a legitimate new sale effect. Some cases may require investigation. Reports should show the variant, location and relevant known events rather than only a discrepancy total. That helps staff distinguish an operational mistake from a delayed transfer. Reconciliation complements an appropriately designed event flow; it does not replace one.

Make adjustment history understandable

Without a reason for quantity changes, staff may need a database investigation every time a question arises. Suitable history can identify the variant, location, reason and source of a change. Access and retention arrangements need their own assessment. Collecting unnecessary sensitive information is not the objective.

Connecting an order reference with its inventory movements can support investigation. Manual corrections should also have a responsible person and explanation. Continually typing new quantities may conceal an underlying fault. During ecommerce inventory workflow design, discuss how operational staff will obtain an understandable answer. Technical logs existing somewhere are different from usable evidence available to the team handling the incident.

Finish with an event-based test matrix

Select scenarios such as the final unit sold through two channels, failed payment, cancellation, duplicate notification, disconnection and a delayed update. Record starting quantity, incoming events and expected final state. Relevant operational owners should review the outcome. Written conditions allow the same test to be repeated after a correction.

Do not inspect the displayed quantity alone. Review accepted orders, reservations and adjustment history together. The result should identify which uncertainty was resolved, which limitation remains and who acts during an exception. Inventory synchronisation succeeds when sales promises stay consistent with physical goods and agreed business rules, rather than simply making several screens look identical.

Frequently asked questions

Will sending inventory updates more frequently solve every problem?

It can reduce delay, but does not independently resolve concurrency or incompatible quantity definitions. Authority, reservations and conflict behaviour still need decisions. Transmitting an incorrect state faster does not create a reliable inventory process.

Must availability be calculated inside an ERP?

The appropriate system depends on which component can reliably enforce the relevant rules. A warehouse application, commerce core or separate service may be considered. Define responsibility for fields and events rather than drawing a conclusion from the system’s category name alone.

What should happen when one notification arrives twice?

The same business event should not produce an unnecessary repeated effect. The design may use stable identifiers and processing checks. Test that distinct events are not incorrectly merged as well. Duplicate protection needs to preserve genuine transactions while recognising repetitions of an existing request.

Should adding to the basket reserve stock?

There is no single rule for every operation. Early reservation can hold units in inactive baskets, while later reservation creates different concurrency exposure. Consider payment, the business model and release conditions together before deciding where the reservation belongs.

Can selling continue using old quantities during an outage?

That requires an explicit policy. Risk varies with product and delay. Define customer information, staff warnings and recovery before relying on a default. A normal-looking storefront should not obscure the fact that its inventory information is no longer current.

Is testing finished when quantities match?

No. Accepted orders, reservations and history must also be consistent. An incorrect number of orders can coexist with a final zero balance. Compare starting state and events with the expected result, not only the last number displayed on screen.