Транспортная компания: путевые листы и ЭТрН — архив на пять лет и где он лежит

MAATRIX

У логиста в шкафу — три коробки путевых листов за прошлый год, у диспетчера в почте — переписка с оператором ЭДО, а ЭТрН лежат в личном кабинете, доступ к которому оплачен только на текущий год. Стоит прийти запросу — от бухгалтера перед проверкой, от страховой после ДТП или от клиента, который спорит по срокам доставки — и поиск нужного документа превращается в квест на день-два. Дальше разберём, как собрать путевые листы и ЭТрН транспортной компании в один архив на собственном сервере: с понятной структурой, автоматическим сбором, резервным копированием и доступом за минуту, а не за два дня беготни по кабинетам и звонков бывшим сотрудникам.

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

Возьмём для примера компанию с парком в 40 машин на сборных и региональных перевозках. За год набегает заметный объём документов, и у каждого — свой формат и своя система-источник:

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

Почему "пять лет" — это не "положить в шкаф и забыть"

В заголовке этой статьи — пятилетний срок как ориентир хранения путевых листов и ЭТрН, часто встречающийся в практике транспортных компаний. Мы сознательно не будем ссылаться на конкретные статьи и приказы: точный срок и порядок хранения именно для вашей компании стоит уточнить у своего бухгалтера или юриста — это зависит от вида перевозок, системы налогообложения и внутренней учётной политики. Здесь важнее другое: пять лет — это не "закинуть архив на диск и забыть о нём", а обязанность в любой момент этого срока быстро достать конкретный документ по конкретному запросу.

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

• Спор с грузоотправителем или получателем — груз "потерялся" или пришёл повреждённым, и нужно поднять ЭТрН и путевой лист конкретного рейса двухлетней давности.
• Страховой случай после ДТП — страховая просит путевой лист, подтверждающий, что водитель в момент аварии был в рейсе по заданию компании.
• Трудовой спор с водителем — путевые листы подтверждают отработанные часы и маршруты, это база для расчёта зарплаты и переработок.
• Весовой и транспортный контроль — иногда запрашивают документы по конкретному рейсу постфактум.
• Внутренний аудит и передача дел — новый бухгалтер или логист должен видеть историю, а не начинать с нуля.

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

Где архив живёт сейчас — и почему это тонкий лёд

В большинстве транспортных компаний, с которыми приходится сталкиваться, документы за 3–5 лет хранятся так:

• Личные компьютеры и почта сотрудников. Диспетчер выгружает ЭТрН из кабинета оператора ЭДО себе на рабочий стол "для порядка". Уволился — увёл архив с собой, физически или морально.
• Личный кабинет оператора ЭДО без выгрузки. Пока действует контракт — документы доступны. Сменили оператора, не продлили тариф или он изменил условия хранения — доступ к старым ЭТрН может усложниться или потребовать отдельного запроса и оплаты.
• Файлы 1С на офисном компьютере без резервного копирования. Диск умер — база и все путевые листы за годы ушли вместе с ним.
• Бумажный архив в шкафу или на складе. Уязвим к затоплению, пожару, банальной потере при переезде офиса, и по бумаге ничего не найти без сканирования каждой папки вручную.
• USB-флешки "для надёжности". Формально бэкап, по факту — единственная копия, которая живёт в кармане у конкретного человека.

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

Своя архивная система: структура, которая отвечает за минуту

Альтернатива разрозненным копиям — выделенный сервер под архив, до которого транспортная компания дотягивается сама, в любой момент, без запросов к третьим сторонам. Задача архива — не просто хранить файлы, а быстро отвечать на вопрос "найди путевой лист за март 2024 года по машине А123ВС77" или "подними ЭТрН по рейсу от 14 мая".

Базовая структура на файловой системе может выглядеть так:

/archive/
├── putevye-listy/
│   ├── 2024/
│   │   ├── 01/
│   │   ├── 02/
│   │   └── 03/
│   │       ├── a123vs77_2024-03-14_reis-4821.pdf
│   │       └── a123vs77_2024-03-15_reis-4835.pdf
├── etrn/
│   ├── 2024/
│   │   └── 03/
│   │       ├── etrn_4821_2024-03-14.xml
│   │       └── etrn_4821_2024-03-14.pdf
└── akty-upd/
    └── 2024/

Единое правило именования файлов (госномер, дата, номер рейса или накладной) — уже половина дела: даже без специальной системы поиска find и grep по такой структуре находят документ за секунды. Но для парка от 20–30 машин имеет смысл поставить сверху лёгкий индекс — либо самописную таблицу в SQLite, либо готовую систему электронного архива вроде Paperless-ngx: она умеет OCR по сканам, теги, полнотекстовый поиск и веб-интерфейс, куда бухгалтер или логист заходит сам, без обращения к айтишнику.

Пример минимальной схемы SQLite-индекса, если делать своими силами:

CREATE TABLE documents (
  id INTEGER PRIMARY KEY,
  doc_type TEXT,        -- 'putevoy_list' | 'etrn' | 'akt'
  vehicle_plate TEXT,
  trip_id TEXT,
  doc_date DATE,
  file_path TEXT,
  added_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_vehicle_date ON documents(vehicle_plate, doc_date);

Такой индекс — это уже интерфейс "спросить архив", а не "перебрать папки руками".

Автоматический сбор: как документы попадают в архив без ручной беготни

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

Электронные документы из ЭДО и 1С. Большинство операторов ЭДО дают API или регулярную выгрузку по расписанию. Простой сценарий — задача по cron, которая раз в сутки забирает новые ЭТрН и раскладывает их по папкам:

#!/bin/bash
# pull-etrn.sh — забирает новые ЭТрН из выгрузки оператора ЭДО
# и раскладывает по /archive/etrn/ГОД/МЕСЯЦ/

SRC="/mnt/edo-export/incoming"
DST="/archive/etrn"

for f in "$SRC"/*.xml; do
  doc_date=$(python3 parse_etrn_date.py "$f")
  year=$(date -d "$doc_date" +%Y)
  month=$(date -d "$doc_date" +%m)
  mkdir -p "$DST/$year/$month"
  mv "$f" "$DST/$year/$month/"
done

# crontab
0 3 * * * /opt/scripts/pull-etrn.sh >> /var/log/archive-pull.log 2>&1

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

Бумажные путевые листы. Здесь без сканирования не обойтись, но процесс можно свести к минимуму: в офисе стоит недорогой сканер с папкой на сервере как сетевым диском, диспетчер раз в день прогоняет пачку путевых листов через сканер в эту папку, а Paperless-ngx (или аналогичный self-hosted инструмент) сам распознаёт дату и номер машины по тексту и раскладывает по тегам. Человеку остаётся только физически положить бумагу в сканер — раскладка и распознавание не его забота.

Резервное копирование: пять лет хранения не должны зависеть от одного диска

Архив, который живёт на единственном сервере без резервных копий, — это не архив, а отложенная потеря данных. Для документов, которые обязаны пережить пять лет, разумна классическая схема 3-2-1: минимум три копии данных, на двух разных типах носителей, одна копия — географически в другом месте.

На практике для такого архива это может выглядеть так:

• Основная копия — на рабочем сервере компании (например, выделенном сервере под 1С и документооборот).
• Локальная резервная копия — на другом диске того же дата-центра или в соседней стойке.
• Внешняя копия — на другом сервере, в другом регионе, зашифрованная перед отправкой.

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

# первый запуск — инициализация зашифрованного репозитория
borg init --encryption=repokey-blake2 /mnt/backup-remote/transport-archive

# ежедневный бэкап архива документов
borg create --stats --compression zstd \
  /mnt/backup-remote/transport-archive::archive-{now:%Y-%m-%d} \
  /archive

# хранить: 14 ежедневных, 8 недельных, 12 месячных копий
borg prune --keep-daily=14 --keep-weekly=8 --keep-monthly=12 \
  /mnt/backup-remote/transport-archive

Отдельно стоит закладывать место под рост архива за пять лет. Если ориентироваться на объём из первого раздела — около 20 000 документов в год на 40 машин, средний скан или PDF на 300–500 КБ, XML ЭТрН значительно легче, — суммарный объём за пять лет обычно укладывается в первые десятки гигабайт, а не в терабайты. Это очень грубая прикидка для ориентира, у вас цифры могут отличаться в разы в зависимости от разрешения сканов и количества фотофиксации грузов — но общий вывод стабилен: хранение такого архива недорогое, и экономить на резервных копиях ради места не имеет смысла.

И главное правило бэкапов, которое легко забыть: бэкап, который ни разу не восстанавливали, нельзя считать рабочим. Раз в квартал стоит доставать из резервной копии случайный путевой лист или ЭТрН и проверять, что он открывается и читается — это пять минут, которые экономят панику в момент, когда восстановление действительно понадобится.

Доступ и права: кто может поднять документ из архива

Архив без разграничения доступа — это просто другая версия проблемы "у всех своя копия", только теперь в одном месте. Разумное разделение для транспортной компании:

• Логисты и диспетчеры — чтение документов за текущий и предыдущий год, без права удаления.
• Бухгалтерия — чтение всего архива за весь срок хранения, без права удаления.
• Руководитель или ответственный за архив — полный доступ, включая перенос в холодное хранилище и (в редких случаях) удаление документов, для которых срок хранения истёк.
• Водители — как правило, доступа к архиву не требуется вообще; свои путевые листы они получают и подписывают по месту, а не ищут в архиве.

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

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