Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Автоматизация процесса исполнения налоговых документов в банковской сфере посредством внедрения технологии RPA

Автоматизация процесса исполнения налоговых документов в банковской сфере посредством внедрения технологии RPA

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 10.12.2019
Размер файла 1,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Стоимость решения BPM: Pega BPM. Стоимость лицензий на нашем проекте с учетом 5 стандартных лицензий (2 - для сотрудников Канцелярии и ОД, присутствующих на этапе верификации данных в первое время, 1 - для администратора процесса, 1 - для оператора ввода данных, 1 - для просмотра статистики руководителем) составит 2 040 ($ на чел/год) * 64,76 руб. * 5 = 660 552 руб.

Исходя из описанного плана процесса разработки BPMS-решения на данном проекте (см. п. 2.2.1) внедрение 1 этапа (сбор документов, объединение, штампирование, регистрация в IBM LotusNotes) будет стоить для Pega BPM 1 250 000 руб. с возможностью полноценного запуска на стороне сотрудников Канцелярии и входящим периодом технической поддержки. 2, более сложный и масштабный, этап, включающий в себя проверку возможности исполнения документов, поиск документов, выгрузка и формирование Проекта ответа, а также регистрация исходящих документов, по стоимости внедрения обойдется в 3 000 000 руб. Стоимость технической поддержки по 2 этапу = 20% от стоимости внедрения, т.е. еще 600 000 руб. Стоимость работы 2 сотрудников на этапе верификации (первые полгода после внедрения по 4 ч в день), исходя из расчетов текущего фонда оплаты труда со всеми взносами и вычетами в регулирующие органы: 3 124 800 руб. (затраты в год на 4 сотрудников по 8 ч/день) / 2чел. /2раза(4 ч в день вместо 8) / 2 раза(6 месяцев вместо года) = 390 600 руб.

Итого решение от Pega BPM будет стоить компании-Заказчику = 660 552 + 1 250 000 + 3 000 000 + 600 000 + 390 600 = 5 901 152 руб.

Итого комплексное BPM-решение с распознаванием первичных данных от ИФНС = 5 901 152 + 4 543 000 = 10 444 152 руб.

Стоимость внедрения RPA будет рассчитана, исходя из таблиц 9 и 10.

Таблица 9 Трудозатраты на проект внедрения RPA в банковском секторе

Название ресурса

Трудозатраты, чел.час

Ставка

руб./ч

Затраты с НДС, руб.

1

2

3

4

РП компании-интегратора

136

3 300,00 ?

448 800,00 ?

1.1 Этап 1. Обследование и проектирование

52

3 300,00 ?

171 600,00 ?

1.2 Этап 2. Создание решения

26

3 300,00 ?

85 800,00 ?

1.3 Этап 3. Приемо-сдаточные испытания

36

3 300,00 ?

118 800,00 ?

1.4 Этап 4. Опытно-промышленная эксплуатация

22

3 300,00 ?

72 600,00 ?

Аналитик компании-интегратора

447,2

3 450,00 ?

1 542 840,00 ?

1.1 Этап 1. Обследование и проектирование

96

3 450,00 ?

331 200,00 ?

1.2 Этап 2. Создание решения

187

3 450,00 ?

645 150,00 ?

1.3 Этап 3. Приемо-сдаточные испытания

75,2

3 450,00 ?

259 440,00 ?

1.4 Этап 4. ОПЭ

89

3 450,00 ?

307 050,00 ?

Ведущий разработчик RPA

167

3 300,00 ?

551 100,00 ?

1.2 Этап 2. Создание решения

80

3 300,00 ?

264 000,00 ?

1.3 Этап 3. Приемо-сдаточные испытания

64

3 300,00 ?

211 200,00 ?

1.4 Этап 4. Опытно-промышленная эксплуатация

23

3 300,00 ?

75 900,00 ?

Разработчик RPA

519

3 100,00 ?

1 608 900,00 ?

1.2 Этап 2. Создание решения

128

3 100,00 ?

396 800,00 ?

1.3 Этап 3. Приемо-сдаточные испытания

135

3 100,00 ?

418 500,00 ?

1.4 Этап 4. Опытно-промышленная эксплуатация

256

3 100,00 ?

793 600,00 ?

Итого трудозатраты и стоимость компании-интегратора

1269,2

4 151 640,00 ?

роботизированный автоматизация налоговый банковский

Исходя из таблицы 9 мы видим, что на проект со стороны интегратора планируется затратить 5 970 440 руб. Далее рассчитаем стоимость лицензий для роботизации.

Таблица 10 Расчет стоимости лицензий для проекта роботизации

Лицензии UiPath

Кол-во

Ресурс, в евро

Цена за ед., в рублях (по курсу ЦБ)

Стоимость, руб

UiPath Unattended Robot

3

€ 1 200,00

89 008,56 ?

267 025,68 ?

Studio

1

€ 3 000,00

222 521,40 ?

222 521,40 ?

Итого

489 547,08

Исходя из таблиц 9 и 10, рассчитаем общую стоимость внедрения программных роботов: 4 151 640 + 489 547,08-30% (партнерская скидка) = 4 151 640 + 342 682,96 = 4 494 322,96 руб.

Итоговая стоимость с учетом работы 1 сотрудника ОД в качестве верификатора данных (в первые полгода) и распознавания документов посдством технологии OCR = 4 494 322,96 + 390 600/2(чел) + 4 543 000 - 40% (партнерская скидка) = 7 415 422,96 руб.

2) Время разработки. Среднее время разработки ПО для подобного процесса занимает минимально 1,3 года, с учетом возникающих нюансов 1,5 года. Время внедрения BPMS - от 9 месяцев до 1,2 года, в зависимости от возможных рисковых ситуаций. Внедрение программных роботов (RPA), описанных более подробно в 3 главе, занимает 1 месяц обследования, сбора и формализации требований, 2 месяца разработки и 3 месяца на тестирование и опытно-промышленную эксплуатацию: итого 6 месяцев.

3) Время работы над процессом. Текущее время обработки 1 документа занимает порядка 27 минут на среднестатистического сотрудника. При внедрении ПО предполагается время от 8 до 15 минут, в среднем - 11,5 минут (см. таблицу 10). Время работы BPMS-системы с учетом запусков всех реестров в самой системе и ожидания запросов от внутренних систем Заказчика составит порядка 7-14 минут. Время работы Роботов (RPA) по одному документу занимает, в среднем, 10,2 минуты на 2 процесса (регистрация и исполнение документов) - см. таблицу 11.

Таблица 11 Сравнительный анализ времени работы человека и системы/робота по детальному процессу

Тип активности

Ср. время работы человека, мин

Ср. время работы ПО, мин

Ср. время работы BPMS-системы, мин

Ср. время работы с Роботом, мин

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

2

0,9

0,3

0,5

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

2

0,2

0,2

0,2

Поиск объединения и штампирования Т+П

1

0,7

1

0,5

Процесс регистрации входящего ЭЦП

3

1

1,5

1,0

Исполнение документа

12

5,7

4,5

5,0

Регистрация исходящего

3

1

1,5

1,0

Подготовка проекта ответа для ИФНС

4

2

1,5

2

Итого

27

11,5

10,5

10,2

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

4) Количество ошибок. В текущем процессе количество ошибок достигает 12% в год. При внедрении ПО он должен снизиться до 0,5%. При внедрении BPMS и RPA (исходя из текущей практики компаний) - до 1,3%.

5) FTE. FTE (Full-Time Equivalent) - эквивалент полной занятости (ЭПЗ), мера включенности сотрудника в проект. Так, FTE, равный 1.0, означает, что человек работает при полной занятости, FTE, равный 0.5, говорит о том, что сотрудник работает неполный рабочий день.

Можно предположить, что, если все сотрудники (4) работают полный рабочий день, FTE будет равно 4, однако данные следует подтвердить расчетами. Для расчета необходимо знать количество сотрудников (4), длительность рабочей недели (40 ч), количество недель в году (52), а также количество часов в году (40*52 = 2080 ч).

Итак, для процесса AS-IS сначала определим количество часов в год, которое затрачивается на работу сотрудниками: 4*40*52 = 8 320 полных рабочих часов. Далее делим итоговое количество часов на расчетный период в часах: 8 320/2080 = 4. Это и есть искомый ЭПЗ (FTE).

Для BPMS-решения: (2 сотрудника * 20ч в неделю(полставки) * 52 недели /2полугодия) /2080 = 0,5.

Для RPA-решения: (1 сотрудник * 20ч в неделю(полставки) * 52 недели/ 2полугодия) /2080 = 0,25.

6) Управление рисками. Один из наиболее спорных и сложных моментов расчета, на наш взгляд - это расчет возможных рисков, т.к. он должен включать не только затраты на сами риски (в % или руб.), но и, в идеале, сумму по возможному нивелированию рисков. А так как в текущей ситуации предсказывать риски непросто даже профессионалам (ввиду экономических и политических изменений, не говоря уже о социальных, которые также значительно влияю на процессы), это несколько затрудняет решение. В данном случае приведем данные, исходя из опыта компании, которая на протяжении 3 лет успешно работает на рынке RPA и разработки ПО. Итак, зафиксируем в таблице 12 по каждому пункту %, который потребует существенных доработок системы, что, непременно, скажется на затратах компании.

Таблица 12 Сравнительный анализ вариантов реализации текущего процесса

Критерии оценки

AS-IS

Разработка ПО

Внедрение BPMS-системы

Внедрение RPA

1

2

3

4

5

Стоимость разработки/внедрения/тех.поддержки 1 год/ руб.

8 634 800

11 943 960

10 444 152

7 415 422,96

Стоимость разработки/внедрения/тех.поддержки 2 год/ руб.

8 634 800

1 156 400

660 552

342 683

Стоимость разработки/внедрения/тех.поддержки 3 год/ руб.

8 634 800

1 156 400

660 552

342 683

Затраты за 3 года

25 904 400

14 256 760

11 765 256

8 100 789

Время разработки, мес.

-

18

12

6

Время работы над процессом, мин

27

11,5

10,5

10,2

Количество ошибок, %

12

0,5

1,3

1,3

FTE

4

0

0,5

0,25

Учет возможных рисков, %

Влияние рисков изменения интерфейса

0%

0%

0%

15%

Влияние рисков появления новых параметров/бизнес-исключений

0%

60%

7%

10%

Влияние риска изменения бизнес-процесса

0%

80%

70%

45%

Влияние риска потери качества внедренной технологии/ПО

0%

5%

10%

15%

Влияние риска социальных потрясений

0%

5%

30%

40%

Так, исходя из таблицы 12, можно прийти к выводу, что наименее ресурсозатратным способом автоматизации является внедрение программных роботов. В разрезе 3 лет (срок принят за основу в связи с тем, что видимый и значительный эффект возникает примерно по прошествии этого времени, к тому же, после 1 года затратами являются только лицензии, а это значительно разнится с затратами на сотрудников, эксплуатационные расходы и штрафы) это сэкономит компании 17 803 611 руб. (25 904 400 - 8 100 789) и 1 219 277 руб. - по сравнению с текущей ситуацией в первый год внедрения. Количество ошибок при этом снизится в 9 раз, а длительность выполнения 1 процесса - в 2,5 раза (27/10,2).

По сравнению с индивидуальной разработкой ПО в первый год RPA сэкономит 4 528 537,04 руб., за 3 года - 6 155 971 руб. (во 2 и последующие годы затраты на ПО рассматриваются с точки зрения технической поддержки, исходя из того, что в год разработчик тратит около 330,4 ч при ставке 3500руб./ч - итого 1 156 400 руб.). Также нужно учитывать, что роботов внедрять в среднем 3 раза быстрее, чем разрабатывать собственное ПО. При этом практически все показатели робота близки к показателям индивидуальной разработки, за исключением, разумеется, рисков. Любое изменение интерфейса или незначительные изменения данных повлекут доработку роботов. Однако, во-первых, вносить корректировки в Студию UiPath при серьезных изменениях (когда нужно будет переписывать ПО), например, при изменении внутренней системы Заказчика, ничего не стоит ни по времени, ни по средствам по сравнению с тем, сколько придется дорабатывать собственную разработку.

По сравнению с BPMS RPA экономит 3 028 729,04 руб. в первый год и 3 664 467 руб. за 3 года (последняя цифра довольно велика, т.к. нужно отметить, что лицензии по RPA и технология распознавания обходятся для клиентов дешевле в данном конкретном случае, когда интегратор является золотым партнером компаний и может себе позволить делать такие скидки для клиентов). Время разработки при этом вдвое меньше, а длительность работы решений практически идентичны - BPMS зачастую может работать даже быстрее Робота, т.к. не привязана к интерфейсам внутренних систем. Риски в BPMS составляют нечто среднее между индивидуальной разработкой и Роботом, т.к., с одной стороны, вносить корректировки не составляет большого труда, с другой - в случае изменения бизнес-процесса в BPMS, возможно, нужно будет продумывать новую логику или даже интеграцию, если речь идет о другой системе или способе получения данных. Таким образом, роботизированная автоматизация процессов планово должна окупить свои недостатки по части зависимости от интерфейсов (Робот с минимальной вероятностью может кликнуть не на ту часть экрана/кнопку/виджет, если система зависла, и выполнить другое действие) за счет относительно низкой себестоимости, сжатых сроков реализации проекта и возможности внесения пользователем корректировок в работу Робота.

Подводя итог по 2-ой главе, мы выяснили, что на рынке ИТ-решений достаточно поставщиков систем автоматизации, при этом каждая из технологий и программ может прекрасно подходить и приносить выгоду для одного процесса компании, а для другого быть неподходящей. Роботизированная автоматизация процессов (RPA) наиболее пригодна для более стабильных процессов с четко определенными алгоритмами, большим количеством систем, высокой частотностью - повторяемых и монотонных - с минимальной потребностью задействовать когнитивные функции и максимальной рутинностью ручных операций. При этом RPA отлично подходит для государственной и банковской сфер, где перекодирование внутренних систем экономически нецелесообразно. Из всех поставщиков RPA-решений мы остановились на UiPath по ряду причин: оптимальное соотношение цены и качества, хорошие технические и бизнес-показатели; при этом у компании-интегратора, являющегося потенциальным исполнителем процесса, установлены с UiPath партнерские отношения, что зачастую выгодно и для клиента. В 3 главе рассмотрим непосредственно исследуемый процесс с точки зрения его реализации в виде программных роботов, написанных на платформе UiPath.

3. ПРИМЕНЕНИЕ ТЕХНОЛОГИИ RPA ДЛЯ АВТОМАТИЗАЦИИ БАНКОВСКОГО ПРОЦЕССА

3.1 Предпосылки автоматизации исследуемого процесса

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

Текущий процесс (AS-IS) исполнения документов представляет собой получение Требований отделом Канцелярии, поиск по текущему Требованию соответствующего Поручения (в случае отсутствия Требования Поручение откладывается, в случае отсутствия Поручения Требование регистрируется и по нему запрашивается Поручение у ИФНС, направившей запрос), скрепление данных файлов в формате pdf. Далее скрепленный файл распечатывается, подписывается у руководителя, по нему у Операционного департамента (ОД) запрашивается входящий номер. После выдачи номера (занимает не более 30 минут) он проставляется в виде штампа на первую страницу объединенного документа с датой и присвоенным номером (отличными от дат и номеров требования и поручения). Далее данный документ сканируется, по нему во встроенной системе IBM LotusNotes заводится карточка, регистрирующая данный документ и уведомляющая сотрудников Операционного департамента о его подготовке для исполнения. После получения уведомления сотрудник ОД открывает программу ExcelRep, вводит пароль для входа в систему, вбивает ИНН в нужное поле для поиска конкретного клиента, после чего открывает таблицу счетов и филиалов по данному контрагенту. В случае, если клиент обслуживается только в филиалах, сотрудник ОД отправляет данный входящий документ через форму IBM LotusNotes ответственным за данный филиал сотрудникам; в противном случае он продолжает работу. Начиная с первого истребуемого документа, сотрудник заходит по очереди в каждую базу, в которой должен находиться определенный документ; авторизуется в ней, вбивает ИНН и расчетный счет (последнее - в случае банковских выписок и депозитных документов) и ищет действующий документ за определенный период, указанный в требовании. После нахождения всех документов, сотрудник выгружает их в определенную папку, запрашивает по описанной выше логике номер для исходящего документа, регистрирует его и готовит шаблон ответа для ИФНС в соответствии с текущими контрагентами, счетами и найденными документами.

Более детально процесс отражен на схеме, представленной в Приложении А (рис. А1). Данный процесс был изначально проанализирован на стороне компании-Заказчика (банка) - после выбора наиболее приемлемого решения стало необходимо проверить процесс на пригодность для автоматизации при помощи технологии RPA, - после чего прошел базовый отбор на потенциальную возможность для роботизации со стороны исполнителя (включая меня по части аналитики). Критерии, по которым производился отбор процесса, представлены в таблице ниже (см. Таблицу 12).

Таблица 13 Анализ пригодности процесса для роботизации [29]

Критерии

Соответствие

Комментарий

Процесс с большим объемом транзакций

+

Обработка от 400 до 800 документов в день

Часто повторяемый процесс (ежедневный/еженедельный)

+

Ежедневный

Процесс со стандартными и согласованными входными данными

+/-

ИФНС запрашивает, как правило, однотипные документы, но в разных формулировках

Процесс, запускающийся по нечитаемым типам входных данных (без OCR)

+/-

До начала работы Робота входные данные обрабатывает партнер - FlexiCapture

Процесс, построенный на основе правил (с четкими инструкциями по обработке)

+

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

Хорошо документированный, стабильный процесс

+

Процесс выполняется в одних и тех же системах около 7 лет

Известные эксплуатационные расходы

+

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

Процесс, позволяющий обеспечить экономию min 2-х рабочих ставок

+

По прогнозам, Робот будет заменять 4 рабочие ставки

Исходя из таблицы 13 мы видим, что процесс абсолютно удовлетворяет по 6 критериям из 8, а именно:

это процесс с обработкой большого количества информации;

он происходит ежедневно;

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

процесс стабилен на протяжении 7 лет;

известны все издержки, которые несет предприятие в рамках данного процесса (помимо оплаты труда самих сотрудников);

процесс позволит сэкономить 4 рабочие ставки (планово).

В среднем весь процесс объединения, штампования, регистрации, исполнения документов и подготовки ответа для ИФНС занимает у среднестатистических сотрудников Канцелярии и Операционного департамента 27 минут. При этом количество ошибок и неточностей (опечатка при наборе названия/ИНН/расчетного счета/ФИО клиента, если это физическое лицо и т.д.) на каждом из подэтапов (сопоставление Требования и Поручения, регистрация входящего документа, поиск документов в базах и системах, подготовка Проекта ответа) достигает, по оценкам сотрудников аналитического отдела банка, порядка 12%. Все это, разумеется, влечет за собой штрафные санкции со стороны Федеральной налоговой службы, а неточность собранных данных при этом часто порождает ошибки при дальнейшем формировании подобных документов (например, если сотрудник привык прикреплять к ответу все копии паспортов, не обращая внимания на количество и даты, ему будет сложно переучиться в том случае, если в базу данных будут поступать архивные документы по клиентам (если была изменена фамилия или после 45 лет). Подробнее эффект от фактического внедрения Робота будет рассмотрен в п. 3.4 текущей работы.

Таким образом, при анализе процесса было выявлено, что он подходит для автоматизации посредством технологии RPA, в связи с чем мы как компания-интегратор приступаем к его проектированию.

3.2 Проектирование процесса TO-BE

Ниже описан проектируемый процесс внедрения программного робота на исследуемом предприятии. На рисунке 8 изображена Studio UiPath с работающим процессом регистрации входящего документа при использовании режима проектирования flowchart (блок-схем).

Рисунок 8 Проектирование автоматизированного процесса TO-BE (Регистрация входящего документа)

В Канцелярию поступают Требования и Поручения из ИФНС (отдельные PDF, doc/docx, JPEG, PNG-файлы). Сотрудники Канцелярии размещают их в специальной папке ImportFolder Abbyy на корпоративном сетевом диске (структура папок описана в таблице п..

Система (Abbyy Flexi Capture, партнер компании-интегратора, т.к. встроенный функционал OCR в UiPath является недостаточным для подобного рода проектов) идентифицирует файлы и текст в них, определяет, что является Требованием и Поручением, и соотносит соответствующие Требования. По тексту Требования ниже следует информация о наличии Поручения к нему:

номер может совпадать;

номер может быть неполным;

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

Сопоставив Требования и Поручения, Робот объединяет их в один файл, присваивает свободный порядковый номер (ЭЦП-№-Р) и штампует. Если в направленном объеме документов остаются:

Требования без Поручений, они регистрируются и передаются на исполнение;

Поручения, оставшиеся без Требований, не подлежат регистрации.

После разбора Робот формирует журнал Требований и Поручений в Excel в отчете «Результат работы робота».

В системе документооборота LotusNotes БД "Канцелярия" в разделе «Входящие» Робот создает карточку документа и размещает в ней объединенный документ.

Робот сохраняет учетную карточку как проект в разделе «Входящие» БД "Канцелярия" системы документооборота LotusNotes в учетной карточке. Карточка содержит следующую информацию:

корреспондент;

вид документа;

исходящий номер и дата;

краткое содержание документа;

количество листов и приложений в документе;

фамилия подписавшего документ;

структурное подразделение и фамилия исполнителя, которому направляется документ;

фамилия Руководителя Банка, наложившего резолюцию в документе, и текст резолюции.

Система документооборота формирует уведомление о созданном Роботом проекте документа и отправляет сотруднику, ответственному за регистрацию таких документов в Канцелярии УДО ДКУ (далее - Ответственный сотрудник).

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

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

Робот проставляет штамп установленного образца, содержащий дату регистрации и входящий номер.

По определенному алгоритму Робот оценивает возможность исполнения Требования. А именно, Требование не может быть исполнено, если:

период запроса не попадает в период обслуживания налогоплательщика;

нет клиента;

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

разные налогоплательщики в Требовании и Поручении;

Требование и Поручение ошибочно направлено не в тот банк.

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

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

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

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

По завершении процесса Робот должна зарегистрировать отсканированные документы в LotusNotes БД "Канцелярия" в карточке исходящего документа. В карточке отражается следующая информация:

Корреспондент

Краткое содержание

Дата (фактический день регистрации)

Исх. Номер

Фамилия исполнителя

ФИО подписанта

Номер входящего письма (ЭЦП-№-Р).

Прикрепленный проект ответа.

В виде бизнес-схемы процесс можно описать следующим образом (рис. 9-10).

Рисунок 9 Распознавание входящих документов и их регистрация в IBM LotusNotes

На данном рисунке (рис.9) представлен предварительный процесс подготовки документов для первого Робота (Робот 1) посредством работы FlexiCapture по части распознавания текста документов, а также процесс регистрации документов Роботом 1 в БД «Канцелярия» LotusNotes.

Рисунок 10 Исполнение документов для ИФНС

На рисунке 10 показан основной процесс работы второго и третьего Роботов (Робот 2 и Робот 3 соответственно) по исполнению документов, регистрации исходящих документов и подготовке Проекта (шаблона) ответа для ИФНС. Далее более подробно рассмотрим проектирование конкретного роботизированного процесса на основе данных, необходимых в процессе разработки Робота.

3.3 Особенности проектирования процесса для RPA

Для текущего процесса используется 3 Attended (с оператором) Робота (3 соответвтующие лицензии) и Studio без Orchestrator. При этом Роботы большую часть работ выполняют сами, то есть фактически выполняют задачи Unattended роботов за более низкую стоимость. Роль Оркестратора при этом (запуск свободного робота в каждый определенный момент времени и остановка, если произошел сбой), как было замечено во 2 главе работы, производит скрипт, в котором прописано, какой Робот (под каким «именем») какой задачей должен заниматься. Робот 1 занимается процессом сбора, сравнения данных, маппингом, штампированием, объединением Требования и Поручения и регистрацией полученного входящего документа «ЭЦП-№-Р» (как правило, это занимает минимум времени и влечет минимальное количество ошибок), Роботы 2 и 3 выполняют всю основную работу - исполняют Требования, т.е. занимаются поиском документов во всех базах данных и приложениях, понимают, по какому контрагенту/ИНН/расчетному счету какой документ запрашивается, где он находится и какие именно данные (архивные/действующие) им нужно выгружать. Завершающим процессом регистрации исходящего документа и подготовкой Проекта ответа для ИФНС занимается освободившийся Робот 2 или 3 по тем документам, которые на первых этапах (в рамках опытно-промышленной эксплуатации) подтверждает Верификатор (сотрудник Операционного департамента, который в рамках проекта проверяет корректность работы Робота). Ниже в таблице 14 представлен перечень систем, в которые должен иметь доступ второй Робот для исполнения Требования (выгрузки документов).

Таблица 14 Перечень систем, участвующих в автоматизации процесса

№ п/п

Название системы

Филиал/ГО

ЮЛ/ФЛ

Роль

Продуктивная среда

Тестовая среда

1

2

3

4

5

6

7

1

Новая Афина (ДРО - Договоры на расчетное обслуживание)

Головной офис (Москва)

-

-

PSB

tdb3

2

Новая Афина (ДРО)

Ставропольский ф-л

-

-

PSBF

tsf16

3

Новая Афина (ДРО)

Ярославский ф-л

-

-

PSBF

tsf16

4

Новая Афина (ДРО)

Южный ф-л

-

-

PSBF

tsf16

5

Новая Афина (ДРО)

Питерский ф-л

-

-

PSBF

tsf16

6

Новая Афина (ДРО)

Приволжский ф-л

-

-

PSBF

tsf16

7

Новая Афина (ДРО)

Дальневосточный ф-л

-

-

PSBE

tse15

8

Новая Афина (ДРО)

Сибирский ф-л

-

-

PSBE

tse15

9

Новая Афина (ДРО)

Уральский ф-л

-

-

PSBE

tse15

10

Новая Афина (РО - Расчетное обслуживание)

Головной офис (Москва)

-

-

PSB

tdb3

11

Новая Афина (РО)

Ставроп. ф-л

-

-

PSBF

tsf16

12

Новая Афина (РО)

Ярославский ф-л

-

-

PSBF

tsf16

13

Новая Афина (РО)

Южный ф-л

-

-

PSBF

tsf16

14

Новая Афина (РО)

Питерский ф-л

-

-

PSBF

tsf16

15

Новая Афина (РО)

Приволжский ф-л

-

-

PSBF

tsf16

16

Новая Афина (РО)

Дальневосточный ф-л

-

-

PSBE

tse15

17

Новая Афина (РО)

Сибирский ф-л

-

-

PSBE

tse15

18

Новая Афина (РО)

Уральский ф-л

-

-

PSBE

tse15

19

АКД (Архив клиентских дел)

-

ЮЛ

udul_usor

?

dm_akd_test

20

АКД

-

ФЛ

udfl_common_readers

?

?

21

Ритейл

-

-

-

?

?

22

SAP BO BI

-

-

-

?

?

23

Excel Rep (ПСБ/Первобанк)

Головной офис (Москва)

-

-

PSB

tdb3

24

Excel Rep (ПСБ/Первобанк)

Ставропольский ф-л

-

-

PSBF

tsf16

25

Excel Rep (ПСБ/Первобанк)

Ярославский ф-л

-

-

PSBF

tsf16

26

Excel Rep (ПСБ/Первобанк)

Южный ф-л

-

-

PSBF

tsf16

27

Excel Rep (ПСБ/Первобанк)

Питерский ф-л

-

-

PSBF

tsf16

28

Excel Rep (ПСБ/Первобанк)

Приволжский ф-л

-

-

PSBF

tsf16

29

Excel Rep (ПСБ/Первобанк)

Дальневосточный ф-л

-

-

PSBE

tse15

30

Excel Rep (ПСБ/Первобанк)

Сибирский ф-л

-

-

PSBE

tse15

31

Excel Rep (ПСБ/Первобанк)

Уральский ф-л

-

-

PSBE

tse15

Из таблицы 14 можно увидеть, что в основном подпроцессе (выгрузке документов) задействовано 6 приложений с разными ролями и доступами внутри систем. Первый Робот (осуществляющий регистрацию документов) при этом работает в 7-ой системе - IBM LotusNotes. Это еще раз подтверждает вывод из п. 3.2 текущей работы о том, что процесс отлично подходит для роботизации: чем больше в работе человека задействовано систем, тем выше вероятность, что действия могут быть выполнены в разы быстрее и эффективнее при внедрении программного робота.

Все выгруженные при этом данные хранятся на сетевом диске, структура которого также была разработана нами для удобства Робота и Flexi Capture (FC) (см. Таблицу 15).

Таблица 15 Структура папок сетевого диска

Название папки

Путь к папке

Описание

1

2

3

Импорт (Робот)

\\Flexy-app\export

Содержит папки с названиями обработанных (распознанных) пакетов

ExportFolder Abbyy

\\Flexy-app\export

Папка тождественна папке Импорт (Робот)

«Exceptions» ExportFolder Abbyy

\\Flexy-app\export\EXCEPTIONS

Папка исключений Flexi Capture

Batch_<Идентификатор>

Любая папка в

Импорт (Робот)

Папка обработанного пакета в корне папки Импорта, в которой хранится XML-файл и исходный документ Требования или Поручения.

Исключения составляют папки, начинающиеся с символа «~»; папки с названиями «xsd», «exceptions».

Исключения Робота

Data\Input\abbyyOutput\~Ошибка обработки

В данную папку Робот отправляет документы, которые не может обработать в рамках стандартного сценария (например, XML-файлы без связанных PDF)

Отложенные Поручения

Data\Input\abbyyOutput\~Отложенные поручения??

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

Папка результатов обработки Требований

Data\Output

Упрощенный отчет работы робота (РРР) по всем Требованиям хранится в корне папки результатов обработки Требований

ЭЦП

Data\Output\ЭЦП

Содержит набор папок "ЭЦП-n-Р-Требование-m" с исполненными Требованиями

ЭЦП-n-Р-Требование-m

Data\Output\ЭЦП\ ЭЦП-n-Р_Требование-№m

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

Папка Отработки

Data\Input\abbyyOutput\~Обработанные пакеты

В папку Отработки отправляются все файлы из Batch-папок обработанных пакетов, с которыми невозможна дальнейшая работа Робота (PDF-файлы без связанных XML)

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

Сам процесс распознавания документа на стороне FC строится не только на непосредственном считывании текста с изображения/PDF, но и на сопоставлении выгруженных данных с конкретными полями, чтобы Робот сразу мог понять, какое значение внести в какое поле при регистрации в LotusNotes или же какие документ ему нужно искать. При этом в алгоритм работы FC встраиваются атрибуты для Поручения и Требования с названиями полей и признаком обязательности/множественности, по которым система может считать то или иное поле и сопоставить его с тегом в XML-файле (см. таблицы А3-А4 Приложения А). Структура XML-файлов представлена в пп.1 и 2 Приложения А данной работы. Сопоставление полей XML-файла и Детального отчета работы Робота, который он создает, начинает заполнять с момента получения документа и в который вносит дополнения в процессе работы с данным ЭЦП, представлено на таблице 16. Подобный отчет (упрощенный) приведен в таблице А6 Приложения А данного диссертационного исследования.

Таблица 16 Соответствие полей XML-файла (Требование) и Детального отчета работы робота (ДРРР)

Название тега XML

Название поля ДРРР

1

2

<_DocNumber>

Требование

<_DocDate>

Дата требования

<_Company>

Наименование проверяемого

<_CompanyINN>

ИНН проверяемого

<_Account>

Дублирование информации в поля:

Расчетный счет проверяемого

Расчетный счет контрагента

<_Name>

Контрагент

<_INN>

ИНН контрагента

<_CommisionNumber>

Поручение

<_CommisionDate>

Дата поручения

<_PeriodFrom>

Период запроса ОТ

<_PeriodTo>

Период запроса ДО

<_NeedDocKey>

Запрашиваемые документы

<_NeedInfoKey>

Запрашиваемые документы

Исходя из таблицы 16 мы видим, что все основные поля XML-файла, подготовленного FC, попадают в Детальный отчет работы Робота, необходимый пользователям для отслеживания аналитики и работы с возможными ошибками автоматизации. Сам отчет также сопоставим с полями, которые необходимо заполнить Роботу в LotusNotes (таблица 17).

Таблица 17 Соответствие полей ДРРР и Входящего документа БД "Канцелярия"

Название поля ДРРР

Название поля Входящего документа

Название ФНС

Корреспондент

Дата регистрации*

Поле "Дата" в разделе "Поступление"

№ вхд.

Поле "Номер" в разделе "Поступление"

Дата требования

Поле "Дата" в разделе "Отправка"

Требование

Поле "Номер" в разделе "Отправка"

Один из вариантов:

Наименование проверяемого

Контрагент

Краткое содержание

Примечание:

Если нет хотя бы одного контрагента, то заполнение на основании поля "Наименование проверяемого".

В ином случае - на основании поля "Контрагент".

Заполнение списка контрагентов начинается после символов "по ".

Если несколько контрагентов - разделяются символами "; "

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

«а также все документы, касающиеся обслуживания счета» -

Договор банковского счета

Заявление на открытие счета

Заявление о присоединении к Правилам комплексного банковского обслуживания

Иные документы по картам

Карточка с образцами подписей и оттиска печати

Устав

Приказ о назначении, вступлении в должность, предоставлении права подписи

Свидетельство о государственной регистрации юридического лица

Свидетельство о постановке на учет российской организации в налоговом органе

Договор банковской карты/ Заявление на открытие счета

Протокол (решение) о создании, назначении, внесении изменений в документы.

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

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

3.4 Анализ эффективности внедрения технологии RPA на предприятии

На текущий момент (14.05.2019) реализована первая часть процесса (см. Рисунок 9 в п. 3.2): разработан 1 Робот, внедрена система FlexiCapture. Процесс начинается с того, что в горячую папку FC (ImportFolder Abbyy) поступают в хаотичном порядке Требования и Поручения. FlexiCapture их распознает, Верификатор проверяет, FC автоматически создает XML-файл и отправляет документы в папку Импорт (Робот). Далее реализуется процесс 1-го Робота (описанный подробно в п. 3.2), он завершается тем, что все Требования и Поручения распределены по папкам, парные Требования и Поручения и одиночные Требования зарегистрированы в LotusNotes. Более подробно реализация процесса описана в Программе и методике испытаний, основная часть из которой описана ниже.

Итак, для проведения первого этапа тестирования предусмотрены следующие входные параметры:

На Рабочем месте установлен Робот.

На Рабочем месте создана Временная папка.

Во Временную папку скопированы два произвольных файла Файл №1 (пустой файл в формате txt) и Файл №2 (пустой файл в формате pdf).

Сформирован пакет из 10 документов в виде PDF-файлов, включающий Поручения и Требования.

Поступающие сканы документов на распознавание должны быть отсканированы с разрешением не менее 300 dpi.

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

Для проведения тестирования выполнены следующие предусловия:

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

Пара связанных документов (Поручение и основанное на нем Требование) по ИП;

Пара связанных документов (Поручение и основанное на нем Требование) по ФЛ (физическим лицам);

Пара связанных документов (Поручение и основанное на нем Требование) по множественным контрагентам-ЮЛ (юридическим лицам);

Пара связанных документов (Поручение и основанное на нем Требование) по контрагенту-ЮЛ;

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

Произвольные документы разных форматов Файл №1 и Файл №2.

Определены Рабочие места пользователей с установленным ПО Станции верификации.

На Рабочем месте установлен Робот.

Включены в тестовое окружение:

Серверы ABBYY FlexiCapture 12: Сервер приложений, Сервер защиты (лицензирования), Сервер обработки, Сервер базы данных;

Станции ABBYY FlexiCapture 12: Станция настройки проектов, Станции обработки.

Определен пользователь с ролью Старший оператор верификации.

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

Папки Импорта (ABBYY) и Экспорта (ABBYY) пустые.

Исполнитель тестирования (далее Пользователь) открыл на одном компьютере (Рабочем месте) Приложение для отслеживания работы Робота - среда разработки UiPath Studio (далее Приложение Робота).

Робот имеет данные для входа в приложение Lotus Notes БД «Канцелярия» с правами создания карточек Требований.

Установлены следующие настройки Робота:

количество повторов действий Робота при возникновении ошибки - 3 повтора;

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

Папки Исключений, Отложенных поручений, Отработки, Папка результатов обработки Требований пусты.

Далее в таблице 18 следует сам сценарий тестирования, позволяющий проверить стандартный сценарий (когда во FlexiCapture поступают Требования и Поручения по форме КНД), а также дополнительные файлы, которые должны переместиться в папку Исключений на этапе распознавания FC.

Таблица 18 Сценарий тестирования (1 этап)

№ п/п

Проверяемые

функции

Порядок действий

Ожидаемый

результат

1

2

3

4

1

Автоматический импорт документов

1. Скопировать пакет документов, включающий 5 пар Требований+Поручений и 2 произвольных файла, в папку Импорта (ABBYY)

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

В системе создан пакет для обработки

2

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

1. Запустить Монитор Сервера обработки

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

3. Открыть станцию Настройки проектов

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

Документы, тип которых автоматически определить не удалось, отмечены как <Неизвестный>.

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

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

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

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

3

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

1. Открыть Станцию Верификации

2. Выбрать проект

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

4. Нажать кнопку «Получить задание» или сочетание клавиш Ctrl+G

5. Проверить задание.

6. Проверить список полей, из которых производится извлечение данных на соответствие с п. 7.1.2 Проверяемые требования (п. 1 Требования по извлечению атрибутов для документов типа «Поручение»; п. 3 Требования по извлечению атрибутов для документов типа «Требование»).

7. Проверить вывод ошибок при отсутствии данных в обязательных.

8. После завершения обработки задания нажать кнопку «Закрыть задание» и, тем самым, отправить задание на этап экспорта.

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

Неуверенно распознанные символы

Для исправления неуверенно распознанных символов, ошибок формата и правил доступен режим Окно документа, в котором отображаются исходное изображение, извлекаемые данные (окно «Форма данных») и окно ошибок.

Не определен тип документа

В случае, если системой не был определен тип документа, он должен быть отмечен как <Неизвестный>. Такие документы оператор может распознать принудительно. Для этого необходимо наложить нужное определение документа, вызвав правой кнопкой мыши контекстное меню и выбрав пункт «Наложить определение документа...», после чего повторно вызвать контекстное меню и выбрать «Распознать» (или через пункт меню Сервис Распознать).

Проблемные пакеты

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

Также Старший оператор верификации имеет следующие возможности, недоступные под ролью Оператор верификации:

1. Просматривать Очередь исключений для обработки проблемных пакетов.

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

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

На станции Верификации задание доступно.

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

Задание, прошедшее проверку, отправлено на этап экспорта.

Список полей для распознанных документов соответствует п. 7.1.2 Проверяемые требования (п. 1 Требования по извлечению атрибутов для документов типа «Поручение»; п. 3 Требования по извлечению атрибутов для документов типа «Требование»).

4

Экспорт данных осуществляется в файл формата XML

1. Открыть ExportFolder Abbyy.

2. Убедиться в наличии xml-файлов по документам, которые были проверены и отправлены на этап экспорта.

После окончания обработки документов на Станции верификации все 10 парных документов (без некорректных файлов) отправляются на этап экспорта в горячую папку ExportFolder Abbyy, доступ к которой имеет система назначения.

В папке ExportFolder Abbyy присутствуют xml-файлы с соответствующими им pdf-файлами в количестве 10 шт.

В папке «Exceptions» ExportFolder Abbyy присутствуют Файл №1, Файл №2.

5

Регистрация карточек в Lotus Notes БД "Канцелярия"

Пользователь запустил Робота в Приложении Робота.

Пользователь наблюдает процесс журналирования регистрации карточек под сформированные требования в приложении Lotus Notes БД "Канцелярия".

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

По окончании процесса регистрации карточек приложение Lotus Notes БД "Канцелярия" закрывается.

6

Проверка соответствия контрольных значений

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

Контрольные значения для первого этапа обработки Роботом папки Импорт совпадают с фактическими.

Контрольные значения для первого этапа проверки прямого сценария работы системы, включая тестирование распознавания документов в системе ABBYY FlexiCapture:

В упрощенном отчете работы Робота (РРР) присутствует 5 записей со статусом «Зарегистрировано».

Папка Импорта пустая.

Папка Отработки пустая.

Папка Исключения пустая.

Папка Отложенные поручения пустая.

В любой созданной в приложении Lotus Notes БД "Канцелярия" карточке Требований значения полей соответствуют полям Детального отчета работы Робота (ДРРР) для данного требования.

В любой папке Требований (ЭЦП-n-Р-Требование-m) из папки Data\Output\ЭЦП значения полей файла Детального отчета работы Робота (ДРРР) соответствуют полям XML-файла.

Создано 5 pdf-файлов (с соответствующими xml-файлами) с проштампованными Требованиями с Поручениями в соответствующих папках «ЭЦП-n-Р-Требование-m» (путь Data\Output\ЭЦП).

В приложении Lotus Notes БД "Канцелярия" создано 5 карточек ЭЦП-n-Р.

В папке «Exceptions» ExportFolder Abbyy присутствуют Файл №1, Файл №2.

Так, 14 мая процесс был принят компанией-Заказчиком на тестовом контуре. В результате были получены следующие документы:

Упрощенный отчет работы робота

Детальный отчет работы робота

Бизнес-лог.

Упрощенный отчет работы робота (без документов, контрагентов, расчетных счетов) представлен в таблице А6 Приложения А. Он представляет собой перечень полей по Требованию, Поручению, номер входящего документа (ЭЦП), даты регистрации входящего, наименования проверяемого с ИНН, название и номер ИФНС, истребующей документы; период запроса, номер исходящего (не заполнен на текущий момент, т.к. исходящие регистрируются в конце всего процесса, после исполнения документов), статус документа и путь к папке, в которой находится Детальный отчет работы Робота.

В детальном отчете (см. таблицу А7 Приложения А), помимо текущих, присутствуют поля по контрагентам, их ИНН и счетам; поля по расчетным счетам проверяемого; более подробные данные по ИФНС (индекс, адрес для заполнения Проекта ответа), список документов для исполнения, поле комментария, количество выгруженных документов по каждой строке, результат поиска документов. Данный отчет необходим пользователям для детальной сверки того, что выполняет Робот и что будет направлено в ИФНС. Также благодаря онлайн-отчету, который Робот заполняет в режиме реального времени, сотрудник-верификатор может отследить, например, какой документ не найден, и выяснить причину.

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

Таблица 19 Бизнес-лог по всем данным

Начало обработки

Окончание обработки

Документ

Задача

Статус

Комментарий

1

2

3

4

5

6

2019.05.14 16:03:21

2019.04.14 16:03:21

Поручение 370

Получение

Успешно

Данные_00000001.

xml

2019.05.14 16:03:21

2019.04.14 16:03:21

Поручение 1226

Получение

Успешно

Данные_00000005.

xml

2019.05.14 16:03:21

2019.04.14 16:03:21

Поручение 2165

Получение

Успешно

Данные_00000009.

xml

2019.05.14 16:03:21

2019.04.14 16:03:21

Поручение 2046

Получение

Успешно

Данные_00000011.

xml

2019.05.14 16:03:21

2019.04.14 16:03:21

Поручение 253

Получение

Успешно

Данные_00000012.

xml

2019.04.14 16:03:24

2019.04.14 16:03:24

Требование 7759 ЭЦП-198-Р

Получение

Успешно

Данные_00000013.

xml

2019.04.14 16:03:24

2019.04.14 16:03:24

Требование 7768 ЭЦП-199-Р

Получение

Успешно

Данные_00000021.

xml

2019.04.14 16:03:24

2019.04.14 16:03:24

Требование 8198 ЭЦП-200-Р

Получение

Успешно

Данные_00000031.

xml

2019.04.05 16:03:24

2019.04.05 16:03:24

Требование 8209 ЭЦП-201-Р

Получение

Успешно

Данные_00000033.

xml

2019.04.05 16:03:26

2019.04.05 16:03:26

Требование 3946 ЭЦП-202-Р

Получение

Успешно

Данные_00000037.

xml

2019.04.14 16:03:26

2019.04.14 16:03:28

Требование 7759 ЭЦП-198-Р

Сопоставление

Успешно

Поручение 370

2019.04.14 16:03:28

2019.04.14 16:03:28

Требование 7768 ЭЦП-199-Р

Сопоставление

Успешно

Поручение 1226

2019.04.14 16:03:30

2019.04.14 16:03:30

Требование 8198 ЭЦП-200-Р

Сопоставление

Успешно

Поручение 2165

2019.04.14 16:03:30

2019.04.14 16:03:32

Требование 8209 ЭЦП-201-Р

Сопоставление

Успешно

Поручение 2046

2019.04.14 16:03:32

2019.04.14 16:03:34

Требование 3946 ЭЦП-202-Р

Сопоставление

Успешно

Поручение 253

2019.04.14 16:03:36

2019.04.14 16:04:32

Требование 7759 ЭЦП-198-Р

Регистрация

Успешно

Новый

2019.04.14 16:04:32

2019.04.14 16:05:25

Требование 7768 ЭЦП-199-Р

Регистрация

Успешно

Новый

2019.04.14 16:05:25

2019.04.14 16:06:13

Требование 8198 ЭЦП-200-Р

Регистрация

Успешно

Новый

2019.04.14 16:06:13

2019.04.14 16:07:11

Требование 8209 ЭЦП-201-Р

Регистрация

Успешно

Новый

2019.04.14 16:07:11

2019.04.14 16:08:02

Требование 3946 ЭЦП-202-Р

Регистрация

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены