Интеграция с маркетплейсами. Продвинутый уровень

В 2022 году я уже рассказывал на конференции Инфостарта про интеграцию с маркетплейсами. Это был доклад базового уровня: мы обсуждали, чем отличаются маркетплейсы; какие у них бывают схемы работы; и как привычная для 1С-разработчиков логика может не срабатывать при погружении в эту предметную область.

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

В этот доклад я постарался собрать и структурировать наиболее актуальную информацию для владельцев магазинов на маркетплейсах. Я регулярно с ними общаюсь, и они делятся историями – рассказывают о своих проблемах, и как они их решают.

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

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

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

Проблемы маркетплейсов. Ozon

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

А здесь показано, как эти же заказы отображаются в личном кабинете селлера на маркетплейсе Ozon – как видите, на эту товарную позицию был только один заказ.

Когда мы обратились в техподдержку, оказалось, что дело в грузовых местах: сначала заказанный товар поместили в одно отправление, а потом что-то поменялось, и его переложили в другое. Поэтому сначала Ozon сообщил об отправлении с номером, оканчивающимся на цифру «2», а потом его номер просто в какой-то момент перестал возвращаться на запрос об актуальном списке заказов.

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

Получается, что вместо того, чтобы поставить в заказе статус «Cancel» (заказ отменен), Ozon про него просто забыл – это отправление просто исчезло, как какой-то «фантомный заказ».

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

Проблемы маркетплейсов. Wildberries

Перейдем к примеру с маркетплейсом Wildberries.

На слайде – скриншот из документации к API Wildberries. Здесь показано описание метода, позволяющего получить данные об остатках ваших товаров на складе маркетплейса.

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

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

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

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

Причем у этого метода есть и вторая проблема: данные по остаткам обновляются раз в 30 минут, и если вы хотите реализовать у себя в системе собственный алгоритм расчета свободных остатков товаров, это нужно учитывать. Например, если при поступлении заказа вы уменьшите свободный остаток товара в системе, а потом сделаете проверку остатков на складе маркетплейса, не дожидаясь интервала обновления в 30 минут – он вам вернет старые остатки. Этот нюанс стоит отслеживать и помнить, что для корректного ответа об остатках должно пройти 30 минут.

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

• В первой строке отражена сама продажа – момент, когда поступил заказ и товар был продан.

• Вторая выделенная строчка – это аналог документа «Прочее оприходование товаров». Метод запрашивает реальный остаток по данным маркетплейса, видит, что реальный остаток товара по данным маркетплейса больше, чем в вашей системе и создает документ прихода товара, делая вывод, что пришла поставка – метод же не знает, по какой причине на вашей стороне остаток меньше.

• Далее из-за неправильного значения параметра dateFrom в регистре сформировалось движение на -3 – остаток обнулился.

• Потом вызов метода исправили – товар снова появился.

• Потом снова обнулили – снова -3.

• И снова появился.

Не делайте так. Учитывайте специфику данного метода API у маркетплейса Wildberries.

Проблемы маркетплейсов. МегаМаркет

Перейдем к примеру с маркетплейсом «МегаМаркет» – раньше он назывался «СберМегаМаркет», а еще раньше был известен как Goods.ru.

Когда в 2021 году я только погружался в тему интеграции с маркетплейсами, наша компания зарегистрировала свой магазин на этой площадке, и мы как франчайзи фирмы «1С» стали продавать там коробочные решения: Бухгалтерию, Управление торговлей и прочее. Именно благодаря этому опыту мы смогли прочувствовать на себе специфику работы с маркетплейсами «от и до» и научились с этим справляться.

У нас была ситуация: поступил заказ на коробку 1С, но в нашем личном кабинете он по какой-то причине оказался в статусе «Отменен». Покупатель спрашивает: «Когда привезете?» и присылает скриншот из личного кабинета, где у него этот заказ на текущий момент находится в статусе «Активный». То есть статусы заказов синхронизируются странно и могут быть разными на стороне продавца и на стороне покупателя.

Причем по информации от одного из наших заказчиков оказалось, что с этой проблемой связана и мошенническая схема: поскольку в терминалах курьеров, которые развозят заказы или кладут их в постаматы, эти заказы тоже обновляются поздно, возможна ситуация, когда заказ уже был передан в доставку, а нечестный человек его может после этого отменить. При этом у курьера, который отвозит заказ или помещает его в постамат, статус все еще зеленый – он все еще «Передан в доставку» или «Готов к отгрузке».

А крайним в этой ситуации окажется сам продавец. Мало того, что он заплатил маркетплейсу комиссию за поездки и логистику, он потеряет товар и не получит свои деньги, потому что совершен возврат этих денег.

Сам маркетплейс уже в курсе этой проблемы и обещает, что ее устранят.

Но давайте не будем о плохом – подумаем о том, что можно сделать в этой ситуации.

Мы для себя пока нашли такое решение: если заказ уже был передан в доставку, а после этого отменен, мы выделяем такие заказы в системе – подсвечиваем их красным цветом и отправляем уведомление о проблеме. Это помогает бизнесу быстрее отреагировать – позвонить в техподдержку на горячую линию маркетплейса и сообщить: «Свяжитесь, пожалуйста, с курьером, чтобы он точно этот заказ не положил в постамат и не передал в руки покупателю, потому что так нельзя делать». Пока только такой костыльный метод решения.

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

Как выбрать модуль для интеграции с маркетплейсами внедренцу

Посмотрим на ситуацию с точки зрения внедренца-айтишника, который работает in-house, и получил от руководства задачу внедрить интеграцию с одним из маркетплейсов. На что стоит обратить внимание, если вы раньше с этим не сталкивались:

• Во-первых, важно понимать, что эта сфера активно развивается, и API маркетплейсов точно будут меняться – сейчас они меняются несколько раз в год. Причем раньше даже бывало так, что изменения API происходили без предупреждения – просто в какой-то день все просто переставало работать. На моей практике такого не встречалось, но мои знакомые несколько лет назад с такой бедой сталкивались. Сейчас, как правило, маркетплейсы заранее предупреждают в новостях, к чему готовиться: что с такой-то даты будет отключен такой-то метод.

• Если вы выбираете для себя модуль из существующих на рынке решений, обратите внимание, открыт ли у него код. Поскольку есть большая вероятность, что вам придется дорабатывать решение самостоятельно, чтобы учесть особенности вашей компании, лучше всего выбирать решение с полностью открытым кодом. Или с открытой реализацией API, но с закрытым модулем для лицензирования – с этим, возможно, придется смириться.

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

• Стоит понять, есть ли в этом модуле специфические функции, которые нужны при торговле на маркетплейсах именно вашей компании. Либо насколько сложно будет их в него добавить при доработке.

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

Минусы:

• Автоматическое обновление должно срабатывать не каждый раз – опция должна быть включаемой и выключаемой.

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

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

Плюсы:

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

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

На скриншоте иллюстрация, как это сделано в замечательном решении Synchrozon – это бесплатный стандартный модуль для интеграции 1С и маркетплейса Ozon. Здесь можно настроить – ставить или не ставить тестовые версии, нужно ли уведомлять об их выходе. Здесь нет автообновления, но при входе он вам скажет: «Уже выпущена новая версия, хотите установить?»

Мы считаем хорошей практикой выносить методы, которые обращаются к API маркетплейса, в отдельные внешние обработки. В этом подходе есть несколько преимуществ:

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

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

• Имея такие коннекторы, вы сможете встраивать интеграцию с маркетплейсами в любую конфигурацию 1С. В свою, в произвольную, УНФ, УПП, Управление торговлей 11 – в любой конфигурации они будут работать. А дальше уже дело за основным ядром решения.

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

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

• Нужно заранее понимать, во сколько обойдется владение модуля: нужно ли для него оплачивать подписку, или лицензия приобретается единовременно, сколько будет стоить обновление и поддержка на год.

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

• У некоторых решений лицензия продается по подписке и за подключение каждого кабинета нужно доплачивать отдельно. Для многих это критично, потому что бизнес часто ведет торговлю сразу от нескольких юридических лиц – с похожим ассортиментом или разными направлениями деятельности. Причем здесь, как правило, нужно продумывать ситуацию «на вырост», потому что желание продвигать различные виды своей продукции на маркетплейсах у бизнеса проявляются постепенно.

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

Как правило, крупные компании не ограничиваются только схемой работы FBO, при которой товары продаются со склада самого маркетплейса. Для товаров с нерегулярным спросом, крупногабаритной продукции или изделий под заказ обычно используется схема FBS – когда заказ пришел, вы собираете этот товар и передаете на сортировочный центр маркетплейса для доставки клиенту.

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

Например, мы сталкивались с ситуацией, когда у крупной компании, которая занимается импортом и дистрибуцией моторных масел, возникли сложности при работе с маркетплейсами по схеме FBS – они не могли позволить себе размещать на площадке больше 80 артикулов, потому что склад с таким большим объемом заказов не справлялся. Это усугублялось тем, что компания привыкла работать как классический B2B-бизнес – у них большое количество дилеров и активные отгрузки по всей стране. Если они сконцентрируются на маркетплейсах, где маржинальность сейчас не самая высокая, их основное направление – B2B-бизнес – начнет страдать.

Максимум производительности, который мы наблюдали при работе по схеме FBS – когда при поступлении заказов нужно собрать их на своем складе и передать в доставку на маркетплейс – это 180 заказов на одного сотрудника за полный 8-часовой рабочий день.

Какие методы можно предложить для оптимизации работы по схеме FBS? Я перечислю несколько возможностей, о которых знаем мы.

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

• Группировка поступающих заказов в один документ – удобно использовать для создания резервов товара на складе. Это вообще первая проблема, с которой обращаются продавцы к разработчикам модуля, они говорят: «Мы продаем товар со своего склада на нескольких маркетплейсах и не хотим, чтобы оказалось, что товара реально нет на складе». Нам нужно создавать резервы по поступающим заказам».
  Обычно такие резервы создаются документом «Заказ клиента». Причем их рекомендуется группировать – например, за определенный период или для определенного количества заказов. Создаете по каждому складу один документ «Заказ клиента» и делаете в нем эти резервы.
  Если создавать для каждого поступившего заказа отдельный документ «Заказ клиента», то перечень заказов быстро засоряется, становится неудобным для поиска и навигации. Некоторые пользуются альтернативным решением: скрывают такие заказы с маркетплейсов из общего списка заказов в системе, чтобы не перегружать интерфейс.

• Еще одна методика или подход к работе – собирать заказы группами по товарам. Например, у многих продавцов бывает ситуация, когда несколько наименований товаров по правилу Парето дают 80% всех продаж. Такие товары удобно собирать группами по очереди, выстраивая приоритеты по количеству заказов. Допустим, пришло 30 заказов на товар А. Собрали его. Дальше менеджер на складе переключается к товару Б. Собирает сколько-то штук этого товара и так далее, так далее.

Начинающим продавцам

С чего вообще начать тем, кто только начинает выходить на маркетплейсы?

Мы рекомендуем начать с Ozon:

• Там при регистрации магазина в 2023 году можно получить 5000 бонусов на продвижение в течение месяца (прим. ред. доклад от 11 октября 2023 года).

• У Ozon отличная документация для продавцов.

• Удобный интерфейс в ЛК.

• И мощные инструменты для продвижения товаров.

Что касается минусов, на которые стоит обратить внимание у Ozon:

• У этого маркетплейса достаточно высокая стоимость услуг.

• И в последнее время есть сложности с техподдержкой. Когда мы в 2021 году только начинали сотрудничать с Ozon, там были замечательные условия. Они бесплатно давали на первый месяц менеджера, которому можно было звонить и задавать любые вопросы. Сейчас коммуницировать с их техподдержкой стало гораздо сложнее – все ответы заскриптованы и практически невозможно дойти до реальных людей, принимающих решения.

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

И еще интересно, что сейчас на трех топовых маркетплейсах – Wildberries, Ozon, «Яндекс Маркет» – есть возможность подтянуть к себе карточки товаров через API. Это очень здорово, если у вас уже был какой-то один маркетплейс, и вы решаете расширяться.

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

На слайде показан счет, который Ozon выставил одному из наших клиентов всего за несколько дней. Обратите внимание, как много здесь строк – за что с вас, как продавца, будут брать средства. В основном, это услуги рекламы, размещение на складе и услуги кроссдокинга – когда Ozon пересылает ваши товары внутри складов.

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

Думаете, это все? Нет. Здесь еще и вторая часть есть, просто на один слайд все не уместилось.

Обратите внимание, что серым цветом здесь закрашена сумма заказов уже за вычетом комиссии Ozon. Т.е. помимо того, что за продажу каждого товара вы платите процент комиссии (он может составлять 10%, 12% или 17%), дополнительно оплачиваются остальные перечисленные здесь услуги.

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

Наиболее важные функциональные возможности для интеграции с маркетплейсами

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

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

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

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

• Рекомендуется придерживаться оборачиваемости от 30 до 60 дней по хранимым в данный момент товарам.

  • Если меньше, вы будете часто выходить в ситуацию, когда товар закончился.

  • Если больше 60 дней, вы будете много платить за хранение – с 1 сентября 2023 года Ozon и Wildberries синхронно значительно подняли стоимость хранения товаров.

• При расчете поставок по схеме FBO также полезно учитывать поставки «в пути» – те, которые вы уже сдали.

• И, как я уже сказал, важно учитывать потребности товаров в разрезе кластеров/регионов (например, у Ozon есть кластер «Сибирь»). Анализировать, какие товары хорошо продаются в конкретном кластере/регионе и в каком количестве их туда везти, чтобы хватило на выбранное вами количество дней – например, на 60.

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

А вот пример, как это можно реализовать для FBO в 1С.

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

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

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

Рекомендуем использовать ABC- и XYZ-анализ. Для этого есть стандартная функциональность Управление торговлей 11 – на ИТС есть статья, как настраивать ABC/XYZ-классификацию номенклатуры в типовой конфигурации.

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

Еще одна из самых обсуждаемых и «хайповых» тем в интеграции на маркетплейсах – парсинг цен. С одной стороны, сами маркетплейсы с этим активно борются, но при этом сами друг друга парсят – например, показывают вам уведомление о том, что цена на ваш продукт на другом маркетплейсе выше.

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

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

Знаю, что это костыль. Будет хорошо, если скажете, как это можно решить по-другому.

На скриншоте показано, как в Ozon выглядит ситуация, когда маркетплейс делает скидку ниже, чем розничная цена.

Важно регулярно следить за состоянием карточек ваших товаров – контролировать «слетевшие» поля, потому что иногда введенная в полях карточек информация внезапно пропадает.

В основном это происходит из-за смены формата – габариты могли хранить в миллиметрах, начали в сантиметрах. Или появляются новые требования к фото, и несоответствующие этим требованиям фото из карточки товара просто удаляются.

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

Этот контроль обязательно надо автоматизировать, но это и не отменяет ручную проверку людьми – сотрудниками.

На скриншоте приведен фрагмент нашей переписки с техподдержкой Ozon, где подтверждается, что да, фото удаляют, и когда удалили, никакого предупреждения вам не пришлют.

Еще один важный момент – иногда требуется реализовать сложное соответствие товаров, связку номенклатуры в 1С с карточками на маркетплейсе. Причем эта связка может быть «один ко многим» – в любую сторону.

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

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

Вопросы и ответы

Как вы решаете вопрос с финансовой отчетностью, которую предоставляет, например, Wildberries – у них очень сложная таблица с «кривыми» комиссиями. Какое решение, на ваш взгляд, самое лучшее ?

Я сейчас не буду делать никому рекламу – решений для этой задачи много, в том числе бесплатные. Например, для загрузки из Wildberries в документ «Отчет комиссионера о продажах» уже давно есть решение в типовой 1С:Бухгалтерии. Но какое решение лучшее – я не смогу сказать. Если в вашем случае это где-то криво работает, то надо погружаться в вопрос, смотреть, что и почему загружается не так.

Еще по поводу загрузок из Wildberries могу посоветовать Telegram-чат разработчиков по обсуждению API Wildberries. Там не только 1С-ники. Там постоянно обсуждаются различные вопросы, возникающие при работе с API маркетплейса.

Если приходит клиент с переписанной УТ 10 и хочет интеграцию с разными маркетплейсами, вы пишете под него какое-то персонифицированное решение или делаете какую-то надстройку над существующими модулями с разными маркетплейсами? Synchrozon и так далее?

В данном случае бы рассмотрел два способа, и по оптимальности параметров выбрал бы один из них:

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

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

А брать для этой цели Synchrozon, как мне кажется, неоптимально – там, на мой взгляд, не самый простой код для адаптации интерфейса на обычные формы.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.