Вопрос изменения свойств заимствованных объектов метаданных в расширениях конфигурации является одним из самых часто обсуждаемых в среде разработчиков 1С. Ситуация, когда типового поля "Комментарий" или "Наименование" длиной 100 символов не хватает, и бизнес требует увеличить его до 129 или 150 символов, встречается повсеместно. Давайте подробно разберем, как платформа 1С позволяет решать эту задачу, какие существуют ограничения в зависимости от версий, и какие "обходные пути" можно использовать, если штатные методы недоступны.
Прежде чем приступать к реализации, нам необходимо выяснить версию платформы и режим совместимости, который используется в конфигурации. Исторически расширения имели строгие ограничения: менять тип и длину заимствованных данных было нельзя. Однако функционал развивался:
Код и Наименование).Рассмотрим несколько сценариев решения задачи, от "правильных" архитектурных до "хитрых" приемов.
Если наша задача — увеличить длину Наименования или Кода справочника, и мы работаем на современной платформе (не ниже 8.3.22), решение будет штатным.
Порядок действий:
Справочник.Номенклатура) в расширение.Наименование.Важно: Это работает только на увеличение длины. Уменьшать длину строки в расширении нельзя, так как это может привести к потере данных, которые уже записаны в базе.
Это наиболее архитектурно верный способ, если конфигурация построена грамотно. Многие современные типовые конфигурации (ERP, КА, УТ) используют ОпределяемыеТипы для задания характеристик полей. Например, реквизит Артикул может иметь тип не просто Строка(25), а ОпределяемыйТип.Артикул.
В этом случае нам не нужно менять сам реквизит. Мы должны:
ОпределяемыйТип в дереве метаданных, используя анализ структуры объектов.После применения расширения все реквизиты во всех объектах, которые ссылаются на этот тип, автоматически "расширятся". Это поддерживается платформой достаточно давно (начиная с 8.3.20 частичная поддержка) и является рекомендуемым путем.
Что делать, если у нас обычный реквизит (не стандартный), он имеет тип Строка (не определяемый тип), а режим совместимости конфигурации не позволяет менять свойства заимствованных полей? В этом случае нам поможет метод подмены, который активно обсуждался в профессиональном сообществе.
Суть метода заключается в создании нового реквизита в расширении и скрытии старого. Разберем этот алгоритм по шагам.
Шаг 1. Создание нового реквизита
В расширении к нужному документу или справочнику добавляем новый (собственный) реквизит, например, Расш1_КомментарийПолный. Задаем ему нужную длину, например, 150 символов.
Шаг 2. Настройка формы
Заимствуем форму объекта в расширение. Программно (используя готовые функции изменения форм) или интерактивно скрываем типовой элемент формы, связанный со старым коротким реквизитом, и добавляем на форму поле ввода, связанное с нашим новым реквизитом Расш1_КомментарийПолный.
Теперь пользователь видит длинное поле и может вводить туда текст более 100 символов.
Шаг 3. Синхронизация данных (Самое важное)
Чтобы типовые механизмы конфигурации не сломались, нам нужно обеспечить заполнение типового реквизита. Ведь отчеты, печатные формы и алгоритмы проведения ничего не знают о нашем новом поле. Используем подписку на событие или расширение модуля объекта (событие ПередЗаписью).
Пример кода в модуле расширения:
&Вместо("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Копируем данные из нашего длинного реквизита в типовой короткий
// При этом обрезаем строку до длины типового реквизита (например, 100)
ЭтотОбъект.Комментарий = Лев(ЭтотОбъект.Расш1_КомментарийПолный, 100);
// Вызываем стандартную логику
ПродолжитьВызов(Отказ, РежимЗаписи, РежимПроведения);
КонецПроцедуры
Также необходимо обработать ситуацию чтения данных (или открытия формы), чтобы если значение было изменено извне (не через форму), оно попало в наш новый реквизит. Обычно достаточно сделать разовую обработку по заполнению нового реквизита историческими данными.
Минусы этого подхода:
Расш1_КомментарийПолный.В настройках свойств заимствованного реквизита в расширении есть пункт, позволяющий отключить проверку соответствия типа с основной конфигурацией (иногда это называют "снять галочку контроля").
Категорически не рекомендуем использовать этот способ для изменения длины строки, если вы не понимаете до конца, как работает СУБД. Даже если платформа позволит сохранить расширение, физическая структура таблицы в базе данных (SQL) останется прежней (длина 100).
При попытке записать в такое поле строку длиной 129 символов вы получите ошибку уровня СУБД: Data truncation (усечение данных) или аварийное завершение работы. Платформа будет думать, что поле длинное, и передаст данные в SQL, а SQL-сервер откажется их принимать в узкое поле.