Бесшовная интеграция между решениями на платформе 1С, такими как 1С:ERP Управление предприятием (или 1С:Комплексная автоматизация) и 1С:Документооборот (ДО), является мощным инструментом для автоматизации бизнес-процессов — для этого есть модуль бесшовной интеграции 1С:ERP с 1С:Документооборот. Однако при попытке передачи пользовательских данных часто возникает ситуация, когда новые дополнительные реквизиты, созданные в одной базе, упорно отказываются появляться в правилах интеграции другой базы. В этой статье мы подробно разберем, как обеспечить корректную видимость и передачу дополнительных реквизитов, включая вставку QR-кода в файлы, проанализируем причины типовых ошибок и рассмотрим программные способы решения сложных задач.
Прежде чем приступать к настройкам на стороне ERP, нам необходимо убедиться, что реквизит в 1С:Документооборот создан правильно. Рассмотрим типичную архитектурную особенность ДО: дополнительные реквизиты в этой системе жестко привязаны к справочнику Виды внутренних документов (или других видов документов). Проанализируем чек-лист необходимых действий:
Внутренний документ, но не включить в конкретный вид, интеграция его «не увидит».Важно помнить: бесшовная интеграция работает в контексте конкретных видов документов. Если в правилах интеграции на стороне ERP выбран определенный вид документа, то система запрашивает через веб-сервис состав реквизитов именно для него.
Допустим, реквизит в ДО создан и привязан к виду документа, но при настройке правил интеграции в ERP в списке Передача в 1С:Документооборот он отсутствует. Выясним причину этой ситуации. Основным виновником здесь является кэширование метаданных.
Система ERP не обращается к веб-сервису ДО при каждом открытии формы. Она хранит структуру данных в локальном кэше. Чтобы заставить систему «увидеть» изменения, выполним следующие шаги:
DMService (веб-сервис Документооборота) для получения актуального описания полей — это удобно через анализатор HTTP-запросов для отладки веб-сервиса DMService.Рассмотрим ситуацию, когда реквизит в списке появился, сопоставление настроено, но при записи документа в ERP значение в Документооборот не «прилетает». Проанализируем механизмы сопоставления. По умолчанию система пытается сопоставить объекты (особенно ссылочного типа, такие как контрагенты или пользователи) по следующему алгоритму:
1. По уникальному идентификатору (GUID). Если объекты были ранее синхронизированы или перенесены через обмен данными, это самый надежный способ.
2. По наименованию. Если GUID не совпадают, система ищет объект с идентичным строковым представлением.
Если ваш дополнительный реквизит является списком значений, убедитесь, что в обеих базах элементы этого списка называются абсолютно одинаково — в этом поможет обработка массового изменения дополнительных реквизитов и сведений. Даже лишний пробел в конце строки приведет к тому, что сопоставление не сработает, и поле останется пустым.
Иногда стандартного сопоставления «поле в поле» недостаточно. Например, если нужно передать в один доп. реквизит ДО комбинацию данных из ERP или выполнить сложный поиск. В этом случае в правилах интеграции для нужного реквизита выберем вариант Из выражения на встроенном языке или применим произвольные действия дополнительных реквизитов — для написания кода пригодится консоль кода и запросов для отладки выражений на встроенном языке. Разберем, как правильно написать такой код.
Посмотрим на пример логики, через которую реализуется заполнение значения данных дополнительных сведений объекта, используемой в выражении на стороне ERP для формирования значения:
// Пример получения значения для передачи в ДО
Результат = "";
Если ТипЗнч(Источник.Сделка) = Тип("ДокументСсылка.ЗаказКлиента") Тогда
Результат = "Заказ №" + Источник.Сделка.Номер + " от " + Формат(Источник.Сделка.Дата, "ДЛФ=D");
КонецЕсли;
Однако, если нам нужно обратиться к дополнительным реквизитам самого объекта-источника в ERP, мы должны учитывать, что они хранятся в табличной части ДополнительныеРеквизиты. Рассмотрим более сложный пример, где мы ищем значение определенного доп. реквизита ERP по его имени, чтобы передать его в ДО:
// Поиск значения дополнительного реквизита в объекте ERP
ИмяРеквизитаДляПоиска = "СрочностьДоставки"; // Внутреннее имя или заголовок
НайденноеЗначение = Неопределено;
Для Каждого СтрокаДопРеквизитов Из Источник.ДополнительныеРеквизиты Цикл
Если СтрокаДопРеквизитов.Свойство.Заголовок = ИмяРеквизитаДляПоиска Тогда
НайденноеЗначение = СтрокаДопРеквизитов.Значение;
Прервать;
КонецЕсли;
КонецЦикла;
Результат = НайденноеЗначение;
В сообщениях форума часто упоминается использование GUID. Проанализируем ситуацию: использование жестко прописанных идентификаторов вида "6d049e68-f461-11ef-8fc6-0050569d66ab" является «плохим тоном» в разработке, так как при обновлении баз или миграции данных эти идентификаторы могут измениться.
Рекомендуется использовать поиск по Имени для разработчика. Это специальное поле в карточке дополнительного реквизита в 1С:ДО. Если оно заполнено, к реквизиту проще обращаться программно. Если же вы все-таки вынуждены использовать запросы в выражениях интеграции, старайтесь кэшировать результаты запросов, чтобы не замедлять работу веб-сервиса при каждой записи документа.
Пример использования функции общего модуля для получения значения (если конфигурация позволяет):
// Использование типовых функций управления свойствами
СвойствоСсылка = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("Проект");
Если ЗначениеЗаполнено(СвойствоСсылка) Тогда
Результат = УправлениеСвойствами.ЗначениеСвойства(Источник, СвойствоСсылка);
КонецЕсли;
Рассмотрим случай, когда данные должны возвращаться из Документооборота в ERP. Часто пользователи жалуются, что реквизит виден, сопоставление настроено, но данные не обновляются. Проанализируем возможные причины:
DMService.Для успешной настройки передачи дополнительных реквизитов мы должны убедиться в трех вещах: корректной привязке реквизита к Виду документа в ДО, отсутствии проблем с правами доступа веб-сервиса и актуальности кэша метаданных в ERP. Для этой задачи есть инструмент управления логикой заполнения и контроля реквизитов. Если типовое сопоставление не справляется, механизм выражений на встроенном языке предоставляет практически неограниченные возможности по трансформации данных, главное — обращаться к табличным частям дополнительных реквизитов правильно и избегать жесткой привязки к GUID.