Контроль расхождений цен и остатков на сайте, маркетплейсах и в 1С
Содержание 10 разделов
Расхождение цены или остатка редко возникает в одной точке. Товар сначала меняется в 1С, затем попадает в модуль обмена, очередь, сайт или кабинет площадки, проходит проверку и только после этого становится доступен покупателю. В это же время другой канал может создать заказ и зарезервировать последнюю единицу. Если контролировать только факт успешной отправки, система не заметит, что получатель применил старое значение, отклонил часть позиций или связал предложение не с тем SKU.
Поэтому задача контроля состоит из двух контуров: надёжно передавать изменения и независимо сверять результат. Для этого не обязательно заменять 1С, CMS или кабинеты продавца. Нужны единая модель идентификаторов, понятная формула доступного количества и журнал, по которому можно объяснить каждое отличие.
Сначала определите владельца каждого значения
Единый источник не означает единственную систему
Для закупочной себестоимости, физического остатка и базовой цены владельцем часто выступает 1С. Сайт может отвечать за контент и локальную механику акции, маркетплейс — за собственные скидки, комиссию и статус публикации. Не следует пытаться принудительно сделать все цифры одинаковыми: нужно различать исходную цену продавца, применённую площадкой скидку и конечную цену для покупателя.
Матрица владения фиксирует для каждого поля источник, направление обмена, допустимое преобразование и частоту обновления. Например, количество поступает из 1С, уменьшается на резервы и страховой запас, а цена канала рассчитывается из типа цен и правил округления. Если площадка изменила значение по своей акции, сверка должна классифицировать это как ожидаемое преобразование, а не как ошибку интеграции.
Сравнивайте доступный, а не бухгалтерский остаток
Физическое количество на складе ещё не равно тому, что можно обещать покупателю. Базовая формула учитывает подтверждённый остаток, активные резервы, уже принятые заказы, карантин, брак, товары в перемещении и страховой буфер. Набор компонентов зависит от процесса, но формула должна быть единой для всех каналов и версионироваться.
Отдельно задают политику общего запаса. Если сайт и три площадки продают из одной корзины, отправка полного остатка каждому каналу создаёт риск перепродажи. Решением может быть общий сервис резервирования, распределённые квоты или консервативный буфер. Выбор зависит от скорости заказов и допустимой задержки обмена.
Разберите причины расхождений по классам
Задержки и гонки событий
Плановый обмен раз в несколько минут всегда оставляет окно, в котором внешнее значение устаревает. Ещё сложнее ситуация, когда заказ и обновление остатка идут параллельно: более старое сообщение может прийти позже нового и вернуть неверную цифру. Поэтому у события должны быть версия или время изменения, а получатель обязан отклонять устаревшее состояние. Периодический полный снимок дополняет события и исправляет пропуски.
Ошибки сопоставления карточек
Артикул, штрихкод, offer ID, номенклатура и характеристика — разные сущности. Один товар может иметь размеры и цвета, несколько упаковок, остатки по складам и отдельные карточки на площадках. Связь по названию ненадёжна. Требуется таблица соответствий, где ключ источника связан с конкретным предложением канала, складом и коэффициентом упаковки.
Изменение артикула или объединение карточек не должно стирать историю. Храните период действия связи и технический ID площадки. Если соответствие отсутствует или неоднозначно, позицию исключают из автоматической отправки и помещают в очередь проверки.
Разные правила цены
На итог влияют НДС, валюта, минимальная цена, наценка канала, округление, промокод и акция площадки. Контроль должен сравнивать не только два числа, но и цепочку расчёта. Полезно сохранять базовую цену, применённое правило, рассчитанную цену продавца, переданное значение и фактически опубликованное значение. Тогда отклонение можно локализовать без догадок.
Создайте каноническую модель предложения
SKU, канал и склад образуют ключ
В центре модели находится продаваемое предложение: номенклатура плюс характеристика и, при необходимости, упаковка. К нему привязываются внутренний SKU, штрихкоды и внешние offer ID. Остаток хранится по складу, а опубликованное значение — по каналу и кабинету. Цена также имеет тип, валюту, период действия и канал.
Не смешивайте текущее состояние и историю передачи. Текущая таблица нужна для быстрого ответа, а журнал событий — для расследования. В нём фиксируются исходное значение, преобразованное значение, номер попытки, ответ API, время подтверждения и корреляционный ID. Секреты доступа и токены в таком журнале хранить нельзя.
Статус публикации — отдельное поле
Нулевой остаток, скрытая карточка, ошибка модерации и товар, заблокированный площадкой, визуально могут выглядеть одинаково — предложение недоступно. Но действия различаются. Поэтому статус листинга, причина отклонения и остаток передаются раздельно. Аналогично цена может быть принята API, но не опубликована из-за ограничения площадки.
Совместите события с регулярной сверкой
Быстрый контур передаёт изменения
После проведения документа, изменения цены или появления заказа формируется событие. Оно попадает в очередь, обогащается правилами канала и отправляется через API либо штатный обмен. Обработчик должен быть идемпотентным: повтор сообщения с тем же ключом и версией не создаёт нового эффекта. Временные ошибки повторяются с увеличивающейся задержкой, постоянные — направляются оператору с понятной причиной.
API площадок и их ограничения меняются, поэтому интеграция не должна зависеть от текста ошибки как от единственного признака. Коды, тело ответа и версия метода сохраняются, а текущие требования сверяются с официальной документацией. Для Яндекс Маркета, например, правила передачи остатков и метод обновления описаны в пошаговой инструкции Partner API.
Медленный контур подтверждает результат
По расписанию система получает фактические цены, остатки и статусы из каждого канала и сравнивает их с ожидаемыми. Важно учитывать время: переданное секунду назад значение ещё может обрабатываться. Поэтому расхождение становится инцидентом только после допустимого окна доставки. Для каждой записи сохраняются ожидаемое, фактическое, разница, возраст и классификация причины.
Полная сверка ловит потерянные события, ручные изменения в кабинете и неполную обработку пакетного запроса. Она не заменяет оперативную передачу, потому что обнаруживает проблему после факта. Вместе оба контура дают скорость и проверяемость.
Настройте резервы и защиту от перепродажи
Резерв должен возникать как можно ближе к моменту принятия заказа и иметь срок жизни. После подтверждения он превращается в заказной резерв, после отмены освобождается, а зависшие резервы разбираются по отдельному регламенту. Если площадка сначала принимает заказ, а сообщает о нём с задержкой, буфер компенсирует часть риска, но не лечит плохой обмен.
Для дорогих или штучных товаров можно передавать меньше доступного количества либо закрывать предложение раньше. Для массового товара чрезмерный буфер снижает продажи. Поэтому его задают по SKU или группе с учётом частоты заказов и скорости синхронизации, а не одним процентом на весь каталог.
Сформулируйте алгоритм сверки
- Получите ожидаемое состояние из канонической витрины на момент проверки.
- Заберите фактическое состояние сайта и площадок вместе со статусом и временем обновления.
- Приведите единицы измерения, валюту, НДС и склады к сопоставимому виду.
- Исключите разрешённые преобразования: акции площадки, округление, буфер и обрабатываемые события.
- Классифицируйте остаток отличий: задержка, сопоставление, отклонение API, ручное изменение или неизвестная причина.
- Создайте повторную отправку либо задачу ответственному и после исправления подтвердите результат новой выборкой.
Контрольные суммы полезны на уровне канала и склада, но не заменяют построчную проверку: положительные и отрицательные отклонения могут взаимно погаситься. При большом ассортименте в первую очередь показывают позиции с продажами, нулём на одном из каналов и значительной денежной разницей.
Показывайте состояние интеграции, а не только ошибки
Операционная панель
На панели нужны время последней успешной загрузки, размер очереди, число повторов, доля отклонённых позиций, возраст старейшего расхождения и распределение причин. Для бизнеса добавляют сумму товаров с неверной ценой, число активных предложений с завышенным остатком и потенциально недоступные продажи. Метрики должны раскрываться до SKU и исходного ответа канала.
Уведомления без шума
Один кратковременный сбой не должен создавать сотни сообщений. Инциденты группируют по кабинету, складу, типу ошибки и запуску обмена. Критичность зависит от влияния: потеря связи со всем каналом важнее единичной карточки без описания. Уведомление содержит владельца, начало, затронутые позиции и ссылку на повторную проверку.
Внедряйте на ограниченном ассортименте
Начните с одного склада, одного кабинета и группы SKU, где понятны характеристики и упаковки. Сначала зафиксируйте эталонные остатки и цены, затем включите журнал передачи, чтение фактического состояния и только после сверки — автоматические корректировки. Отдельно проверьте отмену заказа, возврат резерва, изменение цены задним числом, недоступность API и повтор сообщения.
Для штатного обмена сайта на 1С-Битрикс полезно учитывать официальное описание обмена с 1С, но конкретная схема зависит от редакции и доработок. Маркетплейсы подключают по актуальным кабинетам и документации. Если нужен готовый контур сверки, можно использовать услугу контроля цен и остатков 1С, Битрикс и YML как отправную точку для обследования.
Когда хватает готового модуля
Типовой модуль подходит при одном складе, стандартной конфигурации, простых ценах и стабильных идентификаторах. Доработка оправдана, если несколько юридических лиц делят запасы, используются квоты, сложные характеристики, собственные правила ценообразования или требуется доказуемая история каждой отправки. Оценивать следует не число интеграций, а число исключений из типового процесса.
Перед выбором решения попросите показать обработку частичного ответа API, повтор запроса, потерянное событие и сверку фактического состояния. Именно эти сценарии отличают устойчивый обмен от скрипта, который работает только при идеальных данных.