Работа с дополнительными сведениями в платформе 1С:Предприятие 8.3 представляет собой гибкий механизм расширения функциональности без изменения основной структуры метаданных. Этот инструмент позволяет разработчикам добавлять произвольные реквизиты к объектам, не внося правки в саму конфигурацию, что особенно актуально при работе с типовыми решениями, где прямой доступ к коду ограничен. Правильное извлечение данных из этого слоя требует понимания внутренней архитектуры хранилища и использования специализированных методов платформы.
Основная сложность заключается в том, что значения дополнительных сведений не хранятся в явном виде в таблицах объекта бизнес-логики. Они располагаются в отдельной служебной таблице информационной базы, связанной с конкретным видом дополнительного сведения. Для получения этих данных программист должен использовать объекты метаданных или формировать специфические запросы, учитывающие тип хранимой информации и связь с объектом-владельцем. Ошибки в типизации или неверное указание вида сведений часто приводят к тому, что система возвращает пустые значения или генерирует исключения.
Архитектура хранения дополнительных сведений в 1С
Механизм дополнительных сведений построен на основе таблицы AdditionalInformation, которая является универсальным хранилищем для всех видов расширений. Каждая запись в этой таблице привязана к конкретному объекту конфигурации (справочник, документ, план счетов) через ссылку, а также к конкретному виду дополнительного сведения. Такая структура позволяет избежать дублирования полей в основных таблицах и обеспечивает высокую масштабируемость системы при добавлении новых атрибутов.
Значение самого сведения хранится в поле Value, тип которого определяется настройками вида дополнительного сведения. Это может быть строка, число, дата, булево значение или даже ссылка на другой объект. Важно понимать, что платформа автоматически осуществляет приведение типов при чтении, но при программном доступе необходимо явно указывать ожидаемый тип данных, чтобы избежать ошибок выполнения. Типизация данных является критическим аспектом при работе с этим механизмом.
Связь между объектом и дополнительным сведений осуществляется через уникальный идентификатор вида сведений. Этот идентификатор генерируется платформой при создании вида и остается неизменным в течение жизненного цикла конфигурации, если только вид не будет удален и создан заново. Использование имени вида сведений в коде является более читаемым подходом, однако обращение по имени требует дополнительных вычислительных ресурсов на преобразование имени в ссылку на метаданные.
⚠️ Внимание: При удалении вида дополнительного сведения все связанные с ним данные в таблице хранятся безвозвратно удаляются. Восстановить их стандартными средствами платформы невозможно, поэтому перед удалением видов необходимо убедиться в отсутствии критически важной информации.
Получение значения через объект метаданных
Наиболее надежным и рекомендуемым способом получения значения дополнительного сведения является использование объекта метаданных ВидДополнительногоСведенияОбъекта. Этот подход обеспечивает максимальную совместимость с различными версиями платформы и корректно обрабатывает все типы данных, включая составные типы. Для работы с этим объектом необходимо сначала получить ссылку на сам вид сведений, используя имя, заданное в конфигураторе.
Процесс извлечения данных начинается с получения объекта метаданных по имени. После этого вызывается метод ПолучитьЗначениеДополнительногоСведения, который принимает в качестве параметров ссылку на объект-владелец и возвращает значение в соответствующем типе. Данный метод является частью глобального контекста или может быть вызван через менеджер метаданных, что делает его доступным в любом модуле приложения.
Рассмотрим пример кода, демонстрирующий правильный алгоритм действий. Сначала мы объявляем переменную для хранения вида сведений, затем получаем его через менеджер метаданных. Далее вызываем метод получения значения, передавая ссылку на нужный элемент справочника или документа. Если вид сведений не найден или у объекта нет установленного значения, метод вернет значение Неопределено, что необходимо обрабатывать в логике приложения.
ВидСведений = Метаданные.ВидыДополнительныхСведенийОбъектов.НайтиПоИмени("ЦветТовара");
Если ВидСведений <> Неопределено Тогда
ЗначениеСведения = ВидСведений.ПолучитьЗначениеДополнительногоСведения(СсылкаНаТовар);
Сообщить("Цвет товара: " + ЗначениеСведения);
КонецЕсли;
Использование этого метода гарантирует, что вы получите данные в том формате, в котором они были сохранены. Платформа самостоятельно выполнит все необходимые преобразования. Однако стоит помнить, что частое обращение к метаданным в циклах может негативно сказаться на производительности, поэтому для массовой обработки данных лучше использовать другие подходы, например, запросы.
☑️ Алгоритм получения через метаданные
Извлечение данных с помощью запросов
В ситуациях, когда требуется получить значения дополнительных сведений для большого количества объектов одновременно, использование цикла с обращением к метаданным становится неэффективным. В таких случаях оптимальным решением является формирование запроса к виртуальной таблице дополнительных сведений. Это позволяет загрузить все необходимые данные одним обращением к базе данных, значительно ускоряя работу программы.
Для формирования запроса необходимо знать имя таблицы, в которой хранятся данные. Обычно это таблица с именем, соответствующим имени вида дополнительного сведения, но в пространстве имен дополнительных сведений. В тексте запроса используется конструкция ДополнительныеСведения, за которой следует имя вида сведений. Результатом запроса будет таблица, содержащая ссылки на объекты и соответствующие им значения.
Структура запроса включает выборку поля Ссылка (или Период для планов видов характеристик) и поля Значение. Важно правильно указать псевдонимы полей, чтобы затем удобно работать с результатами в коде. Пример ниже демонстрирует, как получить список товаров и их дополнительных характеристик в одном запросе, что идеально подходит для отчетов или обработок массового изменения данных.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ТоварыДополнительныеСведения.Ссылка КАК Товар,
| ТоварыДополнительныеСведения.Значение КАК Цвет
|ИЗ
| Справочник.Номенклатура.ДополнительныеСведения.ЦветТовара КАК ТоварыДополнительныеСведения";
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Пока Выборка.Следующий() Цикл
// Обработка строки результата
КонецЦикла;
При использовании запросов следует учитывать, что имя вида дополнительного сведения в тексте запроса должно точно совпадать с именем, указанным в конфигурации, включая регистр символов. Если вид сведений имеет составное имя или содержит специальные символы, их необходимо экранировать или использовать синонимы, если они настроены в конфигураторе. Это обеспечивает корректную работу запроса на любых версиях СУБД.
Особенности работы запросов к дополнительным сведениям
Виртуальные таблицы дополнительных сведений не поддерживают все виды соединений, доступные для обычных таблиц. В частности, использование внешних соединений (LEFT JOIN) к таблицам дополнительных сведений может привести к непредсказуемым результатам, если не учитывать наличие записей. Рекомендуется сначала получать основной набор объектов, а затем присоединять к ним дополнительные сведения через внутренний запрос или временную таблицу.
Обработка составных типов и ограничений
Одной из ключевых особенностей дополнительных сведений является возможность хранения данных составных типов. Вид сведения может быть настроен так, чтобы принимать, например, либо строку, либо число, либо ссылку на справочник. При получении такого значения программист должен быть готов к тому, что тип возвращаемой переменной может меняться в зависимости от введенных пользователем данных.
Для корректной обработки таких ситуаций необходимо использовать оператор ТипЗнч или конструкцию Если ... Тогда с проверкой типа. Это позволяет разветвить логику программы в зависимости от того, какой именно тип данных был сохранен. Игнорирование этого аспекта может привести к ошибкам приведения типов при попытке выполнить арифметические операции со строкой или вызвать методы объекта у числа.
- 🔍 Проверяйте тип возвращаемого значения перед использованием в вычислениях.
- 🛡️ Используйте обработку исключений для перехвата ошибок приведения типов.
- 📝 Документируйте ожидаемые типы данных для каждого вида дополнительных сведений.
Кроме того, существуют ограничения на длину хранимых данных. Для строковых типов максимальная длина может быть ограничена настройками вида сведений или характеристиками СУБД. При попытке записать значение, превышающее допустимый лимит, платформа выдаст ошибку. Поэтому при разработке интерфейсов ввода или программной загрузке данных следует предусматривать механизм обрезки или валидации длинных строк.
⚠️ Внимание: Если вид дополнительного сведения настроен как "Булево", но в базе данных по каким-либо причинам (например, после некорректного восстановления из резервной копии) хранится значение другого типа, метод получения значения может вернуть
Неопределеноили вызвать ошибку. Всегда проверяйте целостность данных при миграции между версиями платформы.
Сравнение методов доступа к данным
Выбор между использованием объекта метаданных и запросом зависит от конкретной задачи. Если требуется получить значение для одного конкретного объекта в ответ на действие пользователя (например, при открытии формы), метод метаданных будет предпочтительнее из-за простоты реализации и читаемости кода. В случаях же аналитической обработки или выгрузки больших объемов данных запросы демонстрируют значительное превосходство в скорости.
В таблице ниже приведено сравнение основных характеристик двух подходов, что поможет вам принять взвешенное решение при проектировании архитектуры вашего решения. Учитывайте не только скорость выполнения, но и удобство поддержки кода в долгосрочной перспективе.
| Критерий | Объект метаданных | Запрос к виртуальной таблице |
|---|---|---|
| Производительность (1 запись) | Высокая | Средняя (накладные расходы на компиляцию запроса) |
| Производительность (1000+ записей) | Низкая (цикл) | Очень высокая (пакетная обработка) |
| Читаемость кода | Высокая | Средняя (требуется знание синтаксиса запросов) |
| Гибкость фильтрации | Ограничена | Максимальная (условия WHERE, группировки) |
Также стоит отметить, что при работе в режиме предприятия с тонким клиентом запросы могут выполняться на стороне сервера, что снижает нагрузку на клиентское рабочее место. Методы метаданных также исполняются на сервере, но при массовом вызове из цикла на клиенте (что является антипаттерном) могут создавать значительный сетевой трафик из-за множественных вызовов.
Для одиночных операций используйте методы метаданных ради чистоты кода, а для отчетов и обработок данных — запросы ради производительности.
Частые ошибки и способы их устранения
При работе с механизмом дополнительных сведений разработчики часто сталкиваются с рядом типовых проблем. Одна из самых распространенных ошибок — попытка обратиться к виду сведений, который еще не создан в базе данных или был переименован. Это приводит к тому, что переменная, хранящая ссылку на вид сведений, принимает значение Неопределено, и последующий вызов метода генерирует исключение.
Еще одна проблема связана с правами доступа. Если у роли пользователя нет прав на чтение таблицы дополнительных сведений или конкретного вида сведений, система вернет пустое значение или откажет в доступе, в зависимости от настроек безопасности. В таких случаях необходимо проверить профиль безопасности пользователя и убедиться, что соответствующие флаги прав установлены в конфигураторе.
- ❌ Ошибка: Использование имени вида сведений без проверки на существование.
- ❌ Ошибка: Игнорирование возможности возврата значения
Неопределено. - ❌ Ошибка: Попытка записать данные в вид сведений, предназначенный только для чтения.
Для отладки подобных ситуаций рекомендуется использовать консоль запросов или режим отладки с точками останова. Визуальная проверка содержимого переменных в момент выполнения позволяет быстро выявить, на каком этапе происходит сбой. Также полезно выводить служебные сообщения в журнал регистрации для анализа работы механизма в промышленной эксплуатации.
⚠️ Внимание: Интерфейс и возможности работы с дополнительными сведениями могут незначительно отличаться в зависимости от версии платформы 1С:Предприятие и режима запуска (управляемое приложение vs обычное приложение). Всегда тестируйте код на той версии платформы, которая используется у конечного заказчика.
При создании новых видов дополнительных сведений используйте префиксы в именах (например, "ПрефиксФирмы_ЦветТовара"), чтобы избежать конфликтов имен при обновлении типовых конфигураций или установке сторонних расширений.
FAQ: Часто задаваемые вопросы
Можно ли получить значение дополнительного сведения без знания его имени?
Технически это возможно, если перебирать коллекцию Метаданные.ВидыДополнительныхСведенийОбъектов и фильтровать их по другим признакам, например, по синониму или принадлежности к объекту. Однако такой подход крайне неэффективен и не рекомендуется к использованию в рабочем коде, так как он замедляет выполнение программы и делает его зависимым от порядка элементов в метаданных.
Как узнать, есть ли у объекта какое-либо дополнительное сведение, не зная конкретного вида?
Для этого можно сформировать запрос к общей таблице ДополнительныеСведения (без указания конкретного вида), отфильтровав результаты по полю Ссылка. Это вернет список всех видов сведений и их значений, связанных с данным объектом. Такой подход полезен для универсальных обработок или при создании динамических интерфейсов.
Влияет ли удаление элемента справочника на сохраненные дополнительные сведения?
Да, механизм дополнительных сведений поддерживает каскадное удаление. При удалении основного объекта (например, элемента справочника) все связанные с ним записи в таблице дополнительных сведений автоматически удаляются платформой. Это предотвращает появление "висячих" ссылок и загрязнение базы данных ненужной информацией.
Можно ли использовать дополнительные сведения в условиях отбора СКД (Система Компоновки Данных)?
Да, виды дополнительных сведений доступны для использования в СКД. Они отображаются в списке доступных полей после добавления соответствующего набора данных. Однако для корректной работы может потребоваться настройка параметров компоновки, особенно если вид сведений имеет сложный тип или требует специфических условий соединения.
Какова максимальная длина строки в дополнительном сведении?
Максимальная длина строкового значения зависит от настроек конкретного вида дополнительного сведения, заданных в конфигураторе. По умолчанию платформа позволяет хранить строки длиной до 3634 символов (для СУБД MS SQL) или до 4000 символов (для PostgreSQL/Oracle), но разработчик может установить меньшее ограничение в свойствах вида сведений для оптимизации хранения.