Почему после обновления 1С:Документооборот документы стали «Не утвержден» и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1С:Документооборот IT и автоматизация бизнеса
← На главную

При обновлении конфигурации 1С:Документооборот с релиза 2.1.7.9 на релизы 2.1.8–2.1.9 многие администраторы и разработчики сталкиваются с неприятной ситуацией: ранее утвержденные внутренние документы внезапно получают статус «Не утвержден», несмотря на то, что по ним успешно завершены соответствующие бизнес-процессы и в истории зафиксирован факт утверждения. Разберем детально, почему это происходит, как устроена новая архитектура и какими способами можно восстановить корректные данные.

Выясним причину возникновения проблемы

В релизах ветки 2.1.8 и 2.1.9 разработчики платформенного решения существенно переработали логику согласования, подписания и утверждения документов:

  1. Разделение понятий «Утверждение» и «Подписание»: В старых версиях (2.1.7 и ранее) для справочника Справочник.ВнутренниеДокументы использовался единый реквизит Утвердил (хотя на форме он мог отображаться с подписью «Подписал»). В новой концепции эти процессы строго разделены: появился отдельный реквизит Подписал для подписания и табличная часть ГрифыУтверждения для множественного утверждения.
  2. Динамический расчет статуса: Статус документа на форме в новых релизах вычисляется динамически на основании наличия строк в табличной части ГрифыУтверждения и настроек конкретного вида документа. Если табличная часть пуста, статус автоматически сбрасывается в «Не утвержден», даже если в регистре сведений СостоянияДокументов или в бизнес-процессах записано иное.
  3. Отсутствие мигратора в релизах 2.1.8–2.1.9: При обновлении на указанные промежуточные версии штатные процедуры обновления информационной базы не переносили исторические данные из старого реквизита в новую табличную часть.

Рассмотрим подробнее доступные варианты решения проблемы.

Способ 1. Обновление на релиз 2.1.10 или выше

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

Разберем по шагам порядок действий:

  1. Выполним резервное копирование информационной базы перед проведением любых работ.
  2. Обновим конфигурацию 1С:Документооборот до версии 2.1.10 или более актуальной.
  3. Запустим программу в режиме «Предприятие» и перейдем в раздел «Администрирование» → «Обслуживание» → «Результаты обновления программы».
  4. Убедимся, что все регламентные и отложенные процедуры обновления базы данных завершились успешно. При необходимости запустим выполнение отложенных обработчиков вручную.

Способ 2. Программный перенос данных в табличную часть «ГрифыУтверждения»

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

  1. Сформируем выборку документов, по которым зафиксировано завершение бизнес-процесса утверждения либо установлено состояние утверждения в регистре сведений СостоянияДокументов.
  2. Для каждого найденного документа проверим табличную часть ГрифыУтверждения. Если строк нет, добавим новую запись с указанием пользователя и даты утверждения.
  3. Запишем объект с отключением проверок, чтобы избежать блокировок по закрытым периодам и правам доступа.

Посмотрим на пример программной обработки таких документов:


Выборка = Справочники.ВнутренниеДокументы.Выбрать();

Пока Выборка.Следующий() Цикл
    
    // Проверяем необходимость заполнения
    Если Выборка.ПометкаУдаления Или Выборка.ЭтоГруппа Тогда
        Продолжить;
    КонецЕсли;
    
    // Если в табличной части уже есть грифы, пропускаем документ
    Если Выборка.ГрифыУтверждения.Количество() > 0 Тогда
        Продолжить;
    КонецЕсли;
    
    // Получаем состояние документа из регистра
    Отбор = Новый Структура("Документ", Выборка.Ссылка);
    Состояние = РегистрыСведений.СостоянияДокументов.ПолучитьПоследнее(Дата(1, 1, 1), Отбор);
    
    // Проверяем, был ли документ фактически утвержден
    Если Состояние.Состояние = Перечисления.СостоянияДокументов.Утвержден Тогда
        
        ДокументОбъект = Выборка.Ссылка.ПолучитьОбъект();
        ДокументОбъект.ОбменДанными.Загрузка = Истина;
        
        НоваяСтрока = ДокументОбъект.ГрифыУтверждения.Добавить();
        
        // Заполняем реквизиты грифа из регистра или старого реквизита
        Если ЗначениеЗаполнено(ДокументОбъект.Утвердил) Тогда
            НоваяСтрока.Утвердил = ДокументОбъект.Утвердил;
        ИначеЕсли ЗначениеЗаполнено(Состояние.Установил) Тогда
            НоваяСтрока.Утвердил = Состояние.Установил;
        КонецЕсли;
        
        НоваяСтрока.Дата = ?(ЗначениеЗаполнено(Состояние.Период), Состояние.Период, ДокументОбъект.Дата);
        
        Попытка
            ДокументОбъект.Записать();
        Исключение
            ЗаписьЖурналаРегистрации("ИсправлениеГрифов", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
        КонецПопытки;
        
    КонецЕсли;
    
КонецЦикла;

Важные технические нюансы и постобработка

При восстановлении данных обратим внимание на следующие особенности конфигурации:

  1. Режим загрузки данных: Применение свойства ОбменДанными.Загрузка = Истина является обязательным. Это позволяет избежать ошибок валидации обязательных полей, ограничений по правам доступа и запретов изменения документов, находящихся в архивных делах.
  2. Настройки видов документов: Перейдем в «НСИ» → «Виды документов» и убедимся, что для соответствующих видов внутренних документов включены флаги использования утверждения и/или подписания согласно принятому регламенту организации.
  3. Коллизия утверждения и подписания: Если в вашей компании исторически бизнес-процесс утверждения использовался для подписания приказов руководителем, такие документы после автоматического переноса получат гриф утверждения. При необходимости перенесите значение в реквизит Подписал аналогичным скриптом.
  4. Пересчет прав доступа: Если в базе используется ограничение прав по состояниям документов, после массового изменения табличных частей необходимо выполнить пересчет дескрипторов доступа (в разделе обслуживания), чтобы пользователи получили корректные права на чтение и работу с восстановленными документами.
← На главную