← На главную

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

На первый взгляд задача кажется тривиальной — достаточно загрузить типовой файл конфигурации (.cf) и обновить базу данных. Однако за видимой простотой скрываются серьезные риски нарушения ссылочной целостности, повреждения структуры базы данных на уровне СУБД и появления трудноуловимых ошибок у пользователей. В этой статье мы подробно разберем все скрытые технические проблемы такого перехода, ответим на вопрос о необходимых тестах и приведем пошаговое руководство по безопасному откату к типовой конфигурации.

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

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

1. Нарушение ссылочной целостности и появление битых ссылок:

1. Составные типы данных: В типовых конфигурациях многие реквизиты (например, ДокументОснование, Владелец, Регистратор) имеют составной тип данных. Если при кастомизации в этот тип были добавлены отраслевые документы или справочники, то после их удаления все ссылки в существующих типовых документах превратятся в битые конструкции вида <Объект не найден...>. Это может заблокировать проведение типовых документов или вызывать критические ошибки при формировании отчетов.
2. Системные механизмы и регистры: Отраслевые объекты могли быть задействованы в общих механизмах платформы и БСП (Библиотеки стандартных подсистем). Например, записи об отраслевых документах могли попасть в регистры сведений, отвечающие за версионирование объектов, историю изменений, присоединенные файлы или регистрацию изменений для планов обмена. Если удалить сами метаданные документов, в этих регистрах останутся «мусорные» записи с битыми ссылками, что в будущем приведет к сбоям при синхронизации данных или обновлении ИБ.

2. Проблемы с интерфейсом и пользовательскими настройками:

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

3. Взаимосвязи в коде и свойствах метаданных:

Если отраслевые объекты были включены в составные свойства типовой конфигурации, такие как Определяемые типы (DefinedTypes), Подписки на события (EventSubscriptions) или Функциональные опции (FunctionalOptions), простое удаление объектов без предварительного анализа связей приведет к тому, что конфигурация не пройдет проверку на целостность, а программный код начнет выдавать ошибки компиляции при вызове процедур на сервере.

4. Проблемы на уровне СУБД при реструктуризации:

При удалении большого объема метаданных (особенно если отраслевые регистры содержали миллионы записей) СУБД (MS SQL, PostgreSQL) выполняет масштабную операцию реструктуризации физических таблиц. Это может привести к переполнению файла транзакций (лог-файла СУБД) или временной базы TempDB, из-за чего процесс обновления конфигурации базы данных может прерваться, оставив базу в промежуточном, неработоспособном состоянии.

Какие инструменты тестирования должны быть под рукой?

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

1. Встроенная проверка конфигурации:

Этот инструмент запускается непосредственно в Конфигураторе через меню Конфигурация -> Проверка конфигурации. Перед запуском обязательно установите флаги «Проверка логической целостности конфигурации», «Поиск некорректных ссылок», а также выберите проверку для всех режимов работы (Тонкий клиент, Веб-клиент, Сервер и т.д.). Данный тест выявляет нарушения связей внутри самой структуры метаданных (например, ссылки на удаленные реквизиты в макетах, схемах компоновки данных или формах).

2. Синтаксический контроль модулей:

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

3. Тестирование и исправление базы данных (ТиИ):

Это важнейший шаг после изменения физической структуры БД. Запускается через меню Администратор -> Тестирование и исправление. Для очистки базы от «фантомных» записей и битых ссылок выберите режим «Проверка ссылочной целостности». В настройках обработки обязательно укажите правила обработки битых ссылок: «Очищать ссылки» или «Удалять объект» (в зависимости от логики конкретного реквизита), чтобы система корректно вычистила упоминания удаленных объектов из типовых таблиц.

4. Дымовое тестирование (Smoke-тесты):

Поскольку пользователи могут столкнуться с ошибками непосредственно при работе в режиме «Предприятие», крайне важно автоматизировать проверку открытия форм. Для этого применяют специализированные инструменты тестирования, например, Vanessa Automation или Автоматизированную проверку конфигураций (АПК). Сценарии дымовых тестов в автоматическом режиме имитируют действия пользователей: открывают формы всех справочников и документов, пытаются записать типовые документы, формируют основные отчеты (Оборотно-сальдовую ведомость, Анализ субконто). Это позволяет гарантировать, что интерфейс системы не «упадет» при реальной работе.

Пошаговая инструкция по возврату к типовой конфигурации

Рассмотрим безопасный и проверенный практикой алгоритм перехода от объединенной измененной конфигурации к чистой типовой версии поставщика.

Шаг 1. Создание резервной копии и разворачивание тестового контура

Ни в коем случае не выполняйте эти действия сразу на рабочей базе данных! Сделайте полную резервную копию информационной базы (выгрузку в .dt или средствами СУБД) и разверните ее на отдельном тестовом сервере.

Шаг 2. Предварительный анализ и выгрузка уникальных данных

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

Шаг 3. Снятие конфигурации с поддержки

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

Шаг 4. Загрузка чистой типовой конфигурации поставщика

Скачайте официальный дистрибутив типовой конфигурации (например, 1С:Комплексная автоматизация) точно такого же релиза, какой используется в вашей текущей базе. Извлеките файл полной конфигурации (1cv8.cf). В Конфигураторе тестовой базы выберите пункт меню Конфигурация -> Загрузить конфигурацию из файла и укажите чистый 1cv8.cf. При этом платформа автоматически сопоставит объекты, удалит все лишние отраслевые метаданные, очистит нетиповые реквизиты и вернет конфигурацию на полную поддержку поставщика («поставит на замок»).

Шаг 5. Применение изменений базы данных (Реструктуризация)

Нажмите клавишу F7 или кнопку «Обновить конфигурацию базы данных». На этом этапе платформа выдаст список удаляемых объектов метаданных (таблиц и полей). Внимательно ознакомьтесь со списком и подтвердите изменения. Дождитесь окончания реструктуризации таблиц на уровне СУБД.

Шаг 6. Запуск в режиме «Предприятие» и выполнение обработчиков обновления

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

Шаг 7. Проведение Тестирования и Исправления (ТиИ)

Вернитесь в Конфигуратор и запустите процедуру Тестирования и Исправления (как описано в разделе инструментов тестирования) с включенной проверкой ссылочной целостности и опцией очистки битых ссылок. Это позволит полностью обезопасить базу от «мусора» в таблицах СУБД.

Шаг 8. Финальное тестирование и перенос изменений на рабочую базу

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