Вернуться к статьям Покупатель оформляет заказ на маркетплейсе, а товар уже закончился на сайте. Менеджер обнаруживает расхождение после подтверждения заказа, отменяет его вручную и проверяет остатки, карточку товара и журнал обмена. При работе с несколькими витринами такие ситуации быстро превращаются в постоянную сверку данных.
Интеграция интернет-магазина с маркетплейсами нужна, когда одни товары, цены, остатки и заказы приходится поддерживать в нескольких системах. Обмен задаёт единые правила передачи данных и помогает определить, где искать причину расхождения.
Когда нужен обмен товарами и заказами с маркетплейсами
Интеграция оправдана при общем каталоге, из которого сведения передаются на маркетплейсы, или при передаче изменений обратно в рабочую систему. Изменение доступного количества товара должно обновляться по установленному правилу. Заказ с площадки — попадать туда, где его собирают, отгружают и контролируют.
Часть операций может оставаться ручной, если ассортимент меняется редко и каналов продаж немного. Потребность в обмене обычно появляется в следующих ситуациях:
- один товар продаётся на сайте и нескольких площадках;
- остатки регулярно меняются;
- у товаров есть варианты, комплекты или зависимые характеристики;
- сотрудники переносят заказы между кабинетами;
- ошибки приходится сверять в нескольких таблицах и интерфейсах;
- для каналов продаж действуют отдельные правила цен, доступности или описаний.
До выбора решения описывают повторяющиеся действия. Для регулярной выгрузки каталога достаточно одного направления обмена. Если дальнейшая обработка зависит от изменений статуса заказа на площадке, нужно предусмотреть передачу событий по заказу.
Какие данные передавать между интернет-магазином и маркетплейсами
Состав обмена зависит от сценария работы. Отдельно определяют правила для товаров, предложений, остатков, цен, изображений, характеристик, заказов и статусов обработки.
Для каждого объекта фиксируют источник данных. Нужно определить, где создаётся карточка товара, кто корректирует название, какая система ведёт остаток и какие изменения разрешено вносить в кабинете маркетплейса.
Карточка на сайте и карточка на площадке могут различаться. Для публикации могут потребоваться дополнительные атрибуты, другая категория или иной порядок передачи изображений. Одно поле каталога не всегда подходит для всех каналов.
Полезна таблица соответствий с такими пунктами:
- поле источника и поле получателя;
- направление передачи;
- правило обновления;
- обязательность значения;
- обработка пустого или некорректного поля;
- ответственный за исправление данных.
Таблица помогает заранее определить судьбу товара, который есть в каталоге интернет-магазина, но не должен публиковаться на определённой площадке.
Обмен товарами, остатками и ценами
Наиболее чувствительная часть обмена — остатки. До настройки определяют, какое значение передаётся: общий доступный остаток, количество конкретного склада, остаток с учётом резерва или лимит для отдельного канала продаж. Без этого данные могут передаваться технически корректно, но показывать неверную доступность товара.
Для цен также задают правила: какие значения передаются на каждую витрину, как учитываются скидки, что считается приоритетным при расхождении и как обрабатывается ручное изменение в личном кабинете площадки.
Отдельной проверки требуют варианты товара: размер, цвет, объём, упаковка. На витрине они могут объединяться в одну карточку, а в обмене выступать отдельными позициями с собственными артикулами и остатками. Без определённого соответствия варианты могут обновляться неверно или не передаваться.
Интеграция заказов с маркетплейсов и обработка статусов
Состав данных заказа, момент его создания в рабочей системе и последующие действия определяют до настройки обмена. В одном сценарии достаточно номера, состава и количества товаров. В другом нужны сведения для сборки, данные о доставке, отменах, возвратах и изменениях состава.
Статусы сопоставляют по смыслу этапа, а не по названию. Одинаковое слово в разных системах может означать ожидание подтверждения, передачу в доставку, выдачу покупателю или закрытие по другой причине. Для обмена описывают допустимые переходы и события, которые не нужно передавать.
Отдельно разбирают повторные уведомления. Внешняя система может прислать обновление заказа повторно. В требованиях следует указать, как отличать новое событие от дубликата и где сотрудники проверяют спорные ситуации.
Как выбрать схему интеграции интернет-магазина с маркетплейсами
Схему выбирают по источникам данных и сценариям работы. В проекте определяют, какие системы участвуют в обмене, какие объекты передаются и где должны храниться соответствия товаров.
Если сайт работает на «1С-Битрикс: Управление сайтом», CMS относится к устройству интернет-магазина: каталогу, карточкам, корзине и обработке заказов на сайте. CRM может использоваться для внутренних процессов работы с обращениями и сделками. Её задачи следует отделять от задач CMS и товарного обмена.
Возможны прямое подключение между системами, промежуточный сервис обмена или собственный модуль под конкретные правила. При выборе проверяют:
- поддержку нужных типов товаров и вариантов;
- правила для отдельных каналов;
- фиксацию ошибок и повторных попыток;
- возможность остановить выгрузку для одной площадки;
- место хранения соответствий товаров;
- порядок изменения настроек при расширении каталога;
- доступ сотрудников к журналам обмена и настройкам.
Передача базовых полей готовым модулем не подтверждает его соответствие правилам конкретного каталога и обработки заказов.
Что проверить до запуска обмена
Для проверки выбирают реальные товары и заказы с разными условиями: обычный товар, товар с вариантами, позицию с нулевым остатком, карточку с неполным описанием, отменённый заказ и заказ с изменённым статусом. Проверка только полностью заполненных карточек не показывает проблемы с обязательными полями и исключениями.
До запуска согласуют порядок действий при сбое: кто замечает ошибку, где она отображается, кто исправляет исходные данные и как повторно отправляется конкретный объект. Если ручное исправление выполняется непосредственно на витрине, нужно заранее определить, перезапишет ли его следующий обмен.
После запуска контролируют изменения остатка, цены, создание заказа, отмену и возврат товара в продажу. Так можно проверить соответствие фактической обработки согласованным правилам.
Часто задаваемые вопросы
- Можно ли выгружать на маркетплейсы только часть каталога?
Да, если определён признак отбора: категория, список товаров, статус публикации или другое правило. Также нужно задать действие для товара, который раньше выгружался, а затем перестал соответствовать этому правилу.
- Что считать источником данных для остатков?
Источником выбирают систему, где остаток поддерживается фактически и своевременно. Для неё описывают правила резервирования, списания и передачи нулевых значений.
- Нужно ли передавать все статусы заказа?
Передают статусы, которые нужны для дальнейшей обработки и имеют однозначное соответствие. Остальные события можно оставить внутри площадки или рабочей системы, если они не меняют действия сотрудников.
- Что делать, если карточка товара не проходит выгрузку?
Нужно определить причину: отсутствующее поле, неверный формат, несопоставленная категория или другое правило получателя. После исправления задают способ повторной отправки конкретной карточки, чтобы не перезапускать весь каталог.
- Можно ли менять товары вручную в кабинете маркетплейса?
Можно, если это предусмотрено правилами работы. До этого определяют, какие поля последующий обмен перезаписывает из основного источника. Иначе ручная правка может исчезнуть при следующем обновлении.