Корреспонденция счетов бухгалтерского учета в BW on HANA

28 августа 2017 |

В статье описывается методология и техническая реализация системы OLAP отчетности по корреспонденции счетов на платформе SAP BW on HANA

Введение в проблему

Словарь экономических терминов дает следующее определение понятия: "Корреспонденция Счетов – это метод ведения бухгалтерского учета, при котором каждая операция отражается одной и той же суммой в двух счетах: дебете одного и кредите другого". При таком строгом толковании термина, очевидно, что SAP "Корреспонденцию Счетов" не поддерживает. Принятая в модуле FI концепция Документа обладает большой гибкостью, что особенно важно при формировании автоматических проводок. Однако если мы заглянем в другие словари, то сможем найти менее строгое толкование. Например, Большой Энциклопедический словарь утверждает, что "Корреспонденция Счетов – это взаимосвязь между счетами бухгалтерского учета при регистрации хозяйственной операции способом двойной записи". При таком "облегченном" подходе задача сводится к разбиению каждого FI документа на пары корреспондирующих позиций. Этот подход был реализован в ряде получивших широкое распространение программ, наиболее известная из которых включена в российскую локализацию. Все эти программы работают в ERP системе, что влечет за собой следующие проблемы:

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

Решение проблем

В настоящей статье предлагается альтернативное решение, свободное от вышеперечисленных недостатков. А именно, предлагается перенести расчет корреспонденции и всю связанную с ней отчетность в SAP BW. Действительно,

стандартная экстракция реплицирует FI документы в BW хранилище, и основная работа по расчету корреспонденции делается в рамках обычного процесса трансформации данных, что полностью разгружает ERP сервер;
стандартный OLAP инструментарий позволяет легко формировать отчеты практически произвольной сложности, обладающие мощными средствами навигации и фильтрации данных;
использование технологии Business Rules Framework Plus (BRFplus) позволяет полностью отказаться от настроечных таблиц и дает дополнительный бонус в виде высокой производительности, поскольку сконфигурированные правила определения корреспонденции автоматически компилируются в исполняемый АВАР код.

Алгоритм решения

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

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

Сразу возникает несколько вопросов. Во-первых, что имеется в виду под словом документ в шаге 1. Ответ не столь очевиден. Часто одна хозяйственная операция приводит к автоматическому созданию нескольких FI документов. Примерами являются перемещения ТМЦ и ОС между заводами или балансовыми единицами (БЕ), оплаты открытых позиций из других БЕ, перевыставление расходов и т.д. Для такого рода операций в каждой БЕ создается отдельный FI документ, и всем созданным документам присваивается единый общий номер (поле BKPF-BVORG). Если балансовые единицы принадлежат одному юридическому лицу и мы хотим исключить 79 счет из определения корреспонденции, то необходимо группировать позиции дебетов и кредитов в шаге 1 по этому общему номеру, тем самым объединяя вместе логически связанные друг с другом первичные FI проводки.

Следующий вопрос касается интерпретации приоритетов в шаге 3. Если мы говорим, что "чем выше приоритет, тем более вероятна корреспонденции", то логично запретить отрицательные значения и интерпретировать приоритет равный 0, как запрет корреспонденции. Также следует зафиксировать некоторое максимально возможное значение приоритета (например, 1.000.000), соответствующее 100%-ой вероятности. Применение описанного выше алгоритма может привести к тому, что корреспонденция для части позиций документа останется неопределенной. Если таких документов немного, то они могут обрабатываться специальными более сложными алгоритмами (для чего может использоваться технология BAdI), либо анализироваться визуально бухгалтером, поскольку запрещенная корреспонденция в документе может свидетельствовать об ошибке, сделанной в момент проводки.

Вопрос к шагу 6: что следует сохранять? Дублирование всех полей основной и корреспондирующей позиций (уже имеющихся в базе данных) не выглядит разумным. Сохранять следует необходимый минимум информации, а именно ключевые поля (БЕ, номера документов и их позиций) и суммы. SAP BW on HANA позволяет эффективно строить OLAP отчетность на объектах соединенных операциями JOIN в композитных провайдерах и Calculation View. Тем самым, доступны абсолютно все поля из заголовков и позиций документов, что позволяет легко строить такие востребованные отчеты, как:

оборотные ведомости по дебиторам и кредиторам с корреспонденцией счетов;
анализ отклонений на 16 счетах в разрезе номеров материалов или основных средств, которые имеются в корреспондирующих позициях;
анализ перевыставляемых расходов и расчетов между БЕ с исключением 79 счетов;
разделение условных и фактических начислений расходов и доходов по корреспондирующим балансовым счетам и многие другие.

Техника Calculation View позволяет легко вводить в отчетность счета синтетического учета (например, первые 4 символа номера аналитического счета) без необходимости создания атрибутов навигации для признака 0GL_ACCOUNT, тем самым, не усложняя стандартную структуру данных.

Тонкости реализации алгоритма. Демонстрационный пример

В рамках архитектуры корпоративных хранилищ данных LSA++, разделяются уровни передачи данных (Data Propagation Layer) и витрин данных (Architected Data Mart Layer). Исходные данные финансовых документов хранятся в aDSO, принадлежащих первому уровню, результаты расчета корреспонденции должны сохраняться в aDSO, принадлежащем второму. Сам процесс расчета происходит в пользовательской программе (user routine) трансформации, связывающей эти два aDSO. Семантическое группирование позволяет разбить поток данных на пакеты таким образом, чтобы каждый документ попадал целиком в один пакет. В итоге получается, что кодирование алгоритма, описанного выше, требует менее 200 строк АВАР. Следует отметить, что этот код является абсолютно универсальным и переносимым. Механизм распараллеливания при запуске процесса переноса данных (DTP) позволяет поднять производительность в 10 и более раз, по сравнению с однопоточным выполнением, без каких-либо усилий со стороны разработчика. Звучит слишком просто, не правда ли? Где же спрятаны все сложные правила определения приоритетов для корреспондирующих позиций? В BRFplus функции, вызываемой в user routine трансформации на шаге 3 описанного выше алгоритма. Эта функция имеет два входящих параметра: анализируемые позиции по дебету и кредиту, и один исходящий – целочисленный "Приоритет" корреспонденции, как показано на Рис. 1.