В современных конфигурациях 1С, таких как "Управление торговлей 11" (УТ 11), "ERP" или "Комплексная автоматизация", работа с адресами и телефонами построена на базе Библиотеки Стандартных Подсистем (БСП). Это означает, что контактная информация — это не просто строка, а сложный механизм с хранением данных в XML (XDTO) или JSON, валидацией через ФИАС и динамическими формами.
Часто перед разработчиками и аналитиками встает задача: необходимо к адресу доставки привязать дополнительные данные, например, географические координаты (широта, долгота), номер маршрута, этаж, код домофона или специфические метки для TMS-систем (систем управления транспортом). Давайте разберем подробно, почему это вызывает трудности и как правильно решить эту задачу программным способом.
Многие привыкли, что если нужно добавить поле к справочнику, мы просто добавляем новый реквизит или используем механизм "Дополнительные реквизиты и сведения" (ПВХ). Однако контактная информация в УТ 11 хранится в табличной части КонтактнаяИнформация.
Поэтому нам необходимо найти способ, как "подружить" адрес и наши новые данные (координаты). Рассмотрим варианты решения, предложенные в обсуждении, и углубимся в техническую реализацию.
Наиболее корректный способ вмешательства в работу подсистемы контактной информации — использование переопределяемых модулей БСП. Это позволяет нам настроить поведение системы так, чтобы при добавлении определенного вида информации срабатывали наши алгоритмы.
В теме форума предложено решение, которое позволяет зарегистрировать особый вид контактной информации (например, "Координаты") и определить его поведение. Давайте разберем этот процесс по шагам.
Прежде чем писать код, нам нужно создать сущность, с которой мы будем работать. В режиме "1С:Предприятие" (или программно через обновление ИБ) необходимо зайти в справочник ВидыКонтактнойИнформации.
Нам нужно создать новый элемент справочника:
Теперь нам нужно, чтобы система "подхватила" этот вид и знала, как с ним работать. Для этого используется общий модуль УправлениеКонтактнойИнформациейПереопределяемый (в некоторых версиях старых БСП код может располагаться в общем модуле УправлениеКонтактнойИнформацией, но править нужно именно переопределяемый или использовать расширение).
Нас интересует процедура ПриОпределенииНастроек. Этот метод вызывается при инициализации форм объектов, содержащих контактную информацию.
Разберем код, который необходимо добавить в эту процедуру:
Процедура ПриОпределенииНастроек(Настройки) Экспорт
// 1. Находим ссылку на наш новый вид контактной информации
// В реальном проекте лучше использовать предопределенный элемент или поиск по кешу,
// чтобы не делать запрос к БД при каждом открытии формы.
КоординатыВид = Справочники.ВидыКонтактнойИнформации.НайтиПоНаименованию("Координаты");
Если Не КоординатыВид.Пустая() Тогда
// 2. Копируем настройки для типа "Другое"
// Мы берем стандартное поведение для текстового поля "Другое" как базу
Описание = ОбщегоНазначения.СкопироватьРекурсивно(
УправлениеКонтактнойИнформацией.КомандыТипаКонтактнойИнформации(
Перечисления.ТипыКонтактнойИнформации.Другое
)
);
// 3. Здесь можно дополнительно настроить Описание.
// Например, указать подсказку или регулярное выражение для проверки ввода
// Описание.Подсказка = "Введите координаты в формате XX.XXXXXX, YY.YYYYYY";
// 4. Присваиваем описание нашему виду
Настройки.ОписаниеКоманд[КоординатыВид] = Описание;
КонецЕсли;
КонецПроцедуры
Что делает этот код?
ВидыКонтактнойИнформации (наши "Координаты") нужно использовать определенный набор команд и настроек интерфейса.КомандыТипаКонтактнойИнформации возвращает структуру настроек по умолчанию для типа. Мы берем тип "Другое", так как он наиболее гибкий.Настройки.ОписаниеКоманд, мы гарантируем, что на форме партнера это поле отрисуется корректно.Хотя вышеописанный метод решает задачу "добавить поле", давайте проанализируем ситуацию глубже. В сообщении №8 автор темы указывает: "Тут не хватает возможности, чтоб эти дополнительные поля были сразу определены при добавлении Адреса доставки".
Если мы просто добавим вид контактной информации "Координаты", то у нас в карточке партнера будут два разрозненных поля: "Адрес доставки" и "Координаты". Они визуально могут стоять рядом, но логически они не связаны. Если у партнера 5 адресов доставки, то добавление 5 полей координат превратит форму в хаос, и будет непонятно, какие координаты к какому адресу относятся.
Рекомендуемый подход для УТ 11:
В идеологии 1С:ERP и УТ 11, если у клиента (Партнера) есть несколько точек доставки с разными параметрами (координаты, график работы, контактное лицо, маршрут), то правильнее использовать иерархию справочника Партнеры.
При таком подходе вы можете использовать типовой механизм Дополнительных реквизитов (Администрирование -> Общие настройки -> Дополнительные реквизиты и сведения). Вы просто добавляете доп. реквизиты "Координаты (Широта)", "Координаты (Долгота)", "Номер маршрута" к справочнику Партнеры.
Преимущества этого метода:
Если же архитектура с подчиненными партнерами невозможна, и нужно хранить данные именно внутри строки адреса, рассмотрим техническую возможность, появившуюся в новых версиях БСП.
Поле Значение табличной части КонтактнаяИнформация — это строка неограниченной длины. В последних версиях платформы и БСП разработчики начали использовать формат JSON для хранения сложных структур.
Чтобы реализовать это, нам потребуется:
Значение.Пример (концептуальный):
СтруктураАдреса = Новый Структура;
СтруктураАдреса.Вставить("АдресСтрокой", ТекущийАдрес);
СтруктураАдреса.Вставить("Lat", 55.7558);
СтруктураАдреса.Вставить("Lon", 37.6173);
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, СтруктураАдреса);
СтрокаДляСохранения = ЗаписьJSON.Закрыть();
// Эту строку помещаем в ТЧ.КонтактнаяИнформация.Значение
Важно: Этот метод требует серьезной доработки форм ввода, так как стандартное поле ввода адреса не умеет отображать и редактировать JSON. Вам придется рисовать свои поля на форме и программно собирать/разбирать JSON при открытии и сохранении. Это трудоемкий путь.
Подведем итог решения задачи добавления реквизитов к адресу:
УправлениеКонтактнойИнформацией. Это создаст отдельное поле ввода.Для задачи интеграции с TMS (системы маршрутизации) чаще всего используется первый вариант, так как точка доставки является ключевой сущностью логистики.