Разработка программного обеспечения для автоматизации бизнес-процессов снабжения предприятия на основе каскадной модели внедрения (часть 2)

Аннотация: в статье исследуется бизнес-процесс закупок и разрабатывается веб-приложение, позволяющее автоматизировать формирование потребностей на закупку. Проектирование ПО завершается построением структуры таблиц баз данных и схемы приложения, следуя своду знаний TOGAF. В дальнейшем ведется кодирование интернет-программы, состоящей из Frontend и Backend-частей, согласно клиент-серверной архитектуре. Применение готовых библиотек Bootstrap и Axios позволило получить софтверное решение, отлично показавшее себя в ходе функциональных испытаний и удовлетворившее исходные требования к ПО.
Ключевые слова: управление взаимоотношения с поставщиками, система управления взаимоотношениями с поставщиками, заявка на закупку товаров, управление закупочной деятельности, система SRM закупки, система SAP SRM, comindware, максмарт SRM, ER диаграмма базы данных, модель ER диаграммы, программный интерфейс API, json формат, библиотека react, bootstrap, frontend разработка, веб разработка frontend.
Скачать: PDF (статья), PDF (выпуск №34).

5.2. Формирование таблиц баз данных

Ссылка на 1-ю часть статьи. Проектирование структуры базы данных является критическим этапом создания программной системы, так как именно от него зависит полнота представления процессов, хранения информации и возможность масштабируемости решения [12]. Воспользуемся реляционной моделью данных, приведённой к третьей нормальной форме (3НФ), что устранит избыточность и логические аномалии, а также повысит целостность информации.

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

• Supplier, представляет информацию о поставщике, с которым работает организация. Содержит контактные данные, статус активности, используется в заявках на поставку. Один поставщик может быть участником множества заявок и поставлять множество товаров;
• Product – справочная таблица с номенклатурными данными. Хранит уникальный идентификатор товара, название, категорию и единицу измерения. Один товар может указываться во множестве заявок, поставок и возвратов;
• SupplierProduct, реализует отношение «М:М» между поставщиками и товарами. Показывает, какие именно товары может поставить конкретный поставщик, что позволяет ограничивать их выбор при оформлении заявки и формализует ассортимент;
• Request – заявка на поставку товаров от конкретного пользователя заданному поставщику. Хранит дату, статус (например, создана, подтверждена, выполнена), ссылки на пользователя и поставщика. Одна заявка может включать множество товарных позиций и быть связана с одной/несколькими фактическими поставками;
• RequestPosition – позиции внутри заявки, связывающие ее с конкретными товарами. Содержит количество и цену. Взаимосвязана с сущностями Request и Product;
• Delivery, включает сведения фактической поставки, исполненный в рамках заявки. Содержит дату, статус исполнения (полная, частичная, отклонённая), а также ссылки на инициатора поставки и саму заявку. Одна заявка может иметь несколько связанных поставок;
  
• DeliveryPosition – позиции, входящие в поставку. Каждая строка содержит информацию о фактически поставленном количестве товара. Взаимосвязана с сущностями Delivery и Product, что позволяет фиксировать как полное, так и частичное исполнение заявок;
• Return, оформляется при выявлении отклонений в поставке. Хранит дату возврата, причину, флаг обработки и внешние ключи на поставку и пользователя, оформившего возврат. Один возврат может быть связан с одной поставкой, но включать несколько товаров;
• ReturnPosition – отражает конкретные товарные позиции, подлежащие возврату. Связана с таблицей DeliveryPosition, что позволяет точно зафиксировать, какой товар из какой поставки в каком количестве был возвращён.

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

Рис. 5.11. ER-диаграмма данных реализуемого приложения

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

5.3. Моделирование структуры приложения

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

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

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

Рис. 5.12. Карта разрабатываемого приложения

6. Разработка программной системы

Разработка веб-приложения велась с применением клиент-серверной архитектуры, в рамках которой логика приложения разделена на две автономные части: Backend и Frontend. Связь между ними осуществляется через REST API. Такое разделение повышает гибкость разработки, упрощает тестирование и позволяет независимо развивать различные части системы.

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

Рис. 6.1. Концептуальная архитектура разрабатываемого решения

6.1. Реализация Backend-части

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

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

Каждая сущность, соответствующая предметной области (например, Supplier, Product, Request, Delivery), представлена в виде JPA-класса, связанного с таблицей в базе данных. Для каждого типа данных предусмотрен DTO-класс, формирующий данные, передаваемые клиенту или получаемые от него. Контроллеры получают валидированные DTO-объекты, передают их в сервисный слой, где происходит обработка и обращение к базе данных через репозиторий. Результаты также преобразуются в DTO и возвращаются клиенту в виде JSON.

Функциональность Backend-приложения реализуется через отдельные сервисы, каждый из которых отвечает за одну бизнес-сущность:

• SupplierService реализует всю бизнес-логику, связанную с поставщиками;
  
• ProductService отвечает за управление справочником товаров;
  
• RequestService работает с заявками на поставку;
  
• RequestPositionService управляет позициями заявки;
  
• DeliveryService регистрирует фактические поставки;
  
• DeliveryPositionService управляет составом поставки;
  
• DashboardService собирает агрегированные данные по заявкам, поставкам, товарам и поставщикам;
  
• ReturnService обрабатывает возвраты товаров из поставки;
  
• ReturnPositionService ведет отдельные позиции в возврате;
  
• SupplierProductService связывает поставщиков и доступные для них товары.

6.2. Доработка Frontend-части

Клиентская часть приложения разработана с использованием библиотеки React, что позволило построить гибкую модульную систему. Для обеспечения адаптивной и визуально удобной структуры используется фреймворк Bootstrap [12], а библиотека Axios [13] применяется для обмена данными с сервером.

Проект разработки состоит из: директории src/pages для отдельных страниц (например, Suppliers.jsx, Products.jsx), папки src/components для переиспользуемых элементов интерфейса, а также src/api, необходимой для организации API-запросов. Навигация между страницами реализована через библиотеку React-router-dom [14], где каждому маршруту соответствует отдельный компонент. Каждая страница отвечает за определённую сущность и/или процесс системы:

• Dashboard.jsx отображает обобщённую информацию в виде статистики и уведомлений. Присутствуют визуальные блоки, показывающие количество поставщиков, товаров, заявок и поставок. Система уведомлений выводит актуальные события, например, изменение статусов заявок или поставок (рис. 6.2);
  

Рис. 6.2. Главная страница программы

• Suppliers.jsx отображает таблицы поставщиков с возможностью добавления, редактирования и удаления записей. Пользователю показывается список зарегистрированных поставщиков, где каждая строка может быть раскрыта для просмотра деталей. Доступны кнопки добавления нового поставщика и редактирования существующего (рис. 6.3);
  

Рис. 6.3. Страница поставщиков

• Products.jsx управляет справочником товаров. Включает таблицу с товарами, кнопки создания и удаления, а также всплывающие модальные окна для ввода информации о товаре. Страница поддерживает сортировку и поиск по наименованию (рис. 6.4);
  

Рис. 6.4. Страница товаров

• Requests.jsx представляет интерфейс работы с заявками. Отображается реестр всех созданных заявок с возможностью перейти к подробному просмотру их состава. Страница включает отображение связанных поставщиков и позиций (рис. 6.5);
  

Рис. 6.5. Реестр заявок

• Deliveries.jsx содержит информацию о фактических поставках. Пользователь может просматривать историю поставок, связывать поставки с заявками и подтверждать их выполнение. Реализованы просмотр состава каждой поставки и возможность инициировать возврат (рис. 6.6).

Рис. 6.6. Страница поставок

Маршруты страниц описаны в компоненте index.jsx. Каждый маршрут отображает соответствующий компонент без перезагрузки страницы. Для обмена данными с сервером используются функции, определённые в src/api. Каждая сущность имеет свой файл, где описаны процедуры обращения к соответствующим Backend-маршрутам. Все запросы отправляются с помощью Axios, а структура ответов обрабатывается внутри компонентов.

Таким образом, клиентская часть приложения реализует весь необходимый набор пользовательских сценариев. Благодаря использованию React и Axios обеспечивается динамичное взаимодействие с серверной частью. Совокупность страниц, маршрутов и API-вызовов формирует полнофункциональный пользовательский уровень системы, тесно связанный с Backend-архитектурой и реализующий интерфейс взаимодействия с данными в режиме реальном времени.

7. Функциональное тестирование

Для подтверждения работоспособности и качества разработанной программной системы было проведено всестороннее испытание [15]. Проверка охватывала все ключевые компоненты решения. Было необходимо убедиться в том, что приложение корректно обрабатывает действия пользователей, обменивается данными между клиентом и сервером и сохраняет целостность информации при различных сценариях использования. Функциональное тестирование проводилось вручную через интерфейс пользователя с использованием API-запросов. Ниже дана таблица сценариев тестирования, соответствующих реализованной содержанию (табл. 7.1).

Табл. 7.1. Результаты функционального тестирования

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

Заключение

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

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

Реализация программной системы осуществлялась на основе клиент-серверной архитектуры с использованием современных технологий Spring Boot 3, React и Axios, а также PostgreSQL в качестве СУБД. Все разработанные компоненты интегрировались через REST API, а архитектура приложения была структурирована согласно принципу многослойности с четким разделением обязанностей.

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

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

Литература

1. Логистика / Дыбская В.В. и др. – М.: Эксмо, 2009. – 944 с.
2. Свод знаний по управлению бизнес-процессами: BPM CBoK 4.0 / Бенедикт Т., Кирхмер М., Шарсиг М., Франц П., Саксена Р., Моррис Д., Хилти Д. – М.: Альпина Паблишер, 2024. – 504 с.
3. Стандарты корпоративных информационных систем [Электронный ресурс] // База знаний научно-популярного сетевого журнала «Корпоративные информационные системы». – Режим доступа: http://corpinfosys.ru/knowledgebase/standards (дата обращения 31.03.2026).
4. Демьянов Н.А. Требования к программному обеспечению: от подготовки до управления изменениями (часть 1) // Корпоративные информационные системы. – 2024. – №1 (25) – с. 16-22. – URL: https://corpinfosys.ru/archive/2024/issue-25/271-2024-25-requirements.
5. Официальный сайт AGORA SRM [Электронный ресурс]. – Режим доступа: https://agora.ru (дата обращения: 31.03.2026).
6. Официальный сайт Comindware [Электронный ресурс]. – Режим доступа: https://comindware.com (дата обращения: 31.03.2026).
7. Официальный сайт ELMA365 [Электронный ресурс]. – Режим доступа: https://elma365.ru (дата обращения: 31.03.2026).
8. Официальный сайт Максмарт SRM+ [Электронный ресурс]. – Режим доступа: https://maksmart.ru/ (дата обращения: 31.03.2026).
9. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
10. Harrison R. TOGAF certified study guide. Van Haren Publishing, Zaltbommel, 2013. – 324 p.
11. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
12. Bootstrap.com [Электронный ресурс] // Документация. – Режим доступа:
    https://getbootstrap.com/docs/5.3/getting-started/introduction/ (дата обращения: 31.03.2026).
13. Axios [Электронный ресурс] // Документация. – Режим доступа: https://axios-http.com/docs/intro (дата обращения: 31.03.2026).
14. React.dev [Электронный ресурс] // Документация. – Режим доступа: https://react.dev/learn (дата обращения: 31.03.2026).
15. Терентьев И.М. Стратегия тестирования в проектах имплементации ERP-систем. – 2018. – №3 – с. 39-45. – URL: https://corpinfosys.ru/archive/issue-3/141-2018-3-testingstrategy.

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

Латыев А.Р. Разработка программного обеспечения для автоматизации бизнес-процессов снабжения предприятия на основе каскадной модели внедрения (часть 2) // Корпоративные информационные системы. – 2026. – №2 (33) – c. 1-20. – URL: https://corpinfosys.ru/archive/2026/issue-34/336-2026-34-srm. 

Об авторе

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

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

1. Разработка ПО для автоматизации процессов снабжения (часть 2);
2. Разработка Telegram-бота для автоматизации ремонтных работ (часть 2).