Где хранятся дополнительные сведения в 1С

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

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

Механизм делится на две части: дополнительные реквизиты (жёстко привязаны к объекту и хранятся в его табличной части) и дополнительные сведения (хранятся в отдельном регистре сведений и могут присваиваться объекту независимо). Ниже разобрано, где физически находятся значения, как их найти запросом и как не сломать данные при прямой работе с таблицами.

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

В типовых конфигурациях на БСП (Управление торговлей, ERP, Бухгалтерия, ЗУП и другие) механизм реализован единообразно. Администратор или пользователь с правами настройки создаёт новое свойство через «Администрирование — Общие настройки — Дополнительные реквизиты и сведения». При этом в конфигураторе ничего не меняется: новое поле появляется динамически.

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

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

Где хранятся дополнительные реквизиты

Значения дополнительных реквизитов физически хранятся в табличной части объекта с именем ДополнительныеРеквизиты. Такая табличная часть есть у всех справочников и документов, к которым подключён механизм: «Номенклатура», «Контрагенты», «Партнеры», «Физические лица» и другие. В конфигураторе её видно в составе объекта.

Структура табличной части минимальна: колонка Свойство (ссылка на план видов характеристик «ДополнительныеРеквизитыИСведения»), колонка Значение (составной тип) и служебное поле ТекстоваяСтрока для длинных строк, не помещающихся в ограничение типа «Значение». Именно поэтому длинный текст иногда «теряется» в запросах, если читать только поле «Значение».

На уровне СУБД табличная часть — отдельная таблица с именем вида _Reference123_VT456 (для справочника) или аналогичная для документа. Прямой доступ к ней из SQL возможен, но безопаснее работать через язык запросов 1С: имена физических таблиц меняются при реструктуризации и различаются между базами.

ВЫБРАТЬ
	НоменклатураДополнительныеРеквизиты.Ссылка КАК Товар,
	НоменклатураДополнительныеРеквизиты.Свойство КАК Свойство,
	НоменклатураДополнительныеРеквизиты.Значение КАК Значение
ИЗ
	Справочник.Номенклатура.ДополнительныеРеквизиты КАК НоменклатураДополнительныеРеквизиты
ГДЕ
	НоменклатураДополнительныеРеквизиты.Свойство = &Свойство

Где хранятся дополнительные сведения

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

Такая архитектура даёт важное следствие: запись сведения не изменяет сам объект. Элемент справочника не перепроводится и не помечается как изменённый, что удобно для обменов по правилам конвертации — регистрация изменений на объекте не срабатывает. Обратная сторона: при удалении объекта записи регистра удаляются не всегда автоматически, зависит от настроек и версии БСП.

ВЫБРАТЬ
	ДополнительныеСведения.Объект КАК Объект,
	ДополнительныеСведения.Свойство КАК Свойство,
	ДополнительныеСведения.Значение КАК Значение
ИЗ
	РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения
ГДЕ
	ДополнительныеСведения.Объект = &Ссылка

На уровне СУБД регистр — таблица вида _InfoRg…. При большом количестве объектов и свойств таблица растёт быстро, поэтому в крупных базах на неё накладывают индексы по умолчанию платформы, а периодическую чистку от «осиротевших» записей (свойство удалено, а записи остались) выполняют регламентно.

Где хранятся описания свойств и списки значений

Кроме самих значений, механизм использует ещё несколько объектов метаданных. Само свойство (его имя, тип, заголовок) — элемент плана видов характеристик ДополнительныеРеквизитыИСведения. Если для свойства задан список допустимых значений, они хранятся в справочнике ЗначенияСвойствОбъектов (в новых версиях БСП — ЗначенияСвойствОбъектовИерархия для иерархических списков).

Принадлежность свойств конкретному виду объектов определяется наборами: справочник НаборыДополнительныхРеквизитовИСведений содержит предопределённые элементы вида «Справочник_Номенклатура», «Документ_РеализацияТоваровУслуг» и т.п., а в его табличных частях перечислены свойства, доступные для этого вида. Если свойство «пропало» из карточки объекта — чаще всего оно исключено из набора, а не удалены данные.

Как найти и прочитать значения запросом

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

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

1. 1
   Откройте карточку объекта и определите: поле редактируется в форме (реквизит) или через «Ещё — Дополнительные сведения» (сведение).
2. 2
   Откройте «Администрирование — Дополнительные реквизиты и сведения», найдите свойство в списке и проверьте его тип и набор.
3. 3
   Для реквизита выполните запрос к табличной части объекта с отбором по свойству; для сведения — запрос к регистру «ДополнительныеСведения» с отбором по объекту.
4. 4
   Если значение длинный текст — проверьте поле «ТекстоваяСтрока» табличной части, а не только «Значение».
5. 5
   Проверьте результат на 2–3 объектах, где значение точно заполнено вручную.

Риски при прямой работе с таблицами и обмене

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

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

Как проверить целостность данных

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

Часто задаваемые вопросы