Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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

Типовые примеры использования:

  • Автоотмена броней в тестовом договоре, чтобы клиент не создавал брони для Тестового Теста (сработает везде, кроме "Сирены", так как есть ограничение функционала: нет возможности использовать терминальные команды, возможно вносить только ремарки с типом 3.): Соответственно, если в Amadeus команда указывается целиком, то в "Сирене" – только текст ремарки.

  • Открыть видимость брони для International SOS

  • Внести текстовую ремарку

  • Задать отправку маршрутных квитанций для всех пассажиров по указанному адресу
    (команда для Amadeus – "ITR-EML-AMADEUSMO@SUPERAGENCY.RU"): 

Где:

  • ITR (Itinerary Receipt) – оформление маршрут-квитанции.
    В ITR содержится информация об авиаперелете, агентстве или авиакомпании, форме оплаты и общих ремарках, а также о маршруте и стоимости авиабилета на русском и английском языках; пассажиры, путешествующие с электронными билетами, должны иметь при себе Itinerary Receipt (маршрутную квитанцию), подтверждающую данные о поездке;

  • EML (Email) – способ отправки;

  • AMADEUSMO@SUPERAGENCY.RU – адрес получателя.

Аргументы разделяются знаком дефиса

Добавление авиакоманды.

ВНИМАНИЕ! Ввод авиакоманд осуществляется только заглавными буквами!

Справа в выпадающих списках необходимо последовательно выбрать:

  • нужную операцию:

ВНИМАНИЕ! Для операции “Выписка” возможно два режима отправки команды: ДО непосредственной выписки, и ПОСЛЕ непосредственной выписки билета.

По умолчанию авиакоманда отправляется в бронирование ДО выписки. В случае, если авиакоманда должна быть добавлена ПОСЛЕ выписки авиабилета, текст ремарки необходимо дополнить текстом --FINAL (Например ремарка на отправку маршрут-квитанции будет выглядеть так: ITR-EML-AMADEUSMO@SUPERAGENCY.RU--FINAL

  • GDS:

  • Ввести текст команды:

 

Управляющие ремарки, которые позволяют системе определить некоторые параметры брони.

Вводятся в таком виде:

  • Sabre
    Для Sabre это публичные ремарки следующего вида:

  • FAMILY-EF (код семейства тарифа, который виден в маске расчета) - нужен для того, чтобы при пересоздании масок сохранить нужные условия тарифа;

  • VC-SU (валидирующий перевозчик) - нужен для того, чтобы по нему подтянуть сборы;

  • 3D-ROSTELECOM (код 3D-договора) - чтобы применить правильный 3D-договор;

  • FARE-Y/C - тариф "Эконом" или "Бизнес" - нужен, чтобы бронирование не пересчиталось в эконом.

Переменные для Amadeus и Sirena

Текст ремарки может быть как статическим, так и динамическим (значение переменной, зависящее от параметров заказа). В случае использования динамических ремарок в бронь передается значение переменной для данного заказа. Реализованы следующие переменные и для Amadeus, и для Сирены:

  • @ORDERNUM - номер заказа Corteos (может использоваться только при тикетинге

  • @ORDERDATE - дата создания заказа (брони) в формате 2013-05-30 (может использоваться и при букинге и при тикетинге)

  • @ORDERTIME - время создания заказа (брони) в формате 23:46 (может использоваться и при букинге и при тикетинге)

  • @FEE - размер сервисного сбора клиента в рублях в формате 500.00 (может использоваться только при тикетинге)

  • @MINFARE - минимальный найденный в процессе создания заказа тариф на заданное направление/даты в рублях в формате 10000.00 (может использоваться только при тикетинге)

  • @MAXFARE - максимальный найденный в процессе создания заказа тариф на заданное направление/даты в рублях в формате 10000.00 (может использоваться только при тикетинге)

  • @CREATOR - ФИО пользователя, создавшего заказ (может использоваться только при тикетинге)

  • @AUTHORIZER - ФИО пользователя, авторизовавшего заказ (может использоваться только при тикетинге)

  • @INN - ИНН юридического лица, выбранного в качестве плательщика в заказе (может использоваться только при тикетинге)

  • @KPP - КПП юридического лица, выбранного в качестве плательщика в заказе (может использоваться только при тикетинге)

  • @CODES - значения бюджетных кодов в заказе в формате Dictionary_name=Code, например: Cost Center=Sochi2014 (может использоваться только при тикетинге). Если кодов в заказе несколько, то каждый код передается в бронь отдельной командой в соответствии с настройками договора, например, если в заказе два кода, Cost Center=Sochi2014 и Reason=last date travel, а в договоре задан формат ремарки для Amadeus вида RM*@CODES, то в бронь добаввяться 2 строчки: RM*COST CENTER=SOCHI2014 и RM*REASON=LAST DATE TRAVEL

  • @ST - номер (id в базе Corteos) сервис-тима, к которому относится заказ (может использоваться только при тикетинге)

  • YY:<авиакоманда> - формат для внесения команды для конкретной авиакомпании (в т.ч ремарки по 3Д договорам, корпоративные бонусные карты и т.д.), где: “YY” - код соответствующей авиакомпании, “:” - разделитель, “<текст команды>” - собственно авиакоманда в формате выбранной GDS

Команда для юр. лица

  • #ORG<ORG ID>текст ремарки - формат для ввода команды для конкретного юридического лица  (может использоваться только при тикетинге):

Пример:

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

По умолчанию, если не ввести номер организации, то команда будет применяться под все брони договора в данной ГДС, а если ввести - то только для брони, где плательщиком числится данная организация.

  • @CODE#<ID справочника кода> - формат для передачи в бронь в особом виде кода из справочника (структурного или системного, может использоваться только при тикетинге)

В сейбре для МОМа (мидфоис сейбровский) нужно передавать всякие значения типа костов. Чтобы МОМ понял, что это именно оно, они должны иметь очень специфичный вид. Этот вид в своей форме содержит некую постоянную часть, и  переменную величину (например, значение коста). Клиент вносит ремарку. Статическую часть пишет так, как она должна быть. А то место, где должно быть динамическое значение заменяет ремаркой @CODE#<ID справочника кодов>:

5.X*CODE NAME*@CODE#123456 даст ремарку типа .X*CODE NAME*ZNACHENIE

Пример:

допустим, мы хотим внести в бронь информацию о минимальном тарифе, чтобы наш мидофис мог её анализировать из маски билета. Используем системы Амадеус и Сирена:

Детали:

В амадеусе мы выполняем терминальный запрос, поэтому тут указываем полностью всю команду: RM MINFARE=@MINFARE, при выписке билета произойдет замена @MINFARE на сумму из нашей БД и ремарка в брони будет такая: RM MINFARE=10000.0

В сирене мы не указываем операнд команды, поэтому просто пишем аналогичный текст ремарки: MINFARE=@MINFARE

Для каждой системы бронирования команды надо заводить отдельно.

Важно! Логикой работы различных ГДС предусмотрено внесение команд на разных этапах создания бронирования.

В некоторых случаях, когда внесение осуществляется после непосредственного создания брони (например для GDS Sabre) важно учитывать терминальные особенности в отношении вносимых команд.

Так например, если команда требует обязательной подписи агента в GDS, то она также должна быть добавлена дополнительной командой и в договор, это необходимо для корректного сохранения ремарок.

  • No labels