Почему при сравнении/объединении в 1С не заполняется регистратор в регистре и как это исправить?

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

Выясним основную причину: проблема идентификаторов (UUID)

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

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

Разберем влияние хранилища конфигурации

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

1. У регистра сведений или накопления есть свойство Регистраторы.
2. У документа есть свойство Движения.

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

Пошаговая инструкция по решению проблемы

Для исправления ситуации и успешного обновления БД рекомендуется последовательно выполнить следующие действия:

1. Полный захват связанных объектов в хранилище.

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

2. Проверка настроек сравнения и объединения.

При выполнении процедуры в окне настройки сравнения/объединения обратите внимание на следующие моменты:

• Проверьте, установлена ли настройка «Разрешить удаление объектов». Иногда это необходимо, чтобы система могла корректно пересоздать связи, если идентификаторы объектов различаются.
• Убедитесь, что для проблемных регистров в колонке «Режим объединения» стоит «Взять из файла», а не просто «Объединять».
• Используйте кнопку «Действия» — «Отметить по подсистемам файла», чтобы принудительно обновить коллекцию свойств объектов.

3. Глубокая очистка кэша.

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

1. Завершите все сеансы работы с базой.
2. Очистите каталог cache внутри папки, где физически расположено файловое хранилище (если используется файловый вариант).
3. Запустите конфигуратор с параметром /ClearConfigCache. Это принудительно очистит кэш метаданных.

Метод «Обходного пути» через отключение от хранилища

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

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

Использование программных средств диагностики

Для понимания того, что именно видит система, можно воспользоваться выгрузкой конфигурации в файлы XML. Рассмотрим этот процесс:

1. Выгрузите конфигурацию в файлы через меню «Конфигурация» — «Выгрузить конфигурацию в файлы».
2. Найдите XML-файл вашего регистра (например, AccumulationRegister.ВозвратыТоваров.xml).
3. Проанализируйте секцию <Registers> или <Recorders>. Если список пуст или содержит некорректные ссылки, значит, проблема произошла на этапе записи метаданных в файл или из файла.

Пример структуры метаданных регистра в XML (фрагмент):

<RecordSet>
    <Properties>
        <Name>ВозвратыТоваров</Name>
        <RegisterRecordsWritingOnPost>WriteSelectedOnly</RegisterRecordsWritingOnPost>
        <FullTextSearch>Use</FullTextSearch>
        <ListPresentations/>
        <ExtendedListPresentations/>
        <Explanation/>
        <Recorders>
            <xr:Item xsi:type="xr:MDObjectRef">Document.ВозвратТоваровОтКлиента</xr:Item>
        </Recorders>
    </Properties>
</RecordSet>

Если вы видите, что в XML-файле регистраторы присутствуют, а в конфигураторе — нет, это верный признак повреждения локального кэша или системных таблиц Config/ConfigSave. В таких случаях часто помогает полная загрузка конфигурации (Меню «Конфигурация» — «Загрузить конфигурацию из файла») вместо сравнения/объединения, однако будьте осторожны: этот метод полностью заменяет вашу конфигурацию и может привести к потере несинхронизированных правок.

Резюме

Ситуация, когда регистраторы «исчезают» при обновлении БД, чаще всего вызвана комбинацией работы с хранилищем без захвата всех зависимых объектов и различием в UUID метаданных. Всегда проверяйте, захвачены ли документы-регистраторы, и в случае повторяющихся ошибок используйте метод с временным отключением от хранилища и полной очисткой кэша метаданных.