В статье рассматривается вопрос выбора оптимального формата представления электронных документов для организации ЮЗЭДО на базе произвольной ERP-системы. Сформулированы критерии отбора файловых форматов для использования в юридически значимом документообороте, проанализированы наиболее распространённые из них, сделаны выводы о наиболее приемлемом на сегодняшний день формате, исходя из заявленных критериев.

С момента принятия Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» наступила относительная стабилизация законодательной базы в этой области, что позволило сформировать минимально необходимый набор подзаконных актов, развить инфраструктуру аккредитованных удостоверяющих центров, наработать практику использования электронной подписи государственными исполнительными и судебными органами. На этом фоне всё шире распространяется практика перехода коммерческих организаций от традиционного «бумажного» к юридически значимому электронному документообороту (ЮЗЭДО).

В первую очередь подобные проекты организуют крупные территориально распределённые компании. Уход от обмена бумажными копиями документов, скреплённых подписями и печатями, и его замена работой с документами электронными в единой информационной системе позволяют сократить затраты времени на их согласование, практически исключить расходы на почтовую или курьерскую доставку и сократить риск утечки конфиденциальной информации.

Положительным побочным эффектом внедрения ЮЗЭДО является возможность использования уже развёрнутой инфраструктуры открытых ключей для перехода к строгой (беспарольной) аутентификации в корпоративных информационных системах. Кроме повышения надёжности защиты периметра это обеспечивает также эффект Single Sign-On для конечных пользователей, которые заходят в разные информационные системы при помощи одного и того же «токена».

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

Этот вопрос тем более актуален, чем больше степень интеграции ЮЗЭДО в бизнес-процессы компании. Максимальный вес он приобретает при построении юридически значимого электронного документооборота на базе средств комплексной автоматизации деятельности предприятия — ERP-систем.

В транзакционных системах, которыми являются все ERP-системы, в отличие от СЭД, обрабатываются не документы как таковые, а наборы данных, связанные между собой лишь логически. В «документ» подобный набор превращается лишь на экране, когда пользователь вызывает соответствующий отчёт или программу. И пользователю трудно это принять несмотря даже на то, что подписание набора данных электронной подписью полностью соответствует 63-ФЗ.

Для «материализации» электронного документа необходимо каждый бизнес-объект ERP-системы, затрагиваемый ЮЗЭДО, дополнить отторгаемым документом, в котором транзакционные данные собраны воедино и который является «электронным документом» в обыденном понимании. (Альтернативный вариант — административными методами заставить пользователей считать набор транзакционных данных единым документом — является более рискованным с точки зрения проектного менеджмента, а также неприменим к контрольным органам, работники которых точно так же предпочитают осязаемые электронные документы набору записей в базе данных.)

В этом контексте возникает вопрос выбора основного формата файлов, в котором будут представлены все электронные документы, охватываемые ЮЗЭДО. Среди ключевых требований к такому формату следует, по нашему мнению, выделить следующие.

  1. Поддержка формата корпоративным ПО на основных программно-аппаратных платформах, которые используются самой компанией, её контрагентами, а также госорганами.
  2. Поддержка формата распространёнными средствами печати и сканирования.
  3. Однозначная визуализация содержимого и наличие доступных средств визуализации файлов данного формата на основных программно-аппаратных платформах.
  4. Техническая сложность внесения несанкционированных изменений в документ данного формата (в том числе со стороны вредоносного ПО).
  5. Поддержка форматом электронной подписи, в том числе многократной.
  6. Поддержка включения в файл «контейнеров» с графикой и данными иных форматов.
  7. Возможность непосредственного обмена файлами данного формата с внешними системами и (или) экспорта в них содержимого файла.
  8. Построение формата файла на базе открытых стандартов.
  9. Соответствие формата требованиям к архивному хранению электронных документов, в том числе его независимость от версий программного обеспечения, предназначенного для работы с ним.

В качестве потенциально пригодных можно рассматривать форматы DOCX, ODF, XML, PDF и XPS (см. таблицу).

Из таблицы видно, что фаворитами являются форматы PDF и XPS, которые практически равны по заложенным в них возможностям. Правда, формат XPS, как более «молодой» (а также в силу особенностей политики разработавшей его корпорации), менее распространён и слабо освоен на программно-аппаратных платформах, отличных от Wintel (т. е. Windows + Intel).

На третьем месте — «чистый» XML. Являясь де-факто стандартным форматом обмена данными между информационными системами, для документооборота он в принципе тоже применим, но с рядом оговорок в контексте автоматизации документооборота. Во-первых, XML, строго говоря, — это не формат файлов, а язык представления их содержимого, и конкретные форматы файлов, основанные на XML, могут существенно друг от друга отличаться[1]. Кроме того, средства визуализации XML (не исходного кода, а форматированного документа) встречаются относительно редко, а популярные средства печати и сканирования, насколько нам известно, вообще не поддерживают этот формат. Плюс к тому изменение содержимого XML-файла очень просто реализовать технически (в том числе в коде вируса или троянского коня), так как это обычный текст.

Соответственно в нынешних условиях наиболее подходящим форматом для использования в юридически значимом электронном документообороте, включая архивное хранение электронных документов, является Portable Document Format (PDF).

В то же время, с указанным форматом до последнего времени была связана немаловажная проблема — отсутствие программных средств поддержки электронной подписи в соответствии с ГОСТ Р 31.10-2001/2011[2]. В принципе, частичное её решение было найдено — на рынке доступен плагин к Abobe Acrobat, реализующий данную функцию. Но это решение во многом нивелировало преимущества формата PDF, так как оно работоспособно только на платформе «Wintel».

То есть для систем, работающих под управлением различных вариаций Linux и UNIX (в частности, IBM AIX и HP UX), а также написанных на Java, решение это, к сожалению, неприменимо. Кроме того, Abobe Acrobat (и плагин к нему) является иностранным ПО, которое нельзя использовать в государственных учреждениях и на госпредприятиях. Немаловажен и ценовой фактор: лицензии на использование Adobe Acrobat недешевы. Получается же, что их приобретение необходимо только ради одной побочной функции — электронной подписи PDF,

К счастью, эта проблема на сегодняшний день получила и другое решение. На рынке теперь доступны отечественные продукты, позволяющие просматривать, подписывать и проверять файлы в формате PDF электронной подписью, соответствующей ГОСТ Р 31.10–2001/2011, без использования программного обеспечения, разработанного иностранными компаниями.

Таким образом, в настоящее время как в контексте общих требований к использованию в электронном документообороте, так и с точки зрения требований к квалифицированной электронной подписи оптимальным выбором для построения ЮЗЭДО на базе ERP-систем является формат PDF[3].

[1] Собственно говоря, все рассмотренные форматы, кроме PDF, основаны на XML, но друг с другом не совместимы (требуется конвертация).

[2] По нашим данным с ЭП файлов XPS эта проблема окончательно не решена до сих пор.

[3] На основании проведенного анализа ФСБ России извещает, что при использовании для обеспечения юридической значимости документов ранее сертифицированных средств электронной подписи (далее — средства ЭП) в случае представления документов в форматах ODF, XML или PDF дополнительных работ по подтверждению соответствия указанных средств ЭП требованиям пп. 8, 9 «Требований к средствам электронной подписи», утвержденных приказом ФСБ России от 27 декабря 2011 г. № 796, не требуется (http://www.fsb.ru/fsb/science/single.htm%21_print%3Dtrue%26id%3D10437494%40fsbResearchart.html)