Как решить проблему несоответствия адреса в ФИАС/ГАР паспортным данным сотрудника в 1С:ЗУП 3.1 при выгрузке в банк?

← На главную

При подготовке реестров на открытие лицевых счетов в рамках зарплатных проектов бухгалтеры и кадровики часто сталкиваются с неприятной ситуацией. Банк (например, Газпромбанк, Сбербанк или ВТБ) отклоняет файл выгрузки из-за того, что адрес регистрации сотрудника в файле не совпадает со штампом в его паспорте. Современные банковские системы жестко контролируют соответствие данных, используя технологии автоматического распознавания документов (OCR) и сверяя текстовый файл реестра со сканами паспортов буквально до каждого символа и пробела. Любое расхождение — и автоматика выдает ошибку, блокируя выпуск карты.

С другой стороны, программа 1С:Зарплата и Управление Персоналом 3.1 настоятельно требует вводить адреса строго по Государственному адресному реестру (ГАР / ФИАС). Попытки ввести адрес в произвольном виде приводят к тому, что в XML-файле выгрузки адрес передается одной строкой, тогда как банку требуются раздельные структурированные поля: улица, дом, корпус, квартира. В этой статье мы подробно разберем природу этой проблемы и рассмотрим несколько практических способов ее решения в 1С:ЗУП 3.1.

Выясняем причину: почему ГАР/ФИАС расходится с паспортом?

Для начала проанализируем, почему возникает эта техническая коллизия. В августе 2021 года Федеральная налоговая служба полностью перешла на новую структуру адресного классификатора — ГАР (Государственный адресный реестр), хотя пользователи по старинке продолжают называть его ФИАС.

Главное отличие новой системы заключается в переходе от административно-территориального деления к муниципальному делению. В паспортах граждан, получивших прописку до этой реформы, указаны административные единицы: например, "Раменский район, г. Раменское, дп Удельная". В современном же классификаторе ГАР этот адрес трансформировался в муниципальный: "Городской округ Раменский, дачный поселок Удельная". Сама программа 1С:ЗУП 3.1 ориентирована на новые стандарты, из-за чего кадровику крайне сложно «подружить» официальный классификатор с фактическим штампом в паспорте.

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

Способ 1. Переключение отображения адреса на административно-территориальное деление

В платформу 1С:Предприятие 8.3 заложена возможность переключения отображения структуры адреса. База ГАР фактически хранит в себе оба варианта деления территории. Если вашему банку принципиально видеть в файле старые «районы» вместо новых «городских округов», выполним следующие действия:

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

Способ 2. Отключение строгой проверки соответствия ФИАС/ГАР

Если нужного дома вообще нет в классификаторе ФИАС (например, новостройка или отдаленный поселок), а банк требует разбить адрес по полям в XML-файле, мы можем временно или на постоянной основе отключить жесткую блокировку ввода в настройках программы. Это позволит занести адрес «руками» строго по паспорту, сохранив его структуру по полям.

Проанализируем этот алгоритм:

Зайдем в программу под правами администратора и перейдем в раздел Администрирование — Общие настройки.
Раскроем подраздел Виды контактной информации.
В появившемся списке найдем группу Контактная информация справочника "Физические лица" и выберем элемент Адрес по прописке.
В открывшейся форме настройки найдем группу параметров Дополнительные настройки адреса.
Снимем флажок Запрещать ввод некорректного адреса и сохраним изменения.
Теперь вернемся в карточку сотрудника. Программа позволит нам вручную заполнить поля Улица, Дом, Корпус текстом, полностью идентичным паспортному штампу, даже если этого объекта нет в базе ГАР. Да, поля будут подчеркнуты красным цветом (как некорректные), но при формировании XML-реестра для банка все данные выгрузятся в строго структурированном виде, удовлетворяя требования валидаторов банка.

Способ 3. Обход ограничений через типы строений

Иногда программа не дает записать конкретный номер дома, потому что в ГАР этот объект зарегистрирован иначе (например, как владение или строение). Чтобы не отключать глобальную проверку адресов для всей базы, мы можем использовать маленькую хитрость:

При вводе адреса в форме вместо стандартного типа строения Дом выберем альтернативный вариант из выпадающего списка — например, Владение, Строение, Литера или Земельный участок. Зачастую классификатор ГАР содержит информацию об этих объектах, и это позволит сохранить корректность адреса для систем учета, предоставив банку максимально приближенные к оригиналу структурированные данные.

Способ 4. Создание специального поля «Адрес для банка» (Решение для разработчиков)

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

Мы можем создать дополнительный вид контактной информации, который будет использоваться исключительно для обмена с банками, оставив основной адрес по прописке нетронутым.

Разберем этот процесс по шагам:

В справочнике Виды контактной информации добавим новый элемент с наименованием Адрес для банка (прописка). Для него установим свободный ввод без проверки по ФИАС.
Напишем небольшое расширение для конфигурации 1С:ЗУП 3.1, которое будет перехватывать процедуру формирования XML-файла выгрузки для зарплатного проекта.

Посмотрим на пример программного кода, который можно использовать в расширении для подмены адреса при экспорте данных:


&Вместо("ЗаполнитьАдресныеДанныеДляВыгрузки")
Процедура Ист_ЗаполнитьАдресныеДанныеДляВыгрузки(ПараметрыВыгрузки, ФизическоеЛицо, ДанныеАдреса)
    
    // Проверим, заполнен ли у сотрудника специальный адрес для банка
    ТипАдресаДляБанка = Справочники.ВидыКонтактнойИнформации.НайтиПоНаименованию("Адрес для банка (прописка)");
    ТаблицаАдресаДляБанка = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияОбъекта(ФизическоеЛицо, ТипАдресаДляБанка);
    
    Если ТаблицаАдресаДляБанка.Количество() > 0 И ЗначениеЗаполнено(ТаблицаАдресаДляБанка[0].Представление) Тогда
        // Если спец. адрес заполнен, подставляем его структуру в выгрузку вместо стандартного адреса по прописке
        ДанныеАдреса = ТаблицаАдресаДляБанка[0];
    КонецЕсли;
    
    // Вызываем оригинальный обработчик для формирования XML-структуры
    ПродолжитьВызов(ПараметрыВыгрузки, ФизическоеЛицо, ДанныеАдреса);
    
КонецПроцедуры

Такой подход гарантирует, что регламентированная отчетность для государственных органов (ЕФС-1, Персонифицированные сведения, 6-НДФЛ) будет формироваться на основе актуального государственного реестра ГАР, а капризные банковские роботы получат информацию в точном соответствии с текстовыми штампами в паспортах сотрудников.

Резюме

Мы проанализировали проблему несоответствия адресов ФИАС/ГАР паспортным данным и разобрали различные методы борьбы с этой коллизией. В большинстве случаев достаточно временно отключить строгую проверку адресов в настройках контактной информации программы (Способ 2) либо переключить отображение классификатора на административное деление (Способ 1). Это позволит быстро отправить реестр в банк без привлечения программистов.