(Продолжение цикла статей; предыдущую см.: часть 2)
Очередную статью цикла, посвященного проблематике создания корпоративной СЭД, мы посвятим анализу использования термина “Документ” для обозначения различных объектов в информационной системе. Это уже третья статья вступительной части нашего цикла публикаций. Пока мы не пытаемся построить какой-либо содержательной модели СЭД и сформулировать правильный тезаурус, мы занимаемся исключительно анализом различных аспектов СЭД: в первой статье мы кратко проанализировали потребности различных групп функциональных потребителей и выделили три контекста использования термина СЭД в публикациях; во второй — сделали краткий обзор готового ПО, предлагаемого на рынке в качестве основы для создания корпоративной СЭД. Теперь настал момент поговорить собственно об основном объекте автоматизации в СЭД — документе. Как мы увидим, и этот термин не имеет однозначной интерпретации. В каком же контексте мы употребляем слово “Документ” при рассмотрении систем автоматизации?
Прежде всего попробуем обратиться к официальным определениям понятия “Документ”. В силу отсутствия в России закона об электронном документе, призванного дать формальное определение документа с точки зрения его использования в информационной системе (данный закон уже много лет находится в состоянии проекта), обратимся к другим законодательным актам. Достаточно формальное определение понятия “Документ” дает Федеральный закон № 77-ФЗ “Об обязательном экземпляре документов”. Он определяет документ как материальный носитель с зафиксированной на нем в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания. При этом документ имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения.
В этом смысле большинство контекстов использования термина “Документ” в информационной системе (мы увидим это далее) не соответствует данному определению. Во-первых, как правило, довольно трудно идентифицировать материальный носитель, используемый для хранения документов, во-вторых, он, как правило, не предназначен для передачи, не всегда имеет реквизиты и часто хранит информацию в весьма специфическом виде (не в виде текста, изображения или звука; например, вполне можно себе представить документ в ИС, который состоит из набора GUID’ов и дайджеста хеш-функции этого массива данных). Но, тем не менее, мы говорим о документах в информационной системе и даже обсуждаем систему автоматизации процессов их обработки. Какие же объекты мы называем документами и что между ними общего? В данной статье мы, собственно, и попробуем перечислить данные контексты использования этого слова и сформулировать определение понятия “Документ в СЭД”.
Информация о бумажном документе в ИС
Первое, что научились делать приложения по автоматизации документооборота, — это сопровождать процесс обработки бумажного документа. В СЭД информация о бумажном документе представляет собой специализированный объект — учётную карточку (или карточку документа), которая содержит информацию, необходимую для его идентификации и поиска (набор атрибутов: номер, название, автор, дата создания и регистрации и пр.). Также в карточке может фиксироваться информация о процессе обработки бумажного документа — факты официальной регистрации документа и присвоения ему номера, его размещения в физическом хранилище, перемещения, создания копий документа, их передачи в подразделения и пр. Помимо этого уже первые системы позволяли фиксировать в учетной карточке информацию о выданных резолюциях и отметки о факте и своевременности исполнения документа, а также осуществлять контроль исполнения документов через построение агрегированных отчетов. В данном случае документ в информационной системе представлен набором записей в базе данных и его визуальным интерфейсом в специализированном программном АРМ (автоматизированное рабочее место). Основной проблемой подобного способа работы с документами является то, что адекватность учетной информации в ИС реальному положению дел (например, месту их хранения) невозможно гарантировать.
Образы документов
Следующим способом хранения документа в информационной системе является хранение его образа в виде графического файла. Данный способ хранения уже позволяет синхронизовать реальное перемещение электронной копии документа в информационной системе и изменения стадий его жизненного цикла, его учетную информацию, то есть автоматизировать его обработку. Этот способ позволяет сохранить всю информацию о документе -- в частности, можно убедиться в наличии физических подписей и печати на документе. С образом документа можно осуществлять различные операции, например, рассылать его на ознакомление, фиксировать резолюции и даже вносить правки путём нанесения на изображение документа различных графических и текстовых пометок (так называемое аннотирование). Однако образ документа не позволяет извлекать из него “машиночитаемую” информацию, например, строить индексы для полнотекстового поиска (для этого нужно получить его тестовый вариант с помощью средства распознавания текста). Также образ документа невозможно использовать в таких процессах, как согласование текста, и в коллективной разработке.
Редактируемые файлы
Следующий формат представления документа в ИС — редактируемый файл. Он содержит машиночитаемую информацию и может редактироваться в процессе его разработки. То есть может быть автоматизирован не только этап хранения и исполнения документа, но и этап его подготовки и согласования. Имеется огромное разнообразие форматов представления редактируемых документов. Можно выделить несколько наиболее типичных классов — текстовые документы, электронные таблицы, документы презентации, документы CAD и пр. Сразу можно отметить, что уже давно появилась возможность создавать синтетические документы, содержащие в одном файле компоненты различных типов информации (комбинации текстовой информации, электронных таблиц, презентационной графики и пр.).
Можно выделить два типа редактируемых файлов: плоские (не содержащие внутренней семантической структуры), например, документы в формате TXT или простые DOC-файлы, и структурированные — документы, в теле которых можно выделить отдельные элементы, имеющие определенную семантику. Можно выделить структурированные документы, где каждый информационный фрагмент имеет привязку к семантике. К этой группе можно отнести электронные таблицы и CSV-файлы (Comma Separated Values, формат, используемый для передачи табличной информации в текстовом виде), документы в формате EDI FAKT и XML, речь о которых пойдет чуть позже), а также частично структурированные документы, включающие как плоский текст, так и элементы семантической разметки (например, DocX-файлы со встроенными в шаблон элементами управления).
С точки зрения практического использования в контексте СЭД структурированные (или частично структурированные) файлы документов имеют наибольшее значение, так как данный вид документа может быть автоматизирован на всем его жизненном цикле. Давайте кратко рассмотрим технологии, используемые для хранения такого рода документов.
Структурированные документы
ИТ-индустрия довольно давно была озабочена разработкой универсального формата передачи и хранения структурированных документов. Основной задачей при создании формата хранения структурированных документов является определение универсального механизма разметки документа и выделение отдельных информационных фрагментов для правильной их интерпретации в приложении, которое обрабатывает документ. Еще до недавнего времени эта проблема решалась далеко не тривиальным способом. Давайте рассмотрим небольшой пример, документ “Счет на оплату” в информационной системе (рис. 1.).
Как мы видим, на рисунке представлен строго формализованный документ в виде электронной формы. Каким же образом его содержание может быть упаковано в файл? В простейшем случае, если мы обмениваемся с контрагентом, с которым можем согласовать формат передачи документа, то можно выбрать произвольный формат обмена — определенный шаблон Excel-документа, CSV-файл и т. п. Однако встает необходимость обмена структурированными документами с множеством различных организаций, например при выставлении электронных счетов на оплату, а для этого следует стандартизировать формат разметки документа. В качестве примера можно привести представление структурированного документа в формате EDIFACT, разработанного еще в 80-х годах прошлого века. В таблице приведена часть текста документа, фиксирующего информацию о счете в формате EDIFACT, и его расшифровка.
Безусловным достоинством такого рода оформления структурированного документа является его универсальность: переслав документ в данном формате в любую организацию, вы будете уверены, что его содержание будет однозначно интерпретировано, ведь формат кодировки реализован в соответствующем стандарте. Для каждого типа данных в документе определен формат его записи (например, дата выдачи документа будет следовать за кодовым словом DTM и будет записана в определенной кодировке). Однако данный формат имеет и существенные недостатки: во-первых, для его интерпретации необходимо знание стандарта, который, в свою очередь, ограничен лишь предопределенными типами данных и сложно расширяем. Во-вторых, для представления данного документа необходимо специальное приложение, интерпретирующее документ и совершенно не предназначенное для чтения человеком. Но сама идея формализации описания структуры электронного документа оказалась очень перспективной для автоматизации процессов обработки документов, что и привело к появлению универсального стандарта разметки структурированных документов XML (extensible Markup Language).
XML-документ
В отличие от EDIFACT данный формат легко расширяется, имеет достаточно понятную форму представления информации, содержит комментарии и может быть интерпретирован даже пользователем без применения сложного ПО. Во врезке представлена часть описания заголовка того же счета в формате XML.
Помимо простого, HTML-подобного синтаксиса языка, к факторам успеха XML можно отнести наличие формализованного программного интерфейса Document Object Model (DOM) — механизма, позволяющего любой XML-документ представить в виде программного объекта, с которым может работать (то есть читать и модифицировать его свойства) любое приложение. В любой современной программной среде имеются специальные программные компоненты для работы с XML-документами. XML достаточно хорошо приспособлен для хранения ссылок, иерархических, табличных и бинарных данных. Это позволяет использовать его для хранения самых разнообразных типов информации. Важнейшей особенностью XML является его расширяемость: в случае необходимости обмена какими-то специфическими документами вам достаточно разработать собственный диалект языка XML, создать файл с его описанием (XSD-документ) и распространить его между всеми контрагентами, с которыми вы собираетесь обмениваться информацией. Этого будет достаточно для того, чтобы ваши контрагенты могли правильно обрабатывать документы данного типа. Уже сейчас имеется огромное разнообразие диалектов XML для описания документов в самых разных предметных областях и каталоги подобного рода описаний.
Еще одной приятной особенностью XML именно в контексте СЭД является возможность легкого преобразования любого XML-документа в обычный, удобочитаемый HTML-документ с помощью XSLT-преобразования. Однако XML-документ имеет и целый ряд недостатков. Например, его большой объем, связанный с тем, что внутри тела XML-документа может храниться большое количество служебной информации, так что XML-документ может в разы превышать оптимизированные бинарные форматы упаковки. Но, несмотря на это, XML стал стандартом де-факто для передачи документов между информационными системами и реализации EDI-проектов. Тем не менее с точки зрения организации хранения документов в корпоративной СЭД XML является отнюдь не оптимальным выбором. Связано это в первую очередь с организацией оптимального атрибутивного поиска информации и реализацией групповых представлений документов в СЭД. В случае их хранения исключительно в XML-файлах эти задачи реализовались бы крайне медленно. Основным способом хранения структурированной информации в современной СЭД остается сервер баз данных, чаще всего на базе традиционной SQL-технологии.
ODF или OOXML?
В контексте хранения документов в СЭД невозможно не вспомнить про два формата XML-упаковки контента офисных документов — Open Office (Open Document Format) и Microsoft Office (Office Open XML). Первый из них разработан сообществом Open Office, а второй соответственно корпорацией Microsoft. В настоящее время оба они являются официальными стандартами ISO (OOXML ISO/IEC 29500, ODF ISO/IEC 26300) и поддерживаются наиболее распространенными пакетами обработки документов. Эти форматы разрабатывались и в настоящее время оптимизированы для работы в среде соответствующего офисного пакета. Важнейшей особенностью данного типа хранения документов является то, что для их обработки используются стандартные, наиболее распространенные программы обработки, например Microsoft Word. При этом формат позволяет объединить в одном документе как неструктурированные, даже нередактируемые фрагменты, так и элементы структурированной формы.
На рис. 2 представлен обычный текстовый документ, который содержит элементы структурированных данных, вводимых из справочников системы СЭД. Таким образом, один формат хранения объединяет в себе все вышеописанные способы представления документа в информационной системе — от плоского неструктурированного документа до жестко структурированной электронной формы.
PDF-документы
Еще одним очень распространенным и столь же универсальным форматом хранения документов является PDF (Portable Document Format), разработанный компанией Adobe, но в недавнем прошлом стандартизированный как открытый стандарт. Основным достоинством PDF является его кросс-платформенность: программы для его обработки имеются во всех программных средах. К другим его достоинствам можно отнести богатые возможности хранения и обработки документов, включая:
- многослойность, т. е. возможность независимого хранения и редактирования нескольких слоев (в частности, текстового, изображения, формы) и соответственно совмещения текста и изображения в одном документе;
- встроенную электронную цифровую подпись;
- возможность внедрения в документ мультимедиа-фрагментов;
- возможность включения в документ интерактивных элементов и поддержку стандарта XFA 3.0 (XML Forms Architecture) для описания элементов электронных форм и пр.
- Для просмотра PDF-документов можно воспользоваться бесплатной программой Adobe Reader.
Специфика документа в СЭД
Как правило, в СЭД хранятся не просто файлы в том или ином формате. Документ в СЭД представляет собой более сложную конструкцию, включающую возможность хранения истории версий документа (иногда целой иерархии документов в различных форматах), дополнительную информацию о возможности обработки документа и его блокировках. СЭД позволяет наносить и хранить ЭЦП документа, а также шифровать его вне зависимости от типа. Помимо этого с документом может быть ассоциирован набор метаданных (атрибутов документа), которые используются для атрибутивного поиска и формирования групповых представлений документа. Также часто под документом как единой сущностью в СЭД подразумевается не один, а несколько файлов документов в различных форматах (например, текст договора и спецификации, образ входящего документа и его распознанный текст и пр.). При этом к данной подшивке могут быть применены описанные выше свойства документов (например общая ЭЦП и метаданные), подшивка маршрутизируется как единая сущность.
Документ в контексте прикладных АРМ, ипостаси документа
Очень часто в приложениях документ вообще не существует как самостоятельный объект, а представляет собой набор данных, хранящихся в полях прикладной базы данных (аналогично информации о бумажном документе в СЭД). Он представляется в различной форме, в различных контекстах и этапах жизненного цикла обработки. В качестве примера можно привести первичный документ в бухгалтерской системе: при его вводе используется специальная электронная форма в прикладном АРМ, а для экспорта из системы используется его XML-представление. В отчете документ представлен в виде строки структурированной таблицы, а в других формах АРМа -- в виде текстовой строки на поле формы и ссылки. Имеются пять основных видов представления: набор данных в хранилище; электронная форма для ввода и отображение информации о документе; структурированный файл (например, XML) для передачи информации о документе в другие подсистемы и организации; строка в таблице группового представления или отчета; текстовая строка для размещения ссылки — все они представляют собой различные ипостаси представления документа в информационной системе.
Сложные документы. Документ в делопроизводстве
Наконец, при создании корпоративной СЭД очень часто нам приходится сталкиваться с довольно сложными конструкциями, моделирующими документы. В дальнейшем мы рассмотрим различные примеры сложных документов, здесь же кратко рассмотрим в качестве примера документ в подсистеме автоматизации делопроизводства.
Документ в СЭД представляет собой объединение учетной информации (набор атрибутов учетной карточки) и файлов документов. Атрибуты учетной карточки — поля ввода различного типа (текст, даты, числа), данные, выбираемые из справочников (сотрудники, контрагенты, номенклатуры дел) и различные синтетические данные (например, полученные из нумераторов, рассчитанные по бизнес-календарям и пр.). Данные могут быть организованы в коллекции и иерархические таблицы документов (набор резолюций, исполнителей, карточек поручения, история согласования, история передач). В карточке могут быть зафиксированы ссылки на другие документы (в частности, ссылки, снабженные реквизитами, например окрашенные ссылки). Ссылки на другие документы могут быть простыми (обычная гиперссылка) и “жесткими”, т. е. подразумевающими необходимость одновременного удаления документов, связанных подобными ссылками.
Примером такого рода ссылок может служить связь “документ — резолюция — контрольная карточка поручения”. В сложном случае учета все эти типы учетных объектов могут оформляться как отдельные документы, но существуют в единстве и при удалении карточки документа должны быть удалены также все резолюции и карточки поручения, связанные с ним. С карточкой документа могут быть связаны различные бинарные данные, например информация, закодированная в штрихкоде, нанесенном на документ. Помимо хранения информации в СЭД с документом связана определенная бизнес-логика — документ можно зарегистрировать, утвердить, заархивировать, распечатать, переслать и пр. При этом при выполнении с документом того или иного действия изменяются правила его обработки, доступность тех или иных действий с ним. Например, после утверждения документа запрещается его редактирование, после официальной регистрации -- его удаление до истечения срока хранения и пр. На каждой стадии жизненного цикла документа различным пользователям доступны различные действия с документом, для его обработки должны использоваться различные интерфейсы и т. д. Но несмотря на обилие вышеперечисленных данных и функций описываемая сущность остается единым документом.
Итоги
Мы проделали отнюдь не исчерпывающий анализ практической интерпретации использования термина “Документ” в информационной системе и, в частности, в СЭД, но я надеюсь, что вы убедились в многозначности данного понятия. Попробуем выделить то общее, что позволяет нам объединить все эти контексты в одно понятие. На наш взгляд, можно дать следующую общую трактовку понятия “Документ в ИС”:
- документ представляет собой запись информации в ИС по установленным правилам (для фиксации фактов деятельности людей и организации, для обмена информацией между людьми и организациями);
- документ представляет собой единую сущность с точки зрения функций “создания и удаление”, “блокировка”, “экспорт и импорт”, “маршрутизация в рамках СЭД”);
- один и тот же документ может, в зависимости от контекста обработки, иметь различное представление и различный набор доступных функций;
- хранение и представление может быть организовано самыми разнообразными способами.
Более подробно о вариантах практической реализации средств обработки документов в СЭД мы поговорим в будущих публикациях данного цикла.
Безусловно, формат статьи не дает нам возможности проанализировать все аспекты обсуждаемой темы. Более подробно это изложено в лекциях курса “Создание корпоративной СЭД”, которые доступны для просмотра.
| Текст документа | Расшифровка |
|---|---|
|
UNH+768765324+INVOIC:D:96A:UN:EAN002 BGM+380+12345+9+NA‘ DTM+3:20000105:102‘ AD+SE+++OY Valio++Helsinki++Box 789+Fi' NAD+By+++АО Северная++Saint-Petersburg+Невский 176 ++RU |
Заголовок сообщения Номер транзакции 768765324 Номер инвойса 12345 Дата выдачи 5.01.2000 Отправитель: Valio, Helsinki, Box 789 FI Получатель “АО Северная” Адр: С-Петербург Пр. Невский 176 Россия |
| LIN+1'
IMD+F+011+:::Сыр' MEA+AAI' QTY+92:200' PRI+INV:300' CUX+2:USD' | Первая позиция
Наим. Сыр Ед.изм- кг Кол-во 200 кг Цена 300 за кг Валюта — USD |
Описание заголовка документа-счета в формате XML
<?xml version="1.0"> <!DOCTYPE Invoice> <Transaction id="768765324"> <InvoiceNum>12345</InvoiceNum> <!— номер инвойса —> <DataSend>20000105</DataSend> <!— YYYYMMDD 5/01/2000 -> <Consignee> <!— Получатель —> <ConsigneeName>АО Северная столица</ConsigneeName> <Address> <!— Адрес —> <City>Санкт-Петербург</City> <Street>Невский 176</Street> <Zip>194376</Zip> <Country>RU</Country> </Address> </Consignee>
