Каждую неделю разбираем, как устроен учёт заявок на перевозку и другие задачи диспетчерской работы транспортных компаний: инструменты, готовые шаблоны, разбор ошибок. Подпишись на рассылку журнала, чтобы не пропустить новые материалы.
Разбираем ЭПД, цифровизацию перевозок и учёт автопарка — коротко и по делу. Подпишитесь на канал, чтобы не пропустить.
Что такое учёт заявок на перевозку и зачем он нужен?
Коротко: учёт заявок на перевозку - это единый реестр всех обращений грузоотправителей от момента приёма заявки до закрытия рейса. Он отвечает в любой момент на три вопроса: какая заявка сейчас в работе, какая машина занята и кто отвечает за результат по конкретному рейсу.
Без такого реестра заявки живут в разных местах: часть - в почте, часть - в мессенджере, часть - в личных заметках диспетчера. Когда звонит клиент и спрашивает, где его груз, ответ ищут по памяти или обзвоном водителей. Чем больше рейсов в работе, тем дороже обходится такой поиск.
Учёт заявок решает конкретную задачу: свести весь поток обращений в одно место и на каждом шаге видеть, что происходит с заявкой - принята, назначена машина, в рейсе, закрыта. Это рабочий инструмент внутри управления грузоперевозками, а не отдельная параллельная система.
Заявку и журнал заявок часто путают. Заявка на перевозку - документ по одному рейсу, который грузоотправитель подаёт перевозчику. Журнал учёта заявок - реестр, куда заносят все такие заявки за период, чтобы видеть картину целиком.
Что обязательно указывать в заявке на перевозку груза?
Коротко: заявка должна содержать данные сторон, характеристику груза, маршрут, дату подачи транспорта и обязательные реквизиты по приложению № 5 к Правилам перевозок грузов автомобильным транспортом (Постановление Правительства РФ от 21.12.2020 № 2200). Перевозчик обязан ответить на заявку в течение 3 календарных дней.
Помимо реквизитов из приложения № 5, в заявке должны быть видны: кто грузоотправитель и кто перевозчик, что за груз везут, откуда и куда, к какому сроку подать транспорт под погрузку. Без этого минимума перевозчик формально не обязан рассматривать заявку как поданную.
Договор перевозки груза заключается либо через заказ, либо - если между сторонами уже действует договор об организации перевозок - через заявку грузоотправителя. Правила закрепляют это прямо:
«Перевозка груза осуществляется на основании договора перевозки груза, который может заключаться посредством принятия перевозчиком к исполнению заказа, а при наличии договора об организации перевозки груза - заявки грузоотправителя, за исключением случаев, указанных в пункте 15 настоящих Правил.»
- Постановление Правительства РФ от 21.12.2020 № 2200 «Об утверждении Правил перевозок грузов автомобильным транспортом», п. 7, https://base.garant.ru/400111454/
Дальше Правила описывают состав самой заявки и срок реакции перевозчика:
«Заказ (заявка) на перевозку грузов автомобильным транспортом должен (должна) содержать обязательные реквизиты согласно приложению N 5... Перевозчик обязан рассмотреть заказ (заявку) и в срок, не превышающий 3 календарных дней со дня его (ее) принятия, проинформировать грузоотправителя о принятии или об отказе в принятии заказа (заявки) с обоснованием причин отказа и возвратить заказ (заявку).»
- Постановление Правительства РФ от 21.12.2020 № 2200, п. 8, https://base.garant.ru/400111454/
Форму документа стороны выбирают по соглашению: Правила допускают и письменную, и электронную заявку. В работающем потоке заявка приходит электронно - письмом, файлом в системе электронного документооборота (ЭДО) или записью в диспетчерской программе, откуда её сразу видно всей смене.
Для учёта отсюда следует практический вывод: у каждой заявки должна быть дата подачи и явный дедлайн ответа - плюс 3 календарных дня. Если это поле не фиксировать отдельно, диспетчер узнает о просрочке от самого клиента.
Правила также дают грузоотправителю право до заключения договора запросить у перевозчика прейскурант с условиями расчёта провозной платы. Этот документ удобно хранить рядом с журналом заявок, чтобы не пересчитывать условия заново. Если нужна готовая форма для заполнения, её отдаёт конструктор договора-заявки; разбор самого документа по пунктам - в отдельной статье про договор-заявку на перевозку груза.
Нужна ли заявка всегда или можно работать без неё?
Коротко: нет, не всегда. Правила прямо предусматривают случай, когда вместо заявки оформляется другой документ - заказ-наряд по договору фрахтования. Такие рейсы тоже должны попадать в общий учёт, иначе они выпадают из картины загрузки машин.
Не любая перевозка идёт через заявку. Есть отдельная категория случаев, когда стороны заключают договор фрахтования:
«Перевозка груза с сопровождением представителя грузовладельца, перевозка груза, в отношении которого не ведется учет движения товарно-материальных ценностей, осуществляется транспортным средством, предоставляемым на основании договора фрахтования, заключаемого в письменной форме. Если иное не предусмотрено соглашением сторон, договор фрахтования заключается в форме заказа-наряда на предоставление транспортного средства... составленного по форме согласно приложению N 6.»
- Постановление Правительства РФ от 21.12.2020 № 2200, п. 15, https://base.garant.ru/400111454/
Для журнала учёта заявок это значит, что нужна отдельная колонка или отдельный статус - «фрахтование / заказ-наряд». Иначе диспетчер решит, что заявки нет вообще, и рейс останется без записи в реестре. Подробный разбор самого документа - в статье про электронный заказ-наряд.
Есть ещё деталь, которая часто ускользает. Если в разделе «Условия перевозки» транспортной накладной отдельные пункты не заполнены, применяются условия, установленные законом и Правилами. Отсутствие записи не отменяет обязательств, оно переключает стороны на условия по умолчанию - и это повод фиксировать в журнале не только факт подачи заявки, но и согласованные условия перевозки.
Хочешь собрать систему целиком, а не только учёт заявок? То, что описано в статье, - первый шаг диспетчерской работы. CARGO.RUN START ставит заявки, назначение машин и статус рейсов в одну систему вместо разрозненных таблиц и переписки в мессенджере.
Как организовать учёт заявок в таблице?
Коротко: минимальная таблица учёта заявок - это строка на каждую заявку и фиксированный набор колонок: клиент, груз, маршрут, даты, назначенные машина и водитель, ставка, статус. Такой набор закрывает базовые вопросы диспетчера и руководителя без дополнительных уточнений по телефону.
Компании, которые ещё не автоматизировали диспетчерскую работу, ведут учёт в Excel или Google Таблицах. Состав колонок при этом почти не зависит от инструмента - он задаётся тем, что нужно знать о рейсе: кто подал заявку, когда, какая машина назначена, что везём, куда и за какие деньги.
Рабочий минимум колонок для учёта заявок на перевозку груза:
1. Номер заявки и дата подачи
2. Грузоотправитель (компания, контактное лицо, телефон)
3. Груз (наименование, вес, объём)
4. Маршрут (пункт погрузки, пункт разгрузки)
5. Дата и время подачи под погрузку
6. Назначенные транспортное средство и водитель
7. Ставка за рейс
8. Статус (новая / в работе / подтверждена / в рейсе / закрыта / отказ)
9. Дедлайн ответа перевозчика (дата подачи + 3 календарных дня)
10. Примечания (особые условия, причина отказа, номер договора фрахтования)Такой журнал справляется, пока поток заявок небольшой. Проблемы почти всегда возникают вокруг самого файла: несколько диспетчеров правят один документ, часть заявок приходит вне таблицы - по звонку или в личном чате, история по клиенту разбросана по старым версиям.
Как избежать двойного бронирования машины?
Коротко: перед каждым назначением нужно проверять занятость машины по единой базе заявок. Вручную это делает диспетчер по общей таблице, автоматически - диспетчерская система, которая сама блокирует назначение с наложением по времени.
На практике это значит: прежде чем поставить машину в заявку, диспетчер сверяется со всеми принятыми заявками на тот же интервал времени, а не только со своим списком. Ручной учёт снижает риск двойного бронирования, если статус машины действительно смотрят по всем строкам таблицы. Это работает, пока заявок немного и таблица помещается в поле зрения одного человека.
Проблема почти всегда всплывает при посменной работе. Каждый диспетчер ведёт свой список заявок или держит занятость машин в памяти - и там, где нет общей базы, машину назначают на рейс, который она физически не успевает выполнить, потому что уже в пути по другой заявке. Как только заявок и машин становится больше, ручная сверка начинает пропускать такие конфликты.
Диспетчерская система решает задачу иначе: она хранит все заявки и назначения в одной базе и сама проверяет занятость машины на нужный интервал, прежде чем позволить назначить её на новый рейс. Календарь машин перестаёт быть личным знанием конкретного диспетчера.
Как контролировать статус каждого рейса, если заявок много?
Коротко: статус заявки должен быть виден всем, кому он нужен, без звонка водителю. Для этого в учёте ведут явную статусную модель из фиксированного набора значений, а не текстовые пометки вроде «вроде едет» в колонке примечаний.
Минимальный набор статусов для учёта заявок на перевозку: новая, в работе, подтверждена, в рейсе, закрыта, отказ. Разница между «в работе» и «подтверждена» важна: первое означает, что заявку взяли в обработку, второе - что перевозчик формально принял заявку и назвал условия. Без этого разделения руководитель не видит, сколько заявок реально согласовано.
Ручной журнал показывает статус только тому, кто его открыл и знает про последние правки. Если статус меняют звонком «скажи, что машина выехала», документ расходится с реальностью уже через несколько часов. В диспетчерской программе статус меняется одним действием и сразу виден руководителю, бухгалтеру и следующей смене - без пересказа по цепочке.
Как одному логисту вести больше машин без потери контроля?
Коротко: нужно убрать из рабочего дня логиста рутинный поиск информации. Единый учёт заявок с понятной структурой и статусами отдаёт статус рейса и занятость машины за секунды вместо минут ручного поиска по разным файлам и чатам.
Когда данные лежат в одном журнале, логист тратит время на содержательные решения: какую машину и какого водителя назначить, как выстроить маршрут. Это и есть практический смысл автоматизации диспетчерской работы - она снимает операции, которые не требуют квалификации логиста.
Рост числа заявок без единого реестра означает пропорциональный рост хаоса. Дело редко в квалификации конкретного логиста: время съедают рутинные действия - найти статус заявки, вспомнить, какая машина свободна, сверить историю по клиенту. Каждое из них занимает секунды в системе с единой базой и минуты, если приходится листать несколько файлов.
Таблица или программа для учёта заявок: что меняется
Коротко: программа для учёта заявок - класс систем TMS (Transportation Management System, система управления перевозками) - сама проверяет данные и связи между заявками, машинами и рейсами. Таблица так не умеет: она хранит то, что в неё внесли, и не возражает, когда одну машину назначают на два пересекающихся рейса.
| Критерий | Таблица (Excel, Google Sheets) | Диспетчерская программа (TMS) |
|---|---|---|
| Защита от двойного бронирования | Проверка вручную, зависит от внимательности | Автоматическая проверка занятости машины |
| Статус рейса в реальном времени | Нужно уточнять звонком или в чате | Виден сразу всем, у кого есть доступ |
| История по клиенту | Поиск по разным версиям файла | Мгновенный поиск по базе заявок |
| Одновременная работа нескольких диспетчеров | Правки одного файла затирают друг друга | Общая база, где изменения не теряются |
| Расчёт ставки и себестоимости рейса | Отдельная ручная таблица или калькулятор | Данные заявки сразу видны в расчёте |
Последняя строка таблицы важнее остальных. Если учёт заявок хранит только ставку, а себестоимость рейса считают отдельно, легко не заметить рейс, который уходит в минус. Проверить это по своим цифрам можно через расчёт себестоимости перевозки и сверить, покрывает ли ставка из заявки затраты на километр. С какого объёма перевозок такая система окупается, разобрано в статье про ТМС для перевозчика.
Какие поля включить в журнал учёта заявок?
Коротко: помимо базовых полей заявки, в журнал стоит добавить два: дедлайн ответа перевозчика по закону и тип документа - заявка или заказ-наряд по фрахтованию. Оба поля закрывают ситуации, в которых рейс иначе выпадает из учёта.
Расширенный шаблон, который копируется в таблицу или ложится в основу настройки полей диспетчерской программы:
Заявка №: ______
Дата и время поступления: ______
Грузоотправитель: ______ (компания, контакт, телефон)
Груз: ______ (наименование, вес, объём)
Маршрут: ______ (пункт погрузки → пункт разгрузки)
Дата и время подачи под погрузку: ______
Транспортное средство: ______
Водитель: ______
Ставка за рейс: ______
Дедлайн ответа перевозчика (подача + 3 календарных дня): ______
Статус: новая / в работе / подтверждена / в рейсе / закрыта / отказ
Тип документа: заявка / заказ-наряд (фрахтование)
Примечание: ______Поле «ставка за рейс» стоит сверять не только с заявкой, но и с рынком, чтобы не занижать цену по привычке. Здесь пригодится калькулятор ставки на перевозку: он помогает прикинуть адекватный уровень ставки под конкретный маршрут и груз до того, как цифра попадёт в журнал.
Какие ошибки чаще всего ломают учёт заявок?
Коротко: большинство проблем возникает из-за того, что данные вносят с опозданием или не туда, где их потом ищут. Количество колонок в журнале почти никогда не бывает настоящей причиной - причина в дисциплине внесения и в том, что часть заявок живёт вне реестра.
Пять ошибок, которые встречаются чаще всего:
- Заявки принимают по звонку или в мессенджере и не переносят в журнал сразу - часть рейсов существует только в памяти диспетчера.
- Нет отдельного статуса для заказа-наряда по договору фрахтования - такие рейсы теряются или путаются с обычными заявками.
- Файл журнала правят несколько человек одновременно без согласования - расхождения версий приводят к потере данных.
- Никто не отслеживает 3-дневный срок ответа на заявку по закону - просрочка обнаруживается после жалобы клиента.
- Ставку в журнале не сверяют с фактической себестоимостью рейса - компания годами возит часть заказов в минус, не замечая этого.
Важно. Срок ответа на заявку - обязанность перевозчика по Правилам № 2200, а не внутренняя договорённость. Если журнал не фиксирует дедлайн отдельным полем, отследить просрочку при потоке из десятков заявок в месяц практически невозможно.
Что делать, если перевозчик не отвечает на заявку в срок?
Коротко: Постановление Правительства РФ от 21.12.2020 № 2200 даёт перевозчику 3 календарных дня на ответ по заявке. Если срок прошёл, а ответа нет, это повод зафиксировать нарушение в журнале и обратиться к другому перевозчику либо потребовать письменный отказ с обоснованием.
Правила перевозок грузов автомобильным транспортом обязывают перевозчика не просто рассмотреть заявку, а сообщить решение - принятие или мотивированный отказ - в течение 3 календарных дней с момента получения. Если срок пропущен, у грузоотправителя есть основание зафиксировать факт нарушения прямо в журнале учёта заявок: дата подачи, дата фактического ответа или его отсутствие.
Самый простой способ не пропустить этот момент - хранить дедлайн ответа отдельным полем журнала, а не вычислять его заново по дате из соседней колонки. Тогда просроченная заявка видна сразу, без ручного пересчёта дат по каждой строке.
Статья - первый шаг. CARGO.RUN START ставит заявки, назначение машин и статусы рейсов в одну систему и доводит диспетчерскую работу до результата.


Комментарии
Пока нет комментариев. Будьте первым.