Почему в 1С:ЭДО при формировании документа меняется наименование договора и как это исправить

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия
← На главную

При работе с сервисом 1С:ЭДО пользователи часто сталкиваются с ситуацией, когда визуальное представление договора в карточке электронного документа (УПД, УКД) или в его печатной форме не соответствует тому, что введено в справочнике «Договоры контрагентов». Типичный пример: в базе 1С договор называется № 511/2020 от 01.12.2019SS545Z, а при просмотре электронного документа мы видим SS545Z № 511/2020 от 01.12.2019. Служебные символы, которые должны быть в конце, магическим образом перемещаются в начало строки.

В этой статье мы подробно разберем, почему это происходит, проанализируем программные механизмы, отвечающие за это поведение, и выясним, как можно скорректировать данную логику под требования заказчика.

Разберем причины автоматического изменения наименования

Прежде всего, важно понимать, что 1С:ЭДО формирует XML-файл электронного документа строго по форматам, утвержденным ФНС. В этих форматах данные об основании (договоре) должны быть четко структурированы. Программа не может просто передать произвольную строку «как есть», она пытается распознать в этой строке номер и дату договора, чтобы заполнить соответствующие атрибуты в XML-структуре.

Когда система встречает в наименовании паттерны типа «№», «от» или календарные даты, включается алгоритм нормализации и парсинга. Проанализируем, что происходит, когда в строке присутствуют нестандартные символы (например, служебные коды):

  1. Программа ищет вхождения номера и даты с помощью регулярных выражений.
  2. Всё, что не удалось идентифицировать как чистый «номер» или «дату», система классифицирует как «Наименование» или «Префикс».
  3. При сборке итоговой визуальной формы (через XSLT-трансформацию) или при формировании текстового представления программа выводит сначала текстовую часть, а затем номер и дату. Именно поэтому ваш служебный код SS545Z «перепрыгивает» в начало.

Проанализируем программный код формирования оснований

Чтобы найти место, где происходит трансформация данных, нам необходимо обратиться к общим модулям конфигурации (в примере рассматривается 1С:Бухгалтерия предприятия 3.0). Основная логика подготовки данных для ЭДО сосредоточена в модулях обмена.

Рассмотрим конкретный участок кода в общем модуле ОбменСКонтрагентамиБП. Именно здесь выполняется сбор реквизитов договора из базы данных для последующей передачи в механизмы формирования электронного документа. Посмотрим на пример кода:


// Извлечение данных договора из объекта ссылки
ДанныеОснования = ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
    СсылкаНаОбъект,
    "ДоговорКонтрагента.Номер, ДоговорКонтрагента.Дата, ДоговорКонтрагента.Наименование");

// Вызов функции подготовки таблицы данных договора
Основания = ПодготовитьТаблицуДанныхДоговора(
    ДанныеОснования.ДоговорКонтрагентаНаименование,
    ДанныеОснования.ДоговорКонтрагентаНомер,
    ДанныеОснования.ДоговорКонтрагентаДата);

Функция ПодготовитьТаблицуДанныхДоговора — это «входные ворота» для алгоритмов нормализации. Внутри этой функции (или вызываемых ею методов в других модулях, таких как МенеджерОснованийЭлектронныхДокументов) происходит попытка отделения мусора от значимых реквизитов. Если служебная строка приклеена к дате без пробела, парсер может посчитать всю конструкцию нестандартным описанием документа и перестроить строку по своему усмотрению.

Как исправить поведение системы по шагам

Если вам необходимо сохранить специфический порядок символов в наименовании договора для ЭДО, рассмотрим несколько вариантов решения задачи.

Вариант 1. Использование расширения для корректировки логики

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

Алгоритм действий будет следующим:

  1. Находим процедуру, заполняющую коллекцию оснований для выгрузки в XML.
  2. С помощью метода &После или &Вместо подменяем значение текстового представления договора на исходное Наименование из справочника.
  3. Проверяем, чтобы при этом не нарушалась структура полей Номер и Дата, так как они критически важны для валидации файла в налоговой.

Вариант 2. Изменение формата хранения данных (без кода)

Иногда проблему можно решить административными методами или простым изменением формата ввода данных. Рассмотрим подробнее:

Вариант 3. Анализ XSLT-шаблона визуализации

Если в самом XML-файле данные расположены верно, а «шляпа» (перестановка) происходит только при просмотре карточки на экране, значит, причина кроется в XSLT-трансформации. Визуальные формы ЭДО в 1С генерируются с помощью специальных шаблонов. В этом случае правка кода в общем модуле ОбменСКонтрагентамиБП может не помочь, так как визуализатор сам решает, в каком порядке выводить поля Наименование, Номер и Дата.

Выясним причину, изучив настройки в справочнике Шаблоны внутренних документов (если используется Документооборот) или проверив состав поставляемых макетов визуализации в вашей конфигурации. Однако стоит помнить, что менять типовые XSLT-шаблоны — задача трудоемкая, и чаще всего проще скорректировать данные на этапе их подачи в механизм обмена.

Подводя итог, можно сказать, что проблема «прыгающих» символов в ЭДО — это следствие работы механизмов унификации данных 1С. Для её решения программисту необходимо вмешаться в процесс формирования таблицы оснований в общем модуле ОбменСКонтрагентамиБП или использовать механизмы расширений для сохранения оригинального наименования из справочника.

← На главную