О Регламенте межведомственного электронного документооборота Московской области (стр. 5 )

Элемент «Task/TaskNumber»

Назначение: Номер и дата поручения по документу.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Номер пункта поручения.
taskDate	1	Date	Дата поручения.

Элемент «Task/Confident»

Назначение: Категория поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Описание категории поручения (уровень доступа). = «конфиденциально» для конфиденциальных поручений; = пусто для обычных поручений.
flag	1	String	Признак конфиденциальности поручения. = 1 – поручение конфиденциальное; = 0 – поручение не конфиденциальное

Элемент «Task/Referred»

Назначение: Информация о родительских объектах поручения (документе или другом поручении).

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
idnumber	1	String	Уникальный служебный идентификационный номер родительского объекта.
retype	1	String	Тип родительского объекта. = «д» если поручение ссылается на документ; = «з» если поручение ссылается на поручение.

Элемент «Task/Referred/RegNumber»

Элемент формируется только в случае, когда поручение ссылается непосредственно на документ = «Document/RegNumber».

Элемент «Task/Referred/TaskNumber»

Элемент формируется только в случае, когда поручение ссылается другое пересылаемое поручение = «Task/TaskNumber» родительского поручения.

Элемент «Task/Author»

Назначение: Описание автора поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	1	String	Признак автора поручения. = «ю» - организация, юридическое лицо.

Элемент формируется и используется только для резолюций.

Элемент «Task/Author/Organization»

Назначение: Организация-автор поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
fullname	0	String	Полное наименование организации.
shortname	0	String	Краткое наименование организации.
ogrn	0	Num	Основной государственный регистрационный номер.
inn	0	Num	Идентификационный номер налогоплательщика.

Элемент «Task/Author/Organization/Address»

Назначение: Почтовый адрес организации-автора поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
settlement	0	String	Название населенного пункта (города, поселка и т. п.).
region	0	String	Название региона (республики, края, области, автономного округа, автономной области).
postсode	0	String	Почтовый индекс.
nontypical	0	String	Прочие элементы почтового адреса.

Элемент «Task/Author/Organization/Econtact»

Назначение: Номер (адрес) средств электронной связи с организацией-автором поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Адрес электронной почты.
type	0	String	Тип электронной связи. = «п» для электронной почты.

Элемент «Task/Addressee/Organization/OfficialPerson/Name»

Назначение: Фамилия, имя и отчество (ФИО) должностного лица-автора поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
Содержание	0	String	Единая строка, содержащая фамилию, имя и отчество должностного лица.

Элемент «Task/Author/Organization/OfficialPerson/Official»

Назначение: Описание штатной единицы (подразделение, должность), занимаемой должностным лицом–автором поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
department	0	String	Подразделение.
post	0	String	Должность.

Элемент «Task/Executor»

Назначение: Описание исполнителя поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
responsible	0	Enum	Метка ответственного исполнителя.
deadline	0	Date	Срок исполнения.

Количество элементов равно количеству исполнителей поручения.

Элемент «Task/Executor/Organization»

Назначение: Организация-исполнитель поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
fullname	0	String	Полное наименование организации.
shortname	0	String	Краткое наименование организации.
ogrn	0	Num	Основной государственный регистрационный номер.
inn	0	Num	Идентификационный номер налогоплательщика.

Элемент «Task/Executor/Organization/Address»

Назначение: Почтовый адрес организации-исполнителя поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
settlement	0	String	Название населенного пункта (города, поселка и т. п.).
region	0	String	Название региона (республики, края, области, автономного округа, автономной области).
postсode	0	String	Почтовый индекс.
nontypical	0	String	Прочие элементы почтового адреса.

Элемент «Task/Executor/Organization/Econtact»

Назначение: Номер (адрес) средств электронной связи с организацией-исполнителем поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Адрес электронной почты.
type	0	String	Тип электронной связи. = «п» для электронной почты.

Элемент «Task/Executor/Organization/OfficialPerson/Name»

Назначение: Фамилия, имя и отчество (ФИО) должностного лица-исполнителя поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
Содержание	0	String	Единая строка, содержащая фамилию, имя и отчество должностного лица.

Элемент «Task/Executor/Organization/OfficialPerson/Official»

Назначение: Описание штатной единицы (подразделение, должность), занимаемой должностным лицом–исполнителем поручения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
department	0	String	Подразделение.
post	0	String	Должность.

19.  Зона «Расширение»

Зона содержит информацию об используемом формате. Правила формирования элементов данной зоны не описаны в стандарте «Гильдия Управляющих документацией».

Состав и вложенность элементов зоны «Расширение» приведен в таблице:

Наименование и уровень вложенности элементов	Кратность	Комментарий
1	2	3
Expansion			1
	РК
	File
		EDS
	AdvFields
	Rubric
	AdvInfo
	EAddress

Элемент «Expansion»

Назначение: Описание используемого формата.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
organization	1	String	Название организации-разработчика. = «название»
exp_ver	1	String	Версия зоны «Расширение». = номер текущей версии

Элемент «Expansion/РК»

Назначение: Содержит комментарии к РК и адресату сообщения.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
rc_comment	0	String	Комментарий к РК.
аdr_comment	0	String	Комментарий к адресату сообщения
consist	0	String	Состав (количество листов документа и приложений).

Элемент «Expansion/File»

Назначение: Информация о прикрепленном и пересылаемом файле.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
location	1	String	Признак расположения передаваемого файла - внутри паспорта РК или в сообщении. = «out» - в сообщении
name	1	String	Имя прикрепленного файла в сообщении.
description	1	String	Описание пересылаемого файла. = «Паспорт РК» для «passport. xml»

Количество элементов равно количеству файлов, передаваемых в сообщении.

Элемент «Expansion/File/EDS»

Назначение: Информация об ЭЦП, сформированных для передаваемых и прикрепленных к РК файлов.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	1	String	Содержимое подписи.
Date	1	Date	Дата подписи.
id_kind	1	Enum	Номер вида подписи.
kind	1	String	Вид подписи.
certificate	1	String	Идентификатор сертификата ключа подписи.

Формируются только для элементов, описывающих прикрепленные файлы РК, не являющиеся паспортами РК. Количество элементов равно количеству ЭЦП данного файла.

Элемент «Expansion/AdvFields»

Назначение: Дополнительные реквизиты РК документа.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	1	String	Наименование дополнительного реквизита РК.
type	1	String	Тип данных дополнительного реквизита. = «текст» = «дата» = «число» = «флаг»
data	1	String	Значение дополнительного реквизита.

Количество элементов равно количеству заполненных дополнительных реквизитов РК.

Элемент «Expansion/Rubric»

Назначение: Рубрики документа.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	1	String	Название (содержание) рубрики.
code	1	Enum	Код рубрики.

Количество элементов равно количеству рубрик документа.

Элемент «Expansion/AdvInfo»

Назначение: Дополнительная информация к документу.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Дополнительная информация.

Элемент «Expansion/EAddress»

Назначение: Электронной адрес направления квитанции о регистрации документа.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
содержание	0	String	Адрес (e-mail) направления квитанции о регистрации документа в организации-получателе.

20.  Уведомление о регистрации

Сообщение вида «Уведомление» формируется ведомственной СЭД после регистрации документа, поступившего по электронной почте, и отправляется на ЦУ Единой СЭД.

10.1. Зона «Заголовок» уведомления о регистрации

Содержит информацию об отправителе уведомления. Единственным элементом зоны «Заголовок» является элемент «Header».

Элемент «Header»

Назначение: Заголовок уведомления, общее описание уведомления.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
standart	1	String	Вид формата, по которому создано данное уведомление. = «Стандарт ДОУ»
version	1	String	Версия формата, по которому создано данное уведомление. = «1.0»
time	1	DataTime	Дата и время формирования уведомления. = Текущая дата
msg_type	1	Enum	Вид сообщения. Влияет на перечень допустимых элементов (зон) в сообщении. = 0 для уведомления
msg_id	1	String	Уникальный служебный идентификационный номер уведомления.
msg_acknow	0	Enum	Необходимость посылки уведомления. 0 или 2 в зависимости от значения параметра отправки РК «Требуется уведомление о регистрации». = 0 – не присылать уведомление
from_org_id	1	String	Уникальный служебный идентификационный номер отправителя уведомления.
from_organization	1	String	Наименование организации-отправителя уведомления.
from_sys_id	1	String	Уникальный служебный идентификационный номер СЭД отправителя уведомления.
from_system	1	String	Наименование СЭД отправителя уведомления.
from_system_details	0	String	Дополнительные данные о СЭД отправителя уведомления.
to_org_id	1	String	Уникальный служебный идентификационный номер получателя уведомления. Может быть пустым.
to_organization	1	String	Наименование организации-получателя или информация о гражданине – получателе уведомления. При отправке уведомлений значения атрибутов берутся из атрибутов from_… принятого соответствующего сообщения.
to_sys_id	1	String	Уникальный служебный идентификационный номер СЭД получателя уведомления. Может быть пустым.
to_system	1	String	Наименование СЭД получателя уведомления. Может быть пустым.
to_system_details	0	String	Дополнительные данные о СЭД получателя уведомления.

10.2. Зона «Уведомление» уведомления о регистрации

Содержит информацию о регистрации РК на основе присланного сообщения.

Состав и вложенность элементов, образующих зону «Уведомление» представлен в таблице:

Наименование и уровень вложенности элементов	Кратность	Комментарий
1	2
Acknowledgement		0-1	Кратность = 1 для сообщений вида «Уведомление». Для прочих сообщений кратность = 0
	RegNumber	0-1	Регистрационный номер документа, присвоенный в СЭД организации-получателя. Кратность = 1 для сообщений об успешной регистрации документа (вид сообщения − «Уведомление о регистрации документа»).
	AckResult	1-n	Содержательная часть уведомления.

Элемент «Acknowledgement»

Назначение: Общие реквизиты уведомления.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
msg_id	1	String	Уникальный служебный идентификационный номер поступившего сообщения.
ack_type	1	Enum	Вид уведомления. = 3 для уведомления о регистрации.

Элемент «Acknowledgement/RegNumer»

Назначение: Регистрационный номер и дата регистрации документа, указанные в уведомлении о регистрации.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
regnum	1	String	Регистрационный номер документа.
regDate	1	Date	Дата регистрации документа.

Элемент «Acknowledgement/AckResult»

Назначение: Информация о результате регистрации – содержательная часть уведмоления.

Атрибуты: Допустимые атрибуты представлены в таблице:

Имя атрибута	Кратность	Тип	Описание
errorcode	1	Enum	Код ошибки. Формируется только при успешной регистрации. = 0
errortext	1	String	Описание ошибки. Содержание зависит от значения кода ошибки. При успешной регистрации не заполняется.

Приложение . Функциональные требования к ведомственным СЭД

Содержание:

1. Общие положения и область применения 57

2. Термины, определения и основные понятия 57

1. Классификационная схема 59

2. Меры и средства обеспечения безопасности 62

3. Сохранение контрольной информации. Аудит. 64

4. Отслеживание перемещения документов 65

5. Аутентичность 65

6. Гриф доступа 66

7. Регистрация документов 66

8. Контроль исполнения 69

9. Отчетные формы 70

10. Идентификаторы объектов 70

11. Поиск и визуализация 72

12. Требования к метаданным 74

13. Другие возможности 76

Управление процессами (Workflow) 76

ЭЦП 77

«Открытость» и взаимодействие с другими системами 78

Администрирование 78

Резервное копирование и восстановление 79

Целостность данных 79

 

1.  Общие положения и область применения

Настоящий документ содержит типовые базовые требования, предъявляемые к ведомственной СЭД (далее – СЭД), а также рекомендуемые требования и опциональные «модули», применимые в оговоренных ситуациях.

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

Требования разбиты на тематические «модули». Ряд модулей используются всегда и составляют «ядро» требований - это минимальные базовые требования. Некоторые модули или части модулей являются опциональными. В то же время опциональные модули могут содержать обязательные требования (т. н. «опционально-обязательные» требования), которые будут считаться обязательными в том случае, если опциональный модуль включается в программу тестирования и сертификации. Любой из модулей может содержать необязательные «желательные» требования.

2.  Термины, определения и основные понятия

В настоящем документе, помимо общеупотребительных, используются следующие термины, определения и понятия:

Управление процессами (workflow) - полная или частичная автоматизация делового процесса, в ходе которого документы, информация или задачи передаются от одного участника другому для выполнения действий в соответствии с набором процедурных правил. Под «участником» может пониматься пользователь, рабочая группа, или программное приложение.

Дело – совокупность документов, собранных по определенному критерию. Дело может состоять из нескольких томов и частей.

Том - часть дела, и отдельно от дела не существует. Дело всегда содержит хотя бы один том - первый - который, до момента создания второго тома, совпадает по содержанию со всем делом.

Электронное дело - совокупность взаимосвязанных электронных документов. В терминах настоящего документа термины «дело» и «электронное дело» эквивалентны.

Закрытие дел - процесс изменения атрибутов дела таким образом, что дальнейшее добавление (списание) в него документов не допускается.

Закрытое дело – дело, в которое невозможно добавить (списать) документ.

Открытие дел – процесс изменения атрибутов дела таким образом, что в него можно добавлять (списывать) документы. Открытием дела называют также создание нового дела.

Открытое дело – дело, в которое можно добавить (списать) документ.

Категория защиты - один или несколько атрибутов документа, которые определяют правила, регулирующие доступ к нему.

Классификационная схема - схема, позволяющая распределить документы по упорядоченным группам. Полный набор рубрик всех уровней вместе и составляет классификационную схему. Классификационная схема часто представляется в виде иерархической структуры.

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

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

Метаданные - (в контексте управления документами) структурированная или частично структурированная информация, поддерживающая создание, управление и использование документов. Реквизиты документа в регистрационной карточке являются метаданными. Понятие метаданные шире понятия реквизитов. В частности, данные протоколов обработки документа также относятся к метаданным, но не являются реквизитами документа.

Представление – отображение (проявление) электронного документа, которое пользователь может воспринимать. Сюда входят показ на экране дисплея, вывод на печать.

Роль - совокупность функциональных прав, предоставленных пользователю системы, одному или нескольким.

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

Аутентичность - подлинность (только в контексте управления документами). В отношении документа, данное качество подразумевает, что документ является именно тем, чем он претендует быть; оно не связано с достоверностью содержащейся в документе информации.

Поиск - идентификация объектов (дел и документов) на основе указанных пользователем параметров с целью подтверждения наличия, определения местонахождения, получения доступа к объектам.

Визуализация - создание изображения на экране и вывод на печать какого-либо объекта (документа, дела, списка и пр.). Это понятие может также подразумевать проигрывание аудио - и видеозаписей.

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

Классификационная схема – структура, в которую могут объединяться документы и дела. Как правило, в основе классификационной схемы лежат рубрики – для документов и номенклатура дел или рубрики – для дел.

3.  Классификационная схема

В ходе управления документами документы и дела могут объединяться в определенную структуру. Классификационной схемой называется представление такого объединения документов и дел.

Классификационная схема определяет, каким образом электронные документы формируются в электронные дела, и как организуются дела.

Обычно классификационная схема представляет собой иерархическую структуру. Более высокие уровни иерархии в классификационной схеме (рубрики) являются объединением дел и/или рубрик низшего уровня.

Документы и дела могут быть отнесены к рубрике любого уровня, как показано на приведенной схеме.

СЭД должна поддерживать и быть совместимой с классификационной схемой, используемой в организации.

СЭД должна иметь возможность поддерживать классификационную схему, в которой дела организованы в иерархическую структуру. Желательно, чтобы СЭД не ограничивала число возможных уровней в классификационной схеме.

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

СЭД должна давать возможность системным технологам добавлять новые подрубрики в любые рубрики. Добавление рубрик должно быть возможно на всех уровнях иерархии.

Рубрики «нижнего уровня рубрикации» не обязательно находятся на одном уровне иерархии классификационной схемы.

СЭД должна поддерживать как минимум два механизма присвоения имён делам:

·  механизм формирования и присвоения каждому электронному делу структурированного буквенно-цифрового регистрационного номера (т. е. уникального в масштабах классификационной схемы идентификатора);

·  механизм присвоения каждому электронному делу текстуального заголовка дела.

Должна иметься возможность использовать оба эти механизма по отдельности и совместно в рамках одного приложения

СЭД должна давать возможность добавлять (открывать) дела в рубриках классификационной схемы, не имеющих подрубрик («на нижнем уровне рубрикации»).

СЭД должна предоставлять возможность фиксировать дату создания дела в реквизитах дела.

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

СЭД не должна накладывать каких-либо практически значимых ограничений на число рубрик и дел, которые могут быть созданы.

СЭД должна предоставлять возможность создания и ведения списка (описи) дел.

СЭД должна давать возможность добавлять (открывать) новые электронные тома для любого незакрытого электронного дела.

СЭД должна регистрировать дату открытия нового тома дела в метаданных тома дела.

При открытии нового тома, СЭД должна автоматически включать в его метаданные те атрибуты метаданных «родительского» дела, которые являются общими (например, название, классификационный код).

СЭД не должна позволять пользователям добавлять электронные документы в закрытые дела.

СЭД должна давать возможность временно открывать ранее закрытые тома для добавления документов, и затем снова закрывать их.

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

Желательно, чтобы в СЭД имелась возможность помещать один и тот же электронный документ в несколько электронных дел, избегая при этом физического дублирования электронного документа.

СЭД должна давать возможность переместить электронный документ в другой том дела или в другое дело.

СЭД должна предоставлять возможность организовывать дела в структуру, поддерживая номенклатуру дел. Программное обеспечение СЭД должно давать пользователям возможность списывать электронные документы в дела, разбивать дела на тома.

4.  Меры и средства обеспечения безопасности

СЭД должна давать возможность определить роли и ответственность пользователей в соответствии с функциональными обязанностями в процессе работы документами.

СЭД должна поддерживать одновременный многопользовательский доступ ко всем своим компонентам, метаданным и документам.

СЭД должна иметь web-интерфейс, как минимум, для ввода, поиска и извлечения документов.

СЭД должна давать возможность ограничить доступ к документам, делам и метаданным, разрешив его только определённым пользователям или группам пользователей.

СЭД должна предоставлять возможность определить различных пользователей с различными правами доступа. СЭД должна контролировать доступ к документам на основе членства в группах или индивидуальной учётной информации о пользователе.

СЭД должна давать возможность включить в профиль пользователя атрибуты, определяющие те функциональные возможности системы, к которым пользователь имеет доступ.

Атрибуты профиля должны:

·  запрещать доступ в СЭД без прохождения установленной процедуры аутентификации;

·  ограничивать доступ пользователя к документам и дела определенной категории защиты.

СЭД должна иметь возможность использовать механизмы операционной системы идентификации и аутентификации пользователей, позволяющие только авторизованным лицам получать доступ в СЭД. Как минимум, должны использоваться:

·  идентификатор пользователя;

·  пароль.

Только системный технолог СЭД должен иметь возможность создавать профили пользователей.

Только системный технолог и администратор СЭД должны иметь возможность изменять относящиеся к обеспечению безопасности атрибуты групп пользователей (такие как права доступа, уровень допуска, привилегии, атрибуты управления паролями).

СЭД должна предоставлять возможность пользователю открытия доступа к находящимся у него на исполнении или контроле документам другим пользователям.

Если пользователь запрашивает доступ или ведёт поиск документа, тома или дела, к которым у него нет права доступа, СЭД должна реагировать одним из перечисленных способов (выбираемым на этапе конфигурирования системы):

1.  Показывать название документа/дела и метаданные.

2.  Информировать о существовании документа/дела (т. е. показывать номер документа или дела), но не показывать название и метаданные.

3.  Не предоставлять ни какой-либо информации о документе, ни о факте его существования.

Данные варианты перечислены в порядке усиления режима безопасности. Третий, наиболее строгий вариант требования подразумевает, что СЭД не должна учитывать подобные документы при подсчёте найденных в ходе поиска документов.

При выполнении пользователем полнотекстового поиска, в список результатов поиска не должны включаться документы, к которым пользователь не имеет права доступа.

5.  Сохранение контрольной информации. Аудит

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

СЭД должна отслеживать события в автоматическом режиме, и вносить сведения о них в контрольную информацию.

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

СЭД должна обеспечить сохранение контрольной информации об изменениях, сделанных в отношении:

·  отдельных документов;

·  отдельных дел;

·  реквизитов дел и документов.

СЭД должна обеспечить сохранение контрольной информации обо всех изменениях в параметрах администрирования. Например, об изменении прав пользователя.

СЭД должна иметь возможность фиксировать и сохранять в составе контрольной информации сведения о таких действиях, как:

·  регистрация документа в СЭД;

·  изменение ключевых реквизитов документа (как минимум, регистрационного номера);

·  просмотр документа;

·  удаление документа.

В СЭД должна иметься возможность экспортировать контрольную информацию, не внося при этом каких-либо изменений в контрольную информацию, хранящуюся в СЭД.

6.  Отслеживание перемещения документов

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

Функция отслеживания должна обеспечить фиксирование информации о движении документов, включающей:

·  уникальный идентификатор документа;

·  текущее местоположение документа, а также информация о предыдущих местоположениях;

·  дата и время передачи документа;

·  лицо, получившее документ.

Контролироваться должны все перемещения - как электронных, так и бумажных документов.

7.  Аутентичность

СЭД должна ограничивать доступ к функциям системы в соответствии с ролями пользователей и со строгой системой мер администрирования.

Желательно, чтобы, СЭД выдавала предупреждение о попытке ввода неполного или противоречивого документа, у которого неполнота или противоречивость могут в будущем поставить под сомнение его аутентичность.

8.  Гриф доступа

В СЭД должна быть возможность присваивать документам и делам категории защиты (в т. ч. грифы доступа).

СЭД должна предоставлять возможность назначать пользователям права работы с одним или несколькими грифами доступа.

СЭД должна отказывать пользователям в доступе к документам и делам, на работу с которыми у пользователя нет прав доступа по грифам.

9.  Регистрация документов

СЭД должна обеспечить следующие средства и функциональные возможности на этапе регистрации документов в системе:

·  регистрацию и управление всеми электронными документами;

·  размещение документов в классификационной схеме (рубрицирование) и помещение в одно или несколько дел;

·  интеграцию с прикладными программами, создающими документы;

·  контроль и управление процессом ввода реквизитов документов в СЭД.

СЭД должна давать возможность связывать атрибуты дела с документом и устанавливать связь между рубрикой и документом.

СЭД должна создавать и присваивать уникальный идентификатор каждому электронному документу, регистрируемому в системе.

СЭД должна автоматизировать процесс регистрации документов, за счёт автоматического извлечения метаданных, как минимум, из следующих типов документов:

·  исходящие офисные документы (например, текстовые документы стандартного формата), подготовленные с использованием шаблона;

·  входящие и исходящие электронные документы, передаваемые в виде сообщений электронной почты.

СЭД должна выдавать предупреждение при попытке пользователя зарегистрировать документ, который уже был зарегистрирован.

Желательно, чтобы СЭД предоставляла возможность регистрации документа повторно с соответствующей отметкой в реквизитах.

СЭД должна давать возможность устанавливать, заполнение каких полей реквизитов документа является обязательным для заполнения при регистрации документа в данной организации.

Только системному технологу СЭД должна давать возможность определять и добавлять дополнительные поля реквизитов.

СЭД должна обеспечить, чтобы на каждый зарегистрированный документ имелась доступная для просмотра учётная запись – регистрационная карточка, включающая реквизиты, указанные при настройке системы. При регистрации значения некоторых из реквизитов уже могут быть указаны в настройках системы и внесены в регистрационную карточку автоматически, или же могут быть автоматически извлечены из документа. СЭД должна потребовать ввода значения недостающих обязательных реквизитов.

Для всех исходящих документов, подготовленных с использованием шаблона, СЭД должна извлекать значения реквизитов из шаблона, и заполнять и/или давать пользователю возможность заполнить их до ввода документа в систему. СЭД должна обеспечить, чтобы всем обязательным для заполнения полям реквизитов до ввода в систему были присвоены непустые значения.

СЭД должна дать пользователю возможность отредактировать значения реквизитов документа в процессе регистрации до его ввода в систему.

СЭД должна фиксировать в метаданных дату и время регистрации документа.

СЭД должна давать возможность вводить значения реквизитов документа:

·  в момент регистрации.

и/или

·  на дальнейших стадиях обработки документа.

СЭД должна давать возможность создавать метаданные документа, просматривать их, сохранять и выводить на печать.

СЭД должна обеспечивать сбор и заполнение всех элементов метаданных, указанных при настройках системы, и постоянное сохранение их в неразрывной связи с электронным документом.

СЭД должна устанавливать связь между документом и его метаданными, с тем, чтобы документ был доступен для просмотра, экспорта и т. д.