Заказы Wildberries в 1С: где ломается обмен и что заложить в задание

Две схемы работы — две разные задачи

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

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

Путь заказа внутри учёта

Чтобы склад работал, а не сверялся с личным кабинетом площадки, весь путь должен проходить в программе:

1. загрузка новых заказов с площадки;
2. задание на отбор для кладовщика;
3. рабочее место упаковщика: сканирование, проверка состава;
4. печать этикетки на конкретный заказ;
5. передача перевозчику и закрытие поставки;
6. отражение реализации в учёте.

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

Шесть мест, где это ломается

1. 1С ходит в маркетплейс напрямую

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

В нашем проекте 1С не ходила в маркетплейс вообще: между ними стоял отдельный веб-сервис обмена. Это не усложнение ради красоты — это единственный способ не ставить работу склада в зависимость от доступности чужого API.

2. Товар не найден и пересортица

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

3. Печать этикеток

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

4. Остатки расходятся с площадкой

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

5. Сопоставление номенклатуры

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

6. Площадка меняет правила

Маркетплейсы меняют форматы и требования без согласования с вами. Обмен, который работал год, в какой-то день начинает возвращать ошибки. Это не дефект разработки, а нормальное свойство среды — и поэтому обмену нужны журнал, уведомление об ошибках и человек, который на них реагирует. Подробнее про то, как обмены встают молча, — в статье про обмен с СБИС, Контуром и банком.

Почему проверка стенда важнее, чем кажется

Перед демонстрацией мы провели отдельную проверку собранного стенда и нашли 3 блокирующих дефекта и 19 замечаний. Один из блокеров запирал 11 заданий из 15: упаковать их через рабочее место было физически невозможно.

К контрольной дате в том проекте было закрыто 83 % критичных пунктов задания. Остальное доделывали уже в рабочем режиме — и это нормальный результат для проекта такого объёма, где важно не «сдать всё», а не остановить склад.

Что заложить в задание заранее

• Сценарии отказа. Площадка недоступна, товар не найден, пересортица, отмена заказа покупателем после сборки, возврат.
• Защиту от повторной обработки. Один и тот же заказ не должен превратиться в 2 отгрузки при повторе запроса.
• Журнал обмена, доступный без программиста. Чтобы на вопрос «где заказ» отвечал старший смены, а не подрядчик.
• Печать: сколько принтеров и кто на них печатает. Это выясняется на складе, а не в переписке.
• Кто отвечает за сопоставление номенклатуры. Это операционная роль, и её надо назвать до запуска.

Остальные разборы с цифрами собраны в кейсах, а список того, что мы делаем по маркетплейсам и интеграциям, — в разделе «Что делаем».

Вопросы, которые задают

Сколько занимает интеграция 1С с Wildberries

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

Нужно ли покупать готовый модуль или заказывать разработку

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

Почему остатки на площадке не совпадают с 1С

Чаще всего из-за периодичности передачи и из-за того, что резервы внутри учёта не учитываются при расчёте доступного количества. Лечится уменьшением интервала обмена и правильным расчётом свободного остатка, а не ручной сверкой по утрам.

Можно ли работать с несколькими маркетплейсами из одной базы

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

Что делать, если обмен уже сделан, но постоянно ломается

Начать с журнала: если его нет, первым делом появляется он, потому что без него причина каждый раз ищется заново. Дальше обычно выясняется, что дело в отсутствии очереди и повторов при ошибках площадки. Это переделывается без остановки текущей работы, порядок описан в разделе «Как работаем».