Синхронизация остатков 1С с Wildberries и Ozon: почему цифры никогда не сходятся

Магазин товаров для дома: 280 заказов в день, 12 товарных категорий, продажи на своём сайте, Wildberries и Ozon одновременно, команда 14 человек. Остатки в четырёх местах — сайт, Wildberries, Ozon и 1С — расходились на 7,4%. Менеджер сводил их руками трижды в день, и всё равно магазин продавал товар, которого нет на складе, и получал кассовые разрывы.

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

Числа по остаткам — из одного проекта: аудит процессов онлайн-магазина. Средних по рынку здесь нет, только померенное на конкретном складе. Где я ссылаюсь на соседние проекты, называю их прямо.

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

• 1. Разные идентификаторы. У одной и той же позиции свой код в 1С, свой на Wildberries, свой на Ozon и свой на сайте. Пока не сказано прямо, что это один товар, — для систем это четыре товара.
• 2. Разные единицы учёта. Где-то позиция считается штуками, где-то комплектами или упаковками. Число «12» в двух системах означает разное количество товара, а обмен честно переносит его как есть.
• 3. Разные регистры остатков. Какое именно число вы отдаёте площадке: то, что физически лежит на складе, или то, что осталось свободным после уже принятых заказов? В 1С это разные величины. Пока никто не решил, какая из них правильная, обмен будет складывать одну с другой.

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

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

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

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

Второе решение принимается за пять минут, но без него не работает ничего: назвать одну систему главной. Здесь главной стала 1С — она считает остаток, а сайт, Wildberries и Ozon его получают. Заказы со всех каналов собираются в одно окно в RetailCRM.

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

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

Обмен собран на n8n на сервере заказчика — вся обработка остаётся внутри российского контура. Каждые 15 минут сценарий опрашивает 1С, сайт, Wildberries и Ozon, сводит полученное по таблице соответствия, затем пересчитывает остаток на сайте и обновляет карточки на обеих площадках.

Периодичность выбирают из оборота: 15 минут на 280 заказах в день — это несколько заказов в окне. В соседнем проекте — обмене заказов с рабочими таблицами склада — поток другой, там шаг 30 минут, и этого достаточно. Сначала считаете, сколько заказов помещается в интервал, потом выбираете интервал.

Такие связки я делаю как отдельную услугу — интеграции с 1С, Bitrix24 и amoCRM.

Обещать ноль нечестно. Между тем, как площадка приняла заказ, и тем, как списание прошло в 1С, всегда есть окно: внутри него остаток на площадке чуть больше фактического. Оставшиеся 0,3% — это размер окна.

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

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

• 1. Расписание. Обмен запускается сам, с известной вам периодичностью.
• 2. Суточная сверка. Раз в сутки система сама сравнивает остатки во всех источниках и отдаёт список расхождений.
• 3. Проверка живости. Отдельный сигнал «обмен работает». Молчание нельзя принимать за порядок: остановившийся обмен молчит точно так же, как исправный.
• 4. Ночная резервная копия. И хотя бы один раз проверенное восстановление из неё: непроверенная копия остаётся надеждой.
• 5. Оповещение о сбое. Сообщение человеку, повторные попытки и восстановление записей, которые не доехали.
• 6. Честная деградация. Если площадка не отвечает, это видно как «нет связи» и не выглядит как «остатка нет». Иначе неполные данные молча выдаются за полные, а сотрудник принимает по ним решение.
• 7. Безопасное включение. Переезд на боевые данные — вторым контуром: обмен какое-то время пишет и в боевую систему, и в копию-эталон, расхождения ловит суточная сверка, откат — выключить одно расписание. Никакого «большого включения» в понедельник утром.

Как это собрано у меня: контур на шести расписаниях — в проекте обмена заказов с рабочими таблицами склада; подсчёт сбоев по каждому источнику — во внутренней системе для операционной команды.

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

Расхождение остатков — 7,4% до, 0,3% после: сошлись в 25 раз, продажи несуществующего товара практически исчезли. Освободилось 142 часа в месяц — это примерно 1,1 ставки, или 89 тыс. ₽ расчётной экономии на зарплатах ежемесячно. Вложено 600 тыс. ₽: 380 тыс. — аудит, 220 тыс. — внедрение.

Считайте вместе со мной, по одной проверяемой величине: 600 разделить на 89 — это возврат примерно за 7 месяцев на одних зарплатах. На странице кейса стоит окупаемость 4,2× за 12 месяцев — там к зарплатам добавлены ещё и снятые штрафы за продажу товара, которого нет на складе. Их сумму я не публикую, поэтому в статье держусь того, что вы можете пересчитать сами.

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

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

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

И три ситуации, когда обмен не нужен вообще:

• · Оборот маленький. Если всю сверку человек делает за полчаса в день и заказы при этом не теряются — обмен не окупится. Считайте по своему складу.
• · Справочник товаров в беспорядке. Дубли позиций, товары без кодов, «времянки» на складе. Автоматизация закрепит этот беспорядок и начнёт тиражировать его четыре раза в час.
• · Некому отвечать за 1С. Если сейчас нет человека, который разбирается в вашей учётной системе, обмен добавит вторую систему, за которую тоже некому отвечать. Сначала находят человека.

Порядок сумм, чтобы не гадать. Аудит — 9 900 ₽ и засчитывается в первый проект. Пилот — от 60 000 ₽ за 1–2 недели: одна площадка, один сценарий обмена. Полная связка вроде описанной выше — другой порядок: в этом проекте аудит и внедрение вместе стоили 600 тыс. ₽. Разовая часть, ежемесячная и ожидаемый срок окупаемости по направлению собраны в разделе автоматизация процессов, а шесть смет с расчётом окупаемости — в отдельном разборе о стоимости внедрения ИИ.