Склад хранит и готовит товар, рейс его доставляет, автопарк обеспечивает рейс. Odoo связывает три части: склад и автопарк — в готовых приложениях, а грузоперевозочный бизнес собирается из стандартных приложений. Мы прямо пишем, что в документации отдельное приложение для управления перевозчиком не описано.
Склад и фулфилмент рассмотрены на отдельной странице. Грузоперевозки и автопарк — на этой странице, ниже.
Адресное хранение, партии, пакетный отбор, штрихкод, возвраты и хранение товара клиента (3PL). Страница склада →
Заказ, рейс, накладная, CMR, субподрядный перевозчик и счёт-фактура. Прямо указано, что готовое приложение для перевозчика в документации не описано. Ниже, на этой странице →
Автомобиль, водитель, лизинг, сроки страхования, обслуживание, одометр и анализ расходов: приложение Fleet. Ниже, на этой странице →
Какие приложения нужны, определяется на диагностике. Planning и Documents входят в Enterprise (в открытом репозитории кода их нет).
Запрос грузовладельца, предложение и работа с постоянным клиентом.
Заказ на перевозку и экспедиторские услуги, условия договора.
Документы на перевозку и доставку, погрузочный док, групповая погрузка.
Автомобиль, водитель, договор, обслуживание, одометр.
Услуги субподрядного перевозчика, топливо, закупка ремонта.
Смены водителя и автомобиля, время в пути (Odoo 20).
Договор, копия накладной, документы на автомобиль; в Odoo 20 документы на автомобиль сортируются по государственному номеру.
Счёт-фактура, учёт субподрядчика, аналитический учёт по рейсу.
Претензии по потере или задержке груза, SLA. Входит в Enterprise.
Транспортная компания продаёт услугу: перевозку, экспедирование, хранение. В документации Odoo не описано отдельное приложение для управления перевозками (TMS) для перевозчика, и в отраслевом каталоге пакет для грузоперевозок не обнаружен (25 октября 2026 года). Есть только пакет 3PL: описание Odoo S.A. перечисляет отслеживание входящих и исходящих отправок, плату за хранение и расчёт за услуги, отслеживание транспорта и консигнации, а также клиентский портал. Пакет требует Enterprise и доступен в Odoo Online, Odoo.sh и на собственном сервере; по списку зависимостей в Apps Store он опирается на приложения Inventory, Purchase, Sales, Quality, Subscriptions, Website, Studio, CRM, Invoicing, Documents, Employees, Knowledge и Manufacturing. Поэтому бизнес перевозчика собирается из стандартных приложений: заказ — в Sales, рейс — в Project или Planning, автомобиль и водитель — в Fleet, субподрядный перевозчик — в Purchase, счёт-фактура — в Accounting.
В Odoo 20 Inventory есть формирование загрузки (dispatch), но оно рассчитано на доставку компанией собственных товаров на собственных автомобилях. Продукты группируются по перевозчику, партия привязывается к погрузочному доку, проверяется вместимость автомобиля (максимальные вес и объём). Для этого нужны приложение Fleet, подключение Mapbox, а также вес и объём у каждого продукта. Кнопка «Map» на карте отображается только у перемещений в статусе «В процессе».
Для накладной Odoo 20 заполняет форму CMR по имеющимся данным из документа доставки и распечатывает её; недостающие поля вводятся вручную. В партии на каждую доставку формируется отдельный CMR. Электронная накладная и путевой лист в Узбекистане (документ водителя с данными о рейсе) в готовых документах Odoo не упомянуты: они рассмотрены ниже вместе с «требованиями Узбекистана».
Приложение Fleet ведёт карточку автомобиля (модель, категория, водитель), договоры (лизинг, страхование), записи об обслуживании и ремонте, показания одометра и анализ расходов. Перед окончанием срока договора отправляется напоминание. В категории автомобиля записываются максимальные вес и объём: это используется для проверки вместимости при формировании загрузки.
В новостях Odoo 20 указано, что Documents автоматически сортирует документы на автомобиль по государственному номеру и привязывает их к нужному автомобилю; в счёте поставщика автомобиль выбирается автоматически по приблизительному совпадению. В Payroll при смене автомобиля сотрудника водитель в Fleet обновляется автоматически. В списке зарплатных локализаций в документации Odoo Узбекистан не упомянут, поэтому привязка водителя к автомобилю ведётся вручную: статус локализации расчёта зарплаты.
Честное ограничение: среди функций модуля Fleet из открытого кода (ветка 20.0) отдельной моделью журнал топлива (литры и цена) не найден, учёт шин и контроль рабочего времени водителя также не описаны. Расход на топливо можно вводить как тип услуги; этот путь проверяется на тестовой базе. Данные, которые требует электронный путевой лист (медосмотр водителя, остаток топлива), в Fleet полностью не покрываются.
Склад, учёт автопарка, форма CMR и формирование загрузки есть в готовых приложениях. Управление перевозчиком, накладная и путевой лист Узбекистана, а также GPS — отдельная работа. Данные основаны на документации, новостях и описании пакета Odoo 19 и 20; если в вашей версии есть отличия, проверим на диагностике.
| Задача | В стандартном Odoo | Дополнительная работа (BUline) |
|---|---|---|
| Склад, партии, пакетный отбор, штрихкод | Есть: Inventory и Barcode (Enterprise). Страница склада | Карта склада и способ отбора |
| Хранение товара клиента и учёт услуг (3PL) | Отраслевой пакет 3PL в Odoo 19 (Enterprise) | Тестирование пакета, ставки и правила расчёта |
| Автомобиль, договор, обслуживание, одометр, расходы | Есть: Fleet. Напоминание о сроке договора | Категории, виды услуг, структура документов |
| Журнал топлива, шины, рабочее время водителя | Отдельно в документации и открытом коде не описано | Поля Studio или внешняя система: оценивается |
| Формирование загрузки: перевозчик, док, вместимость | Есть: dispatch в Odoo 20 (нужны Fleet, Mapbox, вес и объём) | Заполнение веса и объёма продукта, места доков |
| Накладная CMR | Есть: в Odoo 20 печатается из документа доставки, остальные поля — вручную | Перечень полей и тест шаблона |
| Электронная накладная Узбекистана | В документации Odoo не упомянуто | Подключение к системе оператора или порядок ручного ввода: оценивается |
| Электронный путевой лист | В документации Odoo не упомянуто | Условия подключения к системе Министерства транспорта уточняются письменно |
| Управление перевозчиком (TMS): рейс, распределение грузов, расчёты | Отдельное приложение не описано; пакет в отраслевом каталоге не обнаружен | Сборка из Sales, Project, Planning и Fleet; оценивается |
| GPS-мониторинг | Не описано в документации | Интеграция по API провайдера телематики |
Нижеприведённое проверено по официальным источникам. Правила часто меняются: в день принятия решения мы заново открываем действующую редакцию и письменно подтверждаем её в Министерстве транспорта или у юриста.
Складской процесс — на странице склада. Здесь — рейс: каждый шаг оставляет запись в Odoo.
Запрос грузовладельца попадает в CRM, предложение оформляется в Sales как услуга перевозки или экспедирования.
Заказ подтверждается, открывается задача рейса. В Planning назначаются автомобиль и водитель, категория Fleet задаёт вместимость.
Если есть товар, в Inventory партия привязывается к погрузочному доку, проверяются вес и объём, готовятся накладная и CMR.
Расходы (топливо, дорога, ремонт) записываются на рейс. Путевой лист отдельно оформляется в системе Uztrans.
Документ доставки подтверждается, электронная накладная закрывается в системе оператора, копии документов загружаются в Documents.
Выставляется счёт-фактура за услугу. Если использовался субподрядчик, его счёт сверяется в Purchase.
Доходы и расходы сопоставляются в разрезе рейса, автомобиля и клиента; руководитель видит маржу.
Каждое подключение оценивается и выполняется отдельно. Мы не обещаем, что «готовый коннектор есть».
Отчёты не переносятся в отдельную таблицу: они формируются из документов в этой же базе.
Этапы соответствуют общему методу BUline. Срок письменно согласовывается после диагностики. Порядок внедрения →
Изучаются виды услуг (перевозка, экспедирование, хранение), процесс рейса, автопарк, документооборот, действующая программа и телематика. Результат: карта бизнес-требований (BRD).
Утверждаются набор приложений, в каком приложении вести рейс (Project или Planning), структура автопарка, документы и путь оператора, тип хостинга.
Сначала от начала до конца проходит одно направление или один клиентский рейс: заказ, погрузка, документ, счёт-фактура, маржа. Затем — автопарк и интеграции.
Диспетчер, водитель, кладовщик, главный механик и бухгалтер обучаются по ролям. Практика проходит на вашем списке автомобилей и клиентов. Выдаются инструкция и видеоуроки.
После запуска — 30 дней усиленной поддержки, затем согласованное постоянное сопровождение. При изменении правил подключение перепроверяется.
Этот список ускоряет диагностику. Начать можно и без полного комплекта.
| Ошибка | Последствие | Как предотвращаем |
|---|---|---|
| Ожидание, что Odoo — готовая система управления перевозками (TMS) | Логика рейса и перевозчика обнаруживается только в конце проекта | Прогнать процесс рейса на диагностике через стандартные приложения и письменно согласовать результат |
| Не вносить в товар вес и объём | Проверка вместимости при сборке грузов не работает | Сделать вес и объём обязательными при загрузке каталога |
| Считать, что путевой лист и накладная оформляются внутри Odoo | Документ отсутствует в системе оператора и в системе министерства | Письменно подтвердить путь документа на этапе архитектуры |
| Ожидание, что зарплата водителей рассчитывается в Odoo | В списке локализаций расчёта зарплаты Узбекистан не упомянут | Оценить расчёт зарплаты отдельно |
| Отложить подключение Mapbox на последний день | Маршрут и время в пути не работают | Настроить подключение в тестовой базе в начале проекта |
В документации отдельное приложение для перевозчика не описано, пакет для грузоперевозок не нашёлся и в отраслевом каталоге. Есть только пакет 3PL и функция сборки грузов в Odoo 20. Бизнес перевозчика собирается из Sales, Project или Planning, Fleet и Purchase; охват оценивается на диагностике.
Да: в Odoo 20 она печатается из документа доставки и заполняется имеющимися данными; недостающие поля вносятся вручную. В партии для каждой доставки формируется отдельная CMR. Подключение к электронной CMR (e-CMR) в документации не описано.
В документации Odoo такое подключение не упоминается. Электронная накладная оформляется в системе оператора, путевой лист — в системе Uztrans Министерства транспорта. Подключение зависит от возможностей оператора и системы и оценивается отдельно.
Карточка автомобиля, водитель, договор лизинга и страхования (напоминание о сроке), обслуживание и ремонт, одометр, анализ расходов. Журнал топлива, учёт шин и GPS в документации не описаны: они решаются полями Studio или внешней системой.
Когда компания доставляет собственный товар на собственных автомобилях. Нужны Fleet, подключение Mapbox, а также вес и объём в карточке товара; вместимость автомобиля берётся из категории. Для услуги перевозки чужого груза эта функция настраивается дополнительно, её пригодность проверяется в тестовой базе.
В документации Odoo такое подключение не упоминается. E-Permit — платформа Министерства транспорта, документация по её открытому API не подтверждена. Разрешения и документы TIR можно хранить в Documents; подключение мы запрашиваем у министерства письменно.
Стандартные приложения работают в Odoo Online. Если нужны телематика, оператор или специальный модуль, выбирается Odoo.sh или собственный сервер. Пакет 3PL опирается на Studio, его ограничения по хостингу проверяются на диагностике. Типы хостинга →
Лицензия Odoo зависит от числа пользователей и приложений (условия на odoo.com). Объём услуг BUline зависит от числа автомобилей, рейсов, складов и пользователей, приложений, кастомизации, интеграций, объёма данных и обучения. Точная стоимость и сроки сообщаются в письменном предложении после бесплатной диагностики.
На диагностике разберём ваши процессы и скажем, где достаточно стандартного Odoo, а где нужна настройка, — со списком приложений, версией и этапами.