Всем привет, меня зовут Ростислав, я расскажу о том, как мы написали доработку для SAP’а, чтобы создавать FI-документы и анализировать финансовую/налоговую отчетность в больших масштабах.
В наше время все развивается с бешеной скоростью, а вместе с этим и постоянно меняются процессы. Такие темпы, мягко говоря, заставляют нас частенько попотеть, потому что релиз ждут еще вчера. В этих условиях нашему подразделению из центра компетенций ERP была поставлена задача по созданию проги для отражения аналитики и управления операциями по базе бухгалтерии. Если чуть подробнее, то от ПО требовалось по прописанным алгоритмам отражать аналитическую информацию и иметь пульт управления бухгалтерскими проводками (FI-документами) по всей базе за отчетные периоды.
*Под пультом управления подразумевается пользовательский интерфейс с действиями по созданию и сторнированию FI-документов*.
Бизнес-процесс, который мы должны были автоматизировать, занимал месяцы, а от нашей разработки ожидали сокращения срока до нескольких часов, с отсутствием трудозатрат. При этом процесс требовалось изменить не только со стороны технической реализации, но и усовершенствовать с точки зрения бизнес-логики.
В таком виде эта задача упала к нам от заказчика: реализовать возможность для пользователя произвести процесс создания большого количество записей в учетной системе ERP при нажатии всего лишь одной кнопки. При этом, чтобы он мог при необходимости отменить созданные операции. Все же любят план «Б».
Первое, что пришло в голову — это безумие. Казалось, нам дали безумное требование, чтобы прога отрабатывала за 2 часа. При этом для создания всех операций из ТЗ требовалось настолько много системных ресурсов, что систему могло и парализовать и сделать работу пользователей в системе дискомфортной настолько, насколько это возможно. Это первая часть беды, а вторая — ПО являлось еще и аналитическим инструментом для принятия решений, что затрудняло вывод всего списка операций в ALV из-за их огромного количества записей.
На первом этапе реализации мы сразу провели анализ роста операций, подлежащих обработке в программе. Оказалось, что количество записей может достигать 1 000 000 за отчетный период. С этой радостной новостью мы вернулись к заказчику и вместе вычеркнули требование «не более, чем 2 часа». Физически данное требование выполнить невозможно, да и мощностей, чтобы потянуть такую задачу, нет.
Описание процесса работы программы
Сначала выводим записи, нужные для обработки в нашей программе. Здесь используем стандартный ALV-инструмент, отображающий все FI-документы в удобном для пользователя формате. Сколько тут было требований от пользователя — и не передать, но после выбора необходимого количества позиций необходимо нажать на кнопку и, наконец, произойдет магия, которая запустит процесс постинга FI-документов по заранее прописанному алгоритму. Как только осуществлен запуск, программа входит в метод по сбору текущей загрузки серверов приложений, где анализирует количество фоновых заданий на каждой из систем. Затем мы оцениваем достаточность ресурсов для проведения операций и устанавливаем порог загруженности в 20% от каждого сервера-приложений. Далее создаем фоновые задания для осуществления проводок по сформированному пулу данных. Как мы делаем проводки? Все просто, мы пропускаем весь пул данных через BAPI_ACC_DOCUMENT_POST для создания прямых операций и BAPI _ ACC _ DOCUMENT _ REV _ POST для их отмены при необходимости, а результат отработки методов записываем в лог программы. После того, как процесс завершен, мы освобождаем заблокированные ресурсы системы.
Проблемы и сложности
Проблема #1. Для соблюдения сроков, определенных заказчиком (1-2 часа), задействовали параллельные запуски транзакций. Итог: падения тестовой системы и сложность устранения ошибок при сбоях работы программы.
Тогда мы зашли в гости к нашим коллегам из базиса и услышали категоричное «Нет. Такое не будет работать». Затем всей бандой мы пошли креативить. Потратив пару дней на мозговой штурм, мы пришли к варианту, что от параллельной работы проги надо отказаться, но решили запараллелить потоки работы программы на разных серверах-приложений. Ну что же, решили сравнить результаты двух подходов.
После положительно прошедших тестов решили переделать процесс создания записей из последовательного в параллельный, что позволило увеличить скорость работы программы. При таком подходе она повышалась от 2 до 10 раз (в зависимости от количества записей), но у распараллеливания были и негативные последствия в виде: падения фонового задания, из-за чего могла не завершиться проводимая операция, или пара записей могла просто не зафиксироваться, нарушая целостность процесса. Столкнувшись с этими рисками, стало понятно, что при этом подходе на исправление последствий мы потратим больше времени, чем если бы он работал в неизмененном виде. Поэтому было принято решение вернуться к последовательной работе программы, что сводило вышеописанные риски к одной ошибке на одно фоновое задание, где количество фоновых заданий на процесс управляется администратором системы.
Проблема #2. Для того, чтобы не уронить систему, нужно было решить проблему с нагрузкой от стандартного функционала в условиях большого количества операций. Причиной проблемы с нагрузкой являлся модуль корреспонденции FI-LOC, а также точки расширения для исключения из модуля создаваемых операций.
Когда мы продумывали функциональность, был расчет на использование стандартных BADI, но одним из наиважнейших и доставляющих неудобства действий данного BADI является вызов события 1025, который включает модуль корреспонденции счетов для каждого прошедшего постинг документа. Из-за того, что этот модуль обрабатывает каждый созданный документ в системе (если такая настройка включена в режиме автоматической корреспонденции счетов), то это вызывает дополнительные ограничения при работе с большими блоками данных, преобразовывающимися в FI-документы. Заполняется количество допустимых блокировок в системе, начинаются проблемы с RFC, что закономерно приводит к критическому состоянию системы. Оставался один выход — звонок в SAP. Ребята подтвердили возможность использования точек расширения в стандартных событиях, где мы исключили из процесса корреспонденции виды документов, нужных для наших процессов. Данный лайфхак может не сработать, если ваш постинг рассчитан на регистр РСБУ, потому что может привести к нагрузке системы в закрытие периода.
Итоги
Во время тестирования мы получали разные цифры по времени отработки программы, но если брать среднее значение, то проводка 1 000 000 записей переваривалась за 1,25 часа, а их сторнирование — за 5 часов. Если сильно повезет и почему-то есть свободные мощности, то все это дело проскакивает еще быстрее.
Искренне советую перед прыжком в подобное болото обязательно проговорить все ожидания как от заказчика, так и от самой системы, а если чуть точнее, то учитывать особенности BTE и особенности внутренних взаимодействий модулей SAP.
P.S. Возможно сделать все.