— Ольга Гелиевна, расскажите поподробнее о принципе формирования текста договора в формате XML.

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

Итак, изначально стояла задача создать машинообрабатываемый текст. Организации хотели в автоматизированном режиме по тексту пришедшего договора формировать карточку договора, куда бы вносились все его существенные показатели, причем не только реквизиты документа и сторон, но и наименование и стоимость ценностей, сроки поставок, оплат, основания и расчетные параметры санкций... Стандартный подход к формированию XML-файла не мог обеспечить выполнение такой задачи, поскольку потребности организаций крайне индивидуальны и разнообразны.

Тогда было предложено фрагментировать нужный контекст, а логическую последовательность фрагментов обеспечить путем присвоения каждому порядкового номера. А среди этих фрагментов, большая часть которых является свободным полем для произвольного текста, дать возможность вставлять/использовать унифицированный фрагмент, описание которого и размерность определяются в перечне типовых фрагментов. Такой перечень размещен на сайте ФНС (https://www.nalog.gov.ru/rn77/ - Деятельность - Иные функции ФНС России - Электронный документооборот - Электронный документооборот между хозяйствующими субъектами – Перечень форматов, утвержденных ФНС России).

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

— Звучит сложно. Можете привести какой-то пример?

— Посмотрим на примере шапки поступающего в организацию договора с наименованием и номером. Это первое, что понадобится для того, чтобы в своей системе сформировать на него «карточку». Например:

«ДОГОВОР № 313-04 / поставки готовой продукции (молока)»

Для начала надо понять, что «машина» должна взять из этого текста в карточку: вид документа и номер. Для этого эти показатели надо выделить в отдельные фрагменты. Тогда получится четыре фрагмента:

(ДОГОВОР) ( №) (313-04) (/_поставки готовой продукции (молока))

Второй и четвертый фрагменты («№» и «_/_поставки готовой продукции (молочные продукты)») являются свободными полями с произвольным необрабатываемым текстом: знак номера и слова можно будет увидеть в привычной текстовой форме всего текста договора. А вот для первого фрагмента при формировании договора можно указать, что это типовой фрагмент (например, «Наименование договорного документа» с кратким наименованием «НаимДок» и текстовым форматом 255 знаков и внести туда значение «Договор»). Третий фрагмент тоже можно определить из состава типовых фрагментов (например, «Номер договорного документа» с кратким наименованием «НомДок» и текстовым форматом 1000 знаков и внести туда значение «313-04»). Получившая такой договор сторона, используя публичный Перечень типовых фрагментов, по кратким наименованиям элемента автоматически сможет определить, что речь идет о наименовании и номере документа и корректно перенесет соответствующие значения в базу данных своей АИС. И далее будет работать именно с этими показателями.

А при визуализации текста договора автоматизированная система поставит фрагменты друг за другом с первого по четвертый. Для красивого расположения текста при визуализации на экране (копии текста на бумаге) предусмотрена также возможность указания на то, что фрагмент является заголовком одного из трех уровней.

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

В таких условиях всю шапку рассмотренного договорного документа во избежание дублирования нужно делать одним большим первым произвольным фрагментом, определив его для визуализации как заголовок, например, 1-го уровня.

А методологически рассмотренный принцип фрагментирования с описанием фрагментов будет работать по всему тексту договора.

Полный текст интервью читайте в ГК, 2023, № 23, с.82.