Статья из журнала «ГЛАВНАЯ КНИГА» актуальна на 20 ноября 2023 г.
Содержание журнала № 23 за 2023 г.Переход в цифру — наше будущее?
ЛАПИНА Ольга Гелиевна
Советник государственной гражданской службы РФ 2 класса, к. э. н., диплом DipIFR, член Научно-экспертного совета Союза «ПНК»
— Ольга Гелиевна, расскажите поподробнее о принципе формирования текста договора в формате XML.
— С удовольствием. Начну с того, что он концептуально отличается от общего порядка работы со всеми утвержденными ранее и утверждаемыми в настоящее время форматами документов (УПД, УКД, акта о расхождениях при приемке, машиночитаемой доверенности, деклараций и пр.).
Итак, изначально стояла задача создать машинообрабатываемый текст. Организации хотели в автоматизированном режиме по тексту пришедшего договора формировать карточку договора, куда бы вносились все его существенные показатели, причем не только реквизиты документа и сторон, но и наименование и стоимость ценностей, сроки поставок, оплат, основания и расчетные параметры санкций... Стандартный подход к формированию XML-файла не мог обеспечить выполнение такой задачи, поскольку потребности организаций крайне индивидуальны и разнообразны.
Тогда было предложено фрагментировать нужный контекст, а логическую последовательность фрагментов обеспечить путем присвоения каждому порядкового номера. А среди этих фрагментов, большая часть которых является свободным полем для произвольного текста, дать возможность вставлять/использовать унифицированный фрагмент, описание которого и размерность определяются в перечне типовых фрагментов. Такой перечень размещен на сайте ФНС.
Вот эти типовые фрагменты за счет их унификации и публичности и сможет распознавать и считывать настроенное на такое считывание внутрисистемное программное обеспечение. Соответственно, появляется возможность без участия человека помещать эти фрагменты в поля «карточки» договора, а потом использовать их для автоматического контроля исполнения его параметров.
Постепенный переход на электронный документооборот, который у нас и происходит, в том числе в результате расширения перечня маркируемых и прослеживаемых товаров, мне представляется наиболее гармоничным.
— Звучит сложно. Можете привести какой-то пример?
— Посмотрим на примере шапки поступающего в организацию договора с наименованием и номером. Это первое, что понадобится для того, чтобы в своей системе сформировать на него «карточку». Например:
«ДОГОВОР № 313-04 / поставки готовой продукции (молока)»
Для начала надо понять, что «машина» должна взять из этого текста в карточку: вид документа и номер. Для этого эти показатели надо выделить в отдельные фрагменты. Тогда получится четыре фрагмента:
ДОГОВОРФрагмент 1 №Фрагмент 2 313-04Фрагмент 3 /_поставки готовой продукции (молока)Фрагмент 4
Второй и четвертый фрагменты («№» и «_/_поставки готовой продукции (молочные продукты)») являются свободными полями с произвольным необрабатываемым текстом: знак номера и слова можно будет увидеть в привычной текстовой форме всего текста договора. А вот для первого фрагмента при формировании договора можно указать, что это типовой фрагмент (например, «Наименование договорного документа» с кратким наименованием «НаимДок» и текстовым форматом 255 знаков и внести туда значение «Договор»). Третий фрагмент тоже можно определить из состава типовых фрагментов (например, «Номер договорного документа» с кратким наименованием «НомДок» и текстовым форматом 1000 знаков и внести туда значение «313-04»). Получившая такой договор сторона, используя публичный Перечень типовых фрагментов, по кратким наименованиям элемента автоматически сможет определить, что речь идет о наименовании и номере документа и корректно перенесет соответствующие значения в базу данных своей АИС. И далее будет работать именно с этими показателями.
А при визуализации текста договора автоматизированная система поставит фрагменты друг за другом с первого по четвертый. Для красивого расположения текста при визуализации на экране (копии текста на бумаге) предусмотрена также возможность указания на то, что фрагмент является заголовком одного из трех уровней.
Оговорюсь, что я сейчас показала именно принцип формирования текста договора. Он действующий. А вот типовых фрагментов с наименованием и номером договорного документа вы в Перечне сейчас уже не найдете. Они по решению рабочей группы, работавшей над форматом, пока исключены из него, чтобы не путать пользователей. Почему? Признано целесообразным их обязательное указание непосредственно в отдельных полях формата как признаков, определяющих информацию (наряду с датой документа и ИНН сторон). То есть это отдельные элементы формата, заполнение которых обязательно. Ведь без них информация вообще не может быть признана документомпп. 11, 11.1 ст. 2 Закона от 27.07.2006 № 149-ФЗ.
В таких условиях всю шапку рассмотренного договорного документа во избежание дублирования нужно делать одним большим первым произвольным фрагментом, определив его для визуализации как заголовок, например, 1-го уровня.
А методологически рассмотренный принцип фрагментирования с описанием фрагментов будет работать по всему тексту договора.
Договорной документ в формате XML напоминает пазл. Ведь вся информация из документа представлена в виде фрагментов, каждому из которых отведено свое конкретное место
— Как же тогда быть, если сторонам нужен для автоматизированной обработки какой-то показатель, характерный именно для их договоренности?
— Сейчас в Перечне чуть более 130 типовых фрагментов. Кстати, к Перечню есть пояснения порядка его использования. Перечень структурирован и за счет структуры кода типовых фрагментов приспособлен для неограниченного расширения. И понятно, что такое расширение будет востребовано.
В частности, участники группы внедрения уже говорят о недостаточности наименований фрагментов для фиксации вводимых в текст договоренности дат, от которых исчисляются даты последующих событий. Они видят преимущество формата в возможности автоматизировать работу с отдельными бухгалтерскими данными, а также в возможности при применении данного формата максимально снизить трудоемкость, сделав более четкими управленческие процессы обеспечения своевременных отгрузок и/или оплат. Например, если известна дата поступившей предоплаты (а система может взять ее из платежки) и «автоматически разобрано» такое условие договора, как, например «...отгрузка в течение трех дней после получения предоплаты», то заранее можно будет автоматом послать на склад готовый проект отгрузочного документа (УПД, например).
Сегодня в Перечне по группе 34ХХ некоторые даты оплат уже зафиксированы. Но типовых фрагментов для определения такой взаимосвязи событий, как «дата предоплаты — дата отгрузки», в Перечне нет. Ничего, введем...
А пока участники группы отмечают, что выведение Перечня типовых фрагментов из самого формата дает возможность иметь и расширять перечень автоматизированно обрабатываемых реквизитов без изменения нормативного акта, устанавливающего формат (достаточно обратиться в ФНС с обоснованием расширения перечня типовых фрагментов). Но еще интереснее, что, не дожидаясь факта такого расширения, организация может самостоятельно по договоренности с партнером определить полное и краткое наименование нужного для этого договора фрагмента электронного договора, который они одинаково прочтут и отправят его значение в машинную обработку в своих системах.
— А что это за группа, о которой вы говорите?
— Учитывая специфику и возможности создаваемого на новых принципах формата XML-договора, ФНС создала и возглавила группу внедрения этого формата. Важно, что это именно группа организаций, которые реально начали делать программное обеспечение для работы с этим форматом: его создания, приемки, визуализации, а также «разбора» информации файлов обмена с последующим использованием данных в автоматизированном режиме.
Интересно, что моделями, с которыми работают участники группы внедрения, выбраны совершенно разные виды договоров: кроме очевидного договора купли-продажи, это договоры и на оказание услуг, и экспедиторский договор, и договор поручительства, и даже договор на строительно-монтажные работы. Думаю, первые рабочие оттестированные программы для использования этого формата скоро появятся, но не раньше декабря этого года.
Но главное уже прослеживается: ведущим организациям удалось разработать среду, в которую можно «залить» любой текст договоренности и назначить любые типовые фрагменты. Это принципиально важно, поскольку подтверждается, что для создания каждого отдельного вида договора не надо будет разрабатывать специальное программное обеспечение.
Это важно, иначе нужно было бы констатировать, что сфера применения утвержденного ФНС XML-формата договора достаточно узка и сможет обслуживать только конкретные интересы крупных организаций. К радости, это не так. И можно думать о масштабировании принципов, заложенных и используемых при разработке XML-формата договора.
— А есть какие-то конкретные планы такого масштабирования?
— Есть задумки. И они достаточно глобальны. Группа создавалась в большей мере с прицелом посмотреть возможность создания любых текстовых документов на принципах этого формата. Если обобщенно — рассмотреть предпосылку перестать разрабатывать и утверждать форматы истребуемых налоговыми органами документов, дав возможность организациям все документы создавать в XML-формате по подобию с форматом договорного документа.
При этом изначально и однозначно речь не идет о тех привычных для нас электронных документах, форматы которых уже были установлены.
Группой внедрения изучается и прорабатывается подход, предусматривающий типизацию видов документа не по названию формы (традиционному или собственному), а по юридико-экономической сути операции, которую он оформляет. Из этой сути должны быть понятны и обязательные реквизиты, которые должны присутствовать в документе.
Например, не акт сверки, а документ о признании или непризнании хозяйствующими субъектами требований и обязательств, возникших у них по совершенным на дату формирования документа и задокументированным взаимным операциям. Сейчас я просто навскидку показываю принцип. И смотрите: из названия уже понятно, что должны быть названы стороны, определена дата сверки, перечислены операции, определены по каждой сумма требования или обязательства и итоговые суммы, а также волеизъявление каждой стороны о согласии/несогласии с ними.
Это общий подход. Смущает длинное название документа? Ну так в Справочнике его можно будет сократить до привычного... Но если истребовать документ именно по такому длинному определению, то организация должна будет представить свой аналогичный по назначению документ вне зависимости от его названия. Вот и получаем некую типизацию с возможностью не установить, а определить для документа логичный, вытекающий из его названия, набор необходимых показателей.
Для этого очень важно, что XML — это формат, легко встраиваемый в любые архитектуры, как российские, так и иностранные.
— На сайте ФНС России есть сервис визуализации электронных документов. Производится ли через этот сервис конвертация электронного договорного документа, созданного в XML-формате, в привычную форму, которую можно скачать в формате PDF?
— Действительно, ФНС предоставляет налогоплательщикам сервис по визуализации файла обмена любого документа из утвержденных форматов. И XML-договор не будет исключением. В обозримом будущем практически любая организация сможет работать с такими электронными договорами, даже если ей не нужно «выбирать» из текста унифицированные фрагменты для автоматизации ведения у себя карточки договора. Пользоваться будет достаточно просто: получили электронный договор, загрузили его на сайт ФНС, визуализировали, просмотрели... Если замечаний нет и договор подписан первой стороной, то подписали его со своей стороны. В дальнейшем при необходимости можно будет просто просмотреть документ, скачать скан или распечатать бумажную копию.
Кроме того, ФНС России имеет планы распространить применяемое на сайте ПО визуализации любым пользователям, что позволит бизнесу быстро настроить у себя визуализацию «как в ФНС».
Как в свое время отметила налоговая служба, формат XML больше подойдет организациям, обладающим высоким уровнем цифровизации
— Как мы выяснили, XML-формат наиболее удобен для автоматизированных информационных систем. Не планирует ли в связи с этим ФНС сделать такой формат обязательным? И что тогда делать с электронными договорами, созданными в других различных форматах, предложенных, например, разными операторами ЭДО?
— В предыдущем номере вашего журнала я уже упоминала, что начиная с июня этого года можно передать налоговым органам договор, созданный в любом из трех форматов. Не вижу достаточных оснований в обозримом горизонте для сокращения форматов до одного. Иначе зачем было их все вводить?
Просто у форматов, как мы увидели, разные возможности, и организациям следует ориентироваться в первую очередь на свои потребности. Если пока потребностей в полностью автоматизированной работе с карточкой договора нет — можно спокойно продолжать пользоваться тем, что предлагают операторы. И даже если это не три упоминаемые в разговоре формата, передать документ в налоговый орган можно всегда: распечатать и заверить.
— Сейчас много говорят об активизации цифровизации, а это подразумевает отказ и от договоров на бумаге, и от их сканов. Нам этого ждать?
— Я даже не знаю, как себе это представить... Свобода договора закреплена Гражданским кодексом, а в ст. 160 ГК РФ предусмотрено совершение сделки с помощью электронных средств, но нет ни слова о запрете письменного оформления сделки на бумаге. Как в таких условиях отказать в признании наличия документа, составленного на бумаге? А если он есть, с ним должны работать любые государственные органы, в том числе и налоговые, и суды.
Понятно, что жесткое ограничение государством хождения бумажных документов резко бы подтолкнуло электронный документооборот. И такие пожелания со стороны активно переходящих «в электрон» организаций периодически слышатся: ведь тогда им не придется уговаривать контрагентов сделать то же самое.
Однако работа с цифрой на уровне страны может дать «прорывной» эффект только при получении реального максимального эффекта от процесса в каждой организации. И я не думаю, что есть острая необходимость принуждать организации к цифровизации договорной работы, если они еще не готовы к этому. А причинами неготовности могут быть как отсутствие на конкретном этапе развития бизнеса потребностей в расширении автоматизации, так и отсутствие возможностей.
Поэтому постепенный переход на электронный документооборот, который у нас и происходит, в том числе в результате постепенного расширения перечня маркируемых и прослеживаемых (в широком смысле этого слова) товаров, мне представляется наиболее гармоничным. Так же постепенно устраняются противоречия и неясности законодательства в сфере ЭДО. И здесь еще есть где потрудиться. А потом уж вводить полную обязаловку.
При этом, по моим прикидкам, автоматизированная обработка договора, как вида документа, востребована сейчас и будет востребована госорганами меньше всего. Договор с точки зрения контроля — это просто намерения сторон. Его условия надо читать и учитывать последствия для налогообложения, но для этого и сканы пригодны... А вот проведение мониторинга движения значимых товаров основывается на других документах, в частности УПД, УКД, акте расхождений. И именно они являются максимально структурированными, пригодными для обработки без участия человека. И интерес государства к их обороту в электронном виде будет расти в первую очередь.