На складе осталось пять единиц товара. Маркетплейс должен знать, что их пять. Товар закончился — нужно быстро передать ноль. Поступил заказ, а поставщик ещё не успел изменить остаток у себя — это тоже желательно учесть.
Когда товаров десять, за этим ещё можно следить вручную. Когда их тысячи, десятки или сотни тысяч, без автоматизации уже не обойтись.
Tovaroved автоматически обновляет остатки на Ozon, Wildberries, Яндекс Маркете и Мегамаркете. Мы работаем с FBS, realFBS, DBS, Express-вариантами и другими похожими схемами, где товар находится не на складе маркетплейса, а у самого продавца или его поставщика.
Именно о таких схемах дальше и пойдёт речь.
Остаток — это количество конкретного товара, которое сейчас есть в наличии. Например, одного артикула осталось 10 штук, другого — 3, третьего уже нет совсем.
Маркетплейсу эти данные нужны по простой причине: он не должен позволить покупателям заказать больше товара, чем продавец сможет отгрузить.
Если на площадке продолжает числиться товар, которого уже нет, поступит заказ. Продавец его отменит, покупатель останется недоволен, а сам селлер может получить штраф или другие ограничения со стороны маркетплейса. При регулярных массовых отменах последствия становятся ещё серьёзнее.
Поэтому при FBS и подобных схемах актуальные остатки — такая же базовая часть работы, как карточки товаров и цены.
Цены тоже можно рассчитывать и обновлять автоматически. Для этого в Tovaroved есть отдельный механизм расчёта цен по юнит-экономике. С остатками задача другая: нужно постоянно следить за изменяющимся наличием и передавать его маркетплейсу.
Если у продавца 5 или 10 товаров, всё ещё можно делать вручную: товар закончился — зайти в кабинет маркетплейса и поставить 0.
С несколькими десятками товаров это уже превращается в рутину. С сотнями легко допустить ошибку. С тысячами ручная работа практически теряет смысл.
Это не значит, что Tovaroved нужен только продавцам с огромным ассортиментом. Автоматизация полезна и при значительно меньшем количестве товаров — тем более что вместе с остатками в одном сервисе можно автоматизировать цены, работу с акциями и другие регулярные задачи. Просто чем больше ассортимент, тем быстрее ручное обновление становится практически невозможным.
А ассортимент наших клиентов нередко исчисляется десятками и сотнями тысяч артикулов. При этом товары могут находиться:
Это актуально и для обычной торговли со своего склада, и для дропшиппинга. С технической точки зрения задача одна: где-то есть источник актуальных остатков, а Tovaroved должен получить эти данные, правильно подготовить их и передать маркетплейсу.
Автоматическое обновление остатков — одна из ключевых функций сервиса Tovaroved. Мы занимаемся ей с момента запуска сервиса в 2020 году, поэтому за это время успели столкнуться с очень разными ситуациями — от простой Google таблицы с двумя колонками до миллионов артикулов и сложных схем с несколькими складами.
Если очень упростить, цепочка выглядит так:
Источник данных → Tovaroved → подготовка остатков → маркетплейс.
Но самое интересное находится как раз посередине.
Автоматическое обновление остатков — это не просто передача числа по API. Нужно понять, откуда взять данные, как сопоставить товар и какой остаток действительно безопасно показать покупателю.
При подключении мы сначала смотрим, где вообще находятся актуальные остатки продавца или его поставщика.
Строгого требования к формату нет.
Дальше нужно понять, как товар из источника связан с товаром на маркетплейсе.
В одном случае это может быть offer_id, в другом — sku,
vendorCode, артикул продавца или штрихкод.
Мы не выбираем поле формально: для каждого подключения проверяем структуру данных и ищем идентификатор, по которому товары действительно можно надёжно сопоставить.
После этого исходный остаток можно скорректировать.
Например:
При необходимости можно экстренно обнулить остатки на подключённом складе сразу для всего ассортимента.
И только после обработки подготовленное значение передаётся на нужный склад маркетплейса.
На практике это один из первых вопросов при подключении нового продавца: «А где у вас сейчас находятся данные?»
Мы можем работать с самыми разными источниками:
В простом случае никакая сложная информационная система вообще не нужна. Например, для автоматической синхронизации остатков может быть достаточно Google таблицы, где есть две колонки:
Артикул | Остаток
Если исходный формат напрямую не подходит, мы можем подготовить дополнительный скрипт и преобразовать данные перед загрузкой в Tovaroved.
Это тоже важный практический момент.
Допустим, основной YML-фид содержит карточки и цены, а актуальные остатки поставщик отдаёт отдельным файлом. Это нормально.
Или:
Для каждой функции Tovaroved можно настроить свой источник. Они могут быть независимыми и даже иметь разные форматы.
Более того, при необходимости данные можно объединить.
Например, продавец хочет использовать разные минимальные остатки для дешёвых и дорогих товаров. Для этого системе нужны и остаток, и цена. Если остатки находятся в одном фиде, а цены в другом, промежуточный скрипт может сопоставить данные и подготовить единый набор для дальнейшей обработки.
То есть отсутствие какого-то поля в конкретном фиде далеко не всегда означает, что нужную логику реализовать невозможно.
При работе с 1С есть отдельная оговорка. Мы можем получать из неё данные, но сами не являемся разработчиками 1С. Если требуется доработка непосредственно внутри конфигурации, подключается специалист 1С — тот, с которым уже работает клиент, либо специалист, которого можем привлечь мы.
Вот здесь начинается одна из самых полезных частей автоматизации.
Показывать на маркетплейсе ровно то число, которое записано у поставщика, — далеко не всегда лучший вариант.
Представим, что на складе числятся последние три единицы товара.
На бумаге они есть. На практике одну могли уже куда-то переместить, а другую не найти при сборке. Особенно часто такая проблема возникает с последними остатками большого ассортимента.
Поэтому в Tovaroved можно установить нижний порог положительного остатка.
Есть два варианта работы.
В простом режиме, например при пороге 3, значения 1 и 2 передаются как 0, а остаток 3 и выше передаётся без изменения.
Но обычно безопаснее другой вариант. Порог определяет минимальное фактическое количество, при котором товар ещё можно показывать в наличии, а первые единицы остаются запасом на возможную недостачу.
Например, при пороге 3:
| В источнике | Передаём на маркетплейс |
|---|---|
| 1 | 0 |
| 2 | 0 |
| 3 | 1 |
| 4 | 2 |
Таким образом, покупателям показывается только количество сверх запаса, который мы решили оставить на возможную недостачу.
Если на складе числятся последние три единицы, это ещё не значит, что сотрудники действительно найдут все три. Такой режим уменьшает риск принять заказ на товар, которого фактически уже не окажется.
У товаров разной стоимости обычно разная интенсивность продаж.
Недорогой товар может быстро разойтись сразу в нескольких экземплярах, поэтому для него разумно использовать более высокий порог. Для дорогого — меньший.
Например:
| Цена товара | Минимальный порог |
|---|---|
| до 100 ₽ | 10 шт. |
| от 100 до 1000 ₽ | 5 шт. |
| более 1000 ₽ | 3 шт. |
Ценовые диапазоны и сами значения полностью настраиваются.
Если в источнике остатков есть цены, Tovaroved может использовать их сразу. Если цены находятся в другом фиде, данные можно предварительно объединить.
Если получить цены невозможно, остаётся простой вариант — один общий порог для всего ассортимента.
Ещё более интересная ситуация возникает между маркетплейсом и учётной системой.
Допустим:
Если при следующем обновлении снова передать эти 5 единиц, уже заказанный товар фактически снова попадёт в доступный остаток.
Tovaroved умеет учитывать поступивший заказ самостоятельно.
Пока исходная система ещё не уменьшила наличие, мы резервируем заказанную единицу и передаём уже 4.
Когда заказ переходит в следующий статус и товар фактически отгружен, резерв снимается: предполагается, что к этому времени фактический остаток уже изменился в исходной системе.
Это позволяет системе реагировать на заказ раньше, чем его успеет обработать поставщик или внутренняя программа продавца.
Иногда поставщик указывает 500, 1000 или даже 10 000 единиц одного товара.
Совсем не обязательно показывать покупателям все десять тысяч.
В Tovaroved можно задать максимальный остаток. Например, фактически доступно 10 000, а на маркетплейс передаём максимум 50.
Одна из причин — защита от слишком крупных заказов.
На практике продавцы сталкиваются и с нежелательными или предположительно фиктивными заказами. Если открыть возможность заказать огромный объём дорогостоящего товара, последствия могут оказаться неприятными: либо отгружать его, либо отменять большой заказ.
Допустим, продавец не хочет, чтобы один покупатель мог заказать конкретный товар больше чем на 50 000 ₽.
Tovaroved учитывает цену и рассчитывает, какое максимальное количество можно показать.
Для товара стоимостью 10 000 ₽ это будет 5 штук. Для товара по 1000 ₽ — 50.
Так ограничение автоматически работает для товаров с разной ценой, а продавцу не приходится вручную рассчитывать максимальное количество каждого артикула.
Не весь ассортимент обязательно должен обрабатываться одинаково.
Для отдельных артикулов, брендов или других групп можно задавать свои правила или вообще исключать их из передачи остатков.
То есть автоматизация не требует подгонять весь большой каталог под одну универсальную формулу.
Tovaroved подходит и для более сложных схем, когда продавец работает сразу с несколькими поставщиками или несколькими складами.
Для разных поставщиков можно использовать отдельные источники данных, а для разных складов — передавать соответствующие остатки раздельно на склады маркетплейсов.
У некоторых наших клиентов используются десятки складов в разных городах, и система автоматически обновляет остатки для каждого из них.
Количество подключённых складов само по себе на стоимость тарифа не влияет.
Общий принцип автоматической синхронизации остатков один и тот же, но площадки отличаются устройством складов и идентификаторами товаров.
Tovaroved может обновлять несколько складов продавца и использовать для них разные настройки.
Есть и интересный сценарий для одновременной работы FBO и FBS.
Допустим, товар уже завезён на склад Ozon и продавец хочет сначала распродать именно его. Пока на FBO есть запас, продавать тот же товар со своего склада ему не нужно.
В Tovaroved можно установить правило: если остаток FBO выше заданного значения, на FBS передавать 0.
Причём порог регулируется. Например, пока на FBO есть две и более единицы, FBS закрыт. Осталась одна — продажи со своего склада снова открываются, потому что последнюю единицу на складе маркетплейса могут не найти.
Система сама проверяет наличие на FBO и решает, какой остаток передать на FBS.
С Wildberries мы работаем с остатками уже давно, и здесь есть разные варианты сопоставления товаров.
Исторически остатки FBS передавались по штрихкодам. Такой режим Tovaroved поддерживает и сейчас — он нужен, например, когда внутри одной номенклатуры есть разные размеры и у каждого должен быть свой остаток.
Но большинству наших клиентов отдельный учёт по размерам не требуется.
Поэтому Tovaroved умеет обновлять остатки Wildberries и непосредственно по артикулам. На практике именно этот вариант сейчас используется у значительной части наших клиентов.
Здесь работает та же общая схема: получаем данные продавца или поставщика, сопоставляем товары и склады, применяем правила обработки и автоматически передаём готовые остатки площадке.
То есть продавцу не требуется отдельная система автоматизации для каждого маркетплейса.
По умолчанию в Tovaroved остатки обновляются раз в час.
Для большинства ассортиментов этого достаточно, особенно вместе с минимальным порогом и резервированием заказов.
Но расписание можно менять.
Некоторым клиентам остатки достаточно обновлять реже. Другим, наоборот, требуется более высокая скорость.
У нас есть проекты, где обновление выполняется каждые 10 минут.
Частая выгрузка требует соответствующего тарифа, а стандартное обновление раз в час входит в обычный тариф.
Это тот случай, где автоматизация должна не только что-то делать, но иногда уметь ничего не делать.
Представим, что у поставщика временно недоступен сервер. Tovaroved не смог получить фид.
Если источник не удалось прочитать, безопаснее пропустить одно обновление, чем по ошибке обнулить весь ассортимент.
Поэтому Tovaroved работает иначе.
Разовый сбой обычно не требует вмешательства клиента.
Если проблема повторяется из часа в час, мы уже связываемся с продавцом. Дальше становится понятно, где искать причину: в его собственной системе или у поставщика.
Такие ситуации — обычная часть эксплуатации интеграций. Поэтому система должна не только обновлять данные в штатном режиме, но и безопасно переживать сбои.
Это уже совсем другая ситуация.
Фид успешно получен, но товар, который раньше там был, пропал.
Если ничего не сделать, на маркетплейсе может остаться старый положительный остаток. Товар продолжат заказывать, хотя поставщик его больше не предлагает.
Поэтому в Tovaroved есть отдельная настройка: автоматически обнулять остатки товаров, исчезнувших из фида.
Обычно мы её включаем.
Но это именно опция: если для конкретного проекта правильнее сохранить прежнее значение, автоматическое обнуление можно отключить.
Когда интеграция работает каждый час и обрабатывает десятки тысяч товаров, иногда нужно восстановить, что происходило в конкретный момент.
Поэтому каждая выгрузка в Tovaroved логируется в специальных файлах.
При необходимости можно посмотреть:
Это позволяет разбирать даже редкие нестандартные ситуации.
Например, остаток мог быть отправлен, но маркетплейс отклонил его из-за неподходящего типа склада: товар должен находиться на складе КГТ, а остаток был передан на обычный. Ответ API сохранится в логе, и причину можно будет найти даже спустя время.
Для Tovaroved это уже знакомый масштаб.
Сейчас у отдельных наших клиентов ассортимент превышает 100 тысяч товаров, и система работает с ним в обычном режиме.
Но самый интересный опыт был ещё крупнее.
Один из клиентов когда-то работал с ассортиментом более 2 миллионов артикулов.
Изначально у его поставщика было около 500 тысяч товаров. Но продавец дополнительно создавал отдельные позиции для комплектов: один товар, две штуки, три штуки, четыре и так далее. У каждого комплекта был свой артикул, название и карточка.
Так ассортимент и вырос до нескольких миллионов позиций.
На такой объём Tovaroved изначально не рассчитывался. Поэтому нам пришлось оптимизировать систему, ускорять обработку и постепенно устранять узкие места.
В результате сегодня механизм обновления остатков спокойно справляется не только с тысячами и сотнями тысяч, но технически может работать и с каталогами в миллионы записей.
Это хороший пример того, откуда в системе появляются возможности, которых не видно по одному переключателю в интерфейсе: многие из них появились потому, что когда-то реальный клиент поставил перед нами реальную задачу, и её пришлось решать.
Новых клиентов мы обычно подключаем вместе с нашим специалистом.
Не нужно заранее переделывать всю свою систему под Tovaroved. Сначала мы смотрим, что уже есть:
Если стандартного подключения недостаточно, подготавливаем скрипт преобразования данных.
Так можно подключить даже ситуацию, где цены лежат в одном месте, остатки в другом, артикулы записаны третьим способом, а маркетплейсу требуется четвёртая структура данных.
Опытные пользователи Tovaroved могут многое настраивать самостоятельно. Но особенно при первом подключении мы предпочитаем участвовать сами: наша цель не просто предоставить доступ к системе, а добиться, чтобы вся цепочка действительно была правильно настроена.
Автоматическое обновление остатков уже входит в тариф и отдельно не оплачивается.
Для ориентира:
В стандартном варианте остатки обновляются раз в час.
При этом тариф используется не только ради одной функции. В него входят и другие возможности Tovaroved: например, автоматическое обновление цен, вывод товаров из архива Ozon, контроль участия товаров в акциях и автоматический вывод из убыточных акций.
Отдельной дополнительной опцией является именно расчёт цен по юнит-экономике.
С тарифами сервиса можно ознакомиться по ссылке.
На первый взгляд автоматическое обновление остатков кажется простой задачей: получить число и передать его по API.
Мы занимаемся этим с 2020 года и хорошо знаем, что реальная работа начинается как раз там, где эта простая схема заканчивается.
Фид может временно не загрузиться. Товар может исчезнуть из источника. Последние единицы могут физически не найти на складе. Заказ уже поступил, а поставщик ещё показывает старый остаток.
Для дешёвых и дорогих товаров может потребоваться разный порог. У продавца могут быть десятки складов. Данные о цене и наличии могут находиться в разных системах. А огромный остаток поставщика иногда вообще не стоит показывать покупателям целиком.
Все эти ситуации когда-то возникали у реальных продавцов. Поэтому сегодня для них в Tovaroved уже есть готовая логика, настройки и защитные механизмы.
Селлер не должен каждый день думать, какой фид сегодня не загрузился, где уменьшить остаток вручную и не остался ли на маркетплейсе товар, которого уже нет. Этим должна заниматься система.
Если вы работаете по FBS, realFBS, DBS или другой схеме со своего склада, начинать можно с самого простого: показать нам, где сейчас находятся ваши остатки.
Это может быть YML-фид, Excel, API, 1С, МойСклад или обычная Google таблица.
Мы посмотрим структуру данных, склады и особенности вашей работы и предложим, как настроить автоматическое обновление в Tovaroved. А дальше система будет регулярно выполнять эту работу сама — с теми правилами и защитой, которые нужны именно вашему ассортименту.
Покажите, где сейчас хранятся ваши остатки. Мы посмотрим источник данных, склады и особенности работы и предложим подходящую схему автоматизации в Tovaroved.
Ozon, Wildberries, Яндекс Маркет и МегаМаркет являются зарегистрированными товарными знаками соответствующих правообладателей. Сервис Tovaroved не является их официальным представителем. Упоминание данных брендов носит информационный характер. Использование на сайте сертификатов осуществляется в информационных целях и на основании участия сервиса в соответствующих партнёрских программах.
Все права защищены © 2020-2026, Tovaroved ® ИП Гневышев А.Ю., ОГРН 313743017200061