Типовые требования к управлению электронными официальными документами (стр. 16 )

массовая э(7) передача э(67) из совместимого ЭХД э(28); массовая э(7) передача э(67)  из совместимой СУЭОД э(32); отдельный совместимый файл данных, содержащий ряд официальных документов э(52) одного типа (например, ежедневные счета); из совместимой системы сканирования или работы с изображениями; официальные документы э(52) из иерархии папок (файловой системы) операционной системы.

СУЭОД э(32) должна быть способной принять их и предоставить средства управления процессом захвата э(8) и поддерживать содержимое и структуру импортированных э(38) официальных документов э(52).

Во время массового импорта э(7), СУЭОД э(32) должна захватывать э(8) ту же информацию, как и при обычном процессе захвата э(8), а именно – сами официальные документы э(52) и их метаданные э(40). Она также должна классифицировать э(12) официальные документы э(52), расширяя схему классификации э(14) в случае необходимости (см. 3.1.2), и, возможно, захватывая э(8) информацию протокола аудита э(4). И наконец, массовый импорт э(7) должен позволять обработку исключений и ошибок.

В момент написания планируется развитие схемы XML для MoReq2. Ожидается, что эта схема позволит реализовать «Модель метаданных MoReq2» (см. приложение 9) и обеспечить идеальный протокол для массового импорта э(7) электронных официальных документов э(31) из СУЭОД э(32), соответствующих MoReq2.

№	Требование	Тест
Если формальная схема MoReq2 XML опубликована, СУЭОД э(32) должна быть способной производить массовый импорт э(7) официальных документов э(52) в форме, соответствующей этой схеме.	В
Смотри также требование э5.3.1, касающееся экспорта э(33) официальных документов э(52). Оба эти требования  адресуются к интероперабельности систем, соответствующих MoReq2.
СУЭОД э(32) обязательно должна обеспечивать возможность захвата э(8) транзакционных официальных документов э(52), сгенерированных другими системами, включая: поддержку предопределенных пакетных транзакционных файлов импорта э(38); задание правил редактирования для настройки процесса автоматического захвата э(8) официальных документов э(52); контроль целостности данных.	В
MoReq2 не указывает, как эта способность обеспечивается.
СУЭОД э(32) должна быть способной автоматически захватывать э(8) метаданные э(40), ассоциированные с официальными документами э(52), во время массового импорта э(7) (позволяя ручной ввод отсутствующих или неправильных метаданных э(40)).	В
Там, где СУЭОД э(32) захватывает э(8) метаданные э(40) некоторых официальных документов э(52) во время импорта э(38), она должна подтверждать, что использует те же правила, которые использовались бы для ручной обработки (захвата э(8)) официальных документов э(52). Там, где процесс подтверждения находит ошибки (такие как отсутствие обязательных метаданных э(40) или ошибки формата), она должна довести это до внимания пользователя э(68), осуществляющего импорт э(38), во всех случаях указывая вовлеченные метаданные э(40) и регистрируя ошибки и действия в протоколе аудита э(4).	Д
В идеальных случаях импортированные э(38) официальные документ(ы) э(52) будет иметь метаданные э(40), полностью соответствующие «Модели метаданных MoReq2» (см. приложение 9). Иногда метаданные э(40) могут быть несоответствующими. В таких случаях возможно несколько выходов: MoReq2 не обязывает использовать ни один из них. Возможные выходы включают: Импортирование э(38) полностью отменено; Импортирование э(38) официального документа э(52) с несоответствующими метаданными э(40) отменено; От пользователя э(68) требуется выбрать между исправлением ошибки и отменой импортирования э(38) затронутых классов э(11); Данные импортируются э(38) как временный неполный официальный документ э(52) (это похоже на требование о том, что регистрация э(8) может быть разделена между пользователями э(68), смотри э6.1.34).
СУЭОД э(32) должна быть способной импортировать э(38) официальные документы э(52) протокола аудита э(4), которые показывают историю импортированного э(38) официальных документа(ов) э(52).	Д
СУЭОД э(32) не должна импортировать э(38) официальные документы э(52) содержащие протокол аудита э(4) непосредственно в свой протокол аудита э(4), импортированные э(38) официальные документы э(52) содержащие  протокол аудита э(4) должны быть сохранены отдельно.	Д
Импортированные э(38) официальные документы э(52) содержащие протокол аудита э(4) должны поддерживаться отдельно во избежание создания механизма, который позволяет лицам, выполняющим роль администратора э(1), изменять или нарушать целостность протокола аудита э(4). MoReq2 не указывает, как это достигается; это может включать в себя сохранение импортированного э(38) протокола аудита э(4) как официального документа э(52) вместе с импортированными э(38) официальными документами э(52), или как отдельную сущность, узнаваемую как протокол аудита э(4), импортированный э(38) из другой системы.
СУЭОД э(32) обязательно должна обеспечивать возможность управления входными очередями.	Д
Можно ожидать следующие возможности: обзор очередей; приостановка любой или всех очередей; повторный запуск любой или всех очередей; удаление очереди.
СУЭОД э(32) должна предоставлять возможность лицу, выполняющему роль администратора э(1) (по выбору), настраивать СУЭОД э(32) на автоматическое закрытие э(16) классов э(11), дел э(34) или томов э(34) после их импортирования э(38).	Д
Например, при слиянии двух организаций может возникнуть необходимость закрытия э(16) отделений структуры, поэтому официальные документы э(52) более не смогут к ним добавляться.

Управление электронной почтой

Определения

Глагол, “e-mail”в английском языке означает механизм для передачи сообщений между «агентами» (в этом контексте термин «агент» имеет точное техническое значение; большая детализация не требуется для понимания MoReq2).

Стандартный протокол, используемый для отправки сообщений электронной почты, определен в Network Working Group documents RFC 2821 and RFC 2822 (см. приложение 7).  MoReq2 использует RFC 2821 / RFC 2822 в качестве рабочего определения “e-mail”.

Как существительное, “e-mail” – «электронная почта» используется обычно по отношению к документу э(26), который содержит полную информацию одной передачи электронной почты. Однако, хотя RFC 2822 определяет синтаксис для передач электронной почты, не существует стандартов, определяющих формат информации, которую следует использовать, когда передачи электронной почты захватываются э(8) в качестве документов э(26).

Другими словами, даже хотя приложения электронной почты от разных поставщиков могут свободно передавать сообщения (поскольку они соблюдают протоколы электронной почты, определенные в RFC 2821 / RFC 2822), невозможно захватить э(8) письмо электронной почты из одного приложения как документ э(26), и быть уверенным, что другое приложение электронной почты сможет его прочитать. Каждый поставщик электронной почты использует свой собственный покупной формат(ы) э(35) для захвата э(8) писем электронной почты. По этой причине точное автоматическое извлечение метаданных э(40) из сообщений не может быть гарантировано.

Применение и возможные вопросы

Электронная почта используется как для отправки документов э(26) (в форме писем и вложений) внутри и между организациями. Особенности программного обеспечения управления электронной почтой (в частности, отсутствие стандартизации для форматов э(35), как объяснялось выше), соединенные с отношением пользователей э(68) к электронной почте, могут осложнять применение функциональности управления официальными документами э(52) к электронной почте. Организации должны быть в состоянии внедрить управленческий контроль, чтобы:

захватывать э(8) все входящие и исходящие электронные письма и вложения;

и/или:

захватывать э(8) электронные письма и вложения согласно предписанным правилам;

и/или:

предоставить пользователям э(68) возможность выборочного захвата э(8) сообщений и вложений.

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

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

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

MoReq2 позволяет СУЭОД э(32)  поддерживать все три подхода. Контроль процедур и управления находятся за рамками MoReq2.

№	Требование	Тест
Когда захватывается э(8)  электронное письмо, СУЭОД э(32) должна по умолчанию захватывать э(8) его в формате э(35), который сохраняет информацию его заголовка.	Д
СУЭОД э(32) должна поддерживать захват э(8) электронной почты в интегрированном виде, с тем, чтобы захват э(8) мог производиться пользователем э(68) внутри приложения электронной почты, без необходимости переключаться в СУЭОД э(32).	Д
Тесная интеграция существенна для эффективного использования СУЭОД э(32). Например, пользователь э(68) должен быть способным «перетаскивать» из электронной почты клиента в СУЭОД э(32), выбирать команду «захват э(8)» из клиента внутри электронной почты или клиент электронной почты должен указывать, какие электронные сообщения были захвачены э(8) в СУЭОД э(32). Суть этого требования состоит в том, что пользователь э(68) не должен переключаться к приложению СУЭОД э(32) для того, чтобы захватывать э(8) сообщения электронной почты.
MoReq2 также разрешает, но не требует захват э(8) электронной почты другими, менее тесно интегрированными, способами.
Должно быть возможным на этапе конфигурации э(20) настраивать СУЭОД э(32) таким образом, чтобы она могла оперировать одним из следующих путей, когда пользователь э(68) посылает электронное письмо: она автоматически захватывает э(8) электронное письмо; она определяет, можно ли захватывать э(8) электронное письмо в соответствии с предопределенными правилами; она автоматически предлагает пользователю э(8) выбор, предлагая опцию  захвата э(8) электронного письма; она не предпринимает никаких действий (т. о. полагая, что пользователь э(68) сам инициирует процесс захвата э(8) в случае необходимости).	Д
Независимо от того, какой способ избран, допустимо, чтобы СУЭОД э(32) потребовала от пользователя э(68) классифицировать э(12) официальные документы э(52) вручную и ввести некоторые метаданные э(40) вручную.
Должно быть возможным на этапе конфигурации э(20) настраивать СУЭОД э(32) таким образом, чтобы она оперировала одним из следующих путей, когда СУЭОД э(32) пользователь э(68) получает электронное письмо: она автоматически захватывает э(8) сообщение, если оно еще не было захвачено э(8); она определяет, можно ли захватить э(8) электронное письмо в соответствии с предопределенными правилами; если электронное письмо еще не захвачено э(8), она автоматически предлагает пользователю э(68) выбор, предлагая опцию захвата э(68) электронного письма; она не предпринимает никаких действий (полагая, что пользователь э(68) сам инициирует процесс захвата э(8) в случае необходимости).	Д
Независимо от того, какой способ избран, допустимо, чтобы СУЭОД э(32) потребовала от пользователя э(68) классифицировать э(12) официальные документы э(52) вручную и ввести некоторые метаданные э(40) вручную.
СУЭОД э(32) должна поддерживать автоматизированную поддержку захвата э(8) как официальных документов э(52) исходящей и входящей электронной почты, с вложениями и без них, автоматически извлекая из нее следующие метаданные э(40): дата отправления электронного сообщения (и в некоторых случаях, время); получатель(и); кому направлены копии; заглавная строка (заголовок); отправитель; встроенная электронная э(29) подпись; поставщик службы сертификации; при наличии всех вышеперечисленных.	В
Это требование указывает на захват э(8) «отправителя» для электронных сообщений. Это не всегда сам автор, например, когда секретарь посылает сообщение от имени руководителя. Захват э(8) отправителя указан здесь как сознательный компромисс, так как невозможно с уверенностью захватить э(8) автора автоматически. Организациям следует рассмотреть необходимость ручных процедур для гарантии верности метаданных э(40) автора.
	Приложение 9 представляет руководство к интерпретации метаданных э(40) электронной почты.
Пользователи э(68) должны быть способны захватить э(8) официальный документ э(52) электронной почты в раздел э(66), дело э(34) или класс э(11), перенося его из клиента электронной почты (технически, Mail User Agent) в указанный в раздел э(66), дело э(34) или класс э(11) в СУЭОД э(32).	Д
Раздел э(66), дело э(34) или класс э(11) могут быть представлены в окне клиента электронной почты или в отдельном окне.
СУЭОД э(32) обязательно должна разрешать пользователю э(68) выбирать, как захватывать э(8) электронное письмо с вложением(ями), как: только электронное письмо без вложения(ий); электронное письмо с вложением(ями) как один официальный документ э(52), созданный из связанных компонентов э(19); вложение(я) только, любое или каждое как индивидуальный официальный документ э(52).	Д
Это относится к отправляемым и полученным сообщениям.
В результате последней из этих трех опций вложение(я) захватываются э(8) вне контекста электронного письма, с которым они были переданы.
Там где электронное сообщение и его вложение(я) захвачены э(8) в одно и то же время, но как разные официальные документы э(52), полученные в результате официальные документы э(52) должны быть связанными автоматически с помощью СУЭОД э(32).	Д
СУЭОД э(32) должна давать возможность пользователю э(68) прослеживать перекрестные ссылки между официальными документами э(52) с тем, чтобы найти каждый вложенный официальный документ э(52) из официального документа э(52) электронной почты и наоборот (официальный документ э(52) электронной почты из каждого официального документа э(52) вложения).
Когда вложение захватывается э(8) как отдельный официальный документ э(5), СУЭОД э(32) обязательно должна требовать, чтобы соответствующие значения метаданных э(40) официального документа э(52) были захвачены э(8) и/или введены.	Д
Во время захвата э(8) электронного сообщения, СУЭОД э(32) должна по умолчанию заполнять метаданные э(40) заголовка сообщения в графе «тема».	Д
Приложение 9 предлагает руководство по интерпретации метаданных э(40) электронной почты.
СУЭОД э(32) в обязательном порядке должна разрешать пользователю э(68), который захватывает э(8) электронное сообщение, исправлять заголовок официального документа э(52).	Д
Это делается с намерением разрешить пользователям э(68) исправлять несоответствующие или пояснять неточные заголовки электронных сообщений или делать заголовки, соответствующими смыслу.
Заголовок электронного письма отличается от строки «тема» электронного письма; последняя останется частью электронного сообщения независимо от его заголовка.
Если пользователь э(68) захватывает э(8) отчет-уведомление о статусе доставки (там, где они поддерживаются) электронного сообщения, которое было захвачено э(8) как официальный документ э(52), СУЭОД э(32) должна быть способной связать их  ссылками автоматически.	Д
Примерами уведомлений статуса доставки являются отчеты о недоставке и подтверждения доставки. Ссылка позволит пользователю э(68) перемещаться внутри официальных документов э(52) в поисках каждого уведомления в официальном документе э(52) электронного письма и официальном документе э(52) электронного письма  в любом из уведомлений.
СУЭОД э(32) должна быть способной автоматически захватывать э(8) метаданные э(8), принадлежащие к электронным письмам и их вложениям, как очерчено в «Модели метаданных MoReq2» (приложение 9).	Д
СУЭОД э(32) обязательно должна разрешать вводить вручную метаданные э(40) «дата отправления» и «дата получения».	Д
Это делается с целью разрешения ситуаций, в которых даты, содержащиеся в электронном сообщении, не подходят к бизнес - установкам (смотри введение к этому разделу, поясняющее, как это может произойти). Выбор конфигурации с целью запрещения этой функции будет допустимым.
Пользователь э(68) обязательно должен быть способным захватывать э(8) в СУЭОД э(32) одним действием несколько отобранных вручную электронных писем, как: один официальный документ э(52); или как набор официальных документов э(52), по одному на каждое электронное сообщение; по выбору пользователя э(68).	Д
СУЭОД э(32) должна быть способной определять автоматически и захватывать э(8) все электронные письма, относящиеся к электронному письму, указанному пользователем э(68), одним действием, регистрируя их как: один официальный документ э(52); или как набор официальных документов э(52), по одному на каждое электронное письмо; по выбору пользователя э(68).	Д
RFC 2822 Раздел 3.6.4. «Поля идентификации» описывает, как опциональные SMTP верхнего колонтитула «Ссылки:» и «В ответ на:» могут быть использованы в соединении с полем «Идентификатор сообщения:» для указания родственных сообщений электронной почты, они иногда называются «нить обсуждения».
СУЭОД э(32) обязательно должна разрешать пользователю э(68), который захватывает э(8) электронное письмо в собственном формате э(35), сохранять его во множественных, включая открытый, форматах э(35).	Д
Может быть полезным для СУЭОД э(32) усилить правила сохранения электронных писем, основанные на порядке хранения, отбора и передачи э(61). Дела э(34), содержащие электронные сообщения, с коротким сроком хранения могут сохраняться в собственном формате э(35), тогда как папки с содержимым более длительного хранения могут быть сохранены в открытом формате э(35).
Когда адресные поля, захваченные э(8) из шапки электронного сообщения, передаются в метаданные э(40) официального документа э(52) электронной почты/text/category/adresat/" rel="bookmark">адресата (если оно присутствует) для любого почтового электронного адреса, например, “Джон Смит“, а не просто “*****@***int“.	Д

Типы официальных документов

Раздел «Типы документов» описывает характеристики официальных документов э(52), которые не определены (и не могут быть определены) в схеме классификации э(14). Это могут быть, в частности: