The implementation of legal electronic documents

Considered in the article are the main problems of the electronic office management implementation as basis of eGoverment. Analyzed are the drawbacks of the legal framework regulating the electronic office management in Ukraine and the procedure is proposed for its specific modifications providing t...

Ausführliche Beschreibung

Gespeichert in:
Bibliographische Detailangaben
Datum:2015
Hauptverfasser: Melaschenko, A.O., Скарлат, О.С.
Format: Artikel
Sprache:Ukrainisch
Veröffentlicht: PROBLEMS IN PROGRAMMING 2015
Schlagworte:
Online Zugang:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/90
Tags: Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:Problems in programming
Завантажити файл: Pdf

Institution

Problems in programming
_version_ 1859502943960563712
author Melaschenko, A.O.
Скарлат, О.С.
author_facet Melaschenko, A.O.
Скарлат, О.С.
author_sort Melaschenko, A.O.
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
collection OJS
datestamp_date 2018-09-20T12:12:37Z
description Considered in the article are the main problems of the electronic office management implementation as basis of eGoverment. Analyzed are the drawbacks of the legal framework regulating the electronic office management in Ukraine and the procedure is proposed for its specific modifications providing the complete electronic documents lifecycle. Motivated is the necessity of the self-contained electronic documents and the main requirements are specified to the electronic documents and their internal structure.
first_indexed 2025-07-17T09:37:58Z
format Article
fulltext Інформаційні системи УДК 681.3:002.651.028(083.73) ІМПЛЕМЕНТАЦІЯ ЮРИДИЧНО ПРАВОМОЧНИХ ЕЛЕКТРОННИХ ДОКУМЕНТІВ А.О. Мелащенко, О.С. Скарлат Інститут кібернетики ім. В.М. Глушкова НАН України, Київ, проспект Академіка Глушкова, 40, тел.: (044) 526 3603, dep145@gmail.com Розглянуто основні проблеми впровадження електронного діловодства як основи електронного урядування. Проаналізовано недоліки чинної нормативно-методичної бази, що регулює електронне діловодство в Україні, та запропоновано порядок її конкретних змін для забезпечення повного життєвого циклу електронних документів. Обґрунтовано необхідність самодостатніх електронних документів та деталізовано основні вимоги щодо електронних документів, які призначені для довічного збереження. В статті подано приклад створення електронних документів у відповідності з чинним законодавством. Considered in the article are the main problems of the electronic office management implementation as basis of eGoverment. Analyzed are the drawbacks of the legal framework regulating the electronic office management in Ukraine and the procedure is proposed for its specific modifications providing the complete electronic documents lifecycle. Motivated is the necessity of the self-contained electronic documents and the main requirements are specified to the electronic documents and their internal structure. Вступ Прийняття концепції електронного урядування [1], провадження адміністративних реформ [2] та дані про проекти і пропозиції до проектів Національної програми інформатизації свідчить про стрімкі темпи впровадження державними органами систем електронного документообігу (ЕДО). Однак, відсутність чинної нормативно-правової бази, яка регулює вимоги до ЕДО призвела до побудови різнорідних систем, які у перспективі мають масштабуватись до систем електронного урядування згідно з вимогами основоположних Законів України [3–4]. У статті розглянуто сучасний стан, ідентифіковано проблеми і запропоновано шляхи їх вирішення при розбудові основної складової електронних бізнесів, зокрема, електронного урядування – електронного діловодства. Сутність «електронного урядування» Згідно з [1] «Електронне урядування – форма організації державного управління, яка сприяє підвищенню ефективності, відкритості та прозорості діяльності органів державної влади та органів місцевого самоврядування з використанням інформаційно-телекомунікаційних технологій для формування нового типу держави, орієнтованої на задоволення потреб громадян» та «Головною складовою електронного урядування є електронний уряд – єдина інфраструктура міжвідомчої автоматизованої інформаційної взаємодії органів державної влади та органів місцевого самоврядування між собою, з громадянами і суб'єктами господарювання». Останню складову більш детально викладено у [5]: «Інфраструктура інформаційного суспільства має забезпечити дві складові: 1) подання даних; 2) засоби довіри до цих даних» (рис. 1). Проблеми, які пов’язані зі специфічними для України проблемами розбудови Національної системи електронної цифрового підпису (НСЕЦП), не є предметом цієї статті, їх докладно викладено у [5]. Саме НСЕЦП, як технологічна підтримка Закону України «Про електронний цифровий підпис» [3], забезпечує довіру (другу складову) при розбудові електронного урядування. Предметом статті є розгляд першої складової електронних бізнесів (інфраструктури) – подання даних. Інфраструктура Інформаційного суспільства Подання даних Довіра PKI QPKI OpenXML ODF XBRL UBL Тощо Рис. 1. Базові складові інформаційного суспільства Електронне урядування, як будь-який електронний бізнес, розглядається як обмін правомочними електронними документами (ЕД) у поняттях Закону України «Про електронні документи та електронний документообіг» [4]. Згідно з Законом України [4] електронні документи, що циркулюють у системах електронного документообігу (СЕД), мають виконувати, зокрема, наступні вимоги: «строк зберігання електронних документів на електронних носіях інформації повинен бути не меншим від строку, встановленого законодавством для відповідних документів на папері», тобто виконувати наказ Головного архівного управління при Кабінеті Міністрів України № 41 від 20.07.98 «Про затвердження Переліку типових документів», а це мінімум 3 роки; ©А.О. Мелащенко, О.С. Скарлат, 2012 ISSN 1727-4907. Проблеми програмування. 2012. № 2-3. Спеціальний випуск 356 Інформаційні системи «має бути забезпечена можливість відновлення електронного документа у тому форматі, в якому він був створений, відправлений або одержаний» – не зовсім коректне формулювання Закону України ускладнює організацію у масштабі країни обміну електронними документами, оскільки при відкритті за допомогою OpenOffice договору в форматі «docx», створеного за допомогою MS Office, ми отримаємо викривлене подання матеріалу, зумовлене відсутністю чітких правил відображення даних. Ця вимога пов’язана з необхідністю забезпечення цілісності ЕД із застосуванням електронного цифрового підпису (ЕЦП). При конвертуванні з одного формату в інший неможливо зберегти валідність ЕЦП, а отже і гарантувати цілісність конвертованого ЕД. Окрім формальних маємо наступні реальні обмеження до електронного документу: 1) загальна вартість програмного забезпечення (ПЗ) має бути мінімальною; 2) застосовні інструменти мають бути однотипними, аналогічно паперу формату А4 у паперовому діловодстві. Реальні обмеження формулюються цільовою аудиторією, зокрема, користувачами електронного урядування, якими є органи державної ради, у тому числі сільські ради та/або районі адміністрації. Ці користувачі переслідують дві суперечливі цілі: − максимально використовувати електронні документи як інструмент звітування, узгодження рішень у вищих інстанціях та взаємодії із громадянами; − мінімізувати витрати на розгортання і підтримку ІТ-інфраструктури. Суперечливість цих задач випливає з поточного підходу ІТ-фірм до задачі побудови електронного документообігу, тобто тези, що без СЕД використання ЕД – неможливе. Деталізуємо задачу статті як унормування вимог до подання електронних документів з урахуванням формальних і реальних обмежень. Системи електронного документообігу проти систем керування електронними документами Для розв’язання поставленої задачі необхідно визначити мінімальні й достатні умови впровадження ЕД як наслідку електронного урядування. Зауважимо, що досягнення інтероперабельності НСЕЦП – є обов’язковою, але не достатньою умовою. Достатність забезпечить створення нормативно-правової бази ЕДО, а саме Технічного регламенту Національної системи електронного документообігу (далі Технічний регламент). Основним елементом Технічного регламенту є поняття самодостатнього ЕД, для обробки якого опціонально застосовують системи керування електронним документами (СКЕД). Суттєвою відмінністю між СЕД і СКЕД є те, що перший вид систем вимагає використання власних функцій на кожній стадії життєвого циклу ЕД, а другий – надає додаткові функції щодо роботи з ЕД (рис. 2). Створення Оброблення Відправлення Передавання Одержання Зберігання Використання Знищення СЕД СКЕД Рис. 2. Порівняння СЕД та СКЕД Фактично СКЕД і СЕД виконують наступні функції: − зберігання і пошуку документів; − канцелярії; − маршрутизації та контролю виконання документів; 357 Інформаційні системи − аналітичних звітів; − інформаційної безпеки; − додаткові (специфічні) функції. Розглядання цих функцій не є предметом роботи, оскільки коректне подання електронних документів є основою організації електронного документообігу (ЕДО) з застосуванням СЕД та/або СКЕД. При визначенні доцільності використання будь-якого типу систем необхідно провести глибинне дослідження, результатом якого має бути обґрунтування впровадження тотальної системи СЕД чи СУЕД, або використання типових інструментів, наприклад, пакетів MS Office або Open(Liber)Office. Незважаючи на вибрану модель, необхідно забезпечити архівне збереження документів, імплементуючи технологічними та/або організаційними методами електронного діловодства архівний формат ЕЦП, оскільки сучасна практика застосування ЕЦП не гарантує юридичну правомочність ЕД протягом 3-х років. Цей факт випливає з правил посиленої сертифікації [6] і Регламентів акредитованих центрів сертифікації ключів, які видають ЕЦП на один рік, тобто після закінчення валідності ЕЦП необхідно використовувати додаткові заходи для забезпечення юридичної правомочності ЕД. В сучасній діловій етиці існують два терміни – діловодство і документообіг, які помилково ототожнюють, як зазначено в [7]. Циркуляція документів в установі від моменту створення та до завершення робочих процесів редагування, транспортування, візування, затвердження, виконання документів – є документообіг. Згідно з [4]: «електронний документообіг (обіг електронних документів) – сукупність процесів створення, оброблення, відправлення, передавання, одержання, зберігання, використання та знищення електронних документів, які виконуються із застосуванням перевірки цілісності та у разі необхідності з підтвердженням факту одержання таких документів». Діловодство ж охоплює повний життєвий цикл документів, від створення до знищення чи передавання на постійне збереження в архівні установи. Згідно з законом «Про Національний архівний фонд та архівні установи» [8]: «діловодство – це сукупність процесів, що забезпечують документування управлінської інформації і організацію роботи із службовими документами». Отже, термін «діловодство» є ширшим за «документообіг» і включає останню стадію життєвого циклу документів – архівне збереження. Однією з умов впровадження електронних документів – є імплементація технологічними та/або організаційними заходами електронного діловодства, тобто забезпечення архівного збереження ЕД. Подання електронних документів Згідно з проектом «Концепції планування життєвого циклу електронних документів» [9] життєвий цикл електронних документів (ЕД) варто розглядати з перспективи завершального етапу життєвого циклу ЕД – архівного збереження. Електронні дані знаходяться в групі ризику через моральне старіння та легке фізичне пошкодження апаратного забезпечення. Згідно з пунктом 4.3.7 порядку [10] у всіх архівних установах «електронні документи приймаються разом з програмним забезпеченням, що дозволяє відтворити інформацію». У такий спосіб втілено норму статті 13 закону [4], а саме: «має бути забезпечена можливість відновлення електронного документа у тому форматі, в якому він був створений, відправлений або одержаний». Хоча такий варіант архівування має на меті відтворення інформації в майбутньому, але існує безліч проблем викладених у [11], які пов’язані з конфігуруванням відповідних програмно-апаратних комплексів. Тобто зберігати необхідно не тільки ЕД і програмне забезпечення, а й персональний комп’ютер (деякі операційні системи й програмні продукти розраховано лише на конкретне апаратне забезпечення) разом з відповідною операційною системою. Фактично, такий підхід «консервує» ЕД без гарантування їх майбутнього відтворення й юридичної правомочності, тому є не ефективним з огляду на сучасні світові тенденції. Основною властивістю електронних документів має бути самодостатність. Згідно з [12] в п. 3.3 загальних понять розшифровано термін «документ»: «інформація, зафіксована на матеріальному носії, основною функцією якого є зберігати та передавати її в часі та просторі. Примітка. Запис інформації повинен відповідати характеристикам певного жанру чи номіналу. Жанрові характеристики запису інформації – це функційні та структурно-композиційні ознаки певного жанру твору літератури чи мистецтва (роман, монографія, хронікально-документальний фільм тощо). Номінальні характеристики запису інформації – це функційні та структурно-композиційні ознаки певного виду задукоментованої службової чи особистої інформації (наказ, акт, протокол, лист, щоденник тощо)». Згідно з п. 3.5 «документна інформація – вся інформація документа (зміст, відбитки печаток і штампів, реєстраційні номери, резолюції, підписи, інші реквізити та службові познаки, а також маргіналії, філіграні, елементи бланка та захисту)». Згідно з п. 3.7: «носій документної інформації – матеріальний об’єкт, основна функція якого – зберігати та передавати документну інформацію». Також введено поняття «контент документу» згідно з п. 3.4: «інформація в документі, потреба, зафіксувати яку – основна мета його створення». Тобто, ЕД як аналог паперового документу має бути самодостатньою одиницею, незалежною від СЕД та/або СКЕД. Згідно з [13], документ, також ЕД, має 32 обов’язкові реквізити. А згідно з [12]: «реквізит – це зафіксована інформація для ідентифікації, організації обігу і юридичної сили документу». Існуючі СЕД зберігають реквізити й «документи» окремо (під «документом» розробники зазвичай мають на увазі текст документу, який насправді є лише 21-м реквізитом згідно з [13]) (рис. 3). Нині задача архівного збереження ЕД ускладнюється відсутністю єдиного формату ЕД, який має властивості самодостатності, мобільності й кросплатформеності. Цю задачу можна розглядати як аналог застосування у сучасному діловодстві окрім документів формату А4 (прямокутної форми), шестикутних паперових документів, бетоних дощечок та інших 358 Інформаційні системи можливих форм подання 32-х атрибутів документу, згідно з [13]. Відмітимо, що подання архівного документу впливає на подання ЕД, навіть якщо його не призначено для довічного збереження, оскільки згідно з абз. 2 ст.6 [4] «Накладанням електронного підпису завершується створення електронного документа», тобто унеможливлюються будь-які перетворення документу, навіть зміна формату без зміни контенту. Відповідно подання самодостатнього ЕД є одиницею обміну у міжсистемній взаємодії різноманітних СЕД та/або СКЕД. Рис. 3. Подання електронного документу в існуючих СЕД Отже, досягнення достатньої умови впровадження електронного урядування є розв’язання задачі архівного збереження ЕД засобами нормативно-правового регулювання формату подання самодостатнього ЕД. Доцільно розділити етапи підготовлення ЕД і його створення, унормуванню підлягає саме етап створення ЕД. Деталізуємо поняття підготовлення і створення ЕД: 1) підготовлення ЕД – це процес роботи над ЕД у зручних текстових редакторах і оперування авторськими форматами, згідно з [11]; 2) створення ЕД – перетворення ЕД у друкарський формат з накладанням ЕЦП відповідальних осіб. Підкреслимо, що створений ЕД має відповідати вимогам нормативно-правової бази й успішно проходити верифікацію на відповідність архівному формату на тестовому стенді [14]. Обов’язковим реквізитом ЕД є ЕЦП, який гарантує цілісність і неспростовність ЕД. Лише частина сучасних СЕД імплементують засоби ЕЦП, але більшість з них не реалізують чинні національні стандарти, які специфікують формати ЕЦП [15–16]. Чинні ДСТУ [12–13] розглядають документ, відповідно і ЕД, як самодостатню множину атрибутів, що сприймається людиною, із визначеними типами даних, серед яких наявний обов’язковий атрибут – ЕЦП. Іншими словами, ЕД – є контейнером (рис. 4), який містить необхідні реквізити та подання. В електронному діловодстві ЕД і архівний ЕД, придатний для архівного збереження, повинні бути однією сутністю. В такому випадку всі ЕД матимуть єдиний формат, який доцільно унормувати з застосуванням національних стандартів, які гармонізовано з міжнародними. Рис. 4. Подання електронного документу згідно з чинним законодавством 359 Інформаційні системи Виходячи з того, що електронний документ в СЕД не є самодостатнім, а зберігається окремо від реквізитів, існує можливість «зібрати» документ з окремих його частин, наприклад для його друку, однак зберегти його у форматі юридично правомочного ЕД, придатного для архівного збереження – неможливо, тому що обов’язковий реквізит ЕД – є ЕЦП, а у випадку «збирання» з окремих частин постає питання відповідальності, тобто яке саме подання підписано ЕЦП. Наприклад, існує можливість подання ЕД у форматах html, doc, pdf, docx та odf, а також потенційна можливість зміни атрибутів ЕД, як полів бази даних, що також вимагатиме повторного підписання юридично правомочного ЕД. Розв’язання задачі впровадження електронного діловодства Отже, для впровадження електронного діловодства слід визначити дві складові: обмінний формат документів та механізм гарантування цілісності, неспростовності та додатково конфіденційності документів. Механізм, що гарантує властивості неспростовності, цілісності контенту документу і, додатково, конфіденційності: відповідно до закону України [1] ЕЦП забезпечує перші дві властивості, конфіденційність можна гарантувати засобами каналів і протоколів обміну, що виноситься за межі обмінного формату. Від формату обміну даними вимагається здатність його зчитування машиною і людиною. Для вибору формату доцільно розглянути всі стадії життєвого циклу ЕД та обрати той формат, який забезпечує збереження вигляду документу таким, яким бачив його автор, має вбудовану структуру документу і ефективний пошук, підтримує електронно-цифрові підписи, кросплатформеність, є застандартизованим і уніфікованим, розповсюдженим, зручним і звичним для користувача. При створенні ЕД, редагуванні, візуванні, тобто при всіх стадіях електронного саме документообігу, обмеження щодо формату не доцільно висувати. Однак, при проходженні стадії затвердження, коли документ переходить у «завершений» стан, його доцільно зберегти в юридично правомочному форматі ЕД, придатного для архівного збереження та підписування. Вказаний крок є необхідним задля забезпечення останньої стадії життєвого циклу ЕД – архівного збереження. Кожні 15-18 місяців відбувається технологічна зміна програмно-апаратного забезпечення. Оскільки ЕД мають зберігатися від 3 до 100 років, то згідно з сучасними темпами розвитку ІТ ми б мали від 2 до 66 різних архітектур, які необхідні для виконання технологічних вимог архівного збереження. Через це формат ЕД, придатного до архівного збереження, має відповідати принципам відкритої системи й бути незалежним від програмно-апаратних засобів відтворення (властивість самодостатності), підтримувати засоби ЕЦП. Із наявних стандартизованих форматів ЕД (OpenXML, ODF, PDF), тільки PDF, а саме його спеціалізована редакція PDF/A [17], відповідає зазначеним властивостям. Існуюча редакція PDF/A не регламентує застосування кваліфікованих підписів, у термінології Закону України «Про ЕЦП» [3] «підписів заснованих на посилених сертифікатах». Але PDF/A явно не забороняє застосовувати ЕЦП для архівного збереження документів. Для розв’язання задачі регламентування формату архівного ЕД у PDF/A доцільно застосувати стандарт ETSI TS 102 778. Стандарт ETSI TS 102 778 визначає серію профілів, що описують використання цифрових підписів у PDF для забезпечення структури розширених електронних підписів для підписування електронних PDF документів, а його частина [17] визначає профіль PAdES-LTV, який забезпечує довгострокову валідність ЕЦП. У [18] описано структуру стенду валідації ЕД, придатного для архівного збереження із акцентом на профіль PAdES- LTV. Згідно з [13] документ (ЕД) складається з 32-ох атрибутів, отже у формат ЕД окрім візуального подання, доцільно інтегрувати їх машинно-зчитувальне подання для спрощення організації ЕДО. Разом з цим, використання реквізитів можливе при застосування інструментарію додавання до PDF-файлів метаданих: XMP- формат файлу метаданих, який застосовує необхідну для конкретних цілей XML-схему. В PDF існує можливість вкладення необхідних метаданих за допомогою платформи Extensible Metadata Platform (XMP). XMP [19] метадані транспортуються разом з файлом і можуть використовуватись у файлах форматів PDF, TIFF і JPEG. Властивості метаданих формуються у схеми. Кожна схема ідентифікується унікальним простором імен URI і містить довільну кількість властивостей. Простори імен URI можуть і не вказувати на конкретний ресурс – вони є просто унікальними ідентифікаторами для деяких сутностей, які використовує XMP. XMP специфікація включає більше 12 визначених схем і сотні властивостей для звичних документів і зображень. Схема, що є найбільш використовувана – Dublin Core (dc). Вона включає найбільш поширені властивості: назва, автор, предмет і опис. У XMP включено можливість визначати додаткові схеми для виконання вимог конкретної сфери. XMP реалізовано у всіх Adobe продуктах і цей формат підтримується багатьма виробниками програмного забезпечення і групами користувачів. PDF/A-1 в [11] вимагає XMP для ідентифікації відповідних файлів і підтримує метадані користувачів по XMP схемам розширень. PDF згідно з [12] повністю підтримує XMP метадані. Схема Dublin Core [20] – розповсюджена схема XMP метаданих, зокрема популярна серед архівістів. Доцільно для імплементації машинно-зчитувального подання 32-ох реквізитів, уточнити їх формат із застосуванням міжнародного стандарту загальних типів даних (ISO/IEC 11404:2007) та XML Schema Part 2: Datatypes Second Edition. Уточнене подання сформує XML схему, яку доцільно інтегрувати у XMP метадані PDF/A файлу. Приклад подання реквізитів у PDF/A файлі відображено на рис. 5–7. 360 Інформаційні системи 1 <?xml version="1.0" encoding="UTF-8"?> 2 <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2.1- 3 c043 52.372728, 2009/01/18-15:08:04 "> 4 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 5 <rdf:Description rdf:about=""xmlns:pdf="http://ns.adobe.com/pdf/1.3/"> 6 <pdf:Producer>Microsoft Word 2010</pdf:Producer> 7 </rdf:Description> 8 <rdf:Description 9 rdf:about=""xmlns:dc="http://purl.org/dc/elements/1.1/"> 10 <dc:creator><rdf:Seq><rdf:li>Olena</rdf:li></rdf:Seq></dc:creator> 11 <dc:title> 12 <rdf:Alt><rdf:li xml:lang="x-default">Contract</rdf:li> 13 </rdf:Alt> 14 </dc:title> 15 </rdf:Description> 16 <rdf:Description rdf:about="" 17 xmlns:mysch="e:\PEOPLE\Elena\Статьи2011\статья_XMP\myschema1.xsd"> 18 <mysch:назва_організації>Інститут кібернетики 19 </mysch:назва_організації> 20 <mysch:код_організації>3222 21 </mysch:код_організації> 22 <mysch:код_форми_документа>02 011 325 23 </mysch:код_форми_документа> 24 </rdf:Description> 25 </rdf:RDF> 26 </x:xmpmeta> Рис. 5. Вміст файлу метаданих Dublin Core На рис. 6 подано XML-схему, що використовується у файлі XMP для подання специфічних для українського діловодства атрибутів. 1 <?xml version="1.0" encoding="utf-8"?> 2 <xs:schema 3 xmlns:xs="http://www.w3.org/2001/XMLSchema"> 4 <xs:element name="mysch" type="mysch"/> 5 <xs:complexType name="mysch"> 6 <xs:sequence> 7 <xs:element name="назва_організації" type="xs:string"/> 8 <xs:element name="код_організації" type="xs:string"/> 9 <xs:element name="код_форми_документа" type="xs:string"/> 10 </xs:sequence> 11 </xs:complexType> 12 </xs:schema> Рис. 6. XML-схема із описом атрибутів українського діловодства Рис. 7. Відображення нових автрибутів у Adobe Reader 10 361 Інформаційні системи Висновок У роботі обґрунтовано необхідні та достатні умови розбудови інфраструктури електронних бізнесів, зокрема, електронного урядування як досягнення інтероперабельності Національної системи електронного цифрового підпису і створення Технічного регламенту Національної системи електронного діловодства. Осатаній створює нормативно-правову базу електронного діловодства, яка оперує юридично правомочним електронним документом як самодостатньою сутністю. На прикладі метаданих архівного PDF, як формату юридично правомочного самодостатнього електронного документу, продемонстровано створення машино-зчитувального подання реквізитів документу поруч із візуальним поданням. 1. Розпорядження Кабінету Міністрів України вiд 13.12.2010 № 2250 «Про схвалення Концепції розвитку електронного урядування в Україні». 2. Указ Президента України № 1085/2010 «Про оптимізацію системи центральних органів виконавчої влади». 3. Закон України «Про електронний цифровий підпис». 4. Закон України «Про електронні документи та електронний документообіг». 5. Мелащенко А.О., Перевозчикова О.Л. Організація кваліфікованої інфраструктури відкритих ключів. – К.: Наукова думка, 2010. – 392 с. 6. Наказ № 3 вiд 13.01.2005. Департамент спеціальних телекомунікаційних систем та захисту інформації служби безпеки України «Про затвердження Правил посиленої сертифікації». 7. Сельченкова С.В. Діловодство: Практичний посібник. – К.: Інкунабула, 2009. – 480 с. 8. Закон України «Про Національний архівний фонд та архівні установи». 9. Проект «Концепції планування життєвого циклу електронних документів» розробленого Центральним державним електронним архівом України. 10. Наказ Державного комітету архівів України «Порядок зберігання електронних документів в архівних установах». 11. Мелащенко А.О., Перевозчикова О.Л., Скарлат О.С. «Формат довгострокового зберігання електронних документів». // Компьютерная математика. – 2011. – № 1. – С. 106–115. 12. Діловодство й архівна справа. Терміни та визначення понять: ДСТУ 2732-2004 – [Чинний від 2005-07-01] – К.: Держспоживстандарт України, 2005. – Національний стандарт України. 13. Уніфікована система організаційно-розпорядчої документації: ДСТУ 4163-2003 – [Чинний від 2003-09-01] – К.: Держспоживстандарт України, 2003. – Національний стандарт України. 14. Мелащенко А.О., Перевозчикова О.Л., Скарлат О.С. «Складові стенду валідації архівних електронний документів». // Проблеми програмування. – 2012 – № 1. – С.52–28. 15. Електронні підписи та інфраструктури (ESI). CMS-розширені електронні підписи (CAdES): ДСТУ ETSI TS 101 733:2009 – [Чинний від 2011-07-01] – К.: Держспоживстандарт України, 2003. – Національний стандарт України. 16. XML-розширені електронні підписи (XAdES): ДСТУ ETSI TS 101 903:2009 – [Чинний від 2011-07-01] – К.: Держспоживстандарт України, 2003. – Національний стандарт України. 17. ISO/IEC 19005-1:2005 Document management – Electronic document file format for long-term preservation – Part 1: Use of PDF 1.4 (PDF/A- 1). – [Електронний ресурс] – Режим доступу: http://www.iso.org/iso/catalogue_detail?csnumber=38920. 18. ETSI TS 102 778-4 V1.1.2 (2009-12) Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term - PAdES-LTV Profile. – [Електронний ресурс] – Режим доступу: http://www.etsi.org/deliver/etsi_ts/102700_102799/10277804/01.01.01_60/ts_10277804v010101p.pdf. 19. XMP Specification. – [Електронний ресурс] – Режим доступу: http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf. 20. ISO 15836:2009. Information and documentation –The Dublin Core metadata element set. – [Електронний ресурс] – Режим доступу: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52142. 362 ІМПЛЕМЕНТАЦІЯ ЮРИДИЧНО ПРАВОМОЧНИХ ЕЛЕКТРОННИХ ДОКУМЕНТІВ Вступ Сутність «електронного урядування» Системи електронного документообігу проти систем керування електронними документами Подання електронних документів Розв’язання задачі впровадження електронного діловодства Висновок
id pp_isofts_kiev_ua-article-90
institution Problems in programming
keywords_txt_mv keywords
language Ukrainian
last_indexed 2025-07-17T09:37:58Z
publishDate 2015
publisher PROBLEMS IN PROGRAMMING
record_format ojs
resource_txt_mv ppisoftskievua/b5/a286426d32764b3840e8522a1ffd93b5.pdf
spelling pp_isofts_kiev_ua-article-902018-09-20T12:12:37Z The implementation of legal electronic documents Имплементация юридически правовых электронных документов Імплементація юридично правових електронних документів Melaschenko, A.O. Скарлат, О.С. electronic document UDC 681.3:002.651.028(083.73) электронный документ УДК 681.3:002.651.028(083.73) електронний документ УДК 681.3:002.651.028(083.73) Considered in the article are the main problems of the electronic office management implementation as basis of eGoverment. Analyzed are the drawbacks of the legal framework regulating the electronic office management in Ukraine and the procedure is proposed for its specific modifications providing the complete electronic documents lifecycle. Motivated is the necessity of the self-contained electronic documents and the main requirements are specified to the electronic documents and their internal structure. Рассмотрены основные проблемы внедрения электронного делопроизводства как основы электронного управления. Проанализированы недостатки действующей нормативно-методической базы, регулирующей электронное делопроизводство в Украине, и предложен порядок ее конкретных изменений для обеспечения полного жизненного цикла электронных документов. Обоснована необходимость самодостаточных электронных документов и детализировано основные требования к электронным документам, которые предназначены для пожизненного сохранения. В статье приведен пример создания электронных документов в соответствии с действующим законодательством. Розглянуто основні проблеми впровадження електронного діловодства як основи електронного урядування. Проаналізовано недоліки чинної нормативно-методичної бази, що регулює електронне діловодство в Україні, та запропоновано порядок її конкретних змін для забезпечення повного життєвого циклу електронних документів. Обґрунтовано необхідність самодостатніх електронних документів та деталізовано основні вимоги щодо електронних документів, які призначені для довічного збереження. В статті подано приклад створення електронних документів у відповідності з чинним законодавством. PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2015-09-10 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/90 PROBLEMS IN PROGRAMMING; No 2-3 (2012) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2012) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2012) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/90/89 Copyright (c) 2015 ПРОБЛЕМИ ПРОГРАМУВАННЯ
spellingShingle electronic document
UDC 681.3:002.651.028(083.73)
Melaschenko, A.O.
Скарлат, О.С.
The implementation of legal electronic documents
title The implementation of legal electronic documents
title_alt Имплементация юридически правовых электронных документов
Імплементація юридично правових електронних документів
title_full The implementation of legal electronic documents
title_fullStr The implementation of legal electronic documents
title_full_unstemmed The implementation of legal electronic documents
title_short The implementation of legal electronic documents
title_sort implementation of legal electronic documents
topic electronic document
UDC 681.3:002.651.028(083.73)
topic_facet electronic document
UDC 681.3:002.651.028(083.73)
электронный документ
УДК 681.3:002.651.028(083.73)
електронний документ
УДК 681.3:002.651.028(083.73)
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/90
work_keys_str_mv AT melaschenkoao theimplementationoflegalelectronicdocuments
AT skarlatos theimplementationoflegalelectronicdocuments
AT melaschenkoao implementaciâûridičeskipravovyhélektronnyhdokumentov
AT skarlatos implementaciâûridičeskipravovyhélektronnyhdokumentov
AT melaschenkoao ímplementacíâûridičnopravovihelektronnihdokumentív
AT skarlatos ímplementacíâûridičnopravovihelektronnihdokumentív
AT melaschenkoao implementationoflegalelectronicdocuments
AT skarlatos implementationoflegalelectronicdocuments