Как изменить тип реквизита табличной части документа в расширении при ограничении режима совместимости?

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

Метод «Теневого реквизита»: пошаговое руководство

Если нам необходимо сузить составной тип реквизита (например, оставить только СправочникСсылка.Контрагенты вместо исходного набора ссылок), а платформа запрещает это сделать напрямую, мы воспользуемся проверенным архитектурным приемом — созданием дополнительного реквизита с нужным типом данных.

1. Создание реквизита: В расширении конфигурации найдем нужный нам документ и его табличную часть. Добавим в нее новый реквизит, например, ЗаказчикКонтрагент. Зададим ему необходимый тип данных (в нашем случае — СправочникСсылка.Контрагенты).
2. Интерфейсная настройка: Вынесем созданный реквизит ЗаказчикКонтрагент на форму документа в нужную колонку табличной части. Старый реквизит Заказчик можно скрыть программно в модуле формы или через свойства элемента формы, установив свойство Видимость в значение Ложь.
3. Синхронизация данных: Чтобы данные корректно сохранялись в исходный реквизит, необходимо настроить передачу значений между полями при изменении. В модуле управляемой формы документа опишем логику обработки события ПриИзменении для нашего нового поля.

Рассмотрим, как реализовать программную связку между полями:

&НаКлиенте
Процедура ЗаказчикКонтрагентПриИзменении(Элемент)
    ТекущаяСтрока = Элементы.ТабличнаяЧасть.ТекущиеДанные;
    // Присваиваем значение из нового реквизита в старый для сохранения в БД
    ТекущаяСтрока.Заказчик = ТекущаяСтрока.ЗаказчикКонтрагент;
КонецПроцедуры

Проработка гибкого интерфейса для пользователей

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

Разберем, как сделать работу удобнее:

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

Проанализируем пример ограничения выбора в коде:

&НаКлиенте
Процедура ЗаказчикНачалоВыбора(Элемент, ДанныеВыбора, СтандартнаяОбработка)
    СтандартнаяОбработка = Ложь;
    // Накладываем программный фильтр на список выбора
    ПараметрыВыбора = Новый Структура;
    ПараметрыВыбора.Вставить("ТипЗначения", Тип("СправочникСсылка.Контрагенты"));
    ОткрытьФорму("Справочник.Контрагенты.ФормаВыбора", ПараметрыВыбора, Элемент);
КонецПроцедуры

Важные рекомендации по проектированию

Проанализируем возможные последствия такого подхода:

1. Производительность: Помните, что добавление избыточных реквизитов в табличные части может увеличивать размер базы данных и нагрузку при чтении документа. Старайтесь использовать этот метод только там, где это действительно необходимо для удобства бизнес-процессов.
2. Обновление конфигурации: При использовании дублирующих полей всегда учитывайте, что при обновлении типовой конфигурации 1С:Управление нашей фирмой, логика синхронизации (которую мы написали в коде) остается на вашей ответственности. Обязательно проверяйте, не затрагивают ли типовые обновления те процедуры, где мы производим подмену значений.
3. Альтернатива (БСП): Если вы работаете в конфигурации на базе Библиотеки стандартных подсистем, рассмотрите возможность использования ДополнительныеРеквизитыИСведения. Это позволит добавить нужный тип данных через механизм платформы без модификации структуры табличной части, что является более «чистым» решением с точки зрения сопровождения системы.

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