← На главную

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

Варианты архитектурных решений для согласования документов

При проектировании модуля согласования в 1С существует несколько основных способов реализации бизнес-логики:

1. Собственная разработка на штатных метаданных «Бизнес-процессы» и «Задачи». В платформе 1С:Предприятие присутствуют специальные типы объектов — БизнесПроцесс и Задача. Бизнес-процессы позволяют описывать маршруты движения задач в виде графических схем, управлять точками действия, ветвлениями и получением результатов. Этот подход идеально подходит, когда требуется встроить жесткую логику согласования непосредственно в рабочую конфигурацию (например, УПП, ERP, Комплексную автоматизацию или УТ) без привлечения сторонних систем.
2. Использование статусной модели (State Machine). Вместо создания тяжелых метаданных типа БизнесПроцесс маршрут согласования описывается через справочник этапов и регистры сведений, фиксирующие текущий статус документа и историю его переходов. Данная схема проще в поддержке при часто меняющейся бизнес-логике и создает меньшую нагрузку на базу данных.
3. Внедрение и бесшовная интеграция с «1С:Документооборот». Готовое типовое решение, содержащее продвинутый движок согласования, делегирования, эскалации задач и ролевой адресации. При использовании «1С:Документооборот КОРП» доступна механизмы бесшовной интеграции, когда пользователь работает в своей учетной системе (например, Управление торговлей), а процессы согласования запускаются и отрабатывают в фоновом режиме в базе СЭД.
4. Использование библиотечных подсистем (БСП). В Библиотеке Стандартных Подсистем доступна подсистема «Процессы и задачи», позволяющая развернуть базовый функционал маршрутизации и адресации задач без покупки дополнительных конфигураций.

Механизм версионирования объектов и правки при согласовании

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

Для контроля изменений и сохранения прозрачности необходимо использовать штатный механизм версионирования объектов из БСП:

1. Механизм сохраняет сжатые XML-слепки объекта при каждом изменении в специальном регистре сведений.
2. В настройках системы следует четко ограничить момент создания версий — например, формировать версию не «При записи», а строго «При отправке на согласование» или «При проведении». Это предотвратит экспоненциальный рост объема базы данных.
3. Для поддержания высокого производительности СУБД (MSSQL, PostgreSQL) необходимо настраивать регламентные задания по регулярной очистке или архивации старых версий объектов.

Ограничения платформы при совместном редактировании документов

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

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

1. Разделение рабочих мест через специализированные обработки. Пользователи не работают напрямую с формой документа. Вместо этого создаются отдельное АРМ (автоматизированное рабочее место) или обработка. Данные вводятся через нее и записываются в независимый регистр сведений в разрезе документа и пользователя. Сам документ-шаблон собирает итоговые данные из регистра только перед проведением.
2. Построчное согласование через регистр сведений. Хранить статусы согласования отдельных строк чекбоксами прямо в табличной части документа — дурной тон разработки, так как это требует постоянной перезаписи документа целиком. Правильное решение — хранить статусы строк в независимом регистре сведений.
3. Использование уникальных идентификаторов строк. Для связи строки табличной части со статусом в регистре нельзя использовать НомерСтроки, так как при пересортировке или удалении нумерация сместится. Для этого применяется специальный тип данных ИдентификаторСтроки (уникальный GUID строки), сохраняющийся при любых манипуляциях с табличной частью.

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