Каталог не проходит модерацию
Позиции возвращаются из-за отсутствующих характеристик и единиц измерения. Товар просто не появляется в продаже, и никто не знает, сколько его там застряло.
Выберите тему — соберём контекст
Каталог проходит требования площадки, а ставки считаются от маржи
Яндекс Маркет строг к каталогу и чувствителен к ставкам: несоблюдение требований категории означает, что товар просто не продаётся. Собираем каталог из учётной системы по правилам площадки, ведём цены и остатки в одном месте, передаём ставки по понятным правилам и разводим схемы доставки, чтобы остаток не расходился между складами.
Площадка предъявляет требования к данным, а не к вашему процессу. Если каталог и цены ведутся в кабинете, любое расхождение превращается в потерянные показы и продажи.
Позиции возвращаются из-за отсутствующих характеристик и единиц измерения. Товар просто не появляется в продаже, и никто не знает, сколько его там застряло.
Цену меняют на площадке, а в учёте остаётся старая. Маржа считается по цифре, которой уже не существует.
Ставка поднята «на всякий случай», а по позиции с низкой наценкой она съедает всю прибыль.
Товар отгружается то со своего склада, то со склада площадки, а остаток считается одной цифрой.
Отдельная строка — ставки: это единственная сущность, которая ходит в обе стороны, потому что решение о ставке принимается по данным самой площадки.
Требования площадки к каталогу меняются: правится проверка и маппинг полей, а данные в учётной системе остаются в своём формате.
Каталог — не файл, который выгружают один раз. Это правила соответствия, которые проверяются при каждом обновлении.
Для каждой категории площадка требует свой набор полей. Он настраивается один раз и проверяется при выгрузке, а не выясняется из сообщения модератора.
Вес, объём и размеры приводятся к тем единицам, которые ждёт площадка. Иначе позиция уходит в модерацию или считается в доставке неверно.
Внутренний артикул связывается с идентификатором на площадке. Это защищает от дублей при повторной выгрузке и при смене формата файла.
Изменения в учёте уходят на площадку точечно: цена, остаток или описание обновляются отдельно, без полной повторной выгрузки каталога.
Схема определяет, где лежит товар и в какой момент продажа становится фактом. Пока это не разведено в учёте, остаток будет расходиться.
Товар передаётся поставкой и продаётся со склада площадки. В учёте он числится там же — с сохранением права собственности до продажи.
Заказ собирается у вас по срокам площадки. Остаток уменьшается при передаче в отгрузку, а не в момент оформления заказа покупателем.
Схема, где доставку выполняет ваша логистика. Статусы из службы доставки передаются на площадку, чтобы покупатель видел движение заказа.
Возврат приходит документом и возвращает товар в остаток того склада, куда он физически приехал.
Начинаем с аудита каталога: какие категории торгуются, что требует площадка и как позиции сопоставляются с учётом. Первый обмен делаем на ограниченном ассортименте и только потом включаем полностью.
Разбираем системы, сущности и потоки. Фиксируем, что считается источником правды и где сейчас расходятся данные.
Описываем поля, форматы, частоту и правила сопоставления справочников. Согласуем до начала разработки.
Проверяем обмен на реальных данных в ограниченном объёме: несколько десятков записей в обе стороны.
Включаем полный обмен с очередью, повторными попытками, журналом и защитой от дублей.
Мониторинг, сверка расхождений, обновление коннекторов при изменениях API на стороне сервиса.
Площадка регулярно уточняет правила и ограничивает частоту запросов. Обмен построен так, чтобы изменения на её стороне не превращались в ручную работу.
Повторная доставка одного и того же события не создаёт вторую сделку, второй заказ или второй платёж.
Если внешняя система недоступна, операция ждёт и повторяется по расписанию, а не теряется.
Видно, что и когда ушло, что вернулось и что не прошло. Неудачную операцию можно повторить вручную.
Учитываем ограничения по частоте запросов, чтобы не получить блокировку со стороны сервиса.
Регулярная сверка ключевых сущностей между системами: расхождение видно в отчёте, а не в конце квартала.
При остановке обмена приходит уведомление ответственным, а не выясняется из жалобы клиента.
Часто эти интеграции внедряются вместе — например, CRM и телефония, или магазин и маркетплейсы.
Остатки и цены совпадают с вашим складом
Интеграция с Wildberries: выгрузка карточек, синхронизация остатков и цен, сбор заказов и статусов поставок.
ПодробнееЗаказы площадки попадают в учёт сразу
Интеграция с Ozon: товары, цены, остатки, заказы, отгрузки и отчёты по реализации.
ПодробнееЭкспортные продажи без двойного учёта
Интеграция с AliExpress: выгрузка товаров, обработка заказов, логистика и статусы отправлений.
ПодробнееОдин склад — несколько площадок
Интеграция с маркетплейсами: единая выгрузка товаров и остатков, сбор заказов с нескольких площадок.
ПодробнееМагазин и учёт показывают одно и то же
Интеграция с e-commerce платформами: товары, цены, остатки, заказы, оплаты и доставка.
ПодробнееОбмен редко ограничивается одной категорией: магазин обычно связан и со складом, и с платежами, и с маркетплейсами.
Если вашего вопроса здесь нет — задайте его в форме ниже.
Расскажите, какие категории продаёте, по каким схемам отгружаете и как сейчас управляете ставками. Предложим схему обмена и порядок работ.
За 3 рабочих дня разберём: где вы теряете заявки, какие каналы недооценены, и что даст рост в первые 30 дней.
Без обязательств. С конкретными цифрами.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.