При работе с сервисом 1С:ЭДО пользователи часто сталкиваются с ситуацией, когда визуальное представление договора в карточке электронного документа (УПД, УКД) или в его печатной форме не соответствует тому, что введено в справочнике «Договоры контрагентов». Типичный пример: в базе 1С договор называется № 511/2020 от 01.12.2019SS545Z, а при просмотре электронного документа мы видим SS545Z № 511/2020 от 01.12.2019. Служебные символы, которые должны быть в конце, магическим образом перемещаются в начало строки.
В этой статье мы подробно разберем, почему это происходит, проанализируем программные механизмы, отвечающие за это поведение, и выясним, как можно скорректировать данную логику под требования заказчика.
Прежде всего, важно понимать, что 1С:ЭДО формирует XML-файл электронного документа строго по форматам, утвержденным ФНС. В этих форматах данные об основании (договоре) должны быть четко структурированы. Программа не может просто передать произвольную строку «как есть», она пытается распознать в этой строке номер и дату договора, чтобы заполнить соответствующие атрибуты в XML-структуре.
Когда система встречает в наименовании паттерны типа «№», «от» или календарные даты, включается алгоритм нормализации и парсинга. Проанализируем, что происходит, когда в строке присутствуют нестандартные символы (например, служебные коды):
SS545Z «перепрыгивает» в начало.Чтобы найти место, где происходит трансформация данных, нам необходимо обратиться к общим модулям конфигурации (в примере рассматривается 1С:Бухгалтерия предприятия 3.0). Основная логика подготовки данных для ЭДО сосредоточена в модулях обмена.
Рассмотрим конкретный участок кода в общем модуле ОбменСКонтрагентамиБП. Именно здесь выполняется сбор реквизитов договора из базы данных для последующей передачи в механизмы формирования электронного документа. Посмотрим на пример кода:
// Извлечение данных договора из объекта ссылки
ДанныеОснования = ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
СсылкаНаОбъект,
"ДоговорКонтрагента.Номер, ДоговорКонтрагента.Дата, ДоговорКонтрагента.Наименование");
// Вызов функции подготовки таблицы данных договора
Основания = ПодготовитьТаблицуДанныхДоговора(
ДанныеОснования.ДоговорКонтрагентаНаименование,
ДанныеОснования.ДоговорКонтрагентаНомер,
ДанныеОснования.ДоговорКонтрагентаДата);
Функция ПодготовитьТаблицуДанныхДоговора — это «входные ворота» для алгоритмов нормализации. Внутри этой функции (или вызываемых ею методов в других модулях, таких как МенеджерОснованийЭлектронныхДокументов) происходит попытка отделения мусора от значимых реквизитов. Если служебная строка приклеена к дате без пробела, парсер может посчитать всю конструкцию нестандартным описанием документа и перестроить строку по своему усмотрению.
Если вам необходимо сохранить специфический порядок символов в наименовании договора для ЭДО, рассмотрим несколько вариантов решения задачи.
Самый правильный технический путь — создание расширения. Нам нужно перехватить выполнение функции, которая собирает итоговую строку основания. Рекомендуется обратить внимание на модуль МенеджерОснованийЭлектронныхДокументов или методы в ЭлектронныеДокументыСлужебный.
Алгоритм действий будет следующим:
&После или &Вместо подменяем значение текстового представления договора на исходное Наименование из справочника.Номер и Дата, так как они критически важны для валидации файла в налоговой.Иногда проблему можно решить административными методами или простым изменением формата ввода данных. Рассмотрим подробнее:
...01.12.2019 SS545Z). Часто парсер 1С корректно распознает дату, если после неё идет разделитель, и может оставить хвост сообщения на месте.Если в самом XML-файле данные расположены верно, а «шляпа» (перестановка) происходит только при просмотре карточки на экране, значит, причина кроется в XSLT-трансформации. Визуальные формы ЭДО в 1С генерируются с помощью специальных шаблонов. В этом случае правка кода в общем модуле ОбменСКонтрагентамиБП может не помочь, так как визуализатор сам решает, в каком порядке выводить поля Наименование, Номер и Дата.
Выясним причину, изучив настройки в справочнике Шаблоны внутренних документов (если используется Документооборот) или проверив состав поставляемых макетов визуализации в вашей конфигурации. Однако стоит помнить, что менять типовые XSLT-шаблоны — задача трудоемкая, и чаще всего проще скорректировать данные на этапе их подачи в механизм обмена.
Подводя итог, можно сказать, что проблема «прыгающих» символов в ЭДО — это следствие работы механизмов унификации данных 1С. Для её решения программисту необходимо вмешаться в процесс формирования таблицы оснований в общем модуле ОбменСКонтрагентамиБП или использовать механизмы расширений для сохранения оригинального наименования из справочника.