Не е доведен да плаче. Особености на архивното съхранение на правно значими електронни документи
Фигура 97. Лента с инструменти. Бутон за отказ
30 дни преди изтичането на сертификата на ключа за проверка на електронния подпис се появява прозорец със съответното информационно съобщение, когато потребителят е оторизиран в SUFD. Този прозорец се затваря с натискане на бутона OK (фиг. 98, 99).
Фигура 98. Информационно поле "Сертификатът изтича" за множество сертификати
Фигура 99. Информационно поле "Сертификатът изтича" за един сертификат
Информационно съобщение се показва и за всяко оторизиране на потребител в SUFD в случай, че сертификатът на ключа за проверка на електронния подпис е изтекъл (фиг. 100, 101).
Фигура 100. Информационен прозорец "Сертификатът е изтекъл" за няколко сертификата
Фигура 101. Информационен прозорец "Сертификатът е изтекъл" за един сертификат
6.7.3. Премахване на подпис
За да премахнете подписа на документ (ако документът все още не е изпратен), изберете документа, чийто подпис се изтрива, в списъка с документи и щракнете върху бутона („Премахване на подписа“) в лентата с инструменти (фиг. 102).
Фигура 102. Лента с инструменти. Бутон за изтриване на подписа
6.8. Изпращане на документ
Преди изпращане на документа подписите се проверяват за внасяне в UES, както и проверка за пълнота на комплекта подписи. Ако подписите на документа не отговарят на изискванията, документът няма да бъде изпратен (статусът на прехвърляне няма да се промени). Потребителят получава съобщение, в което се посочва, че „Подписът не е внесен в UES“ или „Документът не е подписан с пълен набор от подписи“.
За да изпратите избрания документ, щракнете върху бутона ("Изпрати") в лентата с инструменти (фиг. 103).
Фигура 103. Лента с инструменти. Бутон за изпращане
На екрана ще се появи информационен прозорец (фиг. 104).
Фигура 104. Информационен прозорец "Изпращане на документ"
При успешно приключване на операцията по изпращане на документа на екрана ще се появи информационен прозорец с информация за приключването на операцията (фиг. 105).
Фигура 105. Информационен прозорец
Резултатът от операцията може да се види с помощта на "Диспечер на задачи" (виж фиг. 5). След извикване на диспечера на задачите ще се отвори прозорец, както е на фигура 106.
Фигура 106. Прозорец на диспечера на задачите
За повече информация относно операцията за изпращане, щракнете двукратно с левия бутон на мишката върху съответния ред в списъка с операции в прозореца "Диспечер на задачи". След това ще се отвори прозорец с информация за операцията (фиг. 107). Ако схемата на състоянието на документа не включва изпращане на документа с текущото му състояние, тогава в полето "Резултат" се показва съобщение за това.
Фигура 107 Подробности за операцията
Ако при изпращане на документ адресът на получателя не е определен от системата, тогава статусът на документа се променя на „Грешка при адресиране“. В този случай можете да потърсите отново адресата, като щракнете върху бутона („Повторете търсене на адресата“) или да откажете документа, като щракнете върху бутона https://pandia.ru/text/80/135/images/ image215_0.jpg" width="19 " height="22"> ("Изпращане"), след което избраният документ се изпраща. Ако документът е изпратен успешно, състоянието му на прехвърляне се задава на "Изпратено". Освен това състоянието на документа се променя в съответствие със статусите, присвоени на документа на приемащата работна станция.
Ако възникне грешка при изпращане, статусът на документа се задава на "Грешка при изпращане". В този случай е необходимо да върнете обратно състоянието на документа (вижте раздел 5.10.2) и да изпратите документа отново.
6.9. Документ за внос/експорт
6.9.1. Ръчно импортиране на документи
За да импортирате документ, трябва да изпълните следната последователност от действия:
1. В навигационния панел отидете на секцията, съответстваща на типа документ, който се импортира.
2..jpg" width="642" height="450">
Фигура 108. Лента с инструменти. Бутон за импортиране
Забележка. Ако трябва изрично да посочите формата на импортирания файл, трябва да щракнете върху бутона за избор, разположен вдясно от бутона за импортиране. Ще се отвори списък с наличните формати за импортиране (фиг. 109).
Фигура 109. Избиране на формата на импортирания файл
3. В отворения прозорец "Изтегляне на файл" намерете и посочете файла за импортиране. Натиснете бутона "Отвори".
За да извършите автоматично документален контрол на импортирания файл, трябва да изберете един от елементите на менюто, съдържащ думите „+Doc. контролът". В този случай веднага след импортирането на файла ще бъде извършен документален контрол. В случай на успешно преминаване на документален контрол, документът ще бъде прехвърлен в статус „Въведен“ / „Въведен“. Ако възникнат грешки по време на документален контрол, те ще бъдат показани в прозореца на диспечера на задачите, както при ръчния документален контрол (вижте точка 5.6).
В резултат на операцията по импортиране в базата данни на SUFD ще се зареди нов документ(и) от файла(ите), като в общия и избран скролери документите ще бъдат автоматично сортирани в съответствие с настройките за сортиране на потребителя.
6.9.2. Ръчно експортиране на документи
За да експортирате документ, изпълнете следните стъпки:
1. В навигационния панел отидете на секцията, съответстваща на типа документ, който се експортира.
2. Посочете експортирания файл (или няколко файла) в списъка с документи.
3..jpg" width="642" height="450">
Фигура 110. Лента с инструменти. Бутон за експортиране
Забележка. Ако трябва изрично да посочите формата на експортирания файл, щракнете върху бутона, разположен вдясно от бутона за експортиране. Ще се отвори списък с наличните формати за експортиране (фиг. 111, 112).
Фигура 111. Избиране на формата на експортирания файл
30 април 2013 г. 13:40 чИван Агапов, бизнес анализатор в Synerdocs
Нека се опитаме да разберем какво се случва днес в Русия в областта на дългосрочното съхранение на електронни документи с помощта на електронен подпис. Какво да очакват представителите на бизнеса във връзка с новия стандарт и има ли солидна законодателна база за електронно архивиране.
Днес все по-често възниква необходимостта от преобразуване на документи в електронна форма не само за временно ползване, но и за дълъг или дори постоянен период на съхранение. Факт е, че електронното управление на документи ви позволява да работите с документи, без да ги дублирате на хартия. Поради това броят на подобни електронни документи непрекъснато расте. Особено важно е да се съхраняват т. нар. правно значими документи – фактури, договори, актове, фактури и др.
При организиране на съхранението на правно значими електронни документи възникват редица проблеми. На първо място възниква въпросът за физическото местоположение на съхранението на документите.. При избора на носители за съхранение (сменяеми или локални), трябва да се има предвид, че техният срок на годност е ограничен. Условията на работа също са много важни. Например фактори като стайна температура, влажност, UV лъчи и др. А за организиране на съхранението на голямо корпоративно количество информация са необходими сървъри. Логично е изискванията към сървърните стаи да бъдат дори по-сериозни, отколкото към вездесъщите локални носители за съхранение. Това е не само липсата на прозорци в стаята и наличието на повдигнат под, но и редица други съществени ограничения. Въз основа на това съхранената информация трябва периодично да се архивира, презаписва, заменя носителя и т.н.
Специализираните електронни архиви могат да се превърнат в изход от тази ситуация. Например, през март 2002 г. в Руската федерация стартира федералната целева програма "Електронна Русия (2002-2010)", в рамките на която се реализира проектът "Електронен архив на президента на Руската федерация". Общият обем на архива възлиза на приблизително 15 милиона документа. В края на 2010 г. обаче ефективността на програмата беше оценена като ниска: електронното управление на документи между държавните агенции, както и електронните комуникации между държавните агенции и гражданите, не функционираха напълно. Според Световната банка ефективността на публичната администрация в Русия не се е променила много през годините. Жалко е, че днес този проект е спрян и няма нужда да говорим за масовото и широко разпространение на подобни програми. По-специално, това беше улеснено от липсата на регулаторна рамка в Руската федерация, която да регулира отношенията в областта на електронното архивиране, но стартирането на целева програма все още дава надежда за развитието на тази област.
Вторият и може би най-важният проблем при дългосрочното съхранение на електронните документи е осигуряването на тяхната правна значимост. Последното се постига чрез използване на електронен подпис (ЕП). Към днешна дата отношенията в тази област се уреждат от: Федерален закон № 1-FZ от 10 януари 2002 г. „За електронния цифров подпис“ и Федерален закон № 63-FZ от 6 април 2011 г. „За електронния подпис“. Съгласно Федерален закон № 63 се разграничават два вида ЕР: прости и подсилени.
Всички подписи се различават един от друг по своите характерни черти, които са ясно отразени в тези федерални закони. Но, за съжаление, има някои ограничения при използването на всеки от видовете подписи, като същевременно осигурява правно значение. Факт е, че сертификатът за ключа за проверка на електронния подпис по правило се издава за една година, а подписаният документ, съгласно изискванията на закона, трябва да се съхранява най-малко пет години. Възниква въпросът как за три години да се докаже валидността на ЕСП, която е потвърдена от този сертификат? Това означава, че ние сме изправени пред задачата да определим валидността на електронния подпис и удостоверението към момента на подписване на документа.
Този проблем се решава чрез използване усъвършенстван електронен подпис (UEP). Към неговия формат са добавени знаци за доказателство за автентичност, като времеви печат, данни за анулиране на сертификат и др.
UEP ви позволява да предоставите:
● доказателствено потвърждение на момента на създаване на подписа;
● доказателствено потвърждение за валидността на сертификата за ключ за електронен подпис към момента на неговото създаване;
● архивно съхранение на правно значими електронни документи.
Както можете да видите, съвременните разработки и технологии позволяват да се гарантира съхранението на правно значими електронни документи.
Друг важен аспект в въпроса за архивното съхранение на SWED е бързото развитие на оборудването и технологиите. Бързият напредък не ни позволява да погледнем в бъдещето повече от 10-15 години. За да разберем за какво говорим, нека се върнем няколко години назад и какво ще видим? За съхраняване на информация активно се използват 3½-инчови дискети. Но още през март 2011 г. Sony сложи край на историята на дискетите, като официално прекрати тяхното производство и продажба. И сега компютрите просто не предполагат наличието на флопи устройство. Съвременните производители на оптични дискове гарантират работата на устройствата за не повече от 10 години. Срокът на експлоатация на флаш устройствата зависи от броя на процесите на презаписване на данни. Всичко това предполага, че след известно време просто сме принудени да презаписваме информация на все по-модерни устройства. По този начин трябва да имаме гаранции, че след 10-15 години ще можем да проверяваме ES на съхранените документи без никакви проблеми и, разбира се, да „четем“ формата на текстовия редактор, в който е създаден електронният документ 10 години преди (напр. формат Lexicon). За да направите това, се нуждаем от устройство за възпроизвеждане, операционна система и инструменти за работа с ES, които ще поддържат формата на съхранявания електронен документ.
Трябва ли всичко това да е възможно?
да. Към днешна дата разполагаме с всички необходими инструменти за организиране на архивното съхранение на SWED. Използването на разширения формат за подпис гарантира, че вашите документи са правно валидни. Организирането на работно място, което ви позволява да проверявате ES след 10-15 години, с подходяща организация на процесите, също не създава сериозни затруднения. Създаването на електронни архиви няма да ви кара да чакате с увеличаване на търсенето им.
Ситуацията е малко по-сложна със законодателната рамка на Руската федерация в областта на електронното архивиране, но може би колкото по-скоро бизнесът изостави хартията, толкова по-скоро подробна информация за електронните документи ще се появи в нашата страна в закона „За електронните архиви“ ? Появата на първите прецеденти в една слабо проучена досега област просто ще принуди държавата да се заеме с този проблем.
Всичко е взаимосвързано и в повечето случаи зависи от нас. Празните очаквания няма да доведат до резултати - време е да започнете да действате!
За извършване на ревизията в търговска експлоатация е необходимо да се осигурят следните организационни мерки:
Създаване на директория "Офлайн дистрибуции на работни станции" на софтуера "ASFC (SUFD)" за маршрутизиране на документи на клиенти на работната станция "Офлайн - клиент FK" и каталози за качване на данни.
Дейности за обучение на нови клиенти в основните принципи на работа в системата.
Събития за обучение на служителите на OrFC за принципите на взаимодействие с офлайн клиенти и контрол върху документопотока.
2.3.Променена документация
Направени са промени в SUFD_RAS_System settings.doc - клауза 7.1.4 е актуализирана, 7.1.11 е добавена.2.4 Промени в потребителския интерфейс
2.4.1 Системна константа GroupOutgoingPacket
Разработена е системната константа GroupOutgoingPacket (Група от изходящи пакети, изпращани между AWS Offline и SUFD) (фиг. 1).Константата приема стойността:
1 и всяка стойност, различна от 0 - групови пакети;
0 - не групирайте (по подразбиране).
1. EF на системната константа GroupOutgoingPacket
2.5 Промени в директориите
2.5.1. Указател на "Справочник на пакети за OrFC"
В SUFD и офлайн работна станция към екранната форма на записа на Directory of bundle за OrFC е добавено ново поле „Offline организационен код“ (фиг. 2). ).
2. EF записи на директорията с връзки за ORFC
2.5.2. Наръчник „Офлайн дистрибуции на работни станции“
Разработен е нов справочник "Офлайн дистрибуции на работна станция" в елемента от менюто "Справки - Система - Настройки на работната станция офлайн" (фиг. 3, 4).
3. EF на директорията "Офлайн дистрибуции на работни станции"
4. EF записи на директорията "Офлайн дистрибуции на работни станции"
3.SUFD-56709. Усъвършенстване на разширената проверка на електронен подпис
3.1 Кратко описание на ревизията
В съответствие с писмото на Федералното съкровище от 17 юли 2014 г. № 42-11.0-13 / 226 в PPO "ASFC (SUFD)":
Функцията на криптосървъра за укрепване на електронния подпис е подобрена по отношение на добавяне на дата на изтичане на сертификата за доверена времева услуга от външен времеви печат.
Функцията на Cryptoserver за проверка на подобрен електронен подпис е подобрена по отношение на подобряване на алгоритъма за проверка на времеви печати.
В Cryptoserver е разработена функцията за извличане на периода на валидност на доверен сертификат за услуга за време от външен времеви печат.
В Криптосървъра е разработена функцията „Привеждане на електронния подпис в архивен формат“.
Разработена е функция за регистриране на събития за привеждане на електронните подписи в архивен формат
В Cryptoserver е разработена функцията за генериране на заявка към доверената времева услуга за генериране на архивен времеви печат.
Функцията за формиране на времеви печат на архива е разработена в Cryptoserver.
В Cryptoserver е разработена функцията за добавяне на времеви печат на архива към електронен подпис.
В MQ сървъра е разработена функция за получаване на датата на изтичане на сертификата за доверено време, който е използван за генериране на последния времеви печат, от електронен подпис.
В MQ сървъра е разработена функцията „Предаване на електронен подпис в архивен формат“.
Функцията за укрепване на електронния подпис в MQ сървъра е подобрена по отношение на добавяне на датата на изтичане на параметъра на удостоверението за доверено време от външен времеви печат.
Подобрена е функцията за съхраняване на електронен подпис по отношение на добавяне на ново поле „Дата на изтичане на сертификата за услугата доверено време“.
Функцията „Укрепване на електронния подпис“ е подобрена по отношение на запазване на информация за датата на изтичане на сертификата за услугата доверено време от външен клеймо за време.
Подобрена е функцията за проверка на електронния подпис по отношение на определяне на знака за проверка на електронния подпис на удостоверението за доверено време.
Функцията „Привеждане на електронните подписи в архивен формат“ е разработена за електронни подписи, съхранявани в ЗОП „ASFC (SUFD)“.
3.1.1.Разработване на конфигурационен параметър "Период на подновяване на времевия печат на архива" (SUFDCORE-14146)
Към конфигурационния файл sufd.properties е добавен нов параметър „Период на актуализиране на времевата марка на архива“ (sufd.crypto.dateForUpdateArchiveTimestamp).Параметърът е предназначен за уточняване на периода в дни, при наближаването на който се актуализира архивния времеви печат на подписа. Стойност по подразбиране = 30 дни.
3.1.2 Разработване на програма "Определяне на срока на валидност на сертификат за доверено време" (SUFDCORE-13990)
Разработена е програма „Определяне на срока на валидност на удостоверение за доверено време“ за електронни подписи, които вече се съхраняват в ЗОП „ASFC (SUFD)“.Алгоритъмът на програмата е както следва:
Полето „Дата на изтичане на сертификата за доверено време“ се попълва за електронни подписи, които вече са съхранени в софтуера ASFC (SUFD), чрез извличане на датата на изтичане на сертификата за доверено време от външен времеви печат.
Програмата се изпълнява еднократно за всеки електронен подпис, който има празно поле „Срок на валидност на сертификата за доверено време“.
3.1.3. Разработване на функцията "Привеждане на електронните подписи в архивен формат" (SUFDCORE-13989)
Разработена е функцията "Привеждане на електронните подписи в архивен формат".Алгоритъмът на функцията е както следва:
Входният параметър е периодът на припокриване между текущия и новия сертификат за доверено време (SUFDCORE-14146 нов конфигурационен параметър).
Избират се електронни подписи, за които разликата между периода на валидност на удостоверението за доверена времева услуга от последното времеви печат (външно клеймо за време или последно времеви печат във веригата от времеви печати в архива) и текущата системна дата е по-малка от стойността на програмата входен параметър, но по-голям от нула. Всеки електронен подпис се обработва по следния сценарий:
ако програмата се стартира на AWP SUFD-Portal или AWP OrFK, тогава:
електронният подпис чрез извикване на функцията "Функция за привеждане на електронния подпис в архивен формат" на криптосървъра се превежда във формат на архива,
доведени до архивен формат, електронният подпис и датата на изтичане на сертификата за доверено време се съхраняват в базата данни на AWP SUFD-портала / AWP OrFC.
ако програмата се стартира на OFK-офлайн работна станция, тогава:
на базата на електронния подпис, чрез извикване на функцията „Функция за създаване на заявка към доверената времева услуга“ на Криптосървъра, се създава заявка към доверената времева услуга за формиране на архивен времеви печат;
за да достави заявката до доверената времева услуга, се създава документ за услуга на превозвача, в който се добавя заявката. Документът носител се изпраща до работната станция за логистика на SUFD;
когато в SUFD-логистичната работна станция се получи документ-носител, от документа се извлича заявка, въз основа на която чрез извиквания на функцията „Функция за създаване на архивен етикет въз основа на предадената заявка“ се изписва времеви печат на архива е формиран;
За доставяне на генерирания времеви печат се създава служебен документ на превозвача, към който се добавя архивен печат. Носещият документ се изпраща до OFC-офлайн работната станция, от която е дошъл сервизният документ за формиране на архивен етикет;
когато документ-носител се получи на работната станция OFC-офлайн, от документа се извлича архивен печат и чрез извикване на функцията „Функция за добавяне на времеви печат на архив към електронния подпис“ на криптосървъра се добавя към електронен подпис. Веднъж добавен, веригата за времеви отпечатъци на архива се проверява; електронният подпис, приведен в архивен формат, и датата на изтичане на сертификата за услугата доверено време от етикета на архива се съхраняват в базата данни на OFC-офлайн AWS.
Добавен знак на искането: или укрепване на ES, или формиране на архивен етикет.
Добавено е поле от тип Дата, което транспортира датата на изтичане на сертификата за услуга TSP от последното времеви печат.
3.1.4. Прецизиране на съхранението, WF на ES данни (SUFDCORE-13988)
Подобрена е структурата за съхранение на данни на ES: към таблицата е добавено допълнително поле „Дата на изтичане на сертификата за услугата доверено време“ (до полето „Последна проверка“).3.1.5. Усъвършенстване на Cryptoserver/MQ сървъра (SUFDCORE-13980)
Подобрен Cryptoserver/MQ сървър по отношение на:
Подобрение по отношение на поддръжката на архивен подпис (например CAdES-A, използващ атрибута archive-time-stamp, който е времеви печат на архива).
Подписът е:
Формиране:
криптосървърът, въз основа на хеша на подписа на втория времеви печат, генерира заявка в SDV;
SDV подписва със своя ключ;
Последващо налагане на архивни бележки:
криптосървърът, въз основа на хеша на подписа на последния архивиран времеви печат, генерира заявка в SDV;
ADD изважда хеша и прилага точното време;
SDV подписва със своя ключ;
полученият отговор се връща на криптосървъра.
Преглед:
Ако проверката е била успешна, тогава веригата на предишния етикет се проверява по същия начин (и така нататък до първия) - сертификатът се проверява за валидност в момента, посочен в следващия етикет.
Обяснение на текущото изпълнение:
документ (първите 20 kb);
подпис върху документа;
1-ви етикет (вътрешен) е насложен върху хеша за подпис;
OCSP отговор;
Вторият етикет (външен) се наслагва върху хеша (подпис на първия етикет + подпис за отговор на OCSP).
Следният идентификатор на обект (OID) дефинира атрибута archive-time-stamp: 1.2.840.113549.1.9.16.2.48.
Усъвършенстване на функцията "Привеждане в UEP" по отношение на допълнителен параметър за връщане - "Дата на изтичане на последното времеви печат".
Реализация на функцията „Получете от ES датата на изтичане на сертификата за последното времеви печат“.
3.1.6. Усъвършенстване на взаимодействието с криптосървъра „Укрепване на електронния подпис“ (SUFDCORE-13975)
Реализиран е нов тип взаимодействие с криптосървъра - "Укрепване на електронния подпис":
EP се дава като вход.
Резултатът е UES с допълнителен печат за време (archive-time-stamp) и отделно датата на изтичане на сертификата и допълнителния печат (последен timestamp).
Записване на върнатия параметър „Дата на изтичане на последното времеви печат“ (при „привеждане в UES“ или „Подобряване на ES във формат за архивно съхранение“) в съответното поле на таблицата за съхранение на ES (SUFDCORE-13988 - полето „Дата на изтичане“ на сертификата за доверено време“ .
3.1.7 Подобряване на функцията за проверка на подписа (SUFDCORE-13969)
Функцията за проверка на подобрения електронен подпис (SES) е подобрена по отношение на прецизиране на алгоритъма за проверка на времеви печати.Алгоритъмът за проверка на времеви печати е както следва:
В параметрите на функцията "Подобрена проверка на електронен подпис" се посочва знакът за проверка според текущия алгоритъм. В този случай външното клеймо за време се проверява за датата на неговото създаване, вътрешното клеймо за време се проверява за датата, на което е създадено външното времеви печат.
В параметрите на функцията "Проверка на подобрен електронен подпис" има знак за проверка по новия алгоритъм, тогава в този случай:
Електронният подпис съдържа верига от архивни бележки, като в този случай N-тото времеви печат във веригата се проверява за текущата системна дата, (N-1)-тото времеви печат се проверява за датата, на което е генерирано N-то времеви печат. Външното времеви печат се проверява за датата на формиране на 1-ви архивен времеви печат;
електронният подпис не съдържа верига от архивни времеви печати, в този случай външната дата за време се проверява спрямо текущата системна дата, вътрешната дата се проверява спрямо датата на създаване на външната дата.
UEP твърди, че е разкрил две хиляди престъпления
Московската прокуратура приключи проверка на работата на отдела за икономически престъпления на ГДВР на Москва. Установено е, че полицаите се занимават с приписки и изопачаване на репортажите, докато въобще никой не търси много опасни престъпници. Самата UEP категорично не е съгласна с това. Ръководството му обвинява инспекторите в непрофесионализъм и нежелание да проучат задълбочено ситуацията. Кореспондентът на Комерсант ВЛАДИМИР Комерсант-СЮН се опита да направи това.
Още в началото на проверката на прокурорите стана ясно, че вместо реална работа, УЕП усилено създава своя облик. И за да не загубят лице пред МВР, столичните полицаи са се научили да се справят с приписките не по-зле от хората, с които трябва да се бият на пост. Според Игор Бобровски, началник на прокуратурата за надзор върху изпълнението на законите в органите на вътрешните работи, „в УЕП са регистрирани стотици т. нар. продължавани престъпления“. „Вземете например незаконното предприемачество“, възмущава се Бобровски. Ако някой е внесъл нелегално 100 гуми, значи престъпленията за контрабанда са не едно, а сто.“ В резултат на това градската прокуратура дерегистрира над хиляда факта за измами, повече от сто контрабанда и 113 епизода на подкупи само през миналата година. И общо - повече от две хиляди престъпления, разкриването на които UEP приписва на себе си.
Освен това, според прокуратурата, уеповците са измамили министерството, като твърдят, че в техния отдел на практика няма бюрокрация и делата се разглеждат буквално за дни. Така например за три дни са разкрити 147 престъпления. За същия период са отхвърлени 173 дела.
Прокурорите обаче установиха, че само две от 147 дела са разгледани в рамките на три дни, 13 в рамките на 10 дни, по 58 дела са взети решения за повече от три месеца, а 26 дела са разгледани за повече от шест месеца. В много случаи всички рекорди са били счупени като цяло (около две години). Но по правило по време на продължителни разследвания доказателствата губят своята валидност, документите и материалните ценности изчезват, а престъпниците успяват да избягат.
Например през 1996 г. UEP получи жалба за измамни дейности на Мисягин, генерален директор на CJSC "Трети Рим". Той трябваше да присвои 90 милиона рубли. Проверката е извършена повече от година и половина. Тогава девето управление на УЕП издава решение за отказ за образуване на наказателно дело. Прокуратурата от своя страна счете това решение за неразумно и възобнови разследването.
Същото се случи и с материалите на Федералния фонд за задължително медицинско осигуряване. Информация за финансови измами в тази структура е получена през януари 1997 г., а полицията започва да я проверява едва месец по-късно. И шест месеца по-късно UEP изпрати материалите до GUEP на Министерството на вътрешните работи. Оттам в края на 1997 г. те отново са изпратени в градската полиция, която в крайна сметка отказва да образува наказателно дело. На прокурорите им отне по-малко от месец, за да изяснят ситуацията и да открият дело.
Общо от 190 материала, проучени от градската прокуратура относно отказа за образуване на наказателни дела, 38 решения бяха отменени. Според 15 материала самата прокуратура е образувала наказателни дела, а според 23 UEP е предложено да се разследва по-внимателно.
Подобна небрежност доведе до факта, че от 1994 г. насам в много случаи измамниците изобщо не се издирват. Срещу тях не са образувани дори т. нар. оперативно-издирвателни дела.
Фактът, че UEP често пренебрегва задължението си да споделя информация за търговски структури с данъчните власти, предизвика особени оплаквания от градската прокуратура. В тази връзка прокурорите твърдят, че системата за регистриране на престъпленията от МВР трябва да бъде прехвърлена на независими структури. Например Министерството на правосъдието, което не е орган за борба с престъпността и не се интересува от приписки. Очевидно на същото мнение е и Борис Елцин, който наскоро подписа указ „За осигуряване на взаимодействието на държавните органи в борбата с правонарушенията в сферата на икономиката“. С този документ той разпореди на правителството до три месеца да разработи единна система за регистриране на разкритите престъпления в икономическата сфера.
Съвсем противоположно е мнението на ръководството на УЕП за резултатите от прокурорската проверка. Началникът на отдела полковник Анатолий Филатов смята, че регистрациите в неговия отдел са принципно невъзможни: „Прокурорите бъркат престъпността от времето на застой и днес. Сега наказателните дела са многоепизодни. И ние разследваме всеки епизод поотделно. Не е за тях, не се задълбочават в материята, взимат материали от зоналния информационен център, виждат, че има много епизоди по делото – ето ти приписката.”
Филатов също се съмнява, че прокуратурата ще може да внесе в съда наказателни дела, приключени от УЕП. „За 20-те си години служба не си спомням да е вкарала прокуратурата в затвора по изоставени материали. След това сами ги затварят, без да открият състав на престъпление“, твърди полковникът.
Трябва да се каже, че подобни конфликти са типични за правоприлагащите органи. Приписванията на разкрития, а с тях и укриването на реални престъпления, се разкриват от прокуратурата във всички полицейски звена, които се проверяват. От времето на застой им се дават доста трудни планове за борба с престъпността свише. Сега от МВР твърдят, че няма такива планове. Но има показатели за борбата с престъпността и те са основният критерий за разпределяне на бонусите, присъждане на звания и назначаване на нова длъжност. Същата система действа и в прокуратурата: колкото повече нейните служители откриват нарушения в работата на полицията, толкова повече ще получават поощрение от своето ръководство. С една дума, получава се порочен кръг - за всеки е изгодно да се занимава с приписки.