Дилерский портал с Битрикс24: заявки на отгрузку и доступ к своим данным

Партнёру нужны его цены, заказы и документы, а не доступ ко всей CRM. Разбираем границы кабинета, согласование заявки, обмен с 1С и проверку изоляции дилеров.

Дмитрий Максимов01.09.20266 мин чтения

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

Содержание

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

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

Выберите пространство под задачу партнёра #

Совместное обсуждение проекта и оформление регулярных оптовых заказов требуют разных инструментов. Для чата, задач и файлов может подойти коллаба. Но приглашение гостя не означает предоставление ему рабочего места в CRM. Возможности и ограничения внешних участников описаны в руководстве по доступу Битрикс24 .

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

Сначала определите, какие сведения принадлежат дилеру #

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

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

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

Отделите черновик заявки от подтверждённого заказа #

Партнёр должен понимать, когда его действие становится обязательством поставщика. Сохранённая корзина — черновик. Переданная заявка — запрос на согласование. Подтверждённый заказ появляется после проверки условий, остатков и других ограничений. Если называть все три состояния «заказ оформлен», кабинет создаст ложные ожидания.

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

Какие данные передавать между кабинетом, CRM и 1С #

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

Пример ниже показывает внутренний контракт заявки. Это не тело готового REST-запроса Битрикс24. Поле партнёра сервер получает из проверенной учётной записи, а не принимает безусловно из браузера.

example-policy.jsonJSON

{
  "request_id": "REQ-DEMO-24",
  "partner_company_id": "PARTNER-DEMO-7",
  "revision": 2,
  "status": "awaiting_confirmation",
  "lines": [
    {"product_id": "SKU-DEMO-18", "quantity": 4}
  ],
  "confirmed_order_id": null
}

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

Как показывать цены и доступность #

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

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

Что проверить до приглашения дилеров #

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

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

Можно ли обойтись коллабой без отдельного кабинета? #

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

Обязательно ли сразу подключать 1С? #

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

Поможем спроектировать кабинет с понятными границами #

NetLabCS поможет подготовить B2B-кабинет для партнёров , определить разрешённые данные и связать заявки с внутренней CRM. Если каталог и отгрузки ведутся в учёте, отдельно согласуем обмен Битрикс24 с 1С . Опишите процесс заказа : кто его создаёт, кто подтверждает и какие сведения должен видеть дилер.