В процессе интеграции «1С:Управление торговлей 11» (УТ 11) с внешними учетными системами, сайтами или CRM-платформами часто возникает критическая проблема: при регулярной загрузке или обновлении списка контрагентов стандартные поля контактной информации очищаются или перезаписываются данными из внешнего источника. Это особенно неприятно, если менеджеры в 1С ведут актуальную базу почтовых адресов вручную, а внешняя система присылает пустые значения или устаревшие данные.
В данной статье мы разберем, как решить эту задачу, рассмотрим различные механизмы платформы и конфигурации, которые позволят надежно хранить контактные данные в обход стандартных процессов очистки при обмене.
Разберем ситуацию: стандартный вид контактной информации Email для справочника Контрагенты жестко связан с правилами обмена. Чтобы обойти это ограничение, мы можем создать свой собственный вид контактной информации. В УТ 11 это делается в пользовательском режиме без программирования.
Проанализируем шаги по реализации этого метода:
Преимущество данного метода: Поскольку новый вид контактной информации имеет уникальный внутренний идентификатор (GUID), стандартные процедуры загрузки данных, настроенные на типовой Email, просто «не увидят» это поле и не смогут его очистить. При этом поле будет отображаться в карточке контрагента в общем списке адресов и телефонов, что удобно для пользователя.
В архитектуре УТ 11 разделены понятия Партнер (управленческая сущность) и Контрагент (юридическое лицо). Часто внешние обмены настраиваются только на справочник Контрагенты, так как именно он содержит ИНН/КПП и банковские реквизиты.
Рассмотрим стратегию хранения данных в справочнике Партнеры. Если загрузка из другой программы обновляет только подчиненные записи контрагентов, мы можем перенести хранение всех «живых» email-адресов на уровень партнера. Выясним, почему это эффективно: при синхронизации реквизиты юридического лица будут обновляться, но карточка партнера, к которой привязан этот контрагент, останется нетронутой. Это сохранит историю общения и контактные данные менеджеров.
Посмотрим на разницу между «Дополнительными реквизитами» и «Дополнительными сведениями». Это важный технический нюанс:
ДополнительныеСведения.Проанализируем, как настроить хранение через сведения:
Контрагенты.Такой подход гарантирует, что даже при полной перезаписи объекта Контрагент программным кодом, записи в регистре ДополнительныеСведения останутся неизменными, так как они физически лежат в другой таблице базы данных.
Если email-адресов много или они носят неформальный характер, рассмотрим подсистему Заметки. В типовых решениях 1С:ERP и УТ 11 заметки привязаны к объекту, но хранятся изолированно. Это позволяет хранить произвольный текст, включая адреса почты, который гарантированно не будет затронут никакими обработками обмена данными.
Если нам требуется гарантированное и строго типизированное хранение, мы можем создать собственное Расширение конфигурации. Рассмотрим пример создания нового регистра сведений для хранения дополнительных email-адресов.
Создадим регистр Доп_ЭлектронныеАдреса с измерениями Объект (тип СправочникСсылка.Контрагенты) и ресурсом АдресЭлектроннойПочты (тип Строка). Для работы с этим регистром можно использовать следующий код при записи или в специализированных формах:
// Пример записи нового email в независимый регистр через расширение
МенеджерЗаписи = РегистрыСведений.Доп_ЭлектронныеАдреса.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Объект = ВыбранныйКонтрагент;
МенеджерЗаписи.АдресЭлектроннойПочты = "work@example.com";
МенеджерЗаписи.Записать(Истина);
Этот метод является самым надежным с точки зрения целостности данных, так как ни одна штатная обработка загрузки не знает о существовании вашего регистра и не сможет внести в него изменения.
Выясним причину, почему данные вообще затираются. Обычно это происходит из-за того, что в правилах обмена (например, через EnterpriseData) для свойства КонтактнаяИнформация установлено правило «Замещать». Если у вас есть доступ к настройке правил обмена, разберем, что можно изменить:
В правилах конвертации объектов (ПКО) или в коде обработки загрузки можно добавить условие. Проанализируем пример логики:
// Логика в обработчике "ПриЗагрузке" или "ПередЗаписью"
Если ЗначениеЗаполнено(Объект.Ссылка.Email) И ПустаяСтрока(ОбъектПриемник.Email) Тогда
// Если в базе уже есть email, а из файла пришла пустота - игнорируем обновление поля
ОбъектПриемник.Email = Объект.Ссылка.Email;
КонецЕсли;
Использование флага «Не замещать значения существующих объектов в приемнике» для конкретных полей является наиболее правильным архитектурным решением, так как оно устраняет саму причину проблемы, а не создает «костыли» в виде дополнительных мест хранения.
Подводя итог, выберем оптимальный путь в зависимости от ваших возможностей:
Вид контактной информации с типом «Адрес электронной почты». Это быстро, удобно и безопасно.Дополнительные сведения, так как они хранятся в отдельном регистре.Таким образом, мы обеспечим сохранность важной контактной информации и стабильную работу системы обмена данными.