Производитель или дистрибьютор хочет, чтобы партнёры самостоятельно проверяли наличие товара, видели свои цены, оформляли заказы и получали документы. Первая мысль — разработать собственный B2B-портал. Но заказная система нужна далеко не всегда.
На рынке уже есть готовые платформы с каталогом, персональными ценами, заказами, несколькими пользователями одной организации и обменом с 1С. Иногда разумнее внедрить такую систему. В других случаях ключевая сложность скрывается в коммерческих правилах, структуре данных и интеграциях — и тогда сравнивать решения нужно по реальным сценариям бизнеса, а не по количеству функций на сайте разработчика.
Ниже — практический способ принять решение.
Сначала описываем работу дилера, а не экраны кабинета
Начните с одного типового заказа. Например, дилер подбирает товары, получает свою цену по договору, проверяет наличие на нужном складе, отправляет заказ, отслеживает согласование и скачивает документы.
Для каждого шага выясните, где сегодня хранится информация и кто принимает решение. Если условия отличаются по договору, филиалу или категории товаров, это нужно отразить до выбора платформы.
Список «каталог, корзина, личный кабинет, 1С» ничего не говорит о сложности. Её определяют правила.
Пять вопросов, которые определяют архитектуру
1. Как устроены персональные цены?
Есть разница между несколькими заранее определёнными типами цен и системой индивидуальных соглашений с исключениями по брендам, категориям или отдельным товарам. Уточните, где формируется окончательная цена: в 1С, ERP, кабинете или вручную менеджером.
Проверьте важный сценарий: что увидит дилер, если для его организации нет разрешённой цены? Нельзя молча подменять персональные условия розничной ценой, если это нарушает коммерческую политику.
2. Что означает «актуальный остаток»?
Остаток в 1С, доступное к продаже количество и возможность зарезервировать товар — разные понятия. Один склад может принадлежать компании, другой — поставщику; часть товаров может быть под заказ.
Понадобится решение о частоте обновления, резервировании и поведении при временной недоступности учётной системы. Обещание «остатки онлайн» без такой модели создаёт ложные ожидания.
3. Кто оформляет и подтверждает заказ?
У одного контрагента могут работать закупщик, руководитель и бухгалтер. Закупщик собирает корзину, руководитель утверждает крупную сумму, бухгалтер получает документы. Иногда сотрудник обслуживает несколько юридических лиц.
Нужно заранее определить не только роли, но и границы данных: чьи цены, документы и заказы видит каждый пользователь, кто может менять организацию и кто подтверждает нестандартные условия.
4. Что именно передаётся в 1С?
Минимальная модель обмена может включать контрагентов, товары, цены, остатки, заказы и статусы. Но важнее обозначить источник истины для каждой сущности.
Например, заказ создаётся в кабинете, проверяется в 1С и получает новый статус. Нужно понимать, как связать идентификаторы, избежать повторного создания заказа и показать пользователю ошибку обмена, а не бесконечное состояние «обрабатывается».
5. Какие сценарии выходят за стандартный каталог?
Это могут быть заказ по Excel-спецификации, мультикорзина, история повторных закупок, лимиты задолженности, согласование нестандартной цены, территориальные ограничения дилеров, отдельная логика рекламаций и API для внешних систем.
Некоторые готовые B2B-платформы уже поддерживают такие функции. Поэтому утверждать, что «всё нестандартное требует разработки», неправильно. Вопрос в том, насколько именно ваша комбинация правил поддерживается без рискованных доработок.
Три варианта реализации
| Подход | Когда уместен | Что проверить заранее |
|---|---|---|
| 1 Готовая B2B-платформа | Сценарии близки к типовой оптовой торговле; стандартные интеграции покрывают большую часть задач | Лицензии, редакция, доступные роли, обмен с 1С, возможность обновлений |
| 2 Готовая платформа с доработками | Базовые функции подходят, но есть несколько специальных правил | Не помешают ли доработки обновлять платформу; кто будет сопровождать интеграцию |
| 3 Индивидуальный кабинет | Нестандартная ролевая модель, сложные коммерческие правила, несколько систем или собственный API определяют саму ценность решения | Длительность обследования, качество данных, бюджет на поддержку, надёжность и развитие |
Второй вариант часто забывают: не обязательно выбирать между «купить коробку» и «писать всё с нуля». Правильный выбор появляется после проверки критических сценариев на демо или ограниченном прототипе.
Почему интеграция часто важнее интерфейса
Даже удобный кабинет не поможет дилеру, если в каталоге неверные цены и наличие. Для B2B-системы необходимо описать поток данных: откуда поступает номенклатура, как применяются условия партнёра, что происходит после отправки заказа и как отображаются изменения.
При проектировании полезно оформить таблицу: сущность → система-источник → направление обмена → частота обновления → действия при ошибке. Её можно составить до выбора технологии.
Особенно важно не строить параллельный независимый расчёт цен без необходимости. Если коммерческая логика живёт в 1С, кабинет и API должны получать согласованные результаты согласно единому правилу.
Пример из практики: Grifmaster B2B и Grifmaster API
В опубликованном профессиональном портфолио представлен опыт разработки двух связанных, но отдельных решений для дистрибьютора Grifmaster.
Grifmaster B2B — кабинет на Laravel и Filament с каталогом, персональными ценами, корзиной и заказами, организациями, ролями, прайсами и файлами. Каталог получает данные из 1С. В кейсе показаны интерфейс партнёра и административные инструменты.
Grifmaster API — отдельный интеграционный сервис для партнёров: JSON/XML API, Excel/CSV-выгрузки, управление организациями и ключами, правила скидок и статистика использования API.
Эти примеры показывают, что B2B-задача обычно состоит не только из каталога. Важны доступы, единая логика коммерческих условий и корректный обмен с внешними системами. Кейсы описывают личный профессиональный опыт, а не заявляют о разработке этих систем силами отдельной команды BGUS или Panda Group.
Как оценивать бюджет: не только стоимость запуска
Сравните варианты по полной стоимости владения на несколько лет: лицензии, настройка, интеграция, очистка справочников, тестирование, обучение, обновления, хостинг, мониторинг, техническая поддержка и будущие изменения правил.
Готовый продукт может быть выгоднее при близких к типовым процессах. Индивидуальная система может оказаться оправданной, если адаптация коробки слишком сложна или создаёт зависимость от нестабильных модификаций. Но сама по себе заказная разработка не гарантирует меньшую стоимость владения.
Чек-лист перед разговором с подрядчиком
- Сколько организаций и пользователей будет работать в кабинете?
- У одной организации могут быть несколько сотрудников с разными правами?
- Как определяются персональные цены и ограничения по ассортименту?
- Где хранится достоверная информация об остатках и резервах?
- Нужен ли заказ по Excel, артикулу или истории предыдущих закупок?
- Что считается подтверждением заказа и кто имеет право его изменить?
- Какие документы и статусы дилер должен получать без менеджера?
- Какую конфигурацию 1С или ERP использует компания и кто её сопровождает?
- Требуются ли интеграции дилеров по API?
- Какие специальные правила невозможно убрать без ущерба для бизнеса?
Если на эти вопросы есть ответы, выбрать между готовой платформой и индивидуальной разработкой намного проще.