Как спроектировать веб-приложение для автопарка: связка машина-водитель-событие, журнал операций, отчеты по расходам, напоминания по ТО и контроль штрафов.
Почти всегда все начинается с Excel: отдельная таблица по ТО, отдельная по штрафам, еще одна по расходам, а сканы путевых листов лежат в почте или в мессенджере. Пока машин 3-5, это терпимо. На 10+ машинах «одна табличка» быстро превращается в несколько версий, где данные расходятся, а правду приходится собирать вручную.
Главная причина бардака простая: нет единого журнала событий. Когда каждое событие живет в своем файле, чате или папке, вы неизбежно:
Через пару месяцев выясняется, что «все вроде записывали», но никто не может ответить, что было с конкретной машиной и водителем за последнюю неделю.
Пользователей обычно несколько, и у каждого своя боль: диспетчеру нужно понимать, кто на какой машине и что просрочено; бухгалтерии - счета, оплаты и документы; руководителю - где утечки и кто выбивается из нормы; водителю - штрафы, поездки и возможность быстро приложить чек.
Понять, что пора уходить от таблиц к приложению, легко: если задачи завязаны на напоминания, подтверждения и историю по связке «машина -> водитель -> событие», Excel уже не вытянет. Простой пример: штраф пришел на машину, платить должен водитель, бухгалтерии нужна отметка об оплате и документ. В таблице это быстро превращается в переписку, пропущенные сроки и «а кто вообще отвечал?».
Чтобы приложение не превратилось в набор разрозненных экранов, начните с простой связки: машина, водитель и событие. ТО, штрафы, путевые листы, заправки и прочие расходы - это частные случаи события с разными полями и правилами.
Если заводить отдельные сущности под каждую задачу, быстро появятся дубли: пробег хранится в нескольких местах, платежи расходятся, статусы не совпадают. Единый журнал событий решает это: у вас один поток фактов по каждой машине и водителю, а отчеты и напоминания строятся поверх него.
Базовый набор полей у события обычно такой: дата и время, тип (ТО, ремонт, штраф, заправка, путевой лист и т.д.), сумма (если есть), пробег или моточасы (если применимо), комментарий, вложения (фото, сканы), ссылка на машину и, при необходимости, на водителя.
В карточке машины храните то, что редко меняется и нужно для проверок и расчетов: VIN, госномер, марку/модель, год, текущий пробег (и источник пробега), нормы (например, расход топлива) и статусы вроде «в работе / простаивает / на ремонте».
В карточке водителя держите данные для доступа и ответственности: контакты, документы и сроки, допуски, табельный номер.
Связь удобнее делать через назначение на смену. Одна машина может переходить между водителями по датам и времени: Иван ведет машину с 08:00 до 20:00, дальше она закрепляется за Ольгой. Тогда штраф или путевой лист можно автоматически привязать к тому, кто был за рулем в момент события, без ручных догадок.
Событие - это любая запись, которая меняет картину по машине и водителю: что произошло, сколько стоило, какие документы есть, кто отвечает.
Обычно 90% задач закрывают такие типы: ТО и ремонт (плановые и внеплановые), штрафы ГИБДД, путевые листы, заправки, прочие расходы (мойка, парковка, платные дороги), ДТП, осмотры перед рейсом или приемка после аренды. Важно, чтобы все это лежало в одном журнале и отличалось только типом и деталями.
Чтобы потом строить отчеты и напоминания, у каждого события должны быть одинаковые базовые поля:
Для поиска и отчетов обычно добавляют контрагента (СТО, АЗС, оператор парковки), статью расходов (ремонт, топливо, штрафы) и связку с машиной и водителем.
Одна и та же запись часто проходит короткий цикл:
Пример: водитель загрузил фото чека с заправки и пробег, бухгалтерия проставила статью расходов и контрагента, руководитель закрыл событие после оплаты. Чем понятнее статусы и роли, тем меньше споров в конце месяца.
Чтобы данные попадали регулярно, форма должна заполняться за минуту. Рабочее правило простое: сначала сохраняем событие, потом (если нужно) дополняем деталями. Иначе люди откладывают ввод, и вы снова живете в мессенджерах и Excel.
Для быстрого старта оставьте минимум обязательных полей: дата, машина, водитель (или «без водителя»), тип события и короткий комментарий. Остальное - по ситуации: фото чека, номер документа, подрядчик, точная статья затрат.
Помогают шаблоны типовых событий. Для ТО-1 заранее задайте подсказки: пробег, сервис, плановая сумма, следующая дата или порог по пробегу. Для путевого листа - маршрут, показания одометра (начало/конец), расход топлива, отметки (если они вам реально нужны).
Почти всегда понадобится импорт из таблицы. Подготовьте простые колонки и справочники: машины (госномер, VIN, марка, подразделение), водители (ФИО, табельный, телефон), события (дата, тип, сумма, валюта, статус оплаты). И сразу договоритесь о единых значениях типов событий и статей расходов, иначе у вас быстро появятся 20 вариантов «шиномонтаж».
Права доступа лучше разделить по ролям: водитель видит свои машины и добавляет чеки/комментарии; механик ведет ТО и ремонты; бухгалтерия отвечает за суммы, статусы оплат и документы; руководитель видит все и отчеты.
Контроль качества ставьте там, где ошибки дорогие. Для штрафов обычно обязательны номер постановления, дата, сумма, статус (оплачен/нет) и срок оплаты. Для расходов - сумма, статья, способ оплаты и подтверждение (фото/файл).
Чтобы система реально помогала, отчеты по затратам собираются из событий. Каждое событие хранит сумму, дату, статью, привязку к машине и при необходимости к водителю. Тогда любой отчет - это фильтр по журналу.
Базовый набор отчетов обычно закрывает большинство вопросов: расходы по машине, по водителю, по статье и за период (неделя, месяц, квартал). Статьи лучше разделить так, чтобы по ним можно было принимать решения: «топливо» отдельно от «ремонт/запчасти», отдельно «штрафы», отдельно «прочее».
Для стоимости владения по машине хватит двух показателей: общая сумма затрат за период и пробег за период. Дальше легко считать средние: рубли на км и затраты в месяц. Даже такая простая метрика быстро показывает машины, которые «съедают бюджет».
Контроль оплат лучше строить на статусах, а не на комментариях. Минимально хватает таких статусов:
Пример: пришел штраф - событие создается со статусом «выставлено». После оплаты ставите «оплачено». Если водитель признает вину, меняете на «удержано с водителя» и фиксируете сумму удержания.
Перед закрытием месяца полезно фиксировать «срез» отчета, чтобы не спорить постфактум. Это может быть выгрузка или сохраненная версия, к которой можно вернуться при сверке.
Напоминания по ТО обычно опираются на два триггера: пробег и дату. По пробегу хорошо ловятся регламентные работы (масло, фильтры), по дате - то, что «стареет» даже без поездок (например, сезонная резина). На практике удобно сочетать оба: событие считается «к сроку», если сработал хотя бы один триггер.
С пробегом главный вопрос не «как посчитать», а «откуда брать». Минимально рабочий вариант - фиксировать пробег при частых событиях: путевой лист, заправка, ремонт. Тогда система держит последнюю точку и оценивает, сколько осталось до следующего ТО.
Уведомления лучше делать простыми и одинаковыми для всех, а потом уточнять правила. Часто хватает такого набора: водителю - за 7 дней или за 1000 км; механику/ответственному - за 3 дня или за 300 км; руководителю - только «просрочено» и повтор через неделю. Если машина выходит на линию с просрочкой, уведомление должно быть заметным.
План работ удобно хранить как события в статусе «план»: машина, тип ТО, порог по пробегу/дате, исполнитель, бюджет. Когда ТО выполнено, план закрывается, и создается следующий.
Исключения неизбежны: сезонные окна, гарантийные ремонты, машины в простое. В модели «машина -> водитель -> событие» это решается настройками на уровне конкретной машины и отдельными типами событий.
Путевой лист удобнее хранить как событие, связанное с машиной и водителем. Тогда у него понятные поля: период (начало и конец), маршрут (коротко: откуда-куда), пробег на старте и финише.
Чтобы не терять деньги на мелочах, привязывайте к путевому листу все, что подтверждает затраты: заправки, парковки, платные дороги, мойку. Практика простая: расход (сумма + тип + дата) хранится как отдельное событие, но у него есть ссылка на путевой лист. Так вы соберете отчет и по рейсам, и по статьям затрат.
Процесс лучше сделать «в три шага», чтобы водители не упирались в бюрократию, а диспетчер мог быстро проверить:
Проверки должны ловить типовые ошибки еще до закрытия: отрицательный пробег или слишком большой скачок, пересечение дат по одной машине, дубликаты (одинаковые водитель, машина, период), расходы без даты или суммы.
Для быстрого поиска важны статусы и фильтры: «черновик/на проверке/закрыт», машина, водитель, период, маршрут, диапазон пробега. Тогда вопрос «где чек на платную дорогу за 12 января» решается за минуту: нашли путевой лист по дате и машине, открыли привязанные расходы, увидели документ.
MVP для приложения автопарка проще всего собирать вокруг цепочки «машина -> водитель -> событие». Тогда и штрафы, и ТО, и путевые листы становятся разными типами событий в одном журнале.
В тесте используйте реальные документы (чеки, постановления, акты), иначе проблемы формата и обязательных полей всплывут уже после запуска.
Заранее решите, как вы будете жить с изменениями: нужен ли экспорт исходного кода, как будет организован деплой, нужен ли свой домен для сотрудников и подрядчиков, и как вы будете делать точки возврата, если поменяли формы или правила и что-то пошло не так.
Полезный быстрый сценарий проверки: возьмите два автомобиля. У одного водитель постоянный, у второго водители меняются. Так вы сразу увидите, нужны ли смены, закрепления по датам и кто должен подтверждать события.
Первый барьер у любого приложения автопарка - аккуратно перенести стартовые данные. Начните с трех таблиц: машины (VIN, госномер, марка, текущий пробег), водители (ФИО, табельный номер, телефон), справочник статей расходов (топливо, ремонт, мойка, платные дороги, штрафы). Если справочник сделать сразу, отчеты не превратятся в «прочие 1/прочие 2».
С документами проще жить, если договориться о правилах до загрузки: что считается подтверждением, кто прикладывает файлы, какие события без документа нельзя закрывать.
Хороший минимум для имени файла - чтобы было видно «к чему относится» и «когда было»:
Со штрафами важно выбрать единый путь: либо ответственный сотрудник вносит их вручную, либо вы периодически загружаете выгрузку из реестра, а система создает события «штраф» и ставит статус «к оплате». Главное - фиксировать номер постановления и дату, иначе появятся дубли.
Чтобы закрывать месяц без споров, заранее храните поля: статья расхода, сумма, НДС (если нужен), дата документа; контрагент, номер и дата документа, способ оплаты; статус (черновик, согласовано, оплачено); привязка к машине и водителю, плюс период.
Отдельно полезны логи изменений: кто и когда поменял сумму, статус или вложение. Без этого сложно разбирать конфликты и «почему цифра вдруг стала другой».
Провал внедрения почти всегда выглядит одинаково: систему сделали «правильной», но ей неудобно пользоваться каждый день. В итоге события не фиксируются, а отчеты начинают жить своей жизнью.
Если для одного события нужно заполнить 12 полей, люди начнут «доделывать потом» и забудут. Оставьте обязательными только то, без чего запись теряет смысл: машина, водитель (или «без водителя»), дата, тип события и сумма/пробег, если они реально нужны.
Когда одна и та же запись может быть и черновиком, и «учтено в оплате», без статусов быстро начинается спор: бухгалтерия видит одно, механик другое, руководитель третье. Минимальный набор обычно такой: «черновик», «на проверке», «подтверждено», «отклонено».
Путевой лист - это факт поездки, расход - это факт оплаты/начисления. Если смешать их в одну сущность, потом сложно объяснить, почему сумма «не бьется» с поездками. Храните расходы как отдельные события и связывайте их с путевым листом, если нужно.
Одна и та же статья превращается в «Мойка», «Мойка авто», «Мойка/химчистка». Через месяц отчеты по расходам автопарка уже нельзя сравнивать. Введите короткие справочники: статьи расходов, контрагенты, типы событий и штрафов.
Если пробег вводят «как получится», напоминания по ТО становятся шумом. Договоритесь, откуда берется пробег (одометр, путевой лист, GPS), как часто обновляется и что делать при пропусках.
Пример из жизни: водитель внес штраф без машины «потому что спешил», бухгалтерия оплатила, а позже штраф привязали к другой машине. Хорошая система не только хранит данные, но и предотвращает такие ситуации: обязательные связи, статусы и проверки критичных полей.
Перед запуском проверьте не отчеты, а базовые связи. Если в системе нет понятной цепочки «машина -> водитель -> событие», дальше начнутся дубли, пропуски и споры «кто ездил и за что платили».
Пройдитесь по этим пунктам на 10-15 реальных записях:
Перед тем как менять справочники, правила напоминаний или формы, сделайте точку возврата. Так вы сможете спокойно править логику и откатываться, если что-то сломалось.
Короткий тест перед стартом: добавьте один штраф, одну заправку и одно ТО для конкретной машины и водителя. Если все три события легко находите по машине, по водителю и в отчете за месяц, можно запускаться.
Представьте автопарк на 15 машин и 30 водителей (смены, подмены, разовые выезды). Ремонты бывают нечасто, но путевые листы нужны каждый день, а штрафы появляются неожиданно. Чтобы не утонуть в таблицах, достаточно держаться связки «машина -> водитель -> событие», а остальное собирать в журнал.
Как выглядит обычная неделя:
Штраф: пришло постановление - создается событие «Штраф» с привязкой к машине и водителю, датой нарушения, суммой и статусом (новый, на проверке, оплачен). Если удержание с водителя, фиксируется сумма и дедлайн, документ хранится в событии. Если платит компания, событие закрывается после оплаты и попадает в расходы.
ТО: пробег подошел к порогу - система показывает напоминание, дальше ответственный выбирает сервис и дату. После обслуживания событие закрывают: фактический пробег, работы, сумма, документ.
В конце месяца руководитель видит топ затрат по категориям и по машинам, проблемные машины (частые штрафы, простой, неожиданные ремонты) и список просрочек: неоплаченные события, незакрытые ТО, пропущенные путевые листы.
Когда прототип уже показывает журнал и пару отчетов, перестаньте «додумывать на глаз» и зафиксируйте правила. Начните с 10-15 типовых событий для вашей компании и сделайте их одинаково понятными всем: заправка, штраф, ТО, ремонт, путевой лист, мойка, простой, ДТП, выдача/возврат авто.
Для каждого события задайте обязательные поля: кто внес, какая машина, когда, сумма и способ оплаты (если есть), подтверждение (фото, номер документа, комментарий).
Дальше соберите сквозной прототип: журнал событий, отчет по затратам за период и напоминания по ТО. Прогоните его на реальных данных хотя бы 2-4 недели. Быстро всплывают практические вопросы: где нужны статусы «оплачено/не оплачено», как хранить нескольких водителей на одной машине, какие расходы относятся к рейсу.
Если вы хотите собрать такую систему быстрее через чат, можно посмотреть TakProsto (takprosto.ai): это платформа для создания веб, серверных и мобильных приложений из текстового описания, с режимом планирования, деплоем и возможностью экспорта исходного кода. Для безопасных изменений пригодятся снимки и откат, чтобы правки в формах и правилах не ломали учет.
Когда команда привыкает к процессу, выбирайте условия работы под объем: для теста часто хватает бесплатного тарифа, а для регулярной работы с ролями и согласованиями обычно берут Pro или Business. Если важны корпоративные требования, смотрят Enterprise.
Если у вас больше 5–10 машин и начинается жизнь в нескольких версиях таблиц, пора уходить от Excel. Особенно критично, когда нужны напоминания, статусы «проверено/оплачено» и история по связке «машина → водитель → событие», потому что в таблицах это быстро превращается в переписку и пропущенные сроки.
Держите три базовые сущности: машина, водитель и событие. Все остальное делайте вариациями событий, чтобы не плодить отдельные таблицы под каждую задачу и не получать расхождения по пробегу, оплатам и статусам.
Событие удобнее, потому что это единый журнал фактов, из которого строятся отчеты, поиск и напоминания. Добавляя новые типы (штраф, ТО, заправка), вы не ломаете структуру, а просто расширяете поля и правила для конкретного типа.
Минимум: дата и время, тип, привязка к машине, при необходимости к водителю, комментарий и вложения. Для денег добавьте сумму, статью расхода и статус оплаты, а для технического учета — пробег или моточасы, чтобы работали напоминания и контроль отклонений.
Сделайте назначение водителя на смену с датой и временем. Тогда штраф, заправка или путевой лист можно автоматически привязать к тому, кто был за рулем в момент события, и не выяснять это задним числом по чатам.
Дайте короткий понятный цикл: черновик, на проверке, закрыто, плюс вариант отклонено для ошибок. По оплатам лучше иметь отдельные статусы вроде «выставлено», «оплачено», «спор» и «удержано с водителя», чтобы не искать правду в комментариях.
Начните с ролей по ответственности: водитель добавляет факты и чеки, диспетчер проверяет путевые листы и пересечения, механик ведет ТО и ремонты, бухгалтерия отвечает за суммы, статьи и оплаты, руководитель смотрит отчеты и просрочки. Так меньше конфликтов, потому что понятно, кто что должен сделать в системе.
Самый простой вариант — фиксировать пробег в частых событиях: путевой лист, заправка, ремонт. Система берет последнюю актуальную точку и считает, сколько осталось до порога ТО, а при подозрительных скачках просит подтверждение или отправляет на проверку.
Храните путевой лист как отдельное событие поездки, а расходы — как отдельные события оплаты, связанные с этим путевым листом. Тогда вы легко находите документы по рейсу и при этом не смешиваете «факт поездки» и «факт расхода», из-за чего обычно не сходятся суммы.
Начните с импорта трех наборов: машины, водители и справочник статей расходов, а затем загрузите события с минимальными полями. Если вы собираете приложение в TakProsto, заранее заложите снимки и откат, чтобы безопасно менять формы и справочники, а на тесте прогоните реальные документы, иначе проблемы всплывут уже после запуска.
