Что такое TMS-система и зачем она перевозчику и экспедитору
TMS-система – это рабочая среда, в которой перевозчик или экспедитор ведёт рейс от заявки и расчёта до доставки, документов и взаиморасчётов. Она связывает маршрут, ставки, валюты, расходы, исполнителей и статусы в одной карточке. TMS нужна, когда данные о перевозках расходятся между таблицами, перепиской и учётом, поэтому сложно быстро увидеть состояние рейса, маржу или задолженность.
Что такое TMS простыми словами
Каждая перевозка начинается с карточки заявки: заказчик, груз, точки и окна загрузки и разгрузки, условия, ответственный экспедитор, перевозчик и транспорт. Вместо отдельных строк в таблицах команда работает с одним рейсом, где видны текущее состояние и тот, кто должен выполнить следующее действие.
Как выглядит расчёт рейса
Например, ставку заказчика согласовали в евро, а перевозчику нужно заплатить в гривнах. Отдельной строкой добавляется агентское вознаграждение или согласованные расходы на дополнительную услугу. Для пересчёта система применяет определённый договором курс на дату загрузки, доставки, счёта или оплаты и хранит эту дату вместе с курсом. Тогда диспетчер и бухгалтер видят, из каких составляющих получена маржа, даже если курс или расход изменились после согласования.
Типовые этапы рейса
- Заявка принята, маршрут и условия зафиксированы.
- Ставки согласованы, перевозчик и транспорт назначены.
- Транспорт прибыл на загрузку, груз принят.
- Рейс в пути, отклонение или задержка переданы ответственному.
- Доставка подтверждена, оригиналы документов ожидаются или получены.
- Счета и оплаты сверены, рейс закрыт.
Документы в карточке перевозки
К рейсу привязывают заявку-договор, CMR или ТТН, акт выполненных работ, счёт и подтверждение доставки. Для каждого документа полезно видеть состояние: ожидается, получена копия, получен оригинал, проверен или возвращён на исправление. Так отсутствующий акт не теряется среди файлов, а бухгалтерия понимает, можно ли выставлять или оплачивать счёт.
Кому нужна TMS-система
TMS уместна, когда один рейс включает несколько валют, расходов и ответственных, а изменение маршрута вынуждает отдельно исправлять таблицу, переписку, счёт и учётную запись. Ещё один сигнал – статус перевозки известен только конкретному диспетчеру, а финансовый результат можно посчитать лишь после ручной сверки документов.
На какие вопросы система отвечает за секунды
- Какая маржа по рейсу с определённым номером и из каких доходов и расходов она состоит?
- Какие рейсы уже доставлены, но по ним нет закрывающих документов?
- Сколько нужно заплатить перевозчикам на выбранную дату и по каким счетам?
- Какие машины ещё не прибыли на загрузку и кто отвечает за уточнение?
- В каких рейсах изменили ставку, маршрут или курс после первоначального согласования?
Индивидуальная разработка имеет смысл, если стандартная схема не учитывает правила тарифов, согласований, ролей, документов или обмена с учётной системой. Перед решением стоит описать несколько обычных и проблемных рейсов. Это покажет, нужна ли отдельная логика или достаточно упорядочить существующий процесс.
Чем TMS отличается от CRM и ERP
CRM-системы ведут контакты, запросы, предложения и историю договорённостей. TMS начинает подробную работу там, где появляется конкретный рейс: маршрут, транспорт, этапы, расходы, документы и маржа.
ERP-система хранит финансовый и управленческий учёт, закупки и другие ресурсы. TMS передаёт ей согласованные счета, акты и суммы, а получает справочники, контрагентов или состояния оплат. До разработки нужно определить, где создаётся каждая запись, кто может её изменить и какая система имеет приоритет при расхождении.
Какие модули входят в TMS
Базовое ядро включает реестр заявок, карточку рейса, расчёт доходов и расходов, этапы выполнения, документы, взаиморасчёты и отчёты по рейсам. Диспетчеру нужны маршрут, транспорт, контакты, сроки и отклонения. Бухгалтерии – счета, валюты, курсы, акты и состояния оплат. Руководителю – маржа, незакрытые рейсы, просроченные действия и журнал изменений.
Отдельные модули и интеграции
GPS, кабинет водителя, маршрутизацию, телематику и е-ТТН подключают только под конкретный сценарий. Кабинет водителя может принимать задания и фото подтверждения, координаты – уточнять прибытие, а электронный документооборот – передавать подписанный документ в карточку рейса. Наличие интеграции само по себе не гарантирует полезный результат.
Для каждого обмена фиксируют событие запуска, перечень полей, направление передачи и действие при ошибке. Например, если учётная система временно недоступна, счёт остаётся в очереди с видимым статусом, а ответственный может повторить отправку. Это предотвращает ситуацию, когда данные не попали в учёт, но рейс ошибочно считается закрытым.
Как проходит разработка TMS на заказ
Разработка начинается с разбора реальных рейсов, а не с перечня экранов. Команда проходит заявку от получения до закрытия, записывает формулы, точки согласования, документы, роли и исключения. Первый этап ограничивают завершённым контуром, например от создания заявки до подтверждения доставки и передачи счёта в учёт.
- Разбирают обычный рейс, рейс с изменением маршрута и случай с неполными документами.
- Согласовывают поля карточки, формулы, валюты, дату курса, этапы и права ролей.
- Проектируют обмен с учётной системой и правила повтора при ошибке.
- Показывают прототип диспетчеру, экспедитору, бухгалтеру и руководителю на их задачах.
- Разрабатывают первый контур и проверяют его на копиях реальных рейсов без лишних персональных данных.
Что нужно от заказчика
Нужны доступ к тестовой среде существующей учётной системы и описание её API, примеры реальных рейсов, шаблоны документов и рабочие справочники. К справочникам относятся контрагенты, транспорт, водители, типы грузов, валюты, статьи расходов и статусы. Также нужны ответственные из диспетчерской и бухгалтерии, которые объяснят исключения и проверят результат.
Подрядчика стоит спросить, как хранится история изменения ставки и курса, что происходит при ошибке обмена, как ограничиваются финансовые данные по ролям и по каким признакам рейс считается закрытым. Конкретные ответы позволяют сравнить предложения по логике работы, а не по количеству заявленных модулей.