Автоматизация остатков, заказов и цен на WB/Ozon: как настроить синхронизацию с 1С и убрать отмены, пересорт и ручные правки

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

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

Почему ручной режим ломает продажи: 5 типовых сценариев потерь

1) Отмены из-за отсутствия товара

Самый дорогой сценарий для FBS: товар "в кабинете есть", но на складе фактически закончился или зарезервирован под другой канал. В итоге заказ приходит, а выполнить его нельзя - растут отмены, ухудшаются показатели, падает доверие покупателей.

2) Пересорт на складе

Пересорт на складе - это не только ошибка комплектации. Это ещё и "невидимая" проблема в учёте: остатки есть, но не там; SKU перепутаны; менеджер видит запас, а сборщик не находит товар.

3) Двойной учёт остатков

Когда учет остатков ведётся одновременно в 1С, таблицах, личном кабинете и в фулфилменте, неизбежно появляются расхождения. Чем больше каналов, тем быстрее "едет" фактическая картинка.

4) Автоматизация цен отсутствует, цены правят вручную

Автоматизация цен - это не "удобство", а контроль маржи и конкурентоспособности. В ручном режиме цена часто меняется запоздало, не учитывает остатки и расходы, и в итоге продажи идут "не по той экономике".

5) Нет резервирования товара

Если нет понятного правила резервирования товара, бизнес продаёт один и тот же остаток дважды: по разным каналам или разными менеджерами.

Базовый принцип: один "источник правды" для остатков, заказов и цен

Чтобы интеграция 1с и маркетплейсов работала стабильно, нужно определить "источник правды" - систему, где хранится мастер-данные и откуда остальные получают актуальную информацию.

Варианты, которые встречаются чаще всего:

  1. Источник правды - 1С Подходит, если у вас есть складской учет, номенклатура, документы движения товара и вы хотите, чтобы кабинеты WB/Ozon получали данные из 1С.
  2. Источник правды - WMS/складская система или фулфилмент Подходит, если склад ведётся отдельно и именно склад даёт наиболее точную картину по наличию.
  3. Источник правды - управленческая система контроля Подходит, если задача - не только передать данные, но и контролировать расхождения, регламенты и ответственность.

Главное правило: источник правды один. Всё остальное - подписчики, которые получают данные по расписанию и по правилам.

Как устроить синхронизацию остатков: практическая схема

Шаг 1. Привести номенклатуру к единому стандарту

Без единого стандарта по SKU синхронизация остатков становится нестабильной. Минимум, который должен совпадать:

  • единый идентификатор товара (артикул/SKU);
  • единицы измерения;
  • упаковки и кратность, если используется.

Шаг 2. Настроить обновление остатков по расписанию и по событиям

Обновление остатков должно быть:

  • регулярным (по расписанию);
  • и событийным (после отгрузки, после приемки, после списания).

Чем быстрее продажи, тем важнее минимизировать "лаг" между фактом на складе и данными в кабинете.

Шаг 3. Ввести резервирование товара как обязательное правило

Резервирование товара - главный механизм, который снижает отмены из-за отсутствия товара. Логика простая:

  • заказ пришёл → товар зарезервирован → остаток уменьшен для остальных каналов.

Если резервирование не настроено, при росте заказов ошибки становятся системными.

Синхронизация заказов: как выгрузка заказов в 1С превращается в управляемый процесс

Запрос "выгрузка заказов в 1с" обычно означает: селлер хочет видеть заказы в едином месте, контролировать сборку и не путаться в статусах.

Практический подход:

  1. Заказ из маркетплейса попадает в систему учёта.
  2. Для каждого заказа фиксируется статус: принят → собран → отгружен.
  3. По итогам отгрузки формируется документ списания/реализации (в зависимости от схемы).
  4. Остаток уменьшается автоматически и синхронизируется обратно.

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

Автоматизация цен: что важно, чтобы не потерять маржу

Автоматизация цен должна опираться на понятную формулу:

  • себестоимость + расходы маркетплейса + логистика + резерв на возвраты/риски + целевая маржа.

Дальше появляется практический вопрос: как обновлять цены так, чтобы это было управляемо.

1) Правило "кто имеет право менять цену"

Если цены меняют разные люди в разных местах, автоматизация будет ломаться. Цена должна изменяться по регламенту и фиксироваться.

2) Правило "когда цена меняется автоматически"

Например:

  • при изменении закупочной цены;
  • при изменении комиссии/логистики;
  • при дефиците остатков (может включаться "защитное" ценообразование);
  • при сезонном изменении спроса.

3) Контроль отклонений

Любое автоматическое изменение цены должно иметь контроль: что изменилось, по какой причине, и как это повлияло на продажи и маржу.

Как проверить, что синхронизация работает: контрольные точки

Чтобы "настроить и забыть" не превратилось в "сломалось и никто не заметил", нужны контрольные точки.

Контроль 1: расхождения остатков

Еженедельно выбирайте 20-30 SKU и сравнивайте:

  • остаток в источнике правды,
  • остаток в кабинете WB,
  • остаток в кабинете Ozon.

Если расхождения повторяются по одним и тем же товарам - проблема системная (SKU, единицы, упаковки, лаг, резервы).

Контроль 2: отмены из-за отсутствия товара

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

Контроль 3: пересорт на складе

Фиксируйте пересорт как инцидент: где произошло, почему, как исправили. Пересорт - это всегда сигнал к улучшению маркировки/хранения/сборки, а не "случайность".

Вопросы и ответы

Нужен единый источник правды и обязательное резервирование товара. Также важно настроить обновление остатков по событиям (после сборки/отгрузки), а не только раз в сутки.
Чаще всего причина в лагах синхронизации, отсутствии резервов или двойном учёте (таблицы + кабинет + 1С + фулфилмент).
Да, если есть формула цены, регламент правок и контроль отклонений. Автоматизация цен без контроля превращается в риск.
В операционном смысле критичнее остатки и резервы - они защищают от отмен. Заказы важны для управления сборкой и логистикой.

Как превратить интеграцию в управляемый процесс вместе с TotalCRM

В большинстве магазинов проблема не в том, что нет интеграции 1с с wildberries или интеграция 1с с озон "невозможна". Проблема в том, что интеграция живёт отдельно, а управленческий контроль - отдельно. В итоге ошибки обнаруживаются поздно: когда выросли отмены, когда просела маржа, когда пересорт стал регулярным.

TotalCRM помогает выстроить именно управляемость: контроль остатков и резервов, выявление расхождений, единый контур ответственности, прозрачная картина по периодам и товарам. Это снижает ручные правки, ускоряет реакцию на проблемы и позволяет масштабироваться без роста хаоса.