← На главную

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

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

Симптомы проблемы и их проявление

Давайте подробно разберем, как выглядит данная техническая неполадка на практике:

1. В конфигураторе создан новый иерархический справочник (например, в конфигурации «Управление производственным предприятием» на управляемых формах).
2. У справочника создано несколько предопределенных групп. При этом права пользователя настроены корректно (полный доступ, RLS отсутствует).
3. При интерактивном создании нового элемента внутри предопределенной группы поле Родитель автоматически заполняется ссылкой, но вместо понятного наименования группы выводится битая ссылка: <Объект не найден> (80fe0015170e1a0511e7df...).
4. В отладке в процедуре ПриСозданииНаСервере при вычислении выражения Объект.Родитель ссылка на группу определяется нормально, объект считывается, его реквизиты доступны.
5. Если открыть форму списка или интерактивно выбрать родителя из формы выбора, наименования групп отображаются корректно. Но при непосредственном выборе в поле ввода снова появляется <Объект не найден> с абсолютно другим внутренним идентификатором (UUID).
6. Временное «лечение» происходит, если пользователь физически открывает карточку этой предопределенной группы. Платформа принудительно считывает представление объекта, помещает его в локальный кэш сеанса, и до закрытия программы поле родителя отображается правильно.

Выясняем техническую причину: коварный копипаст

Разберем детально внутреннее устройство метаданных 1С, чтобы понять природу этого бага. Источником проблемы практически всегда является копирование объектов метаданных между разными конфигурациями через стандартный буфер обмена операционной системы (комбинацией клавиш Ctrl+C / Ctrl+V).

Когда мы копируем справочник из одной базы в другую, платформа «1С:Предприятие» пытается на лету создать новый объект метаданных и сопоставить его реквизиты, табличные части и предопределенные элементы. На уровне СУБД (например, MS SQL Server или PostgreSQL) соответствие между логической структурой конфигурации и физическими таблицами базы данных хранится в специальной системной таблице (в файловой версии это таблица Params, содержащая упакованный файл DBNames).

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

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

Как диагностировать повреждение метаданных

Если мы столкнулись с подобным поведением, нам необходимо провести диагностику базы данных. Проверить целостность метаданных можно несколькими путями.

Способ 1. Тестирование и исправление (ТИИ)

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

Способ 2. Интерактивная проверка через удаление

Для подтверждения догадки выполним следующие действия:

1. В конфигураторе временно снимем признак предопределенности у проблемных групп справочника.
2. Обновим конфигурацию базы данных (клавиша F7).
3. В режиме «1С:Предприятие» пометим эти группы на удаление.
4. Запустим стандартную обработку «Удаление помеченных объектов».

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

Пошаговое решение проблемы

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

Шаг 1. Очистка существующих данных

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

Шаг 2. Удаление сбойного объекта из метаданных

1. Откроем Конфигуратор.
2. Найдем в дереве метаданных сбойный справочник, вызовем контекстное меню и выберем пункт Удалить.
3. Применим изменения конфигурации базы данных (клавиша F7). На этом этапе платформа выполнит полную реструктуризацию таблиц СУБД и удалит все некорректные связи в таблице DBNames.

Шаг 3. Корректное создание объекта

Чтобы избежать повторного возникновения бага, мы должны категорически отказаться от копирования через буфер обмена (Ctrl+C / Ctrl+V) между разными окнами Конфигуратора. Вместо этого применим один из безопасных методов.

Вариант А. Ручное создание. Создадим справочник в дереве метаданных вручную «с нуля», аккуратно прописав все реквизиты, табличные части и создав предопределенные элементы.

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

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

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

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