CRM для Автошколы. Заключение / forpes.ru

Главная
CRM для Автошколы. Заключение

CRM для Автошколы. Заключение +1

08.07.2025 07:24

glu-dimaz 0 434 Источник

Прошло 5 месяцев с последней публикации на тему "разработка CRM для автошколы". Данная статья будет заключительной, и она поставит точку в данном кейсе. Прислушавшись к опытным специалистам и получив оценку все ситуации вокруг данной задачи - я решил: "хватит писать все своими руками, на дворе 2025 год. пора изучать что-то новое и расширять свои познания". Пишем все на Laravel! И поставил для себя цель - что данный проект должен быть именно на нем. Это будет первый мой самостоятельный проект, которой я доведу до состояния продакта.

Я изучил основную концепцию MVC архитектуры веб-приложений. Почитал документацию о фреймворке. Посмотрел ряд видеоуроков, в которых не указаны никакие тонкости в разработке. Ко всему этому, один человек показал мне основы работы с Laravel, познакомил с базовыми пакетами, такими как Laravel Breeze, Permissions, Dto. Спустя несколько месяцев - я освоил базу, и решил начать сначала разработку той самой CRM.

Модели

Я понимал всю бизнес-логику организации, по этому на данном этапе не было никаких проблем. В действующей CRM, вся бизнес логика завязана на "Ученике". Появилась необходимость отойти от этой концепции, в связи с появлением учеников, которые обучаются повторно на альтернативные категории. Необходимо разделить данную модель на "Ученик" -> "Договор".

## Models/Student
/**
 * Договор.
 *
 * @return HasMany
 */
public function agreements(): HasMany
{
    return $this->hasMany(StudentAgreement::class, 'student_id', 'id');
}

## Models/StudentAgreement
/**
 * Ученик.
 *
 * @return BelongsTo
 */
public function student(): BelongsTo
{
    return $this->belongsTo(Student::class, 'student_id', 'id');
}

Модель "Ученик"(Student) содержит в себе статические поля, которые не меняются при заключении новых договоров(ФИО, телефон, дата рождения, паспорт и т.д.). Модель "Договор"(StudentAgreement) - содержит в себе служебные поля, которые могут меняться в зависимости от категории, на которую обучается ученик:

Стоимость обучения по договору
Кол-во часов вождения по договору
Первоначальный взнос
Учебная группа

Модели "договор" имеет служебное поле "overprice" - что устанавливает итоговую стоимость практического занятия. Если overprice = 0, то оплату по сверх договору мы считаем в случае, если у договора количество практических занятий больше, чем указано (hours_total). Если overprice = 1, то оплата практического занятия всегда считается как сверх договор(вне зависимости от количества практических занятий). И если overprice = 2, по аналогии - всегда стоимость по договору.

const OVERPRICE_DEFAULT = 0; // По умолчанию.
const OVERPRICE_YES = 1; // Стоимость всегда сверх урочная.
const OVERPRICE_NO = 2; // Стоимость всегда по договору.

Соответственно, все остальные модели теперь взаимодействуют только с договором, а не с учеником. Не менее важное поле в договоре - school_payment_first, которая регулирует, будет ли в приоритете тариф филиала, в котором проходит практическое занятие или нет. Договору можно установить фиксированную стоимость занятия или закрепить за ним определенный тарифный план.

Модель "Group" - содержит в себе период обучения договоров, их категории и филиалы обучения. Логика приложения требует разделения практически всех моделей на филиалы. А филиалы - собираются в 1 школу.

## Models/Branch
/**
 * Школа.
 *
 * @return BelongsTo
 */
public function school(): BelongsTo
{
    return $this->belongsTo(School::class, 'school_id', 'id');
}

## Models/School
/**
 * Филиалы.
 *
 * @return HasMany
 */
public function branches(): HasMany
{
    return $this->hasMany(Branch::class, 'school_id', 'id');
}

Исходя из того, какому филиалу принадлежит модель StudetAgreement - происходит одно из условий при расчете стоимости практического занятия, а так же - будет ли предоставлена возможность ученику записаться на данное занятие.

До сих пор на карандаше стоит вопрос о расчете баланса договора. Изначально планировал добавить поле "balance" в модели "Договор" и вести учет в нем(это могло бы сократить количество запросов к БД при выборках, ускорив загрузку списков), но в итоге отказался от этого и решил каждый раз его пересчитывать из сумм в других моделях, что тратит больше времени на запросы, чем предыдущий способ. По мне - лучше каждый раз пересчитывать, чем получить рассинхрон между балансом и суммой финансовых операций.

О финансах. Для этого существует модель "Finance", которая хранит в себе все транзакции договоров(списания/поступления).

protected $fillable = [
    'type', // Тип операции.
    'agreement_id', // ID Договора.
    'method_id', // ID Типа операции.
    'date', // Дата операции.
    'examen_id', // Если оплата была за экзамен.
    'sum', // Сумма операции.
    'responsible_id', // ID ответственного.
    'is_first_payment' // Первоначальный взнос?
];

const WRITE_OFF_TYPE = 1; // Списание.
const DEPOSIT_TYPE = 2; // Пополнение.
const EXAM_FEE_TYPE = 3; // Оплата экзамена.

Тут должно быть все понятно: Сумма Finance::WRITE_OFF_TYPE - будет сумма списаний. Сумма Finance::DEPOSIT_TYPE - поступления. Оплата экзамена в расчетах не учитывается - это более информативное поле, о том что ученик оплатил экзамен.

Вернемся опять к балансу. У нас есть поступления и списания из модели "Финансы", но нам необходимо так же учесть списания за практические занятия. На этапе планирования была задумка - реализовать списания за уроки вождения в модели "Финансы" (ученик записался на занятие, создалась запись в финансах с его стоимостью Finance::WRITE_OFF_TYPE) - но не стал. Решил не менять логику расчета баланса от текущей CRM, а оставил так же. Суммы списаний за занятия вождения - хранятся в модели с занятиями "ScheduleEvent". Решил - что проще контролировать 1 значение в модели, чем контролировать 2 значения в 2-х разных моделях. Можно было подумать о связке ключей - но, не. Пока пусть будет так. Исходя из этого, баланс рассчитывается так:

/**
 * Баланс.
 *
 * @return int
 */
public function getBalanceAttribute(): int
{
    $balance = 0;

    foreach ($this->finances()->get() as $fin){
        if ($fin->type == FinanceMethod::DEPOSIT_TYPE) $balance += $fin->sum;
        if ($fin->type == FinanceMethod::WRITE_OFF_TYPE) $balance -= $fin->sum;
    }

    $balance -= $this->schedule()->sum('sum');

    return $balance;
}

Практические занятия собираются из 2 моделей: ScheduleResource и ScheduleEvent. Ресурсы содержат в себе информацию, которая объединяет в себе все события, закрепленные за собой.

Логика приложения

О контроллерах и маршрутах говорить не интересно, поговорим сразу о логике и расчетах. Рассмотрим всю логику от добавления нового ученика к выходу на экзамен.

К нам приходит новый ученик, который хочет пройти обучение на категорию "B". Сотрудник вносит его персональные данные: ФИО, номер телефона, дату рождения и т.д. Далее - мы оформляем новый договор: сотрудник, исходя из заявления, написанного учеником - заполняет данные в модели договора. Ученику предоставляется доступ к его личному кабинету и начинается процесс обучения. Раз в неделю сотрудник автошколы заполняет графики вождения: выставляет инструкторов, транспорт и маршруты вождения. В определенное время происходит открытие этих записей для всех учеников. Необходимо правильно предоставить, доступные для записи, занятия. На данном этапе есть зависимости и критерии, по которым будет она отображаться или нет.

У модели StudentAgreement есть связь с Group, которая на прямую связана с филиалом(Branch). Мы знаем о принадлежности договора к филиалу - значит выборка достпуных ScheduleResource должна формироваться из одинаковых branch_id группы договора и ресурса занятий. У ресурсов есть критерий - "only_overprice", который может регулировать доступность записей только сверх-урочникам, только по договору или по умолчанию. И все эти условия доступности ScheduleResource могут игнорироваться в случае, если за договором закреплен конкретный автомобиль в модели AgreementCar. Если за договором закреплен хотя бы один авто - ему будут доступны записи только с этим автомобилем - другие не будут отображаться.

В процессе записи договора на практическое занятие идет расчет его стоимости. На нее влияют многие условия по мимо overprice.

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

/**
 * Проверим OVERPRICE.
 */
$overprice = false;
if($agreement->overprice > StudentAgreement::OVERPRICE_DEFAULT){
    if($agreement->overprice == StudentAgreement::OVERPRICE_YES) $overprice = 1;
} else {
    if($agreement->hours_now + 1 > $agreement->hours_total) $overprice = 1;
}

/**
 * Проверяем занятие в школе ученика или нет
 */
if($agreement->branch->school_id != $school_id) $agreement_in_his_school = false;

/**
 * Проверка, учитывается ли школа в расчете стоимости
 */
$school_first = 1;

if(!$agreement->school_payment_first) $school_first = false;

/**
 * Если школа приоритетнее И ШКОЛЫ ОТЛИЧАЮТСЯ - вернем стоимость занятия за вождения, как в школе (Если разные школы)
 */
if($school_first AND !$agreement_in_his_school){
    $payment = app(\App\Home\PaymentRate\Actions\Get::class)->getSchoolPayment($school_id, $category_id, $date);
    if($payment){
        if($overprice) return $payment->summ_overprice;
        return $payment->summ_price;
    }
}

/**
 * Если зафиксирован тариф за учеником
 */
if($agreement->payment_rate_id){
    $payment = app(\App\Home\PaymentRate\Actions\Get::class)->getById($agreement->payment_rate_id);
    if($payment){
        if($overprice) return $payment->summ_overprice;
        return $payment->summ_price;
    }
}

/**
 * Если зафиксирована стоимость вождения
 */
if($agreement->summ_price > 0 AND $agreement->summ_overprice > 0){
    if($overprice) return $agreement->summ_overprice;
    return $agreement->summ_price;
}

/**
 * Берем стоимость как в школе ученика
 */
$payment = app(\App\Home\PaymentRate\Actions\Get::class)->getSchoolPayment($agreement->branch->school_id, $category_id, $date);
if($payment){
    if($overprice) return $payment->summ_overprice;
    return $payment->summ_price;
}

Договор проходит обучение до полной выплаты стоимости договора и завершения занятий вождения по договору. Далее - договору назначается экзамен. Никакой замысловатой логики пока тут нет - StudentAgreement -> ExamObject -> Exam . В дальнейшем из перспектив - будет разработка планирования договоров на экзамены. Необходимо производить расчет примерной даты экзамена для договоров, которые повторно пересдают.

Фронт

По фронту не стал продолжать работу над своим дизайном - установил шаблон с bootstrap и не тратил время на построение стилей в css. Все работает на html + jquery. Календарь с графиком практических занятий решил не изобретать самостоятельно, а подключить EventCalendar - аналог FullCalendar (https://github.com/vkurko/calendar).Таблицы где не обходимо делал с фильтрами, используя jquery и ajax.

На данный момент - сотрудники активно тестируют новуб crm и все готовится выйти в продакт. Первый объемный проект на фреймворке Laravel - еще есть что изучить более детально.

CRM для Автошколы. Заключение +1

Модели

Логика приложения

Фронт

Комментарии (0)