← На главную

В практике сопровождения баз 1С нередко встречаются нетиповые ситуации, когда при открытии окна настройки поддержки обнаруживаются сразу две конфигурации поставщика. Классический пример — одновременное присутствие в базе конфигураций Бухгалтерия предприятия ПРОФ и Бухгалтерия предприятия КОРП. Разберем природу этого явления, выясним, как безопасно отключить ненужную конфигурацию поставщика, и рассмотрим алгоритм выявления реальных доработок в сильно измененной информационной базе.

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

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

В этот момент платформа сохраняет в служебной таблице CONFIG базы данных второй независимый эталонный образ конфигурации поставщика. Поскольку конфигурация БП КОРП исторически создана на базе БП ПРОФ и наследует большинство внутренних идентификаторов объектов метаданных (UUID), объекты в дереве конфигурации не дублируются физически. Они начинают одновременно принадлежать правилам поддержки сразу двух разных конфигураций поставщика.

Как отключить ненужную конфигурацию поставщика

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

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

1. Создаем полную резервную копию информационной базы (выгрузка в .dt или средствами СУБД).
2. Открываем конфигуратор и переходим в главное меню: Конфигурация — Поддержка — Настройка поддержки.
3. В верхней части открывшегося окна находим список зарегистрированных конфигураций поставщика. В нашей ситуации там отображаются две строки: устаревшая БП ПРОФ и актуальная БП КОРП.
4. Выделяем курсором строку с конфигурацией БП ПРОФ и нажимаем кнопку Снять с поддержки.
5. Подтверждаем действие в окне предупреждения платформы и нажимаем Закрыть.
6. Применяем изменения в структуре базы данных нажатием клавиши F7 или через пункт меню Конфигурация — Обновить конфигурацию базы данных.

В результате платформа удалит из служебных таблиц базы образ конфигурации поставщика БП ПРОФ. При этом все объекты метаданных останутся на месте, а их правила поддержки продолжат определяться оставшейся конфигурацией БП КОРП.

Методика выявления доработок и отделения сторонних модулей

После отключения лишней поставки часто возникает задача: понять, какие доработки сделаны в типовом функционале БП КОРП, а какие объекты добавлены сторонними решениями (например, модулями путевых листов или бюджетирования). Выполним ревизию доработок с помощью сравнения с эталонным файлом поставщика.

Рассмотрим алгоритм локализации изменений:

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

Технические риски и ограничения при очистке метаданных

Если принято решение физически удалить неиспользуемые сторонние подсистемы из дерева метаданных, проанализируем ключевые технические риски:

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

Архитектурная альтернатива: переход на актуальную редакцию

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

Оптимальным решением является следующий подход:

1. Разворачивается чистая база актуального релиза конфигурации Бухгалтерия предприятия 3.0 КОРП.
2. Через механизмы выгрузки/загрузки XML или правила конвертации данных переносятся только нормативно-справочная информация и входящие бухгалтерские остатки.
3. Старая база переводится в режим архива (только для чтения), сохраняя исторические данные и исключая риски сбоев при масштабном ручном рефакторинге.