Почему в модуле Контур.EDI при отправке УПД не заполняется основание и договор?

← На главную

При интеграции 1С с торговыми сетями через модуль Контур.EDI пользователи часто сталкиваются с ситуацией: при формировании исходящего универсального передаточного документа (УПД) поле Основание передачи (договор/соглашение) остается незаполненным. При этом в самой учетной системе 1С в документе реализации договор выбран, а отладка показывает, что параметры передаются, но итоговый файл УПД все равно формируется пустым в части основания.

Разберем детально механизм работы связки EDI и ЭДО, выясним архитектурную причину такого поведения и рассмотрим готовый программный способ исправления ситуации.

Архитектурные особенности формирования УПД через цепочку EDI

Для понимания сути проблемы проанализируем, как устроен процесс обмена электронными документами с торговыми сетями:

Цепочка EDI-сообщений: Работа с ритейлерами строится на стандартизированных сообщениях. Сначала от сети поступает электронный заказ ORDERS, поставщик отправляет уведомление об отгрузке DESADV, затем покупатель подтверждает приемку через RECADV.
Формирование сообщения INVOIC: На основании учетных документов 1С и входящей EDI-цепочки модуль 1С формирует исходящий структурированный файл INVOIC (электронный счет/накладная в формате EDI).
Генерация юридически значимого УПД: Сформированное сообщение INVOIC отправляется на сервер провайдера Контур. Серверная часть автоматически генерирует XML-титул продавца УПД по утвержденному формату ФНС (заполняя узлы ОснПер и СвДогОтгр на основе данных из INVOIC) с учетом специфических требований конкретной торговой сети.
Подписание через Диадок: Сгенерированный УПД отправляется в сервис Диадок, откуда модуль 1С получает идентификаторы документа и подписывает его электронной подписью (ЭП) организации.

Причина ошибки: По умолчанию алгоритмы модуля Контур.EDI транслируют данные о договоре из входящего заказа ORDERS. Если торговая сеть присылает заказ без заполненного блока договора, модуль считает этот реквизит отсутствующим и не создает узел contractIdentificator внутри XML сообщения INVOIC. В результате сервер генерации УПД не находит сведений о договоре и оставляет блок основания пустым, даже если в документе информационной базы 1С договор был корректно выбран.

Решение проблемы через подключаемый модуль расширения

Чтобы реквизиты договора гарантированно попадали в УПД независимо от данных во входящем заказе сети, переопределим логику заполнения исходящего сообщения. Разработчики модуля Контур.EDI предусматривают специальные точки расширения (внешние подключаемые модули), что позволяет сохранить типовую обработку обновляемой.

Рассмотрим алгоритм доработки: проверим, заполнена ли структура договора в сообщении INVOIC. Если номер договора пуст, подставим номер и дату договора из реквизита Контракт1С связанного учетного документа базы.

Добавим в подключаемый модуль расширения логики следующий код обработчика события ПослеЗаполнения_EdiMessageXDTO:


Сообщение = Параметры.Сообщение;
Если Сообщение.ТипСообщения = "INVOIC" Тогда
    Если Сообщение.Свойство("Контракт") Тогда
        Если НЕ ЗначениеЗаполнено(Сообщение.Контракт.Номер) Тогда
            Если Сообщение.Свойство("Контракт1С") Тогда
                Если ЗначениеЗаполнено(Сообщение.Контракт1С) Тогда
                    // Удаляем лишние спецсимволы из номера для корректной XSD-валидации
                    Сообщение.Контракт.Номер = СтрЗаменить(Сообщение.Контракт1С.Номер, "№", "");
                    Сообщение.Контракт.Дата = Сообщение.Контракт1С.Дата;
                    
                    // Заполняем XDTO-узел contractIdentificator для передачи на сервер EDI
                    xmlЗаполнитьDocumentIdentificator(Параметры.EdiMessage.invoice, "contractIdentificator", Сообщение, "Контракт");
                КонецЕсли;
            КонецЕсли;
        КонецЕсли;
    КонецЕсли;
КонецЕсли;

Технические требования и нюансы заполнения

При программном заполнении реквизитов договора обратим внимание на важные детали:

Очистка спецсимволов: В номере договора не должно содержаться знака №. Схемы валидации XML-пакетов и форматы ФНС чувствительны к спецсимволам, поэтому использование функции СтрЗаменить() обязательно.
Формат даты: Дата договора должна передаваться без времени в стандартном типе Дата, чтобы процедура сериализации xmlЗаполнитьDocumentIdentificator корректно сформировала атрибут в формате ГГГГ-ММ-ДД.
Именование узлов: В актуальных версиях модуля Контур.EDI структура объекта называется Контракт (в ранних релизах могла именоваться как КонтрактEDI).

Альтернативные способы решения

Если внесение доработок в код нежелательно, рассмотрим альтернативные варианты настройки интеграции:

Обращение к торговой сети: Через службу поддержки или категорийного менеджера ритейлера можно запросить обязательную передачу номера и даты действующего договора в теле входящих заказов ORDERS.
Сопоставление в настройках модуля: В интерфейсе сопоставления объектов модуля Контур.EDI можно проверить настройки партнеров и закрепить статический договор за конкретным GLN торговой сети или филиала.
Прямая отправка через Диадок: Если регламент взаимодействия с сетью допускает работу без сквозной EDI-цепочки (без предварительных сообщений ORDERS/DESADV), можно формировать и отправлять УПД напрямую через модуль Диадок, где основание берется непосредственно из реквизитов документа информационной базы 1С.