Как правильно проверить базу 1С после масштабного обновления нетиповой конфигурации?

Обновление конфигурации 1С, пропустившей десятки релизов за несколько лет (например, перенос доработок в 1С:Управление производственным предприятием с релиза 1.3.29 на 1.3.83), сопряжено с высокими рисками потери данных и нарушения бизнес-логики. Часто у специалистов возникает вопрос: достаточно ли успешного выполнения стандартной синтаксической проверки конфигуратора и сходимости отчета Оборотно-сальдовая ведомость, чтобы сразу переносить изменения в рабочую базу, или необходимо дополнительное тестирование?

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

Почему синтаксической проверки и ОСВ недостаточно

Проанализируем ограничения экспресс-проверок, которые создают ложное ощущение полной готовности базы:

1. Ограниченность синтаксического контроля. Штатная проверка конфигурации в Конфигураторе проверяет корректность объявлений процедур и базовую ссылочную целостность объектов метаданных. Однако она не способна обнаружить ошибки в динамически формируемом коде, текстах запросов, формируемых через конкатенацию строк, а также в вызовах процедур через функции Выполнить(), Вычислить() или методы работы со структурами вроде ЗаполнитьЗначенияСвойств().
2. Скрытые изменения метаданных в типовом коде. В процессе развития типовой конфигурации разработчики вендора могут переименовать или удалить типовые реквизиты документов и справочников, изменить типы значений или переместить экспортные процедуры из одних общих модулей в другие. Если в кастомном коде использовались старые имена реквизитов или удаленные функции, синтаксический контроль при отсутствии явных жестких связей может не зафиксировать ошибку, но при проведении документа или открытии формы возникнет критическое исключение.
3. Поверхностность отчета ОСВ. Оборотно-сальдовая ведомость отражает исключительно проводки по плану счетов бухгалтерского учета. При этом вне поля зрения остаются регистры накопления (взаиморасчеты, складские остатки, партии, НДС), регистры сведений и регистры расчета. Документ может сформировать идентичные проводки в БУ, но полностью исказить управленческие или оперативные регистры.
4. Ограничения прав доступа (RLS). Конфигуратор не проверяет синтаксис условий в шаблонах RLS при изменении состава реквизитов. Если пользователь с ограниченными правами попытается открыть список документов, база может аварийно завершить сеанс из-за ошибки в тексте ограничения.

Пошаговый регламент проверки обновленной базы

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

Шаг 1. Анализ отличий и правильный перенос доработок

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

1. Берем исходную конфигурацию с доработками (старая рабочая база).
2. Берем чистую типовую конфигурацию поставщика того же старого релиза.
3. Сравниваем их между собой, чтобы получить исчерпывающий список всех добавленных объектов, реквизитов, измененных форм и процедур.
4. Выполняем обновление конфигурации на файл .cf целевого релиза через меню Конфигурация — Поддержка — Обновить конфигурацию с включенным режимом трехстороннего объединения. Это позволяет наглядно видеть, где типовой код изменился от поставщика, а где присутствуют наши кастомные правки.

Шаг 2. Контроль отложенных обработчиков обновления данных

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

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

Шаг 3. Глубокая сверка движений документов по всем регистрам

Вместо поверхностной проверки по ОСВ применим методику тотального сравнения движений документов:

1. Разворачиваем копию базы ДО обновления и копию ПОСЛЕ обновления.
2. Выбираем контрольный период (например, последний закрытый квартал или месяц).
3. Выполняем групповое перепроведение документов за этот период в обеих базах.
4. С помощью специализированных внешних обработок выгружаем движения по всем регистрам накопления, сведений и бухгалтерии из базы ДО и базы ПОСЛЕ, а затем производим их построчное сопоставление.
5. При обнаружении расхождений анализируем модули проведения конкретных документов и алгоритмы заполнения регистров.

Шаг 4. Проверка внешнего контура и подключаемого оборудования

Разберем компоненты, которые находятся за пределами основной конфигурации:

1. Внешние печатные формы, отчеты и обработки: в новых релизах конфигураций часто меняются контракты процедур печати (например, параметры процедуры Печать(), структура передаваемых коллекций и табличных документов). Все внешние файлы необходимо подключить к тестовой базе и проверить их формирование.
2. Торговое оборудование: если обновление выполнялось ради перехода на онлайн-кассы и требований 54-ФЗ, обновляется Библиотека подключаемого оборудования (БПО). Необходимо протестировать работу фискальных регистраторов и сканеров с новыми версиями драйверов на тестовом рабочем месте.
3. Интеграции и обмен данными: проверяем выгрузки в смежные системы (например, правила обмена с 1С:Бухгалтерия предприятия) на реальных тестовых пакетах данных.

Шаг 5. Организация пользовательского тестирования

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

1. Предоставляем пользователям доступ к обновленной копии базы с актуальными данными.
2. Формируем список сквозных пользовательских сценариев: создание и проведение основных документов (поступления, реализации, перемещения, закрытие месяца, начисление зарплаты, кассовые чеки).
3. Пользователи выполняют свои ежедневные операции в тестовой базе, проверяя корректность автозаполнения форм, печатных форм и проведения документов с теми правами доступа, под которыми они работают в реальности (для выявления ошибок RLS).

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