Веб-приложение для грузоперевозок: какие сущности и статусы нужны, как хранить ставки, исполнителей и документы, и как собрать трекер заявок без лишней сложности.
Когда заявки живут в мессенджерах и таблицах, они быстро превращаются в шум. Ставки теряются в переписке, договоренности забываются, статус рейса приходится уточнять вручную. В итоге диспетчер дергает перевозчика, бухгалтер просит документы повторно, а руководитель видит картину только со слов.
Трекер заявок решает простую задачу: хранит всю историю рейса в одном месте, чтобы никто не гадал, что происходит сейчас и что нужно сделать дальше. Ключевой эффект не в красивом интерфейсе, а в том, что у каждой заявки появляется единая карточка.
В нормальном потоке работы в карточке рейса за минуту должно быть понятно:
Обычно участвуют четыре роли: диспетчер создает заявку и собирает ставки, перевозчик подтверждает условия и присылает документы, бухгалтер проверяет закрывающие и контролирует оплату, руководитель смотрит маржинальность и дисциплину по срокам.
Успех выглядит не как «внедрили систему», а как измеримые изменения: меньше уточняющих звонков, меньше ошибок в ставках и реквизитах, быстрее закрытие рейса и оплата.
Простой пример: перевозчик прислал ставку в чате, диспетчер согласовал, а через неделю нужно найти, на каких условиях договаривались и почему цена изменилась. В трекере это один экран: ставка, комментарии, статус, прикрепленные файлы и кто когда подтвердил.
Хорошее веб-приложение для грузоперевозок похоже на простую CRM: у каждого рейса есть карточка, понятный статус, история действий и прикрепленные файлы. Диспетчеру важно открыть один экран и сразу увидеть, что срочно, где риск срыва, по каким рейсам не хватает документов.
Чтобы не утонуть в полях, полезно разделить данные на две группы. Справочники меняются редко: клиенты, перевозчики, водители, типы машин, направления, шаблоны документов. Операционные данные живут каждый день: заявки, рейсы, ставки, загрузка и разгрузка, закрывающие документы. Тогда новые рейсы создаются быстро, а данные не дублируются.
Ставка бывает разной: «на этот рейс», «по договоренности с перевозчиком», «по прайсу на направление». Если смешать все в одном поле, через месяц уже никто не вспомнит, откуда взялась цифра.
Рабочая схема обычно такая:
На старте часто хватает четырех разделов:
Пример: диспетчер создает рейс «Москва - Казань», выбирает груз и сроки, собирает 2-3 ставки в карточке, назначает перевозчика и фиксирует договоренность. Дальше система ведет статус и напоминает, что по рейсу не загружена ТТН.
Если собирать такое решение в TakProsto, удобно начать с планирования полей и статусов, а затем быстро получить рабочие экраны и хранение файлов без ручной разработки.
Чтобы веб-приложение для грузоперевозок не превратилось в набор разрозненных таблиц, начните с четырех базовых сущностей. Они должны быть понятны диспетчеру и легко связываться между собой: рейс включает груз, выполняется перевозчиком и сопровождается документами.
Рейс - карточка заявки в работе. В ней важно хранить номер (внутренний или от клиента), даты (план/факт погрузки и выгрузки), маршрут (откуда-куда), статус, ответственного, клиента и назначенного перевозчика. Статус лучше делать одним полем, а детали (почему сдвиг, кто согласовал) оставлять в комментариях и событиях.
Груз описывает, что едет: тип, вес, объем, упаковка, температурный режим, признак опасности и примечания. Если бывает несколько мест или позиций, грузов может быть несколько в рамках одного рейса.
Перевозчик - отдельная карточка контрагента. Минимум: реквизиты, контакты, регионы работы, заметки по автопарку. Полезно добавить внутреннюю оценку качества (например, пунктуальность, дисциплина по документам, связь), чтобы выбор исполнителя не держался на памяти.
Документ - запись с типом (ТТН, договор, счет), номером, датой и файлом, плюс привязка: к рейсу, грузу или перевозчику. Тогда один договор не придется дублировать в каждом рейсе.
Обязательные поля, без которых учет быстро ломается:
Все остальное (температурный режим, упаковка, рейтинг, дополнительные контакты) оставьте опциональным и включайте по мере надобности. Так проще собрать первый рабочий вариант, а потом расширять карточки без боли для команды.
Статусы в заявках на перевозку нужны не для красоты. Это общий язык между диспетчером, бухгалтерией и теми, кто общается с перевозчиком. В хорошем трекере видно, на каком шаге рейс, что уже согласовано, а что еще нет.
Для рейса обычно хватает простой цепочки: Новая заявка -> Ставка согласована -> Назначен перевозчик -> В пути -> Доставлено -> Закрыто. Отдельно нужен статус «Отменено», чтобы не терять историю и причину отказа. Начните с этих шагов и добавляйте детали только когда они реально помогают.
У документов логика другая: рейс может быть «В пути», а документы еще не готовы. Поэтому у каждого файла лучше иметь подстатус: Запрошен, Получен, Проверен, Есть замечания, Принят. Тогда диспетчер не гадает, почему рейс не закрывается: видно, что ТТН получена, но есть замечания.
Заранее договоритесь о правах. Обычно статус рейса меняет диспетчер, а статус документа подтверждает бухгалтерия (или ответственный за проверку). Любое изменение фиксируется автоматически: кто поменял, когда, что было и что стало, плюс короткий комментарий (например, «ждем печать», «переделать фото»).
Чтобы контроль работал, добавьте простые сигналы риска и показывайте их прямо в списке рейсов:
Пример: рейс уже «Доставлено», а документ «Есть замечания». Приложение должно подсветить рейс как проблемный и не давать закрыть его без решения, иначе вы вернетесь к ручным напоминаниям и звонкам.
Ставка - это не просто «цена за рейс». Это набор условий, по которым потом сверяют счета и закрывают перевозку. В приложении удобнее хранить ставку как отдельную запись, привязанную к рейсу.
В карточке ставки обычно хватает: сумма и валюта, НДС (включен или нет), условия оплаты (предоплата/постоплата, сроки), краткий комментарий, срок действия предложения. Тогда диспетчер сравнивает варианты по фактам, а не по памяти.
Частая ситуация: на один рейс приходит несколько ставок. Это разные перевозчики или один перевозчик предлагает два варианта (например, быстрее, но дороже). Чтобы не было путаницы, у каждой ставки должен быть статус: получена, уточнение, согласована, отклонена.
Чтобы решение было прозрачным, задайте простые правила и фиксируйте их в рейсе:
После выбора важно «заморозить» договоренность: кто согласовал, когда, на каких условиях, какая ставка стала победителем. Например: «Согласовано Ивановой 12:40, 100 000 RUB, НДС включен, постоплата 7 дней».
Даже идеальная ставка не покрывает все. Введите допрасходы отдельными строками, привязанными к рейсу и, при необходимости, к ставке: простой, доппогрузка, платные дороги, штрафы. У каждой строки должны быть сумма, причина и подтверждение (файл или номер документа). Так финальная себестоимость считается автоматически, а споры решаются по фактам.
Если собирать это в TakProsto, удобно сразу описать сущности «рейс», «ставка», «перевозчик» и «допрасход», чтобы условия выбора исполнителя не терялись.
В перевозках чаще всего «горит» не ставка и не маршрут, а бумаги. Если документы лежат в чатах и на дисках «у каждого свои», рейс вроде закрыт, а бухгалтерия через месяц ищет ТТН и не может выставить счет.
Не пытайтесь предусмотреть все. Закройте базу, которая покрывает большинство рейсов: договоренности, транспортные и закрывающие документы, финансы, подтверждения.
Хранить документы удобнее «пакетом» внутри рейса. Для каждого документа заведите версии: например, «ТТН v1» от водителя и «ТТН v2» после правок. Старое лучше не перетирать: фиксируйте, кто и когда загрузил новую версию.
Чтобы поиск работал, у документа должны быть обязательные поля: тип, номер (если есть), дата, кто предоставил и к чему он привязан (рейс, груз, перевозчик). Правила именования держите простыми и едиными, например: «Рейс 1543 - ТТН - 2026-01-21 - v2». Тогда файл узнаваем даже вне системы.
Проверка комплектности снимает много ручной работы. Например, статус «К закрытию» возможен только если загружены ТТН с подписью, акт/УПД и счет. Часто не хватает подписи получателя, печати, даты или фото повреждений. Эти пробелы лучше ловить чек-листом, а не памятью диспетчера.
Доступы разделяйте по смыслу:
На TakProsto это удобно собрать как карточку рейса с вкладкой «Документы», где версии, статусы и права доступа идут рядом с таймлайном рейса.
Диспетчеру важны две вещи: быстро понять, где «горит», и не тратить время на лишний ввод. Поэтому интерфейс проще всего строить вокруг списка и одной сильной карточки рейса. Так приложение начинает экономить время уже в первые недели.
В списке рейсов фильтры должны отвечать на вопросы «что делать сейчас» и «где зависло». Обычно достаточно:
Поиск должен находить запись за секунды: по номеру рейса, номеру документа (ТТН/CMR), названию перевозчика. Важно, чтобы поиск был доступен с любого экрана.
Карточка рейса лучше читается блоками: «Груз», «Ставки», «Исполнитель», «Документы», «Комментарии», «История». Диспетчер открывает карточку и сразу видит, что везем, кто везет, по какой цене, какие файлы есть и что менялось.
Уведомления делайте только по реальным рискам: просрочен статус, нет обязательного документа, ставка изменилась после согласования. И каждое уведомление должно вести в конкретное место в карточке.
На формах держите минимум полей «сейчас», остальное заполняется позже. Обычно на старте хватает: клиент, маршрут, даты, коротко о грузе и целевой статус. Телефон водителя, номера документов и сканы - второй шаг, когда исполнитель выбран.
MVP трекера нужен не для идеала, а чтобы каждый день было видно: что в работе, кто исполнитель, какие документы уже есть и где риск сорвать сроки. Реалистичная цель - за 1-2 недели получить рабочее веб-приложение для грузоперевозок, которое покрывает базовый цикл заявки.
Сначала зафиксируйте процесс на одной странице. Без сложных схем: кто создает рейс, кто выбирает перевозчика, кто подтверждает документы, кто закрывает рейс.
Дальше:
Интерфейс делайте по принципу «сначала список, потом карточка». Список дает контроль и поиск, карточка - детали и историю.
Финальный шаг - короткий пилот. Возьмите 10 реальных рейсов, проведите их от создания до закрытия и фиксируйте, где люди спотыкаются: не хватает поля, статус непонятен, документ теряется. После пилота правьте только то, что влияет на скорость и ошибки.
Если вы делаете MVP в TakProsto, удобно начать с Planning mode: описать роли, сущности и статусы текстом, а затем быстро получить список, карточки и загрузку файлов, сохранив возможность отката через snapshots.
Частая причина, почему учет «не взлетает», проста: систему сделали красивой, но неудобной для ежедневной работы. Люди возвращаются к чатам и звонкам, а данные в карточках остаются неполными.
Первая ловушка - слишком детальная воронка статусов. Когда их 15-20, диспетчер начинает ставить «как получится», а водитель не понимает разницы между близкими шагами. Лучше 6-8 статусов, но каждый с понятным смыслом и триггером: что произошло в реальности, чтобы статус поменялся.
Вторая ошибка - нет единого идентификатора рейса. В итоге один и тот же рейс заводят дважды: «Москва-Казань» и «Казань, срочно», а счета и ТТН уходят в разные карточки. Нужен короткий код рейса, который живет везде: в ставках, документах, переписке и в названии файлов.
Третья проблема - ставки хранятся в комментариях. Пока исполнителей двое, это терпимо. Когда их десять, невозможно быстро ответить: кто предлагал 145 000, на каких условиях и с какой датой подачи. Ставка должна быть отдельной сущностью: сумма, валюта, НДС/без НДС, срок действия, комментарий по условиям.
Четвертая ошибка - файлы «просто прикрепили». Документ есть, но непонятно, это договор, заявка, счет или акт, и к чему он относится. Минимум: тип документа, привязка к рейсу или перевозчику, дата, статус (черновик, подписан) и ответственное лицо.
Пятая - смешение ролей и доступов. Бухгалтер видит ставки всех перевозчиков, а диспетчер не видит, что счет уже оплачен. Разведите права заранее: диспетчер работает с рейсами и ставками, руководитель смотрит общую картину и отчеты, бухгалтерия ведет финансы и закрывающие, перевозчик (если даете кабинет) видит только свои рейсы и документы.
Если собираете веб-приложение для грузоперевозок в TakProsto, эти ограничения проще заложить сразу в структуре сущностей и ролей. Тогда потом не придется разгребать хаос миграциями и ручными правками.
Перед тем как отдавать трекер в реальную работу, проверьте базовые вещи. Если они сделаны, система даст порядок с первого дня, а не превратится в еще одну таблицу, которую все обходят.
У каждого рейса должен быть уникальный номер, который не меняется. По нему ищут в переписке, по нему задают вопросы перевозчику, по нему закрывают документы. Рядом с номером всегда должен быть текущий статус, понятный без расшифровки.
По рейсу должно быть однозначно понятно, кто его везет и на каких условиях. Перевозчик выбран, ставка зафиксирована (с валютой и типом: за рейс или за тонну), записаны важные условия вроде времени подачи и штрафов за простой.
По грузу заполните ключевые поля, без которых ошибки неизбежны: вес, объем, тип упаковки, особые требования (температура, опасность, хрупкость). Если эти данные не обязательные, их будут пропускать, а проблемы всплывут на погрузке.
Документы лучше запускать как список обязательных пунктов с отметками проверки, а не как хаотичную папку с файлами. Тогда видно, что уже есть, что в ожидании и что просрочено.
Перед стартом проверьте:
Простой сценарий: диспетчер утром открывает список и сразу видит 3 рейса без подтвержденной ставки и 2 рейса без подписанного документа. Это и есть контроль, ради которого все затевалось.
Клиент прислал заявку: «Москва - Казань, 20 паллет, 8 тонн, погрузка завтра до 14:00». Диспетчер заводит карточку рейса и привязывает к ней груз и список кандидатов-перевозчиков. Один рейс становится «центром правды», а детали живут в связанных сущностях.
Дальше диспетчер рассылает запрос ставки трем перевозчикам. В карточке перевозчика уже есть базовые данные: контакты, типы машин, допуски, направления, условия оплаты. Ставки фиксируются прямо в рейсе, чтобы потом не искать переписку и скриншоты.
По документам удобно идти по этапам. На выборе исполнителя обычно добавляют договор/заявку на перевозку или оферту. На погрузке появляется ТТН/транспортная накладная и доверенность (если нужно), а также фото пломб и состояния груза. На выгрузке - отметки получателя, закрывающие акты, счет. Перед закрытием бухгалтер проверяет: совпадают ли даты, маршрут, тоннаж, ставка, есть ли подписи и печати, нет ли расхождений по простоям.
Чтобы разбирать спорные случаи, помогают простые поля в рейсе: окна погрузки/выгрузки, контакты на точках, номер машины и прицепа, ФИО водителя, условия по простою, кто и когда согласовал ставку, файлы и комментарии по отклонениям.
Если собирать это в TakProsto, можно описать сущности «рейс/груз/перевозчик/документ» и роли (диспетчер, перевозчик, бухгалтер), и платформа соберет трекер со статусами и файлами без ручной рутины.
Начните с правил данных, а не с экранов. Опишите 4 сущности (рейс, груз, перевозчик, документ) и для рейса задайте статусы, по которым вы реально управляете работой. Дальше соберите прототип, где можно создать рейс, назначить исполнителя и прикрепить файлы. Это рабочий минимум: лучше неделя с простым трекером, чем месяц с идеальной схемой.
Чтобы в системе был порядок, договоритесь о нескольких обязательных полях: номер заявки или рейса, маршрут (откуда-куда), даты, ставка, перевозчик, ответственный и текущий статус. Тогда отчеты и фильтры будут честными, а не «как получилось».
Хорошо работает короткий операционный ритм:
Вторым этапом добавляйте то, что экономит больше всего времени: шаблоны документов, отчеты по марже, интеграции (например, импорт заявок из почты или выгрузка в бухгалтерию). Не пытайтесь внедрить все сразу, иначе команда начнет обходить систему.
ИИ подключайте аккуратно и точечно. Пусть он помогает там, где риск ошибки низкий: заполняет черновик карточки рейса из текста заявки, подсказывает недостающие поля, проверяет комплектность документов по чек-листу. Финальное подтверждение данных все равно оставьте человеку.
Если нужен быстрый старт, такое веб-приложение для грузоперевозок можно собрать в TakProsto (takprosto.ai) из чата: сначала в режиме планирования описать сущности и статусы, затем получить рабочие экраны, хранение файлов и развертывание. Когда процесс устоится, исходники можно выгрузить и развивать дальше так, как удобно вашей команде.
Если заявки живут в чатах и таблицах, быстро теряются ставки, переписка и договоренности, а статус рейса приходится уточнять вручную. Трекер дает одну карточку рейса, где видно исполнителя, условия, документы и историю изменений, поэтому меньше звонков и меньше ошибок.
Начните с четырех сущностей: рейс, груз, перевозчик и документ. Этого достаточно, чтобы связать маршрут, условия, исполнителя и комплектность бумаг в одной системе и не превратить учет в набор разрозненных таблиц.
Сделайте обязательными только то, без чего учет ломается: номер рейса, маршрут, даты, статус и ответственный. По грузу достаточно типа и хотя бы одного параметра вроде веса или объема, а по перевозчику — название, ИНН и контакт.
Держите статусы короткой цепочкой из 6–8 шагов, чтобы всем было понятно, что произошло в реальности. Например, отдельно полезно иметь «Отменено», чтобы не терять историю и причины срыва.
Потому что рейс может быть «в пути», а документы еще не получены или не проверены. У документа свой подстатус помогает понять, что именно мешает закрытию: документ запросили, получили, нашли замечания или уже приняли.
Храните ставку отдельной записью, привязанной к рейсу, с суммой, валютой, НДС, условиями оплаты и сроком действия. Тогда можно сравнивать несколько предложений и «заморозить» финальную договоренность с отметкой, кто и когда согласовал.
Заведите допрасходы отдельными строками у рейса и фиксируйте причину и подтверждение, чтобы итоговая себестоимость считалась честно. Это снимает сюрпризы на этапе закрытия и упрощает разбор спорных ситуаций.
На старте обычно хватает списка рейсов с фильтрами, карточки рейса, простых справочников и раздела документов. Важно, чтобы из списка было видно, где «горит», а в карточке — ставка, исполнитель, файлы и история изменений.
Сразу разделите права: диспетчер ведет рейсы и ставки, бухгалтерия подтверждает документы и финансы, руководитель смотрит маржинальность и дисциплину, а перевозчик видит только свои рейсы. Плюс фиксируйте, кто поменял статус или документ, чтобы не было «никто не трогал».
Сделайте короткий пилот на 10 реальных рейсах и исправляйте только то, что влияет на скорость и ошибки: непонятные статусы, недостающие поля, потерю документов. Если собирать в TakProsto, удобно начать с Planning mode, а затем быстро получить рабочие экраны, файлы и контроль статусов с возможностью отката через snapshots.
