Тендеры и лиды
Информация
Типичная ситуация: в пятницу вечером на сайте и в рознице распродали последние двадцать единиц ходового товара. В 1С остаток обнулился сразу, а на Wildberries и Яндекс Маркете карточка продолжает показывать «в наличии». Выгрузка остатков шла по расписанию раз в час, и в этот раз она упала с ошибкой, которую никто не заметил. За выходные приходят заказы, собрать их нельзя, в понедельник менеджер массово отменяет. Итог: штрафы за отмены, просевший рейтинг и карточки ниже в выдаче.
Мы в HPACE пишем интеграции 1С и МойСклад с API маркетплейсов, и почти каждый проект начинается с разбора похожего случая. Ниже восемь ошибок, которые мы встречаем чаще всего, и то, как мы их закрываем.
Выгрузка «раз в час» или «раз в 15 минут» означает, что между продажей и обновлением на площадке всегда есть окно. В обычный день это незаметно, а в распродажу или при малом остатке именно в это окно приходят заказы, которые нечем закрыть.
Как решаем:
Подписываемся на изменения в учётной системе. В МойСклад для этого есть вебхуки на документы и остатки, в 1С — регистрация изменений через план обмена или HTTP-сервис, который вызывается при проведении документа.
Изменение не отправляется на площадку напрямую, а кладётся в очередь задач.
Плановая полная сверка остаётся как страховка: периодически сравниваем учёт с тем, что видит площадка.
API маркетплейса может вернуть ошибку сервера, таймаут или ответ о превышении лимита. Если скрипт просто пишет ошибку в лог и идёт дальше, остаток по этим позициям остаётся старым до следующего полного прогона, а иногда и навсегда.
Как решаем:
Каждая отправка — отдельная задача в очереди со статусом. Неудачная задача возвращается в очередь с повтором через нарастающий интервал (экспоненциальная задержка).
После исчерпания попыток задача попадает в отдельный список «не доставлено», и по нему срабатывает оповещение.
Задачи по одному SKU схлопываются: отправляется только последнее значение остатка.
У Wildberries и Яндекс Маркета есть ограничения на частоту запросов к методам остатков и цен. Интеграция, которая на каждое изменение шлёт отдельный запрос, в часы пик упирается в лимит, начинает получать отказы, и обновления встают в хвост.
Как решаем:
Группируем изменения в пакеты: методы обновления остатков у обеих площадок принимают сразу список товаров, и один запрос на сотни позиций лучше сотни запросов по одной.
Ставим ограничитель скорости на стороне интеграции под лимиты конкретного метода, чтобы не доводить до отказов.
Разводим потоки по приоритету: обнуление остатка отправляется раньше, чем его увеличение. Опоздать с «товар появился» не так дорого, как с «товар закончился».
Даже при быстрой синхронизации остаётся задержка: пока заказ с одной площадки дойдёт до учёта, на другой площадке успевают купить ту же последнюю единицу. Если отдавать на все каналы полный остаток, при малых количествах отмены неизбежны.
Как решаем:
Вводим страховой буфер: на площадку уходит не весь остаток, а остаток минус резерв. Резерв задаётся правилом — фиксированное число, процент или порог «если меньше N, показывать ноль».
Правила настраиваются по категориям и отдельным SKU.
Учитываем уже принятые, но ещё не отгруженные заказы со всех каналов: они резервируются в учёте сразу при поступлении, а не при сборке.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13836 тендеров
проведено за восемь лет работы нашего сайта.
Артикул в 1С, артикул продавца на площадке, баркод, размер и цвет как отдельные позиции. Когда сопоставление ведётся вручную в таблице, рано или поздно остаток одного размера улетает в карточку другого, а новые товары месяцами не синхронизируются, потому что их забыли добавить.
Как решаем:
Ведём справочник соответствий внутри интеграции: позиция учёта, характеристика, артикул продавца и баркод для каждой площадки.
Новые позиции сопоставляются по баркоду или артикулу, а несопоставленные попадают в список на ручную проверку, а не пропускаются молча.
Комплекты и наборы рассчитываются от остатков составляющих: набор доступен в количестве, которое позволяет собрать самый дефицитный компонент.
На FBO товар лежит на складе площадки, и его остаток ведёт площадка. На FBS продавец отгружает со своего склада и сам передаёт остатки, причём у Wildberries и Яндекс Маркета они передаются в разрезе конкретного склада продавца. Частая ошибка — отправлять на FBS-склад общий остаток компании, включая товар, который уже уехал на склад маркетплейса или лежит в другом городе.
Как решаем:
Разделяем в учёте склады: товар, отгруженный на FBO, списывается на отдельный склад или помечается и не участвует в расчёте FBS.
Для каждого FBS-склада площадки задаём, какие склады учёта его питают. Если склады продавца в разных городах, это разные цифры для разных складов площадки.
Остатки FBO забираем из API площадки для планирования поставок, но не смешиваем с остатками FBS.
Самая дорогая ошибка — когда интеграция сломалась, а узнают об этом от покупателей или из отчёта о штрафах. Истёк токен API, сменился формат ответа, на сервере кончилось место — и остатки не обновляются уже несколько дней.
Как решаем:
Логируем каждую операцию: что отправили, по каким SKU, что ответила площадка. Лог доступен в простом веб-интерфейсе, а не только разработчику на сервере.
Настраиваем оповещения в Telegram или на почту: задачи, не доставленные после всех повторов, долгое отсутствие успешных отправок, расхождения при сверке выше порога, скорое истечение токена.
Заказ отменили, покупатель вернул товар, кладовщик нашёл пересорт и поправил остаток инвентаризацией. Если интеграция слушает только продажи, все эти движения проходят мимо, и на площадке остаток оказывается ниже реального — товар есть, а продаж нет. Это не штраф, но упущенная выручка.
Как решаем:
Подписываемся на все документы, которые меняют остаток: возвраты, оприходования, перемещения, корректировки, отмены заказов.
Забираем статусы заказов из API площадок и при отмене снимаем резерв в учёте автоматически.
Считаем остаток для площадки по одной формуле во всех случаях — от текущего доступного остатка в учёте, а не прибавлением и вычитанием разниц. Так ошибки не накапливаются.
Сроки зависят от числа площадок, складов и состояния учёта, поэтому ниже порядок работ, а не даты.
Аудит. Смотрим склады и номенклатуру в 1С или МойСклад, схемы работы с площадками, разбираем последние отмены и находим, где теряются остатки.
Проект правил. Фиксируем связи складов учёта и площадок, правила резерва, приоритеты и сопоставление товаров.
Разработка. Сервис интеграции с очередью, повторами, ограничением скорости, справочником соответствий и журналом.
Тестовый прогон на части ассортимента со сверкой расчётных и фактических остатков.
Полный запуск с оповещениями и контролем расхождений в первые недели.
Поддержка: площадки меняют API и требования, интеграцию нужно обновлять, следить за токенами, подключать новые склады.
Штрафы за отмены обычно появляются из-за задержек, тихих сбоев и ручных таблиц, которые не выдерживают роста ассортимента. Всё перечисленное закрывается инженерно: событиями вместо расписания, очередью с повторами, резервом, аккуратным разделением FBS и FBO и мониторингом, который сообщает о проблеме раньше покупателя.
Начните с простого: возьмите десять последних отмен и проследите, где потерялось изменение. Если хотите разобрать это вместе, команда HPACE проведёт аудит текущей схемы и предложит, что автоматизировать в первую очередь.
