При работе с электронным документооборотом (ЭДО) через систему Диадок часто возникает необходимость привести печатные данные и структуру XML-файла в соответствие с требованиями контрагента. Типичная ситуация: стандартный модуль 1С формирует поле «Основание передачи» в формате «Договор № Номер от Дата», а клиент требует специфический формат, например, «Оферта Номер от Дата» без лишних слов. В этой статье мы разберем, как правильно внести изменения в логику формирования XML, не нарушая целостность типового модуля.
Для начала проанализируем, как данные об основании передачи (договоре) хранятся в XML-файле УПД. За это отвечает блок ОснПер. Согласно формату ФНС (приказ ММВ-7-15/820@), этот тег содержит три ключевых атрибута:
Рассмотрим ситуацию: в базе 1С договор называется «Оферта ОФ-1П». Стандартный модуль Диадок пытается быть «умным» и при выгрузке превращает это в НаимОсн="Договор", НомОсн="Оферта ОФ-1П". В итоге на стороне получателя это отображается как «Договор № Оферта ОФ-1П...», что выглядит избыточно.
Важный технический момент: попытка просто очистить атрибут НаимОсн="" приведет к ошибке валидации XML-файла, так как формат требует заполнения этого поля строкой длиной от 1 символа. Правильным решением будет перераспределение данных: НаимОсн="Оферта", НомОсн="ОФ-1П".
Прежде чем что-то менять, нужно понять, где именно в коде происходит заполнение этих переменных. В современных версиях Диадок (например, 5.47 и выше) основные модули генерации XML и печатных форм «зашиты» внутри основной обработки Diadoc1C.epf в виде макетов с двоичными данными. Чтобы попасть внутрь этих модулей отладчиком, выполним следующие действия:
C:\Diadoc_Debug\).ГенерацияXML.epf и ПечатныеФормы.epf в указанную папку.Теперь мы можем открыть эти внешние обработки в конфигураторе, поставить точки останова и увидеть процесс формирования структуры Content.
Внесение изменений напрямую в ГенерацияXML.epf — плохая практика, так как при обновлении версии Диадока все ваши правки будут стерты. Разработчики Контура предусмотрели механизм Подключаемых модулей. Это внешняя обработка, которая перехватывает управление в определенные моменты работы системы.
Выясним причину, почему ПМ лучше прямой правки: он позволяет изменять данные объекта Content непосредственно перед его конвертацией в XML, сохраняя типовой код нетронутым.
Рассмотрим пример реализации функции в подключаемом модуле для изменения основания передачи:
Функция ОбработатьСобытиеПослеЗаполненияКонтента(Параметры) Экспорт
Контент = Параметры.Контент;
ДокументСсылка = Параметры.ДокументСсылка;
// Проверяем, что это УПД (СЧФДОП)
Если Параметры.ТипКонтента = "UniversalTransferDocument" Тогда
// Работаем с коллекцией оснований (их может быть несколько)
Для Каждого Основание Из Контент.TransferInfo.TransferBases Цикл
// Анализируем текущее наименование документа
Если Основание.DocumentName = "Договор" Тогда
// Проверяем, не содержится ли уже тип документа в номере
Если Найти(Основание.DocumentNumber, "Оферта") > 0 Тогда
Основание.DocumentName = "Оферта";
// Убираем лишнее слово из номера, если нужно
Основание.DocumentNumber = СтрЗаменить(Основание.DocumentNumber, "Оферта", "");
Основание.DocumentNumber = СокрЛП(Основание.DocumentNumber);
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецЕсли;
Возврат Истина;
КонецФункции
Проанализируем ситуацию подробнее. В подключаемом модуле объект Контент (или Content) представляет собой дерево данных, которое практически 1 в 1 соответствует структуре XML. Для УПД путь к данным договора выглядит так: Content.TransferInfo.TransferBases.
Основные свойства элемента коллекции TransferBases:
DocumentName — соответствует НаимОсн.DocumentNumber — соответствует НомОсн.DocumentDate — соответствует ДатаОсн.DocumentInfo — дополнительные сведения (редко используется в стандартных схемах).Если вы хотите полностью заменить логику, вы можете обратиться к реквизитам исходного документа 1С через Параметры.ДокументСсылка. Например, если в договоре в 1С есть дополнительные свойства, их можно вытянуть прямо здесь и подставить в DocumentName.
Многие пользователи замечают, что даже после изменения XML в Личном Кабинете (ЛК) Диадока документ продолжает отображаться «по-старому». Разберем, почему это происходит. Визуализация документа в веб-интерфейсе строится на основании XSLT-шаблона. Если в XML написано НаимОсн="Оферта" и НомОсн="123", шаблон просто склеивает их в строку.
Однако, если ваш контрагент использует автоматическую загрузку в свою учетную систему, для него критически важно именно разделение по тегам. Поэтому всегда ориентируйтесь на то, как данные выглядят при нажатии кнопки «Просмотреть XML» в Диадоке, а не только на картинку предпросмотра.
Рассмотрим подробнее ошибки, которые часто допускают программисты при попытке «подправить» XML:
DocumentDate пустую строку или дату в неправильном формате. Система ожидает стандартный тип Дата.НаимОсн не может быть пустым. Если у документа нет названия, лучше написать туда «Без номера» или «Договор», иначе файл не пройдет проверку на сервере Контура.UniversalTransferDocument (УПД), не забудьте проверить, не нужно ли аналогичное изменение для Invoice (Счет-фактура) или Torg12, если вы их используете.Выясним причину успеха: использование штатного механизма подключаемых модулей позволяет гибко управлять выгрузкой, не опасаясь обновлений. Посмотрим на алгоритм действий еще раз: включили отладку — нашли нужные поля в объекте Content — создали внешнюю обработку (ПМ) — прописали логику в событии ПослеЗаполненияКонтента.
Этот метод подходит не только для изменения договора, но и для добавления кодов маркировки, специфических артикулов покупателя или дополнительных полей (информационных полей ФХЖ), которые часто требуются крупным торговым сетям.