Переход на новые версии программных модулей в 1С всегда сопряжен с адаптацией существующего кода. Особенно это актуально для интеграционных решений, таких как модуль 1С:Диадок. Пользователи, ранее работавшие с модулем "Диадок Стандарт", сталкиваются с необходимостью переработки своих алгоритмов при миграции на "Диадок Универсал". Одна из таких распространенных проблем — поиск функционала, аналогичного устаревшему методу ЗаполнитьСтруктуруАдреса, который активно использовался для работы с адресными данными контрагентов и организаций. Давайте разберем, как мы можем решить эту задачу и адаптировать наш код под новую архитектуру.
В предыдущих версиях, при использовании "Диадок Стандарт", механизм заполнения адресной информации выглядел примерно так:
СтруктураAddress = ОсновнойМодуль.ПолучитьМодульПрог("Модуль_Диадок_РаботаСКонтентом").Новый_AddressInfo();
ОсновнойМодуль.ПолучитьМодульПрог("Модуль_ИнтеграцияУниверсальнаяЛогика").ЗаполнитьСтруктуруАдреса(СтруктураAddress, пГоловнойКонтрагент, Истина);
Такой подход подразумевал динамическую загрузку подмодулей через ОсновнойМодуль.ПолучитьМодульПрог. Однако, в "Диадок Универсал" эта парадигма изменилась. Теперь, при работе с подключаемым модулем (ПМ), разработчики обнаруживают, что им доступно только "ядро" модуля. Это вызывает закономерный вопрос: как добраться до нужного функционала, в частности, до операций с адресами, если прямой вызов привычных методов больше не работает?
Мы вместе исследуем архитектурные изменения, выясним, как универсальный модуль управляет адресными данными, и предложим пути для адаптации вашего кода.
AddressInfo и ее ролиПрежде чем погружаться в особенности "Универсала", давайте кратко вспомним, что представляет собой структура AddressInfo. Эта структура является стандартизированным способом хранения и передачи адресных сведений в рамках интеграции с Диадоком. Ее унифицированный формат позволяет корректно обмениваться информацией об адресах между вашей системой 1С и внешними сервисами ЭДО.
Обычно структура AddressInfo включает в себя следующие ключевые поля:
КодАдреса: Уникальный идентификатор адреса, если таковой предусмотрен системой.ТекстАдреса: Полный текстовый адрес одной строкой.Страна: Код или наименование страны.Индекс: Почтовый индекс.Область: Наименование области, региона, края.Район: Район в составе области.Город: Город, населенный пункт.НаселенныйПункт: Дополнительное уточнение населенного пункта (например, поселок, деревня).Улица: Наименование улицы.Дом: Номер дома.Корпус: Номер корпуса.Строение: Номер строения.Квартира: Номер квартиры или офиса.КодРегиона: Код региона по ФИАС или другим классификаторам.Важно понимать, что сама структура AddressInfo, как концепция и набор полей, скорее всего, осталась неизменной в "Диадок Универсал", так как она отражает общепринятый формат адресных данных. Изменился лишь способ ее создания, получения и заполнения.
Сохранение единообразия данных в этой структуре критически важно для корректной работы электронного документооборота, поскольку эти данные используются для определения сторон сделки, доставки документов и их юридической значимости.
Центральным изменением в "Диадок Универсал" стал подход к организации доступа к функционалу. Если раньше мы динамически загружали отдельные модули, то теперь все взаимодействие происходит через так называемое "ядро" подключаемого модуля. Это своего рода центральный диспетчер, который предоставляет интерфейс для всех основных операций.
Почему произошла такая смена парадигмы? Мы можем предположить, что это сделано для:
Как же это влияет на нашу задачу по работе с адресами? Вместо того чтобы искать модуль "Модуль_ИнтеграцияУниверсальнаяЛогика" и его функцию ЗаполнитьСтруктуруАдреса, нам теперь необходимо взаимодействовать непосредственно с ядром универсального модуля. Из ядра мы можем получить доступ к основным сущностям, таким как организации, контрагенты, а уже через них — к их адресной информации.
Например, в документации к "Диадок 1С" упоминается структура ExtendedOrganizationInfo (расширенные сведения об организации). Эта структура, которая, вероятно, получается из ядра, может содержать коллекцию AddressInfo для различных типов адресов организации (юридический, почтовый и т.д.). Это означает, что заполнение адресной информации, скорее всего, происходит через методы, связанные с работой непосредственно с объектами организаций или контрагентов, доступными из ядра универсального модуля.
Нам потребуется изучить "Методы универсального модуля", фокусируясь на разделах, касающихся работы с:
В этих разделах мы будем искать методы, позволяющие получить или модифицировать объекты, которые содержат адресные данные.
ЗаполнитьСтруктуруАдресаТеперь, когда мы понимаем новую архитектуру, давайте пошагово рассмотрим, как мы можем найти и реализовать необходимый функционал для заполнения адресов в "Диадок Универсал".
Изучаем актуальную документацию по "Диадок Универсал". Это первый и самый важный шаг. Нам необходимо найти официальные руководства, описание API или примеры кода, предоставленные разработчиками модуля. Мы будем искать разделы, посвященные работе с:
AddressInfo, если это необходимо.Исследуем программный интерфейс ядра универсального модуля. Если документация не дает прямого ответа, или нам нужны более глубокие детали, мы можем программно изучить доступные методы и свойства ядра. Обычно ядро предоставляется как экспортируемый объект подключаемого модуля.
Мы будем искать методы, которые позволяют:
Примерный подход к исследованию (для отладки):
// Предположим, что "ОбъектЯдраДиадокУниверсал" - это экспортируемый объект вашего подключаемого модуля
// Получаем доступ к ядру
Ядро = ОбъектЯдраДиадокУниверсал;
// Если мы знаем имя метода, можем попытаться его вызвать,
// но чаще всего приходится исследовать свойства объекта "Ядро" в отладчике.
// Например, для получения текущей организации:
// Организация = Ядро.ПолучитьМоюОрганизацию();
//
// Для получения контрагента:
// ПараметрыПоиска = Новый Структура("ИНН, КПП", "1234567890", "123450001");
// Контрагент = Ядро.НайтиКонтрагента(ПараметрыПоиска);
// Далее в отладчике исследуем объекты "Организация" или "Контрагент"
// на предмет наличия свойств, содержащих адресные данные или коллекции адресов.
Проверяем наличие объектов для работы с адресами. После получения объекта организации или контрагента (например, OrganizationInfo или ExtendedOrganizationInfo), мы должны найти в нем свойства, которые содержат или позволяют управлять адресной информацией.
Наиболее вероятные сценарии:
AddressInfo (например, Организация.ЮридическийАдрес, Контрагент.ПочтовыйАдрес).AddressInfo (например, Организация.Адреса.Добавить(НоваяСтруктураАдреса)).Адаптируем логику заполнения. После того как мы идентифицировали способ получения или создания объекта AddressInfo, мы можем адаптировать наш старый код. Вместо вызова ЗаполнитьСтруктуруАдреса, мы будем напрямую присваивать значения полям найденной или созданной структуры AddressInfo.
Рассмотрим примерный псевдокод, который демонстрирует этот подход:
// Примерный псевдокод для "Диадок Универсал"
// Предполагаем, что "ЯдроДиадокУниверсал" - это доступный объект ядра
// и у него есть методы для получения информации об организации или контрагенте.
// 1. Получаем объект, представляющий организацию или контрагента через ядро.
// Метод может отличаться в зависимости от API модуля.
// Например, для получения информации о нашей собственной организации:
ОрганизацияИнформация = ЯдроДиадокУниверсал.ПолучитьМоюОрганизацию();
// Или для получения данных контрагента по ИНН/КПП:
// ПараметрыПоиска = Новый Структура;
// ПараметрыПоиска.Вставить("ИНН", пГоловнойКонтрагент.ИНН);
// ПараметрыПоиска.Вставить("КПП", пГоловнойКонтрагент.КПП);
// КонтрагентИнформация = ЯдроДиадокУниверсал.ПолучитьКонтрагентаПоРеквизитам(ПараметрыПоиска);
Если ОрганизацияИнформация <> Неопределено Тогда
// 2. Доступ к коллекции адресов или полям адреса.
// В ExtendedOrganizationInfo (или аналогичных структурах для контрагентов)
// могут быть поля типа AddressInfo (например, ЮридическийАдрес, ПочтовыйАдрес)
// или коллекция адресов.
СтруктураAddress = ОрганизацияИнформация.ЮридическийАдрес; // Предполагаем, что такое свойство есть
Если СтруктураAddress = Неопределено Тогда
// Если юридического адреса еще нет, нам нужно его создать.
// Метод создания нового AddressInfo может быть методом ядра
// или методом коллекции адресов.
СтруктураAddress = ЯдроДиадокУниверсал.СоздатьAddressInfo();
// И затем присвоить его свойству организации
ОрганизацияИнформация.ЮридическийАдрес = СтруктураAddress;
// Альтернативно, если есть коллекция:
// СтруктураAddress = ОрганизацияИнформация.Адреса.Добавить(); // Добавляем новый элемент в коллекцию
// ОрганизацияИнформация.Адреса.УстановитьТипАдреса(СтруктураAddress, "Юридический"); // Если нужно указать тип
КонецЕсли;
// 3. Заполняем поля структуры AddressInfo данными из наших источников (например, из контрагента 1С).
// Мы используем "пГоловнойКонтрагент" из исходного сообщения как источник данных.
// Здесь логика заполнения будет зависеть от того, как в вашей системе 1С хранятся адреса
// и какие данные доступны в пГоловнойКонтрагент.
// Пример заполнения из абстрактного объекта "ДанныеАдреса"
// Обычно здесь будет маппинг полей из объекта Контрагент 1С
СтруктураAddress.КодАдреса = "001"; // Если есть внутренний код
СтруктураAddress.ТекстАдреса = "г. Москва, ул. Ленина, д. 10, кв. 5";
СтруктураAddress.Страна = "Россия";
СтруктураAddress.Индекс = "123456";
СтруктураAddress.Область = "Московская";
СтруктураAddress.Город = "Москва";
СтруктураAddress.Улица = "Ленина";
СтруктураAddress.Дом = "10";
СтруктураAddress.Квартира = "5";
// ... и так далее для всех необходимых полей
// 4. Если объект организации/контрагента был изменен, возможно,
// потребуется сохранить эти изменения через ядро.
// Это может быть специальный метод, который синхронизирует данные
// с внутренним состоянием модуля или базой данных Диадока.
ЯдроДиадокУниверсал.СохранитьОрганизацию(ОрганизацияИнформация);
// Или: ЯдроДиадокУниверсал.ЗаписатьКонтрагента(КонтрагентИнформация);
Иначе
// Обработка случая, если организация/контрагент не найдены
Сообщить("Не удалось получить информацию об организации/контрагенте.");
КонецЕсли;
Как мы видим, основной принцип заключается в получении объекта, связанного с организацией или контрагентом через ядро модуля, а затем непосредственной работе с его адресными свойствами или коллекциями.
Помимо изменений в работе с адресами, важно отметить и другие функциональные различия, которые могут повлиять на вашу интеграцию при переходе со "Стандарта" на "Универсал". Эти моменты были упомянуты в обсуждении и подчеркивают общую тенденцию к переработке логики в новом модуле.
Механизм переотправки документов. "Диадок Универсал" предлагает более гибкие возможности для повторной отправки документов после внесения изменений, что является значительным улучшением для бизнес-процессов. Теперь доступно три основных способа:
Это дает пользователям больше контроля и вариативности в сценариях, требующих корректировки уже отправленных документов.
Ограничения при добавлении файлов. Одно из существенных изменений, на которое обратили внимание пользователи, касается прикрепления файлов. Если в "Диадок Стандарт" была возможность добавлять файлы сразу к нескольким пакетам документов, то в "Диадок Универсал" эта функциональность ограничена:
Это может потребовать пересмотра рабочих процессов, если ваш бизнес-сценарий активно использовал прикрепление одного файла к нескольким пакетам. Возможно, потребуется дублирование файла или изменение логики формирования пакетов.
Заполнение реквизитов при сопоставлении УПД. Еще одно отмеченное различие касается автоматического заполнения некоторых реквизитов. При сопоставлении входящего универсального передаточного документа (УПД) с документом "Поступление товаров и услуг" в 1С:
КодСпособаПолучения в подчиненном счете-фактуре не проставляется автоматически со значением "2" (получен по почте), как это могло быть ранее в "Стандарте".Это может потребовать ручного дозаполнения или доработки для автоматической установки этого реквизита, чтобы обеспечить корректность учетных данных, особенно для налогового учета.
Переход на "Диадок Универсал" требует глубокого понимания новой архитектуры и принципов работы. Хотя прямые аналоги старых функций, таких как ЗаполнитьСтруктуруАдреса, могут отсутствовать, новый модуль предлагает более структурированный и унифицированный подход через свое "ядро". Ключ к успешной миграции — это внимательное изучение документации, экспериментирование с методами ядра в отладчике и адаптация вашей логики работы с сущностями модуля.
Мы настоятельно рекомендуем всегда обращаться к актуальной официальной документации от разработчиков 1С:Диадок, поскольку API и функционал могут развиваться и изменяться. Только так вы сможете гарантировать корректную и стабильную работу вашей интеграции.