Почему в больничном листе 1С:ЗУП 2.5 заполняется старый адрес регистрации сотрудника?

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

Разберем детально, почему типовая конфигурация ведет себя подобным образом, как устроен механизм выборки данных сотрудника для ФСС и какими способами можно исправить автозаполнение.

Причина поведения типового механизма

Многие предполагают, что данные об адресе регистрации всегда берутся напрямую из регистра сведений Контактная информация на дату документа. Однако в подсистеме взаимодействия с ФСС (в частности, при прямых выплатах пособий) реализован иной алгоритм.

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

ВЫБОР
    КОГДА ДанныеПоследнегоДокумента.АдресРегистрации ЕСТЬ НЕ NULL 
        ТОГДА ДанныеПоследнегоДокумента.АдресРегистрации
    ИНАЧЕ "," + АдресаРегистрации.Поле1 + "," + АдресаРегистрации.Поле2 + "," + АдресаРегистрации.Поле3 + "," + АдресаРегистрации.Поле4 + "," + АдресаРегистрации.Поле5 + "," + АдресаРегистрации.Поле6 + "," + АдресаРегистрации.Поле7 + "," + АдресаРегистрации.Поле8 + "," + АдресаРегистрации.Поле9 + "," + ВЫБОР
            КОГДА АдресаРегистрации.ТипДома В (ЗНАЧЕНИЕ(Перечисление.ТипыДомов.Дом), ЗНАЧЕНИЕ(Перечисление.ТипыДомов.ПустаяСсылка))
                ТОГДА "дом"
            ИНАЧЕ "владение"
        КОНЕЦ + "," + ВЫБОР
            КОГДА АдресаРегистрации.ТипКорпуса В (ЗНАЧЕНИЕ(Перечисление.ТипыКорпусов.Корпус), ЗНАЧЕНИЕ(Перечисление.ТипыКорпусов.ПустаяСсылка))
                ТОГДА "корпус"
            ИНАЧЕ "строение"
        КОНЕЦ + "," + ВЫБОР
            КОГДА АдресаРегистрации.ТипКвартиры В (ЗНАЧЕНИЕ(Перечисление.ТипыКвартир.Квартира), ЗНАЧЕНИЕ(Перечисление.ТипыКвартир.ПустаяСсылка))
                ТОГДА "кв."
            ИНАЧЕ "оф."
        КОНЕЦ
КОНЕЦ КАК АдресРегистрации

Такой подход заложен разработчиками платформы по следующим причинам:

1. Преемственность выплат и продление листков нетрудоспособности: Если новый больничный лист является продолжением предыдущего страхового случая, реквизиты перечисления и адрес отправки уведомлений/выплат не должны самопроизвольно меняться, если в кадровом учете произошли корректировки уже во время болезни.
2. Отсутствие версионирования контактной информации: В линейке 1С:ЗУП 2.5 регистр сведений Контактная информация непериодический. Фиксация реквизитов на момент оформления возлагается непосредственно на сами документы выплат и заявлений.

Особенности отладки серверного кода

Если при попытке отследить заполнение реквизитов отладчик не останавливается внутри функции ДанныеСотрудникаДляЗаявленияНаВыплатуПособия, выясним причину. Модуль ОбменСведениямиОПособияхСФССПолныеПрава выполняется на стороне сервера. Для успешной отладки в клиент-серверной базе необходимо:

1. Убедиться, что служба сервера 1С:Предприятия (ragent) запущена с параметром -debug.
2. В конфигураторе в меню Отладка -> Подключение проверить наличие активного серверного соединения.
3. Либо временно выгрузить информационную базу в файловый вариант, где серверный и клиентский контексты выполняются в едином потоке.

Способы решения проблемы

Рассмотрим практические варианты обхода и исправления нежелательного наследования старых реквизитов.

Способ 1. Ручное исправление в первичном документе выплаты

Если на предприятии используется учет через документы заявлений в ФСС, актуальный адрес регистрации и банковские реквизиты можно вручную отредактировать непосредственно в первичном заявлении на вкладке данных сотрудника. После проведения этого документа он становится «последним документом» в выборке, и все последующие больничные листы будут автоматически подтягивать уже корректные сведения.

Способ 2. Использование внешней обработки заполнения табличной части

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

Способ 3. Доработка запроса в общем модуле

Если конфигурация снята с полной поддержки, можно скорректировать логику в общем модуле ОбменСведениямиОПособияхСФССПолныеПрава. В запросе функции ДанныеСотрудникаДляЗаявленияНаВыплатуПособия изменяется блок ВЫБОР: приоритет отдается актуальным данным из регистра Контактная информация, либо добавляется проверка давности предыдущего документа и наличия признака «Является продолжением листка нетрудоспособности».