Где деньги, Зин? Или как загрузить информацию из банка, если у вас 200 000 операций в день?

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

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

Проблематика

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

Мы можем это делать разными способами:

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

• Стандартная технология – это клиент-банк, когда бухгалтер или казначей заходит в банк, сохраняет выписку в текстовый файл, и потом подтягивает этот файл в обработку клиент-банка, которая есть в типовой 1С:Бухгалтерии. Загружает, создает документы.

Эту историю автоматизировать не всегда нужно. Особенно, если у нас один клиент, сто выписок, бухгалтер или казначей сам утром зайдет, все проверит, загрузит. У него все будет отлично – ему не нужно сильно напрягаться. Но если у вас 50, 100, 200 клиентов, или у вас много организаций и 30 банковских счетов в разных банках, то эта операция для бухгалтера представляется примерно так:

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

Попробуем каким-то образом это автоматизировать.

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

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

Задачи автоматизации

Какие действия нам нужно автоматизировать:

• Нам нужно получить информацию о платежах. При этом следует учесть, что у каждого банка есть какое-то свое определенное время, когда закрывается банковский день. Обычно, это 4-5 часов утра. Если мы знаем это время для каждого банка, с которым интегрируемся, мы можем сразу же после этого время подать автоматический запрос в банк и получить выписку. Конечно, мы будем это делать разными способами. Дальше расскажу.

• Следующая задача – нам нужно загрузить платежи в нашу базу.

• Дальше мы документы авторазносим – определяем их на правильные счета, проставляем аналитики и проводим.

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

Получаем информацию по платежам

Начнем решать первую задачу. Мы будем получать выписки из банка разными способами.

• Если у банка есть API, можно получать по API. Конечно, у разных банков API бывает настроен по-разному. У кого-то запрос по получению выписок отдает файл только целиком за день. У кого-то запрос отдает текст по 100 операций за раз. В любом случае, у API есть преимущество, потому что его достаточно легко автоматизировать. Но банки уже понимают, что многие начинают автоматизировать загрузку по API, и за использование API берут деньги (использование API обычно тарифицируется начиная с 10 или 100 тысяч операций в месяц).

• Следующий способ – это RPA. Это автоматизация процессов. У нас есть определенный робот, который эмулирует работу казначея или бухгалтера. Заходит в банк и каким-то образом выписку получает.

• Естественно, можно использовать ДиректБанк.

• Или вообще просить банк высылать файл на почту и его как-то обрабатывать.

Сейчас мы у себя используем RPA. На слайде представлена OneRPA – это наша кроссплатформенная разработка, которая как раз роботизирует процессы. Она нативно работает с 1С, и у нее есть много коннекторов к другим системам. Это нам позволяет напрямую подключиться к 1С, но также использовать и распознавание образов и т.д. Здесь приведен пример роботизации загрузки выписки из банка «Авангард», у которого API нет. Зато мы можем таким достаточно быстрым способом эмулировать работу бухгалтера – получить файл выгрузки, куда-то его сохранить и дальше его использовать для загрузки.

Также применимы все RPA-инструменты, которые используются для тестирования в браузере. Например, опенсорсный фреймворк Selenoid тоже можно использовать для получения выписки. Мы можем целиком эмулировать работу бухгалтера воспроизведением сохраненной последовательности нажатия кнопок в браузере.

С какими банками у нас есть подключение по API?

• Сбер

• Точка

• Тинькофф

• Альфа

Чем хорошо API? Быстро подключились, каким-то образом данные получили.

База для хранения выписок – АЗКБ, автозагрузка клиент-банка

Но нам нужно каким-то образом хранить всю эту информацию о подключении, о сохранении файла и т.д.

Конечно, у нас CRM, в которой наши аккаунт-менеджеры ведут контрагентов, договора и прочее. Но хранить выписки в такой базе будет небезопасно.

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

Почему отдельная база?

• Быстрее обновлять.

• Это безопасно.

• Мы можем эту базу поместить в отдельный контур, доступ к которому будет только по определенным правилам – это важно для безопасности.

На слайде представлена схема, как будет работать эта отдельно стоящая база.

База называется АЗКБ, автозагрузка клиент-банка – она представлена в правой части слайда.

База АЗКБ хранит в себе список контрагентов, для каждого из которых определен способ получения выписки:

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

  • синхронное соединение – мы обращаемся в банк и ждем, пока он нам отдаст выписку, используется обычное прямое соединение;

  • асинхронное соединение – это те банки, которые нам отдают выписки через какое-то время. Здесь мы уже подаем запрос, потом раз в какое-то время опрашиваем, что выписка сформировалась, мы ее можем забрать и сохранить;

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

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

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

Как будет работать дальше?

• На стороне базы клиента у нас есть внешняя обработка, которую мы запускаем по расписанию – раз в 15-30 минут. Эта обработка запрашивает напрямую нашу CRM – мы идентифицируем базу контрагента, сопоставляем ее с контрагентом, которому нужно отдать выписки, и идем в нашу базу АЗКБ, где эта выписка уже должна была сохраниться (или нет).

• Если в базе АЗКБ для этого клиента есть выписка, мы ее отдаем.

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

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

Загрузка состоит из:

• чтения файлов;

• создания документов;

• и процедуры авторазноски – про нее рассказывал Евгений Винниченко в своем докладе.

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

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

• не смог контрагент правильно подставиться;

• или нет такого банковского счета у организации;

• или еще какие-то проблемы, которые тоже можно автоматизировать в дальнейшем, но на данном этапе мы о них просто оповещаем.

Здесь на схеме тоже есть элементы обращения в Elastic и заполнения данных для подбора из доклада Евгения Винниченко.

Страхуемся от ошибок

Мы уже автоматизировали таким образом 300-400 контрагентов. Это работает. Идет загрузка, все ок. Но нам нужно добавить немного страховки, чтобы не было проблем.

Что мы делаем?

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

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

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

  • Тестированием;

  • Некоторые изменения в модулях мы делаем через &ИзменениеИКонтроль. Так мы можем сразу видеть, если что-то не работает;

  • И что-то мы делаем через замену типовых процедур целиком – это, конечно, придется проконтролировать. Чтобы это реализовать, достаточно написать тесты.

• И на первичном этапе мы никак не блокировали ручную загрузку документа. Могла быть ситуация, когда казначей зашел в типовую обработку, загрузил выписку, и в этот же момент запустилась загрузка выписки по регламенту. Типовая загрузка такие ситуации обрабатывать не умеет. Она, когда разбирает файл, формирует список документов, которые нужно загрузить, и потом их создаст в любом случае. Если у нас это произойдет одновременно, эти документы задублируются. Избежать этого можно несколькими способами:

  • Влезть в типовую процедуру и добавить туда какой-то контроль, что у нас регламент не запущен.

  • Или, наоборот, со стороны регламента проверять, что у нас не запущена типовая загрузка.

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

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

Обеспечиваем безопасность запроса через токен

Но работать так с внешними клиентами небезопасно – мы не можем выставить этот сервис наружу, чтобы кто-то запрашивал выписки.

И нам пришлось решать эту проблему.

Чтобы выставить сервис в интернет, мы использовали Mule ESB. Так как нам нужно каким-то образом гарантировать безопасность запроса, мы для этой цели используем валидацию запроса.

Схема валидации состоит из того, что нам нужно:

• Создать токен на доступ.

• Потом как-то его проверить.

• Если все ок, мы действительно можем посылать запрос к целевой системе

Разберем подробнее:

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

• К нам в редирект с Mule ESB на CRM поступает запрос на токен.

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

На втором этапе у нас идет выполнение запроса, где нам нужно токен проверить. Здесь для ускорения мы еще использовали Redis.

Как это выглядит?

• Первично запрос поступает на сторону Mule ESB.

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

• Например, мы можем настроить время хранения токена в Redis полчаса или час, а загрузку выписок запрашивать каждые 15 минут. Соответственно, когда реально придет выписка, у нас вот этой задержки времени для обращения в CRM не будет, и запрос будет работать быстро.

Про логирование

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

На слайде показаны примеры из Anypoint Exchange, в котором мы разрабатываем интеграцию с Mule ESB.

• Верхняя схема – это как раз валидация запроса.

• А нижняя схема – это сохранение каких-то ошибок в очередь RabbitMQ, которая уже в асинхронном режиме будет сложена в определенные индексы ElasticSearch. И дальше мы уже можем каким-то образом оповещать ответственных – настроить Zabbix, настроить X-Pack. Это уже, в принципе, не так важно.

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

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

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

Многопоточность

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

Т.е. ранее мы по разным контрагентам грузили по 10, 20, 100 тысяч операций в день. И тут к нам приходит клиент, у которого 200 тысяч операций в один поток.

Это вообще нереально. Типовая загрузка на таком объеме упадет. Она даже не разберет файл, потому что ей в типовой форме загрузки клиент-банка нужно отобразить 200 тысяч строк. Они будут бесконечное количество времени грузиться.

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

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

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

Таких мест достаточно много. Если мы хотим ускорить загрузку, их нужно убрать. Понятно, что когда мы грузим 100 выписок, это непринципиально. Но когда у нас большие объемы, приходится с этим разбираться.

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

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

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

Соответственно нам в зависимости от нашего железа нужно экспериментально выяснить, какое количество фоновых заданий действительно может ускорить загрузку. Обычно это от 5 до 7 заданий, которые в целом ускорят загрузку в 3-4 раза.

На слайде приведен пример самой простой загрузки, которую можно написать за 5 минут. Лучше, конечно, сделать не так примитивно. Но для примера пойдет.

Шаблоны разноски

Такой автоматической схемы не хватает, потому что у нас 200 тысяч операций. Если мы будем в Elastic искать наиболее похожий документ и т.д., это будет очень долго.

С этим клиентом нам повезло. У него было 95% примерно типичных операций, которые можно было как-то разобрать и разнести по каким-то определенным правилам.

Это можно сделать через шаблоны разнесения.

Самая обычная история – мы берем схему СКД, добавляем туда какие-то условия, отбираем по этим условиям документы и разносим их по шаблону.

Так как у нас 95% операций одинаковые, мы:

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

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

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

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

Итоги

Это привело к тому, что:

• Наш контур достаточно безопасный, потому что в нем есть получение токена.

• У нас 95% документов разносятся автоматически, потому что кроме системы поиска похожих документов есть шаблоны разнесения, которые бухгалтера и казначеи могут сами под свою базу руками настраивать. А еще можно эти шаблоны через CRM перекидывать между базами. Т.е. эта система подстраивается под каждого клиента.

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

Немного полезных ссылок

• //infostart.ru/1c/articles/1418759/ – про многопоточность

• //infostart.ru/1c/articles/387232/ – про многопоточность

• https://wiseadvice-it.ru/uslugi-1s/avtomatizaciya-na-baze-1s/integraciya-1s-s-sberbusinessapi-fintechapi/

• //infostart.ru/1c/articles/1163224/ – про RPA

• https://www.onerpa.ru/

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.