Логист сводит рейсы в таблице из почты: своя система на сервере

MAATRIX

Утро логиста часто начинается одинаково: открыть почту, пролистать письма от перевозчиков и клиентов за ночь, найти в каждом номер рейса, статус и место машины, и руками перенести это в общую таблицу. К обеду половина строк уже не соответствует реальности, потому что новые письма пришли, а таблица осталась прежней. Ниже — как вместо этой рутины поднять на своём сервере простую систему учёта рейсов: одну базу, куда данные попадают структурированно, а не разбросаны по цепочкам писем и версиям Excel-файла.

Куда уходит время диспетчера: письма, копипаст, устаревшая таблица

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

Отсюда растёт таблица — Excel или Google Sheets, куда всё это сводится вручную. Первое время она работает: десяток рейсов, один диспетчер, всё под контролем. Проблема начинается с ростом объёма и числа людей, которые с этой таблицей работают. Копирование данных из письма в ячейку — механическая операция, а механические операции с текстом это именно то место, где чаще всего теряется цифра в номере накладной или дата разгрузки сдвигается на день из-за невнимательности при вставке значения не в ту строку.

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

Третье — синхронизация между несколькими сотрудниками. Файл в почтовом вложении или на локальном диске одного компьютера не даёт двум диспетчерам работать одновременно без риска перезаписать правки друг друга. Общий файл в облаке снимает часть проблемы, но конфликты версий и «а кто последний сохранял» всё равно возникают, а полноценной истории изменений по каждому рейсу таблица не ведёт — кто и когда поменял статус, обычно не восстановить.

Четвёртое — поиск и фильтрация. Найти все рейсы конкретного перевозчика за прошлый месяц или все, что сейчас в статусе «задержка», можно через сортировку в Excel, но с ростом числа строк и вкладок это превращается в отдельную задачу, а не в операцию на пару секунд, которая нужна логисту постоянно в течение дня.

Что должна уметь система учёта рейсов — и что ей точно не нужно на старте

Прежде чем разворачивать что-либо на сервере, стоит трезво определить набор функций, реально нужный одному диспетчеру или небольшой логистической команде, а не пытаться с нуля повторить интерфейс тяжёлой корпоративной TMS.

Минимально нужны:

• карточка рейса: номер, перевозчик, маршрут (откуда — куда), дата загрузки, плановая и фактическая дата разгрузки, статус;
• статусная модель, которая отражает реальный процесс: например, «ожидает загрузки», «в пути», «на границе», «на разгрузке», «доставлен», «проблема» — и переключение между статусами должно занимать одно действие, а не пересохранение файла;
• карточка контрагента: перевозчик или клиент, контакты, реквизиты, привязанные к нему рейсы;
• поле для вложений — скан накладной (CMR/ТТН), фото при приёмке, документы от перевозчика;
• журнал событий по рейсу — кто и когда менял статус, короткий комментарий («водитель на связи, ETA сдвигается на 3 часа»);
• фильтры и поиск по маршруту, перевозчику, статусу, диапазону дат — то, что в таблице требует ручной сортировки, здесь должно быть готовым представлением.

Не нужны на старте: биллинг и автоматический расчёт ставок фрахта, интеграция с десятком телематических платформ для трекинга GPS в реальном времени, электронный документооборот с ЭЦП, ролевая модель на полсотни пользователей с отдельными правами на каждое поле. Это функциональность специализированных TMS, рассчитанных на крупные логистические компании с отдельным ИТ-отделом под их сопровождение. Для одного диспетчера или команды из двух-пяти человек такая система обернётся месяцами настройки ради возможностей, которыми никто не будет пользоваться.

Почему не готовая TMS с абонплатой за каждого сотрудника

Готовые облачные TMS решают задачу учёта рейсов быстро: регистрация, готовые поля под груз и маршрут, мобильное приложение для водителей. Но у модели «подписка за пользователя в месяц» есть особенности, которые стоит взвесить заранее.

Абонплата считается за каждого, кто заходит в систему — диспетчера, менеджера по продажам, бухгалтера, которому нужен доступ для сверки. Сумма растёт линейно с командой, и это фиксированные расходы, которые платятся вне зависимости от того, сколько рейсов реально прошло через систему в этом месяце — в низкий сезон логистики счёт от вендора не становится меньше.

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

Ещё нюанс — зависимость от решений вендора: интерфейс меняется без вашего участия, нужная функция может переехать в более дорогой тариф, а бесплатный план — быть урезан задним числом. Логист, у которого от бесперебойной работы учёта прямо зависит операционка, не может позволить себе такую неопределённость в инструменте.

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

Поднимаем систему на сервере: NocoDB поверх PostgreSQL

Для команды из одного диспетчера или нескольких человек разумный вариант — не тяжёлая специализированная TMS, а лёгкая надстройка с готовым веб-интерфейсом над обычной базой данных. NocoDB решает именно эту задачу: берёт таблицы в PostgreSQL и строит вокруг них интерфейс с фильтрами, представлениями (таблица, канбан по статусу рейса, календарь по датам разгрузки) и формами — без единой строчки кода с вашей стороны. Подробности установки — в статье про установку NocoDB на VPS; здесь — минимальный рабочий стек под задачу логиста.

Для базы на несколько сотен активных рейсов и историю за пару лет с запасом хватит VPS с 2 vCPU и 4 ГБ RAM, диск лучше сразу взять от 40 ГБ, если планируете хранить сканы накладных и фото приёмки прямо в системе. На сервере с Ubuntu 24.04 ставим Docker и Docker Compose, дальше — файл docker-compose.yml:

version: "3.8"

services:
  logist-db:
    image: postgres:16-alpine
    container_name: logist-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: logistics
      POSTGRES_USER: logist_user
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - logist_db_data:/var/lib/postgresql/data

  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    depends_on:
      - logist-db
    environment:
      NC_DB: "pg://logist-db:5432?u=logist_user&p=замените_на_свой_пароль&d=logistics"
      NC_PUBLIC_URL: "https://logist.вашдомен.ru"
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  logist_db_data:
  nocodb_data:

Порт NocoDB намеренно проброшен только на 127.0.0.1 — наружу отдаёт обратный прокси с TLS, а не голый HTTP-порт. Для этого подойдёт Caddy — он сам получает и продлевает сертификат Let's Encrypt:

logist.вашдомен.ru {
    reverse_proxy 127.0.0.1:8080
}

После docker compose up -d и запуска Caddy система доступна по вашему домену с рабочим HTTPS. На файрволе закройте всё лишнее — на UFW это ufw allow 22/tcp, ufw allow 80/tcp (нужен только для выпуска сертификата), ufw allow 443/tcp и ufw enable; порт базы данных наружу открывать не нужно вовсе — он и так виден только внутри сети Docker.

Если позже команда вырастет до полноценного логистического отдела с расчётом ставок, биллингом и десятками пользователей — тогда есть смысл присмотреться к специализированной TMS. Но для одного диспетчера или небольшой команды это будет избыточная сложность администрирования ради функций, которыми вы не будете пользоваться.

Структура базы: рейсы, контрагенты, статусы, документы

В NocoDB таблицы — это обычные таблицы PostgreSQL, поэтому структуру стоит продумать один раз, до того как в базу попадут первые сто рейсов. Рабочий минимум — три связанные таблицы.

Рейсы (trips): номер рейса, перевозчик, маршрут (пункт загрузки, пункт разгрузки), дата и время загрузки, плановая и фактическая дата разгрузки, статус, поле для вложений (скан CMR/ТТН, фото приёмки), примечание.

Контрагенты (partners): название, тип (перевозчик/клиент/грузополучатель), контактное лицо, телефон, email, реквизиты — таблица, на которую ссылаются рейсы, чтобы не вбивать одни и те же данные перевозчика заново в каждую карточку.

События (trip_events): связь с рейсом, тип события (смена статуса, звонок водителю, обновление ETA, проблема), дата и время, короткий комментарий своими словами — не для отчётности, а чтобы через день восстановить, что именно произошло и когда.

Пример того, как выглядит журнал событий в интерфейсе NocoDB:

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

Отдельно стоит настроить представление-канбан по полю «статус» — колонки «ожидает загрузки», «в пути», «на границе», «на разгрузке», «доставлен», «проблема». Диспетчер в течение дня просто перетаскивает карточку рейса между колонками при поступлении новой информации — это быстрее и нагляднее, чем искать нужную строку в длинной таблице и менять в ней значение вручную.

Куда деваются письма от перевозчиков и доступ для нескольких сотрудников

Полностью убрать почту из процесса вряд ли получится — перевозчики и клиенты продолжат присылать обновления письмами, и это нормально. Меняется не источник информации, а то, что происходит с ней дальше: вместо копирования данных в разрозненную таблицу диспетчер один раз заносит их в структурированную карточку рейса, и дальше эта карточка — единственный источник правды для всей команды, а не письмо, которое лежит в чьём-то личном почтовом ящике.

Если однотипных обновлений от одного-двух постоянных перевозчиков накапливается заметный объём, можно присмотреться к автоматизации: связке через IMAP, которая вытаскивает данные из писем определённого формата и обновляет карточку рейса без ручного ввода. Это отдельная и не самая простая задача — формат писем у разных перевозчиков разный, и без ручной донастройки правил разбора текста результат будет ненадёжным. На старте разумнее сначала обкатать саму структуру базы на ручном вводе, и только потом, если рутина действительно съедает много времени, добавлять частичную автоматизацию под конкретные повторяющиеся форматы писем.

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

Работа логиста часто идёт не только из офиса — нужно ответить клиенту по телефону, находясь вне рабочего места. NocoDB — обычное веб-приложение, поэтому открывается в браузере телефона по вашему домену без установки отдельного приложения; на iOS и Android можно добавить страницу на домашний экран через «Добавить на главный экран» — по ощущениям это неотличимо от нативного приложения.

Отдельная тема — бэкапы. Вся история рейсов и контрагентов живёт в одном PostgreSQL-контейнере на одном сервере, и без регулярных резервных копий это такая же единая точка отказа, какой раньше была таблица на одном компьютере — просто с другой начинкой. Минимальный рабочий вариант — ежедневный дамп базы через cron:

#!/bin/bash
docker exec logist-db pg_dump -U logist_user logistics | gzip > /backups/logist-$(date +%F).sql.gz
find /backups -name "logist-*.sql.gz" -mtime +14 -delete

Добавьте это в crontab -e на ежедневный ночной запуск и обязательно копируйте архив за пределы сервера — на отдельное хранилище или в другой регион, иначе бэкап на том же диске не спасает от отказа самого сервера. Более надёжный вариант с шифрованием и дедупликацией вместо самописного скрипта разобран в статье про установку BorgBackup на VPS — там же объяснено, почему бэкап должен работать без ручного контроля месяцами, а не только пока о нём помнят.

Похожий переход от разрозненных источников к своей базе на сервере разобран и для другой профессии — в статье про CRM риелтора на своём сервере те же принципы (единая точка отказа, права доступа, регулярный бэкап) показаны на другом типе данных, но с той же логикой.

Частые вопросы