Как заполняется РегистрСведенийМенеджерЗаписи на управляемой форме в 1С:ЗУП 3

← На главную

При разработке или доработке типовых конфигураций, таких как 1С:Зарплата и управление персоналом 3.1 (ЗУП), программисты часто сталкиваются с ситуацией, когда на форме справочника (например, «Сотрудники») присутствуют поля, напрямую не принадлежащие основному объекту. Часто эти поля (Фамилия, Имя, Отчество) связаны с реквизитом формы, имеющим тип РегистрСведенийМенеджерЗаписи. Недоумение вызывает тот факт, что в конфигураторе отсутствуют видимые связи (например, «Связи параметров выбора» или «Связь по типу»), но при открытии формы данные уже заполнены. Разберем этот механизм подробно.

Загадка автоматического заполнения

Рассмотрим ситуацию: мы открываем форму элемента справочника Сотрудники. В отладчике, остановившись в самом начале процедуры ПриСозданииНаСервере, мы замечаем, что реквизит формы ФИОФизическихЛиц, имеющий тип РегистрСведенийМенеджерЗаписи.ФИОФизическихЛиц, уже содержит данные. При этом в свойствах элементов формы мы видим лишь путь к данным, указывающий на этот реквизит.

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

ПриЧтенииНаСервере — это событие выполняется на сервере сразу после того, как данные основного реквизита (например, Объект) были прочитаны из базы данных.
ПриСозданииНаСервере — форма инициализируется, настраиваются элементы управления.

Таким образом, когда управление передается в ПриСозданииНаСервере, данные уже могут быть подготовлены в предыдущем событии. Именно в ПриЧтенииНаСервере типовые конфигурации выполняют программное чтение связанных данных.

Механизм программного связывания данных

Выясним причину использования типа МенеджерЗаписи на форме. Это стандартный паттерн платформы 1С для реализации Data Binding (связывания данных). Вместо того чтобы создавать десятки отдельных реквизитов формы (строкового типа для Фамилии, Имени и т.д.), разработчики создают один реквизит типа МенеджерЗаписи. Это дает следующие преимущества:

Поля ввода на форме привязываются к свойствам менеджера: ФИОФизическихЛиц.Фамилия, ФИОФизическихЛиц.Имя.
Платформа автоматически управляет типами и длиной строк в соответствии с метаданными регистра.
Для записи изменений в базу достаточно вызвать один метод Записать() у этого менеджера.

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


// Примерная логика заполнения менеджера записи на форме
&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
    
    // 1. Устанавливаем отбор по ключевым измерениям регистра
    ФИОФизическихЛиц.ФизическоеЛицо = ТекущийОбъект.ФизическоеЛицо;
    
    // 2. Читаем данные из регистра в реквизит формы
    ФИОФизическихЛиц.Прочитать();
    
КонецПроцедуры

Метод Прочитать() заполняет все ресурсы менеджера записи (Фамилия, Имя, Отчество) значениями из регистра сведений, соответствующими установленному отбору. Если записи в базе нет, менеджер останется пустым (но инициализированным).

Особенности работы в ЗУП 3.1

В конфигурации Зарплата и Управление Персоналом логика еще более сложная. Справочник Сотрудники является, по сути, «проекцией» справочника ФизическиеЛица. Поэтому при чтении сотрудника система должна:

Получить ссылку на связанное ФизическоеЛицо.
Обратиться к регистру сведений ФИОФизическихЛиц.
Заполнить менеджер записи актуальными данными на текущую дату.

Проанализируем ситуацию с проверкой заполнения. Часто в модулях формы можно встретить вызовы типа СотрудникиФормы.ФизическиеЛицаОбработкаПроверкиЗаполненияНаСервере. Это подтверждает, что работа с персональными данными вынесена в специализированные общие модули, которые оперируют реквизитами формы как объектами.

Почему конфигуратор «молчит»?

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

Сохранение данных

Разберем, как данные попадают обратно в базу. Поскольку ФИОФизическихЛиц является реквизитом формы, его состояние сохраняется между серверными вызовами. В процессе записи основного объекта (Сотрудника) система вызывает обработчики записи. В них выполняется обратная операция:


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

&НаСервере
Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
    
    // Записываем данные регистра сведений
    Попытка
        ФИОФизическихЛиц.Записать();
    Исключение
        // Обработка ошибок записи (например, нарушение уникальности)
    КонецПопытки;
    
КонецПроцедуры

Резюме: Если вы видите на форме заполненные данные в реквизите типа МенеджерЗаписи, которые появились там «магическим» образом, всегда проверяйте процедуру ПриЧтенииНаСервере и вызываемые в ней общие модули. Именно там происходит связывание ключей записей регистра с данными основного объекта формы и последующий вызов метода Прочитать().