Как синхронизировать остатки по нескольким складам между 1С и интернет-магазином
Как согласовать склады, резервы и доступность товара при интеграции магазина с 1С, чтобы сайт не обещал покупателю то, чего нельзя отгрузить.
В этой статье
На сайте осталось пять единиц товара, но менеджер не может собрать заказ: три лежат в другом городе, одна зарезервирована, ещё одна повреждена. Формально обмен передал правильное число, а покупатель получил невыполнимое обещание. Так происходит, когда интеграция синхронизирует остаток как одно поле и не описывает смысл этого числа.
Для магазина с несколькими складами нужно отдельно определить физический остаток, доступное количество, резерв, ожидаемое поступление и правила выбора склада. Только после этого можно решать, какие данные показывать в карточке и что отправлять обратно в 1С.
Сначала договоритесь, что означает «в наличии»
Физический остаток отвечает на вопрос, сколько единиц числится на складе. Доступный остаток обычно меньше: из него исключают резервы, брак, карантин и другие количества, которыми нельзя обещать покупателю. Но даже доступное количество не всегда равно тому, что можно продать через сайт. Например, склад может обслуживать только оптовые заказы или другой регион.
Показатель | Для чего нужен | Что пойдёт не так при подмене |
|---|---|---|
Физический остаток | Инвентарный учёт | Сайт покажет зарезервированные и недоступные единицы |
Доступно к продаже | Обещание покупателю | Без правил канала число будет завышено |
Резерв | Защита уже принятых заказов | Два покупателя получат одну единицу |
Ожидаемое поступление | Предзаказ и срок | Будущая поставка станет выглядеть как товар на полке |
Страховой запас | Защита от расхождений | Последние единицы будут обещаны при неточном учёте |
Определение записывают как бизнес-правило. Например: интернет-магазин получает сумму доступных остатков только с двух складов своего региона, уменьшенную на страховой запас; резерв создаётся после подтверждения заказа и действует ограниченное время. Это уже проверяемое требование, в отличие от фразы «передавать остатки онлайн».
Сопоставьте склады, а не их названия
Название склада меняется, повторяется и может содержать сокращения. Надёжная интеграция связывает сущности по устойчивым идентификаторам. Для каждого склада 1С задают роль на сайте: продающий, только для самовывоза, распределительный, закрытый для интернет-заказов или информационный.
Внешний идентификатор склада не должен зависеть от видимого названия.
У сайта должно быть явное правило для неизвестного склада: остановить запись и сообщить об ошибке безопаснее, чем молча сложить количество в общий остаток.
Закрытие или объединение склада проводят как миграцию сопоставлений, а не простое удаление строки.
Регион, способ доставки и юридическое лицо могут ограничивать выбор склада независимо друг от друга.
Если на сайте нужен один общий остаток, исходные складские количества всё равно полезно хранить раздельно. Иначе невозможно объяснить покупателю срок доставки, выбрать точку самовывоза и разобрать расхождение.
Отделите обмен остатков от резервирования
Периодическая выгрузка отвечает на вопрос, каким был остаток в момент обмена. Резервирование — транзакционное действие: две параллельные покупки не должны получить одну и ту же единицу. Если обмен выполняется раз в десять минут, а резерв создаётся только при следующем цикле, окно перепродажи неизбежно.
Есть несколько рабочих моделей. 1С может оставаться единственным владельцем резерва и подтверждать его через отдельный запрос. Сайт может создавать локальный временный резерв, а затем синхронно или через очередь подтверждать его в 1С. В любом варианте нужны срок жизни, идентификатор операции, повторяемость без дублей и сценарий отказа.
Событие | Ожидаемое действие | Контроль |
|---|---|---|
Создан заказ | Попытка зарезервировать состав | Один внешний ID заказа |
Оплата подтверждена | Продлить или закрепить резерв | Сумма и состав не изменились молча |
Оплата не завершена | Снять временный резерв по правилу | Повтор не уводит остаток в минус |
Состав изменён | Пересчитать разницу | История прежнего резерва сохранена |
Заказ отменён | Освободить доступное количество | Операция идемпотентна |
Не превращайте «онлайн» в обещание нулевой задержки
Даже событийный обмен имеет задержку: сообщение проходит очередь, обработчик может повторить запрос, а 1С — быть недоступной на обслуживании. В интерфейсе и требованиях нужно зафиксировать допустимый возраст данных. Для дефицитных товаров полезнее показывать осторожный статус и подтверждать наличие при оформлении, чем выводить красивое точное число, которому нельзя доверять.
Интеграция должна измерять время последнего успешного обмена по каждому складу и количество необработанных событий. Отдельно нужны уведомления о зависшей очереди, неизвестных идентификаторах и отрицательных остатках. Сам факт запуска задания по расписанию не означает, что данные дошли до каталога.
Как принять обмен по складам
Создайте одинаковый товар на двух складах и проверьте правила региона, доставки и самовывоза.
Зарезервируйте последнюю доступную единицу двумя параллельными заказами: второй заказ не должен получить подтверждение без оговорённого сценария.
Повторите одно и то же событие резервирования. Количество и число резервов не должны измениться второй раз.
Остановите тестовый обработчик, накопите несколько изменений и восстановите обмен. Проверьте порядок и отсутствие потерь.
Переименуйте склад без смены внешнего идентификатора, затем добавьте неизвестный идентификатор. Первое изменение должно пройти, второе — стать заметной ошибкой.
Отмените неоплаченный заказ и убедитесь, что резерв снят один раз, а доступность пересчитана.
Сверьте карточку товара, корзину, оформление и кабинет менеджера: они не должны использовать разные определения остатка.
Результат можно считать надёжным, когда команда объясняет происхождение показанного остатка и воспроизводит спорные ситуации. Если число нельзя разложить по складам, резервам и правилам канала, увеличение частоты обмена лишь быстрее распространяет неопределённость.
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
Create the same product on two warehouses and check regional rules, delivery options, and pickup rules.
Reserve the last available unit with two parallel orders: the second order must not receive confirmation without the agreed scenario.
Repeat the same reservation event. The quantity and number of reservations must not change on the second attempt.
Stop the test handler, accumulate several changes, and restore the exchange. Verify the order and ensure no data is lost.
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.
Cancel an unpaid order and verify that the reservation is removed once and availability is recalculated.
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.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.