Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews0

How to Synchronize Stock Levels Across Multiple Warehouses Between 1C and an Online Store

How to align warehouses, reservations, and product availability during store integration with 1C to prevent the website from promising customers items that cannot be shipped.

АльбинаCommunity author★ 114
Comments 0

Shelves in multiple warehouses with boxes and accounting terminals, with no labels
In this article

The website shows five units in stock, but the manager cannot fulfill the order: three are in another city, one is reserved, and another is damaged. Formally, the exchange transmitted the correct number, yet the customer received an impossible promise. This happens when integration synchronizes stock as a single field without defining the meaning of that number.

For a store with multiple warehouses, you must separately define physical stock, available quantity, reservations, expected incoming stock, and warehouse selection rules. Only then can you decide what data to display in the product card and what to send back to 1C.

First, agree on what "in stock" means

Physical stock answers the question of how many units are recorded at the warehouse. Available stock is usually lower: it excludes reservations, defects, quarantine, and other quantities that cannot be promised to customers. However, even available stock does not always equal what can be sold via the website. For example, a warehouse may serve only wholesale orders or a different region.

Metric

Purpose

What can go wrong with substitution

Physical stock

Inventory accounting

The site will display reserved and unavailable units

Available for sale

Promise to the buyer

Without channel rules, the number will be inflated

Reservation

Protection of already accepted orders

Two buyers receive one unit

Expected arrival

Preorder and deadline

Future shipments will appear as shelf stock

Safety stock

Protection against discrepancies

The last units will be promised despite inaccurate accounting

Record it as a business rule. For example: an online store receives the sum of available stock only from two warehouses in its region, reduced by the safety stock; a reservation is created after order confirmation and is valid for a limited time. This is a verifiable requirement, unlike the phrase "transfer stock online".

Match warehouses, not their names

A warehouse name can change, be duplicated, or contain abbreviations. A reliable integration links entities by stable identifiers. For each 1C warehouse, assign a role on the site: selling, pickup-only, distribution, closed to online orders, or informational.

  • The warehouse's external identifier must not depend on its visible name.

  • The site must have an explicit rule for an unknown warehouse: stopping the record and reporting an error is safer than silently adding the quantity to the total stock.

  • Closing or merging a warehouse should be performed as a mapping migration, not as a simple row deletion.

  • The region, delivery method, and legal entity can independently restrict warehouse selection.

If the site needs a single total stock figure, it is still useful to keep the original warehouse quantities separate. Otherwise, it is impossible to explain the delivery time to a buyer, select a pickup point, or resolve discrepancies.

Separate stock synchronization from reservation

Periodic export answers the question of what the stock was at the moment of the exchange. Reservation is a transactional action: two simultaneous purchases must not receive the same unit. If the exchange runs every ten minutes, but a reservation is created only in the next cycle, a resale window is inevitable.

There are several working models. 1C can remain the sole owner of the reserve and confirm it via a separate request. The site can create a local temporary reserve and then confirm it in 1C either synchronously or through a queue. In any scenario, you need a time-to-live, an operation identifier, idempotent repetition without duplicates, and a failure scenario.

Event

Expected action

Control

Order created

Attempt to reserve the assortment

One external order ID

Payment confirmed

Extend or lock the reservation

Amount and assortment must not change silently

Payment not completed

Remove temporary reservation by rule

Retry does not drive stock into negative

Composition changed

Recalculate the difference

History of the previous reservation is preserved

Order cancelled

Release available quantity

Operation is idempotent

Do not turn 'online' into a promise of zero latency

Even event-based exchange has latency: a message passes through a queue, the handler may retry the request, and 1C may be unavailable for maintenance. The interface and requirements must define the acceptable age of data. For out-of-stock items, it is better to show a cautious status and confirm availability at checkout than to display a precise number that cannot be trusted.

Integration must measure the time of the last successful exchange per warehouse and the count of unprocessed events. Separate notifications are needed for stuck queues, unknown identifiers, and negative balances. The mere fact that a scheduled job has started does not mean the data has reached the catalog.

How to accept warehouse exchanges

  1. Create the same product on two warehouses and check regional rules, delivery options, and pickup rules.

  2. Reserve the last available unit with two parallel orders: the second order must not receive confirmation without the agreed scenario.

  3. Repeat the same reservation event. The quantity and number of reservations must not change on the second attempt.

  4. Stop the test handler, accumulate several changes, and restore the exchange. Verify the order and ensure no data is lost.

  5. Rename the warehouse without changing its external identifier, then add an unknown identifier. The first change should succeed, while the second must result in a clear error.

  6. Cancel an unpaid order and verify that the reservation is removed once and availability is recalculated.

  7. Compare the product card, shopping cart, checkout, and manager dashboard: they must not use different definitions of stock levels.

A result can be considered reliable only when the team explains the origin of the displayed balance and can reproduce disputed scenarios. If a number cannot be broken down by warehouse, reserve, and channel rules, increasing the exchange frequency only spreads uncertainty faster.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.