В процессе автоматизации загрузки данных из внешних источников (например, Excel) программисты 1С часто сталкиваются с ситуацией, когда текст в дополнительных реквизитах обрезается. Несмотря на то, что в настройках свойства указана «неограниченная длина», на практике данные могут сокращаться до 100 или 1024 символов. Рассмотрим детально, почему это происходит, как правильно написать код загрузки и какие системные ограничения необходимо учитывать.
Часто при программном заполнении дополнительных реквизитов разработчики по привычке пытаются создать новый элемент в справочнике ЗначенияСвойствОбъектов. Разберем, почему для строковых реквизитов это является ошибкой. Проанализируем ситуацию: если ваш дополнительный реквизит имеет тип «Строка», он должен хранить текстовое значение напрямую в табличной части объекта, а не ссылаться на справочник.
Важный технический нюанс: справочник ЗначенияСвойствОбъектов предназначен для хранения предопределенных значений (например, цветов «Красный», «Зеленый» или размеров). У этого справочника стандартная длина поля Наименование составляет всего 100 символов. Если вы пытаетесь записать длинное описание через создание элемента этого справочника, вы неизбежно столкнетесь с обрезкой текста на сотом символе.
Выясним причину: при типе «Строка» значением реквизита должна быть сама строка. Если же вы создаете элемент справочника, вы записываете в ДопРеквизит.Значение ссылку на этот элемент, а его отображаемое имя ограничивается длиной наименования справочника.
Рассмотрим по шагам, как должен выглядеть код для корректного заполнения дополнительных реквизитов без создания лишних элементов в справочниках. Мы пройдем по циклу свойств, найдем нужное свойство в Плане видов характеристик и запишем значение напрямую.
Для Каждого ЭлементДопСвойства Из ДопСвойства Цикл
// 1. Поиск самого свойства (характеристики)
ТекСвойство = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию(ЭлементДопСвойства.Ключ + " (" + Объект.ВидНоменклатуры + ")", Ложь);
Если Не ЗначениеЗаполнено(ТекСвойство) Тогда
Сообщить("Не удалось найти свойство: """ + ЭлементДопСвойства.Ключ + """");
Продолжить;
КонецЕсли;
// 2. Поиск строки в табличной части объекта (например, Номенклатуры)
МассивСтрок = Объект.ДополнительныеРеквизиты.НайтиСтроки(Новый Структура("Свойство", ТекСвойство));
Если МассивСтрок.Количество() = 0 Тогда
// Если такой реквизит еще не заполнен у объекта, добавляем новую строку
ДопРеквизит = Объект.ДополнительныеРеквизиты.Добавить();
ДопРеквизит.Свойство = ТекСвойство;
Иначе
// Если реквизит уже есть, редактируем существующую строку
ДопРеквизит = МассивСтрок[0];
КонецЕсли;
// 3. Запись текстового значения напрямую
// ТекстыЯчеек - это массив или структура с данными из Excel
ДопРеквизит.Значение = ТекстыЯчеек[ЭлементДопСвойства.Значение];
КонецЦикла;
Объект.Записать();
Этот подход избавляет от зависимости от справочника значений и позволяет использовать всю доступную длину поля. Однако здесь мы сталкиваемся со следующим барьером — ограничением в 1024 символа.
Проанализируем ситуацию, когда даже правильный код обрезает текст. В типовых конфигурациях (УТ 11, ERP 2, КА 2), построенных на Библиотеке Стандартных Подсистем (БСП), дополнительные реквизиты хранятся в табличной части ДополнительныеРеквизиты. Поле Значение в этой табличной части имеет составной тип данных, определяемый характеристикой.
Техническая причина ограничения: в метаданных самой конфигурации для типа Характеристика.ДополнительныеРеквизитыИСведения (который используется в колонке «Значение») для строковых данных зачастую жестко прописано ограничение длины в 1024 символа. Даже если в пользовательском режиме в «Плане видов характеристик» вы установите галочку «Неограниченная длина», физическая структура базы данных (таблица в SQL) для этой колонки может быть ограничена этим лимитом.
Посмотрим на пример:
Значение, отсекает всё, что превышает 1024 символа.Чтобы убедиться в наличии ограничения, попробуем провести эксперимент: введите в форму элемента вручную текст более 1024 символов и сохраните объект. Если после переоткрытия текст обрезался, значит, мы имеем дело с системным ограничением метаданных.
Разберем возможные пути решения этой задачи:
ДополнительныеСведения. В некоторых релизах БСП ресурс «Значение» в этом регистре также ограничен, но его проще расширить через расширение конфигурации, не затрагивая структуру сотен справочников.Подведем итоги нашего анализа. Для успешной загрузки данных необходимо придерживаться следующих правил:
Во-первых, всегда проверяйте тип создаваемого дополнительного реквизита. Если это «Строка», никогда не используйте справочник ЗначенияСвойствОбъектов, записывайте данные напрямую в поле Значение табличной части объекта.
Во-вторых, помните о «потолке» БСП в 1024 символа. Если ваши задачи требуют хранения текстов большего объема, типовой механизм дополнительных реквизитов без доработки метаданных может не подойти. В этом случае стоит рассмотреть использование стандартного реквизита ФайлОписания или текстовых макетов.
В-третьих, при поиске свойства в коде всегда учитывайте контекст (владельца). Как показано в примере выше, поиск через НайтиПоНаименованию с добавлением вида номенклатуры в скобках помогает избежать ошибок, если в базе есть несколько свойств с одинаковыми именами для разных видов товаров.