Подчиненные объекты конфигурации 1С: устройство, виды и практика работы

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

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

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

Что считается подчиненным объектом конфигурации

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

Ключевой признак подчиненности — жизненный цикл. При удалении родительского объекта все его подчиненные объекты удаляются автоматически. При копировании родителя копируются и вложенные элементы. Именно это отличает подчиненный объект от независимого: справочник «Номенклатура» можно удалить, оставив справочник «Контрагенты», но нельзя удалить реквизит «Артикул», сохранив его где-то отдельно от владельца.

Важно не путать подчиненные объекты конфигурации с подчиненными справочниками — это разные понятия. Подчиненный справочник (например, «Договоры контрагентов», владельцем которого является «Контрагенты») — самостоятельный объект метаданных верхнего уровня, просто связанный ссылкой владельца. А вот его реквизиты и табличные части — уже подчиненные объекты конфигурации.

Какие виды подчиненных объектов встречаются на практике

Набор подчиненных объектов зависит от типа родителя. Для большинства прикладных объектов характерны следующие вложенные элементы:

• Реквизиты — поля объекта, хранящие отдельные значения (артикул, ставка НДС, комментарий). Есть у справочников, документов, планов счетов, отчетов, обработок.
• Табличные части — вложенные таблицы (список товаров в накладной). У табличной части есть собственные подчиненные объекты — реквизиты табличной части.
• Измерения, ресурсы, реквизиты регистров — определяют разрезы хранения, хранимые показатели и дополнительные поля регистров сведений и накопления.
• Формы — описания экранных представлений объекта (форма элемента, форма списка, форма документа).
• Макеты — шаблоны печатных форм и схем компоновки данных.
• Команды — прикладные действия, привязанные к объекту (печать, заполнение).
• Движения — для документов-регистраторов: указание, по каким регистрам документ формирует записи.
• Предопределенные элементы — у справочников, планов счетов, планов видов характеристик: элементы, создаваемые на уровне конфигурации.
• Признаки учета — у планов счетов; виды субконто — также подчиненная структура плана счетов.

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

Как устроена иерархия: родитель и вложенные элементы

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

Такая адресация используется при универсальных алгоритмах: обходе метаданных для проверки прав, построении произвольных отчетов, механизмах сопоставления при обмене. Знание пути к подчиненному объекту позволяет программно определить его тип, длину, состав и признаки использования.

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

Для Каждого Реквизит Из Метаданные.Документы.РеализацияТоваровУслуг.Реквизиты Цикл
    Сообщить(Реквизит.Имя + " : " + Строка(Реквизит.Тип));
КонецЦикла;

Как добавить или изменить подчиненный объект в конфигураторе

Работа ведется в конфигураторе, в окне дерева конфигурации. Последовательность типовая для любого вида подчиненных объектов:

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

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

1. 1
   Создайте резервную копию или выгрузку dt рабочей базы
2. 2
   Добавьте реквизит в дереве конфигурации и задайте тип
3. 3
   Обновите конфигурацию БД и проверьте окно реструктуризации на предупреждения
4. 4
   Откройте форму объекта в режиме предприятия и убедитесь, что реквизит доступен и сохраняется
5. 5
   Проверьте отчеты и обмены, где используется объект, — новый реквизит может потребовать доработки правил

Ограничения платформы и влияние на данные

Подчиненные объекты жестко связаны с физической структурой базы, поэтому платформа накладывает ряд ограничений. Имя объекта должно быть уникальным в рамках родителя и соответствовать правилам идентификаторов встроенного языка. Длина строковых реквизитов фиксированной длины ограничена; неограниченная строка не может использоваться в измерениях регистров и в ряде индексируемых полей.

Изменение состава измерений регистра накопления или сведений — одна из самых тяжелых операций: добавление измерения меняет ключ уникальности записей и может вызвать конфликты существующих данных. Удаление реквизита необратимо уничтожает хранящиеся в нем значения. Добавление обязательного реквизита к объекту с существующими данными приведет к тому, что старые элементы не пройдут проверку заполнения при перезаписи.

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

Типичные ошибки при работе с подчиненными объектами

Большинство проблем возникает не при создании, а при изменении уже используемых объектов на базе с данными. Ниже — ошибки, которые встречаются чаще всего.

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

Как проверить результат после изменений

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

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

Частые вопросы