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

Терминология

Термин «захват / capture э(8)» в контексте управления информационными технологиями используется в его изначальном понимании в английском языке. Здесь «захват э(8) информации» означает сохранение ее в компьютерной системе. Это соответствует архивному пониманию «захват / capture э(8)» («акт записывания или сохранения конкретного экземпляра цифрового э(23) объекта»), данному в  InterPARES 2 Project Terminology Database6.

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

Факт того, что СУЭОД э(32) может (в некоторых случаях) захватывать э(8) (простые) документы э(26), также как и официальные документы э(52), означает, что термин «захват / capture э(8)» не является абсолютно точным, поскольку захват э(8) официального  документа э(52) требует больших действий, нежели захват э(8) (простого) документа э(26), не являющегося официальным документом э(52). Например, процесс захвата э(8) официального документа э(52) включает в себя процесс классификации э(12), регистрации э(56) и блокирования возможности изменений, тогда как в случае с (простыми) документами э(26) в этом нет необходимости. Термин «провозглашать / declare» также иногда используется как синоним термина «захват / capture э(8)» в случае официальных документов э(52). В некоторых случаях, термин «провозглашение / declare» может также относиться и к (простому) документу э(26), как созданному вне СУЭОД э(32), так и к документу э(26) уже захваченному э(8) в СУЭОД э(32).

Отсутствие четкого определения не должно негативно отражаться на ясности понимания MoReq2.

Дополнительные формальные определения даны в глоссарии в разделе 13.1.

(Прим. переводчика: процесс превращения неофициального документа э(26) в официальный документ э(52) связан с двумя взаимосвязанными процессами: «провозглашения / declare» и «захвата / capture э(8)». Процесс «провозглашения» следует понимать в большей мере как юридический процесс, который, во‑первых, является обязательным условием по признанию юридического «официального» статуса провозглашаемого документа между заинтересованными сторонами, во‑вторых предоставляет регламентированный доступ к официальному документу и его содержанию всем лицам на которых распространяется юридическое действие официального документа и/или законные права которых он затрагивает. В отличие от процесса «провозглашения», процесс «захвата» следует понимать в большей мере как технический и организационный процесс, который решает две задачи: во-первых, обеспечивает сохранность официального документа и, соответственно, гарантирует наличие экземпляра официального документа в системе, во-вторых, блокирует возможность внесения изменений в официальный документ. MoReq2 исходит из предположения, что все необходимые юридические нормы об «официальном документе», о праве доступа к официальным документам, о сохранности, о защите от изменений, и иные нормы по работе с официальными документами регулируются национальным законодательством. MoReq2, как спецификация, предоставляет лишь методологию организации работ с официальными документами и содержит требования к технической инфраструктуре для реализации соответствующих норм национального законодательства.)

Процесс захвата

Электронные документы э(30) которые созданы или получены в ходе бизнес-процессов порождаются внутренними или внешними источниками. Электронные документы э(30) могут быть в различных форматах э(36), могут быть созданы разными авторами; они могут быть получены как единые документы э(26) или как документы э(26), содержащие несколько компонентов э(19) (см. глоссарий для определения MoReq2 понятия «компонент э(19)»).

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

№	Требование	Тест
Процесс захвата э(8) в СУЭОД э(32) обязательно должен обеспечивать средства управления и функциональные возможности, чтобы позволить пользователям э(68): захватывать э(8) электронные документы э(31) независимо от формата файла э(35), метода кодировки или других технологических характеристик, без изменения их содержания; гарантировать, что официальные документы э(52) связаны со схемой классификации э(14); гарантировать, что официальные документы э(52) связаны с одним или несколькими делом(ами) э(34) или классом(ами) э(11).	В
Определение формата файла э(35) дано в глоссарии. Требование говорит о способности захвата э(8) любого формата файла э(35).
Требование захватывать э(8) официальные документы э(52) в любом формате файла э(35) не предполагает быть тестируемым, и оно не означает, что СУЭОД э(32) должна быть способной делать представления э(50) (см. глоссарий) всех возможных форматов э(36). MoReq2 таким образом не перечисляет виды форматов э(36), которые могут быть захвачены э(8), т. к. форматы э(36) меняются со временем  в процессе эволюции программного обеспечения. Однако, во избежание сомнений, типы официальных документов э(52) могут быть очень разным; они могут включать, например, следующие типы официальных документов э(52), часто используемые в офисной деятельности: результаты настольных приложений, таких как офисные пакеты; сообщения электронной почты/text/category/videozapismz/" rel="bookmark">видеозаписи; интернет-страницы.
В некоторых ситуациях СУЭОД э(32) может также понадобиться захватывать э(8) другие виды официальных документов э(52), такие как:
блоги; сжатые дела э(34) (иногда называемые «архивами», обращаясь к ИТ значению термина); электронные э(29) календари; электронные э(29) формы; данные географической информационной системы (ГИС); информация из других компьютерных приложений, например, система бухгалтерского учета, система обработки платежных ведомостей, система автоматизированного проектирования (САПР); данные из систем обмена мгновенными электронными сообщениями; мультимедийные документы э(26); официальные документы э(52) сетевых транзакций; официальные документы э(52), которые включают ссылки на другие официальные документы э(52); исходный код программного обеспечения и программная проектная документация; структурированные данные (например, EDI-транзакции); сетевое вещание; энциклопедические словарные статьи в формате " wiki".
Эти списки неполные.
СУЭОД э(32) не должна накладывать никакого практического ограничения ни на количество официальных документов э(52) в которые могут быть захвачены э(8) в любом классе э(11), деле э(34), разделе э(66) или томе э(74), ни на общее количество  официальных документов э(52) которые могут храниться в СУЭОД э(32).	В
Большое количество официальных документов э(52) в томах э(74) и т. д., может затруднять использование системы во многих случаях, поэтому, как правило, это не рекомендуется. Это требование имеет целью разрешить ситуации, в которых большое количество документов неизбежно, как в обстановке большого количества транзакций.
При захвате э(8) официального документа э(52), составленного из нескольких компонентов э(19), СУЭОД э(32) должна захватывать э(8) все его компоненты э(19).	В
При захвате э(8) электронного официального документа э(31), имеющего более одного компонента э(19), СУЭОД э(32) должна позволять управление официальным документом э(52) как единым целым, сохраняя отношения между компонентами э(19) и сохраняя структурную целостность официального документа э(52).	В
Примерами таких официальных документов э(52) являются: Интернет-страницы с внедренной графикой; Документ э(26), созданный в текстовом процессоре, но связанный с электронной таблицей.
В некоторых случаях компоненты э(19) будут связаны ссылками, которые не работают при простом копировании в хранилище СУЭОД э(32). Например, многие Интернет-страницы содержат ссылки к графике и другим объектам с адресом (URLs), находящимся вне хранилища; связанные электронные таблицы также обычно содержат ссылки к адресам (имена файлов в операционной системе), находящимся вне хранилища. См. следующее требование.
При захвате э(8) электронного официального документа э(31), который имеет более одного компонента э(19), СУЭОД э(32) должна модифицировать официальный документ э(52), если необходимо, чтобы сохранить способность представления э(50). Это подразумевает,  что СУЭОД э(32) может изменять внутренние связи (ссылки) в некоторых компонентах э(19).	В
Это требование действует только по отношению к форматам файла э(35), определенным для СУЭОД э(32), оно не распространяется на иные  форматы э(36). Примеры могут включать: HTML страницы, включающие ссылки на графику и другие объекты; Электронные таблицы которые включают ссылки на другие электронные таблицы.
Внесение таких изменений противоречит главном принципу неизменности содержания официальных документов э(52), но оно неизбежно, если официальные документы э(52), содержащие компоненты э(19) и т. п., должны храниться в их оригинальных форматах э(36) без потери их функциональности и точности. Изменения, как правило, будут допустимы, если они будут зарегистрированы в протоколе аудита э(4) СУЭОД э(32) (см. следующее требование). Альтернативный подход включает преобразование э(57) официального документа э(52) в какой-то другой формат файла э(35) (такой как PDF/A), сохраняющий статический внешний вид; см. требование 11.7.8; однако, даже хотя это позволяет избежать изменения ссылок, в результате они могут быть потеряны.
Когда СУЭОД э(32) во время захвата э(8) меняет систему ссылок внутри официального документа э(52), это должно быть автоматически зарегистрировано в протоколе аудита э(4) со всеми деталями произведенных изменений.	Д
СУЭОД э(32) для каждого компонента э(19), когда он захватывается э(8), обязательно должна автоматически захватывать э(8) формат файла э(35) (см. глоссарий), включая версию э(72), и должна все это хранить в метаданных э(40) компонента э(19).	В
Это требуется для поддержки цифровой э(23) сохранности официальных документов э(52) – их доступности в течение долгого времени. См. раздел 11.7.
Некоторая информация о формате файла э(35) обычно неявно задана посредством расширения имени файла компонента э(19), например:  “.htm” или “.pdf”; и иногда оно может быть неоднозначно, например, “.doc” может указывать на несколько не связанных друг с другом форматов э(36). Однако одно только расширение часто не указывает на версию формата файла э(35) и иногда даже на сам формат файла. Это может быть приемлемо во многих случаях, однако, этого может быть недостаточно в случаях, когда требуется обеспечить долгосрочное хранение или когда требуется большая точность (например, точное определение используемой палитры цвета).
Форматы файлов э(35) многочисленны и подвержены частому изменению, поэтому в реальности не следует ожидать, что СУЭОД э(32) будет захватывать э(8) информацию для всех форматов файлов э(35). Из этого следует, что  для СУЭОД э(32) допустимо: Указывать список форматов файлов э(35), которые будут распознаваться; Полагаться на ссылку к реестру установленных форматов файлов э(35) – предпочтительно тех, что предназначены специально для поддержки цифрового э(23) сохранения. В любом случае эксплуатирующая организация должна быть убеждена, что перечень включенных форматов файлов э(35) является достаточным для требований сохранности.
Процесс захвата э(8) официальных документов э(52) в СУЭОД э(32) обязательно должен позволять проверять значения метаданных э(40), вводимых в СУЭОД э(32), во время захвата э(8) официальных документов э(52), как минимум в соответствии с правилами, указанными в «Модели метаданных MoReq2» (см. приложение 9).	Д
См. также  э6.1.34 в этом разделе.
СУЭОД э(32) должна поддерживать проверку правильности элементов метаданных э(40) используя алгоритмы контрольных цифр.	Д
Например, дела э(34) могут быть идентифицированы по 16‑значному номеру кредитной карты, в котором последняя цифра является контрольной цифрой и вычисляется на основе пятнадцати других цифр, используя алгоритм умножения по модулю 10.
Предоставление интерфейса прикладного программирования для этого требования должно позволять организациям использовать самостоятельно выбранные ими алгоритмы, что обычно считается приемлемым.
СУЭОД э(32) обязательно должна позволять пользователям э(68) захватывать э(8) электронный официальный документ э(31), даже в отсутствие программного обеспечения, использовавшегося для составления официального документа э(52).	Д
Например, пользователь э(68) может получить план проекта и чертеж системы автоматизированного проектирования и управления производством (САПР / САУП), по электронной почте в виде файлов-вложений (attachments). Если у пользователя э(68) нет программному обеспечению по работе с планами проектов или приложениям САПР / САУП, тогда пользователь э(68) не сможет увидеть присланные ему файлы-вложения. Несмотря на это, пользователь э(68) должен быть в состоянии захватить э(8) фалы-вложения в СУЭОД э(32) как официальные документы э(52). СУЭОД э(32) может предоставлять пользователю э(68) дополнительное программное обеспечение («вьюверы») для просмотра подобных официальных документов; но это не является требованием MoReq2.
СУЭОД э(32) должна быть способной захватывать э(8) метаданные э(40) об официальных документах э(52), соответствующих «Модели метаданных MoReq2» (см. приложение 9).	Д
СУЭОД э(32) должна быть способной захватывать э(8) автоматически значения из полей, указанных ролью администратора э(1), внутри определенного типа документов э(27), используя эти значения автоматически для заполнения элементов метаданных э(40), как определено в «Модели метаданных MoReq2» (см. приложение 9).	Д
Функциональность, необходимая для этого требования, применяется только к специфическим видам электронных э(29) объектов, например, письма, созданные с использованием определенных шаблонов и определенного текстового процессора.
Многие документы э(26), включая некоторые офисные документы э(26) и  PDF э(46) - файлы, включают элементы метаданных э(40), которые конфигурируются пользователем э(68).  Должно быть возможным конфигурировать СУЭОД э(32) для автоматического захвата э(8) значений этих элементов и сохранения их вместе с официальным документом э(52).
СУЭОД э(32) обязательно должна позволять захватывать э(8) все элементы метаданных э(40), указанные во время конфигурации системы, и обязательно должна сохранять их вместе с соответствующим электронным официальным документом э(31) в постоянно-связанных отношениях на все время (жизненного цикла официального документа или системы).	Д
СУЭОД э(32) должна позволять пользователям э(68), желающим осуществить процедуру захвата э(8) официального документа э(52), но не способным предоставить все его обязательные значения метаданных э(40), сохранять его временно в СУЭОД э(32).	Д
Другими словами, СУЭОД э(32) должна обеспечивать способ сохранения официальных документов э(52), не содержащих всех их метаданных э(40), т. е. без завершения нормального процесса захвата э(8). Это подразумевает отчетность и мониторинг изменений; это не имеет в виду каких-либо требований по работе с такими официальными документами э(52), как с обычными официальными документами э(52), в плане экспорта э(33), передачи э(67), создания образа э(59) и пр.  MoReq2 не указывает, как это достигается.
Только доступные для редактирования значения метаданных э(40) могут быть изменены на более поздних стадиях, но зафиксированные метаданные э(40) (напр. данные пересылки электронной почты) должны оставаться неизменными.
СУЭОД э(32) обязательно должна гарантировать, что содержание указанных элементов метаданных э(40) электронного официального документа э(31) может быть изменено только уполномоченным пользователем э(6) или ролью администратора э(1), в соответствии с правилами главы 12.	Д
СУЭОД э(32) обязательно должна гарантировать, что все официальные документы э(52) отнесены как минимум к одному соответствующему классу э(11), делу э(34) (или его разделу э(66), если применимо) во время захвата э(8).	Д
СУЭОД э(32) должна поддерживать автоматизированную поддержку захвата э(8) официальных документов э(52), автоматически извлекая столько метаданных э(40), на сколько это возможно, для стольких различных видов документов э(26), на сколько это возможно.	Н
Суть этого требования состоит в следующем: минимизировать количество данных, вводимых пользователями э(68) (опыт показывает, что во многих случаях требование ввода метаданных э(40) может заставить пользователей э(68) отклонить использование системы); повысить точность метаданных э(40). Элементы метаданных э(40) и виды документов э(26), для которых возможна автоматическая обработка, будут зависеть от системного окружения. Некоторые руководства даны в «Модели метаданных MoReq2» (приложение 9).
СУЭОД э(32) обязательно должна поддерживать автоматизированную поддержку захвата э(8) исходящих и внутренних документов э(26) (напр., служебные записки или письма текстового процессора по определенному шаблону и формату файла э(35)) как официальных документов э(52), автоматически извлекая из них следующие метаданные э(40): дата документа (как  в основной части документа э(26)); получатель(и); каждый получатель(и) копии(й); содержание (заголовок); автор(ы); внутренние ссылки (обычно обозначаемые как «наши ссылки»); в случае их наличия.	Д
MoReq2 не указывает программное обеспечение или форматы э(35) для офисных документов э(26) или электронной почты. Извлечение метаданных э(40) может быть выполнено: или посредством определения местоположения метаданных э(40) в официальном документе э(52), или с использованием шаблона для указания метаданных э(40), или путем заполнения бланка документа э(26), или с помощью других средств.
СУЭОД э(32) обязательно должна захватывать э(8) дату и время официального документа э(52) и в метаданные э(40), и в протокол аудита э(4).	Д
Если дата и время являются частью уникального идентификатора официального документа э(52), и поскольку они могут быть явно извлечены из идентификатора, необязательно хранить дату и время отдельно.
MoReq2 не указывает необходимую степень точности определения времени. В большинстве СУЭОД э(32) время определяется с точностью до одной секунды или точнее.
Некоторые национальные законодательные базы могут требовать использования штампа времени, генерируемого сертифицированным устройством или уполномоченным органом (удостоверяющим центром). Там где это является актуальным, положения об этом должны быть размещены в нулевой главе.
СУЭОД э(32) обязательно должна быть способной представлять э(50) на экране метаданные э(40) каждого захваченного э(8) официального документа э(52), включая те, что определены на этапе конфигурации э(20).	Д
Метаданные э(40), определенные на этапе конфигурации э(20), могут состоять из любого или всех элементов соответствующего раздела главы 12.
СУЭОД э(32) обязательно должна гарантировать, что все обязательные метаданные э(40) присутствуют в каждом захваченном э(8) официальном документе э(52).	Д
Во время захвата э(8) официального документа э(52) СУЭОД э(32) обязательно должна запросить у пользователя э(68) ввести необходимые метаданные э(40), которые не были захвачены автоматически.	Д
СУЭОД э(32) обязательно должна поддерживать присваивание множественных ключевых слов э(39) (или ключевых терминов) для каждого класса э(11), дела э(34), раздела э(66) и официального документа э(52).	Д
MoReq2 не устанавливает требования задавать ключевые слова э(39) для томов э(74).
СУЭОД э(32) должна позволять роли администратора э(1) на этапе конфигурации э(20), решать являются ли те или иные ключевые слова э(39) обязательными или необязательными, для каждого класса э(11), дела э(34) или раздела э(66).	Д
СУЭОД э(32) обязательно должна позволять создавать более чем одну сущность (класс э(11), дело э(34) и т. п.), используя те же самые комбинации ключевых слов э(39).	Д
СУЭОД э(32) должна позволять пользователю э(68) создавать сущность заполняя значения ее ключевых слов э(39) путем их группового копирования из другой сущности одним действием.	Д
СУЭОД э(32) должна позволять пользователю э(68) вводить идентификатор одного или более языков для любого официального документа э(52).	Д
СУЭОД э(32) обязательно должна предоставлять возможность значениям ключевых слов э(39) и иным значениям элементов метаданных э(40) быть выбранными из контролируемых словарей (или списка разрешенных терминов) или быть согласно них проверенными на правильность значений.	Д
Например, посредством списка для выбора или тезауруса. См. также требование э11.8.11.
СУЭОД э(32) обязательно должна разрешать ввод последующих дополнительных описательных и других метаданных э(40) как во время захвата э(8) , так и на более поздних стадиях обработки.	Д
СУЭОД э(32) обязательно должна выдавать предупреждение пользователю э(68), в случае если предпринимается попытка захвата э(8) объекта с заголовком, который уже существует в той же сущности, или в случае если предпринимается попытка переименования объекта, когда одноименный заголовок уже существует в той же сущности.	Д
См. также э11.8.6.
СУЭОД э(32) обязательно должна быть способной резервировать способность добавлять заголовок электронного официального документа э(31) ролью администратора э(1) или иным уполномоченным пользователем э(6).	Д
Эта функция может использоваться или нет по выбору организации.
Когда пользователь э(68) осуществляет процесс захвата э(8) документа э(26), который имеет более чем одну версию э(72), СУЭОД э(32) обязательно должна разрешать пользователю э(68) выбирать как минимум одно из следующих: провозглашать все версии э(72) в качестве официального документа э(52); провозглашать одну конкретную версию э(72) в качестве официального документа э(52); провозглашать каждую версию э(72) как отдельный официальный документ э(52).	Д
СУЭОД э(32) должна быть способна обеспечивать автоматизированную поддержку принятия решения о классификации э(12) электронного официального документа э(31) посредством по крайней мере одного из следующих: определение только подмножества схемы классификации э(14) открытого для доступа пользователю э(68) или роли э(62); предложение классов э(11) или дел э(34), к которым пользователь э(68) обращался недавно; предложения классов э(11) или дел э(34), к которым пользователь э(68) обращался наиболее часто; предложения классов э(11) или дел э(34) на основе логических выводов сделанных по значениям элементов метаданных э(40) официальных документов э(52) (например, по значимым словам заголовка или графы обозначения содержания электронной почты); предложения классов э(11) или дел э(34) на основе логических выводов сделанных по содержательной части официальных  документов э(52).	В
СУЭОД э(32) должна разрешать завершать процесс захвата э(8) официального документа э(52) более чем одному пользователю э(68).	Д
СУЭОД э(32) должна разрешать разделять процесс захвата э(8) между пользователями э(68); обычно это значит, что один пользователь э(68) вводит часть метаданных э(40), а затем передает электронный официальный документ э(31) другому пользователю э(68), который вводит оставшиеся метаданные э(40) и классифицирует э(12) официальный документ э(52).
СУЭОД э(32) должна предоставлять простые средства поддержки рабочих процессов, реализующих простую маршрутизацию, с целью согласования и утверждения документа э(26) перед захватом э(8), включающих протоколирование принимаемых решений, кто их принимал и на каком основании.	Д
Примечание: это требует только базовых функций управления рабочими процессами. Они намеренно описываются кратко в отличие от полных рабочих процессов, описанных в главе 10.
СУЭОД э(32) должна предоставлять интерфейс прикладного программного обеспечения (API) для получения и захвата э(8) в реальном времени индивидуальных официальных документов э(52) и транзакций,  предоставленных другим приложением или системой.	Н
Как упоминалось в разделе 1.4, функциональность СУЭОД э(32) может быть частью более широкой системы. Это может потребовать от СУЭОД э(32) получать официальные документы э(52) из другой системы, например, из приложения корпоративного бизнеса, такого как CRM ("Customer Relationship Management" / «Система управление отношениями с клиентами») или ряд бизнес-приложений доступных через интерфейс API ("Application Programming Interface" / «Интерфейс программирования приложений»), с тем чтобы сделать СУЭОД э(32) способной захватить э(8) индивидуальные официальные документы э(52).
Там, где возможно, СУЭОД э(32) должна выдавать предупреждение, если пользователь э(68) пытается захватить э(8) официальный документ э(52) электронной почты, который уже был захвачен э(8) в том же деле э(34) или в том же классе э(11) (если был классифицирован э(12) сразу в класс э(11)).	Д
MoReq2 не определяет, как идентифицируется электронная почта; однако идентификация сообщения электронной почты может быть в зависимости от ситуации.
В некоторых случаях это логически невозможно, например, когда официальный документ э(52) электронной почты был захвачен э(8) в дело э(34), в доступе к которому пользователю э(68) отказано.
Там, где возможно, СУЭОД э(32) должна выдавать предупреждение, если пользователь э(68) пытается осуществить процесс захвата э(8)  официального документа э(52) (кроме электронной почты, т. к. относится к 6.1.37), имеющего то же текст, что и другой официальный документ э(52), который уже был зарегистрирован э(56) в том же деле э(34) или в том же классе э(11) (если был классифицирован э(12) сразу в класс э(11)).	Д
Там где возможно, СУЭОД э(32) должна выдавать предупреждение, если пользователь э(68) пытается осуществить процесс захвата э(8) официального документа э(52) (кроме электронной почты, т. к. относится к 6.1.37), который имеет те значения определяющих метаданных э(40), что и другой официальный документ э(52), уже зарегистрированный э(56) в том же деле э(34) или в том же классе э(11) (если был классифицирован э(12) сразу в класс э(11)).	Д
Определяющими метаданными э(40) данного требования являются: Заголовок; Дата; Автор; Адресат.
Там, где это возможно и оправдано, СУЭОД э(32) должна выдавать предупреждение, если предпринимается попытка захвата э(8) официального документа э(52), который является неполным или с противоречивым набором параметров, что в будущем может поставить под сомнение его надежность.	Н
Например, заказ на покупку без действующей электронной э(29) подписи или счет от неопознаваемого поставщика.
	СУЭОД э(32) должна разрешать ролям администраторов э(1) (не ролям пользователей э(71)), добавлять официальный документ э(52) в ранее закрытый э(17) том э(74) при условии, что дата официального документа э(52) не позднее даты закрытия э(16) (тома э(74)). Если такое происходит: СУЭОД э(32) должна потребовать, чтобы лицо, выполняющее роль администратора э(1), указывало причину в метаданных э(40) как тома э(74), так и официального документа э(52), с объяснением, почему было сделано исключение; СУЭОД э(32) должна автоматически зарегистрировать это в протоколе аудита э(4). Данное действие не должно изменять дату закрытия э(16) (тома э(74)), сохраненную в метаданных э(40).	Д
	Эта возможность предусмотрена для исправления ошибок пользователей э(68), например, если том э(74) закрыт э(17) случайно. В данном случае важно, чтобы исключение, повлекшее данное действие, было правильно документировано.
MoReq2 не дает указаний, как это достигается. Это может быть достигнуто путем временного открытия э(43) закрытого э(17) тома э(74) или другими средствами.

Массовый импорт

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