Как загрузить адрес из строки в контактную информацию 1С как структурированный адрес КЛАДР?

При пакетном импорте данных контрагентов или физических лиц часто возникает задача перенести адрес из строкового реквизита внешней системы в типовую подсистему контактной информации 1С. Если просто записать строку в поле Представление, программа воспринимает адрес как неструктурированный произвольный текст. В таком случае форма ввода адреса по полям классификатора не открывается, а проверка по классификаторам КЛАДР или ФИАС становится невозможной.

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

Решение для конфигураций обычного приложения (УПП 1.3, УТ 10.3, КА 1.1)

В конфигурациях предыдущего поколения контактная информация контрагентов хранится в регистре сведений КонтактнаяИнформация. Для разбора строго сформированных строк в конфигурациях предусмотрен общий модуль УправлениеКонтактнойИнформацией.

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

// СтрАдрес — строка формата КЛАДР, где поля разделены запятыми
СтруктураАдреса = УправлениеКонтактнойИнформацией.ПолучитьСтруктуруАдресаИзСтроки(СтрАдрес);

// Заполняем реквизиты записи регистра или структуры объекта
УправлениеКонтактнойИнформацией.ЗаполнитьОбъектРедактированияАдресаПоСтруктуре(ЗаписьРегистра, СтруктураАдреса);

Проанализируем принцип работы функции ПолучитьСтруктуруАдресаИзСтроки. Данный метод ожидает строго фиксированный позиционный формат из 9 элементов, разделенных запятыми:

1. Почтовый индекс;
2. Регион (субъект РФ);
3. Район;
4. Город;
5. Населенный пункт;
6. Улица;
7. Дом;
8. Корпус / строение;
9. Квартира / офис.

Важное ограничение: функция опирается исключительно на количество запятых в строке. Если промежуточный элемент отсутствует (например, для городов федерального значения отсутствует поле района), разделитель-запятая обязательно должен оставаться на своем месте. Если запятые опущены, происходит смещение: улица запишется в реквизит Район, номер дома — в Город, и структура окажется испорченной.

Кроме того, если требуется строгая валидация по классификатору, элементам структуры необходимо сопоставить числовые коды КЛАДР. Для этого программно выполняется поиск записей в регистре сведений АдресныйКлассификатор по наименованиям найденных адресных объектов.

Особенности загрузки адресов в современных конфигурациях на базе БСП (ERP, КА 2, УТ 11, БП 3.0)

В современных конфигурациях подсистема контактной информации претерпела существенные изменения. Классификатор КЛАДР заменен на ФИАС/ГАР, а данные контактной информации хранятся в табличных частях объектов (например, табличная часть КонтактнаяИнформация справочника Контрагенты):

1. Реквизит Представление — итоговая строка адреса, видимая пользователю;
2. Реквизит ЗначенияПолей — сериализованный XML-документ по внутренней XDTO-схеме контактной информации;
3. Реквизит Значение — структурированное описание адреса в формате JSON.

Если в табличную часть поместить только Представление, адрес будет помечен как введенный вручную. Чтобы адрес стал валидным с точки зрения классификатора, в XML/JSON должны присутствовать уникальные идентификаторы объектов (GUID ФИАС/ГАР).

Для программного формирования корректного XML/JSON в БСП применяются методы модуля УправлениеКонтактнойИнформацией (например, функция КонтактнаяИнформацияВXML) и вспомогательные алгоритмы модуля РаботаСАдресамиКлиентСервер. При формировании структуры адреса заполняются поля с типами адресных элементов, их наименованиями и кодами, после чего сериализованная строка записывается в реквизит ЗначенияПолей или Значение.

Что делать, если адрес записан в произвольной строке?

На практике адресные строки часто выгружаются из внешних систем в «грязном» виде: с перепутанным порядком слов, опечатками, сокращениями или без разделителей. Типовые функции прямого позиционного разбора с такими строками справиться не могут. Рассмотрим основные подходы к решению этой задачи:

1. Поэтапный поиск по локальным адресным таблицам: Алгоритм выделяет слова из строки и последовательно ищет соответствия в загруженных адресных сведениях базы — сначала определяет субъект РФ, затем в рамках найденного региона ищет город или населенный пункт, далее улицу, а оставшуюся часть строки разбирает регулярными выражениями для извлечения номера дома, корпуса и квартиры.
2. Использование внешних сервисов стандартизации адресов: Для больших массивов разнородных данных наиболее надежным решением является нормализация через специализированные API сервисов подсказок и стандартизации. Такие сервисы автоматически исправляют ошибки, определяют иерархию адресных элементов и возвращают полностью готовую структуру с кодами КЛАДР и актуальными идентификаторами ФИАС/ГАР, которую затем легко загрузить в 1С.