Веб-приложение для грузоперевозок: заявки, ставки, документы

Зачем вообще нужен трекер заявок на перевозки

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

Трекер заявок решает простую задачу: хранит всю историю рейса в одном месте, чтобы никто не гадал, что происходит сейчас и что нужно сделать дальше. Ключевой эффект не в красивом интерфейсе, а в том, что у каждой заявки появляется единая карточка.

В нормальном потоке работы в карточке рейса за минуту должно быть понятно:

• кто везет (перевозчик и контакты)
• что везем (груз и параметры)
• за сколько (ставка и условия)
• куда и когда (маршрут, даты)
• где документы (счет, акт, ТТН/CMR, сканы)

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

Успех выглядит не как «внедрили систему», а как измеримые изменения: меньше уточняющих звонков, меньше ошибок в ставках и реквизитах, быстрее закрытие рейса и оплата.

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

Каким должно быть приложение по заявкам, без лишнего

Хорошее веб-приложение для грузоперевозок похоже на простую CRM: у каждого рейса есть карточка, понятный статус, история действий и прикрепленные файлы. Диспетчеру важно открыть один экран и сразу увидеть, что срочно, где риск срыва, по каким рейсам не хватает документов.

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

Где хранить ставки, чтобы не было путаницы

Ставка бывает разной: «на этот рейс», «по договоренности с перевозчиком», «по прайсу на направление». Если смешать все в одном поле, через месяц уже никто не вспомнит, откуда взялась цифра.

Рабочая схема обычно такая:

• в рейсе: предложения по ставкам от перевозчиков и выбранная ставка
• в карточке перевозчика: базовые условия (валюта, НДС/без НДС, типы ТС)
• в прайсе: ориентиры по направлениям и типам кузова

Минимум экранов, который реально работает

На старте часто хватает четырех разделов:

• список рейсов с фильтрами по статусу, датам и проблемам
• карточка рейса (маршрут, груз, сроки, ставка, исполнитель, чек-лист)
• справочники (клиенты, перевозчики)
• документы (файл, тип, дата, привязка к рейсу)

Пример: диспетчер создает рейс «Москва - Казань», выбирает груз и сроки, собирает 2-3 ставки в карточке, назначает перевозчика и фиксирует договоренность. Дальше система ведет статус и напоминает, что по рейсу не загружена ТТН.

Если собирать такое решение в TakProsto, удобно начать с планирования полей и статусов, а затем быстро получить рабочие экраны и хранение файлов без ручной разработки.

Сущности: рейс, груз, перевозчик, документ

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

Рейс - карточка заявки в работе. В ней важно хранить номер (внутренний или от клиента), даты (план/факт погрузки и выгрузки), маршрут (откуда-куда), статус, ответственного, клиента и назначенного перевозчика. Статус лучше делать одним полем, а детали (почему сдвиг, кто согласовал) оставлять в комментариях и событиях.

Груз описывает, что едет: тип, вес, объем, упаковка, температурный режим, признак опасности и примечания. Если бывает несколько мест или позиций, грузов может быть несколько в рамках одного рейса.

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

Документ - запись с типом (ТТН, договор, счет), номером, датой и файлом, плюс привязка: к рейсу, грузу или перевозчику. Тогда один договор не придется дублировать в каждом рейсе.

Обязательные поля, без которых учет быстро ломается:

• рейс: номер, маршрут, даты, статус, ответственный
• груз: тип и хотя бы один параметр (вес или объем)
• перевозчик: название, ИНН, контакт
• документ: тип, дата, файл, привязка

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

Статусы и контроль: чтобы было понятно, что происходит

Статусы в заявках на перевозку нужны не для красоты. Это общий язык между диспетчером, бухгалтерией и теми, кто общается с перевозчиком. В хорошем трекере видно, на каком шаге рейс, что уже согласовано, а что еще нет.

Для рейса обычно хватает простой цепочки: Новая заявка -> Ставка согласована -> Назначен перевозчик -> В пути -> Доставлено -> Закрыто. Отдельно нужен статус «Отменено», чтобы не терять историю и причину отказа. Начните с этих шагов и добавляйте детали только когда они реально помогают.

У документов логика другая: рейс может быть «В пути», а документы еще не готовы. Поэтому у каждого файла лучше иметь подстатус: Запрошен, Получен, Проверен, Есть замечания, Принят. Тогда диспетчер не гадает, почему рейс не закрывается: видно, что ТТН получена, но есть замечания.

Заранее договоритесь о правах. Обычно статус рейса меняет диспетчер, а статус документа подтверждает бухгалтерия (или ответственный за проверку). Любое изменение фиксируется автоматически: кто поменял, когда, что было и что стало, плюс короткий комментарий (например, «ждем печать», «переделать фото»).

Чтобы контроль работал, добавьте простые сигналы риска и показывайте их прямо в списке рейсов:

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

Пример: рейс уже «Доставлено», а документ «Есть замечания». Приложение должно подсветить рейс как проблемный и не давать закрыть его без решения, иначе вы вернетесь к ручным напоминаниям и звонкам.

Ставки и выбор исполнителя без хаоса

Ставка - это не просто «цена за рейс». Это набор условий, по которым потом сверяют счета и закрывают перевозку. В приложении удобнее хранить ставку как отдельную запись, привязанную к рейсу.

В карточке ставки обычно хватает: сумма и валюта, НДС (включен или нет), условия оплаты (предоплата/постоплата, сроки), краткий комментарий, срок действия предложения. Тогда диспетчер сравнивает варианты по фактам, а не по памяти.

Частая ситуация: на один рейс приходит несколько ставок. Это разные перевозчики или один перевозчик предлагает два варианта (например, быстрее, но дороже). Чтобы не было путаницы, у каждой ставки должен быть статус: получена, уточнение, согласована, отклонена.

Как выбирать исполнителя

Чтобы решение было прозрачным, задайте простые правила и фиксируйте их в рейсе:

• цена и итоговая стоимость с учетом НДС
• сроки подачи и доставки
• надежность (оценка по прошлым рейсам, процент срывов)
• доступность транспорта под тип груза
• готовность работать по нужным документам и оплате

После выбора важно «заморозить» договоренность: кто согласовал, когда, на каких условиях, какая ставка стала победителем. Например: «Согласовано Ивановой 12:40, 100 000 RUB, НДС включен, постоплата 7 дней».

Допрасходы без сюрпризов

Даже идеальная ставка не покрывает все. Введите допрасходы отдельными строками, привязанными к рейсу и, при необходимости, к ставке: простой, доппогрузка, платные дороги, штрафы. У каждой строки должны быть сумма, причина и подтверждение (файл или номер документа). Так финальная себестоимость считается автоматически, а споры решаются по фактам.

Если собирать это в TakProsto, удобно сразу описать сущности «рейс», «ставка», «перевозчик» и «допрасход», чтобы условия выбора исполнителя не терялись.

Документы и файлы: хранение, версии и доступы

В перевозках чаще всего «горит» не ставка и не маршрут, а бумаги. Если документы лежат в чатах и на дисках «у каждого свои», рейс вроде закрыт, а бухгалтерия через месяц ищет ТТН и не может выставить счет.

Какие файлы стоит поддержать с первого дня

Не пытайтесь предусмотреть все. Закройте базу, которая покрывает большинство рейсов: договоренности, транспортные и закрывающие документы, финансы, подтверждения.

• договоры и приложения (включая доверенности)
• заявка/заказ на перевозку
• ТТН и другие транспортные накладные
• счет, УПД, акт
• фото и сканы (пломбы, повреждения, выгрузка, подписи)

Хранить документы удобнее «пакетом» внутри рейса. Для каждого документа заведите версии: например, «ТТН v1» от водителя и «ТТН v2» после правок. Старое лучше не перетирать: фиксируйте, кто и когда загрузил новую версию.

Чтобы поиск работал, у документа должны быть обязательные поля: тип, номер (если есть), дата, кто предоставил и к чему он привязан (рейс, груз, перевозчик). Правила именования держите простыми и едиными, например: «Рейс 1543 - ТТН - 2026-01-21 - v2». Тогда файл узнаваем даже вне системы.

Проверка комплектности снимает много ручной работы. Например, статус «К закрытию» возможен только если загружены ТТН с подписью, акт/УПД и счет. Часто не хватает подписи получателя, печати, даты или фото повреждений. Эти пробелы лучше ловить чек-листом, а не памятью диспетчера.

Доступы разделяйте по смыслу:

• финансы (счет, УПД, акт) - бухгалтерия и руководитель
• операционные документы (заявка, ТТН, фото) - диспетчер и логист
• перевозчик - только свои рейсы и свои файлы
• клиент - только подтверждающие документы по своим рейсам

На TakProsto это удобно собрать как карточку рейса с вкладкой «Документы», где версии, статусы и права доступа идут рядом с таймлайном рейса.

Экраны и поля: как сделать удобно для диспетчера

Диспетчеру важны две вещи: быстро понять, где «горит», и не тратить время на лишний ввод. Поэтому интерфейс проще всего строить вокруг списка и одной сильной карточки рейса. Так приложение начинает экономить время уже в первые недели.

В списке рейсов фильтры должны отвечать на вопросы «что делать сейчас» и «где зависло». Обычно достаточно:

• статус (новый, в работе, на выгрузке, закрыт)
• дата (погрузка/выгрузка, просрочено)
• клиент
• перевозчик
• маршрут (город А - город Б)

Поиск должен находить запись за секунды: по номеру рейса, номеру документа (ТТН/CMR), названию перевозчика. Важно, чтобы поиск был доступен с любого экрана.

Карточка рейса лучше читается блоками: «Груз», «Ставки», «Исполнитель», «Документы», «Комментарии», «История». Диспетчер открывает карточку и сразу видит, что везем, кто везет, по какой цене, какие файлы есть и что менялось.

Уведомления делайте только по реальным рискам: просрочен статус, нет обязательного документа, ставка изменилась после согласования. И каждое уведомление должно вести в конкретное место в карточке.

На формах держите минимум полей «сейчас», остальное заполняется позже. Обычно на старте хватает: клиент, маршрут, даты, коротко о грузе и целевой статус. Телефон водителя, номера документов и сканы - второй шаг, когда исполнитель выбран.

Пошаговый план: собрать MVP трекера за короткий срок

MVP трекера нужен не для идеала, а чтобы каждый день было видно: что в работе, кто исполнитель, какие документы уже есть и где риск сорвать сроки. Реалистичная цель - за 1-2 недели получить рабочее веб-приложение для грузоперевозок, которое покрывает базовый цикл заявки.

Сначала зафиксируйте процесс на одной странице. Без сложных схем: кто создает рейс, кто выбирает перевозчика, кто подтверждает документы, кто закрывает рейс.

Дальше:

• опишите роли и порядок действий (диспетчер, бухгалтерия, руководитель, перевозчик, если есть доступ)
• согласуйте сущности и обязательные поля (рейс, груз, перевозчик, документ)
• определите статусы и правила переходов (что должно быть заполнено, чтобы двигаться дальше)

Интерфейс делайте по принципу «сначала список, потом карточка». Список дает контроль и поиск, карточка - детали и историю.

• соберите список рейсов с фильтрами (статус, дата, перевозчик) и карточку рейса с ключевыми полями
• добавьте загрузку файлов и привязку документов к рейсу (тип документа, дата)
• включите базовые отчеты: в работе, просрочено, закрыто за период

Финальный шаг - короткий пилот. Возьмите 10 реальных рейсов, проведите их от создания до закрытия и фиксируйте, где люди спотыкаются: не хватает поля, статус непонятен, документ теряется. После пилота правьте только то, что влияет на скорость и ошибки.

Если вы делаете MVP в TakProsto, удобно начать с Planning mode: описать роли, сущности и статусы текстом, а затем быстро получить список, карточки и загрузку файлов, сохранив возможность отката через snapshots.

Частые ошибки при внедрении учета рейсов

Частая причина, почему учет «не взлетает», проста: систему сделали красивой, но неудобной для ежедневной работы. Люди возвращаются к чатам и звонкам, а данные в карточках остаются неполными.

Первая ловушка - слишком детальная воронка статусов. Когда их 15-20, диспетчер начинает ставить «как получится», а водитель не понимает разницы между близкими шагами. Лучше 6-8 статусов, но каждый с понятным смыслом и триггером: что произошло в реальности, чтобы статус поменялся.

Вторая ошибка - нет единого идентификатора рейса. В итоге один и тот же рейс заводят дважды: «Москва-Казань» и «Казань, срочно», а счета и ТТН уходят в разные карточки. Нужен короткий код рейса, который живет везде: в ставках, документах, переписке и в названии файлов.

Третья проблема - ставки хранятся в комментариях. Пока исполнителей двое, это терпимо. Когда их десять, невозможно быстро ответить: кто предлагал 145 000, на каких условиях и с какой датой подачи. Ставка должна быть отдельной сущностью: сумма, валюта, НДС/без НДС, срок действия, комментарий по условиям.

Четвертая ошибка - файлы «просто прикрепили». Документ есть, но непонятно, это договор, заявка, счет или акт, и к чему он относится. Минимум: тип документа, привязка к рейсу или перевозчику, дата, статус (черновик, подписан) и ответственное лицо.

Пятая - смешение ролей и доступов. Бухгалтер видит ставки всех перевозчиков, а диспетчер не видит, что счет уже оплачен. Разведите права заранее: диспетчер работает с рейсами и ставками, руководитель смотрит общую картину и отчеты, бухгалтерия ведет финансы и закрывающие, перевозчик (если даете кабинет) видит только свои рейсы и документы.

Если собираете веб-приложение для грузоперевозок в TakProsto, эти ограничения проще заложить сразу в структуре сущностей и ролей. Тогда потом не придется разгребать хаос миграциями и ручными правками.

Быстрый чек-лист перед запуском в работу

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

Минимум, без которого учет не взлетит

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

По рейсу должно быть однозначно понятно, кто его везет и на каких условиях. Перевозчик выбран, ставка зафиксирована (с валютой и типом: за рейс или за тонну), записаны важные условия вроде времени подачи и штрафов за простой.

По грузу заполните ключевые поля, без которых ошибки неизбежны: вес, объем, тип упаковки, особые требования (температура, опасность, хрупкость). Если эти данные не обязательные, их будут пропускать, а проблемы всплывут на погрузке.

Документы, контроль и поиск проблем

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

Перед стартом проверьте:

• в карточке рейса видны ответственный и история изменений (кто и что поменял)
• есть обязательные документы и статус проверки по каждому
• в списке рейсов есть быстрые фильтры: просрочка, без документов, без назначенного перевозчика

Простой сценарий: диспетчер утром открывает список и сразу видит 3 рейса без подтвержденной ставки и 2 рейса без подписанного документа. Это и есть контроль, ради которого все затевалось.

Пример: один рейс от заявки до закрытия, по шагам

Клиент прислал заявку: «Москва - Казань, 20 паллет, 8 тонн, погрузка завтра до 14:00». Диспетчер заводит карточку рейса и привязывает к ней груз и список кандидатов-перевозчиков. Один рейс становится «центром правды», а детали живут в связанных сущностях.

Дальше диспетчер рассылает запрос ставки трем перевозчикам. В карточке перевозчика уже есть базовые данные: контакты, типы машин, допуски, направления, условия оплаты. Ставки фиксируются прямо в рейсе, чтобы потом не искать переписку и скриншоты.

1. Статус рейса: «Новая заявка» (диспетчер)
2. «Сбор ставок» (диспетчер) - заполняются сумма, срок подачи, условия (НДС/без, простой, доп. точки)
3. «Перевозчик выбран» (диспетчер) - фиксируется победитель и причина (цена, готовность, тип ТС)
4. «В пути» (перевозчик) - отмечаются события: выехал, прибыл на погрузку, загрузился, прибыл на выгрузку
5. «Закрыт» (бухгалтер/диспетчер) - подтверждены документы и сумма к оплате

По документам удобно идти по этапам. На выборе исполнителя обычно добавляют договор/заявку на перевозку или оферту. На погрузке появляется ТТН/транспортная накладная и доверенность (если нужно), а также фото пломб и состояния груза. На выгрузке - отметки получателя, закрывающие акты, счет. Перед закрытием бухгалтер проверяет: совпадают ли даты, маршрут, тоннаж, ставка, есть ли подписи и печати, нет ли расхождений по простоям.

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

Если собирать это в TakProsto, можно описать сущности «рейс/груз/перевозчик/документ» и роли (диспетчер, перевозчик, бухгалтер), и платформа соберет трекер со статусами и файлами без ручной рутины.

Следующие шаги: как довести до рабочего инструмента

Начните с правил данных, а не с экранов. Опишите 4 сущности (рейс, груз, перевозчик, документ) и для рейса задайте статусы, по которым вы реально управляете работой. Дальше соберите прототип, где можно создать рейс, назначить исполнителя и прикрепить файлы. Это рабочий минимум: лучше неделя с простым трекером, чем месяц с идеальной схемой.

Чтобы в системе был порядок, договоритесь о нескольких обязательных полях: номер заявки или рейса, маршрут (откуда-куда), даты, ставка, перевозчик, ответственный и текущий статус. Тогда отчеты и фильтры будут честными, а не «как получилось».

Хорошо работает короткий операционный ритм:

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

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

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

Если нужен быстрый старт, такое веб-приложение для грузоперевозок можно собрать в TakProsto (takprosto.ai) из чата: сначала в режиме планирования описать сущности и статусы, затем получить рабочие экраны, хранение файлов и развертывание. Когда процесс устоится, исходники можно выгрузить и развивать дальше так, как удобно вашей команде.