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

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

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

Мы начали с тестирования гипотезы: будет ли этот функционал вообще востребован. Для этого запустили контур в полуручном режиме. На основном сайте Орматека настроили фиды (выгрузки данных в специальном формате), с помощью которых стали передавать товары в маркетплейсы. Особенность в том, что у каждого маркетплейса требования к формату данных свои — поэтому под каждый маркетплейс (Ozon, Wildberries, Яндекс Маркет и Aliexpress) фиды мы кастомизировали.

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

1. Прямая интеграция маркетплейсов с 1С. Решение — рабочее. Но настройкой 1С занималась отдельная служба заказчика, прогнозируемые сроки реализации силами которой были слишком долгими. На эти сроки влияли приоритеты на стороне заказчика: у специалистов по 1С очередь начинается с задач финансового отдела, бухгалтерии, розницы и только потом — сайта. На тот момент задач одной розницы было на полгода.
2. Передача заказов из маркетплейсов на сайт, а потом — с пометкой «Заказ Маркетплейс» — уже в 1С-ку. Этот путь оказался проще, так как у сайта есть кастомизированный обмен с 1С и мы знаем, какие данные по заказам и в каком формате отдавать.

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

С Ozon и Wildberries было сложнее. Штатный модуль Озона плохо ложился на бизнес-логику проекта: имел неподходящие нам методы и способы интеграции, не учитывал всех нужных нам параметров. Например, модуль передает адрес доставки одним полем, а в 1С нам нужно передавать отдельно страну, регион и прочее. Из-за этого пришлось написать отдельный запрос на получение городов из Ozon. Другая проблема озоновского модуля: его код — черный ящик, в котором ничего нельзя поменять.

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

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

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

• маркетплейс (стартовали с Озона, так как у него самое понятное API).
• данные текущего сайта (ID доставок, ID оплат, ID товаров) — всё то, что 1С уже знала как ID от маркетплейсов. Причем, для этого нам не нужно было ничего менять на стороне 1С.
• сама 1С.

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

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

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

Итого имеем:

• сайт Ormatek с товарами;
• несколько 1С;
• несколько маркетплейсов с разными API и форматами данных (Ozon, Wildberries, Яндекс Маркет, Мегамаркет и, добавившийся в 2025-м, казахский Kaspi);
• новую площадку обмена, которая должна это всё объединить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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