Год назад на конференции Инфостарта я рассказывал, как лучше начинать интеграцию с маркетплейсами, какие схемы работы бывают, чем разные маркетплейсы отличаются, и в каких случаях привычная нам логика не работает. На этот раз мы углубимся в эту тему и рассмотрим задачу интеграции как с точки зрения разработчика 1С, так и с точки зрения бизнеса.
Постоянно общаюсь с ИТ-директорами или владельцами малого бизнеса, которые выбирают себе решение для организации интеграции 1С с маркетплейсами. Для подготовки к докладу записывал их жалобы, удивления и мысли. Рассказывать их одним потоком нет большого смысла, хочется структурировать информацию, добавить рекомендации по решению проблем. Поэтому буду упоминать по ходу доклада пример этих реальных ситуаций.
Кроме того, когда мы стали разрабатывать свое решение для интеграции с маркетплейсами, то для того, чтобы понять, насколько глубока эта кроличья нора, сами открыли свои магазины на МП (МаркетПлейс). Сейчас под нашим управлением находится два магазина - как франчайзи продаем коробки 1С и также реализуем предметы декора и ароматические свечи и аромадиффузоры для помещений.
Поэтому могу рассказывать и как разработчик решения по интеграции, и как продавец. Вижу полную картину ситуации.
У нас в модуле обратите внимание на эти два очень похожих заказа:
В то же время в ЛК Озон список выглядит так:
То есть в ЛК Озон заказа с posting_number 23318997-0122-2 нету, а есть только 23318997-0122-5.
Вероятно, человек поменял способ оплаты или дату доставки или типа того. И вместо того, чтобы поставить статус cancel, Озон установил новый номер в заказе. Старый как бы пропал.
Поэтому надо следить за тем, если один раз какой-то заказ пришел в ответе на запрос, а потом один из свежих заказов перестал приходить, это означает, что заказ фантомный. И в 1С у него надо поставить статус отменен.
Во-первых, т.к. остаток меняется раз в 30 минут, актуальный остаток, который вы с учетом свежих заказов рассчитаете самостоятельно, в моменте может отличаться от остатка по данным метода /api/v1/supplier/stocks
Представим, что вы хотите построить собственный учет текущих свободных остатков товаров на складе маркетплейса. Например, для прогнозирования, на сколько дней хватит остатков товаров при сохранении текущей средней скорости продаж.
Пришел заказ на товар. Вы создаете документ "Продажа маркетплейса", который двигает регистр свободных остатков. Свободный остаток данного товара уменьшается.
Срабатывает проверка остатков по данным ВБ (Wildberries). 30 минут еще не прошло, и вам приходит информация, что остаток товара больше, чем вы рассчитали. Вы создаете документ "Прочее оприходование товаров маркетплейса".
Срабатывает новая проверка остатков по данным Вайлдбериз. Остатки по данным ВБ обновились, система видит, что товара стало меньше. Создается документ "Прочее списание товара маркетплейса".
Во-вторых, параметр dateFrom означает дату последнего изменений по товару. Получается, если указать сегодняшнее утро, а изменений остатка по товару за сегодня не было, то остаток данного товара мы не получим.
С одной стороны, этот параметр позволяет получить только изменения остатков и, соответственно, облегчить работу алгоритмов.
С другой стороны, если нюанс работы этого параметра не понимать (а раньше в документации не было про него написано понятно) и не адаптировать под это свои алгоритмы, то можно написать код, который посчитает, что товары, которые не пришли в результатах ответа, отсутствуют на складах Wildberries. То есть их остаток 0. И вообще, если указывать свежую дату как значение этого параметра, то отличить товары, по которым не было изменений и товары, у которых остаток равен нулю, никак не получится.
Вот скриншот-иллюстрация проблемы:
Лично я встречал ситуацию, что неподтвержденный заказ был в статусе отменен у нас в кабинете, а у заказчика (мы с ним обменялись скриншотами) статус был активен. И заказчик сидел и ждал доставку товара.
Но от одного из продавцов узнал про возможную мошенническую схему из-за данной проблемы.
Нечестные люди могут знать про эту особенность МегаМаркета и в день доставки в постамат или курьером отменить заказ и получить деньги за него назад. В то же время у курьера статус заказа останется готов к отгрузке и он положит товар в постамат или доставит его в руки "покупателя".
Опытным путем установили, что задержка в обновлении статуса заказа может достигать до 3 суток.
В случае передачи товара и возврата денег крайним в этой ситуации останется продавец. МегаМаркет еще и возьмет плату за услуги доставки товара до постамата/покупателя, так называемые "покатушки".
Это кажется невероятным, но вы можете проверить самостоятельно (создать заказ и отменить его в день доставки), если планируете работать с данным маркетплейсом.
Решение:
Даже у такой абсурдной ситуации есть решение. Знакомый реализовал в модуле функционал выделения красным цветом заказов, по которым товары уже переданы в доставку продавцом, но которые отменены.
Этот красный цвет означает для менеджера, чтобы нужно обращаться на горячую линию, требовать связаться с курьером по данному заказу, убедиться, что он не будет передавать товар клиенту/класть его в постамат.
Кроме неочевидных моментов в работе API главное, о чем следует помнить - что API меняют очень часто. Особенность ВБ в том, что может меняться еще и без предупреждения. Просто в один прекрасный день метод перестает работать, а в документации вы видите уже другую версию этого метода.
Полезные фичиЧто точно известно про API маркетплейсов - это то, что оно будет часто меняться. Нередко изменения происходят без предупреждения. Поэтому процесс установки обновления для новой версии API должен быть автоматизирован разработчиком вашего модуля для интеграции.
Если вы делаете свой модуль, то посмотрите на проблему с другой стороны - имена методов для запросов и параметры должны храниться понятным образом для каждого маркетплейса. Тогда при необходимости внесения изменений (а такая необходимость будет много раз в год появляться) вы сможете быстро все исправить.
Стандартом при разработке программных продуктов является одновременная поддержка минимум двух версий продукта. Одна - стабильная, в которую не добавляется новый функционал, а только исправляются обнаруженные ошибки. Вторая - для разработки нового функционала.
Если у вас в используемом решении коннектор к каждому маркетплейсу выделен во внешнюю обработку-коннектор, то средствами вашего же модуля несложно сделать функционал, который будет с веб-сервиса обновлений скачивать обновления и обновлять файл внешней обработки. В этом случае должна для каждого маркетплейса возвращать результаты одинаковых запросов в универсальном формате. Этот формат результата не должен меняться в зависимости от версии вашего модуля и/или версии API маркетплейса.
Торговля товарами-аналогами, а также ситуация, когда один товар в 1С выкладывается как несколько товаров на МП.
Про аналоги понятно. Очень важно сделать у них одинаковый артикул и штрихкод (не оставлять штрихкод от производителя аналога при сдаче товара на склад маркетплейса, а создать свой).
Один товар как несколько разных выкладывают на Маркетплейсы, когда хотят попасть в несколько категорий сразу.
Соответственно, в модуле у вас должна быть возможность установить такое соответствие, так торговать, во всех отчетах сделать поддержку такого сложного соответствия товаров.
Все зависит от специфики деятельности. Но как правило крупные торговые продавцы работают по смешанной схеме - совмещают ФБО и ФБС. Популярные товары сдают на склад маркетплейса, те, которые заказывают нечасто, а также КГТ и изготавливаемые на заказ, продают по схеме ФБС.
Модуль должен поддерживать режим смешанной работы. Давать возможность обрабатывать отправления по схеме ФБС (на ВБ их также называют поставками).
Что помогает в скорости сборки заказов?Заказы на маркетплейсах приходят в течение дня неравномерно. Крупная торговая компания может позволить себе посадить отдельного человека для оформления документов и отдельного кладовщика только для обработки заказов маркетплейсов. Но даже при этом производительность труда может быть неидеальной.
В идеальной ситуации, которую я наблюдал в жизни, один менеджер склада (он же готовил и этикетки и документы) собирал до 180 заказов в день при восьмичасовом рабочем дне. Но обычно у компаний получается собирать в день гораздо меньше заказов.
Как добиться максимума эффективности?
Модуль для интеграции должен поддерживать пакетную обработку текущих необработанных заказов. То есть важно в каждый момент времени видеть, какие заказы во-первых, должны быть сегодня собраны. Во-вторых, ранее они обработаны не были.
У ВБ с этим проще, там это называется "Поставка", хотя подразумевается именно сборка заказов по ФБС и их сдача в сортировочный центр маркетплейса ВБ.
У Озона такой функционал группировки должен поддерживать сам модуль. Тогда менеджер может один в день обрабатывать заказы, которые в сегодняшний день должны быть отгружены (у ВБ такой проблемы нет, там чем быстрее отгрузить, тем лучше) и отправлять их в доставку в сортировочный центр маркетплейса.
Документ "Заказ клиента" надо создавать, чтобы был резерв товара. Иначе товар могут успеть продать другому клиенту.
Если не делать группировку, будет создаваться отдельный документ "Заказ клиента" для каждого заказа маркетплейса. В этом случае список заказов клиентов становится очень обширным, неудобно с ним работать.
Альтернативный способ: отбором прятать заказы маркетплейса из общего списка заказов клиентов. И работать с ними в отдельном АРМ.
Начинать рекомендуем с Озона. Это не реклама, правда так считаю.
Преимущества:
Это касается всех маркетплейсов. Комиссия "размазана" на большое количество разных услуг. Вы платите не только комиссию за продажу, но и за хранение на складах, обработку (пересчет) поставок, часто за приемку товаров в поставке, за утилизацию брака, за последнюю милю, эквайринг и за доставку.
За каждую поездку невыкупленного товара тоже в итоге платите.
Думаете, это все? Нет, отдельными строками указаны еще услуги комиссии за продажу, логистика, последняя миля, плата за возвраты и отмены, обратная логистика и другое:
Понятно, что часть этих услуг можно распределить на себестоимость товаров, а часть придется вычитать из прибыли от торговой деятельности.
Если ваш модуль не будет поддерживать возможность учета финансового результата от торговли с учетом всех понесенных расходов, то на фоне общей работы компании можно годами не замечать, что на маркетплейсах торговля идет в минус.
Особенно это актуально для категории "Одежда". Там процент выкупа может составлять 35-40%, а за все поездки, где человек померил товар, но не купил его, придется заплатить.
Кстати, Яндекс.Маркет также дает бонусы при регистрации. Нужно иметь в виду, что они сгорают через месяц. То есть после момента регистрации нужно сразу же загружать товары и начинать торговлю, иначе можно не успеть.
Если начинали торговлю с Озона, то на Яндексе есть удобная возможность загрузить карточки товаров из Озона. Все фото, описание, прочие основные поля будут загружены.
Список содержит 40 пунктов и может быть использован для сравнения различных модулей интеграции.
Файл со списком функциональных опций, на которые можно разбить решения для интеграции:
Выбираете из перечня критически важный для вас функционал, ставите его сверху. Просите заполнить разработчиков модулей, которые рассматриваете к покупке, что у них реализовано, что нет.
Оставляете только подходящие решения. И выбираете по ценообразованию, качеству техподдержки, удобству интерфейса лично для вас (попросите провести демонстрацию) и также по широте поддержки необходимого вам функционала.
Рекомендуемая глубина хранения остатков товаров на маркетплейсах составляет от 30 до 60 дней. То есть количество, которое вы сдали на склады маркетплейса, должно хватить на это число дней. Нарушение этого правила чревато финансовыми убытками.
Если товара мало, вы не будете успевать сдавать его до того, как товар закончится. Статус "out of stock" (товар закончился) означает, что позиция товара в рейтинге снижается. После следующей поставке вы увидите, что позиция товара в поиске стала очень низкой. И придется снова прилагать усилия для продвижения товара.
Обратная сторона (слишком много товара сдавать на склады маркетплейса, то есть с запасом) будет означать, что вы будете платить очень много за хранение товаров на маркетплейсе.
Буквально с 1 сентября 2023 года маркетплейсы очень значительно подняли плату за хранение товаров с низкой оборачиваемостью.
Поэтому именно сейчас чрезвычайно важно следить за остатками товаров на маркетплейсах. И придерживаться выбранного вами уровня хранения остатков. Перед высоким сезоном глубину хранения остатков можно сделать больше. В конце сезона можно ориентироваться остаток примерно равный 30 дням продаж.
Считаю, что достаточно простым в ведении учета и интуитивно понятным для пользователей является отчет о прибылях и убытках. Настраиваются постоянные и переменные расходы, вносятся данные по ним плановые и фактические. Данные о продажах и себестоимости собираются автоматически по заказам на маркетплейсах и с учетом себестоимости. Значения себестоимости предварительно надо загрузить как значения отдельного вида цен товаров.
Выглядеть это может похожим образом:
Теория:Напомним, что АВС-анализ ассортимента позволяет выявить ту часть ассортимента, которая обеспечивает наибольшую доходность. В его основе лежит принцип Парето — 20 % всех товаров дают 80 % оборота. Одна из основных идей анализа заключается в том, что контроль 20 % позиций позволяет на 80 % контролировать выручку. Аналогично принципу XYZ анализа ассортимент классифицируется по группам А, В и С.
- Группа А – это очень важные товары, приносящие максимальную прибыль, которые всегда должны присутствовать в ассортименте.
- Группа В – товары средней степени важности.
- Группа С – наименее важные товары, это претенденты на исключение из ассортимента и товары-новинки.
Еще есть XYZ-анализ номенклатуры. Он характеризует вариативность спроса на товар. Идеальный товар - это тот, на который спрос равномерный, в любой период времени близок к среднему.
Классификацию нужно периодически анализировать. Выглядеть это может примерно так:
Парсинг цен конкурентов на маркетплейсах - чрезычайно хайповая тема. Только представьте, сколько можно алгоритмов придумать, имея такую информацию. Сами маркетплейсы эффективно борются с теми, кто пытается программно получать с них информацию.
Пара мыслей на этот счетМы предлагаем как решение использовать полуручной парсинг. То есть в сеансе вашей базы 1С открывается встроенный браузер. Пользователь там вручную авторизуется. Далее система по необходимому алгоритму с заданной периодичностью проверяет реальные цены, которые маркетплейс показывает клиентам. Далее несложно реализовать алгоритм, который поднимет цены на товары, если маркетплейс начинает давать за свой счет слишком большие скидки.
Если у вас есть идея получше, буду рад услышать!
На нашей практике была ситуация, что даже Озон без какого-либо предупреждения очищал фотографии товаров, потому что ужесточил требования к формату фото. Ранее разрешалось формат прямоугольный использовать. А потом стали требовать только квадратные фото.
Соответственно, надо добавлять команды для программной проверки статуса товара (продается / нет), для проверки заполнения ключевых полей (габариты, вес, наличи фото). Но такая программная проверка не исключает и периодическую ручную проверку пользователем.
Ознакомиться с тарифами, условиями продажи и сделать заказ можете на этой странице >>