← На главную

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

Анализируем симптомы проблемы

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

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

Разберем по шагам: что происходит на уровне СУБД

Для того чтобы понять корень зла, проанализируем ситуацию с точки зрения хранения данных. Когда мы добавляем реквизит через расширение, платформа не меняет структуру основной таблицы справочника в базе данных (например, _Reference45). Вместо этого она создает вспомогательную таблицу расширения (например, _Reference45_Ext), где хранятся наши новые поля.

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

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

Воспроизведение проблемы на пустой базе

Чтобы убедиться, что это баг платформы, а не ошибка конкретной конфигурации, проведем эксперимент. Создадим пустую базу с двумя справочниками: Хозяин и Раб (где Хозяин является владельцем Раба). Заполним их данными и убедимся, что ТиИ проходит успешно. Затем:

1. Создадим расширение.
2. Добавим в справочник Хозяин новый реквизит через расширение.
3. Запустим ТиИ с флагами проверки целостности.

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

Решение 1: Изменение архитектуры хранения данных

Если ваша платформа находится в диапазоне версий 8.3.12 — 8.3.14, самым надежным способом будет отказ от добавления реквизитов непосредственно в справочники через расширения. Вместо этого рассмотрим использование Регистров Сведений.

Вместо добавления реквизита в справочник Контрагенты, создайте в расширении непериодический независимый регистр сведений (например, ДополнительныеДанныеКонтрагентов):

• Измерение: Контрагент (тип СправочникСсылка.Контрагенты).
• Ресурс: НашНовыйРеквизит (нужный вам тип).

Такой подход имеет ряд преимуществ:

1. Безопасность ТиИ: Регистры сведений в расширениях не вызывают сбоев в проверке владельцев справочников.
2. Целостность: При удалении объекта в основной базе, записи в регистре расширения можно очищать программно или оставить для истории.
3. Универсальность: Вы всегда можете получить данные простым запросом или через метод МенеджерРегистраСведений.Получить().

Решение 2: Переход на исправленные версии платформы

Фирма «1С» признала наличие этой проблемы в баг-трекере (ошибки типа «Корректность данных при использовании расширений»). Если бизнес-задача требует использования именно реквизитов в расширениях (например, для автоматического вывода в стандартные отчеты через СКД), необходимо обновить платформу.

Проанализируем стабильные релизы: проблема была массово исправлена в ветке 8.3.14.1565 и более поздних версиях. Также важно, чтобы Режим совместимости основной конфигурации и расширения соответствовал актуальным требованиям платформы. Использование режима совместимости «8.3.12» на платформе 8.3.15 иногда может провоцировать старые баги ТиИ.

Решение 3: Использование механизмов БСП (Дополнительные реквизиты)

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

Вместо расширения метаданных мы можем использовать стандартный интерфейс:

1. Администрирование — Общие настройки — Дополнительные реквизиты и сведения.
2. Добавьте нужный реквизит к справочнику Контрагенты.

Важный нюанс: Многие программисты избегают этого пути, так как считают, что к таким данным сложно обращаться. На самом деле, в СКД к ним можно обращаться «через точку», а программно это делается одной строкой кода БСП. Это на 100% безопасно при тестировании и исправлении базы.

Риски версионирования объектов

Выясним еще одну важную деталь. При добавлении реквизитов через расширение часто «ломается» механизм версионирования (хранение истории изменений объектов). В типовых решениях за это отвечает регистр сведений ВерсииОбъектов. При ТиИ система может выдавать ошибки в этом регистре, так как структура XML-сериализации объекта в расширении меняется, а механизмы БСП не всегда готовы к тому, что в объекте появились «неродные» поля из расширений. Если вы видите ошибки по этому регистру — это верный признак того, что расширение данных конфликтует с логикой платформы.

Краткие итоги и рекомендации

Подведем итог нашему исследованию:

• Никогда не запускайте ТиИ на рабочей базе с расширениями, добавляющими данные, без предварительного создания полной копии (желательно в формате .dt и средствами СУБД).
• Если вы используете платформу ниже 8.3.14.1565, избегайте добавления реквизитов справочников через расширение. Используйте Регистры Сведений.
• Если данные уже добавлены и ТиИ их удаляет, попробуйте временно отключить расширение (снять галку «Использовать»), провести ТиИ, а затем включить его снова. Но помните: если ТиИ настроено на очистку битых ссылок, оно может удалить данные в самой таблице расширения, так как без метаданных расширения эти колонки станут «мусором» для СУБД.
• Самый стабильный путь для долгосрочной разработки — добавление критически важных реквизитов в основную конфигурацию (снятие с поддержки только нужных объектов), а логику их обработки выносить в расширение. Это гарантирует выживание данных при любых манипуляциях с базой.