Ormatek: площадка для обмена заказами с маркетплейсами

Ormatek — наш давний клиент, с которым мы прошли огонь, воду, медные трубы, пандемию и её последствия: в 2021 году сделали из просто интернет-магазина маркетплейс. Развитием проекта мы занимаемся более 10 лет.

В 2020 году, когда случился коронавирус, начался бум онлайн-продаж. Наш клиент — Орматек — решил, что кроме развития своего сайта стоит выйти на сторонние маркетплейсы. Сделать это хотелось в рамках уже существующей IT-инфраструктуры, для чего требовалось автоматически передавать товары на торговые площадки, а заказы с маркетплейсов — в 1С.

Итого, нам нужно было:

1️⃣ Автоматизировать работу Ormatek с маркетплейсами – передавать товары и заказы между маркетплейсами и 1С.

2️⃣ Создать единый сервис обмена – объединить данные из разных 1С и маркетплейсов в одной системе.

3️⃣ Настроить гибкую интеграцию – учесть разные форматы данных, статусы заказов и бизнес-логику.

4️⃣ Оптимизировать бизнес-процессы – упростить работу менеджеров с заказами и повысить скорость обработки.

5️⃣ Обеспечить масштабируемость – подготовить сервис к работе с новыми маркетплейсами и брендами.

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

2️⃣ Выбор архитектуры и технологий – решили вынести обмен заказами в отдельный сервис на Laravel, сохранив выгрузку товаров через фиды.

3️⃣ Разработка и интеграция – подключили несколько маркетплейсов (Ozon, Wildberries, Яндекс.Маркет и др.), настроили передачу заказов и статусов в 1С.

4️⃣ Гибкая настройка и автоматизация – реализовали расшивочные таблицы, маппинг статусов, фильтры, автотесты и чат для работы с заказами.

5️⃣ Запуск, отладка и масштабирование – протестировали сервис, добавили графики, роли пользователей, аналитику и подготовили его к дальнейшему расширению.

Реализацию отдельного сервиса для работы с маркетплейсами мы начали с аналитики — подготовки протокола интеграции. У нас было два обмена с маркетплейсами: заказами и товарами. Товары мы решили оставить как есть — фидами. А вот для импорта заказов с маркетплейсов — разрабатывать новую систему.

Для импорта заказов с маркетплейсов нам требовалось смэтчить несколько систем:

• Маркетплейс – стартовали с Ozon, так как у него самое понятное API.

• Данные текущего сайта – ID доставок, ID оплат, ID товаров, которые 1С уже знала как ID от маркетплейсов (без необходимости вносить изменения в 1С).

• 1С – конечная система, в которую передавались заказы и статусы.

Для этого мы планировали разработать сервис на базе Laravel, который вел бы обмен заказами так же, как штатный в Битриксе (на котором работает сайт Орматека), причем с кастомизациями, которые уже много лет как реализованы на сайте.

Вот как это должно было работать:

• Площадка обмена получает заказы от маркетплейса и в разных форматах данных (JSON, XML), сохраняет их в свою базу данных в исходном виде и формирует из них представление в виде XML (CommerceML), чтобы передать в 1С.

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

• Пользователь может отменить заказ на маркетплейсе — информация об этом попадает на площадку обмена, но НЕ передается в 1С. Менеджер «Орматек» при этом получает уведомление об отмене заказа.

В теории всё здорово, но есть одно большое «но»: у «Орматек» несколько торговых марок и интернет-магазинов для разных ценовых сегментов — Райтон, Орматек, Proson и TSleep), у каждого из которых своя 1С. Внутри все 1С-ки устроены одинаково, вот только товары у всех — разные. Нашей задачей было сделать, чтобы для магазина каждой марки можно было легко настроить свой обмен с маркетплейсами.

Итого имеем:

• сайт Ormatek с товарами;

• несколько 1С;

• несколько маркетплейсов с разными API и форматами данных (Ozon, Wildberries, Яндекс Маркет, Мегамаркет и, добавившийся в 2025-м, казахский Kaspi);

• новую площадку обмена, которая должна это всё объединить.

Для гибкости и удобства мы выбрали для площадки обмена Laravel с админ-панелью Orchid. При этом от разработки отдельного фронтэнда площадки обмена на первом этапе решили отказаться, пустив менеджеров прямо в интерфейс админ-панели (естественно, настроив необходимые права доступа). А дальше — стали добавлять нужный нам функционал.

➤ Работа с данными из 1С

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

• задать на сайте логин и пароль для 1С, с которым она будет «стучаться» на сайт;

• создать пользователей, которые будут ей управлять, — чтобы менеджеры не видели лишнего и работали только со своими данными;

• задать префикс, с которым заказы будут улетать в 1С.

➤ Работа с данными от маркетплейсов

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

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

Из крутого, и пока крайне редко встречающегося в web-разработке: обмен с маркетплейсами мы покрыли автотестами — это позволяет автоматически и по расписанию проверять, что все работает как положено.

➤ Соединяем данные от 1С с данными от маркетплейсов

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

Расшивочная таблица — таблица, в которой организованы взаимосвязи между данными из нескольких источников, в данном случае — двух: 1С конкретного онлайн-магазина и конкретного маркетплейса.

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

Для каждой «расшивки» задаются:

• Маркетплейс и 1С из уже созданных на площадке обмена.

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

• client_id и api_key — нужны, чтобы маркетплейс «узнавал» площадку и делился с ней данными.

• Платежные системы и сервисы доставки.

• Данные для настройки обмена с 1С — различные xmlID контрагентов, договоров и пользователей, так как в 1С под них создаются индивидуальные сущности.

• Настройки уведомлений — можно задать адреса электронной почты, куда приходят уведомления по заказам от каждой пары 1С-маркетплейс.

Для всех маркетплейсов в 1С уже задана определенная платежная система, поэтому мы не стали «зашивать» её ID в код площадки обмена, а сделали настраиваемым параметром — на случай, если потребуется добавить дополнительные платежные системы. Аналогично поступили и с сервисами доставки. Реализовали это как выбор из отдельной таблицы, в которой также можно создать новые платежные системы или службы доставки.

Было важно сопоставить статусы заказов: в 1С они свои, у каждого маркетплейса — тоже свои. Поэтому мы реализовали гибкую настройку соответствий (так называемый «маппинг»), которая может меняться админом площадки. Например, на маркетплейсе у заказа есть статус «Готов к сборке» — если отдать его в 1С, как есть, она ничего не поймёт. С помощью маппинга мы заменяем этот статус на понятный ей «Выполняется». И наоборот: статус 1С-ки вроде «Запланирована доставка» для маркетплейса — китайская грамота, а вот «Готов к отгрузке» — уже другое дело.

➤ Дополнительный импорт данных

Когда стали обкатывать решение на практике, поняли, что иногда обычный ID заказа неинформативен для менеджера. Поэтому мы написали два дополнительных импорта данных из основного интернет-магазина Ormatek:

• импорт товаров — с его помощью получаем название товара, ID в каталоге и особый параметр xmlID, который нужен 1С для матчинга и идентификации;

• импорт местоположений — по каждому заказу в 1С также передается местоположение пользователя: от этого зависит бизнес-логика на стороне 1С.

➤ Мощные фильтры в списке заказов

Заказчик попросил сделать «такие же фильтры, как в Битриксе, или даже круче»: мы сделали. Заказы в списке можно фильтровать по любому параметру: от даты создания до даты окончания доставки. А ещё — гибко выводить нужные колонки и скрывать ненужные (причем, по каждому пользователю площадки обмена вывод этих колонок сохраняется) и управлять количеством строк, которые выводятся в таблице. В общем — всё, чтобы быстро найти конкретный заказ.

➤ Расчет дедлайна сборки заказа

Маркетплейсы отвечают за сроки доставки заказа перед покупателями, поэтому, если продавец сильно задерживается с поставкой, маркетплейс может или просто отменить заказ, или дать покупателю за это скидку (такая практика была, например, у Ozon в связи с санкциями). Дату, после которой сборка заказа будет отменена, маркетплейс передает на площадку обмена в параметре «дата окончания сборки».

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

➤ Кастомная детальная страница заказа с режимом отладки

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

1. Основное: ключевая информация с расшифровками каждого параметра — например, когда заказ был создан, изменен или обновлен.

2. «Отладка». Вкладка в режиме реального времени показывает, что именно пришло при обмене от маркетплейса и что ушло в 1С. Такой режим позволяет быстро найти ошибку — например, если маркетплейс не передал какие-то данные на площадку и из-за этого 1С не принимает заказ. Благодаря этому менеджеры зачастую могут справиться с проблемой сами, а не писать в техподдержку.

3. Журнал. Хранит историю действий по каждому заказу: когда тот был создан, выгружен в 1С, обновлен на маркетплейсе и в 1С. Это помогает отследить аномалии, если те случаются.

4. История изменений. Помогает отследить, кто из пользователей площадки и что именно редактировал в заказе.

5. Чат в маркетплейсе. При работе по схеме FBS, когда продавец сам отвечает за хранение и доставку товара, он часто общается с покупателями по деталям заказа в чате на самом маркетплейсе. Чтобы менеджеры «Орматека» не заходили на каждый маркетплейс для переписки с покупателями, мы вывели чат маркетплейса на отдельную вкладку детальной страницы заказа. Передача данных — отдельно по API. Такое решение серьезно упрощает и ускоряет работу.

6. Постоянная вкладка «Внутренний чат»: заказчик просил этот функционал, поскольку бывают случаи, когда сразу несколько человек «сидят» в системе и делают пометки — чат поможет не запутаться. Например, здесь менеджер может указать, что забрал заказ в работу, чтобы его не взял никто другой.

➤ Удобные графики

Раньше по каждому бренду отчёты создавались в 1С и выгружались в Excel — да, наглядно, но когда у тебя пачка маркетплейсов и четыре бренда — это долго и муторно. На площадке мы предусмотрели возможность строить графики в одном месте — так все заказы по всем брендам и по всем маркетплейсам как на ладони.

С графиками очень удобно работать — их можно настраивать настолько гибко, насколько это нужно маркетологу или его руководителю. Например, можно посмотреть все заказы с Озона за сентябрь — и это без всяких выгрузок из 1С и заполнения табличек в экселе.

Но если всё-таки очень нужны данные в формате CSV, есть опция выгрузки и фильтры: можно настроить, что именно нужно для отчета, за какой период и все ли заказы должны попасть в эту выгрузку.

➤ Гибко настраиваемые роли пользователей

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

➤ Генерация документации

Чтобы не писать документацию к коду отдельно, мы сразу аккуратно написали к нему комментарии (зачем нужны классы и что делают методы в этих классах), а затем — создали отдельный скрипт для генерации из всех комментариев к PHP-коду текстового документа.

Когда «Орматек» начнет работать с большим количеством маркетплейсов, мы планируем сделать рабочее место менеджера маркетплейса — отдельный личный кабинет, по сути — фронтенд к уже готовому функционалу.

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

✔ Разработали удобный сервис для автоматического обмена заказами с маркетплейсами.

✔ Реализовали гибкую интеграцию между несколькими 1С и торговыми площадками.

✔ Автоматизировали бизнес-процессы, повысив скорость обработки заказов.

✔ Создали масштабируемую систему, готовую к подключению новых маркетплейсов.