Интеграция с маркетплейсами. Советы, байки и интересный функционал

• Введение
• Термины
• Работа API маркетплейсов (байки, ситуации, проблемы)
  • Фантомные заказы
  • Вайлдбериз. Получение остатков по ФБО
  • МегаМаркет (задержка статусов заказов)
• Внедренцу. Как выбрать модуль для интеграции с технической точки зрения? Как облегчить сопровождение собственного модуля?
  • Автообновление решения
  • Отдельная обработка-коннектор к каждому маркетплейсу
  • Сложное соответствие товаров.
• Как выбрать модуль с точки зрения удобства работы, стоимости и качества?
  • Ценообразование
  • Производительность обработки заказов работниками склада
  • Пакетная обработка заказов по ФБС
  • Группировка заказов маркетплейса при создании документа "Заказ клиента" в 1С
• С чего начать?
  • Озон
  • Услуги маркетплейса и учет финансового результата
  • Яндекс.Маркет
• Функционал решений для интеграции
  • Декомпозиция функционала
  • Расчет поставок по FBO
  • Расчет финансового результата от торговли
  • ABC-анализ товаров
  • Парсинг цен на маркетплейсах
  • "Слетевшие" поля в карточках товаров
• Дополнительный материал (байки продавцов и интеграторов)

Введение

Год назад на конференции Инфостарта я рассказывал, как лучше начинать интеграцию с маркетплейсами, какие схемы работы бывают, чем разные маркетплейсы отличаются, и в каких случаях привычная нам логика не работает. На этот раз мы углубимся в эту тему и рассмотрим задачу интеграции как с точки зрения разработчика 1С, так и с точки зрения бизнеса.

Постоянно общаюсь с ИТ-директорами или владельцами малого бизнеса, которые выбирают себе решение для организации интеграции 1С с маркетплейсами. Для подготовки к докладу записывал их жалобы, удивления и мысли. Рассказывать их одним потоком нет большого смысла, хочется структурировать информацию, добавить рекомендации по решению проблем. Поэтому буду упоминать по ходу доклада пример этих реальных ситуаций.

Кроме того, когда мы стали разрабатывать свое решение для интеграции с маркетплейсами, то для того, чтобы понять, насколько глубока эта кроличья нора, сами открыли свои магазины на МП (МаркетПлейс). Сейчас под нашим управлением находится два магазина - как франчайзи продаем коробки 1С и также реализуем предметы декора и ароматические свечи и аромадиффузоры для помещений.

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

Термины

• Поставка - отправка некоторого количества товаров на склад маркетплейса.
• ФБО - схема работы, при которой товар хранится на складе маркетплейса и при поступлении заказа его собирают и отправляют сотрудники маркетплейса
• ФБС - схема работы, при которой товар хранится на складе продавца. При поступлении заказа продавец самостоятельно собирает заказ (упаковывает товар и наклеивает этикетку заказа), далее сдает его в маркетплейс. Маркетплейс только выполняет доставку до конечного клиента.
• Селлер / мерчант - продавец на маркетплейсе

Работа API маркетплейсов (байки, ситуации, проблемы)

Фантомные заказы

У нас в модуле обратите внимание на эти два очень похожих заказа:

В то же время в ЛК Озон список выглядит так:

То есть в ЛК Озон заказа с posting_number 23318997-0122-2 нету, а есть только 23318997-0122-5.

Вероятно, человек поменял способ оплаты или дату доставки или типа того. И вместо того, чтобы поставить статус cancel, Озон установил новый номер в заказе. Старый как бы пропал.

Поэтому надо следить за тем, если один раз какой-то заказ пришел в ответе на запрос, а потом один из свежих заказов перестал приходить, это означает, что заказ фантомный. И в 1С у него надо поставить статус отменен.

Wildberries. Получение остатков по ФБО

Во-первых, т.к. остаток меняется раз в 30 минут, актуальный остаток, который вы с учетом свежих заказов рассчитаете самостоятельно, в моменте может отличаться от остатка по данным метода /api/v1/supplier/stocks

Представим, что вы хотите построить собственный учет текущих свободных остатков товаров на складе маркетплейса. Например, для прогнозирования, на сколько дней хватит остатков товаров при сохранении текущей средней скорости продаж.

Пришел заказ на товар. Вы создаете документ "Продажа маркетплейса", который двигает регистр свободных остатков. Свободный остаток данного товара уменьшается.

Срабатывает проверка остатков по данным ВБ (Wildberries). 30 минут еще не прошло, и вам приходит информация, что остаток товара больше, чем вы рассчитали. Вы создаете документ "Прочее оприходование товаров маркетплейса".

Срабатывает новая проверка остатков по данным Вайлдбериз. Остатки по данным ВБ обновились, система видит, что товара стало меньше. Создается документ "Прочее списание товара маркетплейса".

Во-вторых, параметр dateFrom означает дату последнего изменений по товару. Получается, если указать сегодняшнее утро, а изменений остатка по товару за сегодня не было, то остаток данного товара мы не получим.

С одной стороны, этот параметр позволяет получить только изменения остатков и, соответственно, облегчить работу алгоритмов.

С другой стороны, если нюанс работы этого параметра не понимать (а раньше в документации не было про него написано понятно) и не адаптировать под это свои алгоритмы, то можно написать код, который посчитает, что товары, которые не пришли в результатах ответа, отсутствуют на складах Wildberries. То есть их остаток 0. И вообще, если указывать свежую дату как значение этого параметра, то отличить товары, по которым не было изменений и товары, у которых остаток равен нулю, никак не получится.

Вот скриншот-иллюстрация проблемы:

МегаМаркет (задержка статусов заказов)

Лично я встречал ситуацию, что неподтвержденный заказ был в статусе отменен у нас в кабинете, а у заказчика (мы с ним обменялись скриншотами) статус был активен. И заказчик сидел и ждал доставку товара.

Но от одного из продавцов узнал про возможную мошенническую схему из-за данной проблемы.

Нечестные люди могут знать про эту особенность МегаМаркета и в день доставки в постамат или курьером отменить заказ и получить деньги за него назад. В то же время у курьера статус заказа останется готов к отгрузке и он положит товар в постамат или доставит его в руки "покупателя".

Опытным путем установили, что задержка в обновлении статуса заказа может достигать до 3 суток.

В случае передачи товара и возврата денег крайним в этой ситуации останется продавец. МегаМаркет еще и возьмет плату за услуги доставки товара до постамата/покупателя, так называемые "покатушки".

Это кажется невероятным, но вы можете проверить самостоятельно (создать заказ и отменить его в день доставки), если планируете работать с данным маркетплейсом.

Решение:
Даже у такой абсурдной ситуации есть решение. Знакомый реализовал в модуле функционал выделения красным цветом заказов, по которым товары уже переданы в доставку продавцом, но которые отменены.
Этот красный цвет означает для менеджера, чтобы нужно обращаться на горячую линию, требовать связаться с курьером по данному заказу, убедиться, что он не будет передавать товар клиенту/класть его в постамат.

Внедренцу. Как выбрать модуль для интеграции с технической точки зрения? Как облегчить сопровождение собственного модуля?

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

Полезные фичи

• Автообновление решения
• Выделение коннектора к маркетплейсу в отдельный модуль или подключаемую внешнюю обработку. Так, чтобы при изменении API было понятно, что именно нужно обновлять, не требовалось обновлять все решение. В таком случае получается, что внешняя обработка - коннектор должна передавать результаты в унифицированном формате независимо от маркетплейса и версии API.

Автообновление решения

Что точно известно про API маркетплейсов - это то, что оно будет часто меняться. Нередко изменения происходят без предупреждения. Поэтому процесс установки обновления для новой версии API должен быть автоматизирован разработчиком вашего модуля для интеграции.

Если вы делаете свой модуль, то посмотрите на проблему с другой стороны - имена методов для запросов и параметры должны храниться понятным образом для каждого маркетплейса. Тогда при необходимости внесения изменений (а такая необходимость будет много раз в год появляться) вы сможете быстро все исправить.

Отдельная обработка-коннектор к каждому маркетплейсу

Стандартом при разработке программных продуктов является одновременная поддержка минимум двух версий продукта. Одна - стабильная, в которую не добавляется новый функционал, а только исправляются обнаруженные ошибки. Вторая - для разработки нового функционала.

Если у вас в используемом решении коннектор к каждому маркетплейсу выделен во внешнюю обработку-коннектор, то средствами вашего же модуля несложно сделать функционал, который будет с веб-сервиса обновлений скачивать обновления и обновлять файл внешней обработки. В этом случае должна для каждого маркетплейса возвращать результаты одинаковых запросов в универсальном формате. Этот формат результата не должен меняться в зависимости от версии вашего модуля и/или версии API маркетплейса.

Сложное соответствие товаров.

Торговля товарами-аналогами, а также ситуация, когда один товар в 1С выкладывается как несколько товаров на МП.
Про аналоги понятно. Очень важно сделать у них одинаковый артикул и штрихкод (не оставлять штрихкод от производителя аналога при сдаче товара на склад маркетплейса, а создать свой).

Один товар как несколько разных выкладывают на Маркетплейсы, когда хотят попасть в несколько категорий сразу.

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

Как выбрать модуль с точки зрения удобства работы, стоимости и качества?

Ценообразование

Лучше выбирать модуль, который не надо оплачивать по подписке. Если есть такая возможность, лучше разворачивать на базе в своей инфраструктуре (есть решения, которые работают только на условиях аренды во Фреше). Потому что захочется дорабатывать. Подключать новые маркетплейсы, новых сотрудников. В решениях на условиях аренды это будет затруднительно и будет означать дополнительные затраты.

Производительность обработки заказов работниками склада

Все зависит от специфики деятельности. Но как правило крупные торговые продавцы работают по смешанной схеме - совмещают ФБО и ФБС. Популярные товары сдают на склад маркетплейса, те, которые заказывают нечасто, а также КГТ и изготавливаемые на заказ, продают по схеме ФБС.

Модуль должен поддерживать режим смешанной работы. Давать возможность обрабатывать отправления по схеме ФБС (на ВБ их также называют поставками).

Что помогает в скорости сборки заказов?

• Заказы товаров из ТОП продаж собирать по очереди группами. (Сначала для первого артикула печатаются все этикетки, потом на складе подбирается этот товар в нужном количестве, на него наклеиваются этикетки. Потом переходим к следующему товару).
• Удобная реализация листа подбора (чтобы кладовщик шел с этим листом по складу, видел, какой товар надо взять и какую из ранее распечатанных этикеток заказов на него наклеить).
• Пакетная обработка отправлений. Про это расскажем подробнее.

Пакетная обработка заказов по ФБС

Заказы на маркетплейсах приходят в течение дня неравномерно. Крупная торговая компания может позволить себе посадить отдельного человека для оформления документов и отдельного кладовщика только для обработки заказов маркетплейсов. Но даже при этом производительность труда может быть неидеальной.

В идеальной ситуации, которую я наблюдал в жизни, один менеджер склада (он же готовил и этикетки и документы) собирал до 180 заказов в день при восьмичасовом рабочем дне. Но обычно у компаний получается собирать в день гораздо меньше заказов.

Как добиться максимума эффективности?

Модуль для интеграции должен поддерживать пакетную обработку текущих необработанных заказов. То есть важно в каждый момент времени видеть, какие заказы во-первых, должны быть сегодня собраны. Во-вторых, ранее они обработаны не были.

У ВБ с этим проще, там это называется "Поставка", хотя подразумевается именно сборка заказов по ФБС и их сдача в сортировочный центр маркетплейса ВБ.

У Озона такой функционал группировки должен поддерживать сам модуль. Тогда менеджер может один в день обрабатывать заказы, которые в сегодняшний день должны быть отгружены (у ВБ такой проблемы нет, там чем быстрее отгрузить, тем лучше) и отправлять их в доставку в сортировочный центр маркетплейса.

Группировка заказов маркетплейса при создании документа "Заказ клиента" в 1С

Документ "Заказ клиента" надо создавать, чтобы был резерв товара. Иначе товар могут успеть продать другому клиенту.

Если не делать группировку, будет создаваться отдельный документ "Заказ клиента" для каждого заказа маркетплейса. В этом случае список заказов клиентов становится очень обширным, неудобно с ним работать.

Альтернативный способ: отбором прятать заказы маркетплейса из общего списка заказов клиентов. И работать с ними в отдельном АРМ.

С чего начать?

Озон

Начинать рекомендуем с Озона. Это не реклама, правда так считаю.

Преимущества:

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

Недостатки:

• Высокая стоимость услуг маркетплейса.
• Пробить первую линию техподдержки и дойти до людей, отвечающих не только скриптами, практически невозможно

Услуги маркетплейса и учет финансового результата

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

За каждую поездку невыкупленного товара тоже в итоге платите.

Думаете, это все? Нет, отдельными строками указаны еще услуги комиссии за продажу, логистика, последняя миля, плата за возвраты и отмены, обратная логистика и другое:

Понятно, что часть этих услуг можно распределить на себестоимость товаров, а часть придется вычитать из прибыли от торговой деятельности.

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

Особенно это актуально для категории "Одежда". Там процент выкупа может составлять 35-40%, а за все поездки, где человек померил товар, но не купил его, придется заплатить.

Яндекс.Маркет

Кстати, Яндекс.Маркет также дает бонусы при регистрации. Нужно иметь в виду, что они сгорают через месяц. То есть после момента регистрации нужно сразу же загружать товары и начинать торговлю, иначе можно не успеть.

Если начинали торговлю с Озона, то на Яндексе есть удобная возможность загрузить карточки товаров из Озона. Все фото, описание, прочие основные поля будут загружены.

Функционал решений для интеграции

Декомпозиция функционала

Список содержит 40 пунктов и может быть использован для сравнения различных модулей интеграции.

Файл со списком функциональных опций, на которые можно разбить решения для интеграции:

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

Оставляете только подходящие решения. И выбираете по ценообразованию, качеству техподдержки, удобству интерфейса лично для вас (попросите провести демонстрацию) и также по широте поддержки необходимого вам функционала.

Расчет поставок по FBO

Рекомендуемая глубина хранения остатков товаров на маркетплейсах составляет от 30 до 60 дней. То есть количество, которое вы сдали на склады маркетплейса, должно хватить на это число дней. Нарушение этого правила чревато финансовыми убытками.

Если товара мало, вы не будете успевать сдавать его до того, как товар закончится. Статус "out of stock" (товар закончился) означает, что позиция товара в рейтинге снижается. После следующей поставке вы увидите, что позиция товара в поиске стала очень низкой. И придется снова прилагать усилия для продвижения товара.

Обратная сторона (слишком много товара сдавать на склады маркетплейса, то есть с запасом) будет означать, что вы будете платить очень много за хранение товаров на маркетплейсе.

Буквально с 1 сентября 2023 года маркетплейсы очень значительно подняли плату за хранение товаров с низкой оборачиваемостью.

Поэтому именно сейчас чрезвычайно важно следить за остатками товаров на маркетплейсах. И придерживаться выбранного вами уровня хранения остатков. Перед высоким сезоном глубину хранения остатков можно сделать больше. В конце сезона можно ориентироваться остаток примерно равный 30 дням продаж.

Расчет финансового результата от торговли

Считаю, что достаточно простым в ведении учета и интуитивно понятным для пользователей является отчет о прибылях и убытках. Настраиваются постоянные и переменные расходы, вносятся данные по ним плановые и фактические. Данные о продажах и себестоимости собираются автоматически по заказам на маркетплейсах и с учетом себестоимости. Значения себестоимости предварительно надо загрузить как значения отдельного вида цен товаров.

Выглядеть это может похожим образом:

ABC-анализ товаров

Теория:

Напомним, что АВС-анализ ассортимента позволяет выявить ту часть ассортимента, которая обеспечивает наибольшую доходность. В его основе лежит принцип Парето — 20 % всех товаров дают 80 % оборота. Одна из основных идей анализа заключается в том, что контроль 20 % позиций позволяет на 80 % контролировать выручку. Аналогично принципу XYZ анализа ассортимент классифицируется по группам А, В и С.

• Группа А – это очень важные товары, приносящие максимальную прибыль, которые всегда должны присутствовать в ассортименте.
• Группа В – товары средней степени важности.
• Группа С – наименее важные товары, это претенденты на исключение из ассортимента и товары-новинки.

Еще есть XYZ-анализ номенклатуры. Он характеризует вариативность спроса на товар. Идеальный товар - это тот, на который спрос равномерный, в любой период времени близок к среднему.

Классификацию нужно периодически анализировать. Выглядеть это может примерно так:

Парсинг цен на маркетплейсах

Парсинг цен конкурентов на маркетплейсах - чрезычайно хайповая тема. Только представьте, сколько можно алгоритмов придумать, имея такую информацию. Сами маркетплейсы эффективно борются с теми, кто пытается программно получать с них информацию.

Пара мыслей на этот счет

• Яндекс.Маркет предлагает ценовые стратегии на основе цен конкурентов (Озон тоже имеет стратегии "следовать за ценой")
• Бывают категории товаров, по которым дистрибьютор / вендор / производитель строго контролирует цены, по которым дилеры имеют право продавать продукцию. Пример - фирма 1С, продажа их коробочных решений. При нарушении партнерский договор может быть разорван. Маркетплейсы дают скидку за свой счет, а потом вендор с вами разрывает договор. Страшно, да?

Мы предлагаем как решение использовать полуручной парсинг. То есть в сеансе вашей базы 1С открывается встроенный браузер. Пользователь там вручную авторизуется. Далее система по необходимому алгоритму с заданной периодичностью проверяет реальные цены, которые маркетплейс показывает клиентам. Далее несложно реализовать алгоритм, который поднимет цены на товары, если маркетплейс начинает давать за свой счет слишком большие скидки.

Если у вас есть идея получше, буду рад услышать!

"Слетевшие" поля в карточках товаров

Пара фактов

• Товары без фотографий не участвуют в результатах поиска на маркетплейсах. Товары без указанных габаритов на ВБ имеют стоимостью хранения х10.
• Маркетплейсы периодически меняют и карточку товара. Добавляют новые поля. Очищают старые значения полей, если изменился формат хранения данных и старые значения ему не удовлетворяют.

На нашей практике была ситуация, что даже Озон без какого-либо предупреждения очищал фотографии товаров, потому что ужесточил требования к формату фото. Ранее разрешалось формат прямоугольный использовать. А потом стали требовать только квадратные фото.

Соответственно, надо добавлять команды для программной проверки статуса товара (продается / нет), для проверки заполнения ключевых полей (габариты, вес, наличи фото). Но такая программная проверка не исключает и периодическую ручную проверку пользователем.

Дополнительный материал (байки продавцов и интеграторов)

Байки:

Дмитрий СММ:


• 80% продаж дают 6 артикулов. Хочется сначала их обойти по очереди. Очень удобно все заказы одного товара распечатать, собрать их, потом перейти к следующего топовому товару;
• мошенники на СберМегаМаркет. Долго по АПИ подгружается статус заказа. У нас был отменен из-за неподтверждения в срок, у клиента "активен". В день заказа если отменить заказ, курьер может приехать и товар спокойно передать вам, т.к. у него в терминале все еще будет статус "готов к отгрузке".
• лист подбора MUST HAVE

Невзоров:


• продают аналоги в одной карточке товара, но не меняют штрихкоды и артикулы. От этого на складах страшная пересортица.
• уперлись в возможности склада. Больше 80 артикулов не могут на маркетплейсы собирать каждый день.
• вес одного отправления в Озон ФбС не более 25 кг. Но Озон сам не разбивает, если в отправлении два товара и всего вес больше получается. Приходится самим.
• Люди даты переносят. Водитель уже может ехать, а в этот момент заказ переносят.
• После набора товаров на складе производится еще процесс проверки, тот ли это товар. Сканируется его штрихкод и печатается в итоге документ. Это когда товары уже набраны.
• при сдаче товаров в Озон (по схеме ФБО или ФБС - неважно) создается документ ПТиУ на склад Озона. С его далее создается уже и реализация.