Четыре бренда, один заказ: как мы собрали интернет-магазин HOTZ Global и связали его с 1С

Около 1100 товаров · около 270 цветов · четыре бренда · публичный запуск за пять месяцев

Всем привет, я Антон Фокин, CEO Qtim. Расскажу, как мы разработали сайт и интернет-магазин для HOTZ Global – производителя материалов для кузовного ремонта и покраски автомобилей.

Проект объединяет четыре бренда с разным позиционированием и визуальным языком. Покупатель видит их как части одной платформы: изучает ассортимент, подбирает цвет, читает техническую документацию, собирает корзину и оформляет доставку. За этим маршрутом работают синхронизация с 1С, резерв товара и двухстадийная оплата через ЮKassa.

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

До проекта: часть ассортимента была на сайте, остальное дилеры искали в PDF

До начала работ у HOTZ Global был общий информационный сайт с каталогом, который охватывал часть брендов, а дилеры брали данные о товарах оттуда или из PDF-таблиц: передать ассортимент так можно, поддерживать ежедневную работу – нет. Клиент хотел собрать весь ассортимент на своей площадке, постепенно переводить покупателей с маркетплейсов на сайт и дать дилерам одну точку с актуальными ценами, остатками и техническими материалами.

У каждого из четырёх брендов своя аудитория и подача. HOTZ ориентирован на премиальный сегмент и профессиональные мастерские, MEGAmix – на массовый авторемонт, «Краски на Тачки» – на молодых специалистов и самостоятельную работу, INACHE – на поклонников японских автомобилей и тюнинга. На одной витрине требовалось сохранить характер каждой линейки и при этом собрать общий путь к покупке.

Мы отвечали за исследование, UX/UI, дизайн-систему, фронтенд, бэкенд, административную панель, интеграции, тестирование и запуск. Команда клиента наполняла сайт контентом и товарами, а разработчики на его стороне дорабатывали API 1С.

Четыре разных бренда должны работать как один магазин

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

Мы собрали одну модель брендовой страницы: баннер, категории, информационные блоки, товарные подборки и комплексные решения. Сотрудник меняет состав и порядок блоков, тексты и изображения в соседних полях сразу на двух языках. Русский по умолчанию, английский добавляют отдельно; если перевода нет, страница показывает русский текст. Характер каждого бренда живёт в коде, поэтому лендинги остаются разными на общей структуре и данных.

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

Покупателю – выбор, мастеру – документы

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

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

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

Товар и цвет получили два равноправных входа в каталог: один пользователь ищет продукт, другой – оттенок по коду.

Цвет здесь не свойство товара, а точка входа в каталог

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

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

Рядом с каталогом лежит документация: техкарты с фильтром по брендам, а в карточке товара – TDS, MSDS и инструкция. «База знаний» собирает видео, статьи и PDF и делит их на базовый и PRO-уровни.

Все эти данные сотрудники ведут через одну панель: товары загружаются из XLSX, а контент – названия, описания, изображения, категории, свойства и SEO-поля – хранится на стороне сайта. Со сложным каталогом главная работа — не вёрстка, а модель данных: если связать цвет, товар и остаток верно, дизайн получает прочную опору вместо украшения поверх хрупкой конструкции.

Деньги списываются только после того, как 1С подтвердила товар

Оформление заказа связано сразу с тремя внешними контурами: СДЭК, 1С и ЮKassa. Последовательность здесь важна, потому что сайт должен подтвердить наличие товара до окончательного списания денег.

Сначала система создаёт черновик заказа и рассчитывает доставку СДЭК. Покупатель выбирает пункт выдачи, постамат или курьера. Затем сайт отправляет запрос на резерв товара в 1С. После успешного резерва ЮKassa авторизует платёж и удерживает сумму без окончательного списания. Система закрывает резерв продажей в 1С и только после этого списывает деньги. Неоплаченный черновик снимает резерв по тайм-ауту, дополнительная очистка идёт каждые десять минут.

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

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

Синхронизация защищает остатки от конфликтов

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

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

Для Яндекс Директа сайт формирует отдельный товарный фид. Полная версия пересобирается раз в час, а изменения проверяются каждые пять минут. Панель показывает статус, историю сборок, исключённые товары и позиции с неполными данными. Цена и наличие приходят из 1С, остальные поля — из базы сайта.

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

Публичную часть мы разработали на Nuxt 4, Vue 3 и TypeScript. Серверный рендеринг помогает поисковым системам получать содержимое страниц, а API-клиент генерируется из OpenAPI и остаётся синхронизированным с серверным контрактом.

На бэкенде работают NestJS 11, PostgreSQL, Redis и очереди BullMQ. Служебный интерфейс собран на AdminJS. Длительные операции — синхронизация с 1С, импорт каталога, обработка изображений и пересборка товарного фида — уходят в очереди и не задерживают пользовательские запросы. Проект разворачивается через GitLab CI, Docker и Traefik; миграции базы выполняются отдельным шагом деплоя.

Эта схема учитывает профиль проекта: у HOTZ Global много управляемого контента, сложный каталог, несколько внешних интеграций и заказ, состояние которого меняется сразу в нескольких системах.

Первый этап запустил витрину и полный путь заказа

Команде клиента первый этап дал один контур управления: около 1100 товаров и 270 оттенков на общей витрине, четыре брендовых лендинга из одной панели, цены и остатки из 1С каждые полчаса, загрузка каталога из XLSX примерно за минуту. Личный кабинет партнёра пока остаётся следующим этапом: для дилеров спроектирован отдельный кабинет с заявкой и входом, уровнями и историей скидок, магазинами, маркетинговыми материалами и заказами, на момент подготовки кейса готов дизайн, разработка ещё не началась, и сейчас публично работает только страница «Партнёрам» с формой заявки, которая передаёт лид в Bitrix24.

Следующий этап обсуждаем: он потребует отдельного API-контракта с 1С и подтверждения дилерских сценариев.

Один маршрут вместо четырёх сайтов

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

Если вам нужен интернет-магазин со сложным каталогом и интеграциями, напишите команде Qtim. Разберём задачу, предложим подход к разработке и оценим сроки.