ГИС ЭП Электронная Путёвка: что нужно знать туроператорам в 2026

ГИС ЭП — Государственная Информационная Система Электронная Путёвка — обязательный канал учёта электронных путёвок туроператоров. Каждая проданная путёвка должна быть зарегистрирована в ГИС, изменения статуса (аннуляция, возврат) — синхронизированы. На практике это значит, что система бронирования туроператора работает в связке с ГИС асинхронно: после успешной оплаты — формирование ЭП и отправка.

Контекст 2026. В начале февраля 2026 стало известно, что Минэкономразвития фактически прекратило развитие ГИС ЭП — последний контракт на сопровождение завершён в декабре 2025-го, новых тендеров с тех пор не объявлено. Тем, кто интегрировался ранее (как наш клиент в августе 2024), система продолжает работать в режиме maintenance. Новые подключения становятся всё сложнее.

Что такое ГИС ЭП

Полная расшифровка: Государственная Информационная Система Электронная Путёвка. Назначение — централизованное формирование и учёт электронных путёвок на основе договоров реализации туристского продукта. Принимающие стороны:

• Туроператоры — обязаны передавать каждую сформированную путёвку.
• Турагенты — работают через своих туроператоров.
• Туристы — получают доступ к своей путёвке в личном кабинете госуслуг.
• Гос-органы (Ростуризм, Росстат) — используют для статистики и контроля.

Связка с другими системами:

• 152-ФЗ — обработка ПД туристов (ФИО, паспорт, контакты).
• Договор реализации турпродукта — каждая ЭП связана с конкретным договором.
• Реестр туроператоров — отправлять ЭП имеют право только аккредитованные операторы.

Нормативная база

Технические требования

• Транспорт: REST API (основной) + резервный CSV-канал.
• Кодировка: строго UTF-8.
• Валидация: двухступенчатая — предварительная на стороне туроператора (по схеме) + при приёме в ГИС.
• Связь со статусом: ЭП имеет жизненный цикл создана → активна → завершена | аннулирована | возвращена. Каждое изменение синхронизируется.
• Связка с оплатой: ЭП формируется только после подтверждения оплаты (либо предоплаты по договору).

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

Реализовано в системе бронирования речных круизов (production). Стек:

• Триггер: успешная оплата через Альфа-банк SBP C2B или ЮKassa → callback → enqueue в Hatchet.
• Worker: gis-ep-worker в hermes-stack docker-compose.
• Связка с PDF: одновременно формируется PDF-ваучер (через PDFme + cruise-pack плагин) для туриста и ЭП для ГИС. Один источник данных — одна модель тура и пассажира.
• Резервирование: все попытки отправки логируются в crm_activities, неудачные — в DLQ для ручного разбора.

Workflow (упрощённо)

// hermes-stack/gis-ep-worker/src/workflows/issue-voucher.ts
export const issueElectronicVoucher = defineWorkflow(hatchet)
  .step('snapshot-order', async ({ input }) => {
    // Снимок данных тура + пассажира на момент формирования ЭП
    return { snapshot: await fetchOrderSnapshot(input.orderId) };
  })
  .step('build-payload', async ({ parentOutput }) => {
    return { payload: buildGISEPPayload(parentOutput.snapshot) };
  })
  .step('submit-to-gis', async ({ parentOutput }) => {
    const res = await gisEP.submit(parentOutput.payload, {
      apiKey: process.env.GIS_EP_API_KEY,
      idempotencyKey: input.orderId, // одна оплата = одна ЭП
    });
    if (res.code !== 'OK') throw new RetryableError(res.message);
    return { gisVoucherId: res.voucherId };
  })
  .step('persist-and-notify', async ({ parentOutput }) => {
    await db.orders.update(input.orderId, { gisVoucherId: parentOutput.gisVoucherId });
    await crmActivities.add({ kind: 'gis-ep:issued', orderId: input.orderId, ... });
  });

Типичные грабли при интеграции

Связка ГИС ЭП с PDF-ваучером

Один и тот же тур порождает два документа:

1. PDF-ваучер для туриста — печатный документ через PDFme (наш плагин cruise-pack даёт компоненты под речные круизы: схема палубы, расписание стоянок, маршрут). Хранится в Supabase Storage, ссылка /pdf/v/{shortToken} в email и SMS.
2. Электронная путёвка в ГИС — машиночитаемый документ для гос-системы. Хранится в ГИС, в нашей БД только gisVoucherId для связи.

Оба формируются в одном Hatchet workflow после успешной оплаты — это гарантирует консистентность.

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

• ГИС ЭП лучше делать сразу при разработке системы бронирования, а не «прикручивать потом» — слишком много connecting points (статусы, аннуляции, возвраты, ПД).
• Idempotency на уровне orderId решает 90% проблем с дублями. Не используйте случайные UUID — они теряют смысл при retry.
• Snapshot-pattern для данных туриста обязателен — иначе при правке данных в туре после оформления ЭП теряется консистентность.
• DLQ + админка для разбора окупается на первом же инциденте с массовым отказом ГИС.

Ссылки

• Закон «Об основах туристской деятельности» — №132-ФЗ
• 152-ФЗ — обработка ПД туристов
• Hatchet TS SDK v1 — workflow engine
• PDFme — visual PDF designer