Кейсы

Механизм согласований в 1С:ERP: как мы встроили процесс прямо в систему и перевели 650 документов в месяц из чатов в учёт

2026-07-17 16:28 Доработка
В строительной компании с 200 пользователями 1С согласование закупок шло по кругу: инженер отправлял заявку, экономист проверял цены, руководитель давал добро — и всё это через почту, чаты и устные договорённости. Кто согласовал, когда, на каком основании — узнать было невозможно. Мы разработали механизм согласований прямо внутри 1С:ERP. Сейчас через него проходит больше 650 документов в месяц, большинство согласуется в тот же день, а каждое решение зафиксировано в протоколе.
Этот кейс — часть большого проекта по внедрению 1С:ERP (подробнее — в обзорной статье). Здесь разберём, как устроена подсистема согласований.

О клиенте

Крупная строительная компания, работающая на государственных объектах. Несколько тысяч сотрудников, около 200 пользователей 1С. Одновременно в работе около 30 проектов. Рядом с ERP работают 1С:Бухгалтерия, 1С:ЗУП и 1С:Документооборот.

Как было: «галочки» вместо процесса

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

«У нас «галочки» согласований растут и как будто это даже не конец. Нам нужно придумать какой-то гибкий механизм и прикрутить его к тем документам, которые требуют согласований»


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

Почему не 1С:Документооборот

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

Что мы сделали

Универсальный бизнес-процесс согласований

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

Четыре типа документов — один механизм

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

Автоподстановка участников

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

Управление правами и статусами

Отдельный большой блок — матрица прав. Кто и что может делать с документом на каждом этапе:
  • При отправке на согласование таблица с позициями блокируется — никто не изменит состав ТМЦ, пока идёт проверка. При этом отдельные поля (цена поставщика, дата потребности) остаются доступными — закупщику нужно работать с документом параллельно
  • Статусы «Согласовано» и «Не согласовано» устанавливаются автоматически по результатам процесса. Пользователь с ограниченными правами не может сменить их вручную
  • Пользователь с полными правами может переключить статус в любой — это осознанное административное действие для нештатных ситуаций
  • Согласованный документ нельзя пометить на удаление без полных прав
Эта матрица складывалась постепенно. Каждый новый сценарий — «а если пользователь случайно сменил статус при редактировании?», «а если согласованный документ пометили на удаление?» — уточнял правила. Мы прошли через несколько раундов доработок, прежде чем система стабилизировалась. Для итерационной разработки это нормальная ситуация: архитектура уточняется по мере накопления реального опыта.

Управление процессом

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

Отчёты и печатные формы

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

Сложности

Безопасность. В ходе эксплуатации обнаружилось, что любой пользователь с определённой типовой ролью мог открыть чужую задачу через отчёт и согласовать её — за другого человека. Убрать эту роль нельзя — она нужна для других функций системы. Мы создали отдельную роль с проверкой: кнопки «Согласовать» и «Не согласовать» доступны только если текущий пользователь совпадает с назначенным исполнителем задачи.
Производительность. При 200 пользователях список «Мои задачи» начал тормозить. Причина — запрос, который для каждой задачи подтягивал данные из таблицы бизнес-процессов. Мы переписали запрос: добавили предварительную выборку во временную таблицу, а затем уже соединяли с основным списком. Открытие стало быстрым.
Итерационная доработка прав. Матрица «кто что может в каком статусе» оказалась значительно сложнее, чем можно было предусмотреть при проектировании. Каждый новый сценарий — пользователь редактирует документ на согласовании, система из внешнего сервиса создаёт заказ в обход согласования, статус сбрасывается при проведении — требовал отдельной проработки. Мы прошли через 8 пакетов доработок и 59 задач за полтора года, прежде чем покрыли все комбинации.

Что получилось

650 документов в месяц проходят через механизм согласований. Это ~26 документов каждый рабочий день: заказы поставщику, заявки на закупку и замену, заявки на расход денежных средств.
Большинство согласуется в тот же день. Сотрудник получает задачу, открывает документ, принимает решение — без переписки и напоминаний.
Полный протокол. Каждое решение зафиксировано: кто, когда, с каким комментарием. Протокол доступен в отчёте и в печатной форме.
Автоматические статусы. Результат согласования сразу отражается в документе. Ручное вмешательство — только для администраторов.
Контроль доступа. Пользователь не может согласовать чужую задачу, изменить состав позиций во время согласования или сменить статус без соответствующих прав.
Всё внутри ERP. Сотрудники не выходят из программы. Не нужно осваивать отдельную систему, переключаться между окнами, вспоминать, где искать задачу.

Стоимость и сроки

Подсистема согласований разрабатывалась и дорабатывалась на протяжении полутора лет — параллельно с другими блоками ERP. Стоимость подобного проекта — от 1,4 млн рублей. Общая стоимость проекта внедрения ERP, сроки и состав работ — в обзорной статье.
Если в вашей компании согласования идут через почту и чаты — напишите, разберёмся, как встроить их в 1С.