B2B-портал самообслуживания: роли покупателей и повторные заказы

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

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

Начните с компании, филиала и конкретного человека

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

В документации Shopify B2B компания, её локация и покупатель описаны как отдельные сущности. У локации могут быть собственные цены, адреса и условия оплаты. Это пример модели данных, а не требование выбирать Shopify. Для своего портала сначала выясните, где уже хранятся эти связи и кто вправе их менять.

Показывайте активный филиал рядом с корзиной. После переключения контекста проверяйте адрес и прайс заново. Сам доступ к филиалу ещё не означает права совершать закупки от его имени.

Разделите рабочие роли и границы делегирования

Роли покупателей в B2B-кабинете стоит строить вокруг действий, а не названий должностей. Человек может просматривать каталог, готовить корзину, оформлять закупку, читать счета или управлять коллегами. Это разные разрешения. В Adobe Commerce, например, права компании отдельно охватывают оформление, просмотр заказов и управление пользователями. Конкретный набор зависит от решения и настроек.

Приведённую ниже условную стартовую матрицу уточните вместе с покупателями. Пометка «по правилу» означает отдельную настройку, а не автоматический доступ.

Администратор клиента не должен выдавать себе все права

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

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

Проверяйте разрешение в момент действия

OWASP различает аутентификацию и авторизацию: успешный вход подтверждает личность, но не разрешение на любую операцию. Для портала это означает проверку доступа к конкретному заказу, документу и филиалу на сервере. Скрытая кнопка не заменяет такой проверки.

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

Повторяйте состав закупки, а не прошлые условия

Надёжный повторный заказ начинается с нового черновика на основе истории. Старый документ остаётся историческим фактом, а новая корзина проверяется по текущим правилам. Цена, минимальная партия, кратность упаковки, доступность товара и адрес могли измениться. Покупатель должен увидеть разницу до отправки, а не после получения счёта.

Разделите результат проверки на понятные группы: готово к закупке, требует исправления и недоступно. Для каждой проблемной строки нужны объяснение и действие. «Не удалось повторить» не помогает понять, исчез ли артикул или не хватает права на каталог. Не подменяйте товар аналогом и не увеличивайте количество до упаковки без явного решения пользователя.

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

Условный пример: замена закупщика и новая упаковка

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

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

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

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

После нажатия кнопки покупателю нужен определённый результат

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

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

Границы ответственности между системами стоит рассматривать отдельно от ролей покупателя. Если непонятно, где хранится главный статус, поможет материал о том, когда интернет-магазину нужна OMS. А нестандартная закупка с индивидуальными условиями относится к другому процессу — согласованию B2B-предложения. Не смешивайте эти маршруты в одной кнопке «повторить».

Проведите предпусковой тест под рабочими ролями

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

1. Войдите как закупщик одного филиала и попробуйте открыть заказ другого, в том числе по прямой ссылке. Ожидание — отказ без раскрытия документа.
2. Пригласите коллегу через администратора покупателя. Проверьте разрешённую область и попытку выдать более широкие права, чем администратор вправе делегировать.
3. Откройте корзину, затем отзовите право оформления. Попытка отправки должна пройти новую проверку и завершиться контролируемым отказом.
4. Повторите закупку с изменёнными ценой, упаковкой и доступностью. Сверьте каждую строку и объяснение; испытайте также непустую корзину.
5. Имитируйте потерю ответа после принятия документа учётной системой. Проверьте повторную попытку, поиск результата и отсутствие лишнего заказа.
6. Завершите срок замещения, заблокируйте пользователя и проверьте доступ к документам. Сверьте журнал действий и маршрут передачи незавершённых черновиков.

Для отклонений назначьте ответственных и повторные тесты. Доступ к чужим документам, закупка за пределами полномочий или незаметная потеря строк — причины отложить запуск.

Как ограничить сроки, расходы и операционные риски

Сроки зависят от готовности справочника компаний, качества истории заказов и правил в вашей ERP — системе учёта ресурсов предприятия. Сначала проверьте одну сквозную закупку на тестовых данных. Затем расширяйте роли, филиалы и исключения. Календарная оценка до проверки интеграции скрывает главную неопределённость: можно ли получить актуальные условия и однозначный результат отправки.

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

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

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

Начинать стоит с карты полномочий и одного сложного повторного заказа, а не с перечня желаемых виджетов. Для обсуждения разработки B2B-кабинета с GL.ua (Глянец) подготовьте структуру филиалов, перечень ролей и обезличенный пример закупки с изменениями. На этой основе можно определить границы пилота и предметно оценить интеграцию.