Как правильно реализовать статусы нетиповых документов в 1С?

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

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

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

1. Запрет изменения прошлых периодов. Если документ записан в закрытом периоде, платформа не позволит обновить его статус из-за встроенного механизма даты запрета изменения данных.
2. Проблемы с производительностью. Если статус подчиненных документов меняется из другого объекта (например, групповой обработки или документа-задания), разработчику приходится в цикле получать объекты, менять значения и записывать их. Изменение и перепроведение десятков документов за раз с вызовом всех тяжелых обработчиков существенно замедляет работу.
3. Отсутствие истории. Реквизит документа содержит только текущее состояние и не позволяет легко узнать, когда именно документ перешел в тот или иной статус и кто совершил действие.

Решение 1. Независимый периодический регистр сведений

Наиболее популярным и гибким способом является вынос статусов в отдельный регистр сведений. Разберем его устройство:

1. Структура регистра:

   Создаем независимый периодический регистр сведений (например, СтатусыДокументов) с периодичностью «Секунда».

   • Измерение: Документ (тип: ОпределяемыйТип или Ссылка на нужные документы).
   • Ресурс: Статус (ПеречислениеСсылка или СправочникСсылка).
   • Реквизит (опционально): УстановилПользователь, Комментарий.
2. Преимущества подхода:

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

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

МенеджерЗаписи = РегистрыСведений.СтатусыДокументов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДатаСеанса();
МенеджерЗаписи.Документ = СсылкаНаДокумент;
МенеджерЗаписи.Статус = Перечисления.СтатусыЗаявок.ВЗадании;
МенеджерЗаписи.Ответственный = Пользователи.ТекущийПользователь();
МенеджерЗаписи.Записать(Истина);

Решение 2. Гибридная схема (кэширование статуса)

Хотя регистр сведений решает задачу хранения истории и обхода даты запрета, постоянное использование виртуальной таблицы СрезПоследних в динамических списках (в журналах или списках документов) может существенно снижать скорость работы при миллионах записей. Кроме того, использование регистра усложняет настройку прав доступа на уровне записей (RLS).

Проанализируем гибридный подход, комбинирующий оба метода:

1. История изменений и полная хронология хранятся в периодическом регистре сведений.
2. Текущий статус дополнительно дублируется в реквизит самого документа для максимальной скорости отображения в динамических списках и простой настройки RLS.
3. Обновление кэша: если изменить статус документа нужно из закрытого периода, запись реквизита в документе можно выполнить через регламентное/фоновое задание или режим записи без проверок и проведения.

Решение 3. Использование бизнес-процессов и задач

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

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

Важные технические детали реализации

При проектировании системы статусов важно учитывать следующие технические аспекты:

• Контроль матрицы переходов (Граф состояний): Независимо от выбранного места хранения, в коде модулей необходимо реализовать проверку допустимости смены статуса. Например, запретить прямой переход из статуса На рассмотрении в статус Выполнен в обход статуса В задании.
• Управляемые блокировки: При групповой смене статусов из фоновых задач необходимо явно устанавливать управляемые блокировки на записи регистра или ссылки документов с помощью объекта БлокировкаДанных, чтобы исключить взаимные блокировки (deadlocks) в СУБД.
• Использование Библиотеки Стандартных Подсистем (БСП): В конфигурациях на базе БСП можно задействовать подсистему «Дополнительные реквизиты и сведения». Создав дополнительное сведение для документа, вы получаете хранение статусов в типовом независимом регистре ДополнительныеСведения без изменения структуры метаданных.