# Техническое задание на платформу ДонБилет

Разработать платформу продажи и сопровождения пассажирских билетов: новый backend и API, сайт ДонБилет, личные кабинеты, рабочий веб-интерфейс сотрудников поддержки и финансов, билетный виджет и клиентское мобильное приложение ДонБилет. Приложение выпускается для iOS и Android. Пользователь должен пройти весь путь от поиска поездки до получения билета, обслуживания заказа и возврата без обращения к техническому интерфейсу iDempiere.

Документ определяет функциональные и технические требования к платформе и клиентскому мобильному приложению ДонБилет.

## Содержание

- [1 Назначение и границы версии](#1-назначение-и-границы-версии)
- [2 Термины и основные сущности](#2-термины-и-основные-сущности)
- [3 Роли и доступ](#3-роли-и-доступ)
- [4 Архитектура и технологические границы](#4-архитектура-и-технологические-границы)
- [5 Справочники и поставщики](#5-справочники-и-поставщики)
- [6 Поиск и выбор поездки](#6-поиск-и-выбор-поездки)
- [7 Оформление и резерв](#7-оформление-и-резерв)
- [8 Оплата, выпуск и документы](#8-оплата-выпуск-и-документы)
- [9 Личный кабинет и принадлежность покупок](#9-личный-кабинет-и-принадлежность-покупок)
- [10 Единый поиск заказов и билетов для сотрудников](#10-единый-поиск-заказов-и-билетов-для-сотрудников)
- [11 Карточка заказа](#11-карточка-заказа)
- [12 Карточка билета](#12-карточка-билета)
- [13 Стоимость и финансовые компоненты](#13-стоимость-и-финансовые-компоненты)
- [14 Возврат билета](#14-возврат-билета)
- [15 Биллинг, комиссии и сверка](#15-биллинг-комиссии-и-сверка)
- [16 Сайт, виджет и поддержка](#16-сайт-виджет-и-поддержка)
- [17 Требования к мобильному приложению](#17-требования-к-мобильному-приложению)
- [18 Мобильное приложение ДонБилет](#18-мобильное-приложение-донбилет)
- [19 Веб-кабинет юридического лица и ИП](#19-веб-кабинет-юридического-лица-и-ип)
- [20 Веб-кабинет агента](#20-веб-кабинет-агента)
- [21 Депозит, лимиты, согласования и коды](#21-депозит-лимиты-согласования-и-коды)
- [22 Подключаемые расширения исходного предложения](#22-подключаемые-расширения-исходного-предложения)
- [23 Администрирование, контент, аналитика и аудит](#23-администрирование-контент-аналитика-и-аудит)
- [24 Взаимодействие частей системы](#24-взаимодействие-частей-системы)
- [25 Нефункциональные требования](#25-нефункциональные-требования)
- [26 Эксплуатационная документация и конфигурация](#26-эксплуатационная-документация-и-конфигурация)
- [27 Решения заказчика](#27-решения-заказчика)

## 1 Назначение и границы версии

### 1.1 Результат для заказчика

Система продаёт билеты через каналы, сохраняет историю пользователей и заказов, обеспечивает работу поддержки с найденным билетом непосредственно из результатов поиска и ведёт проверяемый учёт оплат и возвратов. Новый backend обслуживает целевые сценарии без обязательной работы Java API, iDempiere и прямого чтения старой базы.

В настоящем ТЗ слово «клиент» означает покупателя или пассажира. Сотрудник поддержки работает в защищённом веб-интерфейсе.

### 1.2 Состав обязательных работ

| **Код** | **Результат** | **Основное содержание** |
|----|----|----|
| V3-01 | Backend и API | Авторизация, справочники, поставщики, поиск, резерв, заказы, платежи, билеты, возвраты, документы, фоновые процессы |
| V3-02 | Данные и история | Сохранение пользователей, истории покупок и финансов; обслуживание ранее созданных заказов |
| V3-03 | Сайт ДонБилет | Публичные страницы, поиск и покупка, гостевой сценарий, личный кабинет |
| V3-04 | Веб-кабинеты B2B | Кабинет юридического лица и ИП, кабинет агента, договоры, депозит, ограничения и отчёты в границах разделов 19–21 |
| V3-05 | Суперадминка | Работа поддержки, управление данными и доступом, единый поиск, карточки заказов и билетов, финансовая сверка |
| V3-06 | Виджет | Встраиваемый поиск и передача в оформление; режим полной покупки определяется настройкой согласованной площадки |
| V3-07 | ДонБилет iOS и Android | Один пассажирский продукт, две платформенные сборки |
| V3-09 | Комплект результатов | Исходный код, схема данных, API, инструкции, сборки приложений и материалы публикации |

Мобильное приложение ДонБилет выпускается для iOS и Android и использует единые серверные методы и бизнес-правила.

### 1.3 Ключевые функциональные требования

| **Требование** | **Решение** | **Раздел** |
|----|----|----|
| Клиентское приложение | ДонБилет для iOS и Android | 17–18 |
| Все заказы в ЛК | Единая история личных покупок, включая гостевые и перенесённые, с правилами подтверждённой принадлежности | 9 |
| Поиск пользователя | Email и телефон; переход из пользователя к заказам и билетам | 9, 10 |
| Ошибка в почте заказа | Проверенная ручная привязка поддержкой с основанием и аудитом | 9 |
| Пароль не доставляется | Смена пароля и выдача разового пароля уполномоченной поддержкой | 9 |
| Единый поиск | Один раздел «Заказы и билеты» с обычными и дополнительными критериями | 10 |
| Действия с билетом | Билет открывается с отдельными действиями PDF, допустимого изменения и возврата | 10–12 |
| Состав карточек | Поля заказа и порядок полей билета по разделам 11–12 | 11–12 |
| Форма возврата | Все составляющие стоимости, ручной ввод и заполнение из ответа API | 13–14 |
| История возврата | Даты, суммы по строкам и раздельные результаты поставщика, внутреннего учёта и денег | 14–15 |

### 1.4 Границы функционального состава

Внутренний справочник перевозчиков, получение их предложений, название перевозчика в билете и внутренние взаиморасчёты сохраняются.

Лояльность, динамическая комиссия, ИИ-сопоставление предложений, составные поездки, самостоятельные продажи авиа/ЖД и отелей описаны как подключаемые расширения в разделе 22. Состав этих расширений определяется отдельно. Заявки B2B на авиа, ЖД и отели через поддержку входят в указанный веб-сценарий.

## 2 Термины и основные сущности

| **Сущность** | **Значение и отличие от других сущностей** |
|----|----|
| Продукт | ДонБилет: клиентское приложение, оформление, договорные настройки и разрешённые данные |
| Канал продажи | Сайт, iOS, Android, виджет, агент, корпоративный кабинет, сохранённый старый канал; хранится отдельно от поставщика |
| Пользователь | Учётная запись клиента с проверенными контактами и правами |
| Пассажир | Человек, на которого оформлена перевозка; не обязан иметь учётную запись и может отличаться от покупателя |
| Покупатель | Лицо или организация, оформляющие и оплачивающие заказ |
| Поставщик API | Внешняя система расписаний и инвентаря; не равен перевозчику |
| Перевозчик | Исполнитель перевозки; один перевозчик может присутствовать в нескольких API |
| Предложение | Конкретная продаваемая перевозка с источником, местами, тарифом, актуальностью и условиями |
| Заказ | Общий объект оформления, контактов и оплаты; содержит один или несколько билетов и финансовые связи |
| Билет | Документ на пассажира и перевозку; имеет собственные номер, состояние, стоимость, документы и возврат |
| Резерв | Временное удержание места у поставщика или денег на депозите; это разные виды резерва |
| Платёжная попытка | Попытка оплаты определённой версии заказа, суммы и валюты |
| Возврат у поставщика | Изменение обязательства по перевозке и получение результата от источника |
| Внутренний возврат | Отражение возврата в backend и запуск либо подтверждение требуемой денежной операции по заданной ответственности |
| Денежный возврат | Возврат через эквайринг либо зачисление на депозит; не подтверждается одним статусом билета |
| ManualReturnForced | Историческое имя внутренней команды возврата. В новом интерфейсе раскрывается понятным названием и режимом операции |
| Депозит | Подтверждённые денежные средства B2B-клиента за вычетом списаний; отдельно учитываются резервы |
| ЛК | Личный кабинет клиента с его заказами, билетами, документами и обращениями |

Заказ, билет, платёжная попытка и возврат имеют собственные устойчивые внутренние ID. Человекочитаемый код заказа, номер билета и ID транзакции не используются как взаимозаменяемые ключи. Все внешние идентификаторы сохраняются вместе с поставщиком и областью данных.

## 3 Роли и доступ

### 3.1 Матрица полномочий

| **Роль** | **Область данных** | **Разрешённые действия** |
|----|----|----|
| Гость | Текущее оформление и отдельно подтверждённая покупка | Поиск, покупка, проверенное получение заказа и документов; возврат по разрешённому гостевому сценарию |
| Клиент | Личные покупки и сохранённые пассажиры | Профиль, история, PDF, запрос возврата, поддержка, управление сессиями |
| Участник компании | Разрешённые покупки своей организации | Покупка в пределах прав и лимитов, запрос согласования, документы |
| Суперпользователь компании | Своя организация | Участники, роли, лимиты, согласования, депозит и документы в пределах договора |
| Участник агента | Разрешённые продажи агентского аккаунта | Оформление и обслуживание в границах договора |
| Суперпользователь агента | Свой агентский аккаунт | Участники, ограничения, разрешённые продажи и отчётность |
| Поддержка | Назначенные бренды и обращения | Поиск, карточки, повторная выдача документа, проверенная привязка покупки и разрешённое восстановление доступа |
| Специалист по возвратам | Назначенные заказы | Возврат у поставщика и внутренний возврат по отдельным разрешениям |
| Финансовый сотрудник | Разрешённые финансовые данные | Сверка, подтверждение поступлений, ручные корректировки, денежные возвраты в пределах разрешений |
| Администратор | Настройки и назначенная область управления | Пользователи, роли, справочники, интеграции, контент; финансовые полномочия выдаются отдельно |
| Аудитор | Разрешённая история | Чтение журнала и отчётов без изменения данных |

## 4 Архитектура и технологические границы

### 4.1 Технологический стек

Для веб-интерфейсов используются Next.js, React и TypeScript; для серверной части — NestJS и TypeScript, PostgreSQL с Prisma, Redis и BullMQ. Предусмотрены API gateway, авторизация, транспортные функции, администрирование, уведомления и поисковый индекс. Взаимодействие с поставщиками выполняется через адаптеры с едиными контрактами.

### 4.2 Схема ответственности

Клиентские интерфейсы обращаются по HTTPS в API gateway. Gateway проверяет внешнюю авторизацию и направляет запросы в доменные компоненты. Доменные компоненты выполняют бизнес-правила, изменяют PostgreSQL и обращаются к адаптерам поставщиков, банка, документов и уведомлений. Очереди обеспечивают восстановимую фоновую обработку.

| **Компонент** | **Ответственность и постоянные данные** |
|----|----|
| Авторизация | Пользователи, подтверждённые контакты, пароли, сессии, временные полномочия |
| Каталог | Города, станции, направления, перевозчики, соответствия внешних ID |
| Интеграции | Конфигурация подключений, возможности источников, нормализация и диагностические результаты |
| Поиск | Предложения и производный кэш; не хранит окончательную истину об оплаченных билетах |
| Заказы | Версия состава, пассажиры, контакты, источник, резерв и процесс оформления |
| Платежи | Попытки, подтверждения, внешние транзакции, денежные возвраты и сверка |
| Билеты и возвраты | Выпуск, документы, операции по отдельным билетам, состояния поставщика и внутренней обработки |
| Биллинг | Депозиты, начисления, комиссии, проводки, взаиморасчёты и закрытые периоды |
| Документы | Файлы, версии, права, сроки ссылок и происхождение документа |
| Поддержка и администрирование | Единый поиск, карточки, обращения, разрешённые команды и аудит |
| Уведомления и аналитика | Шаблоны, доставка, события и производные показатели |

Выделение ответственности не требует отдельного микросервиса для каждой строки. Следует использовать существующие модули и готовые библиотеки, выделяя процессы при необходимости изоляции и нагрузки. Замена BullMQ на другой оркестратор без обоснования не является обязательным результатом.

### 4.3 Данные и доступ ДонБилета

**ARC-01.** Backend и общие контракты обслуживают платформу ДонБилет. Заказы, платежи и возвраты хранятся в согласованной модели данных ДонБилета. Общие справочники публикуются из единого источника в необходимые проекции.

**ARC-02.** Клиентский канал определяется разрешённой конфигурацией домена и приложения и проверяется вместе с авторизацией. Публичный client_id, параметр запроса или заголовок сам по себе не является секретом и не открывает чужие данные. Канал сохраняется в заказе и аудите.

**ARC-03.** Каждый заказ и его денежные операции имеют одного владельца и согласованные транзакционные границы. Аналитика читает разрешённые проекции, не изменяя исходные записи. Доступ к покупкам определяется подтверждённой принадлежностью и правами пользователя.

Личный кабинет показывает всю принадлежащую пользователю историю ДонБилета во всех разрешённых каналах. Покупки не объединяются по одному неподтверждённому совпадению телефона или email.

### 4.4 Надёжность и развёртывание

**ARC-04.** PostgreSQL хранит состояние процессов; Redis, очередь и поисковый индекс содержат восстанавливаемые производные данные. Перезапуск worker не теряет принятый платёж, оформленный билет или начатый возврат. Критическое поручение фоновой обработке согласуется с записью в БД, например через transactional outbox.

**ARC-05.** Используются воспроизводимые сборки и версионируемые миграции. Конфигурации сред и секреты отделены от кода. Обновление приложения не пересоздаёт базу и не удаляет постоянные файлы. Тестовая среда изолирована от боевых оплат и уведомлений.

## 5 Справочники и поставщики

### 5.1 Города, станции и направления

**CAT-01.** Населённый пункт и станция — отдельные сущности. Станция хранит внутренний ID, название, город, адрес, координаты при наличии, часовой пояс, состояние, источник и внешние соответствия. Для поездки сохраняются конкретные станции посадки и высадки, а не только города.

**CAT-02.** Сотрудник может создать станцию вручную без API либо из записи источника. Синхронизация не перезаписывает подтверждённые ручные названия, адреса и связи. Внешний ключ уникален внутри поставщика; одинаковый ID у другого поставщика не создаёт совпадение.

**CAT-03.** Сверка показывает новые, изменившиеся, неподтверждённые и конфликтные записи. Доступны ручная привязка, создание новой станции, исправление привязки и откладывание решения. Автоматическое предложение не является окончательным объединением.

**CAT-04.** Направление — упорядоченная пара: А–Б отличается от Б–А. Исчезновение у одного источника не скрывает направление, доступное у другого. Ошибка или неполная выгрузка не приводит к массовому удалению справочников.

**CAT-05.** Исторический заказ хранит снимок станций, маршрута и перевозчика. Изменение справочника не меняет уже выписанный билет. Спорные объединения и изменения имеют автора, время и основание.

### 5.2 Контракт адаптера

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

| **Возможность** | **Требуемое поведение** |
|----|----|
| Каталог и расписания | Загрузка с пагинацией, актуальностью и контролем полного/неполного ответа |
| Поиск и детали | Нормализованное предложение со ссылкой на источник и внешние ID |
| Места и тариф | Актуальная схема при наличии, правила выбора, обязательные сборы, срок действия цены |
| Резерв и отмена | Внешний ID резерва, срок и способ освобождения; запрет выдуманного подтверждения |
| Выпуск | Результат по каждому билету, номер, документ и восстановление после потери ответа |
| Возврат | Возможность предварительного расчёта, выполнение, получение статуса и детализации |
| Сверка | Получение заказа, билета, оплаты или возврата по устойчивому внешнему ключу |

**INT-01.** Возможности задаются по источнику. Если нет точного предварительного расчёта возврата, интерфейс не вызывает изменяющий метод ради «предпросмотра». Если нет детализации комиссий, отсутствующие суммы показываются как неизвестные и направляются на сверку.

**INT-02.** Адаптер сохраняет семантику денежных компонентов и внешний результат с техническим идентификатором, временем и безопасной диагностикой. Секреты, полный паспорт и карточные данные не попадают в обычный лог.

**INT-03.** Перенести используемые функции действующих поставщиков. Реестр и очерёдность согласовать до разработки. Адаптерный слой расширяем; подключение неизвестных будущих API требует отдельной оценки.

## 6 Поиск и выбор поездки

### 6.1 Ввод и результаты

**SRC-01.** Клиент выбирает отправление, прибытие и дату. Подсказки различают города и конкретные станции; одинаковые названия уточняются регионом и адресом. Доступны обмен направлениями и повтор поиска с сохранёнными условиями.

**SRC-02.** Выдача содержит станции, дату и местное время отправления и прибытия, длительность, перевозчика, полное название рейса, доступные места, минимальную применимую цену и обязательные сборы, предусмотренные удобства, правила багажа и возврата. При отсутствии сведений показывается понятное отсутствие данных.

**SRC-03.** Поддерживаются сортировки по отправлению, стоимости и длительности, фильтры по времени, станции и перевозчику. Набор дополнительных фильтров зависит от реальных данных источника. Изменение фильтра не запускает новую покупку или резерв.

**SRC-04.** Система различает отсутствие рейсов, отсутствие мест, недоступность источника и частичную выдачу. При сбое одного API доступные результаты других источников сохраняются. Пользователь видит предупреждение и возможность повторить поиск.

### 6.2 Свежесть, календарь и дубли

**SRC-05.** Справочники, выдача, детали и места имеют отдельные правила свежести. Одинаковые параллельные запросы объединяются; фоновые задачи имеют ограничения нагрузки. Дата в календаре с неизвестной ценой не отображается как бесплатная поездка.

**SRC-06.** Перед резервированием сервер повторно проверяет цену, места и доступность. Изменение полной стоимости требует подтверждения клиента. Старая карточка в кэше не гарантирует ни место, ни тариф.

**SRC-07.** При группировке совпадающих предложений сохраняются все доступные внешние варианты. Число мест разных источников не суммируется. Выбор поставщика продажи фиксируется до резерва; после оплаты он не меняется произвольно. Интеллектуальное сопоставление разных API относится к расширению раздела 22.

## 7 Оформление и резерв

### 7.1 Пассажиры и места

**ORD-01.** Поддерживаются покупка без регистрации и покупка после входа. При входе в процессе оформления черновик не теряется, а принадлежность заказа проверяется до связывания с профилем.

**ORD-02.** Для каждого пассажира вводятся категория тарифа, ФИО, дата рождения, пол, гражданство, тип и номер документа в требуемом поставщиком составе. Допускаются отсутствие отчества и иностранный документ, если это разрешено источником. Обязательность полей зависит от категории и маршрута, а не от произвольной маски интерфейса.

**ORD-03.** Сохранённый пассажир подставляется в форму, но после выпуска билет содержит самостоятельный снимок. Исправление карточки пассажира не исправляет документ на перевозку. Доступный способ исправления выписанного билета определяется поставщиком и отдельным разрешением.

**ORD-04.** При наличии схемы автобуса показываются доступные, занятые, выбранные и недоступные места. Печатный номер места не смешивается с техническим Place ID. При продаже без выбора места показывается соответствующее условие. Нельзя создать собственную фиктивную схему вместо отсутствующей схемы источника.

### 7.2 Контакты и состав заказа

**ORD-05.** Контакт покупателя включает email и телефон. Перед оплатой email отображается целиком для проверки, телефон приводится к согласованному международному формату. Проверка формата не считается подтверждением владения контактом.

**ORD-06.** Заказ показывает пассажиров, места, тариф, все обязательные сборы, выбранный багаж, добровольную страховку при наличии, скидку и итоговую сумму. Дополнительная платная услуга подключается явным выбором клиента. Купон проверяется сервером с объяснением результата.

**ORD-07.** Сохраняются бренд, канал, организация/агент при наличии, поставщик, внешние ID, версия цены, валюта, применённые правила и необходимые согласия. Изменение состава создаёт новую версию заказа; созданная платёжная попытка остаётся связанной со своей версией.

### 7.3 Сроки и конкуренция

**ORD-08.** Время окончания резерва определяется сервером и источником. Интерфейс показывает оставшееся время и состояние истечения. Изменение часов устройства не продлевает резерв. Восстановление приложения получает актуальное состояние с сервера.

**ORD-09.** Повторное нажатие и параллельные запросы не создают несколько резервов или заказов одной операции. Если результат внешнего вызова неизвестен, система сначала проверяет исходную операцию. Снятие локального черновика не объявляется подтверждённым снятием внешнего резерва.

**ORD-10.** Если поставщик допускает частичный выпуск нескольких билетов, результат хранится по каждому билету. Клиент видит фактически выписанное и проблемные позиции. Принудительный повтор выпуска всего заказа не допускается.

## 8 Оплата, выпуск и документы

### 8.1 Платёжная попытка

**PAY-01.** Сервер создаёт платёжную попытку с уникальным ID, версией заказа, суммой, валютой и получателем. Ссылка прежней попытки не используется после изменения оплачиваемой суммы. Позднее подтверждение старой попытки не теряется и направляется на сверку.

**PAY-02.** Оплата проходит через согласованный эквайринг и его защищённую форму или SDK. Платформа не хранит номер карты и CVV. Доступность СБП, банковского приложения, Альфа-Пэй и других способов определяется действующим подключением, а не только наличием кнопки.

**PAY-03.** Переход браузера или приложения на страницу успеха не подтверждает оплату. Сервер проверяет подлинность уведомления либо получает статус у банка; сверяет заказ, сумму, валюту и внешнюю транзакцию. Повторное уведомление не создаёт второе поступление.

### 8.2 Выпуск и восстановление

**PAY-04.** После подтверждения оплаты система завершает выпуск у поставщика и сохраняет результат по билетам. «Оплачено», «Билеты оформляются» и «Билеты выпущены» отображаются раздельно. Оплаченный заказ не возвращается в неоплаченный из-за позднего пустого ответа.

**PAY-05.** Оплата без билета поступает в контролируемую очередь восстановления. До повторного выпуска проверяется результат у источника. Невозможность выпуска приводит к разрешённому сценарию компенсации с понятным состоянием; повторное списание не выполняется.

**PAY-06.** Заказ и билеты доступны после перезагрузки страницы, переустановки приложения и на другом устройстве после входа. Недоставленное письмо не означает отсутствия билета и не запускает повторную продажу.

### 8.3 PDF и доставка

**DOC-01.** Для выписанного билета доступны просмотр, скачивание и штатная передача PDF средствами устройства. Файл содержит документ поставщика либо документ по утверждённому шаблону с корректными реквизитами. QR/штрихкод отображается только из легитимного источника, собственный код посадки не изобретается.

**DOC-02.** Документ проверяется на принадлежность при каждом получении. Короткая ссылка не заменяет проверку прав для закрытого файла. Название файла и уведомления не раскрывают номер паспорта. Допускается повторная отправка документа по подтверждённому адресу с ограничением частоты.

**DOC-03.** Возвращённый или отменённый билет не выдаётся как действительный посадочный документ. Исторический PDF допускается только с явной пометкой об утрате действительности либо как отдельный архивный документ; сохраняются документ возврата и финансовая история. Недоступность оригинального файла показывается как ошибка документа, а не как отсутствие заказа.

**DOC-04.** Фискальный чек и билет — разные документы. Система хранит известные реквизиты чека, состояние его формирования и ссылку при наличии. Кто формирует чек и чек возврата — банк, поставщик или отдельный сервис — фиксируется в паспорте интеграции.

## 9 Личный кабинет и принадлежность покупок

### 9.1 Учётная запись и история

**ACC-01.** ЛК предоставляет профиль, подтверждённые контакты, сохранённых пассажиров, все личные заказы, предстоящие поездки, историю, билеты, документы, возвраты и обращения. В истории сохраняются покупки сайта, приложений, виджета и перенесённые покупки своего бренда. Оформление за другого пассажира не скрывает заказ от покупателя.

**ACC-02.** Вкладки и фильтры не удаляют данные. История содержит оплаченные, неоплаченные, отменённые, частично выпущенные, возвращённые и проблемные заказы с понятным состоянием. Глубина просмотра задаётся политикой хранения. Пагинация позволяет найти более старую покупку; ограничение размера первой страницы не обрезает историю навсегда.

**ACC-03.** После входа список обновляется; при открытии приложения, возвращении фокуса и завершении операции запрашивается актуальное состояние. При недоступности источника уже сохранённые заказы остаются видны с отметкой свежести. Кнопка «Повторить» повторяет чтение, а не покупку.

### 9.2 Автоматическая привязка гостевой покупки

**ACC-04.** Если при покупке без входа указан email, соответствующий существующей учётной записи с подтверждённым email в том же бренде, заказ автоматически связывается с этой учётной записью. Это серверный процесс, не зависящий от последующего открытия страницы успеха. После выпуска билет виден в соответствующем заказе ЛК.

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

**ACC-05.** Если пользователь ещё не зарегистрирован, покупка остаётся гостевой. После регистрации и подтверждения того же email система подбирает доступную личную историю, включая более ранние покупки, и однократно связывает её. Если профиль существует, но адрес не подтверждён, доступ к найденным заказам открывается после подтверждения.

**ACC-06.** Совпадение телефона, ФИО или документа отдельно не присваивает заказ ЛК. Совпадение email не меняет уже установленного другого владельца и не раскрывает организации личные покупки. При нескольких старых аккаунтах с одной почтой или конфликте принадлежности автоматический выбор запрещён: создаётся задача разбора с безопасным статусом.

**ACC-07.** Привязка проверяется транзакционно и выдерживает одновременные вход, обработку покупки и фоновую миграцию. Одна покупка не дублируется в базе; повторная привязка к тому же владельцу возвращает прежний результат. Событие фиксирует источник правила, пользователя, заказ и время.

**ACC-08.** До подтверждения прав гостю не показывается содержимое чужого ЛК и факт наличия конкретного аккаунта. Автоматическая привязка не отменяет требования к получению заказа гостем: код покупки и знание email без достаточной проверки не становятся универсальным доступом к паспорту, PDF или возврату.

### 9.3 Ошибка email и привязка поддержкой

**ACC-09.** В карточке пользователя и в карточке заказа доступна команда «Добавить заказ в ЛК» для уполномоченной поддержки. Сотрудник находит пользователя по email или телефону, выбирает конкретный заказ или билет, проверяет покупку и подтверждает операцию с причиной и номером обращения.

Перед подтверждением показываются целевой ЛК, текущий владелец, код заказа, состав билетов, бренд, контакты покупки в разрешённом объёме и предупреждение о предоставляемом доступе. Для проверки используется утверждённая инструкция: сведения поездки и пассажира, документ оплаты или иной согласованный набор. Пароль, CVV и полный номер карты не запрашиваются.

**ACC-10.** Если билет входит в общий заказ, команда явно сообщает, какие позиции станут доступны. По умолчанию связывается заказ целиком с его билетами и документами. Передача только одного билета другому пользователю не выполняется скрыто: такая модель требует отдельного решения о правах, контактах и финансовой истории. Конфликт с другим владельцем передаётся уполномоченному сотруднику для отдельной перепривязки.

**ACC-11.** Исправление контактной почты и назначение владельца — разные изменения. Сотрудник может выполнить их совместно в одной форме, но подтверждает каждое; исходные контакты покупки сохраняются в истории. Изменение профиля пользователя не переписывает контакты всех старых заказов и не отбирает уже законно принадлежащие ему покупки.

**ACC-12.** После успешной операции заказ появляется в ЛК, приложении и разрешённых каналах при следующем обновлении. Повтор операции не создаёт дубль. Ошибка привязки исправляется компенсирующей командой с аудитом; первоначальное событие не удаляется. Уведомление клиенту не содержит паспортных и полных платёжных сведений.

### 9.4 Пароль и разовый доступ

**ACC-13.** Сохраняются установка, смена и восстановление пароля. Пользователь меняет пароль после предусмотренной проверки; поддержка может инициировать восстановление или сформировать разовый пароль по отдельному разрешению. Существующие способы входа, включая email-код, инвентаризируются и сохраняются в согласованном составе.

**ACC-14.** Разовый пароль генерирует сервер криптографически стойким способом. В БД хранится только защищённое проверочное значение. Контрольные параметры для согласования: срок 30 минут, до пяти неверных попыток, один успешный вход, аннулирование предыдущего разового пароля при выпуске нового. Эти параметры настраиваются централизованно.

**ACC-15.** Разовый пароль показывается сотруднику только в момент создания либо доставляется через разрешённый сервис. Поддержка передаёт его по заранее проверенному альтернативному каналу, если email не работает. В обычные журнал, комментарий, аналитическое событие и обращение открытый пароль не записывается. Подтверждение личности выполняется до выпуска, а не через сам новый пароль.

**ACC-16.** После входа с разовым паролем клиент обязан установить постоянный пароль до операций с закрытыми данными и возвратами. Разовый секрет погашается атомарно: два одновременных входа не используют его дважды. Клиент может просмотреть и завершить активные сессии; смена пароля и блокировка отзывают сессии по принятой политике.

### 9.5 Данные пассажиров и удаление аккаунта

**ACC-17.** Сохранение пассажира для повторных покупок является отдельным действием. Клиент может удалить сохранённую карточку без удаления законно оформленного билета и обязательной финансовой истории. Смена фамилии в профиле не исправляет выписанный документ.

**ACC-18.** В профиле есть понятная команда запроса удаления учётной записи и связанных необязательных данных. Перед подтверждением показываются последствия для обоих приложений при общем входе, активные поездки и порядок получения оставшихся документов. Закрытие аккаунта не оформляет возвраты автоматически. Обязательные сроки сохранения финансовых и перевозочных документов задаются утверждённой политикой; оставляемые сведения, основание и срок сообщаются пользователю. Детали публикации приложений приведены в разделе 17.

## 10 Единый поиск заказов и билетов для сотрудников

### 10.1 Раздел и форма поиска

**ADM-01.** Вместо отдельных рабочих блоков «Билеты» и «Заказ билетов» используется один раздел «Заказы и билеты». В нём одна форма критериев, два вида результата и переходы между связанными объектами. Для пользователя раздела не требуется знание поля SIB Order и скрытого меню iDempiere.

| **Группа** | **Поле** | **Поиск и представление** |
|----|----|----|
| Основная | First Name | По данным пассажира; отдельное поле, допускается комбинация |
| Основная | Second Name | По данным пассажира; отдельное поле |
| Основная | Last Name | По данным пассажира; отдельное поле |
| Основная | Ticket Number | Номер билета как строка с сохранением ведущих нулей |
| Основная | Телефон | Нормализованный телефон контакта заказа; поиск по номеру в разрешённой области |
| Основная | EMail | Email контакта заказа; точное нормализованное совпадение по умолчанию |
| Основная | Ключ поиска | Человекочитаемый код заказа; не ID платёжной попытки |
| Основная | Комментарий/Помощь | Идентификатор/код транзакции для поиска оплаты; ищется также в выделенном индексе транзакций |
| Раскрываемая | SIB Doc Number | Серия и номер документа пассажира; с отдельным разрешением и маскированием |
| Раскрываемая | Seat Number | Печатный номер места, в сочетании с датой, рейсом или другими критериями |
| Дополнительные фильтры | Период, бренд, источник, перевозчик, статусы | Сужают выборку; не заменяют перечисленные поля |

**ADM-02.** Исходные подписи First Name, Second Name и Last Name сохраняются в карте миграции. До её утверждения нельзя предполагать, что Second Name и Last Name в старой базе соответствуют привычному английскому порядку. Интерфейс получает понятные русские подписи из проверенной карты; техническое имя доступно в описании поля.

**ADM-03.** Несколько заполненных полей соединяются условием «И». Поиск по любому из ФИО доступен отдельно; слишком широкая выборка просит уточнить период или значение. Номер билета, код заказа и код транзакции ищутся точно по умолчанию. Частичное совпадение ФИО, телефона или email включается явно и ограничивается правами, длиной строки и числом результатов. Исходные значения не теряются при нормализации.

### 10.2 Какой объект показывать

| **Заполненные критерии** | **Основной результат** | **Доступные переходы** |
|----|----|----|
| Ticket Number или поля пассажира/документа/места | Билеты | Открыть билет с действиями; при необходимости открыть его заказ |
| Телефон, email, ключ заказа, идентификатор оплаты | Заказы | Открыть заказ с билетами и платежами |
| Одновременно критерии билета и заказа | Билеты, удовлетворяющие всем критериям | Сводка связанного заказа и переход к нему |
| Поиск в карточке клиента | Все разрешённые заказы выбранного владельца | Фильтр билетов внутри найденной истории |

**ADM-04.** Фильтры не переключают тип результата неожиданно. Над таблицей явно указан режим «Билеты» или «Заказы» и число найденных объектов; сотрудник может переключить представление с сохранением критериев. Заказ с несколькими найденными билетами в представлении заказов выводится одной строкой с числом совпавших билетов.

**ADM-05.** Из строки билета доступны отдельные команды «Открыть билет», «PDF/Печать», «Возврат» и «Открыть заказ», а изменение — только если поддерживается источником и разрешено сотруднику. Команда PDF не находится внутри общего меню возвратов. Нажатие печати не вызывает изменяющий запрос.

### 10.3 Таблица и состояние поиска

Таблица билетов показывает номер, пассажира в разрешённом объёме, маршрут и отправление, место, статус билета, полную стоимость, код заказа, бренд и источник. Таблица заказов показывает код, дату покупки и отправления, маршрут, контакты с маскированием, число билетов, сумму, статус оплаты, статус заказа, бренд и источник.

**ADM-06.** Поддерживаются сортировка, пагинация, сохранение фильтров при возврате из карточки, очистка формы и понятное пустое состояние. Время поиска и актуальность данных видимы. Ошибка источника отличается от отсутствия результата; повтор не удаляет ранее найденный заказ.

**ADM-07.** Поиск не привязывает покупку к пользователю и не выполняет возврат. Выгрузка и раскрытие полного документа требуют отдельных разрешений. Персональные критерии не попадают в общедоступный URL, браузерную аналитику и обычные журналы запросов. Аудит фиксирует цель и факт доступа в необходимом объёме, без копирования полного паспорта.

## 11 Карточка заказа

### 11.1 Основные поля

**ORD-11.** После поиска по реквизитам заказа открывается карточка со следующими сведениями. Техническое название сохраняется для проверки переноса и интеграций; рядом используется понятная русская подпись.

| **Поле заказчика** | **Значение и правила** |
|----|----|
| Ключ поиска | Код заказа, удобный для обращения в поддержку и копирования |
| Описание | Исходное описание с сохранённым назначением; внешние ID не подменяются свободным текстом |
| Комментарий/Помощь | Идентификатор для поиска оплаты; отдельно хранятся структурированные транзакции и внутренний комментарий |
| Значение стоимости | Общая стоимость всех билетов заказа с учётом скидок; валюта и точность до копейки |
| Departure station | Полное название и данные станции отправления |
| Arrival station | Полное название и данные станции прибытия |
| Дата и время | Отправление с датой и местным часовым поясом |
| SIB Route | Полное название рейса; не только участок, купленный пассажиром |
| Статус оплаты | Финансовое состояние заказа, отдельно от выпуска |
| Статус заказа | Состояние оформления и обслуживания |
| Дата по | Дата и время прибытия, включая переход через полночь и другой пояс |
| EMail | Контакт покупки; история исправлений доступна по правам |
| Телефон | Контакт покупки в исходном и нормализованном виде |
| Купон на скидку | Код/основание купона и фактически применённая стоимость скидки на заказ |
| Frontend API | Исходный клиентский канал; историческое значение сохраняется без выдуманной расшифровки |
| SIB DB Stations API | Источник транспортных данных/поставщик API |
| Business Partner | Перевозчик; не подменяется названием технического API |

Дополнительно показываются внутренний и внешние ID, бренд, дата создания, покупатель и связь с ЛК, организация/агент при наличии, исходная версия состава, срок резерва, последнее обновление и ответственный за проблемную операцию. Полные персональные данные раскрываются по правам.

### 11.2 Вкладки и действия

**ORD-12.** В карточке есть вкладки «Билеты», «Платежи и возвраты», «Документы», «История» и связанная поддержка. Число билетов видно до открытия вкладки. По каждому билету доступны его собственные статус и действия; возврат одного не возвращает остальные.

**ORD-13.** Команды заказа: обновить статус, открыть/передать доступный документ, повторить разрешённую доставку, перейти к обращению, выполнить проверенную привязку к ЛК. Отмена, изменение и возврат выполняются предметными командами с проверками, а не произвольным редактированием статуса в форме.

**ORD-14.** Одновременное изменение обнаруживается по версии объекта. При конфликте сотрудник видит актуальное состояние и повторно выбирает допустимое действие. Нельзя сохранить старую форму поверх состоявшейся оплаты или возврата.

## 12 Карточка билета

### 12.1 Порядок полей

**TKT-01.** Основные данные билета располагаются в указанном заказчиком порядке. Группа стоимости также сохраняет этот порядок. Нулевое значение и отсутствие данных различаются. В интерфейсе клиента показываются необходимые покупателю сведения; служебная детализация комиссий предназначена сотрудникам с соответствующими правами.

| **№** | **Поле** | **Правило представления** |
|----|----|----|
| 1 | Passenger Category | Вид тарифа/категория пассажира из снимка покупки |
| 2 | SIB Document Type | Тип документа |
| 3 | SIB Doc Number | Серия и номер; маскирование и отдельное раскрытие по правам |
| 4 | Гражданство | Название и технический код при необходимости |
| 5 | First Name | Значение по утверждённой карте полей |
| 6 | Last Name | Значение по утверждённой карте полей |
| 7 | Second Name | Значение по утверждённой карте полей; отсутствие допускается по правилам источника |
| 8 | День рождения | Дата без ошибочного сдвига по часовому поясу |
| 9 | Gender | Пол в представлении источника и нормализованном значении |
| 10 | Ticket Number | Номер билета строкой; доступно копирование |
| 11 | Baggage Ticket Number | Номер багажного билета либо явное отсутствие |
| 12 | Seat Number | Печатный номер места; технический Place ID отдельно |
| 13 | Ticket Status | Состояние билета и момент последнего подтверждения |
| 14 | Тарифная стоимость | Тариф перевозки до выбранного правила скидки |
| 15 | Агентские принципала | Отдельный компонент либо признак вхождения в другой компонент |
| 16 | Агентские субагента | Отдельный компонент либо признак вхождения в другой компонент |
| 17 | Провоз багажа | Стоимость багажа |
| 18 | Агентское вознаграждение | Сервисный/агентский компонент с установленным владельцем |
| 19 | Insured Amount (страховка) | Стоимость страховой услуги по данному билету, если поле источника имеет именно это значение |
| 20 | Скидка | Применённая сумма уменьшения стоимости, с основанием и распределением |
| 21 | Полная стоимость | Сумма к оплате по билету с учётом всех непересекающихся составляющих и скидки |

Поле Insured Amount не переименовывается автоматически в страховую премию без проверки: у конкретного источника оно может обозначать иную страховую величину. Если это страховое покрытие, оно хранится отдельно от цены страховки и не суммируется с оплатой. Смысл подтверждается картой финансовых полей.

### 12.2 Контекст и операции

**TKT-02.** Над указанной последовательностью допускается компактная строка контекста: код заказа, маршрут, отправление, бренд и поставщик. Она не меняет порядок основных полей. Доступны переход в заказ и связь с покупателем без повторного ручного поиска.

**TKT-03.** «PDF/Печать» и «Возврат» представлены отдельными действиями. Для возврата открывается самостоятельная форма с суммами и подтверждением; печать открывает только документ. Изменение билета доступно при подтверждённой возможности поставщика; иначе показывается обращение в поддержку. Локальное изменение ФИО не выдаётся за переоформление билета.

**TKT-04.** Карточка содержит историю изменения Ticket Status, связанные оплату и возвраты, суммы по строкам, даты и инициаторов. Исходная стоимость не перезаписывается суммой возврата. Действительность билета, внутреннее состояние возврата и прохождение денег отображаются раздельно.

## 13 Стоимость и финансовые компоненты

### 13.1 Состав стоимости

**FIN-01.** Покупатель видит итоговую стоимость до оплаты, валюту, применённую скидку и платные дополнительные услуги. Денежные значения отображаются точно, для рублей — с двумя знаками после запятой.

**FIN-02.** Стоимость билета содержит тариф, агентские принципала и субагента, багаж, агентское вознаграждение и страховку, если они применяются к покупке. Сбор, уже включённый в другую строку, повторно не увеличивает цену. Первоначальная стоимость и условия покупки сохраняются в истории.

### 13.2 Скидки и суммы возврата

**FIN-03.** Применённая скидка уменьшает стоимость покупки один раз. Для заказа с несколькими билетами сохраняется скидка каждого билета. Возврат одного билета не изменяет стоимость остальных, кроме случаев, предусмотренных условиями продажи.

**FIN-04.** Сотрудник видит по каждой строке стоимости: «Оплачено», «Уже возвращено», «Предлагается вернуть», «Удержано» и «Остаток». В форме доступны тарифная стоимость, агентские принципала, агентские субагента, багаж, агентское вознаграждение, страховка, скидка и полная стоимость. Итог соответствует составляющим; скидка не выплачивается пассажиру отдельной суммой.

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

Возвратность сборов, багажа и страховки, размер удержания и зависимость от времени до отправления определяются действующими условиями продажи и поставщика. Проценты 5/15/25 не применяются как единое правило ко всем перевозчикам. Если поставщик не передал детализацию, сотрудник видит отсутствие данных; неизвестные суммы не подменяются нулями.

## 14 Возврат билета

### 14.1 Три независимых результата

**REF-01.** У операции хранятся отдельные состояния возврата перевозки у поставщика, отражения во внутреннем backend и денежного возврата. Дополнительно хранится результат сверки. Фраза «Билет возвращён» не означает, что деньги уже зачислены на карту.

| **Слой** | **Примеры состояний** | **Что подтверждает завершение** |
|----|----|----|
| Поставщик | Не запрошен, выполняется, подтверждён, отказ, результат неизвестен | Проверенный ответ или последующая проверка исходного возврата |
| Внутренний backend | Не оформлен, ждёт детализации, готов к подтверждению, оформлен, ошибка | Сохранённая внутренняя операция с компонентами и финансовым основанием |
| Деньги | Не требуется, не начат, отправлен, обрабатывается, подтверждён, отказ, неизвестно | Подтверждение ответственной платёжной системы либо проводка депозита |
| Сверка | Совпадает, неполные данные, расхождение, требует сотрудника | Сопоставленные билет, источник, операция, валюта и суммы |

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

### 14.2 Раздельные действия интерфейса

**REF-02.** В карточке сотрудника предусмотрены самостоятельные действия:

1\. «PDF/Печать» — чтение документа без изменения билета.

2\. «Возврат у поставщика» — операция через API источника с его правилами расчёта.

3\. «Оформить возврат у нас» — внутренний возврат, соответствующий назначению ManualReturnForced, с выбором режима заполнения и явным описанием денежного результата.

4\. «Проверить результат» — безопасное чтение исходной операции после ожидания или потери ответа.

Клиент сайта или мобильного приложения видит согласованный единый путь возврата и его фактические этапы. Внутренние команды и ручной ввод сумм клиенту недоступны. Сотрудник может выполнить два этапа отдельно; автоматическое продолжение второго этапа допускается только по явно утверждённой политике источника. В базовом сценарии внутренний этап подтверждает сотрудник.

### 14.3 Проверка до начала

**REF-03.** Сервер проверяет владельца, права, билет и его версию, источник, возможность возврата, исходную оплату, уже созданные операции, ограничения времени и принадлежность выбранных билетов. При групповом выборе показываются суммы и допустимость каждого билета. Транзакционная блокировка или уникальность не допускает две активные операции одного основания.

**REF-04.** Если источник умеет предварительный расчёт без изменения состояния, система получает его и показывает сумму, компоненты, срок актуальности и условия. Если источник возвращает точную сумму только при выполнении, интерфейс до подтверждения показывает условия и предупреждает о порядке определения суммы; необратимый вызов не маскируется под расчёт.

**REF-05.** Форма подтверждения содержит номер билета, пассажира в необходимом объёме, поездку и отправление, исходную стоимость, предлагаемый возврат или отсутствие точного расчёта, удержание, выбранные позиции, способ возврата денег и следующий этап. Подтверждение устаревшей формы отвергается либо требует повторного согласия при изменении условий.

### 14.4 Стандартный возврат через API и заполнение ManualReturnForced

**REF-06.** Для обычного возврата сотрудник запускает «Возврат у поставщика». Партнёр определяет положенное удержание по времени отправления и своим правилам, включая применимые 5%, 15% или 25% от тарифной стоимости. Сотрудник не вводит эти суммы вручную.

**REF-07.** Backend сохраняет внешний ID возврата, исходный ответ в защищённом хранилище, время запроса и подтверждения, валюту, общую сумму, известные компоненты, удержания и источник расчёта. Сохранённый ответ связывается с конкретными заказом и билетом, а не ищется по последнему возврату на экране.

**REF-08.** После подтверждения поставщика сотрудник нажимает «Оформить возврат у нас» и выбирает режим «По результату API». Форма автоматически подставляет суммы во все известные строки стоимости, скидку и итог. Рядом указывается «Источник: ответ партнёра», внешний ID и дата результата. Перед внутренним проведением выполняются проверка принадлежности ответа, валюты, уже возвращённых сумм и общей арифметики.

**REF-09.** Если партнёр вернул только общий итог либо неясную детализацию, неизвестные компоненты не заполняются нулями. Доступны сохранение ожидания, запрос детализации, проверка у партнёра и ручное уточнение с отдельным правом и основанием. Математическое распределение допускается только по заранее утверждённой карте конкретного источника. Самовольное разнесение остатка в «Агентские принципала» запрещено.

**REF-10.** Подтверждение внутреннего этапа создаёт одну операцию возврата и её финансовые строки. Для эквайринга формируется одна команда возврата, если её владелец — наша платформа и она ещё не выполнена. Для оплаты депозитом выполняется одно зачисление на исходный депозит. Если источник уже вернул деньги, сохраняются его подтверждение и режим «Деньги возвращает партнёр» без новой банковской команды.

**REF-11.** Повторное нажатие ManualReturnForced по тому же возврату возвращает существующий результат. Двойной клик, вторая вкладка и повтор после таймаута не создают новую проводку и второй возврат денег. Изменение сумм после проведения выполняется отдельной корректировкой с основанием, не редактированием прошлой записи.

### 14.5 Ручной внутренний возврат

**REF-12.** Сохраняется независимая операция ручного внутреннего возврата без вызова API поставщика. Режим «Ручной ввод» показывает все строки стоимости, исходные суммы, уже возвращённое и остаток. Допускаются полный, частичный и согласованный вынужденный возврат; сотрудник указывает причину и подтверждающее основание.

**REF-13.** В форме явно выбирается финансовое действие: инициировать возврат через нашу платёжную систему, вернуть на депозит либо отразить уже выполненный внешней стороной возврат с доказательством. Право только на учёт не даёт права отправить деньги. Ошибочный выбор блокируется по известному владельцу исходного платежа и состоянию операции.

**REF-14.** «Вернуть 100%» заполняет все возвратные компоненты из доступного оплаченного остатка, включая агентские принципала и субагента, багаж, вознаграждение, страховку и скидку. Итог равен допустимому невозвращённому нетто-остатку. Оператор может изменить разрешённые строки до подтверждения; итог пересчитывается. Если договор не допускает возврат компонента, его включение требует соответствующего основания и полномочия.

**REF-15.** Внутренний возврат не объявляет отмену перевозки у поставщика, если API не вызван и внешнее подтверждение отсутствует. Карточка показывает «У нас оформлен возврат; статус у поставщика не подтверждён» и задачу сверки. Если билет продолжает быть действительным у источника, это расхождение видно ответственному; клиент не получает ложное подтверждение внешней отмены.

### 14.6 Неизвестный результат и частичные операции

**REF-16.** До внешнего вызова намерение и ключ операции фиксируются в постоянной БД. При таймауте операция получает состояние «Результат уточняется». Автоматический повтор необратимой команды запрещён без подтверждённого безопасного механизма поставщика. «Проверить результат» обращается к исходной операции и не создаёт новую.

**REF-17.** Если поставщик подтвердил возврат, а банковский этап завершился ошибкой, билет остаётся возвращённым у поставщика, деньги — в соответствующем состоянии. Повторяется только разрешённый денежный этап с тем же основанием. Если банк подтвердил возврат, а локальная запись не завершилась, сверка восстанавливает запись без повторного перечисления.

**REF-18.** Для заказа с несколькими билетами возврат одного не меняет статусы и документы остальных. Для связанных багажных/страховых документов проверяется политика источника. Пропорциональное распределение общего платежа и границы возврата сохраняются по билетам. Массовая операция возвращает результаты по каждому элементу; недоступность одного не объявляет успех всех.

### 14.7 Даты, платежи и видимость результата

**REF-19.** Хранятся дата создания запроса, подтверждения у партнёра, внутреннего оформления, отправки денежного возврата, подтверждения платёжной системой и последней проверки. Если фактическое зачисление на карту неизвестно, система не подменяет его датой отправки в банк. Для каждой даты сохраняются источник и часовой пояс представления.

**REF-20.** Во вкладке «Платежи» возвраты расположены под исходными оплатами или в связанной с ними группе. Видны тип, статус, все составляющие цены, итог, признак ручного режима, источник расчёта, дата и время возврата, инициатор, внешние ID и остаток. Оплаты показываются положительными движениями, возвраты — отрицательными в финансовой истории; форма ввода использует положительные суммы с явным назначением.

**REF-21.** Ticket Status меняется на «Возвращён» после подтверждённого факта возврата перевозки, а внутренний и денежный этапы показываются рядом. При возврате только части финансовой суммы без отмены перевозки статус билета не подменяется. Клиент получает уведомление о принятии запроса и подтверждённом результате; повторное событие не рассылает несколько одинаковых уведомлений.

## 15 Биллинг, комиссии и сверка

### 15.1 Реестр операций

**BIL-01.** Раздельно учитываются попытки платежа, подтверждённые поступления, резервы, списания депозита, возвраты, комиссии, обязательства и корректировки. Для каждой строки сохраняются бренд, организация/агент при наличии, заказ, билет, валюта, компоненты, тип, состояние, автор/система, время и внешнее основание.

**BIL-02.** Журнал финансовых операций не редактируется через обычные формы и не очищается при скрытии заказа. Исправление выполняется компенсирующей записью со ссылкой на исходную операцию. Проверяется уникальность внешнего подтверждения и внутреннего бизнес-ключа; одинаковая транзакция из callback и сверки учитывается один раз.

**BIL-03.** Ставки комиссий имеют версию, область применения, базу, порядок скидок и округления, срок действия и автора изменения. Заказ сохраняет применённую версию. Новая ставка не пересчитывает историю. Возврат изменяет связанные начисления согласно договору и не создаёт произвольный доход на разнице неизвестных компонентов.

### 15.2 Сверка

Система сверяет собственные записи с отчётами или статусами поставщика и платёжного сервиса. Выделяются оплата без выпуска, выпуск без подтверждённой оплаты, расхождение суммы, неизвестный возврат, возврат у партнёра без внутреннего проведения, внутренний возврат без отмены перевозки, повтор внешнего события и неразнесённый платёж.

**BIL-04.** Для расхождения есть ответственный, приоритет, дата обнаружения, исходные идентификаторы, последнее состояние и доступное безопасное действие. Завершение требует подтверждения результата. Нажатие «Сверено» не инициирует банковскую операцию и не меняет факт поступления.

**BIL-05.** Суммы билетов, заказа, поступлений и возвратов можно проследить до исходных строк. Сводка показывает оплачено, возвращено, в обработке и остаток без смешения неподтверждённых попыток с деньгами. При разнице в одну копейку действует утверждённое правило округления, а не скрытая ручная правка.

### 15.3 Взаиморасчёты и отчётность

**BIL-06.** Внутренние реестры по агентам и перевозчикам формируются из подтверждённых продаж, возвратов, комиссий и корректировок. Они показывают обязательства, проведённые расчёты и остаток с расшифровкой. Работа с внутренним реестром не предоставляет перевозчику кабинет и не выполняет банковский перевод сама по себе.

**BIL-07.** Закрытый период и подписанный отчёт сохраняются как версия. Поздний возврат отражается корректировкой в предусмотренном периоде со ссылкой на исходную продажу. Исходные подписанные файлы и состав строк не перезаписываются.

## 16 Сайт, виджет и поддержка

### 16.1 Сайт ДонБилет

**WEB-01.** Сайт включает главную, поиск и оформление, страницы направлений, сведения о компании, контакты, справочную, информационные и юридические документы, новости по согласованной структуре, кабинет покупателя и вход в веб-кабинеты организаций и агентов. Контент редактируется уполномоченными сотрудниками без изменения исходного кода страницы.

**WEB-02.** Сохраняются необходимые старые URL либо настраиваются корректные перенаправления. Страницы направлений имеют согласованные заголовки, адреса, метаданные и правила индексации. ЛК, результаты частных поисков, документы и платёжные URL не попадают в поисковый индекс. Цена в SEO-разметке не выдаётся за доступную при отсутствии актуального предложения.

**WEB-03.** Покупка работает на компьютере и в браузере телефона. Формы имеют подписи, ошибки рядом с полем, клавиатурную навигацию и сохраняют допустимые введённые данные после временного сбоя. Браузерная мобильная версия сайта и мобильное приложение на iOS и Android используют общие серверные правила, но проверяются как разные каналы.

### 16.2 Виджет

**WID-01.** Виджет встраивает поиск отправления, прибытия и даты, выдачу и выбор предложения. Базовый режим переводит в оформление на сайте ДонБилет, сохраняя выбор, площадку и разрешённую атрибуцию. Полная покупка внутри виджета включается для согласованных площадок отдельной настройкой после проверки платёжных переходов и авторизации.

**WID-02.** Площадка имеет ID, разрешённые домены, оформление, начальное направление и режим продолжения. Код встраивания не содержит ключи поставщиков. Межоконные сообщения проверяют origin, тип и структуру; внешний сайт не может передать команду произвольного возврата или подменить цену.

**WID-03.** Проверяются блокировка сторонних cookie, повторное открытие, изменение размера, возврат из банка, недоступность API и пустая выдача. Сессия не передаётся небезопасно через постоянный URL. Источник привлечения не заменяет владельца заказа.

### 16.3 Обращения и существующие каналы

**SUP-01.** Клиент создаёт обращение из заказа, билета или общего раздела помощи. В обращение подставляются внутренние ссылки и необходимые реквизиты; клиент может исправить текст перед отправкой. Сотрудник видит контекст в пределах прав, историю, вложения, состояние и ответственного. Обращение не меняет билет и не запускает возврат автоматически.

**SUP-02.** Сотрудники могут отправлять согласованные сообщения через подключённые каналы с фиксацией доставки. Повторная доставка билета и выпуск разового пароля имеют отдельные ограничения и аудит. Сбой почты отображается как проблема доставки.

**SUP-03.** Доступ существующего MAX-канала и иных действующих клиентов поддерживается по согласованному контракту; они не подменяют мобильное приложение ДонБилет. Разработка нового мессенджера или нового ИИ-оператора не является обязательной частью платформы.

## 17 Требования к мобильному приложению

### 17.1 Количество продуктов и платформ

**MOB-01.** Передаётся один клиентский мобильный продукт «ДонБилет» в двух платформенных сборках: iOS и Android. Для каждой ОС настраиваются идентификатор приложения, иконка, экран запуска, карточка магазина, API, ссылки и push. Полный набор обязательных функций доступен на обеих платформах.

**MOB-02.** Основная роль — клиент/пассажир. Доступны поиск, покупка, ЛК, билеты, документы, возвраты и поддержка. Корпоративное администрирование и управление агентом остаются в веб-кабинетах.

**MOB-03.** Для общей кодовой базы допускается React Native/TypeScript с поддерживаемыми библиотеками и платформенными модулями. Выбор библиотеки подтверждается техническим решением до разработки. Сайт в WebView не считается выполненным мобильным приложением: поиск, заказ, билеты, профиль, навигация, локальные состояния и системные взаимодействия реализуются как мобильный продукт. Защищённая форма банка и отдельные партнёрские страницы могут открываться штатным браузерным способом.

Контрольная нижняя граница поддержки для оценки — iOS 17 и Android 10; окончательная матрица ОС и устройств утверждается до разработки по аудитории и требованиям выбранного стека. Целевой SDK и инструменты публикации соответствуют требованиям магазина на дату подачи. Отдельные приложения для iPad, часов и телевизора не разрабатываются; на планшете допустим корректно работающий телефонный интерфейс.

### 17.2 Карта экранов

**MOB-04.** Общий обязательный набор экранов реализуется в обоих брендах.

| **Экран** | **Содержание и обязательные состояния** |
|----|----|
| Первый запуск | Оформление бренда, понятный переход к поиску; вход не требуется для просмотра предложений |
| Поиск | Отправление, прибытие, дата, обмен направлениями, последние разрешённые запросы |
| Выбор города/станции | Подсказки, уточнение региона, отсутствие данных, ошибка и повтор |
| Календарь | Дата и доступные серверные минимальные цены; неизвестная цена обозначается отдельно |
| Результаты | Карточки рейсов, фильтры, сортировки, частичная выдача, пустое состояние |
| Детали рейса | Станции, время с поясами, перевозчик, маршрут, багаж, условия и место посадки |
| Места | Реальная схема и легенда при наличии; продажа без выбора места при соответствующем источнике |
| Пассажиры | Ввод, выбор сохранённого пассажира, категории и документы, валидация |
| Контакты | Email, телефон, явная проверка перед оплатой, пояснение гостевого заказа |
| Проверка заказа | Все пассажиры и услуги, полная сумма, скидка, условия и согласия |
| Оплата | Переход к разрешённому способу, ожидание результата, отмена и ошибка |
| Результат оформления | Подтверждённые билеты, частичный выпуск, проверка и восстановление |
| Заказы | Предстоящие поездки и история, фильтры, пагинация, сохранение при временном сбое |
| Заказ | Состав, статусы оплаты/выпуска, документы и обращения |
| Билет | Пассажир, номер, маршрут, место, действительность, PDF и возврат |
| Документ | Просмотр, скачивание, системная передача и пометка свежести локальной копии |
| Возврат | Выбор билета, условия и расчёт при наличии, отдельное подтверждение, последующая проверка |
| Вход и регистрация | Согласованные способы, подтверждение контакта, неверный/истёкший код, восстановление |
| Пароль | Смена, обязательная установка после разового входа, ошибки и истечение сессии |
| Профиль | Контакты и их подтверждение, управление сессиями, запрос удаления аккаунта |
| Пассажиры | Создание, изменение и удаление сохранённых карточек без изменения истории билетов |
| Уведомления | Полученные разрешённые сообщения, состояние заказа, настройки категорий |
| Поддержка | Контакты, справочная, обращение из заказа/билета, переписка и вложения |
| О приложении | Бренд, версия, документы, условия, политика данных и разрешённые контакты |

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

### 17.3 Оплата, внешние переходы и потеря процесса

**MOB-05.** Для каждого бренда настраиваются проверенные Universal Links/App Links и отдельная обработка разрешённых внешних URL. Возврат из банка связывается с конкретной платёжной попыткой; параметры ссылки не подтверждают оплату. Приложение запрашивает состояние backend.

**MOB-06.** Проверяются переход в браузер и банковское приложение, отказ пользователя, отсутствие нужного приложения, повторное открытие ссылки, неверный бренд, закрытие процесса ОС, перезагрузка телефона и истечение резерва во время оплаты. После восстановления приложение показывает фактический результат и не предлагает повторно платить уже подтверждённый заказ.

**MOB-07.** Несколько одновременно открытых заказов не смешивают пассажиров, оплату и результаты. Отмена платёжного окна не отменяет уже принятый банком платёж. Если подтверждение задержалось, клиент видит «Проверяем оплату» и может безопасно обновить статус или обратиться в поддержку.

### 17.4 Билеты без сети

**MOB-08.** После успешного получения клиент может сохранить PDF на устройстве и открыть его без сети. Приложение показывает время последней проверки и сообщает, что без сети текущий статус не подтверждён. Новый билет, возврат, исправление и оплата без сервера не выполняются.

**MOB-09.** При следующем соединении статусы обновляются. Если билет возвращён на другом устройстве или через поддержку, локальная карточка теряет признак действительного билета; доступная приложению копия помечается либо удаляется по политике. Уже экспортированный пользователем файл технически не отзывается; серверный статус и сообщение в приложении остаются определяющими.

**MOB-10.** Локальные данные ограничиваются необходимым объёмом. Токены и закрытые ключи хранятся штатными защищёнными средствами iOS/Android; паспортные данные не пишутся в открытые настройки. Выход очищает сессионные и доступные приложению закрытые данные. Системный экспорт PDF требует явного действия клиента и предупреждения о персональных сведениях в документе.

### 17.5 Уведомления и разрешения

**MOB-11.** Push-уведомления сообщают об оформлении, существенном изменении поездки при наличии источника, возврате и ответе поддержки. Токен устройства связан с пользователем, брендом и разрешением; смена аккаунта и выход прекращают доставку закрытого контекста прежнему пользователю. Недействительные токены отключаются.

**MOB-12.** На экране блокировки не показываются паспорт и полная платёжная детализация. Открытие уведомления проверяет сессию и принадлежность объекта. Маркетинговые сообщения выделены в отдельную добровольную категорию. Отказ от push не блокирует покупку и получение билета через приложение.

**MOB-13.** Геолокация необязательна: станции можно выбрать вручную. Камера, файлы и уведомления запрашиваются только перед требующей их функцией. Приложение не требует контакты телефона, постоянное местоположение или микрофон для обычной покупки. Биометрия при согласованном включении защищает локальный доступ к сессии и не заменяет серверную проверку владельца.

### 17.6 Интерфейс и эксплуатация

**MOB-14.** Основной язык — русский. Поддерживаются системный возврат Android, жесты iOS, безопасные области, открытая клавиатура, масштаб текста, озвучиваемые подписи и достаточная различимость элементов. Форма не прячет ошибку под клавиатурой; кнопки необратимых действий имеют ясные подписи.

**MOB-15.** Загружаемые сведения имеют состояния загрузки, пустоты, ошибки и повтора. Временная потеря сети сохраняет разрешённый черновик без открытых платёжных секретов. Долгая операция показывает ожидание; двойное нажатие блокируется локально и независимо защищено на сервере.

**MOB-16.** Минимальная поддерживаемая версия клиента задаётся серверной конфигурацией с понятным сообщением. Обязательное обновление не лишает клиента доступа к уже купленному билету: предусматривается безопасное получение через разрешённый веб-канал или поддержку. Сборки iOS и Android могут обновляться независимо.

### 17.7 Публикация приложений

**MOB-17.** Для iOS подготавливаются подпись, TestFlight, карточка App Store и материалы проверки; для Android — подписанный AAB для Google Play и тестовый APK либо иной разрешённый тестовый формат. Дополнительный магазин Android, включая RuStore, включается отдельным решением. Заказчик предоставляет и сохраняет владение аккаунтами разработчика, идентификаторами, ключами и доступами.

**MOB-18.** Продажа перевозки использует согласованный эквайринг. Для таких физических услуг Apple предусматривает способы оплаты вне In-App Purchase, а Google Play исключает транспортные услуги из обязательного Play Billing. Это правило не определяет доступность конкретного банка, Apple Pay или Google Pay. Основание: [Apple App Review Guidelines, 3.1.3(e)](https://developer.apple.com/app-store/review/guidelines/#other-purchase-methods) и [Google Play Payments](https://support.google.com/googleplay/android-developer/answer/9858738?hl=en), проверено 21.10.2026.

**MOB-19.** При создании аккаунта iOS-приложение предоставляет запуск его удаления внутри приложения; Android-приложение — путь удаления внутри и веб-страницу запроса. Политика данных и декларации магазинов отражают фактические SDK, сбор, передачу и сроки хранения. Основание: [Apple, удаление аккаунта](https://developer.apple.com/support/offering-account-deletion-in-your-app/) и [Google Play, требования удаления](https://support.google.com/googleplay/android-developer/answer/13327111?hl=en), проверено 21.10.2026.

**MOB-20.** Для ДонБилета предоставляются позиционирование, тексты, скриншоты, каталог, условия и карточки выбранных магазинов. Готовность сборок и получение допуска к публикации фиксируются отдельно; проверка магазина является внешним этапом.

**MOB-21.** Конфигурации мобильных сред не содержат рабочих секретов. Тестовая среда не использует реальные персональные или платёжные данные.

## 18 Мобильное приложение ДонБилет

### 18.1 ДонБилет

**DB-01.** ДонБилет является пассажирским приложением действующего бренда и использует его каталог, условия продажи, поддержку, документы, платёжную конфигурацию и собственную историю. Пользователь получает доступ к принадлежащим ему покупкам старого приложения после предусмотренного подтверждения, без повторной покупки и ручного ввода всех старых билетов.

**DB-02.** Поддерживаются необходимые ссылки из писем и сайта, обработка старых номеров заказов и билетов и совместимость согласованных клиентских контрактов. Совместимость обеспечивается целевым backend без обязательной зависимости от Java API.

## 19 Веб-кабинет юридического лица и ИП

### 19.1 Регистрация и договор

**ORG-01.** Кабинет запускается для новых корпоративных регистраций. История старых B2B-операций сохраняется при миграции, но действующие организации не становятся автоматически активными участниками нового договорного процесса. Перенос конкретных аккаунтов и остатков требует отдельного реестра и сверки.

**ORG-02.** Зарегистрированный пользователь подаёт реквизиты организации/ИП, ИНН, применимые регистрационные и банковские сведения, адреса и контакты. Первый суперпользователь получает полномочия после проверки представителя. Совпадение ИНН не открывает существующий кабинет.

**ORG-03.** Состояния подключения: черновик, проверка, требуется исправление, оформление договора, активна, приостановлена, закрыта. Статус договора ведётся отдельно. До активации доступны профиль, замечания, договор и поддержка; новые покупки и расходные коды закрыты.

**ORG-04.** При ЭДО формируются утверждённые документы, выполняются отправка, получение статусов и сохранение подписанного комплекта. Активация требует проверки организации и обеих подписей. Если сохраняется бумажный процесс, покупки открываются после полного обмена оригиналами. Скан не заменяет оригиналы и не является условием подписания через ЭДО.

### 19.2 Участники и покупки

**ORG-05.** Приглашается существующий пользователь с подтверждённым email. Приглашение не создаёт новую учётную запись. Получатель принимает его после входа именно в приглашённый профиль. До принятия, после отзыва и при входе другим пользователем доступ к организации закрыт.

**ORG-06.** Суперпользователь управляет разрешёнными участниками, ролями и ограничениями. Обычный участник видит свои и дополнительно разрешённые заказы; доступ ко всем финансам не выдаётся автоматически. Отзыв участия не удаляет личную учётную запись и её личные покупки.

**ORG-07.** Автобусные билеты покупаются самостоятельно: поиск, место, пассажир, полная стоимость, лимит, необходимое согласование, резерв депозита, выпуск. Оплата не выполняется при недостатке доступных средств или отсутствии обязательного одобрения. При изменении цены проверки повторяются.

**ORG-08.** Для авиа, ЖД и отеля создаётся заявка поддержке с параметрами услуги, пассажирами/гостями и пожеланиями. Поддержка направляет предложение с ценой и сроком; клиент подтверждает его. До платного оформления проверяются депозит, лимиты и согласования. Документы прикрепляются к заказу, списание выполняется один раз. Отказ освобождает резерв, неизвестный результат направляется на проверку.

### 19.3 Разделы и документы

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

**ORG-09.** Предоставляются счета на пополнение, документы заказов, реестр расходов и сверка за период. Подписанные файлы не перезаписываются. Приостановка запрещает новые расходы, сохраняя разрешённое обслуживание истории и уже выпущенных билетов. Возврат билета зачисляется на исходный депозит по подтверждённой операции, если иной способ не закреплён договором.

## 20 Веб-кабинет агента

### 20.1 Подключение и договорная модель

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

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

**AGT-03.** Участники и суперпользователь агента имеют доступ только к своему агентскому аккаунту и допустимым операциям. Суперпользователь не изменяет ставки договора и не получает полномочия администратора ДонБилет. Сотрудники поддержки и финансов получают отдельные полномочия.

### 20.2 Продажа и обслуживание

**AGT-04.** В оформлении показываются рейс, место, пассажир, полная цена покупателю, расход депозита и предусмотренные договором сборы/вознаграждение в разрешённом объёме. Сервер проверяет договор, права, средства, лимит и согласование. Фиксируются агент, автор продажи, бренд, канал и применённая версия условий.

**AGT-05.** Разрешённое обслуживание включает документы, возврат и доступное поставщику переоформление либо поддержку. Перерасчёт вознаграждения связан с исходной продажей. Возврат средств агенту и расчёт агента с пассажиром различаются; интерфейс не утверждает, что пассажир получил деньги, если подтверждено только зачисление на депозит агента.

**AGT-06.** Постоянный справочник внешних клиентов агента, применение Альфа-Пэй для ИП и обработка авиа/ЖД/отелей включаются только в согласованном составе агентского договора. Данные чужого агента недоступны через поиск пассажира, документ и выгрузку.

### 20.3 Вознаграждение и отчёт агента

**AGT-07.** Условия вознаграждения версионируются с датой действия, базой, ставкой и округлением. Начисление не превращается в доступный депозит до предусмотренного договором события. Возврат корректирует вознаграждение по той же договорной модели.

**AGT-08.** Отчёт агента формируется по утверждённой форме приложения к договору. Согласуются составитель, получатель, период, поля, формулы и подписание. Доступны просмотр, расшифровка, PDF и XLSX, согласование и сохранение итогового экземпляра. Пополнение депозита не учитывается как продажа.

**AGT-09.** Подписанный отчёт сохраняется неизменно. Поздние возвраты отражаются корректировочным документом или следующим периодом по договору. Передача в ЭДО включается в согласованный процесс. Агентский кабинет является веб-функцией партнёрских продаж и не включает операционную систему кассовых смен.

## 21 Депозит, лимиты, согласования и коды

### 21.1 Депозит и подтверждение поступлений

**DEP-01.** Доступные средства равны подтверждённому остатку минус действующие резервы. Ожидаемые поступления и начисленное, но не зачисленное вознаграждение не расходуются. Каждая операция имеет тип, сумму, валюту, основание, автора и время.

**DEP-02.** Формируется PDF-счёт «На оплату депозита» с номером, датой, суммой, сторонами, банковскими реквизитами и назначением. Счёт и загруженное платёжное поручение не увеличивают остаток. Поступление подтверждает уполномоченный сотрудник либо проверенная банковская интеграция. Частичная оплата, переплата и одно поступление по нескольким основаниям отображаются явно.

**DEP-03.** Пополнение через Альфа-Пэй для ИП при согласованной применимости подтверждается сервером платёжного сервиса. Страница успеха не зачисляет деньги. Одинаковое банковское подтверждение учитывается один раз. Пополнение депозита и оплата билета являются разными операциями.

**DEP-04.** До необратимого оформления атомарно резервируются деньги и расход личного лимита. При остатке 5 000 ₽ два одновременных заказа по 4 000 ₽ не могут оба получить расход. Подтверждённый выпуск превращает резерв в списание, подтверждённая неудача освобождает его. При неизвестном результате резерв сохраняется до проверки.

### 21.2 Лимиты и одобрение

**DEP-05.** Поддерживаются денежные и билетные лимиты на согласованные периоды и услуги. В расчёте учитываются расходы и активные резервы. Значение «не задано», сочетание ограничений и восстановление квоты при возврате задаются явно; отрицательный остаток не разрешается скрыто.

**DEP-06.** При превышении личного лимита доступен запрос разового согласования. Одобрение относится к конкретным составу, сумме и сроку заказа, не изменяет общий лимит и не разрешает расход сверх депозита. Отказ содержит причину. Изменение существенной цены, пассажиров или услуги требует нового согласования. Ожидание одобрения не гарантирует место и тариф.

### 21.3 Коды оплаты

**DEP-07.** Код связан с организацией/агентом, автором, назначением, услугой, сроком, лимитом расхода, числом применений и получателем при необходимости. Код оплаты, промокод скидки, реферальный код и код заказа имеют разные типы; одна строка не используется вместо всех назначений.

**DEP-08.** Создание кода само по себе не списывает деньги. При применении проверяются срок, состояние, назначение, допустимый получатель, договор, лимиты, доступные средства и число использований. Параллельное применение одноразового кода допускает только один расход. Код не раскрывает баланс компании и чужие заказы.

**DEP-09.** Место применения кода и необходимость входа утверждаются до интерфейса. Отзыв, истечение, повтор и чужой контекст имеют понятные ошибки. Если код опубликован случайно, его можно отозвать, не удаляя историю. Неиспользованный депозит возвращается отдельным процессом по договору и не смешивается с возвратом билета.

## 22 Подключаемые расширения исходного предложения

### 22.1 Порядок включения

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

| **Модуль** | **Подробные требования при включении** | **Что требуется до оценки** |
|----|----|----|
| Лояльность | Бонусный баланс, начисления и списания, срок действия, кэшбэк, промокоды, рефералы; отмена начисления и восстановление списания при возврате | Правила, ставки, база, применимость к брендам, ограничения и примеры |
| Динамическая комиссия | Версионируемые правила по каналу, направлению, времени и достоверной заполненности; предварительная полная цена, ограничение и журнал результата | Источник заполненности, минимумы/максимумы, приоритет правил и договорная допустимость |
| Сопоставление рейсов | Кандидаты дублей из разных API, объяснение признаков, подтверждение спорного решения, сохранение вариантов и цены каждого источника | Обучающие/контрольные примеры, допустимые ошибки и ответственность сотрудника |
| Поездки с пересадкой | Сегменты, минимальное время стыковки, общая и раздельные цены, резервы, частичный выпуск, компенсация и возврат по сегментам | Поставщики, ответственность за стыковку и правила общей оплаты |
| ГДС и внешние API-клиенты | Регистрация технического клиента, scopes, квоты, ключи, договор, единый каталог, sandbox, версии и учёт использования | Потребители, модель тарификации, SLA и разрешённые данные |
| Партнёрские отели | Поиск/предложение, отдельный документ, условия отмены, дата заезда по поездке, понятный переход к партнёру | Поставщик, договор, финансовая ответственность, возможность API |
| Общая оплата билета и отеля | Раздельные позиции, распределение платежа, выпуск обеих услуг, частичная неудача и независимые возвраты | Подтверждённая техническая и договорная возможность общего платежа |
| Самостоятельные авиа и ЖД | Отдельные тарифные, документные и возвратные правила, прямые адаптеры и специализированные функции | Контракты поставщиков и самостоятельное предметное ТЗ |

### 22.2 Ограничения финансовой модели расширений

**EXT-01.** Бонусный кошелёк отделён от денежного депозита и банковских платежей. Бонусы не становятся свободно выводимыми деньгами по одному изменению названия поля. Показываются происхождение, срок, доступность и движение; двойное начисление от повторного события запрещено.

**EXT-02.** ИИ может предлагать сопоставление, но не менять оплаченного поставщика, пассажира, билет или денежные обязательства. Пересадка не продаётся как единая гарантированная перевозка без подтверждённых правил ответственности. Недоступная услуга отеля не включается в общую сумму заказа.

## 23 Администрирование, контент, аналитика и аудит

### 23.1 Рабочий интерфейс сотрудников

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

**ADM-09.** Управление доступом включает назначение допустимых ролей, блокировку, отзыв участия и просмотр разрешений. Нельзя назначить полномочие за пределами политики назначающего. Защищаются доступ последнего управляющего аккаунта и привилегированные служебные учётные записи. Настройки источника не раскрывают сохранённый секрет в обычной форме.

**ADM-10.** Контент поддерживает черновик, публикацию и снятие с публикации, заголовок, текст, допустимые изображения, бренд и даты. Юридический документ имеет версию и период действия; заказ хранит согласованную версию условий. Удаление медиа, уже связанного с опубликованным материалом, обрабатывается с проверкой ссылок.

### 23.2 Аналитика и выгрузки

**RPT-01.** Базовые показатели: число заказов и билетов, подтверждённые оплаты, выпуски, возвраты перевозки, денежные возвраты, продажи нетто, удержания, комиссии, проблемы оплаты/выпуска и незавершённые возвраты. У каждого показателя есть определение, единица, время события и правила включения статусов.

**RPT-02.** Доступны фильтры периода, бренда, канала, поставщика, перевозчика, организации/агента и состояния. Отчёт по дате продажи и отчёт по дате возврата не смешиваются. Часовой пояс и свежесть указываются. Ноль, отсутствие данных и ошибка различаются.

**RPT-03.** Финансовый реестр показывает все ценовые компоненты и даёт переход до заказа, билета, платежа и возврата. Экран и XLSX используют одинаковые параметры и права. Подготовка большого отчёта выполняется фоновым заданием с состоянием и сроком доступности; чужое задание нельзя скачать заменой ID.

### 23.3 Аудит

**AUD-01.** Журнал фиксирует событие, автора или внешнюю систему, время, бренд, объект, безопасный контекст запроса, результат и основание. Для значимых изменений сохраняются необходимые значения до/после без секретов и избыточных паспортных реквизитов.

Обязательный охват: доступ к закрытым данным, привязка/перепривязка заказа, восстановление пароля, роли, договоры, лимиты и одобрения, пополнения и корректировки, возврат через API, ManualReturnForced, повторная сверка, ручные суммы, изменения справочников и интеграций, выгрузки, ошибки и фоновые действия.

**AUD-02.** Журнал имеет поиск по периоду, автору, объекту, действию и результату. Редактирование и удаление событий через интерфейс запрещены. Пароли, OTP, секреты API, CVV и полные номера документов не записываются. Срок хранения и доступ определяются утверждённой политикой отдельно от времени хранения обычных технических логов.

## 24 Взаимодействие частей системы

### 24.1 Единые правила работы

**API-01.** Сайт, мобильное приложение, виджет и рабочие кабинеты используют общие правила поиска, оформления, оплаты и обслуживания заказа. Служебные операции доступны только сотрудникам с соответствующими правами.

**API-02.** Номера заказов, билетов и платежей сохраняются без искажений. Стоимость и валюта совпадают во всех интерфейсах. Дата и время поездки отображаются с учётом часового пояса отправления.

**API-03.** При ошибке пользователь получает понятную причину и доступное дальнейшее действие: исправить данные, войти, обновить цену, повторить поиск, дождаться результата или обратиться в поддержку. Сообщение об ошибке не раскрывает чужие заказы и персональные данные.

**API-04.** Повторное нажатие, повтор запроса после потери связи и одновременная работа сотрудников не создают повторную оплату, выпуск билета, возврат или зачисление депозита. Пользователь видит состояние исходной операции.

**API-05.** Просмотр заказа и проверка результата не меняют его состояние. Если другой участник уже изменил заказ, система показывает актуальные сведения до подтверждения следующего действия.

### 24.2 Покупка и обслуживание

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

Сотруднику доступны поиск заказов, билетов и пользователей, просмотр истории и карточек, привязка покупки к личному кабинету, выдача разового пароля, получение PDF, расчёт допустимого возврата, возврат у поставщика, внутреннее оформление по ответу поставщика или с ручным вводом, проверка результата, корректировка и просмотр оплат. Действия выполняются в пределах полномочий и сохраняются в истории.

**API-06.** Действующие согласованные клиентские подключения продолжают работать после перехода на новый backend без обязательной зависимости от старого Java API.

### 24.3 Состояния и уведомления

**API-07.** История отражает создание и изменение заказа, подтверждение оплаты, выпуск билета, привязку гостевой покупки, возврат у поставщика, внутреннее оформление возврата, возврат денег и финансовое расхождение. Для действия сохраняются объект, время и связь с исходной операцией.

**API-08.** Уведомления соответствуют фактическому состоянию заказа. Повторная доставка сообщения не повторяет операцию, а запоздавшее сообщение не заменяет актуальное состояние устаревшим. Письмо или push не считаются подтверждением оплаты либо возврата денег.

## 25 Нефункциональные требования

### 25.1 Безопасность и персональные данные

**NFR-01.** Все внешние соединения используют HTTPS. Секреты, пароли и токены хранятся вне репозитория и публичных сборок. Публичные мобильные настройки не содержат секреты поставщика. Входящие служебные заголовки очищаются и формируются доверенным gateway; внутренние сервисы не доверяют произвольному внешнему заголовку роли.

**NFR-02.** Ограничиваются частота входа/OTP, поиска частных покупок, выпуска временного пароля, получения документов и команд возврата. Погашение кода, счётчик попыток и захват права на операцию выполняются атомарно. Защита включает проверку входа, размеров файлов и запросов, допустимых origin и URL внешних переходов.

**NFR-03.** Определяются оператор данных, цели обработки, согласия, сроки хранения по категориям, доступ сотрудников, порядок удаления и восстановления. Конкретные юридические сроки и тексты утверждает заказчик с ответственным специалистом. Техническое удаление профиля не стирает обязательные финансовые основания; необязательные данные не сохраняются бессрочно по умолчанию.

### 25.2 Производительность и нагрузка

Приведённые значения являются предварительными целевыми параметрами. Они уточняются с учётом объёма базы, числа источников, одновременных пользователей, рабочих устройств и сети.

| **Показатель** | **Контрольное значение и границы измерения** |
|----|----|
| Набор данных | 1 млн заказов, 2 млн билетов и связанные операции; обезличенный или синтетический набор |
| Нагрузка | 100 активных клиентских сессий; суммарно 20 запросов/с чтения и 2 команды/с на согласованном профиле |
| Внутреннее чтение | p95 не более 2 с для ЛК, карточки и точного индексированного поиска без ожидания внешнего API |
| Поиск рейсов | Первый частичный результат до 5 с при ответившем источнике; общий бюджет ожидания до 15 с |
| PDF | Начало выдачи сохранённого файла до 3 с; генерация/ожидание поставщика измеряются отдельно |
| Возврат | Принятие команды с ID до 3 с; завершение зависит от источника и банка, ожидание отображается |
| Мобильный запуск | Интерактивный первый экран до 3 с на согласованных устройствах среднего класса без ожидания выдачи API |
| Сохранённый PDF | Открытие доступного локального файла до 2 с на тех же устройствах |

**NFR-04.** При превышении лимита система даёт управляемую ошибку и не увеличивает бесконтрольно параллелизм поставщика. Недоступность Redis или поискового индекса не уничтожает постоянные данные. Деградация допускает безопасное чтение и понятное ограничение функций.

### 25.3 Доступность, резервирование и наблюдаемость

**NFR-05.** Предлагаемый ориентир доступности собственных клиентских API — 99,5% за календарный месяц, плановые окна учитываются по договору. Ошибка банка не означает подтверждённый успех собственной операции и отражается отдельной метрикой. Времена сторонних сервисов измеряются отдельно.

**NFR-06.** Для согласования предлагаются RPO не более 15 минут для основной БД и RTO не более 4 часов восстановления платформы. Схема резервирования должна учитывать финансовую сверку после восстановления; восстановление старой копии не разрешает повторить уже исполненные банковские команды. Проверяется восстановление БД и файлов в отдельной среде.

**NFR-07.** Резервные копии защищаются, хранятся отдельно от жизненного цикла контейнера и проверяются пробным восстановлением. Интервал и срок хранения согласуются с требуемым RPO и объёмом. При обновлении тома и базы не удаляются. Доступы production и теста различаются.

**NFR-08.** Метрики включают задержки и ошибки API/источников, состояние очередей, возраст ожидающей оплаты/выпуска/возврата, недоставленные документы, конфликты привязки и расхождения сумм. Есть health/readiness, корреляция запросов и фоновых задач, алерты ответственным и понятная инструкция разбора.

### 25.4 Совместимость и сопровождаемость

**NFR-09.** Веб-интерфейсы работают в поддерживаемых Chrome, Edge и Safari; мобильное приложение — на iOS и Android в пределах установленной матрицы версий, включая минимальную ОС. Номер версии приложения видим в поддержке. Версии пакетов и образы фиксируются lock-файлами, а обновление зависимостей проходит регрессию.

**NFR-10.** Код, конфигурации и миграции хранятся в репозитории. Есть отдельные среды разработки, проверки и production, воспроизводимый запуск, проверка сборки, правила работы с секретами и журнал релиза. Демоданные не попадают к покупателю как реальные рейсы и билеты.

## 26 Эксплуатационная документация и конфигурация

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

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

## 27 Решения заказчика

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

| ID | Вопрос | Решение заказчика | Рабочая граница | Когда требуется |
|---|---|---|---|---|
| Р-01 | В первой версии подключаем новых поставщиков билетов? | Не заполнено | Прямые адаптеры только по подтверждённому реестру | До оценки интеграций |
| Р-08 | Меняем действующие правила возврата сборов? | Не заполнено | 5/15/25% не являются универсальным правилом; действует паспорт источника | До настройки расчётов |
| Р-09 | Оставляем текущий банк для оплаты билетов? | Не заполнено | Клиентский переход не подтверждает деньги; финансовые основания разделены | До платёжной интеграции |
| Р-14 | Можно ли компаниям работать по бумажному договору? | Не заполнено | Неактивный договор не разрешает покупки | До договорных кабинетов |
| Р-15 | Кто платит за билет при продаже через агента? | Не заполнено | Продажа, депозит и вознаграждение учитываются отдельно | До расчётной части агента |
| Р-23 | Дополнительные функции включаем в первый этап? | Не заполнено | Включаются в состав работ отдельным решением | До оценки соответствующего модуля |

### 27.1 Исходные данные для реализации

Финансовая карта формируется на основании обезличенных примеров обычной продажи, скидки, нескольких билетов, багажа, страховки, полного и частичного возврата, удержаний 5/15/25%, ответа API и последующего ManualReturnForced. Для каждого примера необходимы исходные поля, смысл сумм, ожидаемый итог и ответственный за деньги.

Правила привязки проверяются на обезличенных примерах гостевого заказа с правильной почтой, ошибочной почтой, дублем аккаунта, уже установленным другим владельцем и покупкой на нескольких пассажиров. Реальные персональные реквизиты в рабочее ТЗ не включаются.