Почему не подбирается физлицо при обмене из УПП в ЗУП и как корректно обновлять данные в форме

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

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

Проблема идентификации: особенности ФИО и структуры справочников

Проанализируем ситуацию, когда сотрудник с фамилией, содержащей приставку «АКИФ ОГЛЫ», не подбирается в документ при загрузке через веб-сервис. Выясним причину такого поведения системы. В 1С:ЗУП 3.1 поиск и идентификация объектов при обмене часто строятся на сопоставлении полей Наименование и Табельный номер (Код).

Рассмотрим основные факторы, влияющие на успех поиска:

  1. Парсинг ФИО: Приставки вроде «Оглы», «Кызы», «Улы» могут по-разному интерпретироваться механизмом разбора ФИО. Если в УПП эти данные записаны в одну строку, а в ЗУП при загрузке система пытается разложить их на Фамилию, Имя и Отчество, может возникнуть несоответствие.
  2. Невидимые символы: Одной из скрытых причин часто является наличие неразрывного пробела (код 160) вместо обычного (код 32). Визуально строки идентичны, но для поискового запроса 1С это разные объекты.
  3. Связь «Физическое лицо — Сотрудник»: Важно помнить, что в ЗУП 3.1 реализована жесткая архитектура: одному Физическому лицу может соответствовать несколько объектов в справочнике Сотрудники (например, при внутреннем совместительстве). Если программный код ищет только по наименованию, он может наткнуться на дубль или «старую» карточку уволенного сотрудника.

Проверка актуальности кадровых данных

Если объект в базе существует, но документ все равно не «видит» сотрудника, проанализируем состояние вспомогательных регистров. В ЗУП 3.1 для ускорения работы списков и подборов используется регистр сведений Текущие кадровые данные сотрудников.

Если вы записываете данные программно с установленным флагом ОбменДанными.Загрузка = Истина, типовые механизмы обновления этого регистра могут не сработать. В результате сотрудник есть в справочнике, но его «кадровое состояние» (подразделение, должность) не определено. Чтобы исправить это, попробуйте перепровести последний кадровый документ по этому сотруднику или воспользуйтесь следующим методом:

Рассмотрим пример кода для обновления планового ФОТ и кадровых данных:


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

Как избежать путаницы при выборе сотрудников

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

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

Технический нюанс: почему пропадают данные при использовании ЗначениеВРеквизитФормы

Разберем ситуацию, описанную в теме: при программном обновлении документа на сервере и последующей передаче его на форму через ЗначениеВРеквизитФормы(Док, "Объект"), в табличной части исчезают результаты расчетов (НДФЛ, суммы). Почему это происходит?

Проанализируем архитектуру ЗУП 3.1. Многие колонки в документах (например, результат начисления) являются вычисляемыми. Они не всегда хранятся в основных табличных частях в том виде, в котором мы их видим на экране. Когда вы выполняете Док.Записать(РежимЗаписиДокумента.Проведение), система обновляет записи в регистрах. Но метод ЗначениеВРеквизитФормы выполняет полное перечитывание данных объекта. Если в модуле формы или в процедурах пересчета не заложен механизм восстановления этих динамических колонок при чтении, они останутся пустыми до следующего интерактивного изменения.

Чтобы обновить форму без потери данных, рассмотрим альтернативные варианты:

Вариант 1: Использование ОповеститьОбИзменении

Вместо полной перезаписи реквизита формы, после записи документа на сервере, вызовите оповещение на клиенте:


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

Вариант 2: Вызов серверных процедур пересчета

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

Рассмотрим правильную последовательность действий в коде:


// 1. Получаем объект из реквизита формы
ДокОбъект = РеквизитФормыВЗначение("Объект");

// 2. Выполняем необходимые действия и записываем
ДокОбъект._Выгружен = Истина;
ДокОбъект.Записать(РежимЗаписиДокумента.Проведение);

// 3. Возвращаем данные на форму
ЗначениеВРеквизитФормы(ДокОбъект, "Объект");

// 4. ВАЖНО: вызываем типовой механизм пересчета, чтобы заполнить экранные колонки
// В зависимости от документа, название процедуры может отличаться
ЭтаФорма.РассчитатьДокументНаСервере();

Итоги

Для стабильного обмена между УПП и ЗУП 3.1 необходимо:

  1. Следить за чистотой строковых данных (ФИО без лишних пробелов).
  2. Обеспечить уникальность связки «ФИО + Табельный номер».
  3. При программном изменении документов учитывать, что ЗУП 3.1 — это сложная расчетная система, где простая запись объекта в базу требует последующего вызова процедур актуализации экранных данных.
← На главную