[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1vo2j4la7xtnl":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":12,"headMarkup":13,"projectUrl":11,"bodyMd":14,"bodyHtml":15},"rebase-market","Кейс Rebase.market: строительный маркетплейс с двухбазовой архитектурой 1С",true,"01.06.2021 00:00:00","2026-07-18T20:34:06.075Z","sites","Запуск строительного маркетплейса Rebase.market: двухбазовая архитектура 1С, инструмент сопоставления каталогов партнёров, модуль обмена для 1С:УНФ, комиссии и 6 городов за год.",null,"\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F56e614251913.webp",[],"# Кейс: Rebase.market — строительный маркетплейс с двухбазовой архитектурой 1С\n\n## О клиенте\n\nRebase — поставщик строительного инструмента из Краснодара. До запуска маркетплейса компания работала по классической дистрибьюторской модели: поставляла инструмент в розничные магазины разных городов России по партнёрским ценам. У большинства партнёров не было собственных сайтов, поэтому торговля шла офлайн, а покупатель узнавал об ассортименте и остатках только в точке продаж.\n\nКлиент хотел расширять бизнес и помогать партнёрам продавать больше. Так появилась идея собственного маркетплейса: площадки, где магазины размещают каталоги, передают остатки из своих учётных систем и получают онлайн-заказы — без затрат на собственный сайт и его администрирование.\n\nПроект реализовывался в 2020–2021 годах. Сейчас сайт rebase.market недоступен, поэтому кейс описывает исторический опыт запуска.\n\n![Каталог Rebase.market — фильтры по городам и магазинам, поиск и карточки товаров](\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F56e614251913.webp)\n\n## С чем пришли\n\nВ 2020 году клиент пришёл с объёмным техническим заданием и старым сайтом на готовом решении, который требовалось переделать. Маркетплейс должен был закрыть четыре задачи:\n\n1. **Упростить партнёрскую программу.** Расчёт поставок и комиссий, поиск и подключение новых магазинов — всё это велось вручную и с ростом числа партнёров становилось узким местом.\n2. **Дать партнёрам витрину в интернете.** Магазин размещается на площадке как пункт выдачи заказов (ПВЗ) со своим каталогом и передаёт актуальные остатки из своей 1С.\n3. **Снять с локальных магазинов издержки выхода в онлайн.** Для небольшой компании выход в интернет-торговлю означает новых людей: кто-то должен администрировать каталог, принимать и обрабатывать заказы. Эту нагрузку нужно было забрать на сторону площадки.\n4. **Дать покупателям из разных городов понятный сервис** онлайн-покупки товаров партнёров.\n\nПо итогам проработки ТЗ сформировали план из шести этапов: проектирование интеграции с 1С, инструмент сопоставления товаров, синхронизация сайта с двумя базами 1С заказчика, модуль обмена для 1С партнёров, функционал взаиморасчётов и доработка сайта. Ниже — пять функциональных слоёв решения.\n\n## Решение 1. Архитектура обменов: основная база 1С и её клон\n\nЯдром системы стала база 1С центрального склада Rebase — в ней хранятся только товары заказчика. Изначально планировалось связать обменом только её: партнёры продавали бы на площадке исключительно то, что закупают у Rebase, и собственной базы клиента для этого хватало.\n\nВ процессе проработки ТЗ появилась идея позволить партнёрам размещать на маркетплейсе и собственную продукцию. Чтобы не смешивать основной каталог клиента с чужими товарами, базу разделили на две:\n\n- **Основная база** — только товары Rebase. Сотрудники клиента продолжают работать с ней так же, как до запуска портала.\n- **База-клон** — получает актуальный каталог Rebase из основной базы; дополнительно менеджеры добавляют в неё продукцию ПВЗ по их заявкам. С клоном работают только в контексте развития маркетплейса.\n\nИз базы-клона каталог выгружается на сайт, где для каждой позиции оформляется единая карточка — одинаковая для всех магазинов: название, фотографии, описание, характеристики. Уже к этой «эталонной» карточке привязываются предложения конкретных ПВЗ. Обмен между базами и сайтом идёт в формате стандартной выгрузки, и при необходимости товары Rebase в клоне всегда можно обновить из основной базы.\n\nТакой подход полностью снял с партнёров работу с каталогом: магазину не нужно описывать и фотографировать товары, а покупатель видит одинаково оформленные карточки независимо от продавца. Если партнёр хочет продавать товар, которого нет в ассортименте Rebase, менеджеры заводят его в базе-клоне и оформляют карточку — после этого к позиции могут привязаться и другие ПВЗ.\n\n## Решение 2. Инструмент сопоставления товаров\n\nГлавная проблема каталога мультивендорной площадки — разнобой в данных партнёров. Один и тот же товар, закупленный со склада Rebase, у разных магазинов существовал под разными названиями, артикулами и символьными кодами. Часть партнёров вела каталог в 1С, часть — в Excel. Позиция трёх цветов могла быть заведена как один товар или как три отдельных. Пускать такое разнообразие на портал было нельзя — каталог превратился бы в набор дублей.\n\nДля нормализации разработали Инструмент сопоставления товаров (ИС) на базе 1С. Логика работы:\n\n1. ПВЗ присылает свой каталог в шаблонном документе со столбцами артикулов и названий. Таблица загружается в инструмент, который «сращивает» её с актуальным каталогом маркетплейса из базы-клона.\n2. Автопоиск находит совпадения по названиям или по артикулам; менеджер проверяет результат.\n3. Оставшиеся позиции сопоставляются вручную — для этого в инструменте есть отбор и поиск. Если подходящего товара в каталоге Rebase нет, менеджер создаёт новую позицию прямо в процессе.\n4. Для сопоставленных пар генерируются связывающие идентификаторы, которые отправляются в базу сайта. Портал записывает каждую позицию как торговое предложение конкретного ПВЗ к конкретному товару.\n5. Большой каталог можно обрабатывать частями: файл таблицы скачивается и позже загружается обратно, а связки, уже записанные на сайт, доступны для просмотра.\n\n![Инструмент сопоставления товаров — связывание каталога ПВЗ с каталогом площадки](\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F9e33a75b6ca7.webp)\n\nВ результате подключение каталога нового партнёра превратилось из многодневной ручной сверки в управляемую процедуру с автопоиском и проверкой результата.\n\n## Решение 3. Модуль синхронизации с 1С партнёров\n\nПосле сопоставления каталогов ПВЗ должен регулярно передавать на портал цены и остатки собственной продукции. Заказчик просил решение, которое проще всего адаптировать под разные версии 1С будущих партнёров, поэтому разработали собственный модуль обмена с воспроизводимой архитектурой. Первой стала версия для «1С:Управление небольшой фирмой» на платформе 8.3.15 и выше.\n\nВ модуль заложены три режима:\n\n- **периодическая частичная выгрузка** — на сайт уходят только изменившиеся данные, а не весь справочник;\n- **подписка на изменения справочника «Номенклатура»** — обмен запускается по событию, а не только по расписанию;\n- **полный обмен в ручном режиме** — для первичной загрузки и восстановления после сбоев.\n\nДля обмена модуль формирует компактный файл данных: связывающие идентификаторы предложений, цены и количество остатков. Сайт находит товары по идентификаторам и записывает свежие значения в торговые предложения. В товарах ПВЗ фиксируются даты последнего изменения цены и остатков — покупатель видит, насколько актуальна информация по конкретному магазину.\n\nФормат выбран под ограничения реальной эксплуатации. Минимальный объём данных снижает нагрузку и на сайт, и на учётную систему партнёра — портал выдерживает большой поток обменов от множества ПВЗ. А сформировать такую выгрузку можно практически в любой версии 1С, что и требовалось для подключения новых городов.\n\n## Решение 4. Взаиморасчёты: комиссии и отчёт по продажам\n\nRebase не продаёт собственный товар конечному покупателю и поэтому не конкурирует с магазинами на своей площадке. Доход маркетплейса — комиссия с продаж продукции, которую партнёры закупают с центрального склада. Комиссии отличались не только по типу товара, но и по бренду, поэтому потребовалась гибкая настройка.\n\nКомиссии устанавливаются заказчиком внутри базы-клона 1С. Для этого в неё добавлены:\n\n- **регистр сведений «Размеры комиссии»** — хранит раздел каталога, бренд и значение комиссии;\n- **регламентное задание «Расчет комиссии номенклатуры»** — по расписанию проверяет каждый товар на вхождение в заданную категорию или бренд, рассчитывает комиссию по формуле и записывает её в отдельное свойство номенклатуры;\n- **выгрузка сводной таблицы** с информацией о назначенных комиссиях.\n\nРассчитанные значения отправляются на сайт вместе с очередной выгрузкой. Портал собирает данные о продажах по каждому ПВЗ и формирует отчёт: общая сумма продаж каждого предложения, размер установленной комиссии, итоговое вознаграждение маркетплейса. Отчёт доступен обеим сторонам — менеджеру Rebase и представителю магазина в его личном кабинете продавца. Обе стороны видят одни и те же цифры, и взаимные расчёты перестают быть предметом споров.\n\n## Решение 5. Сайт в формате маркетплейса\n\nРабота над порталом шла с самого старта проекта и параллельно с разработкой 1С-части — функционал сторон был неразрывно связан. Опустим мелкие правки и перечислим главные изменения.\n\n**Каталог с фильтрами по городам и магазинам.** Покупатель отбирает предложения по наличию в конкретном городе или в конкретном магазине. В списке выводится наименьшая цена позиции среди всех вариантов, доступных у разных ПВЗ.\n\n**Карточка товара с таблицей предложений.** К стандартным блокам информации добавилась таблица: название и адрес каждого магазина, где продаётся товар, его цена и остаток там, срок получения при заказе.\n\n![Карточка товара — вкладка «Цены» с предложениями магазинов, наличием и сроками](\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F35d8718afe98.webp)\n\n**Мульти-магазинная корзина.** Покупателю доступен заказ из нескольких ПВЗ одновременно, и это отражено визуально: видно, товары какого магазина лежат в корзине. Позицию можно перенести из одного ПВЗ в другой — например, туда, где она дешевле или ближе. Заказ оформляется сразу на всё содержимое корзины или только на выборку одного продавца. Скидки, промокоды и покупка за бонусы сохранились.\n\n![Мульти-магазинная корзина — заказ разделён по магазинам «ПРОРАБ» и «Строитель»](\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002Fdaaf1c720c5a.webp)\n\n**Личный кабинет менеджера Rebase.** Функции колл-центра по обработке заказов взяли на себя менеджеры площадки — для них сделан отдельный кабинет. Каждый сотрудник закреплён за конкретным городом и видит заказы всех ПВЗ этого города. Заказы сгруппированы по покупателю: внутри системы один большой заказ разбивается на отдельные по магазинам, но менеджер работает с общей картиной. Он подтверждает наличие товаров у продавцов и подтверждает заказ с покупателем по телефону.\n\n**Личный кабинет ПВЗ.** Партнёр настраивает свой магазин: время работы, информация о доставке и самовывозе, контакты. Администратор ПВЗ добавляет на сайт своих менеджеров и закрепляет за ними доступ к отдельным функциям: редактирование магазина, отчёт по продажам и комиссиям, просмотр и обработка заказов. В списке заказов сотрудники магазина подтверждают наличие товаров и видят информацию о покупателе и способе получения.\n\n## Итоги проекта\n\nВсе задуманные заказчиком механизмы были реализованы и запущены:\n\n| Слой | Что сделано |\n|---|---|\n| Архитектура 1С | Две базы: основная (товары Rebase) и клон (каталог площадки с продукцией ПВЗ), стандартная выгрузка на сайт |\n| Каталог | Инструмент сопоставления: автопоиск по названиям и артикулам, ручная доводка, связывающие идентификаторы, работа частями |\n| Обмен с партнёрами | Модуль для 1С:УНФ 8.3.15+: частичная выгрузка, подписка на изменения «Номенклатуры», полный обмен вручную |\n| Взаиморасчёты | Регистр сведений «Размеры комиссии», регламентное задание «Расчет комиссии номенклатуры», общий отчёт по продажам для обеих сторон |\n| Сайт | Фильтры по городам и магазинам, таблица предложений в карточке, мульти-магазинная корзина, кабинеты менеджера Rebase и продавца |\n\nК середине 2021 года к порталу Rebase.market присоединилось уже 6 городов. Функционал продумывался и расширялся по ходу работы, а после запуска сотрудничество продолжилось: подключение новых партнёров, оптимизация проекта, разработка новых идей.\n\n## Типичные ошибки в похожих проектах\n\n1. **Выгружать каталоги партнёров «как есть».** Без нормализации на площадке появляются десятки дублей одного товара с разными названиями и артикулами: покупатель не может сравнить предложения, поиск перестаёт работать. Слой сопоставления между каталогами партнёров и витриной — обязательная часть мультивендорного проекта, а не опция.\n\n2. **Смешивать собственный каталог и товары партнёров в одной учётной базе.** Чужие позиции засоряют учёт, ломают отчётность и усложняют обмены. Разделение на основную базу и базу-клон позволяет держать собственный учёт нетронутым, а портал развивать независимо от него.\n\n3. **Односторонняя интеграция.** Каталог выгрузили на сайт один раз, а цены и остатки обновляются вручную или раз в сутки большим файлом. Итог — заказы на отсутствующий товар, отмены и потеря доверия покупателей. Обмен должен быть событийным и частичным: изменился остаток в 1С — изменение ушло на сайт.\n\n4. **Жёсткая привязка к одной конфигурации 1С партнёров.** У каждого нового продавца своя версия учётной системы со своими доработками. Модуль, написанный под одну конфигурацию без компактного универсального формата обмена, придётся переписывать под каждого подключаемого партнёра.\n\n5. **Комиссии в Excel или «в голове».** Без автоматического расчёта и общего отчёта взаиморасчёты превращаются в ежемесячные сверки и споры с партнёрами. Комиссия должна считаться в учётной системе по заданной формуле, а отчёт по продажам и вознаграждению — быть одинаково виден обеим сторонам.\n\n## Заключение\n\nRebase.market — пример того, как дистрибьютор превращается в оператора маркетплейса, не ломая сложившуюся партнёрскую сеть. Критичными оказались три вещи: двухбазовая архитектура, отделившая собственный учёт клиента от каталога площадки; инструмент сопоставления, снявший с партнёров работу с каталогом; и модуль обмена с компактным форматом данных, который воспроизводится под разные версии 1С.\n\nСхема подходит проектам, где площадка объединяет локальных продавцов с разрозненными каталогами и разными учётными системами: строительные материалы и инструмент, автозапчасти, товары для дома и сада. Главное — закладывать нормализацию каталога и формат обмена ещё на этапе технического задания, а не после подключения первых партнёров.\n","\u003Ch1>Кейс: Rebase.market — строительный маркетплейс с двухбазовой архитектурой 1С\u003C\u002Fh1>\n\u003Ch2>О клиенте\u003C\u002Fh2>\n\u003Cp>Rebase — поставщик строительного инструмента из Краснодара. До запуска маркетплейса компания работала по классической дистрибьюторской модели: поставляла инструмент в розничные магазины разных городов России по партнёрским ценам. У большинства партнёров не было собственных сайтов, поэтому торговля шла офлайн, а покупатель узнавал об ассортименте и остатках только в точке продаж.\u003C\u002Fp>\n\u003Cp>Клиент хотел расширять бизнес и помогать партнёрам продавать больше. Так появилась идея собственного маркетплейса: площадки, где магазины размещают каталоги, передают остатки из своих учётных систем и получают онлайн-заказы — без затрат на собственный сайт и его администрирование.\u003C\u002Fp>\n\u003Cp>Проект реализовывался в 2020–2021 годах. Сейчас сайт rebase.market недоступен, поэтому кейс описывает исторический опыт запуска.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F56e614251913.webp\" alt=\"Каталог Rebase.market — фильтры по городам и магазинам, поиск и карточки товаров\">\u003C\u002Fp>\n\u003Ch2>С чем пришли\u003C\u002Fh2>\n\u003Cp>В 2020 году клиент пришёл с объёмным техническим заданием и старым сайтом на готовом решении, который требовалось переделать. Маркетплейс должен был закрыть четыре задачи:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Упростить партнёрскую программу.\u003C\u002Fstrong> Расчёт поставок и комиссий, поиск и подключение новых магазинов — всё это велось вручную и с ростом числа партнёров становилось узким местом.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Дать партнёрам витрину в интернете.\u003C\u002Fstrong> Магазин размещается на площадке как пункт выдачи заказов (ПВЗ) со своим каталогом и передаёт актуальные остатки из своей 1С.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Снять с локальных магазинов издержки выхода в онлайн.\u003C\u002Fstrong> Для небольшой компании выход в интернет-торговлю означает новых людей: кто-то должен администрировать каталог, принимать и обрабатывать заказы. Эту нагрузку нужно было забрать на сторону площадки.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Дать покупателям из разных городов понятный сервис\u003C\u002Fstrong> онлайн-покупки товаров партнёров.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>По итогам проработки ТЗ сформировали план из шести этапов: проектирование интеграции с 1С, инструмент сопоставления товаров, синхронизация сайта с двумя базами 1С заказчика, модуль обмена для 1С партнёров, функционал взаиморасчётов и доработка сайта. Ниже — пять функциональных слоёв решения.\u003C\u002Fp>\n\u003Ch2>Решение 1. Архитектура обменов: основная база 1С и её клон\u003C\u002Fh2>\n\u003Cp>Ядром системы стала база 1С центрального склада Rebase — в ней хранятся только товары заказчика. Изначально планировалось связать обменом только её: партнёры продавали бы на площадке исключительно то, что закупают у Rebase, и собственной базы клиента для этого хватало.\u003C\u002Fp>\n\u003Cp>В процессе проработки ТЗ появилась идея позволить партнёрам размещать на маркетплейсе и собственную продукцию. Чтобы не смешивать основной каталог клиента с чужими товарами, базу разделили на две:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Основная база\u003C\u002Fstrong> — только товары Rebase. Сотрудники клиента продолжают работать с ней так же, как до запуска портала.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>База-клон\u003C\u002Fstrong> — получает актуальный каталог Rebase из основной базы; дополнительно менеджеры добавляют в неё продукцию ПВЗ по их заявкам. С клоном работают только в контексте развития маркетплейса.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Из базы-клона каталог выгружается на сайт, где для каждой позиции оформляется единая карточка — одинаковая для всех магазинов: название, фотографии, описание, характеристики. Уже к этой «эталонной» карточке привязываются предложения конкретных ПВЗ. Обмен между базами и сайтом идёт в формате стандартной выгрузки, и при необходимости товары Rebase в клоне всегда можно обновить из основной базы.\u003C\u002Fp>\n\u003Cp>Такой подход полностью снял с партнёров работу с каталогом: магазину не нужно описывать и фотографировать товары, а покупатель видит одинаково оформленные карточки независимо от продавца. Если партнёр хочет продавать товар, которого нет в ассортименте Rebase, менеджеры заводят его в базе-клоне и оформляют карточку — после этого к позиции могут привязаться и другие ПВЗ.\u003C\u002Fp>\n\u003Ch2>Решение 2. Инструмент сопоставления товаров\u003C\u002Fh2>\n\u003Cp>Главная проблема каталога мультивендорной площадки — разнобой в данных партнёров. Один и тот же товар, закупленный со склада Rebase, у разных магазинов существовал под разными названиями, артикулами и символьными кодами. Часть партнёров вела каталог в 1С, часть — в Excel. Позиция трёх цветов могла быть заведена как один товар или как три отдельных. Пускать такое разнообразие на портал было нельзя — каталог превратился бы в набор дублей.\u003C\u002Fp>\n\u003Cp>Для нормализации разработали Инструмент сопоставления товаров (ИС) на базе 1С. Логика работы:\u003C\u002Fp>\n\u003Col>\n\u003Cli>ПВЗ присылает свой каталог в шаблонном документе со столбцами артикулов и названий. Таблица загружается в инструмент, который «сращивает» её с актуальным каталогом маркетплейса из базы-клона.\u003C\u002Fli>\n\u003Cli>Автопоиск находит совпадения по названиям или по артикулам; менеджер проверяет результат.\u003C\u002Fli>\n\u003Cli>Оставшиеся позиции сопоставляются вручную — для этого в инструменте есть отбор и поиск. Если подходящего товара в каталоге Rebase нет, менеджер создаёт новую позицию прямо в процессе.\u003C\u002Fli>\n\u003Cli>Для сопоставленных пар генерируются связывающие идентификаторы, которые отправляются в базу сайта. Портал записывает каждую позицию как торговое предложение конкретного ПВЗ к конкретному товару.\u003C\u002Fli>\n\u003Cli>Большой каталог можно обрабатывать частями: файл таблицы скачивается и позже загружается обратно, а связки, уже записанные на сайт, доступны для просмотра.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F9e33a75b6ca7.webp\" alt=\"Инструмент сопоставления товаров — связывание каталога ПВЗ с каталогом площадки\">\u003C\u002Fp>\n\u003Cp>В результате подключение каталога нового партнёра превратилось из многодневной ручной сверки в управляемую процедуру с автопоиском и проверкой результата.\u003C\u002Fp>\n\u003Ch2>Решение 3. Модуль синхронизации с 1С партнёров\u003C\u002Fh2>\n\u003Cp>После сопоставления каталогов ПВЗ должен регулярно передавать на портал цены и остатки собственной продукции. Заказчик просил решение, которое проще всего адаптировать под разные версии 1С будущих партнёров, поэтому разработали собственный модуль обмена с воспроизводимой архитектурой. Первой стала версия для «1С:Управление небольшой фирмой» на платформе 8.3.15 и выше.\u003C\u002Fp>\n\u003Cp>В модуль заложены три режима:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>периодическая частичная выгрузка\u003C\u002Fstrong> — на сайт уходят только изменившиеся данные, а не весь справочник;\u003C\u002Fli>\n\u003Cli>\u003Cstrong>подписка на изменения справочника «Номенклатура»\u003C\u002Fstrong> — обмен запускается по событию, а не только по расписанию;\u003C\u002Fli>\n\u003Cli>\u003Cstrong>полный обмен в ручном режиме\u003C\u002Fstrong> — для первичной загрузки и восстановления после сбоев.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Для обмена модуль формирует компактный файл данных: связывающие идентификаторы предложений, цены и количество остатков. Сайт находит товары по идентификаторам и записывает свежие значения в торговые предложения. В товарах ПВЗ фиксируются даты последнего изменения цены и остатков — покупатель видит, насколько актуальна информация по конкретному магазину.\u003C\u002Fp>\n\u003Cp>Формат выбран под ограничения реальной эксплуатации. Минимальный объём данных снижает нагрузку и на сайт, и на учётную систему партнёра — портал выдерживает большой поток обменов от множества ПВЗ. А сформировать такую выгрузку можно практически в любой версии 1С, что и требовалось для подключения новых городов.\u003C\u002Fp>\n\u003Ch2>Решение 4. Взаиморасчёты: комиссии и отчёт по продажам\u003C\u002Fh2>\n\u003Cp>Rebase не продаёт собственный товар конечному покупателю и поэтому не конкурирует с магазинами на своей площадке. Доход маркетплейса — комиссия с продаж продукции, которую партнёры закупают с центрального склада. Комиссии отличались не только по типу товара, но и по бренду, поэтому потребовалась гибкая настройка.\u003C\u002Fp>\n\u003Cp>Комиссии устанавливаются заказчиком внутри базы-клона 1С. Для этого в неё добавлены:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>регистр сведений «Размеры комиссии»\u003C\u002Fstrong> — хранит раздел каталога, бренд и значение комиссии;\u003C\u002Fli>\n\u003Cli>\u003Cstrong>регламентное задание «Расчет комиссии номенклатуры»\u003C\u002Fstrong> — по расписанию проверяет каждый товар на вхождение в заданную категорию или бренд, рассчитывает комиссию по формуле и записывает её в отдельное свойство номенклатуры;\u003C\u002Fli>\n\u003Cli>\u003Cstrong>выгрузка сводной таблицы\u003C\u002Fstrong> с информацией о назначенных комиссиях.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Рассчитанные значения отправляются на сайт вместе с очередной выгрузкой. Портал собирает данные о продажах по каждому ПВЗ и формирует отчёт: общая сумма продаж каждого предложения, размер установленной комиссии, итоговое вознаграждение маркетплейса. Отчёт доступен обеим сторонам — менеджеру Rebase и представителю магазина в его личном кабинете продавца. Обе стороны видят одни и те же цифры, и взаимные расчёты перестают быть предметом споров.\u003C\u002Fp>\n\u003Ch2>Решение 5. Сайт в формате маркетплейса\u003C\u002Fh2>\n\u003Cp>Работа над порталом шла с самого старта проекта и параллельно с разработкой 1С-части — функционал сторон был неразрывно связан. Опустим мелкие правки и перечислим главные изменения.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Каталог с фильтрами по городам и магазинам.\u003C\u002Fstrong> Покупатель отбирает предложения по наличию в конкретном городе или в конкретном магазине. В списке выводится наименьшая цена позиции среди всех вариантов, доступных у разных ПВЗ.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Карточка товара с таблицей предложений.\u003C\u002Fstrong> К стандартным блокам информации добавилась таблица: название и адрес каждого магазина, где продаётся товар, его цена и остаток там, срок получения при заказе.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002F35d8718afe98.webp\" alt=\"Карточка товара — вкладка «Цены» с предложениями магазинов, наличием и сроками\">\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Мульти-магазинная корзина.\u003C\u002Fstrong> Покупателю доступен заказ из нескольких ПВЗ одновременно, и это отражено визуально: видно, товары какого магазина лежат в корзине. Позицию можно перенести из одного ПВЗ в другой — например, туда, где она дешевле или ближе. Заказ оформляется сразу на всё содержимое корзины или только на выборку одного продавца. Скидки, промокоды и покупка за бонусы сохранились.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Frebase-market\u002Fassets\u002Fdaaf1c720c5a.webp\" alt=\"Мульти-магазинная корзина — заказ разделён по магазинам «ПРОРАБ» и «Строитель»\">\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Личный кабинет менеджера Rebase.\u003C\u002Fstrong> Функции колл-центра по обработке заказов взяли на себя менеджеры площадки — для них сделан отдельный кабинет. Каждый сотрудник закреплён за конкретным городом и видит заказы всех ПВЗ этого города. Заказы сгруппированы по покупателю: внутри системы один большой заказ разбивается на отдельные по магазинам, но менеджер работает с общей картиной. Он подтверждает наличие товаров у продавцов и подтверждает заказ с покупателем по телефону.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Личный кабинет ПВЗ.\u003C\u002Fstrong> Партнёр настраивает свой магазин: время работы, информация о доставке и самовывозе, контакты. Администратор ПВЗ добавляет на сайт своих менеджеров и закрепляет за ними доступ к отдельным функциям: редактирование магазина, отчёт по продажам и комиссиям, просмотр и обработка заказов. В списке заказов сотрудники магазина подтверждают наличие товаров и видят информацию о покупателе и способе получения.\u003C\u002Fp>\n\u003Ch2>Итоги проекта\u003C\u002Fh2>\n\u003Cp>Все задуманные заказчиком механизмы были реализованы и запущены:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Слой\u003C\u002Fth>\n\u003Cth>Что сделано\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Архитектура 1С\u003C\u002Ftd>\n\u003Ctd>Две базы: основная (товары Rebase) и клон (каталог площадки с продукцией ПВЗ), стандартная выгрузка на сайт\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Каталог\u003C\u002Ftd>\n\u003Ctd>Инструмент сопоставления: автопоиск по названиям и артикулам, ручная доводка, связывающие идентификаторы, работа частями\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Обмен с партнёрами\u003C\u002Ftd>\n\u003Ctd>Модуль для 1С:УНФ 8.3.15+: частичная выгрузка, подписка на изменения «Номенклатуры», полный обмен вручную\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Взаиморасчёты\u003C\u002Ftd>\n\u003Ctd>Регистр сведений «Размеры комиссии», регламентное задание «Расчет комиссии номенклатуры», общий отчёт по продажам для обеих сторон\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Сайт\u003C\u002Ftd>\n\u003Ctd>Фильтры по городам и магазинам, таблица предложений в карточке, мульти-магазинная корзина, кабинеты менеджера Rebase и продавца\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>К середине 2021 года к порталу Rebase.market присоединилось уже 6 городов. Функционал продумывался и расширялся по ходу работы, а после запуска сотрудничество продолжилось: подключение новых партнёров, оптимизация проекта, разработка новых идей.\u003C\u002Fp>\n\u003Ch2>Типичные ошибки в похожих проектах\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\n\u003Cp>\u003Cstrong>Выгружать каталоги партнёров «как есть».\u003C\u002Fstrong> Без нормализации на площадке появляются десятки дублей одного товара с разными названиями и артикулами: покупатель не может сравнить предложения, поиск перестаёт работать. Слой сопоставления между каталогами партнёров и витриной — обязательная часть мультивендорного проекта, а не опция.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Смешивать собственный каталог и товары партнёров в одной учётной базе.\u003C\u002Fstrong> Чужие позиции засоряют учёт, ломают отчётность и усложняют обмены. Разделение на основную базу и базу-клон позволяет держать собственный учёт нетронутым, а портал развивать независимо от него.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Односторонняя интеграция.\u003C\u002Fstrong> Каталог выгрузили на сайт один раз, а цены и остатки обновляются вручную или раз в сутки большим файлом. Итог — заказы на отсутствующий товар, отмены и потеря доверия покупателей. Обмен должен быть событийным и частичным: изменился остаток в 1С — изменение ушло на сайт.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Жёсткая привязка к одной конфигурации 1С партнёров.\u003C\u002Fstrong> У каждого нового продавца своя версия учётной системы со своими доработками. Модуль, написанный под одну конфигурацию без компактного универсального формата обмена, придётся переписывать под каждого подключаемого партнёра.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>Комиссии в Excel или «в голове».\u003C\u002Fstrong> Без автоматического расчёта и общего отчёта взаиморасчёты превращаются в ежемесячные сверки и споры с партнёрами. Комиссия должна считаться в учётной системе по заданной формуле, а отчёт по продажам и вознаграждению — быть одинаково виден обеим сторонам.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Заключение\u003C\u002Fh2>\n\u003Cp>Rebase.market — пример того, как дистрибьютор превращается в оператора маркетплейса, не ломая сложившуюся партнёрскую сеть. Критичными оказались три вещи: двухбазовая архитектура, отделившая собственный учёт клиента от каталога площадки; инструмент сопоставления, снявший с партнёров работу с каталогом; и модуль обмена с компактным форматом данных, который воспроизводится под разные версии 1С.\u003C\u002Fp>\n\u003Cp>Схема подходит проектам, где площадка объединяет локальных продавцов с разрозненными каталогами и разными учётными системами: строительные материалы и инструмент, автозапчасти, товары для дома и сада. Главное — закладывать нормализацию каталога и формат обмена ещё на этапе технического задания, а не после подключения первых партнёров.\u003C\u002Fp>\n"]