Разработка механизма массовой загрузки финансовых документов в SAP ERP (часть 1)

Подробности

Опубликовано: 11.09.2025 10:24

Автор: Кирюшин Дмитрий Сергеевич

Просмотров: 138

Аннотация: в статье разрабатывается механизм загрузки финансовых документов в систему SAP ERP. Рассматриваются стратегии доставки программных продуктов: классические модели внедрения, способы сбора требований, методы проектирования процессов, данных и приложений, а также категории тестирования программ. Применяя каскадную модель имплементации, осуществляется анализ, идентификация и приоритизация пользовательских требований, предъявляемых к будущему программному средству загрузки данных в SAP-систему, а также формирование единой матрицы отслеживания требований.
Ключевые слова: SAP разработки, интеграция 1С SAP, SAP S4, модуль SAP ERP, SAP ERP FI, SAP ERP процессы, транзакции SAP ABAP, SAP ABAP ALV, SAP ABAP BAPI, загрузка в SAP, документы SAP, ошибка SAP, SAP SD, загрузка данных.
Скачать: PDF (статья), PDF (выпуск №31).

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

В связи с этим механизмы обработки документов являются частым объектом доработки в ИТ-системах, так как от удобства, интуитивности и представительности этих средств напрямую зависит эффективность работы пользователей и как следствие всей организации [2]. Актуальность тематики данной статьи обусловлена растущими требованиями к скорости обработки финансовых данных, необходимостью минимизации ошибок при вводе и анализе информации, а также повышением требований к удобству программных интерфейсов. Современные подходы к проектированию приложений должны учитывать не только технические аспекты, но и интересы пользователей, что делает эту задачу многогранной и сложной.

1. Цель и задачи

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

• анализ и выбор оптимальных методов и подходов для реализации КИС;
• сбор бизнес и пользовательских требований к реализуемому программному продукту;
• проектирование ИТ-архитектуры будущего решения в разрезе процессов, данных и приложений;
• реализация программного решения с использованием языков программирования VBA и ABAP;
• функциональное тестирование разработанного продукта.

2. Подходы к реализации КИС

Решение любой задачи требует анализа доступных способов ее реализации. Применительно к области информационных систем и технологий доступно несколько научных работ, способных описать ключевые вопросы к проработке: своды знаний по корпоративной архитектуре EABoK [3] и управлению проектами PMBoK [4], а также теория корпоративных информационных систем [5]. Согласно EABoK/TOGAF построение ИТ-архитектуры требует комплексной работы над:

• бизнес-процессами;
• данными;
• приложениями;
• техникой,

которые дополняются двумя поддерживающими активностями PMBoK:

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

и обогащаются релевантными методами и подходами теории КИС. Тогда для реализации программного средства массового ввода финансовых данных необходимо выбрать:

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

что будет задавать стратегию доставки софтверного продукта.

2.1. Обзор моделей, методов и способов

2.1.1. Модели внедрения

Выделают три классические модели разработки программных продуктов и внедрения платформенных софтверных решений (рис. 1), в то время как общеизвестные методологии, например, ASAP, Agile Scrum и 1С: ТКВ, наследуют их принципы работы, максимально детализируя выполняемые задачи [6].

Рис. 1. Классические модели внедрения ПО

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

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

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

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

• определение требований для всех итераций;
• планирование итерации (выбор требований к реализации);
• разработка;
• тестирование;
• демонстрация заказчику;
• сбор обратной связи;
• корректировка требований для всех итераций;
• планирование следующей итерации.

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

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

• определение требований для всех витков;
• планирование работ на текущем витке;
• разработка и тестирование;
• реагирование на возникающие риски;
• оценка результатов витка;
• принятие решения о переходе на следующий виток.

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

2.1.2. Методы сбора требований

Сбор требований – начальный и определяющий шаг работы над программным обеспечением, именно он задает границы проекта, ограничивая объем выполняемых задач. Ниже даны основные методы выявления требований [7]:

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

2.1.3. Способы моделирования бизнес-процессов

Свод знаний по управлению бизнес-процессами BPM CBoK [8] задает графические нотации, позволяющие моделировать операции для состояний AS-IS и TO-BE. Переход из AS-IS в TO-BE осуществляется за счет выявления «узких мест» текущего процесса и их устранения в целевом состоянии. Нотации моделирования разделяют на верхнеуровневые и низкоуровневые, первые дают общее представление о процессе, вторые – максимально детализируют его понимание. Табл. 1 демонстрирует отличительные особенности графических нотаций [9].

Табл. 1. Особенности нотаций проектирования бизнес-процессов

2.1.4. Методы проектирования таблиц баз данных и структуры приложения

Проектирование таблиц баз данных и структуры приложения не предполагает какой-либо вариабельности. Чаще всего под моделированием таблиц данных понимается [10]:

• задание таблиц и атрибутов данных, их типов и размерностей;
• указание простых/составных первичных ключей для таблиц;
• нормализация таблиц баз данных;
• формирование ER-диаграмм между таблицами.

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

Рис. 2. Пример смоделированной структуры приложения

2.1.5. Виды тестирования ПО

Тестирование программного обеспечения – это испытание разработанного приложения с целью проверки его работоспособности и соответствия изначально заявленным требованиям [11]. Выделяют следующие категории тестирования:

• функциональные;
• не функциональные;
• связанные с изменениями,

в контексте которых задают виды испытаний, представленные на рис. 3 и кратко описанные в табл. 2 [12].

Рис. 3. Виды тестирования КИС

Табл. 2. Наиболее распространенные виды испытаний КИС

2.2. Выбор релевантного подхода

Рассмотренные модели, методы и способы реализации КИС, задающие стратегию доставки программному продукта, продемонстрировали особенности выполнения ключевых проектных задач. Принимая во внимание сильные и слабые стороны проанализированных подходов, выберем те из них, которые в дальнейшем будут применяться для доработки SAP-системы:

• каскадная модель разработки. Выбор модели обусловлен статичностью исходных требований и их относительной неизменчивостью на протяжении всего срока проекта;
• интервьюирование как способ сбора и уточнения требований, что мотивировано небольшим числом стейкхолдеров, озвучивающих потребности;
• IDEF0 и BPMN2.0 для верхнеуровневого и низкоуровневого моделирования бизнес-процессов. IDEF0 наиболее используемая нотация для наглядного описания процессов без излишней детализации с учетом ограничений. BPMN2.0 поддерживает концепцию «плавательных дорожек», отображая распределение ответственности и исключая «нагроможденность», свойственную ARIS eEPC;
• функциональное тестирование в виду ограниченной лоскутно-кусочной доработки существующей системы SAP ERP,

а также типовой и единственный метод проектирования таблиц баз данных и структуры приложения, описанный ранее в п.2.1.4. Ссылка на 2-ю часть статьи.

Литература

1. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
2. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. – 164 с.
3. Harrison R. TOGAF certified study guide. Van Haren Publishing, Zaltbommel, 2013. – 324 p.
4. A guide to the project management body of knowledge and the standard for project management, 7th edition. Project Management Institute, 2021. – 369 p.
5. Stepanov, D.Y. (2023). The Theory of Corporate Information Systems. In: Radionov, A.A., Gasiyarov, V.R. Advances in Automation IV. RusAutoCon 2022. Lecture Notes in Electrical Engineering, vol. 986, pp.23-43. Springer, Cham. https://doi.org/10.1007/978-3-031-22311-2_3 – URL: https://stepanovd.com/science/article/144-2022-3-theory.
6. Гудков Е.А., Деревнина А.М., Катасонова Н.С. Анализ каскадной, итерационной и спиралевидной моделей внедрения корпоративных информационных систем // Корпоративные информационные системы. – 2018. – №1. – с. 18-29. – URL: http://corpinfosys.ru/archive/issue-1/48-2018-1-models.
7. Вигерс К., Битти Д. Разработка требований к программному обеспечению. – М.: Издательство Русская редакция, 2017. – 736 с.
8. Свод знаний по управлению бизнес-процессами: BPM CBoK 4.0 / Бенедикт Т., Кирхмер М., Шарсиг М., Франц П., Саксена Р., Моррис Д., Хилти Д. – М.: Альпина Паблишер, 2024. – 504 с.
9. Степанов Д.Ю. Методы проектирования организационной структуры и бизнес-процессов предприятия при внедрении ERP-систем (часть 1) // Корпоративные информационные системы. – 2018. – №4 – с. 50-60. – URL: https://corpinfosys.ru/archive/issue-4/134-2018-4-processes.
10. Стивен Р. Основы проектирования баз данных. – М.: БХВ, 2025. – 768 с.
11. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
12. Терентьев И.М. Стратегия тестирования в проектах имплементации ERP-систем. – 2018. – №3 – с. 39-45. – URL: https://corpinfosys.ru/archive/issue-3/141-2018-3-testingstrategy.

Выходные данные статьи

Кирюшин Д.С. Разработка механизма массовой загрузки финансовых документов в SAP ERP (часть 1) // Корпоративные информационные системы. – 2025. – №3 (31) – c. 19-30. – URL: https://corpinfosys.ru/archive/2025/issue-31/307-2025-31-massuploadinginsaperp.

Об авторе

Кирюшин Дмитрий Сергеевич – выпускник кафедры корпоративных информационных систем института информационных технологий РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Принципы и подходы к построению интерфейсов взаимодействия с финансовыми документами в корпоративных информационных системах». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №31

1. Автоматизация закупочной деятельности в 1С: ERP (часть 1);
2. Механизм загрузки финансовых документов в SAP ERP (часть 1);
3. Об использовании и учете векселей на предприятии;
4. Стратегия завершения использования программного обеспечения;
5. Универсальный передаточный документ в 2026 году.