На форму попадаем с поиска и предварительного бронирования. К моменту попадания на форму имеем сохраненный в базе офер и OfferId
-
Пользователь меняет, или не меняет (тогда остается 0) extra markup
-
Жмет Add
- Отправляется POST запрос на репрайс оффера п. 4.1 markup в запросе
- Форма отображает обновленный прайсинг
-
Видит обновленный прайсинг на форме
-
В базе ни чего не сохраняется, Pnr не создается
-
Пользователь заполняет данные формы
-
Жмет book
-
Выполняется валидация запроса и всякие проверки
- В случае ошибки
- Возвращаем форму с ошибками
- Ошибки показываются на форме бронировния
- Возвращаемся к п. 1.2
- В случае ошибки
-
Создается бронь в амадеусе получаем PNR
-
Делаем полноценный репрайс с полученным PNR
- При ошибках
- Мы еще не сохранили ордер в базе, а PNR уже получили
- При ошибках
-
Создаем ордер в базе с обновленным прайсингом. Ордер помечается как "невидимый/временный" и еще не виден в админке, но все данные по нему уже есть в базе
-
Проверяем, изменилась ли цена
agency net price
после репрайса с PNR
-
Помечаем созданный в п. 1.2 ордер как "видимый"
-
Редиректим на форму выписки п.3 с пометкой "без проверки FXX"
К этому моменту у нас есть OrderId от временного ордера со всеми данными и PNR
-
Сохраняем ошибку формы куда нибудь (в редис?) по паре (OrderId, PnrLocator)
-
Создаем задачу в таскере на отмену брони по таймауту п. 5.1
-
Редиректим пользователя на форму подтверждения п.2
Форма подтверждения берет из урла OrderId
и PnrLocator
, которые
закодированы в сегменте урла
host#confirm_booking/OrderId/PnrLocator
-
Пользователь переходит по урлу формы
-
Фронт достает из формы OrderId и PnrLocator
-
Фронт делает GET запрос на получение формы по ордеру п.4.3
- Бэк берет ошибку бронирования из редиса (если есть) сохраненную в п. 1.2.2
-
Фронт отображает данные по оферу и пасажирам
На форме подтверждения у нас уже есть ордер, следовательно мы можем делать полноценный репрайс ордера
-
Пользователь меняет agency extra markup
-
Жмет Add
-
Отправляется запрос на репрайс ордера п. 4.2
-
На форме обновляется прайсинг
-
Пользователь проверяет прайсинг и соглашается с ним. Выбирает форму оплаты
-
Жмет Confirm
-
Отправляется запрос на подтверждение ордера п. 4.5
-
Делается полноценный репрайс ордера с запросом в CM
-
Проверяется, изменилась ли
gency net price
в сравнении с той, что показана пользователю
-
Обновляем во временном ордере прайсинг
-
Делаем пометку в ордере чтобы он стал видимым в админке
-
Отменяем задачу на снос ордера п. 5.1 созданную в п. 1.2.2, либо надо придумать другой механизм защиты от автосноса брони
-
Редиректим пользователя на форму выписки п.3 с пометкой "без проверки FXX"
-
Возвращаем форму с обновленным прайсингом и фронт отображает его
-
Переходим к п.2.2
host#ticketing/Checking/OrderId/PnrLocator
Где
-
Checking
может принимать два значения:-
no_check
означает, что форма не должна проверять FXX и получать данные из запроса формы ордера п. 4.3 -
check_price
форма должна получать данные из запроса формы ордера с проверкой FXX п. 4.4
-
-
OrderId
- ид ордера -
PnrLocator
- pnr -
Пользователь попадает на форму выписки
-
Фронт берет из урла параметры
Checking
,OrderId
иPnrLocator
и делает запрос на получение формы и отображает данные
Полностью аналогично репрайсу ордера на форме подтверждения бронирования п. 2.1
-
Пользователь заполняет форму и/или соглашается с прайсингом
-
Жмет ticket
-
Выполняется запрос на выписку п. 4.7
-
Делаются проверки лимитов и валидация запроса
-
Делаем полноценный репрайс с проверкой FXX
-
Проверяем что цена
agency net price
не отличается от показанной пользователю
-
Сохраняем в базе обновленный прайсинг некоторым образом (либо добавляем прайсинг к существующим продуктам, либо пересоздаем продукты, а старые переводим в другое состояние).
-
Списываются деньги с acquiring если надо, создаются платежки в базе
-
Добавляем ремарки и добавляем в очередь на выписку, добавляем форму оплаты в амадеусе
-
Запускаем задачу на загрузку билетов п. 5.2
-
Возвращаем пользователю APIItinerary
-
Мапим ошибки из эквайринга в человекочитаемые ошибки формы и возвращаем их
-
В базе ни чего не сохраняем
-
Пользователь видит ошибку оплаты на форме выписки
-
Переходим к п. 3.2
-
Формируем ответ с обновленной ценой
-
Фронт отображает обновленный прайсинг и ошибки
-
Переходим к п. 3.2
Выполняет упрощенный репрйас оффера без запроса в CM и калькулятор.
POST /api/v1/reprice/offer/OfferId
Где OfferId
- ид оффера
Тело запроса:
{ "extra_markup": 10 }
extra_markup
- agency extra markup в долларах
Тело ответа: booking offer с обновленным прайсингом
Выполняет репрайс ордера.
POST /api/v1/reprice/order/OrderId/PnrLocator
Где OrderId
и PnrLocator
- ид ордера и pnr соответственно.
Тело запроса
{ "extra_markup": 10 }
extra_markup
- agency extra markup в долларах
Тело ответа: booking offer с обновленным прайсингом
Запрос нужен для получения формы подтверждения бронирования и формы тикетирования, если мы попали на нее сразу с формы бронирования. Запрос ни чего не меняет в базе и не делает запросов в амадеус, только возвращает данные ордера (оффер с прайсингом + пасажиры)
GET /api/v1/order/form/no_check/OrderId/PnrLocator
Запрос нужен для формы выписки когда мы попадаем на нее с админки. То же самое, что п.4.3, но выполняет проверку изменения цены в FXX, если цена изменилась делает новый прайсинг и возвращает его с ошибкой, поясняющей что цена изменилась. Новый прайсинг в базе не сохраняется, только показывается пользователю. Запрос в базе ни чего не меняет.
GET /api/v1/order/form/check_price/OrderId/PnrLocator
host/api/v1/confirm_booking/OrderId/PnrLocator
Запрос на подтверждение изменившейся после бронирования цены. Делается с формы подтверждения п. 2.2, работа запроса описана там же
При изменении цены на бронировании, когда пользователь не сгласился с ценой, но и бронь не отменил, а просто закрыл вкладку, у нас остается временный ордер с бронью, которую надо отменить.
Задача запускается на бронировании при изменении цены перед показом формы подтверждения.
Задача должна проверять, что ордер находится в состоянии "временный" и сносить бронь если это так. Плюс закрывать ордер.
И надо еще придумать механизм, который не позволит задаче сносить бронь в случае, если пользователь играется с ценой, или вошел в цикл изменения цены (когда цена постоянно меняется, пользователь тупит, потом соглашается, а цена снова меняется). Или не придумывать и тупо сносить по таймауту если ордер не подтвержден в течении X минут.