Почему добавленные в расширение реквизиты не отображаются в форме справочника и как правильно работать с данными в расширениях

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет IT и автоматизация бизнеса

При работе с механизмом расширений в 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда новые реквизиты, добавленные в расширение или заимствованные из основной конфигурации, упорно не желают появляться в составе реквизита Объект на заимствованной форме. Рассмотрим подробно, как устроен этот механизм, разберем типичные ошибки и выясним, какие риски несет в себе хранение данных в расширениях.

Механизм добавления реквизитов в расширение: пошаговая инструкция

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

Заимствование объекта метаданных. Откроем дерево основной конфигурации, найдем нужный справочник (например, Номенклатура), нажмем правую кнопку мыши и выберем пункт "Добавить в расширение". В расширении появится пустой объект справочника.
Заимствование конкретных реквизитов. Вернемся в основную конфигурацию. Важно понимать: реквизиты не переносятся автоматически. Нам необходимо зайти в список реквизитов справочника в основной конфигурации, выделить нужные (включая те, что были добавлены разработчиком ранее) и также через правую кнопку мыши нажать "Добавить в расширение".
Заимствование формы. Только после того, как сами реквизиты добавлены в расширение, заимствуем форму элемента.

Если вы уже заимствовали форму, а затем добавили реквизиты в расширение, они могут не отобразиться в редакторе формы мгновенно. В этом случае рассмотрим следующий шаг: в редакторе формы в расширении перейдем на закладку "Реквизиты", найдем основной реквизит Объект, нажмем на него правой кнопкой мыши и выберем команду "Обновить". Это заставит платформу перечитать состав метаданных объекта в контексте расширения.

Создание собственных реквизитов в расширении

Начиная с версии платформы 8.3.11 и 8.3.12, у разработчиков появилась возможность не только заимствовать существующие поля, но и создавать собственные реквизиты в расширении, которые будут иметь свои колонки в базе данных. Посмотрим, какие условия для этого должны быть соблюдены:

Во-первых, режим совместимости основной конфигурации и расширения должен быть не ниже 8.3.11. Если ваша конфигурация (например, старая УТ 11.2) работает в режиме совместимости 8.3.6, то создание собственных таблиц данных в расширении будет недоступно или крайне нестабильно.

Во-вторых, при создании собственного реквизита в расширении, платформа автоматически добавит ему префикс (например, имяРасширения_ИмяРеквизита). Это необходимо для предотвращения конфликтов имен при обновлениях основной конфигурации.

Почему платформа может вести себя нестабильно?

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

Тестирование и исправление (ТиИ). В ранних версиях платформы (8.3.12, 8.3.13) существовала критическая проблема: при запуске ТиИ с проверкой ссылочной целостности, система могла посчитать данные в таблицах расширений «лишними» и удалить их. Перед любыми манипуляциями с данными в расширении обязательно делайте резервную копию базы данных.
Динамическое обновление. Изменение структуры данных в расширении (добавление или удаление реквизитов) крайне плохо сочетается с динамическим обновлением. Всегда выполняйте монопольное обновление конфигурации базы данных.
Конфликт структур в СУБД. Когда мы добавляем реквизит в расширение, в SQL-таблице справочника создается дополнительная таблица или колонки с суффиксами. Если вы удаляете реквизит из расширения, платформа должна корректно выполнить ALTER TABLE. На больших базах или при наличии блокировок это может привести к аварийному завершению работы процесса rphost.

Альтернативный подход: использование регистров сведений

Проанализируем совет из сообщения №2 форума. Если ваша цель — добавить дополнительные данные к объекту (например, характеристики номенклатуры), которые не критичны для работы типовых запросов основной конфигурации, использование Регистра сведений в расширении часто оказывается более безопасным и гибким решением.

Рассмотрим преимущества этого метода:

Вы не меняете структуру основной таблицы справочника Номенклатура, что снижает риск повреждения базы при обновлении.
Данные регистра хранятся обособленно.
Легко реализовать хранение истории изменений (если сделать регистр периодическим), чего нельзя сделать простым реквизитом справочника.

Пример кода для программного обращения к такому регистру из расширения:


// В расширении формы элемента номенклатуры
&НаСервере
Процедура Расш1_ПриЗаписиНаСервереПосле(Отказ, ТекущийОбъект, ПараметрыЗаписи)
    // Записываем доп. данные в наш регистр
    МенеджерЗаписи = РегистрыСведений.Расш1_ДопРеквизитыНоменклатуры.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.Номенклатура = ТекущийОбъект.Ссылка;
    МенеджерЗаписи.СобственныйПараметр = Объект.Расш1_ПолеНаФорме;
    МенеджерЗаписи.Записать();
КонецПроцедуры

Поддержка РИБ и обновлений

Важно помнить, что полноценная поддержка передачи данных расширений через механизмы РИБ (Распределенные информационные базы) появилась только в версии 8.3.12. Если ваша система использует обмен данными, убедитесь, что все узлы переведены на актуальную платформу и в настройках обмена включена синхронизация расширений.

Выясним ситуацию с обновлениями основной конфигурации. Если вы перенесли свои реквизиты в расширение, то при обновлении типовой конфигурации (например, при переходе с УТ 11.2 на 11.4), вам не придется вручную объединять формы и модули, где задействованы эти реквизиты. Однако помните, что при удалении реквизитов из основной конфигурации с целью их "переноса" в расширение, вы должны сначала мигрировать данные обработкой, иначе они будут безвозвратно утеряны при удалении поля из метаданных основной конфигурации.

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

← На главную