Проектирование интеграционного решения для автоматизации детской футбольной школы

Детская футбольная школа имеет базу данных детей и их родителей, в которой более 7000 уникальных записей. На данный момент посещаемость, продление абонементов и напоминания об оплате происходять в ручном режиме через ERP‑систему.

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

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта

Чтобы автоматизировать процесс и защитить систему от некорректных данных, в наешй работе — это попытки записать ребенка в группу, не соответствующую его возрасту, логика интеграции должна быть строго регламентирована. Валидация данных выполняется на стороне ERP‑системы до того, как транзакция попадет в базу данных.

Схема взаимодействия систем / UML Sequence Diagram

Диаграмма последовательности описывает два сценария взаимодействия между сайтом, ERP‑системой и Базой Данных:

• Позитивный: данные проходят внутреннюю валидацию возраста, создается запись в MySQL, и сайт получает ответ 200 OK с подтверждением регистрации.

• Альтернативный: возраст ребенка не соответствует лимитам группы, ERP‑система прерывает процесс и возвращает сайту ошибку 422 Unprocessable Entity, не нагружая базу данных лишними запросами.

Проектирование и тестирование API‑контракта в Postman

Перед началом разработки бэкенда спроектированный контракт был протестирован с помощью Mock‑сервера в Postman. Для эмуляции реального поведения системы были настроены динамические ответы в зависимости от передаваемых параметров и заголовков.

При успешной валидации Mock‑сервер возвращает статус 200 OK. Пример успешного запроса:

При ошибке валидации на выходе получается ошибка 422 Unprocessable Entity и сообщение о том, что ребёнок не подходит по возрасту.

Реализация архитектуры данных на уровне СУБД

В этой работе в качестве СУБД использовался MySQL. После успешного проектирования сквозных процессов и API‑контрактов необходимо расписать логику решения на уровне физического хранения данных. Для автоматизации учета футбольной школы была спроектирована реляционная структура из трёх нормализованных таблиц. Ниже представлен SQL‑код, описывающий структуру этих таблиц:

Для проверки работоспособности схемы в таблицы были внесены тестовые записи. Вместо вывода разрозненных идентификаторов мы используем оператор INNER JOIN для связывания таблиц, а также встроенную функцию CONCAT. Она склеивает имя и фамилию родителя из разных ячеек, разделяя их пробелом, и формирует единое ФИО в результирующей колонке «Родитель».

Выгрузим данные для проверки нашей БД.

Результат:

Схема автоматизации уведомлений и платежный шлюз

Для достижения ключевой цели проекта — минимизации задержек оплат — была спроектирована логика автоматического взаимодействия с внешними провайдерами: Платежным шлюзом и СМС‑шлюзом. Процесс автоматизации разделен на три последовательных этапа:

1. За 3 дня до окончания абонемента — проверка и выставление счета;

2. Момент оплаты — оработка Webhook;

3. Обработка должников.

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

Схему автоматизации можно представить с помощью BPMN‑диаграммы:

Заключение:

Внедрение спроектированного интеграционного решения позволило успешно оптимизировать операционные процессы футбольной школы и обеспечить стабильное развитие коммерческих показателей бизнеса. Ключевым экономическим результатом автоматизации стало повышение конверсии в повторные оплаты абонементов с 78% до 91% за счет перехода на проактивные уведомления с прямой платежной ссылкой.

Таким образом, интеграция ERP‑системы с внешними сервисами объединила программные модули и финансовые потоки в единую отказоустойчивую систему, функционирующую в строгом соответствии с заложенной бизнес‑логикой.