Как программно создать физическое лицо и обеспечить отображение его паспортных данных в 1С:ЗУП 3.1?

← На главную

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

Разберем причину: почему данных не видно в форме?

Проблема кроется в архитектуре современных конфигураций на базе БСП. Данные о документах хранятся в периодическом регистре сведений ДокументыФизическихЛиц, однако форма справочника ФизическиеЛица не всегда считывает их напрямую из регистра в момент открытия. Для оптимизации быстродействия система использует механизмы кэширования и вспомогательные реквизиты. Рассмотрим основные факторы, влияющие на видимость данных:

Флаг основного документа: В регистре есть критически важный реквизит ЯвляетсяДокументомУдостоверяющимЛичность. Если он не установлен в значение Истина, система считает запись второстепенной (например, ИНН или свидетельство) и не выводит её в основные паспортные поля.
Кэширование в справочнике: Часть данных зеркалируется в скрытые реквизиты самого объекта СправочникОбъект.ФизическиеЛица. При прямой записи в регистр через менеджер записи это зеркалирование не срабатывает.
Актуальность по периоду: Если дата записи в регистре больше текущей даты или пустая, стандартные механизмы получения данных «на сегодня» просто проигнорируют эту запись.

Шаг 1. Правильное заполнение регистра сведений

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

Физлицо — ссылка на созданный элемент справочника.
ВидДокумента — ссылка на предопределенный элемент справочника ВидыДокументовФизическихЛиц.ПаспортРФ.
ЯвляетсяДокументомУдостоверяющимЛичность — значение Истина.
Период — дата начала действия документа (обычно дата выдачи).

Посмотрим на пример кода, реализующего корректную запись:


МенеджерЗаписи = РегистрыСведений.ДокументыФизическихЛиц.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Физлицо = НовоеФизЛицоСсылка;
МенеджерЗаписи.ВидДокумента = Справочники.ВидыДокументовФизическихЛиц.ПаспортРФ;
МенеджерЗаписи.Период = ДатаВыдачиПаспорта;
МенеджерЗаписи.Серия = "4510";
МенеджерЗаписи.Номер = "123456";
МенеджерЗаписи.ДатаВыдачи = ДатаВыдачиПаспорта;
МенеджерЗаписи.КемВыдан = "ОВД города Москвы";
МенеджерЗаписи.КодПодразделения = "770-001";
МенеджерЗаписи.ЯвляетсяДокументомУдостоверяющимЛичность = Истина; // Обязательно!
МенеджерЗаписи.Записать();

Шаг 2. Использование типовых процедур обновления

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

Рассмотрим процедуру СотрудникиКлиентСервер.ОбновитьНаборЗаписейИсторииДокументыФизическихЛиц. Она отвечает за актуализацию истории. Однако на стороне сервера наиболее надежным способом будет использование программного интерфейса модуля КадровыйУчет.

Выполним обновление актуальных данных физических лиц следующим образом:


// После записи в регистр принудительно обновляем данные
КадровыйУчет.ОбновитьАктуальныеДанныеФизическихЛиц(НовоеФизЛицоСсылка);

Шаг 3. Работа через программный интерфейс (API) конфигурации

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

Попробуем реализовать запись через метод ЗаписатьДанныеСправочника или аналогичные функции в модуле ФизическиеЛица. Если мы используем стандартные механизмы БСП, то заполнение данных должно выглядеть как работа со структурой данных, которую система сама распределит по регистрам.

Проверим важные нюансы при заполнении

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

Представление документа: В регистре есть поле Представление. Если оно не заполнено, в некоторых отчетах или формах вместо «Паспорт РФ серия 0000 №000000» может быть пустота. Для его формирования можно использовать функцию КадровыйУчетКлиентСервер.СформироватьПредставлениеДокумента.
Вид документа по умолчанию: Убедитесь, что в справочнике ВидыДокументовФизическихЛиц для Паспорта РФ стоит признак того, что он является документом, удостоверяющим личность. Программно это проверяется через реквизит вида документа.
Транзакционность: Всегда создавайте сначала элемент справочника ФизическиеЛица, фиксируйте его в базе методом Записать(), и только после получения ссылки приступайте к формированию записей в регистре документов.

Итоговый алгоритм действий

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

Создаем и записываем объект Справочники.ФизическиеЛица.
Создаем запись в РегистрыСведений.ДокументыФизическихЛиц, обязательно установив ЯвляетсяДокументомУдостоверяющимЛичность = Истина.
Устанавливаем Период записи равным дате выдачи документа (или актуальной дате начала учета).
Вызываем процедуру КадровыйУчет.ОбновитьАктуальныеДанныеФизическихЛиц(СсылкаНаФизЛицо) для синхронизации кэша и интерфейсных полей.

Соблюдение этих шагов гарантирует, что программно созданные данные будут неотличимы от тех, что введены пользователем вручную через интерфейс программы 1С:ЗУП.