В процессе разработки интеграций или обработок по загрузке данных в 1С:Зарплата и управление персоналом 3.1 программисты часто сталкиваются с тем, что обычная передача строки адреса не приводит к желаемому результату. Система либо «обрезает» страну, либо выдает ошибку, если в адресе вместо города указано село или деревня. Проанализируем, как правильно работать с подсистемой «Контактная информация» (КИ) библиотеки стандартных подсистем (БСП), которая лежит в основе ЗУП. Для глубокого изучения доступного инструментария рекомендуем использовать справочник по методам БСП (с примерами использования), так как работа с КИ в ЗУП целиком базируется на этой подсистеме.
При использовании стандартных методов преобразования текста в объект XDTO, таких как УправлениеКонтактнойИнформациейЛокализация.КонтактнаяИнформацияXDTOПоПредставлению, система пытается разобрать строку по определенным правилам. Если вид контактной информации (например, «Адрес по прописке») настроен в справочнике ВидыКонтактнойИнформации как российский адрес, то слово «Россия» считается избыточным и может удаляться. Однако при некорректном разборе вся остальная строка может сместиться, и валидация адреса по классификатору ГАР (ФИАС) провалится.
Рассмотрим пример кода, который часто приводит к ошибкам:
ВидАдресПоПрописке = Справочники.ВидыКонтактнойИнформации.АдресПоПропискеФизическиеЛица;
ТипАдресПоПрописке = ВидАдресПоПрописке.Тип;
ОбъектXDTOАдресПоПрописке = УправлениеКонтактнойИнформациейЛокализация.КонтактнаяИнформацияXDTOПоПредставлению(СокрЛП(Стр.АдресПоПропискеПредставление), ВидАдресПоПрописке);
ЗначенияПолей3 = УправлениеКонтактнойИнформациейЛокализация.КонтактнаяИнформацияXDTOВXML(ОбъектXDTOАдресПоПрописке);
УправлениеКонтактнойИнформацией.ЗаписатьКонтактнуюИнформацию(ФизЛицо, ЗначенияПолей3, ВидАдресПоПрописке, ТипАдресПоПрописке);
В этой ситуации главная проблема заключается в том, что метод КонтактнаяИнформацияXDTOПоПредставлению пытается угадать структуру адреса из плоской строки. Чтобы не тратить время на поиск альтернатив, можно заглянуть в справочник методов конфигурации Зарплата и кадры 3.1, который поможет быстро подобрать нужные функции для работы с объектами физических лиц.
Выясним причину, по которой программа «вылетает», если в адресе нет города, но есть село. В структуре адреса 1С (и ГАР) существуют разные уровни: City (Город) и Locality (Населенный пункт). Когда мы передаем строку, автоматический парсер может пытаться записать название села в поле города. Если поле города в структуре XDTO обязательно или ожидается в определенном формате, а данные попадают «не туда», возникает ошибка разбора. Это особенно актуально при формировании JSON или XML для хранения в базе.
В современных версиях 1С (БСП 3.x) адрес хранится не в XML, а в формате JSON. Для правильного формирования адреса по представлению рекомендуется использовать метод ПредставлениеВЗначение. Рассмотрим, как это сделать правильно:
// Определяем вид КИ
ВидКИ = Справочники.ВидыКонтактнойИнформации.АдресПоПропискеФизическиеЛица;
// Преобразуем строку в структурированное значение (JSON)
ЗначениеАдреса = УправлениеКонтактнойИнформацией.ПредставлениеВЗначение(ПредставлениеАдреса, ВидКИ);
// Записываем информацию
УправлениеКонтактнойИнформацией.ЗаписатьКонтактнуюИнформацию(СсылкаНаФизЛицо, ЗначениеАдреса, ВидКИ, Перечисления.ТипыКонтактнойИнформации.Адрес);
Метод ПредставлениеВЗначение более интеллектуален: он лучше справляется с определением населенных пунктов и автоматически подставляет CountryCode (для России — 643).
Если вы создаете физическое лицо программно «с нуля», удобнее не использовать внешние процедуры записи, а работать напрямую с табличной частью КонтактнаяИнформация самого объекта. Это гарантирует, что данные будут записаны вместе с объектом в одной транзакции. При этом важно учитывать, что программный интерфейс ЗУП часто скрывает за собой сложную бизнес-логику, которую необходимо соблюдать при программном заполнении данных.
Разберем этот способ по шагам:
СправочникОбъект.ФизическиеЛица.КонтактнаяИнформация.УправлениеКонтактнойИнформацией.ПредставлениеВЗначение для формирования поля ЗначенияПолей.
ФизЛицоОбъект = Справочники.ФизическиеЛица.СоздатьЭлемент();
// ... заполнение реквизитов ...
НоваяСтрокаКИ = ФизЛицоОбъект.КонтактнаяИнформация.Добавить();
НоваяСтрокаКИ.Вид = Справочники.ВидыКонтактнойИнформации.АдресПроживанияФизическиеЛица;
НоваяСтрокаКИ.Тип = Перечисления.ТипыКонтактнойИнформации.Адрес;
НоваяСтрокаКИ.Представление = Стр.АдресПроживанияПредставление;
// Важный момент: получение структурированного JSON
НоваяСтрокаКИ.ЗначенияПолей = УправлениеКонтактнойИнформацией.ПредставлениеВЗначение(Стр.АдресПроживанияПредставление, НоваяСтрокаКИ.Вид);
ФизЛицоОбъект.Записать();
Проанализируем дополнительные способы сделать адрес «валидным» (чтобы он подсвечивался зеленым в интерфейсе и правильно попадал в отчетность СФР/ПФР):
GUID адресных объектов по ФИАС/ГАР, обязательно передавайте их. В этом случае 1С не будет пытаться «угадать» адрес по строке, а точно привяжет его к классификатору.УправлениеКонтактнойИнформацией.СведенияОПредставленииАдреса, который вернет структуру полей. Для проверки корректности выгрузки полезно изучить, как формируются адреса физических лиц по колонкам (город, улица, дом, квартира), чтобы убедиться в правильном распределении данных по уровням ГАР.JSON.Для отладки и проверки того, как данные КИ хранятся и считываются через API, идеально подойдет консоль запросов ЗУП с поддержкой обращения к методам программного интерфейса, которая умеет работать с исполняемыми представлениями.
Резюмируем: Для корректной записи адреса в ЗУП 3.1 откажитесь от прямого манипулирования XDTO в пользу высокоуровневых функций БСП, таких как УправлениеКонтактнойИнформацией.ПредставлениеВЗначение. Это позволит избежать проблем с «исчезновением» России и корректно обрабатывать адреса сельской местности.