Согласование и статусы заказов в B2B-портале на 1С-Битрикс

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

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

Почему в B2B заказ проходит согласование

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

Важно понимать: согласование заказов — это не про сайт и не про Битрикс. Это управленческий процесс, который существует в компании независимо от того, есть у неё B2B-портал или нет. До портала он живёт в почте, звонках и мессенджерах: закупщик собирает список, отправляет руководителю на почту, тот отвечает «ок» или «убери вот это», закупщик пересобирает и звонит поставщику. Медленно, без истории, с потерями. Портал не выдумывает этот процесс, а переносит его в удобный интерфейс, где всё зафиксировано и прозрачно.

Зачем компании-покупателю нужен контроль над заказами — если назвать честно, без пафоса:

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

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

Роли в организации-покупателе

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

Типовой набор ролей закупщика в B2B-портале:

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

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

Корзина-заявка и черновик заказа

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

Разложим по шагам, как заказ рождается и превращается в заявку:

1. Сбор корзины. Закупщик наполняет корзину из каталога, по артикулу или загрузкой из Excel. На этом этапе цены персональные, наличие видно, но заказ ещё не оформлен.
2. Сохранение черновика. Собранная корзина сохраняется как черновик: можно закрыть портал и вернуться завтра, ничего не потеряв. Черновиков может быть несколько — под разные нужды.
3. Проверка и уточнение. Закупщик сверяет количества, кратность упаковок, суммы. Портал подсказывает, что изменилось в ценах или наличии с момента сборки.
4. Отправка на согласование. Закупщик нажимает «Отправить на утверждение». Заказ фиксируется и меняет статус — теперь это заявка, и его состав заморожен до решения утверждающего.
5. Решение по заявке. Утверждающий видит заявку, состав и сумму. Он утверждает её, отклоняет или возвращает на доработку с комментарием.

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

Жизненный цикл заказа и статусы

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

Типовой конвейер статусов заказа b2b с согласованием:

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

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

Маршрут согласования: закупщик → утверждающий → в работу

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

Базовый маршрут выглядит так:

1. Закупщик собирает и отправляет заявку. Заказ уходит из черновика в статус «на согласовании», система определяет, кто утверждающий для этого закупщика и этой суммы.
2. Утверждающий получает задачу. Ему приходит уведомление, в кабинете появляется заявка с составом, суммой и данными закупщика. Он видит всё, что нужно для решения.
3. Утверждающий принимает решение. Три исхода: утвердить, отклонить совсем или вернуть на доработку с комментарием (например, «убери позицию X, дорого»).
4. Утверждённая заявка передаётся в работу. Заказ меняет статус на «утверждён» и уходит в 1С — начинается исполнение. Закупщик получает уведомление, что заказ принят.
5. Отклонённая заявка возвращается. Закупщик видит причину, правит состав и отправляет заново — круг повторяется, пока заявку не утвердят или не отменят.

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

Многоступенчатое утверждение по лимиту суммы

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

Логика простая и знакомая любому, кто работал в компании с бюджетом:

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

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

Кредитный лимит и отсрочка платежа

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

В контексте согласования лимит — это ещё одна развилка маршрута, только считается она не по сумме заказа, а по остатку лимита. Логика такая:

• Заказ в пределах лимита. Текущий долг плюс новая сумма укладываются в лимит — заказ идёт обычным маршрутом согласования.
• Заказ на грани лимита. Портал предупреждает закупщика: «после этого заказа останется 10% лимита». Полезно, чтобы партнёр успел оплатить.
• Заказ сверх лимита. Срабатывает правило компании-поставщика: заблокировать, потребовать предоплату или отправить на отдельное согласование менеджеру поставщика.
• Просрочка по оплате. Если есть просроченная задолженность, новые заказы могут ограничиваться до её погашения — независимо от остатка лимита.

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

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

Проверка дебиторки при оформлении заказа

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

Что портал проверяет по дебиторке в момент оформления:

• Общая сумма долга. Сколько контрагент должен прямо сейчас — база для сравнения с лимитом.
• Наличие просрочки. Есть ли счета, срок оплаты которых прошёл. Просрочка — более серьёзный сигнал, чем просто большой долг в пределах срока.
• Глубина просрочки. Просрочено на три дня или на два месяца — разные ситуации, и правила могут отличаться.
• Заблокированные заказы. Нет ли уже придержанных отгрузок по этому контрагенту из-за долгов.

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

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

Уведомления участникам согласования

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

Кого и о чём уведомляют на разных этапах:

Каналы стандартные: e-mail как база, уведомления внутри портала (колокольчик со списком задач), а для срочного — мессенджеры или SMS, если это оправдано. Для утверждающего особенно ценно, чтобы решение можно было принять прямо из уведомления — например, по ссылке из письма сразу попасть на заявку с кнопками «утвердить»/«отклонить», а не искать её в кабинете.

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

История согласований и повтор заказа

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

Что фиксирует история согласования:

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

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

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

Документы: счёт на утверждение

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

Как документы вплетаются в маршрут согласования:

• Счёт по заявке. Портал может сформировать предварительный счёт по составу заявки — чтобы утверждающий и бухгалтер видели финальную сумму с НДС и реквизитами.
• Счёт как основание. В некоторых компаниях внутреннее утверждение идёт именно по счёту: закупщик прикладывает его к заявке, руководитель утверждает конкретную сумму.
• Документы после утверждения. Когда заказ принят и отгружен, к нему привязываются УПД, накладные, акты — уже из 1С, по факту операций.
• Изоляция документов. Счёт и акты одного контрагента не должны быть доступны другому — доступ проверяется по привязке к контрагенту на бэкенде.

Здесь важна та же развилка, что и в кабинете дилера: где формируется документ. Предварительный счёт по заявке портал может сгенерировать сам — это несложно, данные все есть. А вот бухгалтерские документы (УПД, накладные, финальные счета) формируются в 1С по факту операций и приходят на сайт как файлы, привязанные к заказу. Пытаться «рисовать» учётные документы на сайте в обход 1С — плохая идея: они разойдутся с учётом.

Бизнес-процессы Битрикса для маршрутов

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

Что даёт модуль «Бизнес-процессы» для согласования заказов:

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

Бизнес-процессы бывают двух типов — привязанные к элементам (например, к заказу как к сущности) и последовательные/со статусами. Для согласования заказа обычно используют процесс, стартующий при оформлении заказа или переводе его в статус «на согласовании», который дальше ведёт заявку по цепочке. Триггером служит смена статуса, а результатом работы процесса — перевод заказа в «утверждён» или «отклонён».

Модуль доступен в старших редакциях 1С-Битрикс (в «Бизнесе» и выше), поэтому если планируется строить согласование на бизнес-процессах, это учитывают при выборе редакции. В младших редакциях маршруты приходится собирать на статусах и собственном коде — об этом в следующем разделе.

Статусы заказа против бизнес-процессов

Возникает закономерный вопрос: на чём вообще строить согласование — на модуле «Бизнес-процессы» или на собственной логике статусов и прав? Однозначного ответа нет, и честный подход — выбирать под конкретный процесс и нагрузку. Сравним оба пути.

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

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

Группы, роли и разграничение прав

Фундамент всего согласования — разграничение прав. Именно оно определяет, кто может собирать заказ, кто утверждать, кто видеть баланс. Без чёткого разграничения роли превращаются в фикцию: если закупщик технически может сам утвердить свою заявку, никакого контроля нет.

В 1С-Битрикс права стоят на нескольких уровнях, и в согласовании задействованы все:

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

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

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

Реализация в кастомном личном кабинете

Теперь о том, где всё это живёт в интерфейсе. Согласование заказов — часть личного кабинета, и штатных «розничных» компонентов Битрикса для него недостаточно. Кабинет с согласованием — это связка штатного каркаса и доработок под B2B.

Из чего складывается реализация:

• Штатные компоненты как каркас. Семейство sale.personal.* даёт список и деталь заказов, профиль, адреса — базовую механику кабинета.
• Кастомные страницы согласования. «Мои черновики», «На согласовании», «На моё утверждение» — отдельные разделы со своими компонентами или контроллерами.
• Расширенные статусы заказа. К штатным статусам добавляются статусы согласования; переходы между ними управляются кодом или бизнес-процессом.
• Дополнительные поля заказа. Автор заявки, утверждающий, комментарии решений, история согласования — как свойства заказа.
• AJAX-контроллеры действий. Отправить на согласование, утвердить, отклонить — через контроллеры с проверкой прав, чтобы кабинет работал быстро и без перезагрузок.

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

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

Интеграция статусов с 1С

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

Что ходит между порталом и 1С в контексте согласования:

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

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

Эскалация, сроки и «зависшие» заявки

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

Инструменты против «зависаний»:

• Сроки на решение. У шага согласования есть ожидаемое время. Если заявка висит дольше — срабатывает напоминание или эскалация.
• Напоминания. Утверждающему повторно приходит уведомление: «заявка ждёт вашего решения второй день».
• Эскалация вверх. Если срок вышел, заявка поднимается к руководителю утверждающего или к резервному согласующему.
• Заместители. На время отсутствия утверждающего его задачи автоматически идут заместителю — чтобы процесс не вставал из-за отпуска.
• Видимость очереди. Утверждающий видит, сколько заявок и как давно ждут его решения, — это само по себе дисциплинирует.

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

Кэш, права и безопасность согласования

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

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

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

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

Как проектировать маршрут: от простого к сложному

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

Разумная последовательность внедрения согласования:

1. Опишите реальный процесс. Как сейчас, до портала, утверждаются закупки: кто готовит, кто решает, на какой сумме включается контроль. Без этого всё остальное бессмысленно.
2. Начните с одного уровня. Закупщик → один утверждающий → в работу. Даже это уже наводит порядок и приучает людей к процессу в портале.
3. Добавьте порог суммы. Мелочь в пределах лимита — без утверждения, крупнее — на согласование. Первый реальный фильтр, снимающий рутину.
4. Встройте кредитный лимит. Проверка остатка лимита и дебиторки при оформлении — как дополнительная развилка маршрута.
5. Настройте уведомления и сроки. Чтобы заявки не зависали: напоминания, эскалация, заместители на время отсутствия.
6. Усложняйте под потребность. Второй и третий уровни, параллельные ветки, роли — добавляйте только тогда, когда простая схема упёрлась в реальный запрос.

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

Частые ошибки при внедрении согласования

Эти промахи повторяются в B2B-проектах чаще всего — зная их, вы сэкономите время и нервы участников:

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

Чек-лист внедрения

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

1. Реальный процесс описан. Известно, кто готовит, кто утверждает и на какой сумме включается контроль — до настройки, а не после.
2. Роли разграничены. Закупщик, утверждающий, бухгалтер, наблюдатель — с разными правами; закупщик не может утвердить свою заявку.
3. Черновик и заявка разделены. Черновик правится свободно, отправленная заявка заморожена; изменение возвращает на пересогласование.
4. Статусы описаны как карта переходов. Видно, из какого статуса в какой можно попасть и кто имеет на это право; тупиков нет.
5. Пороги суммы заданы покупателем. Уровни утверждения отражают реальную финансовую политику компании.
6. Кредитный лимит и дебиторка встроены. Проверка остатка лимита и просрочки при оформлении; правило сверх лимита определено; цифры из 1С.
7. Уведомления настроены по ролям. Каждый получает значимые для него события; есть напоминания и эскалация зависших заявок.
8. Заместители предусмотрены. Процесс не встаёт из-за отпуска утверждающего.
9. История согласования ведётся. Видно, кто, когда и с каким комментарием утвердил или отклонил.
10. Интеграция с 1С состыкована. В 1С уходит только утверждённый заказ; статусы возвращаются; поведение при сбое обмена определено.
11. Безопасность на бэкенде. Права проверяются на сервере, данные контрагентов изолированы, кэш учитывает пользователя.
12. Схема реализации выбрана осознанно. Статусы или бизнес-процессы — под конкретный маршрут и нагрузку, а не «по моде».

Вывод

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

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