ВЕБ ШТУРМ
Обсудить →

Минтранс ГИС ЭП: что важно знать к обязательности 1 сентября 2026

Веб Штурм
  • Минтранс
  • ГИС ЭП
  • ЭПД
  • 152-ФЗ
  • интеграция
  • compliance

Электронные перевозочные документы (ЭПД) становятся обязательными для всех грузо- и пассажирских перевозок в РФ с 1 сентября 2026 года. Минтранс уже выделил 152 млн ₽ на модернизацию ГИС ЭП в 2026 году. Те, кто не интегрируются вовремя, получают двойной риск: блокировка работы + штрафы 152-ФЗ за нарушение порядка передачи ПД пассажиров. Делимся реальным опытом интеграции для крупного речного круизного оператора.

Контекст

ГИС ЭП — государственная информационная система электронных перевозочных документов Минтранса. Туроператоры круизных и прогулочных рейсов обязаны передавать туда списки пассажиров с персональными данными до отправки. Формат — CSV-пакеты со строгой структурой, шифрование ГОСТ 28147-89, отправка через FTP, асинхронные XML-квитанции о приёме/отказе.

Параллельно действует 152-ФЗ: те же ПД, но с ограничениями на обработку, передачу третьим лицам, хранение. Между двумя законами нужно пройти, не нарушив ни одного.

Архитектура нашей интеграции

В Круизном флоте (K:/webshturm/germes-frontend/frontend/) интеграция с ГИС ЭП реализована как отдельный pipeline:

[оператор → заявка с ПД пассажиров]
 ↓
[анонимизатор ФИО → personRef «Имя Отчество Ф.»] ← email-уведомления только так
 ↓
[CSV-формирователь по схеме АЦБПДП]
 ↓
[ZIP + GOST 28147-89 шифрование через КриптоПро CSP]
 ↓
[FTP push → quittance email от Минтранса]
 ↓
[XML-парсер квитанций → 10 категорий ошибок]
 ↓
[email-маршрутизация: менеджеру / бухгалтеру / Telegram critical-alert]

Каждый этап решает один тип проблем. Связка такая, потому что любое смешивание (например, отправка с полными ФИО в Telegram) — нарушение 152-ФЗ.

Анонимизация на источнике

Главный принцип: ПД проходят минимальное число точек обработки. Email-уведомления никогда не содержат полных ФИО клиентов — только «personRef» вида Иванов Иван И..

function toPersonRef(fio: string): string {
 // "Иванов Иван Иванович" → "Иванов Иван И."
 const parts = fio.trim().split(/\s+/);
 if (parts.length < 3) return fio;
 return `${parts[0]} ${parts[1]} ${parts[2][0]}.`;
}

В админке менеджер видит полные ФИО (для исправления заявки). В письмах, чатах, логах — только personRef. Сами ФИО лежат в одной таблице с RLS, доступ — только авторизованной роли.

CSV-пакеты по схеме АЦБПДП

АЦБПДП (Автоматизированный центр обработки персональных данных пассажиров) — оператор ГИС ЭП. Принимает строго типизированные CSV в кодировке Windows-1251. Любое отклонение — отказ всего пакета.

Шаблон строки (упрощённо):

last_name;first_name;middle_name;birth_date;doc_type;doc_series;doc_number;citizenship;tour_id;cabin_no
Иванов;Иван;Иванович;01.01.1980;01;4509;123456;643;TR2026-0042;A-12

Тонкие места:

В нашем pipeline это валидируется на этапе формирования CSV, а не на отправке — отказ ловится до того, как пакет ушёл в АЦБПДП.

Шифрование ZIP + ГОСТ 28147-89

АЦБПДП требует ZIP-архив, зашифрованный по ГОСТ 28147-89 через сертифицированное ПО (КриптоПро CSP). Бесплатных Python/Node-библиотек для этого нет — только официальный КриптоПро.

Решение — отдельный shell-скрипт, который вызывается из Node:

#!/bin/bash
# encrypt-package.sh
INPUT="$1"
OUTPUT="$2"
RECIPIENT_CERT="$3"

zip -j "$INPUT.zip" "$INPUT"
csptest -keyset -cont '\\.\HDIMAGE\PassengerCert' -keytype exchange
cryptcp -encr -cert "$RECIPIENT_CERT" "$INPUT.zip" "$OUTPUT"
rm "$INPUT.zip"

Запускается на отдельной Windows-VM (Hyper-V) с установленным КриптоПро CSP — на Linux это не работает.

Парсер XML-квитанций

После приёма АЦБПДП присылает XML-квитанцию по email (наш quittance@-ящик). Парсер раскладывает по 10 категориям ошибок:

const ERROR_CATEGORIES = {
 'PD_INVALID': 'Невалидный паспорт',
 'PD_FORMAT': 'Формат поля',
 'PD_MISSING': 'Отсутствует обязательное поле',
 'STAFF_INVALID': 'Экипаж — данные не заполнены',
 'TOUR_NOT_FOUND': 'Тур не найден в реестре',
 'CABIN_INVALID': 'Каюта не зарегистрирована',
 // ...4 ещё
};

В одном прогоне (575 архивных квитанций за весь сезон) парсер автоматически разнёс по категориям все ошибки + отметил default unknown→IT для нестандартных случаев. Из этого формируется email-дайджест с 3 секциями:

  1. 🚨 Экипаж не заполнен (критично, отдельный Telegram-alert)
  2. Ошибки данных ПД (менеджеру с конкретным полем)
  3. Каюты без данных (менеджеру для дозаполнения)

В каждой строке дайджеста — close-button с HMAC close-token (TTL 7 дней) для повторной отправки исправленной квитанции без авторизации.

Реальный E2E-тест с prod-Минтрансом

01 мая 2026 года в 18:03 квитанция от АЦБПДП пришла со статусом «принято» — Уровень A нашего канала был задеплоен в 13:33 того же дня. От разработки до приёма реального prod-пакета — около 4.5 часов, включая отладку кодировки Windows-1251 и пары полей doc_type.

Что мы из этого вынесли

Ссылки