При работе в конфигурациях на обычных формах часто возникает вопрос: поддерживает ли штатная подсистема адресного классификатора «Управление торговлей» редакции 10.3 современный формат ФИАС или ГАР?
Проанализируем техническую составляющую проблемы и разберем доступные варианты решения задачи в случае необходимости загрузки и ввода актуальных адресов.
Конфигурация «Управление торговлей» 10.3 (как и «Управление производственным предприятием» 1.3) была спроектирована под стандарт классификатора КЛАДР. Эта подсистема использует «плоские» структуры данных формата .dbf и не рассчитана на использование уникальных идентификаторов объектов (GUID), а также сложных иерархических связей, присущих ФИАС и ГАР.
ФНС России прекратила официальную поддержку устаревшего формата КЛАДР и перешла на Государственный адресный реестр (ГАР). Вся адресная информация теперь поставляется в формате XML с разделением на муниципальное и административно-территориальное деление. Загрузить такие файлы напрямую штатным механизмом УТ 10.3 невозможно без изменения структуры базы и программного кода.
Разберем основные практические подходы, которые позволяют организовать работу с актуальными адресами в «1С:Управление торговлей 10.3».
Посмотрим на самый простой вариант, который не требует снятия конфигурации с поддержки или изменения исходного кода. Существуют специализированные утилиты и конвертеры, которые преобразуют свежие файлы выгрузок ГАР/ФИАС обратно в классический формат .dbf (КЛАДР).
Сформированные файлы загружаются в 1С через штатную обработку ЗагрузкаАдресногоКлассификатора. При этом подходе специфические сведения (например, GUID муниципального деления) не сохраняются, но этого объема данных вполне достаточно для корректного формирования печатных форм и первичных документов.
Рассмотрим наиболее современный и удобный способ ввода контактной информации. Вместо хранения тяжеловесных адресных баз внутри информационной базы 1С настраивается взаимодействие с внешними HTTP-сервисами автодополнения адресов.
Разберем по шагам, как организуется данный механизм:
Во вводных формах контактной информации добавляется вызов процедуры, отправляющей HTTP-запрос к веб-сервису с помощью штатных объектов платформы HTTPСоединение и HTTPЗапрос. Сервис возвращает полный актуальный адрес, индекс и нужные коды в формате JSON.
Посмотрим на базовый пример отправки запроса к веб-сервису:
Соединение = Новый HTTPСоединение("api.service.ru", 443, , , , Истина);
Запрос = Новый HTTPЗапрос("/suggest/address");
Запрос.Заголовки.Вставить("Content-Type", "application/json");
Запрос.Заголовки.Вставить("Authorization", "Token " + ТокенАвторизации);
Запрос.УстановитьТелоИзСтроки("{""query"": """ + ТекстЗапроса + """}");
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
РезультатJSON = Ответ.ПолучитьТелоКакСтроку();
Этот способ избавляет базу данных от разрастания из-за хранения миллионов адресных объектов и гарантирует всегда актуальные данные.
Проанализируем вариант полной доработки конфигурации. Программист может перенести функционал работы с адресным классификатором из актуальной Библиотеки Стандартных Подсистем (БСП) или внедрить стороннюю внешнюю обработку (например, с подгрузкой локальной базы адресов SQLite).
При таком подходе в базу добавляются новые регистры сведений и справочники для хранения GUID и структуры ГАР. Это требует высокой трудоемкости при первоначальной настройке и последующей поддержке кастомного кода при обновлениях.
Если предприятию требуется постоянная и полноценная работа со всеми требованиями законодательства, целесообразно рассмотреть миграцию на конфигурацию «Управление торговлей» редакции 11 (на управляемых формах), где поддержка ГАР и ФИАС реализована на уровне платформы с возможностью автоматического обновления через интернет-поддержку 1С.