Обновление 1С:Документооборот ПРОФ до версии 2.1.38.11: изменения и подготовка к миграции в редакцию 3.0

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

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

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

Что известно о релизе 1С:Документооборот ПРОФ 2.1.38.11

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

Поэтому номер релиза сам по себе не дает основания сразу обновлять рабочую информационную базу. Сначала нужно проверить, какие изменения относятся к используемым функциям и какие ограничения указал разработчик.

Какие сведения необходимо подтвердить по официальной документации

Для принятия решения запросите или найдите комплект материалов по версии 2.1.38.11. В него должны входить:

описание релиза с перечнем новых возможностей и измененных объектов;
список исправленных ошибок с условиями их проявления;
инструкция по обновлению и допустимый путь перехода с текущей версии;
требования к версии платформы «1С:Предприятие 8»;
сведения о совместимости с расширениями, внешними обработками, печатными формами и интеграциями;
описание изменений, связанных с редакцией 3.0;
методика миграции, если переход с редакции 2.1 действительно поддерживается начиная с версии 3.0.21.

Отдельно зафиксируйте дату и место получения документации. Для рабочей базы важно понимать, какая редакция описания относится к установленному комплекту поставки и договору сопровождения. Практический подход к проверке доступности обновлений и совместимости с поддержкой можно сопоставить с разбором обновления другой конфигурации 1С.

Кому особенно важно проверить этот релиз

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

в организации регулярно сканируют бумажные документы и передают их на регистрацию, согласование или исполнение;
в базе настроены сложные бизнес-процессы с несколькими маршрутами, делегированием и контролем сроков;
с системой работают десятки или сотни пользователей с разными ролями и уровнями доступа;
используются расширения, внешние обработки, нестандартные печатные формы или измененные роли;
настроены обмены с ЭДО, учетными системами, архивами, почтой или другими внешними сервисами;
в информационной базе хранится большой объем вложений и исторических документов.

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

Что нового в 1С:Документооборот ПРОФ 2.1.38.11

Ниже перечислены заявленные направления релиза и практические проверки, которые помогут оценить их влияние. Конкретные изменения нельзя выдавать за подтвержденные до сверки с официальным описанием версии 2.1.38.11.

Обновление библиотек и связанные зависимости

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

После обновления проверьте минимум пять групп сценариев:

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

Для каждой доработки зафиксируйте владельца и результат проверки. Ошибки компиляции, пропавшие команды формы, сообщения о недоступном методе или изменения состава прав нужно передать разработчику до обновления рабочей базы.

Полезно сравнить подход к анализу библиотек с разбором релиза «1С:Документооборот КОРП». Это другой продукт и другой релиз, поэтому его перечень нельзя переносить на ПРОФ, но структура проверки зависимостей подходит для подготовки тестов.

Изменения производственного календаря

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

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

Результат проверки должен включать исходную дату, рассчитанный срок, статус поручения и время срабатывания задания. Если сроки отличаются от ожидаемых, сначала проверьте календарь и настройки конкретного процесса, затем анализируйте обновление библиотек.

Автоматическая подача документов при сканировании

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

Точный алгоритм нужно проверить по инструкции релиза. Без нее нельзя утверждать, какие реквизиты заполняются автоматически, используется ли распознавание текста, как система выбирает карточку и на каком шаге запускается маршрут.

На тестовой базе проверьте:

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

Делопроизводитель проверяет полный пользовательский путь, администратор контролирует права и ошибки, а руководитель подтверждает, что документ попадает к нужному исполнителю без дополнительной ручной операции.

Исправления ошибок в релизе 2.1.38.11

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

Для учета результатов используйте таблицу:

Область	Что зафиксировать до обновления	Ожидаемый результат	Ответственный
Документ	Текст ошибки, шаги и пользовательская роль	Операция завершается без ошибки	Делопроизводитель
Права	Доступ к форме, файлу и истории	Разрешения совпадают с матрицей доступа	Администратор
Маршрут	Исполнитель, срок и переход состояния	Документ движется по заданной схеме	Владелец процесса
Фоновые операции	Расписание и последнее сообщение	Задание выполняется без критичной ошибки	Администратор

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

Какие исправления проверить после обновления

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

История изменений и контроль действий пользователей

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

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

Права доступа и рабочие роли

Сравните результаты с матрицей прав, которую нужно сохранить до обновления. Для каждой роли проверьте чтение и изменение документов, просмотр и добавление вложений, запуск согласования, просмотр истории, выполнение административных операций и доступ к уничтожению дел.

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

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

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

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

Уничтожение дел и операции с архивными данными

Операции уничтожения дел связаны с необратимым удалением информации. Все проверки проводите на копии базы или на специально подготовленных тестовых данных, которые не нужны для учета.

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

Если после обновления изменились доступные команды, состав отбора или сведения в протоколе, остановите проверку и привлеките администратора и владельца архива.

Восстановление пароля и доступ пользователей

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

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

Регламентные задания и фоновые операции

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

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

Нужно ли обновлять 1С:Документооборот ПРОФ до версии 2.1.38.11

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

Когда обновление имеет высокий приоритет

Перенесите обновление в верхнюю часть плана работ, если выполняется хотя бы одно условие:

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

Даже при высоком приоритете сначала сделайте резервную копию, проверьте ее восстановление и выполните обновление на копии базы. Критичное исправление снижает операционный риск только тогда, когда новый релиз совместим с конкретной конфигурацией.

Когда необходима дополнительная проверка совместимости

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

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

Как оценить примерное время миграции на редакцию 3.0

Точный срок перехода нельзя вывести из исходной версии 2.1.38.11. На него влияют объем данных, количество вложений, число пользователей, качество справочников, доработки, расширения, интеграции, требования к простою и количество циклов исправлений.

Достоверная оценка появляется после инвентаризации и пробной миграции. До этого можно составить перечень работ и определить факторы риска, но нельзя обещать универсальное количество часов или дней.

Какие данные нужны для предварительной оценки

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

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

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

Из каких этапов складывается срок перехода

План перехода обычно включает несколько последовательных этапов:

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

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

Почему пробная миграция обязательна

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

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

Подготовка данных к переходу на редакцию 3.0

Подготовку нужно вести как отдельный проект с ответственными и контрольными точками. Версию 2.1.38.11 можно использовать для приведения текущей базы в порядок, но сам факт доступности миграции на 3.0 начиная с версии 3.0.21 требует подтверждения официальной методикой.

Инвентаризация конфигурации, расширений и доработок

Составьте реестр компонентов, которые могут потребовать повторной настройки:

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

Для каждой позиции укажите владельца, назначение, частоту использования и критичность. Компонент без владельца нельзя считать готовым к переходу: после миграции будет сложно определить, кто подтвердит его работоспособность.

Проверка и очистка данных

До пробного перехода проверьте дубли документов и контрагентов, незавершенные процессы, некорректные ссылки, устаревших пользователей, архивные данные и неиспользуемые настройки. Отдельно оцените объем вложений и документы с поврежденными или недоступными файлами.

Удаление данных допускается только по утвержденному регламенту и после резервного копирования. Для подготовки можно пометить объекты к архивированию или исключить их из тестового набора, но не удалять их без согласования с владельцем информации.

Подготовка прав, маршрутов и регламентных заданий

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

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

Проверка интеграций и внешних обменов

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

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

Когда миграция на редакцию 3.0 будет доступна

В исходных материалах нет подтвержденной методики перехода с «1С:Документооборот ПРОФ» редакции 2.1 на редакцию 3.0. Не подтверждено и условие, что соответствующая миграция доступна начиная с версии 3.0.21. Поэтому эту версию нужно рассматривать как заявленное техническое условие, пока разработчик не подтвердит поддерживаемый путь перехода.

Что проверить в методике миграции

До утверждения плана перехода закройте следующие вопросы:

какие исходные версии редакции 2.1 поддерживаются;
требуется ли предварительное обновление до 2.1.38.11 или другого релиза;
какая минимальная версия платформы нужна для редакции 3.0;
какие документы, файлы, справочники, права и истории переносятся;
как обрабатываются вложения и архивные данные;
что происходит с расширениями, внешними обработками и печатными формами;
нужна ли конвертация или ручная настройка объектов;
кто получает право запускать миграцию и как контролируется результат.

Ответы должны находиться в официальной инструкции, а не только в устной оценке подрядчика. Если методика допускает ограничения, включите их в критерии приемки и план возврата.

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

Версия 3.0.21 может задать минимальное техническое условие, но она не описывает состояние конкретной базы. Сроки меняют доработки, качество данных, число интеграций, объем файлов, количество ролей и требования бизнеса.

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

Пошаговый план безопасного обновления и миграции

Используйте последовательность ниже как рабочий чек-лист. Каждый этап должен иметь ответственного и зафиксированный результат.

Проверки до начала работ

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

До старта работ пользователи должны завершить редактирование документов или получить четкое окно недоступности. Активные согласования и незакрытые задания внесите в отдельный список для последующей проверки.

Проверки сразу после обновления

Выполните проверки в таком порядке:

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

Критичные ошибки фиксируйте с указанием времени, пользователя, документа и последовательности действий. Не ограничивайтесь сообщением «работает»: приемка должна подтверждать конкретный результат для каждой роли.

Критерии готовности к переходу на редакцию 3.0

Переход можно выносить на согласование, когда выполнены все основные условия:

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

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