Как программно записать адрес в административно-территориальном формате в 1С?

← На главную

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

Почему адрес записывается в «Свободной форме»?

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

Решение 1: Использование механизма автоматического разбора строки

Как выяснилось в ходе обсуждения (Сообщение 8), самым простым и эффективным способом для конфигураций на базе БСП (Библиотеки стандартных подсистем) является передача простого строкового представления адреса. Внутренние механизмы 1С сами попытаются «распарсить» эту строку и сопоставить её с адресным классификатором.

Рассмотрим пример кода, который решает задачу:


// Определяем ссылку на объект (Контрагент, Организация и т.д.)
// Ссылка = ... 

// Формируем строковое представление адреса точно по правилам классификатора
Представление = "455023, Челябинская обл, г Магнитогорск, ул Ленинградская, д. 5, кв. 76";

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

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

Решение 2: Программное формирование структуры с указанием типа

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

Проанализируем пример расширенного формирования контактной информации:


АдресСтруктура = Новый Структура;
АдресСтруктура.Вставить("Представление", "455023, Челябинская обл, г Магнитогорск, ул Ленинградская, д. 5, кв. 76");
// Важный момент: ключи должны соответствовать ожидаемым в БСП
АдресСтруктура.Вставить("Страна", "РОССИЯ");
АдресСтруктура.Вставить("Регион", "Челябинская обл"); // Именно 'Регион', а не 'Район'
АдресСтруктура.Вставить("Город", "Магнитогорск");
АдресСтруктура.Вставить("Улица", "Ленинградская");
АдресСтруктура.Вставить("Дом", "5");
АдресСтруктура.Вставить("Квартира", "76");

// Добавляем явное указание типа адреса
// В современных версиях это может быть "AddressRF" (Административный) 
// или "AddressRFMunicipal" (Муниципальный)
АдресСтруктура.Vinsert("AddressType", "AddressRF"); 

// Преобразуем структуру в XML, а затем в JSON
АдресXML = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВXML(
    АдресСтруктура, 
    "", 
    Перечисления.ТипыКонтактнойИнформации.Адрес
);
АдресJSON = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВJSON(АдресXML);

// Записываем информацию
УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию(
    Ссылка, 
    АдресJSON, 
    Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента, 
    ТекущаяДата(), 
    Истина
);

Решение 3: Валидация адреса перед записью

Выясним причину, по которой адрес может все же «свалиться» в свободную форму. Это происходит, если в базе не загружен адресный классификатор по нужному региону или в строке допущена ошибка (например, лишнее сокращение). Чтобы избежать этого, рекомендуется использовать предварительный разбор через специализированные методы БСП.

Посмотрим на пример функции, которая проверяет корректность разбора:


Функция ПолучитьСтруктурированныйАдрес(ТекстАдреса)
    // Метод пытается сопоставить текст с ФИАС/ГАР
    РезультатРазбора = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияИзСтроки(
        ТекстАдреса, 
        , 
        Перечисления.ТипыКонтактнойИнформации.Адрес
    );
    
    // Если результат содержит только текст представления, значит разбор не удался
    // Можно добавить логику проверки идентификаторов (GUID)
    Возврат РезультатРазбора;
КонецФункции

Важные рекомендации по работе с контактной информацией

Соблюдайте порядок элементов: При использовании Решения №1 (передача строки) старайтесь придерживаться формата: Индекс, Регион, Район, Город, Населенный пункт, Улица, Дом, Корпус, Квартира. Именно в таком порядке парсер работает наиболее стабильно.
Обновляйте классификатор: Если адрес «свежий» (новые дома), 1С не сможет его структурировать, пока вы не загрузите актуальные данные ФИАС/ГАР через веб-сервис или из файла.
Используйте идентификаторы: Для максимальной надежности при интеграциях с внешними сайтами передавайте не только текст, но и ID объектов (города, улицы) из ФИАС. В структуре JSON они записываются в поля cityId, streetId и т.д.
Проверяйте Вид контактной информации: Убедитесь, что в справочнике ВидыКонтактнойИнформации для выбранного элемента (например, «Юридический адрес») установлен флаг «Проверять по ФИАС».

Подведем итог: Для большинства задач в типовых конфигурациях (Садовод, БП 3.0) достаточно использовать метод УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию, передавая в него правильно оформленную строку. Если же требуется сложная логика, используйте формирование JSON через промежуточное преобразование XML с обязательным указанием AddressType.