Вернуться к статьям Покупатель оформляет заказ на товар, который видит в наличии, а затем узнаёт, что позиции уже нет на складе. Бывает и наоборот: товар есть физически, но сайт показывает нулевой остаток и не позволяет добавить его в корзину. Такие ситуации возникают, когда интернет-магазин и система складского учёта по-разному обрабатывают остатки, резервы и изменения по заказам.
Интеграция интернет-магазина со складским учётом нужна не ради передачи данных между системами. Её задача — определить источник остатка, момент его изменения, правила продажи и действия при сбое обмена.
Почему остатки на сайте и складе расходятся
Расхождения появляются, когда две системы учитывают одну позицию по разным правилам. Например, товар уже зарезервирован под заказ, но сайт продолжает считать его доступным. Или возврат приняли на складе, а данные ещё не отразились в учётной системе, поэтому карточка товара остаётся недоступной.
Отдельная причина — разная идентификация товаров. На сайте может быть одна карточка с вариантами размера или цвета, а в складском учёте каждый вариант ведётся отдельной позицией. Сопоставление только по названию в таком случае приводит к обновлению не той позиции или пропуску части номенклатуры.
Проблемы возникают и после ручных правок. Сотрудник меняет остаток в административной части сайта, а следующий обмен возвращает значение из учётной системы. Если источник данных не определён, восстановить причину расхождения становится сложно.
Единый источник остатков для интернет-магазина
До настройки обмена нужно зафиксировать, какая система хранит фактический остаток. Обычно это система складского учёта: в ней отражаются поступления, перемещения, списания, инвентаризации и резервы. Сайт получает рассчитанные значения для витрины и оформления заказа.
Слово «остаток» само по себе не описывает правила продажи. В проекте стоит разделить:
- физический остаток;
- доступный к продаже остаток;
- товар в резерве;
- товар в пути или на приёмке;
- остаток по конкретному складу;
- товар под заказ.
Для покупателя имеет значение возможность купить и получить товар, а не количество единиц в помещении. Без такого разделения сайт может показывать наличие позиции, которую нельзя отгрузить.
Какие данные передаются между сайтом и складским учётом
Обмен остатками — лишь одна часть интеграции. После оформления заказа сайт передаёт в учётную систему состав заказа, сведения о покупателе в согласованном объёме, способ получения, комментарий и другие данные, необходимые для обработки. В обратную сторону могут поступать изменения статуса, отмены, сведения об отгрузке или скорректированные суммы, если это предусмотрено процессом.
Для каждого поля требуется определить четыре условия: где оно создаётся, кто может его менять, в каком направлении передаётся изменение и как разрешается конфликт. Иначе один заказ может получить разные статусы в двух системах.
Отмена заказа не всегда должна сразу снимать резерв, а частичная отгрузка не всегда означает уменьшение доступного остатка. Правило зависит от процесса: кто подтверждает отмену, когда товар возвращается в продажу, как обрабатываются недопоставки и замены. Эти сценарии фиксируют до настройки обмена.
Резервирование товара при оформлении заказа
Наиболее чувствительный участок — время между добавлением товара в корзину и подтверждением заказа. Если два покупателя оформляют последнюю единицу одновременно, один заказ может быть создан без фактически доступного товара. Для такого сценария определяют момент создания резерва.
Резерв может появляться после отправки заказа, проверки менеджером, подтверждения оплаты или на другом этапе. Раннее резервирование ограничивает продажу дефицитного товара, но способно блокировать позиции в незавершённых заказах. Позднее оставляет больше товара доступным на витрине, но увеличивает риск отсутствия товара после оформления.
Отдельно согласуют причины снятия резерва: отмену, отсутствие оплаты, невозможность связаться с покупателем, частичную сборку и замену товара. Правила, существующие только в устных договорённостях сотрудников, не могут быть корректно учтены в обмене.
Сопоставление номенклатуры, вариантов и складов
Сопоставление товаров строят на стабильных идентификаторах, а не на названиях. Название меняется после редакторской правки, а артикул может быть общим для нескольких вариантов. Поэтому до запуска проверяют, какие идентификаторы есть в обеих системах и как они назначаются новым позициям.
Отдельно рассматривают товары с размером, цветом, объёмом, комплекты и наборы. Для каждого типа номенклатуры нужно определить, что считается самостоятельной складской единицей, как она отображается на сайте и в каком виде передаётся в заказе.
При нескольких складах недостаточно решить, нужно ли суммировать остатки. Требуются правила выбора склада для заказа, перемещений между точками хранения, доступности по регионам и продажи с разных складов. Витрина может показывать общий остаток либо наличие для выбранного способа получения — это определяется логистикой магазина.
Контроль ошибок обмена и работа сотрудников
При сбое сотрудник должен видеть статус передачи, объект, который не был обработан, причину ошибки и доступное действие: повторить операцию, исправить данные или передать ситуацию ответственному специалисту. Для этого в проекте предусматривают журнал операций, понятные сообщения и возможность повторной обработки отдельного товара или заказа.
Заранее описывают работу с пустым идентификатором, дублем товара, недоступностью внешней системы, изменённой структурой данных и заказом, который редактировали вручную. Также определяют ответственных за разбор ошибок и границы их действий в сайте и учётной системе.
Интеграцию проверяют на сценариях поступления товара, продажи последней единицы, отмены, возврата, заказа с вариантами, перемещения между складами и недоступности одной из систем. Проверка только обычного успешного обновления не показывает, как обмен поведёт себя в спорных ситуациях.
Как выбрать вариант интеграции со складским учётом
Выбор зависит не от названия CMS. Если интернет-магазин работает на «1С-Битрикс: Управление сайтом», это определяет устройство витрины, каталога и оформления заказа, но не правила складского обмена. CMS сайта и CRM решают разные задачи, поэтому процессы работы с клиентами не следует подменять правилами учёта товаров.
При выборе готового модуля или разработки оценивают поддерживаемые сценарии: типы товаров, резервы, несколько складов, обработку ошибок и содержание журнала обмена. Отдельно уточняют границы решения: базовая передача каталога и остатков может не покрывать нестандартную комплектацию или распределение товаров по регионам.
Подход подходит, когда он соответствует фактическому процессу. Если решение об отгрузке принимает сотрудник, новый заказ не должен автоматически считаться готовым к списанию. Если остатки обновляются по расписанию, это ограничение учитывают в правилах продажи и отображения доступности на сайте.
Часто задаваемые вопросы
- Как понять, что расхождение вызвано интеграцией, а не ошибкой сотрудника?
Сравнивают историю изменений одной позиции в обеих системах: поступление, резерв, заказ, списание, возврат и ручные корректировки. Если исходные данные были корректны, но на сайт пришло другое значение или обновление не состоялось, проверяют правила обмена и журнал операций. Если ошибка уже есть в учётной системе, обмен передаст её дальше.
- Можно ли менять остатки вручную на сайте?
Можно, если для этого определён отдельный сценарий и понятно, как правка соотносится с учётной системой. Иначе следующее обновление перезапишет значение на сайте. Лучше заранее установить, где сотрудники корректируют остатки, а где только просматривают их.
- Что делать, если один товар продаётся с разных складов?
Нужно определить правило выбора склада: регион покупателя, способ получения, приоритет точки хранения или ручное решение сотрудника. Затем проверяют, передаёт ли выбранный вариант обмена остатки и заказы с нужной детализацией. Общий остаток подходит не для каждого процесса.
- Нужен ли резерв товара при добавлении в корзину?
Это зависит от ассортимента и правил продаж. Резерв в корзине может ограничить продажу дефицитной позиции, но при этом блокировать остатки в незавершённых заказах. Решение принимают вместе с правилами срока действия резерва и его снятия.
- Какие данные подготовить до настройки обмена?
Понадобятся примеры товарных карточек и вариантов, список складов, правила доступности, сценарии заказа и отмены, перечень статусов, описание ручных операций и данные об используемых идентификаторах. Если расхождения уже возникали, полезно разобрать конкретные проблемные заказы и позиции.