Оптовый заказ согласуют несколько сотрудников: какие роли нужны в кабинете покупателя

Одна покупка, разные полномочия

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

Должность не равна разрешению. Руководитель может согласовывать расходы и не заниматься подбором товаров, а бухгалтер — видеть документы без права менять состав корзины, поэтому роли проектируют через действия над заказом, а не через названия должностей в штатном расписании. На старте достаточно перечислить участников. Затем возле каждого записывают доступные действия. Так появляется основа задания для кабинета.

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

Учётная запись относится к сотруднику и организации

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

В российском модуле «B2B-кабинет» для 1С-Битрикс описаны отдельные пользователи организации и роли руководителя, закупщика и наблюдателя. Последний видит цены и историю без оформления заказов. Это пример готовой модели. Такие возможности относятся к названному модулю. При другом решении их надо запросить и испытать отдельно.

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

Отключение сотрудника не удаляет историю. Его прошлые решения остаются привязаны к заказам, а незавершённые задачи передаются действующему участнику по правилу компании, чтобы закупка не зависла после кадровой перемены.

Корзина превращается в заявку на решение

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

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

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

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

Что увидит каждый участник

Кнопка подсказывает право, но не устанавливает его. Исполнитель должен запретить чужое действие на сервере, поэтому приёмка включает попытку открыть недоступный заказ по прямой ссылке и осмотр видимого меню как отдельное действие.

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

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

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

Возврат на исправление и замещение

Отказ не обязан уничтожать подбор. Если руководитель просит убрать позицию или изменить количество, закупщику полезно вернуть тот же набор с комментарием, чтобы не восстанавливать длинную закупку заново и не терять причину предыдущего решения.

Правило возврата связано с блокировкой. Можно разрешить автору редактировать только после возврата либо позволить отозвать заявку из ожидания. Второй вариант удобнее для найденной ошибки. Но отзыв закрывает возможность одобрить старую версию. В противном случае одновременные действия автора и руководителя создадут два разных представления о принятом составе.

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

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

Одобрение покупателя не запускает склад без правил продавца

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

В описанном модуле B2B-кабинета есть настройка «Согласовывать заказы сверх лимита». Пока заявка ждёт решения или отклонена, отгрузка удерживается. Приёмка этой функции начинается с тестового заказа. Оплата до согласования не должна случайно обходить установленное удержание. Для другой платформы такое поведение является требованием, которое исполнитель подтверждает демонстрацией.

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

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

Пройдите покупку без общего входа

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

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

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

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