Шаблон технического задания
для продукта СЭД DV Box

Общие сведения

Полное наименование работ

Настоящее Техническое задание определяет требования и порядок создания Системы электронного документооборота.

Термины и условные обозначения

Табл. 1 Термины и условные обозначения

Назначения и цели

1.1 Назначение системы

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

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

1.2 Цели создания системы

Основной целью создания системы является повышение эффективности управления предприятием и выполнения операционных бизнес-процессов, связанных с обработкой документов, за счет подчиненных целей:

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

Требования к программному обеспечению в целом

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

Требования к структуре и функционированию

Технологический ракурс

Программное обеспечение Системы должно иметь трехуровневую архитектуру, основными компонентами которой являются:

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

Процессный ракурс

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

Делопроизводство:

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

Требования к способам и средствам связи для информационного обмена между компонентами программного обеспечения

Все компоненты программного обеспечения Системы должны поддерживать взаимодействие между собой при помощи локальной сети предприятия, построенной по технологии Ethernet с использованием протоколов TCP/IP. Взаимодействие клиентов с серверами приложений должно осуществляться по протоколу HTTP+SOAP либо WCF.TCP. Отдельные клиенты могут соединяться с серверами приложений через каналы доступа к Интернет, по технологии VPN или с применением других технологий безопасного удаленного доступа.

Требования к характеристикам взаимосвязей программного обеспечения со смежным программным обеспечением

Программное обеспечение системы должно иметь возможность взаимодействия с основными элементами инфраструктуры информационно-коммуникационных технологий (ИКТ-инфраструктуры) предприятия.

Рис. 1

Смежным программным обеспечением являются:

• Службы Windows – взаимодействие ПО СЭД с основными службами Windows должно осуществляться в процессах:
  • Авторизация пользователей для доступа к СЭД посредством службы каталогов Active Directory;
  • Импорт-экспорт с файловой системой, вывод данных карточек СЭД на печать, и т.п.
• Система электронной почты – ПО СЭД должно обладать возможностью отправки и получения электронных почтовых сообщений из/в СЭД при помощи почтовой программы (уведомления, документы, задания и пр., в том числе со ссылками на задания в Системе) с использованием протоколов SMTP/POP3 или Exchange Web Services.
• Стандартные клиентские приложения – ПО СЭД должно обеспечить возможность обработки файлов документов, хранящихся в ПО СЭД, и другие способы взаимодействия в ходе выполнения операций пользователей с ПО.

Перспективы развития, модернизации

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

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

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

Для реализации подписания документов и операций с карточками ПО СЭД должно обеспечивать поддержку всех видов электронной подписи в соответствии с ФЗ-63 «Об электронной подписи»:

• Простой электронной;
• Усиленной неквалифицированной;
• Усиленной квалифицированной.

ПО Системы должно поддерживать протокол TSP, позволяющий установить метку (штамп) времени и осуществить проверку действительности квалифицированного сертификата электронной подписи на момент подписания документа, а также протокол OCSP для проверки сертификата в режиме реального времени. Подписание должно производиться с использованием криптопровайдеров, совместимых с Microsoft CryptoAPI.

Требования к безопасности

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

Программное обеспечение системы должно обеспечивать два уровня безопасности:

• Дискреционная – прямое назначение прав пользователям доступа к объекту (списки);
• Ролевая – роль пользователя вычисляется динамически для каждой карточки в зависимости от значений полей карточки, её статуса, а также дополнительных условий, определяющих принадлежность пользователя к процессу обработки Роль пользователя системы - совокупность функциональных прав, предоставленных предопределенному подмножеству пользователей системы, может ограничивать возможности пользователя системы, допуская поиск и чтение электронных документов (электронных образов документов) только в пределах определенных разделов (подразделов) классификационной схемы.

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

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

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

Требования к эргономике и технической эстетике

Взаимодействие пользователей с прикладным программным обеспечением Системы, должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс ПО Системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме.

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

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

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

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

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

Требования к патентной чистоте

Требования к патентной чистоте определяются требованиями действующего Российского Законодательства и требованиями договора на поставку программного обеспечения СЭД.

В случае использования в составе ПО СЭД модулей, разработанных на базе свободно распространяемого программного обеспечения, ее предоставление Заказчику производится на основе открытой лицензии (ст. 1286.1. Гражданского кодекса РФ).

Исполнитель должен гарантировать патентную и лицензионную чистоту предоставляемой простой (неисключительной) лицензии и нести полную ответственность в случаях обращения на Заказчика претензий третьих лиц, в том числе обладателей исключительных прав, связанных с нарушением предоставленных прав, согласно законодательству Российской Федерации.

Требования к программно-аппаратному комплексу

ПО СЭД должно поддерживать возможность работы пользователей как в Web-клиенте, так и в клиентском рабочем месте для Windows и Linux. Функции администрирования системы могут осуществляются только в клиентском рабочем месте для Windows.

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

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

ПО СЭД должно обеспечивать возможность использования системного ландшафта, состоящего из двух полигонов:

• Среда разработки (тестовая среда) - комплекс программно-аппаратных средств, используемый программистами для разработки и настройки программных решений, а также для тестирования настроенного решения, внесенных изменений и доработок;
• Промышленная среда - комплекс программно-аппаратных средств, используемый для промышленной эксплуатации системы.
• В состав каждой из сред входят:
• Сервер БД – база данных под управлением Microsoft SQL Server, содержащая набор таблиц и хранимых процедур;
• Сервер приложений – сервер, с установленными серверными компонентами СЭД;
• Рабочее место пользователя, обеспечивающее пользователю интерфейс для полнофункциональной работы со всеми объектами системы в соответствии с имеющимися у него правами доступа;
• Рабочее место администратора, обеспечивающее функциональность по настройке системы;
• Консоль настройки, предназначенная для создания и обновления базы данных, а также для настройки служб и компонентов системы.

Системное программное обеспечение и программное обеспечение офисного назначения (в том числе средства СКЗИ, сертификаты ЭП, офисное программное обеспечение, программное обеспечение информационной безопасности и т.д.) а также лицензии на такое ПО, равно как и аппаратное обеспечение (сервера, телекоммуникационное оборудование, клиентские рабочие станции и т.д.) не являются предметами настоящей Закупки и будут предоставлены Заказчиком.

Требования к системному программному обеспечению

Программное обеспечение сервера приложений

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

• Microsoft .NET Framework 4.6.1.;
• веб-сервер Internet Information Services (IIS) версий 7.5, 8.0, 8.5 с поддержкой ASP.NET 4.0;
• Microsoft Visual C Runtime (MSVCRT);
• Internet Information Services (IIS) с поддержкой ASP.NET 4.0;
• Microsoft XML Parser (MSXML).

Операционная система:

• Microsoft Windows Server 2016 (Standard, DataCenter);
• Microsoft Windows Server 2012 R2 (Standard, DataCenter);
• Microsoft Windows Server 2012 (Standard, DataCenter);
• Microsoft Windows Server 2008 R2 (Standard, Enterprise, DataCenter, Web);

Лицензии на ПО сервера приложений не входит в состав ПО, предоставляемого в рамках настоящей поставки.

В качестве почтового сервера должен использоваться любой почтовый сервер, поддерживающий протоколы SMTP/POP3 или Microsoft Exchange Web Services (Microsoft Exchange версий 2010 или 2007SP1 с установленным дополнительным компонентом).

Программное обеспечение сервера баз данных

ПО СЭД должно предусматривать использование одной из следующих СУБД:

• Microsoft SQL Server 2017 (Standard, Enterprise или Developer Edition);
• Microsoft SQL Server 2016 (Standard, Enterprise или Developer Edition);
  • для Microsoft SQL Server 2016 должно быть установлено обновление Cumulative Update 4 for SQL Server или более новое;
  • для Microsoft SQL Server 2016 SP1 должно быть установлено обновление Cumulative Update 2 for SQL Server 2016 SP1 или более новое;
• Microsoft SQL Server 2014 (Standard, Enterprise или Business Intelligence).

Лицензии на ПО сервера баз данных не являются предметом настоящей поставки.

Дополнительное программное обеспечение:

Программное обеспечение клиентских рабочих мест

ПО СЭД должно поддерживать следующее программное обеспечение на клиентских рабочих местах при работе через Win-клиент:

• Microsoft Windows 7 SP 1 (Enterprise, Professional, Ultimate);
• Microsoft Windows 8/8.1 (Pro, Enterprise)3;
• Microsoft Windows 10 (Pro, Enterprise);

При подключении к СЭД через Web-клиент:

• Операционная система:
• Microsoft Windows 7 (Enterprise; Professional; Ultimate).
• Microsoft Windows 8/8.1 (Pro, Enterprise).
• Microsoft Windows 10 (Pro, Enterprise).
• Linux-совместимая ОС (Astra Linux, Alt Linux и др.)
• MacOS
• Android
• iOS, iPadOS

Работа Web-клиента должна быть поддержана для следующих браузеров:

• Microsoft Internet Explorer 11;
• Microsoft Edge 42.17134.1.0 и выше;
• Google Chrome 70.0.3538.77 и выше (для OC Windows, Android, *nix);
• Яндекс.Браузер 18.9.1.954 и выше (для ОС Windows);
• Safari 12.0.1.и выше (для MacOS, iOS, iPadOS)
• Почтовый клиент – любой совместимый с ОС АРМ
• Microsoft Office 2010 или выше

1.2.1. Требования к аппаратному обеспечению

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

Табл. 2 Системные требования к серверу приложений/баз данных

Табл. 3 Минимальные системные требования к клиентским рабочим местам

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

Табл. 4 Рекомендуемые системные требования к клиентским рабочим местам

Общие требования к автоматизации работы с документами и заданиями

Хранение и доступ

Программное обеспечение СЭД для хранения и поиска карточек должно обеспечивать иерархическую структуру хранения. На верхнем уровне иерархии должны располагаться блоки: Входящие документы, Исходящие документы, Организационные, Служебные записки, Договоры, Отчеты, Мои задания.

Блоки с документами на 2-м уровне должны быть разбиты на подпапки по состояниям документов: Подготовка, На согласовании, На подписании, На регистрации, Зарегистрированы, Отменены и т. д. Также на 2-м уровне должна располагаться папка «Поиск» для осуществления поиска по атрибутам карточки и папка «Шаблоны» для хранения шаблонов типовых документов.

Блок «Отчеты» на 2-м уровне должна содержать папки с названиями отчетов, настроенных в системе.

Блок «Мои задания» на 2-м уровне должна содержать папки «Мои задания» (для доступа к поступившим заданиям на текущего сотрудника), «Я – заместитель» (для доступа к заданиям замещаемого), «Поиск» (для поиска заданий по атрибутам). Также в блоке «Мои задания» должны располагаться папки для осуществления контроля и приемки Поручений.

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

• Хранение регистрационной карточки документа;
• Хранение файлов документов, ассоциированных с карточкой;
• Настройка иерархической структуры хранения документов (папок);
• Разграничение прав доступа на уровне иерархии хранения карточек документов;
• Разграничение прав доступа к отдельному документу, в том числе:
  • Полный контроль над карточкой;
  • Право редактировать, но не уничтожать карточку;
  • Право читать карточку, но не редактировать ее;
  • Право доступа к карточке, но не к содержимому документа;
  • Полное отсутствие прав доступа к карточке;
• Присвоение регистрационных номеров;
• Категоризация карточек документов – отнесение через атрибуты к одной или нескольким категориям из настраиваемого списка;
• Установление ссылочных связей между карточками документов;
• Возможность блокировки файлов документов и контроль использования для файлов документов.

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

• Полнотекстовый поиск с поддержкой морфологии русского языка;
• Поиск по атрибутам карточек документов;
• Создание библиотеки поисковых запросов;
• Параметризация поискового запроса в момент его использования;
• Поиск по служебным словам, интерпретируемым при выполнении запроса (например, для дат; «сегодня +/– N дней», «сейчас»), для пользователей: «текущий пользователь», «руководитель текущего пользователя»).

Организация замещения исполнения

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

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

Назначить постоянного или временного заместителя должен иметь возможность Администратор системы. Также пользователь должен иметь возможность самостоятельно установить замещение на время отсутствия (данная функция доступна только в приложении для Windows).

Работа с шаблонами карточек документов

В системе должна быть возможность создания карточек документов по преднастроенным шаблонам.

В структуре папок с документами по каждому виду документа должна быть добавлена папка «Шаблоны», предназначенная для создания и хранения карточек шаблонов.

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

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

Кроме полей, которые должны быть заполны динамически:

• «№ СЭД» (системный номер) - поле должно быть заполнено значением в соответствии с правилом нумерации.
• «Дата создания» - поле должно быть заполнено текущей датой.
• «Инициатор» - поле должно быть заполнено текущим сотрудником.

А также полей, которые должны остаться пустыми:

• «№ документа» (регистрационный номер)
• «Дата документа»

Исполнение заданий

В Системе должна быть возможность направлять задания со следующими типами исполнения:

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

Требования к блоку «Делопроизводство»

Настройка справочников

Справочник сотрудников

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

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

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

Для всех сотрудников должна быть настроена строка отображения формата <Фамилия> <Имя> <Отчество>, <Должность>.

Справочник контрагентов

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

Справочник контрагентов системы заполняется из таблицы формата MS Excel, заполняемой Заказчиком по шаблону, предоставляемому Исполнителем, либо вручную специалистами Заказчика по мере использования Системы.

Справочник ссылок

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

Табл. 5 Виды ссылок

Значения справочника могут быть изменены или дополнены специалистами Заказчика в ходе эксплуатации системы.

1.2.2. Дополнительные справочники системы

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

В системе должны быть созданы следующие дополнительные справочники:

Справочник типов доставки

Справочники типов документов:

• Справочник типов Входящих документов
• Справочник типов Исходящих документов
• Справочник типов Служебных записок
• Справочник типов Организационно-распорядительных документов
• Справочник типов Договоров

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

Справочник типов Договорных документов

Справочник Номенклатуры дел:

• Справочник «Года номенклатуры». Данный справочник представляет собой перечень годов
• Справочник «Дела номенклатуры». Данный справочник представляет собой линейный перечень названий дел номенклатуры

Данные справочники должны быть наполнены в соответствии с данными, предоставленными Заказчиком.

Виды документов

Для работы с документами в системе должны быть доступны следующие виды карточек документов:

• Входящий документ;
• Исходящий документ;
• Организационно-распорядительный документ;
• Служебная записка;
• Договор.

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

Нумерация документов

Для нумерации каждого вида карточек документов должны использоваться два типа номера: регистрационный и системный. Регистрационный и системный номера должны записываться в разные поля карточки документа. Системные номера всем документам должны присваиваться по единому правилу при создании карточки, регистрационные – после подписания документа (для входящих документов – в момент создания).

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

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

Требования к карточкам документов и заданий

1.2.3. Общие настройки

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

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

Вкладка «Основная» предназначена для отображения регистрационных данных о карточке документа. Состав атрибутов на данной вкладке зависит от вида документа и описан в разделах по соответствующим видам документов.

Вкладка «Комментарии» предназначена для добавления комментариев к документу. На вкладке должен отображаться пользователь, внесший комментарий, дата внесения комментария и текст комментария.

Вкладка «Ссылки», предназначенная для отображения карточек, связанных с текущей, а также внешних гиперссылок и ссылок на файлы, связанные с карточкой документа.

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

Вкладка «История» предназначена для просмотра журнала работы с карточкой. На вкладке в табличной форме должны быть отображены события, произошедшие с карточкой документа – редактирование атрибутов карточки, чтение приложенных файлов, изменение состояний документа.

1.2.4. Входящий документ

Документ вида «Входящий» должен быть предназначен для хранения в системе файлов входящей корреспонденции, то есть для той документации, которая поступила в систему от контрагентов – внешних организаций.

Вкладка «Основная» предназначена для заполнения данных о документе.

Сценарии работы с карточкой Входящего документа

Сценарий 1. Регистрация документа и отправка на рассмотрение.
Роль: Регистратор

При получении Входящего письма Регистратор создает в Системе карточку Входящего документа и заполняет в ней атрибуты, описанные в Табл. 6.

Табл. 6 Перечень атрибутов карточки Входящего документа

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

После заполнения всех необходимых полей Регистратор отправляет документ Получателям нажатием на кнопку «На рассмотрение». В случае, если необходимо внести в Систему документ, уже рассмотренный и исполненный в бумажном виде, нажимает кнопку «Зарегистрировать без рассмотрения».

• На рассмотрение – система проверяет, что к карточке приложен файл. Если файл приложен, в системе Получателям формируется задание на рассмотрение Входящего документа. Также отправляется уведомление на электронную почту о том, что в СЭД поступило задание на рассмотрение Входящего документа.
• Зарегистрировать без рассмотрения – задания в системе не направляются. Система проверяет наличие приложенного файла, а также заполнение полей «№ документа» и «Дата регистрации». После регистрации система отображает Входящий документ в Журнале регистрации.

Сценарий 2. Отмена документа
Роль: Регистратор

В случае, если Регистратор допустил ошибку при отправке документа на рассмотрение (вложил неправильный скан, неправильно указал Получателей в и т.д.), либо если документ потерял актуальность, регистратор может отменить это действие, нажав на кнопку «Отменить».

При этом Система запрашивает обязательный ввод причины отмены, который после ввода будет отображаться на вкладке «Комментарии» карточки Входящего документа.

После отмены документа все активные задания по нему отзываются.

Если документ утратил актуальность, Регистратор может оставить его в отмененном состоянии. Если регистратор допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть в подготовку».

После нажатия на кнопку «Вернуть в подготовку» Регистратор может отредактировать значения атрибутов, а также приложенные файлы, и заново отправить документ Получателям.

Сценарий 3. Рассмотрение документа
Роль: Адресат, Помощник адресата

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

После этого завершает задание на рассмотрение по кнопке «Рассмотрен». Если документ не требует исполнения, Получатель может завершить задание, не расписывая по нему резолюцию.

После завершения задания на рассмотрение Входящего документа, если по документу было создана резолюция, Система отображает документ в реестре Входящих документов на исполнении. Если задание на рассмотрение было завершено без резолюции, Система отображает документ в журнале Входящих документов.

Сценарий 4. Исполнение документа
Роль: Исполнитель поручения

Процесс работы с Поручениями идентичен для всех видов документов.

Если в процессе исполнения поручения по Входящему документу необходимо создать Исходящий документ в ответ, исполнитель поручения создает связанную карточку Исходящего документа по кнопке «Создать Исходящий». Входящий и Исходящий документ при этом связываются двусторонними ссылками, а в созданной карточке Исходящего автоматически предзаполняются поля таблицы «Получатели»: Организация» - значением из поля «Контрагент» Входящего, «Конт. лицо» - значением из поля «Отправитель», «Телефон» и «E-mail» должны быть заполнены телефоном и e-mail’ом Организации-получателя (если они заполнены в справочнике).

После выполнения всех заданий по Поручению, расписанному Адресатом Входящего документа, Входящий документ отображается в Журнале Входящих документов как исполненный.

Сценарий 5. Отправка на ознакомление

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

В системе указанным сотрудникам отправляется задание на ознакомление с документами. Исполнителям заданий предоставляются права на просмотр карточки Входящего документа.

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

• Автор – сотрудник, создавший карточку, или его заместитель и входящий в группу «Отдел документооборота»;
• Регистратор – сотрудник, указанный в поле «Регистратор» карточки, или его заместитель и входящий в группу «Отдел документооборота»;
• Получатель – сотрудники, указанные в поле «Получатели» карточки документа, или их заместители;
• Руководители – сотрудники, которые являются руководителями Регистратора, Получателей, или их заместители;
• Участник связанной карточки – сотрудник, являющийся инициатором или исполнителем задания связанной карточки;
• Участник задания по документу – сотрудник, являющийся исполнителем задания по документу, или его заместитель;
• Отдел документооборота – сотрудники, или их заместители, входящие в группу «Отдел документооборота».
• Администратор – сотрудник из группы «Администраторы УД».

1.2.5. Исходящий документ

Документ вида «Исходящий» должен быть предназначен для хранения в системе исходящей корреспонденции, то есть для тех документов, которые должны быть отправлены контрагентам – внешним организациям.

Сценарии работы с карточкой Исходящего документа

Сценарий 1. Подготовка проекта документа
Роль: Инициатор документа

Инициатором в Системе создается карточка Исходящего документа одним из способов:

• По кнопке «Создать документ»;
• По шаблону, если Исходящий документ является типовым;
• Из карточки Входящего документа, если Исходящий является ответом на Входящий.

В рамках формирования Инициатор заполняет поля карточки Исходящего документа, описанные в Табл. 7.

Табл. 7 Перечень атрибутов карточки Исходящего документа

После заполнения всех необходимых полей Инициатор направляет Исходящий документ по маршруту: На согласование – если согласующие заполнены, в системе формируются задания на Согласование (Сценарий 3), если согласующие не заполнены, формируется задание на подписание (Сценарий 5). Также при отправке на согласование Система должна проверять, что к карточке приложен хотя бы один файл.

В системе предусмотрена возможность установки срока исполнения заданий для каждого этапа маршрута согласования. Срок исполнения должен рассчитываться в рабочих днях исходя из настроенного бизнес-календаря. При отправке документа на новый цикл согласования срок должен быть пересчитан.

Сценарий 2. Отмена согласования Исходящего документа
Роль: Инициатор документа

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

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

После отмены документа все активные задания по данному документу отзываются.

Если документ утратил актуальность, можно оставить документ в состоянии «Отменен». Если Инициатор допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть в подготовку».

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

Инициатор редактирует карточку и заново отправляет ее по маршруту нажатием кнопки «На согласование». На согласование – если согласующие заполнены, в системе формируются задания на Согласование, если согласующие не заполнены, формируется задание на подписание.

Сценарий 3. Согласование документа
Роль: согласующий

Все согласующие параллельно или последовательно получают задание на согласование документа. Согласующие ознакамливаются с проектом Исходящего письма.

При необходимости согласующие могут направить документ на согласование своим подчиненным сотрудникам.

При необходимости согласующие вносят в согласуемый документ правки в режиме рецензирования и принимают решение по документу, нажав одну из кнопок в задании:

• Согласовано – Система ожидает завершения остальных заданий на согласование, после чего направляет документ на подписание в случае, если все согласующие приняли положительное решение, либо на доработку Исполнителю в случае, если хотя бы один согласующий принял отрицательное решение.
• Не согласовано - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, ожидает завершения остальных заданий на согласование, после чего в Системе формируется задание для Инициатора на доработку Исходящего документа (Сценарий 4).

При завершении согласования Исходящего документа Инициатору в зависимости от решения согласующих отправляется уведомление на электронную почту либо о том, что Исходящий документ согласован и направлен на подписание, либо о том, что он поступил на доработку.

Сценарий 4. Доработка проекта Исходящего документа
Роль: Инициатор

В случае, если хотя бы один из согласующих принял решение «Не согласовано», после завершения заданий всеми согласующими Инициатору в Системе отправляется задание на доработку документа.

Инициатор ознакамливается с результатами согласования одним или несколькими из следующих способов:

• В Листе согласования можно ознакомиться с решениями и замечаниями основных согласующих на последнем цикле согласования;
• В Истории согласования можно ознакомиться с решениями и замечаниями всех согласующих (в том числе подчиненных согласующих в случае, если основные согласующие направляли документ на подчиненное согласование) на всех циклах согласования;
• В версиях файлов можно ознакомиться с правками согласующих, внесенными согласующими в режиме рецензирования.
• После ознакомления с замечаниями согласующих и корректировки текста документа, Инициатор завершает задание на доработку с одним из следующих вариантов:
• На новый цикл согласования – в общем случае после корректировки текста документа он должен быть направлен на повторный цикл согласования. При выборе данного варианта всем согласующим повторно отправятся задания на согласование (Сценарий 3).
• На подписание – в случае, если у согласующих есть непримиримые замечания, решение может быть эскалировано на подписанта данного документа, для этого Исполнитель выбирает вариант «На подписание». В этом случае Подписанту в системе будет создано задание на подписание (Сценарий 5).
• Снять с согласования – Исполнитель выбирает данный вариант в случае, если подписант документа принял решение об утрате актуальности данного документа и прекращении работы с ним.

Сценарий 5. Подписание Исходящего документа
Роль: Подписант

В системе подписанту приходит задание на подписание Исходящего документа в одном из следующих случаев:

• Все согласующие приняли решение «Согласовано»;
• В карточке документа не были указаны согласующие;
• Решение по документу было эскалировано на подписанта в случае, если у Согласующих возникли непримиримые разногласия (решение об эскалации принимает Инициатор документа).

Подписант может ознакомиться с решениями и комментариями согласующих в Листе согласования. После ознакомления с текстом документа, а также с Листом согласования, Подписант завершает задание на подписание с одним из вариантов:

• Подписано – система направляет задание на регистрацию Исходящего документа сотрудникам отдела документооборота.
• На доработку - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего в Системе формируется задание для Исполнителя о необходимости доработки Исходящего документа.

Сценарий 6. Регистрация Исходящего документа
Роль: Сотрудники отдела документооборота

Сотрудники отдела документооборота получают задание на регистрацию Исходящего документа.

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

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

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

После данных действий сотрудник завершает задание на регистрацию, нажав на кнопку «Завершить».

Сценарий 7. Отправка Исходящего документа получателям
Роль: сотрудники отдела документооборота

Сотрудник отдела документооборота переходит в Системе в папку Исходящие документы/К отправке, где отражается реестр зарегистрированных, но еще не отправленных Исходящих документов.

После фактической отправки документа одним из способов, сотрудник отдела документооборота открывает карточку и нажимает кнопку «Документ отправлен». В случае, если был выбран способ отправки «Почта России» система запрашивает обязательной ввод трек-номера отправления.

Сценарий 8. Отправка Исходящего документа на ознакомление

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

В системе указанным сотрудникам отправляется задание на ознакомление с документами. Исполнителям заданий предоставляются права на чтение карточки Исходящего документа.

Сценарий 9. Регистрация Исходящего документа без согласования
Роль: Инициатор документа, сотрудники отдела документооборота

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

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

После регистрации без согласования никакие задания в системе не направляются, Исходящий документ появляется в Журнале регистрации.

Сценарий 10. Исполнение документа
Роль: Исполнитель поручения

Процесс работы с Поручениями идентичен для всех видов документов.

Для карточек исходящих документов должны быть настроены следующие роли:

• Автор – сотрудник, создавший карточку, или его заместитель;
• Инициатор – сотрудник, создавший документ (указан в поле «Инициатор» карточки);
• Согласующий – сотрудник, указанный в поле «Согласующие» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Подписант – сотрудник, указанный в поле «Подписант» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Руководители – сотрудники, которые являются руководителями Инициатора, Согласующих, Подписанта и сотрудников группы «Отдел документооборота», или их заместители;
• Участник связанной карточки – сотрудник, являющийся регистратором, исполнителем задания или получателем связанной карточки;
• Участник задания по документу – сотрудник, являющийся исполнителем задания по документу, или его заместитель;
• Отдел документооборота – сотрудники, или их заместители, входящие в группу «Отдел документооборота»;
• Администратор - сотрудник из группы «Администраторы».

1.2.6. Служебная записка

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

Сценарий работы с карточкой Служебной записки

Сценарий 1. Создание Служебной записки
Роль: Инициатор документа

Инициатором в Системе создается карточка Служебной записки одним из способов:

• По кнопке «Создать документ»;
• По шаблону, если Служебная записка является типовой.

В рамках формирования Инициатор заполняет поля карточки Служебной записки, описанные в Табл. 8.

Табл. 8 Перечень атрибутов Служебной записки

После заполнения всех необходимых полей Инициатор направляет Служебную записку по маршруту:

На согласование – при отправке на согласование Система должна проверять, что к карточке приложен хотя бы один файл. Если согласующие заполнены, в системе формируются задания на Согласование (Сценарий 3), если согласующие не заполнены, формируется задание на подписание (Сценарий 5). При отправке Служебной записки по маршруту ей автоматически должен быть выдан регистрационный номер в соответствии с правилом нумерации.

В системе предусмотрена возможность установки срока исполнения заданий для каждого этапа маршрута согласования. Срок исполнения должен рассчитываться в рабочих днях исходя из настроенного бизнес-календаря. При отправке документа на новый цикл согласования срок должен быть пересчитан.

Сценарий 2. Отмена согласования Служебной записки
Роль: Инициатор документа

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

При нажатии на кнопку «Отменить» система запрашивает обязательный ввод причины отмены документа. Причина отмены документа будет отображаться на вкладке «Комментарии» карточки Служебной записки.

После отмены документа все активные задания по данному документу отзываются.

Если документ утратил актуальность, можно оставить документ в состоянии «Отменен». Если Инициатор допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть в подготовку».

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

Инициатор редактирует карточку и заново отправляет ее по маршруту нажатием кнопки «На согласование».

На согласование – если согласующие заполнены, в системе формируются задания на Согласование, если согласующие не заполнены, формируется задание на подписание.

Сценарий 3. Согласование документа
Роль: Согласующий

Все согласующие параллельно или последовательно получают задание на согласование документа. Согласующие ознакамливаются с проектом Служебной записки.

При необходимости согласующие могут направить документ на согласование своим подчиненным сотрудникам.

При необходимости согласующие вносят в согласуемый документ правки в режиме рецензирования и принимают решение по документу, нажав одну из кнопок в задании:

• Согласовано – Система ожидает завершения остальных заданий на согласование, после чего направляет документ на подписание в случае, если все согласующие приняли положительное решение, либо на доработку Исполнителю в случае, если хотя бы один согласующий принял отрицательное решение.
• Не согласовано - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, ожидает завершения остальных заданий на согласование, после чего в Системе формируется задание для Инициатора на доработку Служебной записки (Сценарий 4).

При завершении согласования Исходящего документа Инициатору в зависимости от решения согласующих отправляется уведомление на электронную почту либо о том, что Исходящий документ согласован и направлен на подписание, либо о том, что он поступил на доработку.

Сценарий 4. Доработка проекта Служебной записки
Роль: Инициатор

В случае, если хотя бы один из согласующих принял решение «Не согласовано», после завершения заданий всеми согласующими Инициатору в Системе отправляется задание на доработку документа.

Инициатор ознакамливается с результатами согласования одним или несколькими из следующих способов:

• В Листе согласования можно ознакомиться с решениями и замечаниями основных согласующих на последнем цикле согласования;
• В Истории согласования можно ознакомиться с решениями и замечаниями всех согласующих (в том числе подчиненных согласующих в случае, если основные согласующие направляли документ на подчиненное согласование) на всех циклах согласования;
• В версиях файлов можно ознакомиться с правками согласующих, внесенными согласующими в режиме рецензирования.
• После ознакомления с замечаниями согласующих и корректировки текста документа, Инициатор завершает задание на доработку с одним из следующих вариантов:
• На новый цикл согласования – в общем случае после корректировки текста документа он должен быть направлен на повторный цикл согласования. При выборе данного варианта всем согласующим повторно отправятся задания на согласование (Сценарий 3).
• На подписание – в случае, если у согласующих есть непримиримые замечания, решение может быть эскалировано на подписанта данного документа, для этого Исполнитель выбирает вариант «На подписание». В этом случае Подписанту в системе будет создано задание на подписание (Сценарий 5).
• Снять с согласования – Исполнитель выбирает данный вариант в случае, если подписант документа принял решение об утрате актуальности данного документа и прекращении работы с ним.

Сценарий 5. Подписание Служебной записки
Роль: Подписант

В системе подписанту приходит задание на подписание Служебной записки в одном из следующих случаев:

• Все согласующие приняли решение «Согласовано»;
• В карточке документа не были указаны согласующие;
• Решение по документу было эскалировано на подписанта в случае, если у Согласующих возникли непримиримые разногласия (решение об эскалации принимает Инициатор документа).

Подписант может ознакомиться с решениями и комментариями согласующих в Листе согласования. После ознакомления с текстом документа, а также с Листом согласования, Подписант завершает задание на подписание с одним из вариантов:

• Подписано – система направляет задание на исполнение Служебной записки сотрудникам из поля «Исполнители».
• На доработку - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего в Системе формируется задание для Исполнителя о необходимости доработки Служебной записки.

Сценарий 6. Исполнение Служебной записки
Роль: исполнители Служебной записки

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

Когда необходимые действия по исполнению Служебной записки выполнены, исполнители завершают задание, нажатием на кнопку «Завершить». Система отражает Служебную записку в Журнале исполненных Служебных записок.

Сценарий 7. Отправка Служебной записки на ознакомление

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

В системе указанным сотрудникам отправляется задание на ознакомление с документами. Исполнителям заданий предоставляются права на чтение карточки Служебной записки.

Сценарий 8. Регистрация Служебной записки без согласования
Роль: Инициатор документа, сотрудники отдела документооборота

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

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

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

Для карточек служебных записок должны быть настроены следующие роли:

• Автор – сотрудник, создавший карточку, или его заместитель;
• Инициатор – сотрудник, создавший документ (указан в поле «Инициатор» карточки);
• Согласующий – сотрудник, указанный в поле «Согласующие» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Подписант – сотрудник, указанный в поле «Подписант» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Руководители – сотрудники, которые являются руководителями Инициатора, Согласующих, Подписанта и сотрудников группы «Отдел документооборота», или их заместители;
• Участник связанной карточки – сотрудник, являющийся регистратором, исполнителем задания или получателем связанной карточки;
• Участник задания по документу – сотрудник, являющийся исполнителем задания по документу, или его заместитель (должна быть использована стандартная роль из модуля Управление документами);
• Отдел документооборота – сотрудники, или их заместители, входящие в группу «Отдел документооборота»;
• Администратор - сотрудник из группы «Администраторы».

1.2.7. Организационно-распорядительный документ

Документ вида «Организационно-распорядительный» (ОРД) должен быть предназначен для документирования распорядительной деятельности организации. Подвиды ОРД должны иметь возможность настройки с использованием дополнительного справочника видов ОРД.

Сценарий работы с Распорядительными документами

Сценарий 1. Создание Распорядительного документа
Роль: Инициатор документа

Инициатором в Системе создается карточка Распорядительного документа одним из способов:

• По кнопке «Создать документ»;
• По шаблону, если Распорядительный документ является типовым.

В рамках формирования Инициатор заполняет поля карточки Распорядительного документа, описанные в Табл. 9.

Табл. 9 Перечень атрибутов Распорядительного документа

После заполнения всех необходимых полей Инициатор направляет Распорядительный документ по маршруту:

• На согласование – если согласующие заполнены, в системе формируются задания на Согласование (Сценарий 3), если согласующие не заполнены, формируется задание на подписание (Сценарий 5). Также при отправке на согласование Система должна проверять, что к карточке приложен хотя бы один файл.

В системе предусмотрена возможность установки срока исполнения заданий для каждого этапа маршрута согласования. Срок исполнения должен рассчитываться в рабочих днях исходя из настроенного бизнес-календаря. При отправке документа на новый цикл согласования срок должен быть пересчитан.

Сценарий 2. Отмена согласования Распорядительного документа
Роль: Инициатор документа

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

При нажатии на кнопку «Отменить» система запрашивает обязательный ввод причины отмены документа. Причина отмены документа будет отображаться на вкладке «Комментарии» карточки Распорядительного документа.

После отмены документа все активные задания по данному документу отзываются.

Если документ утратил актуальность, можно оставить документ в состоянии «Отменен». Если Инициатор допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть в подготовку».

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

Инициатор редактирует карточку и заново отправляет ее по маршруту нажатием кнопки «На согласование».

• На согласование – если согласующие заполнены, в системе формируются задания на Согласование, если согласующие не заполнены, формируется задание на подписание.

Сценарий 3. Согласование документа
Роль: Согласующий

Согласующие параллельно или последовательно получают задание на согласование документа. Согласующие ознакамливаются с проектом Распорядительного документа.

При необходимости согласующие могут направить документ на согласование своим подчиненным сотрудникам.

При необходимости согласующие вносят в согласуемый документ правки в режиме рецензирования и принимают решение по документу, нажав одну из кнопок в задании:

• Согласовано – Система ожидает завершения остальных заданий на согласование, после чего направляет документ на подписание в случае, если все согласующие приняли положительное решение, либо на доработку Исполнителю в случае, если хотя бы один согласующий принял отрицательное решение.
• Не согласовано - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, ожидает завершения остальных заданий на согласование, после чего в Системе формируется задание для Инициатора на доработку Распорядительного документа (Сценарий 4).

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

Сценарий 4. Доработка проекта Распорядительного документа
Роль: Инициатор

В случае, если хотя бы один из согласующих принял решение «Не согласовано», после завершения заданий всеми согласующими Инициатору в Системе отправляется задание на доработку документа.

Инициатор ознакамливается с результатами согласования одним или несколькими из следующих способов:

• В Листе согласования можно ознакомиться с решениями и замечаниями основных согласующих на последнем цикле согласования;
• В Истории согласования можно ознакомиться с решениями и замечаниями всех согласующих (в том числе подчиненных согласующих в случае, если основные согласующие направляли документ на подчиненное согласование) на всех циклах согласования;
• В версиях файлов можно ознакомиться с правками согласующих, внесенными согласующими в режиме рецензирования.
• После ознакомления с замечаниями согласующих и корректировки текста документа, Инициатор завершает задание на доработку с одним из следующих вариантов:
• На новый цикл согласования – в общем случае после корректировки текста документа он должен быть направлен на повторный цикл согласования. При выборе данного варианта всем согласующим повторно отправятся задания на согласование (Сценарий 3).
• На подписание – в случае, если у согласующих есть непримиримые замечания, решение может быть эскалировано на подписанта данного документа, для этого Исполнитель выбирает вариант «На подписание». В этом случае Подписанту в системе будет создано задание на подписание (Сценарий 5).
• Снять с согласования – Исполнитель выбирает данный вариант в случае, если подписант документа принял решение об утрате актуальности данного документа и прекращении работы с ним.

Сценарий 5. Подписание Распорядительного документа
Роль: Подписант

В системе подписанту приходит задание на подписание Распорядительного документа в одном из следующих случаев:

Все согласующие приняли решение «Согласовано»;

В карточке документа не были указаны согласующие;

Решение по документу было эскалировано на подписанта в случае, если у Согласующих возникли непримиримые разногласия (решение об эскалации принимает Инициатор документа).

Подписант может ознакомиться с решениями и комментариями согласующих в Листе согласования. После ознакомления с текстом документа, а также с Листом согласования, Подписант завершает задание на подписание с одним из вариантов:

• Подписано – система направляет задание на регистрацию Распорядительного документа сотрудникам отдела документооборота.
• На доработку - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего в Системе формируется задание для Исполнителя о необходимости доработки Распорядительного документа.

Сценарий 6. Регистрация Распорядительного документа
Роль: Сотрудники отдела документооборота

Сотрудники отдела документооборота получают задание на регистрацию Распорядительного документа.

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

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

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

После данных действий сотрудник завершает задание на регистрацию, нажав на кнопку «Завершить».

Сценарий 7. Ознакомление с Распорядительным документом

После завершения регистрации Распорядительного документа всем сотрудникам из поля «Ознакомление» формируются задания на ознакомление с документом.

Дополнительно, на этапах «На согласовании», «На доработке», «На подписании», «Подписан», «Зарегистрирован» любой участник карточки может отправить Распорядительный документ на ознакомление заинтересованным лицам. Сотрудник нажимает на кнопку «На ознакомление», заполняет сотрудников, которым необходимо отправить задание, срок ознакомления, при необходимости указывает комментарий.

В системе указанным сотрудникам отправляется задание на ознакомление с документами. Исполнителям заданий предоставляются права на чтение карточки Распорядительного документа.

Сценарий 8. Исполнение Распорядительного документа
Роль: Исполнители Распорядительного документа

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

Процесс работы с Поручениями идентичен для всех видов документов.

Сценарий 9. Регистрация Распорядительного документа без согласования
Роль: Инициатор документа, сотрудники отдела документооборота

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

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

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

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

• Автор – сотрудник, создавший карточку, или его заместитель;
• Инициатор (И) – сотрудник, создавший документ (указан в поле «Инициатор» карточки);
• Согласующий – сотрудник, указанный в поле «Согласующие» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Подписант – сотрудник, указанный в поле «Подписант» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Руководители – сотрудники, которые являются руководителями Инициатора, Согласующих, Подписанта и сотрудников группы «Отдел документооборота», или их заместители;
• Участник связанной карточки – сотрудник, являющийся регистратором, исполнителем задания или получателем связанной карточки;
• Участник задания по документу – сотрудник, являющийся исполнителем задания по документу, или его заместитель (должна быть использована стандартная роль из модуля Управление документами);
• Отдел документооборота – сотрудники, или их заместители, входящие в группу «Отдел документооборота»;
• Администратор - сотрудник из группы «Администраторы».

1.2.8. Договорной документ

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

Сценарии работы с Договорными документами

Сценарий 1. Создание Договорного документа
Роль: Инициатор документа

Инициатором создается карточка Договорного документа одним из способов:

• По кнопке «Создать документ»;
• По шаблону, если Договорной документ является типовым.

В рамках формирования Инициатор заполняет поля карточки Распорядительного документа, описанные в Табл. 10.

Табл. 10 Перечень атрибутов Договорного документа

После заполнения всех необходимых полей Инициатор направляет Договорной документ по маршруту:

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

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

В системе предусмотрена возможность установки срока исполнения заданий для каждого этапа маршрута согласования. Срок исполнения должен рассчитываться в рабочих днях исходя из настроенного бизнес-календаря. При отправке документа на новый цикл согласования срок должен быть пересчитан.

Сценарий 2. Отмена согласования Договорного документа
Роль: Инициатор документа

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

При нажатии на кнопку «Отменить» система запрашивает обязательный ввод причины отмены документа. Причина отмены документа будет отображаться на вкладке «Комментарии» карточки Договорного документа.

После отмены документа все активные задания по данному документу отзываются.

Если документ утратил актуальность, можно оставить документ в состоянии «Отменен». Если Инициатор допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть в подготовку».

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

Инициатор редактирует карточку и заново отправляет ее по маршруту нажатием кнопки «На согласование».

• На согласование – если согласующие заполнены, в системе формируются задания на Согласование, если согласующие не заполнены, формируется задание на подписание.

Сценарий 3. Согласование документа
Роль: Согласующий

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

При необходимости согласующие могут направить документ на согласование своим подчиненным сотрудникам.

При необходимости согласующие вносят в согласуемый документ правки в режиме рецензирования и принимают решение по документу, нажав одну из кнопок в задании:

• Согласовано – Система ожидает завершения остальных заданий на согласование, после чего направляет документ на подписание (Сценарий 5) в случае, если все согласующие приняли положительное решение, либо на доработку (Сценарий 4) Инициатору в случае, если хотя бы один согласующий принял отрицательное решение.
• Не согласовано - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, ожидает завершения остальных заданий на согласование, после чего в Системе формируется задание для Инициатора на доработку Договорного документа (Сценарий 4).

При завершении согласования Договорного документа, Инициатору в зависимости от решения согласующих отправляется уведомление на электронную почту либо о том, что Договорной документ согласован и направлен на подписание, либо о том, что он поступил на доработку.

Сценарий 4. Доработка проекта Договорного документа
Роль: Инициатор

В случае, если хотя бы один из согласующих принял решение «Не согласовано», после завершения заданий всеми согласующими Инициатору в Системе отправляется задание на доработку документа.

Инициатор ознакамливается с результатами согласования одним или несколькими из следующих способов:

• В Листе согласования можно ознакомиться с решениями и замечаниями основных согласующих на последнем цикле согласования;
• В Истории согласования можно ознакомиться с решениями и замечаниями всех согласующих (в том числе подчиненных согласующих в случае, если основные согласующие направляли документ на подчиненное согласование) на всех циклах согласования;
• В версиях файлов можно ознакомиться с правками согласующих, внесенными согласующими в режиме рецензирования.
• После ознакомления с замечаниями согласующих и корректировки текста документа, Инициатор завершает задание на доработку с одним из следующих вариантов:
• На новый цикл согласования – в общем случае после корректировки текста документа он должен быть направлен на повторный цикл согласования. При выборе данного варианта всем согласующим повторно отправятся задания на согласование (Сценарий 3).
• На подписание – в случае, если у согласующих есть непримиримые замечания, решение может быть эскалировано на подписанта данного документа, для этого Исполнитель выбирает вариант «На подписание». В этом случае Подписанту в системе будет создано задание на подписание (Сценарий 5).
• Снять с согласования – Исполнитель выбирает данный вариант в случае, если подписант документа принял решение об утрате актуальности данного документа и прекращении работы с ним.

Сценарий 5. Подписание Договорного документа
Роль: Подписант

В системе подписанту приходит задание на подписание Договорного документа в одном из следующих случаев:

Все согласующие приняли решение «Согласовано»;

В карточке документа не были указаны согласующие;

Решение по документу было эскалировано на подписанта в случае, если у Согласующих возникли непримиримые разногласия (решение об эскалации принимает Инициатор документа).

Подписант может ознакомиться с решениями и комментариями согласующих в Листе согласования. После ознакомления с текстом документа, а также с Листом согласования, Подписант завершает задание на подписание с одним из вариантов:

• Подписано:
  • Если в карточке установлен флаг «Договор подписан контрагентом», система направляет задание на регистрацию Договорного документа сотрудникам отдела документооборота (Сценарий 7).
  • Если в карточке не установлен флаг «Договор подписан контрагентом», система направляет Инициатору задание на подписание Договора у контрагента (Сценарий 6).
• На доработку - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего в Системе формируется задание для Исполнителя о необходимости доработки Распорядительного документа (Сценарий 4).
• Отказано – при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего документ переходит в состояние «Отменен».

Сценарий 6. Подписание Договорного документа контрагентом
Роль: Инициатор

В системе Инициатору приходит задание на подписание Договорного документа у контрагента. Инициатор передает два экземпляра подписанных со стороны его Организации контрагенту на подписание.

Когда от контрагента получен ответ, Инициатор завершает задание на подписание контрагентом с одним из вариантом:

• Подписано – данный вариант выбирается в случае, если контрагент подписал Договорной документ. В этом случае Инициатор либо вкладывает в карточку скан Договорного документа, подписанный двумя сторонами, самостоятельно, либо передает оригинал, подписанный двумя сторонами, в отдел документооборота. Система направляет задание на регистрацию Договорного документа сотрудникам отдела документооборота.

• На новый цикл согласования – данный вариант выбирается в случае, если контрагент не подписал договор и предоставил новую версию. В этом случае Инициатор вкладывает новую версию Договора в карточку и направляет новую версию на новый цикл согласования всем участникам маршрута. В системе направляются задания на согласование документа (параллельно или последовательно), если согласующие не заполнены, направляется задание на подписание. Если установлен признак «Согласование с руководителем» перед согласованием направляется задание на согласование непосредственному руководителю Инициатора.

• Отказано - при выборе данного варианта Система запрашивает ввод обязательного текстового комментария, после чего документ переходит в состояние «Отменен».

Сценарий 7. Регистрация Договорного документа
Роль: Сотрудники отдела делопроизводства

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

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

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

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

После данных действий сотрудник завершает задание на регистрацию, нажав на кнопку «Завершить».

Договорной документ меняет свой статус на «Заключен» и отображается в Журнале заключенных Договоров.

Сценарий 8. Ознакомление с Договорными документами
Роль: любой сотрудник, имеющий доступ к карточке Договорного документа

На этапах «На согласовании», «На подписании», «На доработке», «На подписании контрагентом», «Заключен», «Исполнен» Договорной документ можно отправить на ознакомление заинтересованным сотрудникам.

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

В системе указанным сотрудникам отправляется задание на ознакомление с документами. Исполнителям заданий предоставляются права на чтение карточки Договорного документа.

Сценарий 9. Регистрация Договорного документа без согласования
Роль: Инициатор документа, сотрудники отдела документооборота

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

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

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

Сценарий 10. Контроль за истечением сроков действия Договора
Роль: Инициатор

За 30 календарных дней до истечения срока окончания этапа, а также окончания срока действия Договора, Инициатору на электронную почту отправляется уведомление о том, что срок действия Договора/этапа истекает через 30 дней.

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

• Если все обязательства по Договору исполнены, отмечает Договор как исполненный нажатием на кнопку «Договор исполнен».
• Создает Дополнительное соглашение о продлении сроков действия Договора. После того, как дополнительное соглашение заключено, Инициатор обновляет сроки действия в карточке Договора.

Сценарий 11. Исполнение Договорного документа
Роль: Исполнители Договорного документа

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

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

• Автор – сотрудник, создавший карточку, или его заместитель;
• Инициатор – сотрудник, создавший документ (указан в поле «Инициатор» карточки);
• Согласующий – сотрудник, указанный в поле «Согласующие» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Подписант – сотрудник, указанный в поле «Подписант» карточки документа, или его заместитель, а также сотрудники, которым делегировано задание или их заместители;
• Руководители – сотрудники, которые являются руководителями Инициатора, Согласующих, Подписанта и сотрудников группы «Отдел документооборота», или их заместители;
• Участник связанной карточки – сотрудник, являющийся регистратором, исполнителем задания или получателем связанной карточки;
• Участник задания по документу – сотрудник, являющийся исполнителем задания по документу, или его заместитель (должна быть использована стандартная роль из модуля Управление документами);
• Отдел документооборота – сотрудники, или их заместители, входящие в группу «Отдел документооборота»;
• Администратор - сотрудник из группы «Администраторы».

1.2.9. Групповое поручение

В системе предусмотрено создание групповых поручений по документам, а также инициативных групповых поручений.

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

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

Рис. 2 Структура объекта «Групповое поручение»

Сценарий 1. Создание поручения и отправка на исполнение
Роль: Автор поручения

Автор поручения создает карточку группового Поручения одним из способов, описанных выше, и заполняет поля карточки Поручения, описанные в Табл. 11.

Табл. 11 Перечень атрибутов Группового поручения

После заполнения всех необходимых полей Автор поручения отправляет его на исполнение, нажатием на кнопку «На исполнение»:

• На исполнение – в Системе сотрудникам, указанным в поле «Исполнители», формируются задания на исполнение (последовательно или параллельно).

Сценарий 2. Отзыв группового поручения с исполнения
Роль: Автор поручения

В случае, если Автор допустил ошибку при отправке группового Поручения на исполнение (неправильно указал Исполнителей, Срок и т.д.), либо если Поручение больше не нужно выполнять, Автор может отменить это действие, нажав на кнопку «Отозвать» в карточке группового Поручения.

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

Если Поручение больше не нужно выполнять, можно оставить его в состоянии «Отозвано». Если Автор допустил ошибку при подготовке Поручения, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть на редактирование».

После возврата Поручения на редактирование, карточка становится доступна для редактирования, и Автор может отредактировать любые ее атрибуты, в т.ч. Исполнителей, Контролера, Срок и т.д.

Автор редактирует Поручение и заново отправляет его на исполнение нажатием кнопки «На исполнение».

На исполнение – в Системе сотрудникам, указанным в поле «Исполнители», формируются задания на исполнение (последовательно или параллельно).

Сценарий 3. Направление запроса автору Поручения
Роль: Исполнитель поручения

Исполнитель получает в системе задание на Исполнение. В случае, если Поручение направлено данному исполнителю ошибочно, либо если требуются пояснения по Поручению или необходимо запросить перенос срока, Исполнитель может направить запрос Автору Поручения по кнопке «Запрос автору»:

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

После ввода комментария Автору группового Поручения в системе приходит задание на исполнение с запросом от исполнителя.

Сценарий 4. Рассмотрение запроса Автором Поручения
Роль: Автор поручения

Автор в системе получает задание на исполнение с запросом от Исполнителя. Автор ознакамливается с сутью запроса на вкладке «Комментарии» и может выполнить одно из следующих действий:

• Снять поручение с исполнения, если оно направлено этому Исполнителю ошибочно.
• Дать пояснения по выполнению задания, добавив комментарий на вкладке «Комментарии» и обратно направить задание Исполнителю по кнопке «Отправить».
• Изменить плановый срок выполнения задания и обратно направить задание Исполнителю по кнопке «Отправить».

Сценарий 5. Создание подчиненного группового поручения
Роль: Исполнитель поручения

При необходимости Исполнитель задания может создать групповое Поручение на своих подчиненных по кнопке «Подчиненное поручение».

Из родительского Поручения будут скопированы значения следующих атрибутов: Название, Срок исполнения, Важность, Содержание, Срок, отметки о необходимости контроля и приемки Поручения.

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

Когда поручение подготовлено отправляет его на исполнение нажатием на кнопку «На исполнение»:

На исполнение – в Системе сотрудникам, указанным в поле «Исполнители», формируются задания на исполнение (последовательно или параллельно). Сформированные задания будут отображаться в дереве исполнения как подчиненные к родительскому заданию, из которого они были созданы.

После отправки подчиненных поручений Исполнитель может завершить свое задание, когда его завершат подчиненные (Сценарий 7), либо не дожидаясь исполнения подчиненными (Сценарий 6).

Сценарий 6. Завершение задания на исполнение
Роль: Исполнитель задания

Чтобы завершить задание, Исполнитель заполняет текстовый отчет о задании (обязательно), а также прикладывает файл отчета или карточку системы в качестве отчета (опционально). Затем завершает задание по кнопке «Завершить».

«Завершить» - Система проверяет обязательность заполнения текстового отчета. Если в Поручении был установлен признак «Требуется приемка», Контролеру или Ответственному исполнителю отправляется задание на приемку результатов выполнения (Сценарий 8). Если признак приемки не был установлен, задание завершается.

Сценарий 7. Завершение задания на исполнение после завершения подчиненными
Роль: Исполнитель задания

Когда подчиненные завершат свои задания по данному Поручению, задание Исполнителя родительского задания отразится в папке «Завершено подчиненными».

Исполнитель переносит отчеты подчиненных Исполнителей в свое задание по кнопке «Перенести отчеты подчиненных», Система переносит в карточку задания Исполнителя текстовый отчет, а также файлы и карточки отчетов из всех завершенных подчиненными Исполнителями заданий.

При необходимости Исполнитель родительского задания редактирует перенесенные отчеты и завершает свое задание по кнопке «Завершить»:

«Завершить» - Система проверяет обязательность заполнения текстового отчета. Если в Поручении был установлен признак «Требуется приемка», Контролеру или Ответственному исполнителю отправляется задание на приемку результатов выполнения (Сценарий 8). Если признак приемки не был установлен, задание завершается.

Сценарий 8. Выполнение приемки задания на исполнение
Роль: Контролер поручения или Ответственный исполнитель

Приемку результатов выполнения Поручения осуществляет Контролер или Ответственный исполнитель в зависимости от параметров, указанных в групповом Поручении:

• В случае, если в групповом Поручении указан и Ответственный исполнитель, и Контролер и установлен признак «Требуется приемка», то на приемку Контролеру должно прийти только задание Ответственного исполнителя.
• В случае, если указан только Контролер и установлен признак «Требуется приемка», на приемку должны прийти задания всех исполнителей.
• В случае, если указан только Ответственный исполнитель и установлен признак «Требуется приемка», на приемку Ответственному исполнителю должны прийти задания соисполнителей.

У сотрудника, выполняющего приемку поручения, доступны 2 кнопки:

• «Принять» – переводит задание в состояние «Завершено», результаты выполнения считаются принятыми.
• «На доработку» - Система запрашивает обязательный ввод комментария (причины возврата на доработку). Введенный комментарий отражается на вкладке «Комментарии» карточки задания.

Сценарий 9. Доработка задания
Роль: Исполнитель задания

Исполнитель получает в системе задание на доработку документа, если Контролер или Ответственный исполнитель вернул его на доработку (Сценарий 8).

Исполнитель ознакамливается с причиной возврата на доработку на вкладке «Комментарии» карточки задания.

После этого Исполнитель редактирует отчеты о выполнении задания и завершает его по кнопке «Завершить»:

«Завершить» - Система проверяет обязательность заполнения текстового отчета. Если в Поручении был установлен признак «Требуется приемка», Контролеру или Ответственному исполнителю отправляется задание на приемку результатов выполнения (Сценарий 8). Если признак приемки не был установлен, задание завершается.

Для карточек заданий «На исполнение» должна быть предусмотрена ролевая модель доступа, разграничивающая доступ к операциям в карточке в зависимости от того, в какую роль входит пользователь, открывший карточку. Должны быть предусмотрены следующие роли:

• Автор – сотрудник, создавший задание (указан в поле «Автор» карточки задания), или его заместитель;
• Исполнитель – сотрудник, ответственный за исполнение задания (указан в поле «Исполнитель» карточки задания), или его заместитель;
• Контролёр – сотрудник, ответственный за проверку результатов исполнения задания (указан в поле «Контролёр» карточки задания), или его заместитель;
• Автор, исполнитель или контролер родительского задания (УРЗ) – сотрудник, который является автором исполнителем или контролером в родительском к текущему задании;
• Ответственный исполнитель – сотрудник, ответственный за исполнение поручения (указан в поле «Ответственный исполнитель» карточки поручения), или его заместитель;
• Все руководители– сотрудники, являющиеся руководителями автора, исполнителя или контролёра задания;
• Администратор – сотрудник, входящий в группу «Администраторы» справочника сотрудников. Роль должна быть сделана общей для всех заданий.

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

• Автор – сотрудник, указанный в поле «Автор» карточки группы заданий, либо в скрытом поле «Подготовил» карточки группы заданий.
• Читатель – сотрудники, указанные в полях «Автор», «Исполнители», «Контролер», а также их заместители.
• Администратор – сотрудник, входящий в группу «Администраторы» справочника сотрудников. Роль должна быть сделана общей для всех заданий.

1.2.10. Групповое Подчиненное согласование

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

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

Рис. 3 Структура объекта «Групповое подчиненное согласование»

Сценарий 1. Создание задания на подчиненное согласование
Роль: Основной согласующий

Чтобы создать групповое подчиненное согласование, основной Согласующий нажимает на кнопку «Подчиненное согласование» и заполняет атрибуты, приведенные в Табл. 12.

Табл. 12 Перечень атрибутов группового подчиненного согласования

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

«Отправить на исполнение» – система формирует задания на подчиненное согласование всем согласующим параллельно.

Сценарий 2. Отзыв с подчиненного согласования
Роль: Основной Согласующий

В случае, если Автор допустил ошибку при отправке заданий на подчиненное согласование (неправильно указал Исполнителей, срок и т.д. либо если передумал отправлять документ на подчиненное согласование, Автор может отозвать задания на подчиненное согласование нажатием на кнопку «Отозвать».

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

Если согласующий передумал направлять задания на подчиненное согласование, он может оставить их в отозванном состоянии. Если согласующий допустил ошибку при заполнении карточки, он может вернуть карточку на редактирование, нажав на кнопку «Вернуть на редактирование».

После нажатия на кнопку «Вернуть на редактирование» согласующий может отредактировать значения атрибутов, и заново отправить задание исполнителям.

Сценарий 3. Выполнение задания подчиненным согласующим
Роль: Подчиненный согласующий

Выполнение задания подчиненным согласующим происходит в обычном порядке.

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

Система ожидает завершения задания остальными согласующими. В случае, если это было последнее незавершенное задание на подчиненное согласование, отображает задание основного согласующего в отдельной папке Мои задания/Завершены подчиненные.

При этом при выборе варианта «Не согласовано» система запрашивает обязательный ввод комментария.

Сценарий 4. Выполнение задания основным согласующим
Роль: Основной Согласующий

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

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

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

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

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

Затем основной согласующий завершает свое задание, подчиненные задания при этом завершаются автоматически.

1. Настройка уведомлений

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

Уведомления должны обладать следующими возможностями:

• настройка шаблонов уведомлений;
• отправка уведомлений сотрудникам по настроенному шаблону из карточек или процессов;
• отправка уведомлений по настроенному расписанию рассылки;
• отправка уведомлений по согласованию и исполнению документов.

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

Табл. 13 Описание почтовых уведомлений

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

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

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

• Область вложений, в которой отображаются иконки файлов, приложенных к карточке документа, по которому создано задание;
• Тема письма - строка с описанием причины отправки письма, возможны варианты: «Для вас создано новое задание», «Вам поступил на согласование документ» и т.д.;

Содержание письма, в котором может присутствовать:

• информация о задании - область отображения атрибутов карточки Задание, в которой могут быть отображены атрибуты: Автор задания, назначенный Исполнитель, плановая Дата завершения и т.д.;
• область подсказок, в которой отображаются фразы-подсказки о порядке исполнения задания, например, «Для отклонения задания необходимо добавить комментарий в тексте ответного письма»;
• ссылка на карточку задания в системе.

1.3 Отчеты

В системе должны быть доступны два отчета для контроля за исполнением заданий. Отчеты должны быть настроены с использованием стандартных конструкторов: конструктором поисковых запросов и конструктором представлений.

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

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

Отчет «Просроченные задания». Отчет позволяет найти все просроченные задания определенного Исполнителя.

Отчет «Задания со сроком исполнения». Отчет позволяет найти задания по атрибутам: «Исполнитель», «Плановый срок исполнения (период с, по)», «Фактические срок исполнения (период с, по)».

В представление отчетов должны выводиться значения следующих атрибутов:

• Вид задания;
• Вид связанного документа;
• Тема документа;
• Рег. номер;
• № CЭД;
• Автор задания;
• Текущие исполнители задания;
• Дата отправки задания;
• Плановая дата завершения задания;
• Фактическая дата завершения задания;
• Состояние.

Функциональные границы ПО

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

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

Добавление до 3 новых справочников, наполняемых Заказчиком вручную.

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

Реализации дополнительной логики в связи с появлением новых полей в карточках документов. Например, логика по автоматическому заполнению поля на основании другого поля (при наличии четкой логики по правилам автозаполнения).

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

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

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

Изменение маршрутов движения документов. Для каждого вида документа должна быть обеспечена возможность настройки до 8 маршрутов.