Резервирование товаров между сайтом и 1С: схема, настройки и проверка

Резервирование товаров между сайтом и 1С — это механизм, при котором часть физического остатка временно исключается из доступного к продаже количества. Короткий ответ: сайт показывает доступное количество как разницу между физическим остатком и активными резервами, чтобы исключить продажу одной единицы дважды. Ниже — как выстроить такую схему, кто отвечает за остаток, как освобождать резерв при неоплате и как проверить результат на тестовых данных.

Что решает резервирование товаров между сайтом и 1С

Резервирование товаров между сайтом и 1С закрывает одну практическую задачу: не продать одну и ту же единицу дважды. В 1С живёт физический остаток на складе, а на сайте показывается не весь остаток, а та его часть, которую разрешено продавать прямо сейчас. Когда покупатель оформляет заказ, нужное количество временно вычитается из доступного — это и есть резерв. Пока резерв держится, следующий покупатель видит меньше товара или не видит его вовсе.

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

Важно разделять два показателя: физический остаток (реальное наличие на складе) и доступное количество (физический остаток минус активные резервы). Резервирование работает именно со вторым числом. Складской учёт и количественный учёт — это разные режимы, и от выбранного режима зависит, какие документы и движения вообще существуют. Поэтому прежде чем настраивать резерв, нужно определиться, какой учёт ведётся.

Где проходит граница ответственности за остаток

Кто владелец числа «доступно к продаже»

Главное решение проекта — назначить владельца числа. Логика такая: 1С отвечает за физический остаток и за движения по складу, а сайт отвечает за показ доступного количества и за приём заказов. Резерв — это пограничная зона, и здесь важно, кто именно его создаёт и снимает.

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

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

Что делать с последней единицей

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

Здесь нет универсально правильного ответа — есть выбор политики. Можно держать небольшой буфер: не показывать к продаже последнюю единицу, если она нужна для гарантийного обмена или витрины. Можно разрешать продажу до нуля, но тогда нужно заранее решить, как обрабатывается конфликт. Главное — чтобы это решение было принято осознанно и одинаково понималось и магазином, и складом.

Как устроена схема резервов

Схема резервов — это последовательность состояний товара. Её следует зафиксировать до настройки, чтобы избежать разночтений при реализации.

Базовые состояния выглядят так:

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

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

Отдельно стоит продумать, что происходит при частичном заказе. Если из трёх позиций оплачена одна, резерв по двум другим должен либо сохраняться, либо освобождаться — но по заранее заданному правилу, а не по настроению менеджера.

Настройки, от которых зависит поведение резерва

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

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

Вторая группа — правила обмена с 1С. Здесь определяется, как часто приходят остатки, что делать при конфликте версий и как передаются заказы. Порядок обмена товарами и заказами описан в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами.

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

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

Освобождение резерва при неоплате

Неоплаченный заказ — главный источник «зависших» резервов. Покупатель оформил заказ, товар ушёл в резерв, оплата не пришла, а товар всё это время недоступен другим. Если ничего не делать, склад постепенно «замерзает».

Решение — задать срок жизни резерва и правило его освобождения. Например: при отсутствии оплаты в течение N часов резерв снимается автоматически, а заказ переходит в статус «Ожидает решения». Конкретный срок — управленческое решение магазина, а не техническая константа.

Важно связать это с оплатой. Если магазин принимает онлайн-платежи, момент подтверждения оплаты должен надёжно фиксироваться, иначе резерв снимется у уже оплаченного заказа. Как устроена эта связка, разбирается в материале Интеграция магазина с платёжными системами: онлайн-оплата и касса.

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

Таблица: какую политику резерва выбрать

Таблица помогает принять решение до настройки. Сравнивайте варианты по ситуации магазина, а не по принципу «так современнее».

Выбор политики — это компромисс между риском двойной продажи и риском заморозки. Чем строже резерв, тем меньше конфликтов с покупателями и тем больше товара стоит вне продажи. Чем мягче резерв, тем быстрее оборот и тем выше шанс отмены заказа.

Учебный пример: заказ из двух позиций

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Интернет-магазин продаёт инструменты. В каталоге две позиции: «Дрель» и «Набор свёрл». Физический остаток в 1С: дрель — 5 штук, набор — 12 штук. На сайте включён показ доступного количества, резерв создаётся при оформлении заказа, срок жизни резерва — до конца дня оформления. Склад один.

Шаг 1. Покупатель добавляет в корзину одну дрель и два набора и оформляет заказ. Система создаёт резерв: дрель — 1, набор — 2. Доступное к продаже становится: дрель — 4, набор — 10. Физический остаток в 1С пока не меняется.

Шаг 2. Второй покупатель в это же время открывает карточку дрели. Он видит 4 штуки, а не 5. Если бы резерва не было, он тоже увидел бы 5 и мог заказать пятую единицу, которая уже обещана первому покупателю.

Шаг 3. Первый покупатель оплачивает заказ. Резерв переходит в состояние, связанное с оплатой, и держится до отгрузки. Менеджер видит, что заказ оплачен и готов к сборке.

Шаг 4. Заказ отгружен. Количество списывается со склада: дрель — 4, набор — 10. Резерв снимается, потому что товар уже ушёл. Доступное к продаже совпадает с физическим остатком.

Шаг 5. Проверка. Если бы первый покупатель не оплатил до конца дня, резерв должен был освободиться: дрель снова стала бы 5, набор — 12. Если этого не произошло, значит, правило освобождения не сработало или срок задан неверно.

Наблюдаемый результат: в течение всего цикла доступное количество на сайте было меньше физического остатка ровно на величину активных резервов. После отгрузки оба числа совпали. Это и есть признак работающей схемы.

Как проверить результат и принять работу

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

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

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

Типичные ошибки и ограничения

Первая ошибка — два источника истины. Сайт и 1С независимо уменьшают остаток, и числа расходятся. Лечится назначением одного владельца числа.

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

Третья ошибка — резерв, не связанный со статусами. Когда статус меняется вручную и непонятно, что он значит для резерва, схема становится непредсказуемой.

Четвёртая ошибка — отсутствие ручного управления. Менеджер должен уметь снять резерв без обращения к разработчику.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны конкретные вводные. Без них любая оценка будет гаданием.

• Сколько складов участвует и нужно ли привязывать резерв к конкретному складу.
• Какой режим учёта используется сейчас и планируется ли складской учёт.
• Как часто обновляются остатки и заказы при обмене.
• Какие статусы заказа существуют и какие из них влияют на резерв.
• Есть ли онлайн-оплата и как фиксируется момент подтверждения платежа.
• Нужен ли буфер на витрину и для каких групп товаров.
• Кто со стороны магазина отвечает за разбор зависших резервов.
• Есть ли товары под предзаказ и как для них должно работать резервирование.

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

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