Согласование заказов в B2B-портале: роли, лимиты и маршрут заявки

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

Что решает согласование заказов в B2B-портале и где границы задачи

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

В границы задачи входит:

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

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

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

Матрица ролей и лимитов — главный рабочий документ

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

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

Как определить пороги

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

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

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

Инициатор, согласующий и получатель: зоны ответственности

Три роли встречаются в любом маршруте, и путать их нельзя.

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

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

Получатель — склад, логистика или менеджер поставщика — отвечает за исполнение. Он видит уже согласованный заказ и не участвует в споре о том, надо ли было его согласовывать.

Что видит каждая роль

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

Замещение и делегирование

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

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

Базовый маршрут выглядит так: черновик — отправка на согласование — проверка — решение — отправка поставщику — подтверждение поставщиком. Каждый переход сопровождается сменой статуса, а не только письмом.

Маршрут может ветвиться. Типичные развилки: сумма ниже порога — согласующий один; сумма выше — добавляется финансовый уровень; контрагент новый — добавляется проверка реквизитов; позиция из особой категории — добавляется профильный специалист. Чем меньше развилок, тем проще поддерживать маршрут, поэтому лишние условия лучше не добавлять «на всякий случай».

Последовательное или параллельное согласование

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

Где маршрут заканчивается

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

Лимиты и пороги: что именно сравнивать с суммой

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

Лимит на заказ и лимит на период

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

Отклонение от согласованной цены

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

Изменения согласованного заказа и версии

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

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

Что фиксировать в версии

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

Статусы и уведомления: чтобы задача не терялась

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

Минимальный набор статусов

• черновик;
• на согласовании;
• возвращена на исправление;
• отклонена;
• согласована, ожидает отправки;
• отправлена поставщику;
• подтверждена поставщиком;
• закрыта.

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

Что писать в уведомлении

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

Отказ, возврат на исправление и отсутствие согласующего

Три разные ситуации, которые часто смешивают в одну.

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

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

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

Причина решения обязательна

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

Учебный пример: согласование закупки на тестовых данных

Учебный пример. Данные условные и не описывают реальную компанию.

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

Сценарий. Менеджер склада собирает заявку на 40 позиций. Сумма ниже лимита руководителя склада, поэтому маршрут короткий: заявка уходит руководителю склада, тот утверждает, заявка получает статус «согласована, ожидает отправки» и уходит поставщику.

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

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

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

Как проверить результат и принять работу

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

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

Если портал уже работает, а маршрут вызывает вопросы, разумно начать с Аудит интернет-магазина — что проверяют и что будет в отчёте: он покажет, где правила расходятся с фактическим поведением системы.

Типичные ошибки и ограничения

Ошибки, которые встречаются чаще всего:

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

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

Если портал только предстоит создать, полезно заранее посмотреть, из чего складывается Сколько стоит разработка интернет-магазина: из чего складывается цена — маршрут согласования относится к тем частям, которые требуют отдельной проработки, а не входят в базовый набор по умолчанию. В платформе 1С-Битрикс функционал согласования реализуется через модуль бизнес-процессов, а управление ценами и доступом — через настройки каталога и прав пользователей. Конкретный набор возможностей зависит от редакции продукта, поэтому его стоит сверить с документацией и специалистом до начала работ.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по согласованию заказов в B2B-портале, нужен не список пожеланий, а описание процесса. Подготовьте:

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

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