← На главную

При формировании универсального передаточного документа (УПД) в электронном виде пользователи часто сталкиваются с громоздким заполнением строки «Основание передачи (сдачи) / получения (приемки)» (строка [8] или [10] в зависимости от статуса документа). По умолчанию программа формирует составную строку вида [Наименование договора] ([Номер договора] от [Дата договора]). Если наименование договора уже содержит слова «Договор поставки № 12 от...», итоговая запись выглядит как масло масляное: «Договор поставки № 12 от 01.01.2024 (12 от 01.01.2024)».

Разберем, где в конфигурации формируется это значение, почему возникает подобная склейка и как правильно решить задачу с учетом требований форматов ФНС.

Где в коде формируется строка основания

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

Точка входа, отвечающая за обработку реквизитов договора и разделение их на смысловые части:

ЭлектронныеДокументыВнутренний.ПредставлениеОснованияПоЧастям()

Именно эта функция принимает на вход исходные данные документа-основания (ссылку на договор или введенную пользователем строку), разбирает шаблон и возвращает структуру с наименованием, номером и датой документа. На основе этой структуры формируются как печатное отображение УПД для визуализации на экране, так и служебные теги электронного файла.

Почему возникает некорректная склейка: решение без изменения кода

Прежде чем снимать конфигурацию с поддержки и править программный код, выясним причину такого поведения системы. В справочнике ДоговорыКонтрагентов присутствуют как стандартный реквизит Наименование, так и специализированные реквизиты Номер и Дата.

Типовой алгоритм платформы рассчитан на следующую логику заполнения справочника:

1. В реквизите Наименование указывается только вид документа-основания (например, «Договор поставки», «Договор подряда» или просто «Договор»).
2. В реквизитах Номер и Дата указываются фактические номер и дата подписания соглашения.

Если пользователи заполняют поле Наименование полностью вместе с номером и датой, а затем повторно вносят эти же данные в поля Номер и Дата, функция ПредставлениеОснованияПоЧастям() считает наименование типом договора и принудительно приписывает к нему номер и дату в скобках. Если нормализовать ведение нормативно-справочной информации (НСИ) и оставить в наименовании только форму договора, строка основания в УПД примет стандартный читаемый вид: «Договор поставки № 12 от 01.01.2024» без ненужных дублей в скобках.

Внимание: требования формата ФНС и риск непрохождения валидации

Если изменить алгоритм в коде требуется обязательно, проанализируем структуру электронного документа. ЭДО состоит из двух частей: визуального макета (табличного документа для просмотра) и файла обмена в формате XML, отправляемого через оператора ЭДО.

Согласно форматам передачи первичных учетных документов в электронной форме (приказы ФНС России № 820@ и № 970@), сведения об основании передачи передаются в узле СвОснПер (или ОснПер) со следующими обязательными атрибутами:

1. НаимОсн — Наименование документа-основания (является обязательным элементом XSD-схемы).
2. НомОсн — Номер документа-основания.
3. ДатаОсн — Дата документа-основания.

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

Таким образом, корректировку визуального вывода строки основания необходимо разделять с заполнением выгрузки XML:

1. Для визуализации макета допускается объединение номера и даты в строку вывода.
2. Для формирования структуры XML атрибут наименования должен оставаться заполненным (например, словом «Договор» по умолчанию, если оно не было выделено явно).

Ограничения и рекомендации по доработке в УПП 1.3

Рассмотрим технические аспекты внедрения доработки в систему:

1. Режим совместимости и расширения: Конфигурация «1С:Управление производственным предприятием» работает в режиме совместимости платформы 8.2 на базе обычных форм. Механизм расширений (патчей) для модулей подсистемы БЭД здесь либо недоступен, либо строго ограничен, поэтому модификация кода требует включения возможности изменения в настройках поддержки.
2. Сложности при обновлениях: Общий модуль ЭлектронныеДокументыВнутренний регулярно обновляется фирмой «1С» при каждом изменении законодательства, форматов обмена и требований операторов. Любые прямые изменения типового кода в этом модуле придется отслеживать и вручную переносить при каждом обновлении конфигурации.
3. Побочные эффекты универсального метода: Метод ПредставлениеОснованияПоЧастям() является общим для всей подсистемы БЭД. Его переопределение повлияет не только на титулы УПД, но и на формирование электронных актов, накладных ТОРГ-12 и корректировочных документов. Если требуется изменить отображение исключительно для УПД, добавьте в код условие проверки типа текущего документа или вносите точечные изменения непосредственно в процедуру вывода данных в визуальный макет УПД.