← На главную

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

Причины расхождения основной конфигурации и конфигурации поставщика

Проанализируем ключевые факторы, из-за которых конфигуратор фиксирует подобные аномалии:

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

Чем опасна рассинхронизация идентификаторов метаданных

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

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

Способ восстановления: фиктивное обновление конфигурации поставщика

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

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

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

Если при последующих обновлениях выясняется, что объекты задваиваются или определяются как новые из-за различий UUID, применим механизм ручного сопоставления. Разберем порядок действий:

1. В окне сравнения и объединения анализируем состав несовпадающих элементов. Если объект отображается как удаляемый в одной ветке и создаваемый в другой, открываем настройки сопоставления.
2. Используем пункт меню сопоставления объектов или контекстное меню, чтобы вручную указать соответствие между объектом основной конфигурации и объектом поставщика.
3. Проверяем, чтобы по результатам настройки в окне реструктуризации базы данных не было операций полного удаления таблиц СУБД для тех объектов, в которых хранятся рабочие данные.

Безопасный перенос доработок в расширения

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

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