При переходе на современные конфигурации, разработанные на базе 1С:Библиотеки стандартных подсистем (БСП), разработчики часто сталкиваются со сложностями при попытке программно записать или обновить контактную информацию (адреса, телефоны, email) контрагентов, физических лиц или партнеров. В старых редакциях (например, в Управлении торговлей 10.3) данные хранились в плоском регистре сведений, и их запись не вызывала вопросов. В современных же конфигурациях, таких как 1С:Бухгалтерия предприятия 3.0, 1С:ERP или 1С:Комплексная автоматизация, механизм хранения и обработки контактной информации устроен значительно сложнее.
В этой статье мы подробно разберем архитектуру хранения контактной информации в БСП, выясним причины возможных ошибок при простом добавлении строк в табличную часть и рассмотрим три надежных способа программного заполнения этих данных с использованием готовых функций типового функционала.
Давайте проанализируем, где и в каком виде хранятся данные. Вся контактная информация (сокращенно — КИ) действительно записывается в табличную часть КонтактнаяИнформация конкретного объекта (справочника Контрагенты, ФизическиеЛица, Организации и т.д.). Однако структура этой табличной части содержит специфические поля:
Тип, Вид, Представление.Страна, Регион, Город, ЗначениеРазделенное. Они необходимы платформе исключительно для быстрого построения отчетов, отборов и индексации в запросах.Значение (в формате JSON) и ЗначенияПолей (в формате XML).Важно понимать: интерактивные формы 1С работают именно с сериализованными XML и JSON данными. Если вы попытаетесь напрямую добавить строку в табличную часть через стандартный метод Объект.КонтактнаяИнформация.Добавить() и заполнить только текстовое поле Представление, то при открытии карточки контрагента пользователь увидит пустые поля адреса. Более того, при первом же ручном сохранении объекта пользователем некорректно заполненная строка КИ будет полностью стерта системой, так как валидация БСП не найдет валидной XDTO-структуры в полях Значение и ЗначенияПолей.
Для корректной работы нам необходимо использовать программный интерфейс БСП. Все ключевые методы сосредоточены в общем модуле УправлениеКонтактнойИнформацией. Рассмотрим подробнее основные сценарии программного заполнения.
Представим ситуацию: у вас есть простая текстовая строка с адресом (например, полученная из внешнего файла Excel или сторонней CRM-системы): "620000, Свердловская обл, г. Екатеринбург, ул. Ленина, д. 5, оф. 10". Вы хотите записать ее контрагенту так, чтобы система сама попыталась сопоставить элементы адреса со справочником ФИАС/ГАР.
Для этого в общем модуле УправлениеКонтактнойИнформацией предусмотрена процедура ДобавитьКонтактнуюИнформацию. Давайте разберем пример ее использования:
// Предположим, что у нас уже есть ссылка на контрагента, и мы открыли его объект для редактирования
КонтрагентОбъект = СсылкаНаКонтрагента.ПолучитьОбъект();
// Определяем вид контактной информации, который мы хотим заполнить
ВидКИ = Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента;
// Задаем текстовое представление адреса
СтрокаАдреса = "620000, Свердловская обл, г. Екатеринбург, ул. Ленина, д. 5, оф. 10";
// Вызываем метод БСП для добавления информации
УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию(
КонтрагентОбъект,
СтрокаАдреса,
ВидКИ,
ТекущаяДата(),
Истина, // Замещать существующую запись этого вида
Истина // Запускать автоматическое распознавание адреса по ФИАС/ГАР
);
// Обязательно записываем объект контрагента для фиксации изменений в базе данных
КонтрагентОбъект.Записать();
Этот способ максимально прост в реализации. Система берет на себя всю черновую работу по парсингу строки, генерации XML-структуры и заполнению плоских полей. Однако помните, что если строка написана с грубыми ошибками или сокращениями, распознавание по ФИАС может сработать некорректно, и адрес запишется как "неформализованный".
Если вы переносите данные из конфигурации Управление торговлей 10.3 или любой другой системы, где адрес изначально хранился в раздельных полях (индекс, регион, город, улица, дом, квартира), собирать их обратно в одну плоскую строку для последующего распознавания — плохая практика. Намного надежнее сразу передать БСП структурированную информацию.
Для реализации этого сценария мы сначала создадим пустую структуру КИ нужного типа, заполним её свойства и передадим в сериализатор БСП для получения JSON и XML. Посмотрим на практический пример:
// 1. Получаем объект контрагента для изменения
КонтрагентОбъект = СсылкаНаКонтрагента.ПолучитьОбъект();
// 2. Инициализируем структуру КИ для типа "Адрес"
АдресСтруктура = УправлениеКонтактнойИнформацией.ОписаниеНовойКонтактнойИнформации(Перечисления.ТипыКонтактнойИнформации.Адрес);
// 3. Наполняем структуру структурированными данными из старой базы
АдресСтруктура.country = "РОССИЯ";
АдресСтруктура.countryCode = "643";
АдресСтруктура.ZIPcode = "620000"; // Почтовый индекс
АдресСтруктура.area = "Свердловская обл"; // Регион
АдресСтруктура.city = "Екатеринбург"; // Город
АдресСтруктура.street = "Ленина"; // Улица
АдресСтруктура.houseNumber = "5"; // Номер дома
АдресСтруктура.flat = "10"; // Офис / Квартира
// 4. Генерируем XML и JSON строки, соответствующие требованиям БСП
АдресXML = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВXML(АдресСтруктура, , Перечисления.ТипыКонтактнойИнформации.Адрес);
АдресJSON = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВJSON(АдресXML);
// 5. Записываем подготовленные сериализованные данные в объект контрагента
ВидКИ = Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента;
УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию(
КонтрагентОбъект,
АдресJSON,
ВидКИ,
ТекущаяДата(),
Истина // Замещать существующую запись
);
// Сохраняем изменения
КонтрагентОбъект.Записать();
Использование этого метода гарантирует стопроцентную точность переноса. Адрес в карточке контрагента сразу откроется в корректно разнесенном по полям виде, и у пользователей не возникнет никаких проблем при формировании первичных документов (УПД, Счетов-фактур), где крайне важна точность адреса.
Помимо адресов, разработчикам регулярно требуется программно вносить телефоны и адреса электронной почты. С ними работать значительно проще, так как их структура содержит меньше полей. Тем не менее, для них также рекомендуется использовать стандартные методы БСП.
Рассмотрим пример добавления адреса электронной почты и номера телефона:
КонтрагентОбъект = СсылкаНаКонтрагента.ПолучитьОбъект();
// Запись Email
ВидEmail = Справочники.ВидыКонтактнойИнформации.EmailКонтрагента;
СтрокаEmail = "info@romashka.ru";
УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию(
КонтрагентОбъект,
СтрокаEmail,
ВидEmail,
ТекущаяДата(),
Истина
);
// Запись Телефона
ВидТелефона = Справочники.ВидыКонтактнойИнформации.ТелефонКонтрагента;
СтрокаТелефона = "+7 (999) 111-22-33";
// Для телефона также можно подготовить структуру, если нужно разделить код страны, города и добавочный номер
ТелефонСтруктура = УправлениеКонтактнойИнформацией.ОписаниеНовойКонтактнойИнформации(Перечисления.ТипыКонтактнойИнформации.Телефон);
ТелефонСтруктура.phoneNumber = "1112233";
ТелефонСтруктура.countryCode = "7";
ТелефонСтруктура.areaCode = "999";
ТелефонXML = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВXML(ТелефонСтруктура, , Перечисления.ТипыКонтактнойИнформации.Телефон);
ТелефонJSON = УправлениеКонтактнойИнформацией.КонтактнаяИнформацияВJSON(ТелефонXML);
УправлениеКонтактнойИнформацией.ДобавитьКонтактнуюИнформацию(
КонтрагентОбъект,
ТелефонJSON,
ВидТелефона,
ТекущаяДата(),
Истина
);
КонтрагентОбъект.Записать();
Мы проанализировали внутренние механизмы хранения КИ в конфигурациях на базе БСП и убедились, что ручное манипулирование строками табличной части часто приводит к ошибкам десериализации и потере данных. Использование штатных процедур общего модуля УправлениеКонтактнойИнформацией полностью решает эту проблему.
При выборе метода руководствуйтесь простым правилом: если исходные данные представляют собой сплошной текст — используйте автоматический разбор по ФИАС (Способ 1). Если же данные структурированы — формируйте промежуточную структуру ОписаниеНовойКонтактнойИнформации (Способ 2), чтобы избежать ошибок неточного распознавания.