Вернуться к статьям Закупщик находит нужную позицию в каталоге, но не понимает, доступна ли она его организации, можно ли включить её в заявку и требуется ли внутреннее согласование. Менеджер получает обращение без реквизитов, спецификации или состава заказа. Каталог при этом существует, однако условия приходится уточнять в переписке и таблицах.
Разработка B2B-портала с каталогом начинается с описания закупочного процесса. На одной площадке могут работать сотрудники разных компаний, подразделения одного клиента, дилеры, сервисные партнёры и сотрудники поставщика. Для каждой группы определяют доступ к товарам, данным и действиям.
B2B-портал и интернет-магазин: различия в оформлении заказа
Обычный интернет-магазин рассчитан на самостоятельное оформление: посетитель выбирает товар, добавляет его в корзину, оставляет контактные данные и передаёт заказ в обработку. Для большинства посетителей сценарий одинаков.
В B2B-портале товар может быть частью заявки. Пользователь собирает позиции для расчёта, прикладывает техническое задание, указывает объект поставки или выбирает организацию. Заявка может проходить внутреннее согласование и проверку со стороны поставщика.
До проектирования полезно зафиксировать маршрут заявки: кто ищет товар, кто формирует состав, кто согласует его у клиента, какие сведения получает поставщик и что происходит после отправки. Иначе корзина и форма заказа останутся интерфейсом для ручной обработки.
Структура каталога и состав товарных данных
Каталог должен помогать закупщику и техническому специалисту сопоставить позицию со своей задачей: сравнить варианты, открыть документы, добавить товар в заявку. Для сложного ассортимента недостаточно названия, изображения и краткого описания.
Категории строят с учётом реального поиска. Навигация может опираться на тип оборудования, область применения, совместимость или производителя. Одна позиция иногда относится к нескольким разделам, поэтому правила размещения нужно определить заранее.
Для каждого типа товара задают набор полей: параметры, варианты исполнения, единицы измерения, файлы, связанные позиции и признаки доступности. Фильтры дают предсказуемый результат, когда значения заполняются по единым правилам. Если одно и то же свойство вносится в свободной форме или отсутствует в части карточек, выдача становится неполной.
Личный кабинет и роли пользователей
Один контрагент нередко представлен несколькими сотрудниками. Закупщик готовит заявку, руководитель согласует её, бухгалтер работает с документами, а технический специалист проверяет параметры. Этим пользователям не требуется одинаковый набор прав.
В требованиях отдельно описывают роли и границы видимости. Важно определить, видит ли сотрудник заявки коллег, имеет ли доступ к истории обращений организации, может ли менять реквизиты и адреса или только создавать черновик.
Отдельно предусматривают изменение состава пользователей: увольнение, перевод в другое подразделение, ошибочное назначение роли. Данные сотрудника и данные организации не стоит объединять в одной модели без правил доступа. Контактное лицо, договор, адрес поставки и условия оформления относятся к разным сущностям и могут иметь разные ограничения видимости.
Доступ к ассортименту и правила оформления заявок
Разным группам пользователей может быть доступен разный ассортимент и разные способы оформления. Такие правила не стоит оставлять только в программной логике. До разработки определяют, от каких признаков зависит отображение товара, где хранится источник данных и кто поддерживает сведения в актуальном состоянии.
Для товаров, которые нельзя оформить по стандартному сценарию, предусматривают отдельный маршрут: запрос на расчёт, сбор спецификации или передача заявки менеджеру. Пользователь должен понимать, что именно передаётся: отдельная позиция, набор товаров, проектная потребность или повторный заказ по ранее согласованному составу.
При тестировании проверяют исключения: организацию без назначенных условий, товар с неполными данными, изменившийся статус позиции, несколько условий для одной компании. Такие ситуации стоит предусмотреть ещё на этапе проектирования и тестирования.
Интеграции B2B-портала и обмен данными
Формулировка «нужна интеграция с учётной системой» не определяет состав работ. Для портала перечисляют объекты обмена и действия, в которых они участвуют: товары, параметры, статусы заявок, реквизиты организаций, документы, история заказов.
Для каждого объекта определяют источник данных, направление передачи и правило сопоставления идентификаторов. Также заранее решают, что происходит при ошибке: где она фиксируется, кто разбирает проблему, можно ли повторить передачу и как обрабатываются неполные сведения. Иначе товар может появиться без обязательных полей, а заявка — без связи с нужной организацией.
«1С-Битрикс: Управление сайтом» может использоваться для публичной части портала и личного кабинета в рамках настроенного проекта. CMS не заменяет процессы обработки заявок и не определяет, кто принимает решение по ним.
Как определить границы разработки
При выборе подхода оценивают не только перечень экранов, но и рабочие сценарии. Каталог, карточка товара и личный кабинет могут выглядеть похоже, но отличаться правилами доступа к ассортименту, составом заявки, согласованием, документами и обменом данными.
До начала работ нужны реальные примеры: обычные товары, позиции с вариантами, карточки с неполными данными, товары под запрос и повторные заказы. На таких примерах проще проверить структуру каталога, фильтры, права пользователей и логику оформления.
С подрядчиком важно согласовать границы решения: какие сценарии входят в проект, какие данные предоставляет заказчик, кто поддерживает каталог и какие условия требуют отдельного описания. Это помогает избежать ситуации, когда слово «портал» по-разному понимают участники проекта.
Проверка B2B-каталога перед запуском
Тестирование не сводится к просмотру карточек на тестовых данных. Проверяют путь каждого типа пользователя: поиск, фильтрацию, выбор варианта, формирование заявки, согласование, передачу данных и отображение результата в личном кабинете.
Отдельно проверяют ограничения: пользователя без доступа к части ассортимента, организацию без заполненных условий, товар без изображения или документа, заявку с нестандартным составом и ошибку обмена. Такие сценарии показывают, где требуется понятное сообщение пользователю, а где нужно уточнить правила работы.
Часто задаваемые вопросы
- Можно ли использовать обычную корзину для B2B-портала?
Да, если оформление сводится к выбору товаров и передаче заявки менеджеру. Когда нужно согласование состава, прикрепление спецификации, выбор организации или запрос расчёта, корзину дополняют нужными сценариями либо используют другой механизм заявки.
- Какие данные нужны для проектирования B2B-каталога?
Понадобятся примеры товарных групп и карточек, перечень параметров, правила отображения вариантов, документы, роли пользователей и путь заявки. Также необходимо определить источники данных и ответственных за их актуальность.
- Можно ли ограничить ассортимент для отдельных клиентов?
Да, если правила доступа определены заранее. Нужно описать, какая группа пользователей видит ассортимент, от чего зависит доступ и как обрабатываются новые организации или изменения их статуса.
- Чем личный кабинет B2B отличается от обычной регистрации на сайте?
Личный кабинет B2B связан не только с сотрудником, но и с организацией, подразделением или условиями взаимодействия. Поэтому при проектировании определяют роли, видимость заявок и порядок подтверждения полномочий, а не только поля регистрационной формы.
- Что проверить перед передачей портала в работу?
Проверяют реальные товары и нестандартные ситуации: неполные карточки, варианты товара, ограниченный доступ, заявку без обязательного параметра, повторное оформление и ошибку передачи данных. Отдельно оценивают, понятны ли пользователю причины недоступности действия или необходимости уточнения заявки.