Кейс Rebase.market: строительный маркетплейс с двухбазовой архитектурой 1С

Кейс: Rebase.market — строительный маркетплейс с двухбазовой архитектурой 1С

О клиенте

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

Клиент хотел расширять бизнес и помогать партнёрам продавать больше. Так появилась идея собственного маркетплейса: площадки, где магазины размещают каталоги, передают остатки из своих учётных систем и получают онлайн-заказы — без затрат на собственный сайт и его администрирование.

Проект реализовывался в 2020–2021 годах. Сейчас сайт rebase.market недоступен, поэтому кейс описывает исторический опыт запуска.

С чем пришли

В 2020 году клиент пришёл с объёмным техническим заданием и старым сайтом на готовом решении, который требовалось переделать. Маркетплейс должен был закрыть четыре задачи:

1. Упростить партнёрскую программу. Расчёт поставок и комиссий, поиск и подключение новых магазинов — всё это велось вручную и с ростом числа партнёров становилось узким местом.
2. Дать партнёрам витрину в интернете. Магазин размещается на площадке как пункт выдачи заказов (ПВЗ) со своим каталогом и передаёт актуальные остатки из своей 1С.
3. Снять с локальных магазинов издержки выхода в онлайн. Для небольшой компании выход в интернет-торговлю означает новых людей: кто-то должен администрировать каталог, принимать и обрабатывать заказы. Эту нагрузку нужно было забрать на сторону площадки.
4. Дать покупателям из разных городов понятный сервис онлайн-покупки товаров партнёров.

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

Решение 1. Архитектура обменов: основная база 1С и её клон

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

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

• Основная база — только товары Rebase. Сотрудники клиента продолжают работать с ней так же, как до запуска портала.
• База-клон — получает актуальный каталог Rebase из основной базы; дополнительно менеджеры добавляют в неё продукцию ПВЗ по их заявкам. С клоном работают только в контексте развития маркетплейса.

Из базы-клона каталог выгружается на сайт, где для каждой позиции оформляется единая карточка — одинаковая для всех магазинов: название, фотографии, описание, характеристики. Уже к этой «эталонной» карточке привязываются предложения конкретных ПВЗ. Обмен между базами и сайтом идёт в формате стандартной выгрузки, и при необходимости товары Rebase в клоне всегда можно обновить из основной базы.

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

Решение 2. Инструмент сопоставления товаров

Главная проблема каталога мультивендорной площадки — разнобой в данных партнёров. Один и тот же товар, закупленный со склада Rebase, у разных магазинов существовал под разными названиями, артикулами и символьными кодами. Часть партнёров вела каталог в 1С, часть — в Excel. Позиция трёх цветов могла быть заведена как один товар или как три отдельных. Пускать такое разнообразие на портал было нельзя — каталог превратился бы в набор дублей.

Для нормализации разработали Инструмент сопоставления товаров (ИС) на базе 1С. Логика работы:

1. ПВЗ присылает свой каталог в шаблонном документе со столбцами артикулов и названий. Таблица загружается в инструмент, который «сращивает» её с актуальным каталогом маркетплейса из базы-клона.
2. Автопоиск находит совпадения по названиям или по артикулам; менеджер проверяет результат.
3. Оставшиеся позиции сопоставляются вручную — для этого в инструменте есть отбор и поиск. Если подходящего товара в каталоге Rebase нет, менеджер создаёт новую позицию прямо в процессе.
4. Для сопоставленных пар генерируются связывающие идентификаторы, которые отправляются в базу сайта. Портал записывает каждую позицию как торговое предложение конкретного ПВЗ к конкретному товару.
5. Большой каталог можно обрабатывать частями: файл таблицы скачивается и позже загружается обратно, а связки, уже записанные на сайт, доступны для просмотра.

В результате подключение каталога нового партнёра превратилось из многодневной ручной сверки в управляемую процедуру с автопоиском и проверкой результата.

Решение 3. Модуль синхронизации с 1С партнёров

После сопоставления каталогов ПВЗ должен регулярно передавать на портал цены и остатки собственной продукции. Заказчик просил решение, которое проще всего адаптировать под разные версии 1С будущих партнёров, поэтому разработали собственный модуль обмена с воспроизводимой архитектурой. Первой стала версия для «1С:Управление небольшой фирмой» на платформе 8.3.15 и выше.

В модуль заложены три режима:

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

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

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

Решение 4. Взаиморасчёты: комиссии и отчёт по продажам

Rebase не продаёт собственный товар конечному покупателю и поэтому не конкурирует с магазинами на своей площадке. Доход маркетплейса — комиссия с продаж продукции, которую партнёры закупают с центрального склада. Комиссии отличались не только по типу товара, но и по бренду, поэтому потребовалась гибкая настройка.

Комиссии устанавливаются заказчиком внутри базы-клона 1С. Для этого в неё добавлены:

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

Рассчитанные значения отправляются на сайт вместе с очередной выгрузкой. Портал собирает данные о продажах по каждому ПВЗ и формирует отчёт: общая сумма продаж каждого предложения, размер установленной комиссии, итоговое вознаграждение маркетплейса. Отчёт доступен обеим сторонам — менеджеру Rebase и представителю магазина в его личном кабинете продавца. Обе стороны видят одни и те же цифры, и взаимные расчёты перестают быть предметом споров.

Решение 5. Сайт в формате маркетплейса

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

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

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

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

Личный кабинет менеджера Rebase. Функции колл-центра по обработке заказов взяли на себя менеджеры площадки — для них сделан отдельный кабинет. Каждый сотрудник закреплён за конкретным городом и видит заказы всех ПВЗ этого города. Заказы сгруппированы по покупателю: внутри системы один большой заказ разбивается на отдельные по магазинам, но менеджер работает с общей картиной. Он подтверждает наличие товаров у продавцов и подтверждает заказ с покупателем по телефону.

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

Итоги проекта

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

Слой	Что сделано
Архитектура 1С	Две базы: основная (товары Rebase) и клон (каталог площадки с продукцией ПВЗ), стандартная выгрузка на сайт
Каталог	Инструмент сопоставления: автопоиск по названиям и артикулам, ручная доводка, связывающие идентификаторы, работа частями
Обмен с партнёрами	Модуль для 1С:УНФ 8.3.15+: частичная выгрузка, подписка на изменения «Номенклатуры», полный обмен вручную
Взаиморасчёты	Регистр сведений «Размеры комиссии», регламентное задание «Расчет комиссии номенклатуры», общий отчёт по продажам для обеих сторон
Сайт	Фильтры по городам и магазинам, таблица предложений в карточке, мульти-магазинная корзина, кабинеты менеджера Rebase и продавца

К середине 2021 года к порталу Rebase.market присоединилось уже 6 городов. Функционал продумывался и расширялся по ходу работы, а после запуска сотрудничество продолжилось: подключение новых партнёров, оптимизация проекта, разработка новых идей.

Типичные ошибки в похожих проектах

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

2. Смешивать собственный каталог и товары партнёров в одной учётной базе. Чужие позиции засоряют учёт, ломают отчётность и усложняют обмены. Разделение на основную базу и базу-клон позволяет держать собственный учёт нетронутым, а портал развивать независимо от него.

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

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

5. Комиссии в Excel или «в голове». Без автоматического расчёта и общего отчёта взаиморасчёты превращаются в ежемесячные сверки и споры с партнёрами. Комиссия должна считаться в учётной системе по заданной формуле, а отчёт по продажам и вознаграждению — быть одинаково виден обеим сторонам.

Заключение

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

Схема подходит проектам, где площадка объединяет локальных продавцов с разрозненными каталогами и разными учётными системами: строительные материалы и инструмент, автозапчасти, товары для дома и сада. Главное — закладывать нормализацию каталога и формат обмена ещё на этапе технического задания, а не после подключения первых партнёров.