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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие связки с 1С, Bitrix24 и amoCRM описаны в каталоге услуг.

Ноль обещать нельзя. Между тем, как площадка приняла заказ, и тем, как списание прошло в 1С, всегда есть промежуток. Пока он длится, остаток на площадке чуть больше настоящего. Небольшое расхождение набегает как раз за это время.

С тем же я столкнулся, когда сверял выручку из трёх источников. Разрыв в 8,4% после разбора по заказам почти целиком объяснился отменами и частичными возвратами. Оставшиеся 0,33% пришлись на заказы, оформленные у границы суток.

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

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

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

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

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

В готовом решении для такого магазина три доработки: обмен остатками, ИИ на первой линии поддержки и документы из 1С. Вместе они, по оценке, освободят 142 часа в месяц — почти целую ставку при 40-часовой неделе, или 89 тыс. ₽ экономии на зарплатах каждый месяц. Вложения — 600 тыс. ₽: 380 тыс. — подробный аудит, 220 тыс. — внедрение.

Проверьте расчёт сами: 600 тыс. ₽ делим на 89 тыс. ₽ в месяц, и вложения возвращаются примерно за 7 месяцев за счёт одних зарплат. Экономия на штрафах площадок за отмены сюда не входит: она зависит от магазина.

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

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

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

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

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

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