Как изменить тип данных и длину реквизита в расширении 1С?

← На главную

При активном использовании механизма расширений в платформе 1С:Предприятие разработчики часто сталкиваются с необходимостью доработки существующих типовых реквизитов. Типичный сценарий: в типовой конфигурации длина строкового реквизита (например, НомерСчета в справочнике БанковскиеСчетаКонтрагентов) составляет 34 символа, а для бизнес-процессов организации требуется расширить его до 50 символов. Однако при попытке изменить длину заимствованного реквизита в расширении на старых версиях платформы (включая 8.3.11) система выдает ошибку о несовпадении контролируемых свойств с основной конфигурацией.

В этой статье мы подробно разберем, почему возникает эта проблема, как ее приходилось решать на платформе версии 8.3.11, и как этот вопрос элегантно решается в современных релизах 1С (начиная с 8.3.18 и выше).

Почему старые версии платформы (до 8.3.17 включительно) запрещают менять тип и длину данных?

Разберем причину такого поведения платформы на уровне СУБД. В версии 8.3.11 и близких к ней релизах расширения создавались как надстройки, которые не должны были монопольно изменять физическую структуру таблиц основной базы данных для заимствованных объектов. Когда мы заимствуем справочник в расширение, платформа строго контролирует соответствие метаданных. Если бы разработчику было позволено изменить длину строки с 34 до 50 символов на уровне расширения:

Конфликт СУБД: СУБД хранит поле таблицы с жестким ограничением длины, заданным в основной конфигурации. Расширение не пересоздавало колонки основных таблиц.
Проблема совместимости нескольких расширений: Если бы несколько разных расширений пытались установить разную длину одного и того же поля (одно — 50 символов, второе — 60), платформа столкнулась бы с неразрешимым конфликтом приоритетов на уровне базы данных.

Именно поэтому при попытке запуска система проверяет контролируемые свойства и блокирует компиляцию, защищая целостность базы данных.

Решение проблемы на платформе 1С 8.3.11: обходной путь через добавление нового реквизита

Если ваша база данных вынужденно работает на старой версии платформы (например, в силу требований совместимости или ограничений инфраструктуры), единственным надежным способом решения задачи является создание собственного реквизита в расширении и программная синхронизация его с основным реквизитом.

Проанализируем по шагам, как реализовать этот обходной путь:

Заимствуем необходимый справочник (например, БанковскиеСчетаКонтрагентов) в расширение.
Создаем в расширении новый реквизит справочника с именем НомерСчета_Расширение, задаем ему нужный тип данных — Строка, длина 50 символов.
Добавляем этот реквизит на форму элемента справочника в расширении, скрывая при этом стандартное поле НомерСчета.
Обеспечиваем программную синхронизацию данных. Нам необходимо сделать так, чтобы при записи нового значения длинный номер сохранялся в наше новое поле, а в стандартное (которое ограничено 34 символами) записывалась обрезанная часть строки (или генерировался шаблон), чтобы не нарушать работу стандартных алгоритмов, которые могут обращаться к исходному реквизиту.

Рассмотрим пример кода синхронизации данных. В модуле формы элемента справочника в расширении переопределим обработчики событий чтения и записи:


&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    // Заполняем поле формы расширения сохраненным ранее длинным значением
    Если ЗначениеЗаполнено(Объект.Ссылка) Тогда
        // Читаем значение длинного номера счета из нашего реквизита расширения
        ЭтаФорма.НомерСчета_Расширение = Объект.НомерСчета_Расширение;
    КонецЕсли;
КонецПроцедуры

&НаСервере
Процедура Расш1_ПередЗаписьюНаСервереПосле(Отказ, ТекущийОбъект, ПараметрыЗаписи)
    // Перед записью синхронизируем данные.
    // В стандартный реквизит пишем первые 34 символа (для совместимости)
    ТекущийОбъект.НомерСчета = Лев(ЭтаФорма.НомерСчета_Расширение, 34);
    
    // В реквизит расширения записываем полные 50 символов
    ТекущийОбъект.НомерСчета_Расширение = ЭтаФорма.НомерСчета_Расширение;
КонецПроцедуры

Важное ограничение метода: При использовании такого обходного пути вам придется вручную дорабатывать или заменять логику во всех отчетах, запросах и печатных формах, где фигурирует стандартный реквизит НомерСчета, перенаправляя их на чтение поля НомерСчета_Расширение. Это трудоемкий процесс, требующий внимательности.

Современное решение: изменение длины и типов данных в платформе 8.3.18 и выше

Фирма «1С» детально проработала этот сценарий и значительно расширила возможности механизма расширений в последующих релизах. Рассмотрим, как эта задача решается на современной платформе.

1. Изменение длины строковых и числовых реквизитов (начиная с 8.3.18)

Начиная с версии платформы 8.3.18, разработчикам официально разрешено изменять длину существующих строковых и числовых реквизитов непосредственно в расширении. Теперь сценарий из темы форума реализуется без создания дублирующих реквизитов:

Вы заимствуете стандартный реквизит НомерСчета в свое расширение.
В свойствах заимствованного реквизита внутри расширения увеличиваете длину с 34 до 50 символов.
Платформа автоматически берет на себя задачу по реструктуризации таблиц СУБД. При обновлении конфигурации базы данных колонка в физической таблице будет расширена до 50 символов.

Также появилась возможность расширять составные типы данных. Если стандартный реквизит имеет составной тип (например, СправочникСсылка.ФизическиеЛица, СправочникСсылка.Пользователи), вы можете добавить в состав этого типа новые объекты метаданных, созданные внутри вашего расширения.

2. Работа с определяемыми типами и общими реквизитами (начиная с 8.3.20)

В платформе 8.3.20 возможности работы со свойствами данных были существенно расширены:

Определяемые типы: Теперь их можно заимствовать в расширение и изменять их тип (например, расширять длину или точность числовых показателей, добавлять новые типы в составные определяемые типы).
Общие реквизиты: Разрешено заимствовать общие реквизиты и расширять их типы данных (при условии, что реквизит не используется в качестве разделителя данных).

3. Изменение длины кодов и номеров документов (начиная с 8.3.22)

Начиная с версии 8.3.22, разработчикам больше не нужно использовать сложные программные ухищрения для изменения длины кодов справочников или номеров документов. Если вашей организации не хватает стандартной длины номера счета-фактуры или кода номенклатуры, вы можете заимствовать объект в расширение и изменить свойство ДлинаКода или ДлинаНомера прямо в конфигураторе расширения.

Обязательные технические условия для использования новых возможностей

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

Режим совместимости: Режим совместимости основной конфигурации и самого расширения должен быть установлен в значение не ниже той версии платформы, в которой появилась соответствующая фича (например, не ниже 8.3.18 для изменения длины строки и не ниже 8.3.22 для длины номеров).
Монопольный доступ при обновлении базы: Изменение физической структуры таблиц СУБД (увеличение колонок) требует монопольного захвата базы данных. Применение расширения, изменяющего типы данных, возможно только тогда, когда в базе нет активных сеансов пользователей. В противном случае платформа выдаст ошибку реструктуризации.
Риск потери данных при отключении расширения: Это критически важный нюанс! Если вы расширили длину строки до 50 символов, пользователи заполнили базу данных длинными строками, а затем вы временно или навсегда отключили (или удалили) данное расширение — платформа автоматически выполнит обратную реструктуризацию. Все накопленные данные в этих полях будут безвозвратно обрезаны до исходного лимита основной конфигурации (в нашем примере — до 34 символов).

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