Как обновить значение связанного реквизита на управляемой форме при изменении данных в справочнике?

Приветствуем вас! В процессе разработки в среде «1С:Предприятие 8» программисты часто сталкиваются с ситуацией, когда данные, выведенные на управляемую форму «через точку» (путем разыменования ссылочного поля), не обновляются в реальном времени. В этой статье мы подробно разберем, почему возникает эта проблема, как работает механизм кэширования платформы, и рассмотрим практические способы решения этой задачи.

Суть проблемы: почему данные «застревают» в кэше

Рассмотрим типичный сценарий. В документе «Заказы» (управляемая форма) добавлено поле ввода, путь к данным которого настроен как Объект.Контрагент.ДопСведения. Поле ДопСведения — это строковый реквизит справочника «Контрагенты». Разработчик справедливо решает не дублировать информацию в документе, а считывать её напрямую из справочника-владельца.

Однако при изменении реквизита ДопСведения в форме контрагента (особенно если она открыта в режиме обычного приложения) и последующем открытии формы документа «Заказ» значение на форме оказывается пустым или устаревшим. Данные обновляются только после полного перезапуска сеанса работы с базой данных.

Давайте выясним техническую причину этого поведения. Она кроется в механизме кэширования объектов на стороне клиента:

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

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

Решение №1: Использование метода ОповеститьОбИзменении()

Самым правильным и простым решением при работе со ссылочными данными является использование встроенного метода платформы ОповеститьОбИзменении(). Этот метод сообщает всем открытым динамическим спискам и формам, что данные конкретного объекта были изменены, и заставляет их сбросить кэш и перечитать информацию из базы данных.

Давайте добавим вызов этого метода в модуль формы справочника «Контрагенты». Нам необходимо перехватить событие после записи объекта.

Если форма справочника «Контрагенты» является обычной формой, то в модуле формы пропишем следующий код:

Процедура ПослеЗаписи()
    // Сообщаем системе, что данные этого контрагента изменились
    ОповеститьОбИзменении(Ссылка);
КонецПроцедуры

Если форма справочника является управляемой формой, код будет выглядеть аналогично, но в соответствующем обработчике событий:

&НаКлиенте
Процедура ПослеЗаписи(ПараметрыЗаписи)
    ОповеститьОбИзменении(Объект.Ссылка);
КонецПроцедуры

Как это работает: Вызов ОповеститьОбИзменении() посылает системное уведомление. Платформа автоматически находит все открытые формы, где используется ссылка на данного контрагента, инвалидирует (обнуляет) локальный кэш для этой ссылки и принудительно считывает свежие данные из СУБД.

Решение №2: Принудительное чтение данных в документе через метод Прочитать()

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

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

Мы можем разместить на форме документа кнопку «Обновить» или принудительно перечитывать данные в обработчике события ПриАктивизации или ПриОткрытии (если форма открывается повторно без пересоздания объекта формы):

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

&НаКлиенте
Процедура ОбновитьДанные(Команда)
    ОбновитьДанныеФормыНаСервере();
КонецПроцедуры

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

&НаКлиенте
Процедура ОбновитьОтображение(Команда)
    ЭтаФорма.ОбновитьОтображениеДанных();
КонецПроцедуры

Решение №3: Архитектурно правильный подход с использованием БСП

Давайте проанализируем ситуацию с точки зрения архитектуры крупных систем. В современных конфигурациях, построенных на базе Библиотеки стандартных подсистем (БСП), для хранения несистематизированных или пользовательских свойств объектов (таких как «Дополнительные сведения», «Регион», «Особые условия») не рекомендуется добавлять новые реквизиты в сами справочники.

Для этого в БСП предусмотрен специальный механизм «Дополнительные реквизиты и сведения». Как это работает и почему это решает проблему кэширования:

1. Дополнительные сведения хранятся не в самом элементе справочника «Контрагенты», а в независимом регистре сведений ДополнительныеСведения.
2. При выводе таких сведений на управляемую форму документа данные запрашиваются динамически из регистра сведений при каждом открытии или обновлении формы.
3. Поскольку данные считываются напрямую из регистра (а не «через точку» от кэшированной ссылки объекта), проблема с «устареванием» кэша справочника исчезает сама собой.

Для вывода дополнительного сведения на форму управляемого приложения вы можете использовать динамический запрос или программно считывать данные из регистра сведений при создании формы на сервере:

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    Если ЗначениеЗаполнено(Объект.Контрагент) Тогда
        // Запрос к регистру сведений дополнительных сведений БСП
        Запрос = Новый Запрос;
        Запрос.Текст = 
            "ВЫБРАТЬ
            |	ДополнительныеСведения.Значение КАК ДопСведения
            |ИЗ
            |	РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения
            |ГДЕ
            |	ДополнительныеСведения.Объект = &Контрагент
            |	И ДополнительныеСведения.Свойство = &СвойствоДопСведения";
            
        Запрос.УстановитьПараметр("Контрагент", Объект.Contragent);
        // Предполагается, что у вас есть ссылка на план видов характеристик "ДополнительныеРеквизитыИСведения"
        Запрос.УстановитьПараметр("СвойствоДопСведения", ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("ДопСведения"));
        
        Выборка = Запрос.Выполнить().Выбрать();
        Если Выборка.Следующий() Тогда
            // Записываем полученное значение в реквизит формы (не объекта!) для отображения
            ДопСведенияСтрокой = Строка(Выборка.ДопСведения);
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Подведем итоги

Мы детально изучили проблему обновления связанных данных «через точку» на управляемых формах 1С и нашли оптимальные пути решения:

• Если у вас есть доступ к изменению кода справочника, используйте метод ОповеститьОбИзменении(Ссылка) в обработчике ПослеЗаписи() формы справочника. Это наиболее элегантный платформенный способ.
• Если справочник менять нельзя, обновляйте отображение в документе с помощью методов ОбновитьОтображениеДанных() или перечитывайте объект методом Прочитать().
• В долгосрочной перспективе старайтесь использовать механизмы БСП (регистры сведений) для хранения нетипизированных данных, чтобы избежать проблем с платформенным кэшированием объектных данных.