Остаток в 1С и на сайте не совпадает: где должна жить окончательная цифра

В 1С у товара осталось три штуки, на сайте показано пять, а четвёртый заказ уже оформлен. Это может быть ошибка обмена, но не обязательно. Между учётной системой, сайтом и складом почти всегда есть задержка, а слово «остаток» в этих системах может означать разные величины.

Главный вопрос здесь не «почему цифры не равны каждую секунду». Нужно определить, какая система принимает решение в каждый момент: кто публикует доступное количество, кто резервирует товар, кто отменяет резерв и кто разбирает конфликт после повторной доставки данных.

Физический остаток отвечает на вопрос, сколько единиц числится или фактически лежит на складе. Доступный к обещанию остаток учитывает резервы, необработанные заказы, страховой запас и ограничения конкретного канала продаж. Показываемый остаток — то, что видит покупатель: точное число, диапазон, статус «в наличии» или ограничение количества в корзине.

Эти величины не обязаны совпадать. На складе может быть десять единиц, две уже зарезервированы под оплаченные заказы, одна оставлена как страховой запас. Тогда физический остаток равен десяти, доступный — семи, а сайт разумно показывает лишь «в наличии». Ошибка начинается не с различия, а с отсутствия согласованного правила пересчёта.

В «1С-Битрикс: Управление сайтом» количественный учёт и резервирование влияют на момент уменьшения доступного количества. Если количественный учёт выключен, товар остаётся доступным для покупки независимо от введённого числа. Данные по складам при отключённом складском учёте могут носить информационный характер и сами по себе не управлять списанием после заказа. Поэтому одинаковая цифра в административной форме ещё не доказывает одинаковое поведение корзины.

Фраза «источник истины — 1С» звучит аккуратно, пока покупатель не оформляет заказ между двумя сеансами обмена. Если сайт каждую минуту ждёт нового файла и не резервирует товар локально, он способен продать единицу, которую другой канал уже забрал. Если сайт безусловно считает себя главным, учётная система позже может перезаписать его значение и вернуть товар в продажу.

Полезнее назначить владельца каждому событию:

• приход, списание и инвентаризация на складе;
• публикация ассортимента и доступного количества на сайте;
• резерв при оформлении заказа;
• подтверждение оплаты;
• отмена заказа и освобождение резерва;
• возврат и решение о повторной продаже;
• ручная корректировка и её причина.

Для каждого события фиксируют направление передачи, постоянный идентификатор товара или торгового предложения, время изменения и правило повторной обработки. Тогда спор о главной системе превращается в проверяемую схему: один участник создаёт факт, другой подтверждает его получение и не применяет то же изменение второй раз.

Допустим, полная выгрузка остатков идёт каждые 15 минут. У популярного товара в пике бывает четыре попытки покупки в минуту. За интервал между выгрузками сайт может принять до 60 попыток. Это не означает 60 потерянных заказов: часть товаров есть в запасе, часть корзин не будет оплачена, локальное резервирование может сработать. Расчёт показывает верхнюю границу нагрузки на правило согласования.

Если доступных единиц меньше числа возможных покупок за окно, одного расписания недостаточно. Нужен хотя бы один из механизмов: локальный атомарный резерв, более частое обновление для изменённых объектов, страховой запас по каналу или синхронная проверка перед подтверждением. У каждого механизма есть цена: нагрузка, задержка ответа, сложность возврата резерва или уменьшение выставленного ассортимента.

Страховой запас не исправляет обмен. Он лишь снижает вероятность продажи последней единицы, пока задержка мала и спрос предсказуем. Для редкого товара с остатком один или для всплеска продаж буфер быстро перестаёт помогать.

CommerceML используется для передачи каталогов, коммерческих предложений и документов между учётной системой и интернет-магазином. Конкретный регламент обмена задаёт проект. В настройках интеграции 1С предусмотрена выгрузка только изменённых объектов: это ускоряет обычные циклы, но повышает требования к версионности и восстановлению после пропуска.

Частичная выгрузка хороша, пока цепочка изменений непрерывна. Если один пакет не дошёл, идентификатор товара изменился или обработчик завершился посередине, следующий маленький пакет может не восстановить целое состояние. Поэтому нужен периодический контрольный обмен или сверка, которая сравнивает не только факт успешного задания, но и ожидаемые количества по выборке.

Полная выгрузка тоже не должна бездумно побеждать локальные события. Если файл был сформирован в 10:00, заказ создан в 10:03, а импорт закончился в 10:05, слепое присваивание значения из снимка может вернуть зарезервированную единицу. Важны время состояния и правило применения, а не время окончания загрузки.

Остаток относится не просто к названию товара. Он привязан к постоянному идентификатору, иногда — к конкретному торговому предложению и складу. Размер и цвет часто живут на уровне SKU, а карточка лишь объединяет варианты. Если обмен прислал десять единиц синей модели 42-го размера, складывать их с остальными вариантами для доступности всей карточки опасно.

Склады тоже требуют явной модели. Сайт может показывать общий остаток, только склады с доступной доставкой в выбранный регион или один склад выдачи. Официальная документация интеграции отдельно различает общий остаток и ведение остатков по складам. Это настройка бизнес-правила, а не косметика отчёта.

При замене идентификатора нельзя молча создавать новый товар и оставлять старый с запасом. Нужна таблица соответствий и контролируемая миграция: какой объект продолжает историю, что происходит с резервами и когда старый вариант перестаёт продаваться.

Конфликт должен приводить к известному результату, а не к случайному последнему значению. Для магазина обычно важны четыре случая:

• учётная система уменьшила остаток, пока на сайте создавался заказ;
• заказ отменён на сайте, но освобождение резерва ещё не дошло;
• один пакет обмена повторно доставлен после ошибки связи;
• приёмка на складе увеличила запас, но сайт получил более старый пакет позже.

Правило «последняя запись побеждает» работает только при надёжном общем времени и одинаковом смысле записи. Чаще безопаснее сравнивать версию объекта или время самого бизнес-события, а повторную доставку делать идемпотентной: один и тот же документ не должен дважды прибавлять или вычитать товар.

Если автоматическое разрешение невозможно, товар временно снимают с продажи или ограничивают количество, а конфликт попадает в очередь с причиной. Молчаливое продолжение продаж удобнее для интерфейса, но переносит проблему в отменённые заказы и работу поддержки.

Перед запуском выберите тестовый товар и воспроизведите последовательности в изолированном контуре. Важен не красивый итог одного обмена, а переходы между состояниями.

• Оформите два заказа на последнюю единицу почти одновременно и проверьте, где возникает отказ.
• Отмените неоплаченный заказ до и после передачи в 1С; резерв должен освободиться ровно один раз.
• Повторно доставьте тот же пакет и убедитесь, что остаток не меняется второй раз.
• Пропустите один частичный пакет, затем выполните контрольную сверку.
• Измените остаток конкретного торгового предложения и проверьте соседние варианты карточки.
• Проверьте склад, который не обслуживает выбранный регион.
• Сопоставьте время события, формирования файла, начала и окончания импорта.

Для каждого сценария заранее записывают ожидаемый результат в 1С, на сайте, в резерве и в журнале обмена. Иначе одинаковые числа после теста легко принять за успех, хотя один из переходов просто не выполнялся.

Статус «обмен завершён» подтверждает работу процедуры, но не актуальность каждого товара. Полезны метрики возраста последнего принятого изменения, числа конфликтов, размера очереди, доли повторных пакетов и расхождений контрольной выборки. Отдельно отслеживают товары с нулём, последней единицей и быстрыми продажами — именно там задержка заметнее всего.

Если остатки в 1С и на сайте различаются, первым делом определите смысл каждой цифры и владельца события. Затем посчитайте окно рассинхронизации, проверьте идентификаторы, порядок пакетов и повторную обработку. Равенство двух полей в один момент приятно выглядит, но надёжность продажи показывает другое: магазин не обещает товар дважды и умеет объяснить каждое изменение количества.

1C shows three units remaining for the item, the site displays five, and the fourth order is already placed. This could be an exchange error, but not necessarily. Between the accounting system, the site, and the warehouse, there is almost always a delay, and the word "inventory" in these systems can denote different values.

The main question is not "why the figures are not equal every second." You need to determine which system makes the decision at each moment: who publishes the available quantity, who reserves the item, who cancels the reserve, and who resolves the conflict after data is re-sent.

Physical inventory answers the question of how many units are recorded or physically on the warehouse shelf. Available-for-promise inventory accounts for reserves, unprocessed orders, safety stock, and restrictions of a specific sales channel. Displayed inventory is what the buyer sees: an exact number, a range, a "in stock" status, or a quantity limit in the cart.

These values do not have to match. The warehouse may hold ten units, two already reserved for paid orders, and one kept as a safety buffer. In this case, the physical stock is ten, the available stock is seven, and the site reasonably displays only "In stock". The error does not stem from the difference itself, but from the lack of a unified rule for recalculation.

In "1C-Bitrix: Site Management", quantity accounting and reservation affect the moment when available quantity is reduced. If quantity accounting is disabled, the product remains available for purchase regardless of the entered number. Warehouse data with warehouse accounting disabled may be informational only and cannot independently manage deductions after an order. Therefore, the same number in the administrative form does not guarantee identical cart behavior.

The phrase "the source of truth is 1C" sounds neat until a customer places an order between two exchange sessions. If the site waits every minute for a new file and does not reserve stock locally, it can sell an item that another channel has already taken. If the site unconditionally considers itself the primary system, the accounting system may later overwrite its value and return the item to sale.

It is more useful to assign an owner to each event:

• receipt, write-off, and inventory at the warehouse;
• publishing the assortment and available quantity on the site;
• reservation during order placement;
• payment confirmation;
• order cancellation and release of the reservation;
• return and decision on resale;
• manual adjustment and its reason.

For each event, record the transfer direction, the permanent product or product variant identifier, the change timestamp, and the reprocessing rule. Then the dispute over the primary system becomes a verifiable scheme: one participant creates a fact, the other confirms receipt, and neither applies the same change twice.

Suppose full inventory export runs every 15 minutes. A popular item may see up to four purchase attempts per minute during peak times. Between exports, the site can receive up to 60 attempts. This does not mean 60 lost orders: some items remain in stock, some carts will not be paid, and local reservation may take effect. The calculation shows the upper bound of load on the reconciliation rule.

If available units are fewer than possible purchases within the window, a single schedule is insufficient. At least one of the following mechanisms is needed: local atomic reservation, more frequent updates for changed objects, a safety buffer per channel, or synchronous verification before confirmation. Each mechanism carries a cost: increased load, response latency, complexity of releasing the reservation, or reduced displayed assortment.

A safety buffer does not fix the exchange. It only lowers the probability of selling the last unit while latency is low and demand is predictable. For a rare item with a single unit in stock or during a sales spike, the buffer quickly stops helping.

CommerceML is used to transfer catalogs, product variants, and documents between an accounting system and an online store. The specific exchange protocol is defined by the project. Integration settings in 1C allow for the export of only changed objects: this speeds up routine cycles but increases requirements for versioning and recovery after skipped items.

Partial export works well as long as the chain of changes remains continuous. If a single package fails to arrive, a product identifier changes, or the processor terminates mid-way, the next small package may fail to restore the complete state. Therefore, periodic control exchanges or reconciliation are needed that compare not only the fact of successful task execution but also expected quantities in a sample.

Full export must not blindly override local events. If a file was generated at 10:00, an order was created at 10:03, and import finished at 10:05, blindly assigning a value from the snapshot may restore a reserved unit. The state timestamp and application rule matter, not the import completion time.

The remaining quantity is not just tied to a product name. It is linked to a persistent identifier, sometimes to a specific product variant and warehouse. Size and color often exist at the SKU level, while the product card merely aggregates variants. If the exchange sends ten units of the blue model in size 42, adding them to other variants to update the availability of the entire product card is dangerous.

Warehouses also require an explicit model. The site may display the total remaining quantity, only warehouses with delivery available to the selected region, or a single pickup point. The official integration documentation separately distinguishes between total remaining quantity and warehouse-level inventory management. This is a business rule configuration, not a cosmetic report adjustment.

When replacing an identifier, you must not silently create a new product and leave the old one with a reserve. A mapping table and controlled migration are required: which object continues the history, what happens to reserves, and when the old variant stops being sold.

A conflict must lead to a known result, not a random last value. For a store, four cases are typically important:

• the accounting system reduced the remaining quantity while an order was being created on the site;
• the order was cancelled on the site, but the reserve release has not yet arrived;
• a single exchange package was delivered again after a connection error;
• warehouse acceptance increased the stock, but the site received an older package later.

The 'last write wins' rule works only with reliable shared timestamps and identical record semantics. It is often safer to compare the object version or the timestamp of the business event itself, and to make repeated deliveries idempotent: the same document must not add or subtract inventory twice.

If automatic resolution is impossible, the item is temporarily removed from sale or its quantity is limited, and the conflict is placed in a queue with a reason. Silently continuing sales is more convenient for the interface, but it shifts the problem to cancelled orders and support operations.

Before launching, select a test item and reproduce the sequences in an isolated environment. The goal is not a pretty result from a single exchange, but the transitions between states.

• Place two orders for the last unit almost simultaneously and check where the failure occurs.
• Cancel the unpaid order before and after sending it to 1C; the reservation must be released exactly once.
• Redeliver the same package and verify that the remaining balance does not change a second time.
• Skip one partial package, then perform a control reconciliation.
• Change the balance for a specific product variant and check the neighboring variants on the card.
• Test a warehouse that does not serve the selected region.
• Compare the event time, file generation time, and the start and end of the import.

For each scenario, the expected result is pre-recorded in 1C, on the website, in the reserve, and in the exchange log. Otherwise, identical numbers after the test can easily be mistaken for success, even though one of the transitions simply did not execute.

The "exchange completed" status confirms the procedure worked, but not the currency of every product. Useful metrics include the age of the last accepted change, the number of conflicts, queue size, the share of repeated batches, and discrepancies in the control sample. Separately, track products with zero stock, single-unit stock, and fast-moving items — delays are most noticeable there.

If stock levels in 1C and on the site differ, first determine the meaning of each figure and the owner of the event. Then calculate the desynchronization window, verify identifiers, batch order, and reprocessing. Equality of two fields at a single moment looks pleasant, but sales reliability shows something else: the store must not promise the same item twice and must be able to explain every quantity change.