← На главную

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

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

Выясним причину проблемы и почему различаются идентификаторы

Каждый объект метаданных в конфигурации 1С имеет свой внутренний уникальный идентификатор (GUID). На физическом уровне СУБД этот идентификатор связывается с именем конкретной таблицы базы данных (например, _Reference123 или _Document456). Данная связка хранится во внутренних таблицах структуры конфигурации (таких как DBNAMES и DBSCHEMA).

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

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

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

Вариант 1. Штатное массовое изменение правил поддержки через корень конфигурации

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

Разберем данный процесс по шагам:

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

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

Вариант 2. Переименование конфликтующих объектов и перенос данных

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

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

1. Находим объекты метаданных, по которым при сравнении выявлены расхождения GUID.
2. Добавляем к именам этих объектов префикс (например, Удалить_СпособыЗаполненияЦен или Удалить_Номенклатура). При этом синонимы можно оставить прежними.
3. Обновляем конфигурацию базы данных. Так как объект был переименован, платформа переименует существующую физическую таблицу в базе данных, сохранив всю содержащуюся в ней информацию.
4. Выполняем штатное объединение или обновление с конфигурацией поставщика. В результате в конфигурации появятся типовые объекты с правильными идентификаторами поставщика, а рядом останутся переименованные объекты со старыми данными.
5. С помощью универсальных обработок (например, группового изменения реквизитов, обработки «Поиск и замена дублей» или специализированного алгоритма) переносим данные из таблиц с префиксом Удалить_ в новые таблицы с типовыми идентификаторами.
6. После переноса данных и перепривязки ссылок старые переименованные объекты можно безопасно удалить из метаданных конфигурации.

Вариант 3. Перенос данных в чистую типовую базу через «Конвертацию данных»

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

Разберем последовательность выполнения этой процедуры:

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

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

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

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