валидирующий перевозчик что это значит
О процедуре электронного билетооформления. Часть 2
Примечание: В зависимости от обстоятельств, валидирующий перевозчик, маркетинг- перевозчик и фактический перевозчик могут быть одной и той же авиакомпанией (например, если вся перевозка выполняется одной авиакомпанией, которая оформила билет) или тремя разными авиакомпаниями.
Файл электронного билета
По сути, контроль означает, что авиакомпания получает в свое распоряжение электронный вид полетного купона электронного билета как основание для дальнейших действий, например, перевозки пассажира или возврата денег пассажиру за неиспользованный билет. Это то же самое, что получить в свое физическое распоряжение полетные купоны бумажного билета, то есть получить право на соответствующие действия, например, на выполнение перевозки пассажира или на возврат ему денег за неосуществленную перевозку.
Право передавать контроль над купоном другой авиакомпании принадлежит валидирую- щему перевозчику. Принимая такое решение, он должен исходить из таких критериев, как наличие двустороннего соглашения по электронному билетооформлению, присутствие или отсутствие в билете разрешительных/ограничительных записей и т.д. Единовременно контроль над купоном может принадлежать только одной авиакомпании. Если контроль был ранее передан Авиакомпании А, то валидирующий перевозчик не может передать контроль Авиакомпании В, предварительно не отозвав его у Авиакомпании А. Такой порядок установлен во избежание многократного использования конкретного билета или купона.
Статус полетного купона электронного билета
Каждый полетный купон электронного билета, хранящийся в ETS валидирующего перевозчика, имеет соответствующий код статуса купона. По этому коду можно определить состояние купона на каждый данный момент. После оформления электронного билета всем его купонам присваивается статус «Открыт для использования» (« Open for Use »).
По мере использования купонов для перевозки или для других операций (например, для возврата денег пассажиру) код статуса купонов в ETS обновляется с целью фиксации произведенных операций.
Что такое единый авиабилет, или Когда не нужна виза при транзите
Почему мы задали вопрос о едином билете?
Потому что от этого зависит, берет ли на себя авиакомпания полную ответственность за транзит вас и вашего багажа через пересадочные аэропорты, или вам придется организовывать стыковку самостоятельно. От этого зависит, нужны ли вам визы для транзита через аэропорты пересадок. От этого зависит, нужно ли вам выходить из транзитной зоны, чтобы забрать свой багаж и зарегистрировать себя и багаж на следующий рейс.
«Единый билет» — понятие условное. В общих чертах — это один билет на весь маршрут следования, включая все полетные сегменты. А полетных сегментов может быть несколько.
1. Основная отличительная черта — единый билет имеет один номер/код бронирования в системе бронирования («код бронирования / booking reference / reservation code / confirmation / PRN» и т.д.), который указывается в так называемой маршрутной квитанции.
Единый билет всегда имеет только один код бронирования в системе бронирования на весь маршрут следования — как правило, 6 букв/цифр.
Это не код заказа сайта-агрегатора.
Это не код бронирования авиакомпании, хотя они могут и совпадать. Если авиакомпаний несколько, могут быть указаны несколько кодов бронирования авиакомпаний, для каждой авиакомпании свой. При этом код бронирования в системе бронирования все равно должен быть один.
Если авиакомпания не использует международную систему бронирования, она укажет свой собственный код бронирования, в котором может быть больше, чем 6 знаков.
Это не номер электронного билета. Если билет туда и обратно, в маршрутной квитанции будут два номера электронного билета — номер билета туда и номер билета обратно.
Если единый билет авиакомпания выписывает в бумажном виде, он будет на одном бланке авиакомпании.
2. Покупка билета одной транзакцией не означает, что он будет единым. Точно так же покупка одного билета на весь маршрут на сайте-агрегаторе или на сайте агента не гарантирует, что он будет единым. Агрегаторы могут компоновать перелеты под ваш маршрут, стыкуя предложения разных авиакомпаний и совершенно не заботясь о том, чтобы соблюсти визовые требования транзитных стран. При этом вы даже можете купить билет одной транзакцией, но фактически это будет несколько отдельных билетов.
3. Единые билеты бывают разные.
Самый простой пример — все полетные сегменты выполняет одна авиакомпания. В ее обязанность входит доставить вас и ваш багаж из начальной точки маршрута в конечную, включая транзитные аэропорты. Она же сама и перегрузит ваш багаж, и вы получите его в конечной точке маршрута. В случае задержки первого рейса и вашего опоздания на последующие авиакомпания обязана доставить вас в конечный пункт другими рейсами (своими или компаний-партнеров). Некоторые авиакомпании, например, Turkish Airlines или Emirates, в случае длительной стыковки (более 6-8 часов) в транзитном аэропорту (как правило, это их «домашний» аэропорт) могут организовать вам бесплатную экскурсию по городу или предоставить отель.
Покупка двух отдельных билетов на рейсы одной и той же авиакомпании не означает, что вы купили единый билет. Авиакомпания может пойти вам на встречу, сама перегрузить ваш багаж в транзитном аэропорту и даже обеспечить ваш безвизовый транзит через этот аэропорт, но это будет скорее исключением. Правилом будет отказать вам в посадке на рейс, если транзит через стыковочный аэропорт требует визы, а у вас ее нет, и выдать вам багаж после выполнения своих обязательств по первому полетному сегменту, а не перегружать его на свой следующий рейс. Авиакомпания сама принимает решение, как с вами поступить, и об этом решении вы узнаете в последний момент при регистрации на рейс, что крайне рискованно с точки зрения планирования запасных вариантов.
Если единый билет продан авиакомпанией, работающей по код-шеринговому соглашению, ее обязательства ничем не отличаются от описанных выше. Разница только в том, что в таком билете есть валидирующий перевозчик — как правило, это авиакомпания, выполняющая более продолжительную часть маршрута; она же и получает ваши деньги и выписывает вам билет. В случае непредвиденных обстоятельств все претензии нужно предъявлять валидирующему перевозчику. При этом название фактического (оперирующего) перевозчика вы можете даже не знать, поскольку его может не быть в выписанном вам билете.
Если авиакомпании работают по интерлайн-соглашению, которое предполагает взаимное признание авиабилетов и возможность продавать перевозки по маршрутам другой стороны, то и в этом случае билет будет единым, если в перевозке участвуют обе авиакомпании. Все перечисленные выше обязательства по отношению к вам и вашему багажу сохраняются, однако, в отдельных случаях следует просить зарегистрировать багаж до конечного пункта. Но если на одном из полетных сегментов произошло ЧП, вы должны предъявить претензию к фактическому перевозчику на этом сегменте. В билетах такого типа указываются все задействованные перевозчики.
4. Посадочные талоны. Получение посадочных талонов на первый и все последующие полетные сегменты при регистрации на рейс в первом аэропорту вылета — отличительная черта единого билета.
В некоторых случаях все же придется получить посадочные на последующие сегменты в транзитных аэропортах. Так может быть, если компании-перевозчики по вашему маршруту действуют по интерлайн-соглашению, или компания не готова в данный момент выдать вам посадочный на следующий рейс, или произошло изменение в расписании, или еще ряд случаев. Это не должно вас смущать, поскольку посадочный на следующий рейс вы все равно получите.
5. В случае, если ваш маршрут предполагает транзитные стыковки в странах / аэропортах, имеющих визовые требования по отношению к вашему гражданству, единый билет обеспечит вам безвизовый транзит при таких стыковках. Исключение составляют:
6. Частным случаем является отсутствие в некоторых аэропортах транзитной зоны или ее работа только в дневное время (на ночь аэропорт закрывается). Чаще всего авиакомпании не продают единый билет с вылетом из страны, гражданам которой требуется виза для транзита через такие аэропорты.
Терминология
Ниже приведен справочник основных терминов, используемых при работе с Corteos Avia API.
Список терминов
Описание терминов
— система взаиморасчетов между субъектами воздушного транспорта, основанная на системе продаж перевозок на нейтральном бланке авиабилета.
Суть системы в том, что нет необходимости в заключении двухсторонних договоров, а также ведения отдельной отчетности и перечисления выручки между агентством по продаже перевозок и каждым авиаперевозчиком.
Агентство, вступив в BSP, получает возможность продавать перевозки всех авиакомпаний, входящих в BSP, с другой стороны, авиаперевозчик, вступив в BSP, автоматически дает доступ к продаже своих рейсов всем агентствам-членам BSP. При этом всю работу по взаиморасчетам между участниками берет на себя BSP, т.е. агенты отчитываются в целом за все проданные билеты и перечисляют выручку в BSP, которое, в свою очередь, распределяет ее по авиаперевозчикам.
Объединения авиаперевозчиков и агентов по продаже BSP имеют региональный характер, т.е. в каждой стране (иногда в группе стран) – свое BSP.
В России действует BSP Russia. Из-за ограничений российского законодательства отношения между агентами и авиаперевозчиками в BSP Russia осложняются тем, что для доступа к продаже авиабилетов того или иного перевозчика необходимо заключение двухстороннего договора между агентством и авиаперевозчиком, поэтому набор доступных валидирующих перевозчиков у каждого агентства свой. Однако взаиморасчеты и отчетность производятся по общепринятой схеме. Все продажи в системе BSP проводятся на нейтральном стоке (бланках) BSP.
Для того, чтобы определить принадлежность авиабилета конкретному авиаперевозчику, применяется понятие валидирующий перевозчик.
в этом поле авиабилета указываются различные ограничения (restrictions) на перевозку по данному билету, а также возможность «передачи» (endorsement) пассажира другому перевозчику в случае, если пассажир по каким-либо причинам не сможет улететь на рейсе, указанном в билете.
PNR создаются во всех ГДС (система бронирования). PNR необходимо создавать в любом случае: и когда нужно просто закрепить (забронировать) за пассажиром места на рейсе, и когда пассажир уже готов купить билет, все равно создание брони является обязательным этапом, предшествующим оформлению билета (ticketing).
Некоторые авиаперевозчики также требуют ввод дат рождения пассажиров, номеров и типов документов, удостоверяющих личность, и срока их действия.
По ряду направлений необходим ввод информации о визе.
На детей дата рождения обязательна.
Номер PNR в системе Амадеус 6-значный, состоит из латинских букв и цифр.
Номер PNR в системе Сирена 6-значный, состоит из кириллических букв и цифр.
Забро��ированные в PNR рейсы называются авиасегментами (air segment). После того, как PNR создано, на каждый авиасегмент должен прийти из инвенторной системы а/к номер PNR (record locator), присвоенный самой авиакомпанией. Только тогда можно быть уверенным, что места успешно забронированы. Обычно record locator а/к приходит мгновенно после создания PNR, но бывают задержки.
Валидирующий
перевозчик
(Validating carrier) — перевозчик (авиакомпания), чьим кодом подтверждается перевозка, и которому, согласно отчету, поступят денежные средства от продажи авиаперевозки. Валидирующий перевозчик не всегда совпадает с перевозчиком, реально осуществляющим перевозку – оперирующий перевозчик (operating carrier), или же с перевозчиком, под чьим кодом рейс представлен в ГДС (система бронирования) – маркетинговый перевозчик (marketing carrier). Виды улучшений
типа тарифа
Авиакомпании часто объединяют тарифы в специальные группы, называемые семействами тарифов.
Обычно, можно провести улучшение выбранной категории (upgrade) для того, чтобы получить какие-то преимущества, например, бесплатный багаж.
— соглашение между двумя авиаперевозчиками о взаимном признании перевозочной документации, т.е. когда рейсы одного перевозчика могут продаваться под валидатором другого перевозчика (валидирующий перевозчик). Агентства, продающие перевозку, используют интерлайн-соглашения для оформления авиабилетов на рейсы тех перевозчиков, которые не входят в региональное BSP, с которыми у них нет двухстороннего договора в рамках BSP, а также для оформления единым авиабилетом маршрутов, отдельные части которых выполняются разными авиаперевозчиками. Сведения о наличии интерлайн-соглашений доступны в ГДС.
Пример: агентство хочет продать авиабилет на рейс AA (American Airlines) внутри США. Агентство и перевозчик являются членами BSP Russia, но у агентства нет договора с AA, поэтому агентство не может использовать в качестве валидирующего перевозчика AA. Но зато у агентства есть двухсторонний договор с Аэрофлотом, который имеет интерлайн-соглашение с АА. Поэтому агентство продает билет на рейс АА с валидатором SU (Аэрофлот).
Еще пример: агентство хочет продать билет Москва – Париж – Москва, причем туда рейс Аэрофлота (SU), а обратно – Air France (AF). Агентство может выписать 2 отдельных билета: Москва – Париж на SU, отвалидировав этот билет SU, и Париж – Москва на AF, отвалидировав этот билет AF. Но тарифы в одну сторону всегда дороже, чем один билет туда-обратно. Поэтому агентство, пользуясь наличием интерлайн-соглашения между AF и SU, оформляет 1 билет Москва – Париж – Москва, валидируя его SU.
Ряд авиаперевозчиков применяют ограничения по своим интерлайн-соглашениям, например, разрешают оформление билетов по интерлайну только при условии наличия в маршруте билета.
Исходящие
статусы
сегментов
— классами (кодами) бронирования называются специальные однобуквенные коды, каждый из которых соответствует одному или нескольким уровням тарифа на авиаперевозку. Бронирование места в ГДС всегда происходит по определенному классу бронирования, определяя тем самым стоимость авиабилета. Распределение мест на рейсах по классам бронирования нужно авиаперевозчикам для управления доходами от продажи рейсов. Стоимость билета в разных классах бронирования может существенно (в разы) отличаться. При этом неважно, в каком классе бронирования был продан авиабилет, уровень сервиса для пассажира определяется только классом (подклассом) обслуживания.
В российской терминологии (ГДС Сирена) классы бронирования могут называться подклассами бронирования или тарифными подклассами.
Обычно есть устоявшиеся классы бронирования для каждого класса обслуживания, например:
Классы
обслуживания
(Classes of service)
— в международной практике называются уровни сервиса, которые получают пассажиры воздушного судна на борту.
В российской терминологии (ГДС Сирена) классы обслуживания иногда называют классами бронирования (что не совсем верно, и порой вносит путаницу, т.к. в международной практике классами бронирования называют совсем другое).
Внутри класса обслуживания некоторые перевозчики практикуют разбиение на «подклассы обслуживания», например, разбивание эконом-класса на премиум эконом и обычный эконом, предоставляя при этом пассажирам разных «подклассов обслуживания» различный уровень сервиса.
Каждому классу или подклассу обслуживания на рейсе соответствует один или несколько классов бронирования.
Классы
обслуживания
(кодировка
в системе Corteos)
— служебный строковый параметр, который добавляется во все запросы, связанные с бронированием авиаперелетов. Предназначен для корректной аутентификации агентства и выдается службой поддержки Corteos после обращения по электронной почте.
— международная система кодировки географических объектов, авиаперевозчиков и типов воздушных судов (ВС).
В кодах IATA используются только латинские буквы и цифры.
Города – каждый город, имеющий хотя бы один аэропорт, имеет уникальный трехбуквенный код.
Например, MOW – Москва, LON – Лондон, MAD – Мадрид, LED – Санкт-Петербург.
Например, коды аэропортов Москвы(MOW) таковы: SVO – Шереметьево, DME – Домодедово, VKO – Внуково.
В Санкт-Петербурге код аэропорта Пулково (LED) совпадает с кодом города – LED.
Например, SU – Аэрофлот, S7 – Сибирь, 4U – Germanwings.
Типы воздушных судов (ВС) – каждый тип ВС имеет уникальный трехсимвольный код, который может включать буквы и цифры.
Например, 737 –Boeing 737 (all series), 732 – Boeing 737-200, TU5 – Ту-154, CRJ – Canadair Jet.
Некоторые объекты (региональные российские перевозчики, региональные российские аэропорты и т.п.) могут не иметь кода IATA, тогда они имеют только код ЦРТ.
— перевозчик, заключивший на тех или иных коммерческих/технологических условиях договор с оперативным перевозчиком о праве продажи мест на рейсе оперативного перевозчика под своим кодом (code-sharing).
Неготариф
(Конфиденциальный
тариф)
— признак того, что в данном предложении используется конфиденциальный тариф (него) авиакомпании, открытый только для избранных агентств. bool GDSConnector. Structures. Offer. IsNegoFare – используется только в Амадеусе.
Нормы
провоза
багажа
Условные обозначения основаны на двух системах норм провоза багажа: весовой и системы количества мест.
— т.к. не любую пару городов связывает прямое воздушное сообщение (прямые рейсы), то не всегда один участок перелета можно преодолеть одним рейсом. Иногда требуется лететь последовательно двумя или тремя рейсами отдельными прямыми рейсами, чтобы из пункта отправления попасть в пункт назначения. Эти рейсы называют стыковочными, а те пункты (города), где осуществляются пересадки с одного рейса на другой – пунктами пересадки (стыковки), разумеется, пункт прилета первого рейса является пунктом вылета следующего. Стыковочные рейсы образуются независимыми друг от друга прямыми рейсами, в общем случае это рейсы разных авиакомпаний, каждый из них имеет свой номер, свой тип самолета и прочие характеристики. Стыковки бывают как в рамках одного аэропорта, так и с переездом в другой аэропорт того же города.
Стыковки строятся автоматически системами ГДС по специальным алгоритмам. При этом проверяется так называемое MCT (minimum connecting time, минимальное время стыковки) – время, требующееся для осуществления пересадки с рейса на рейс. В ГДС достаточно указать дату, начальный и конечный пункт участка перелета – и она подберет стыковки.
Однако перелет стыковочными рейсами используется не только в том случае, если между начальным и конечным пунктом нет прямых рейсов. Довольно часто перелет стыковочными рейсами стоит дешевле прямого рейса, а иногда он получается удобнее по времени вылета/прилета и т.п.
Не нужно путать стыковочные (пересадочные) пункты с пунктами отправления/назначения сегментов перелета. В терминах нашей системы участки (сегменты) задаются пользователем, и на этапе задания маршрута он не должен задумываться о том, какие пересадки пассажиру потребуется совершить, чтобы попасть из пункта отправления каждого участка в пункт назначения.
— это устоявшееся понятие, обозначающее 1 рейс.
– это пронумерованные бланки строгой отчетности (БСО), на которых оформляются авиабилеты. Раньше сток представлял собой бумажные БСО, в настоящее время сток — это электронные бланки (фактически номера бланков).
Сток может принадлежать какому-то авиаперевозчику или быть нейтральным (ТКП система, зарубежные BSP), т.е. принадлежать некоей системе расчетов (клиринга) между авиаперевозчиками.
Для оформления авиабилетов агентство использует доступные ему стоки, то есть электронные бланки тех владельцев (авиаперевозчиков или систем расчета), с которыми агентство имеет соответствующие договоры. Каждый владелец стока выделяет агентству доступный дапазон номеров бланков, которые агентство использует (расходует) для оформления билетов. Если агентство оформило авиабилет с использование номера БСО какого-то владельца стока, то этот владелец стока называется валидирующим перевозчиком для данного авиабилета.
Таймлимит
(Time limit)
— крайний срок удержания мест в PNR (Бронь, бронирование (PNR)) без оформления билета. Указывается в виде даты (Амадеус) или в виде даты и времени (Сирена).
— ТКП (Транспортная клиринговая палата) – система взаиморасчетов субъектов рынка авиаперевозок, действующая в России и некоторых странах СНГ, основанная на продаже перевозок на нейтральном бланке ТКП. Суть системы та же, что и в BSP. В отличие от BSP Russia, субъекты системы не нуждаются в наличии двухсторонних контрактов между агентством и авиаперевозчиком. В системе ТКП отсутствует понятие валидирующего перевозчика.
Финансовый профиль — термин системы Corteos, обозначающий набор условий для применения сервисных сборов и скидок корпоративного клиента (или группы клиентов) при работе как с API, так и с web-интерфейсом Corteos. Каждое агентство самостоятельно создает и редактирует финансовые профили для своих корпоративных клиентов через web-интерфейс системы Corteos, это могут делать только пользователи агентства с административными правами. Для работы с API используется идентификатор финансового профиля по Авиабилетам, который можно найти в общем списке финансовых профилей в соответствующем разделе системы. Экран наличия
мест на рейсе
— процесс бронирования мест (создание PNR) обычно начинается с просмотра экрана наличия мест на участках перелета на выбранную дату. Экран наличия мест представляет собой список прямых (если они есть) и стыковочных рейсов с указанием наличия мест в классах бронирования по всем классам обслуживания, времени отправления/прибытия по каждому рейсу, типу воздушного судна, общему времени в пути.
— это электронная запись в базе данных авиакомпании, содержащая данные о пассажире, маршруте следования, примененном тарифе и подтверждающая сделку по договору авиаперевозки.
Электронному билету присваивается уникальный номер бланка из стока валидирующего перевозчика, состоящий из 13 цифр, первые 3 из которых – цифровой код валидирующего перевозчика.
В качестве подтверждения того, что электронный билет оформлен, пассажиру высылается в электронном виде или выдается в распечатанном виде на руки маршрут-квитанция (itinerary receipt), которая содержит полную информацию о маршруте, ФИО пассажира, классе обслуживания, дополнительных услугах и т.п.
Обратная сторона авиабилета. Как Туту.ру помогает подобрать оптимальный тариф
Весной 2014 года были приняты поправки к Воздушному кодексу РФ, позволяющие авиакомпаниям заключать договор на перевозку без возврата платы за проезд в случае расторжения договора. Иными словами, на рынке авиаперевозок появились невозвратные тарифы. До этих изменений авиакомпании могли лишь удерживать штраф в размере не более 25% от стоимости билета, если пассажир сдавал билет позднее, чем за сутки до вылета. Новые поправки позволили авиакомпаниям предложить пассажирам более дешевые, но невозвратные билеты.
В это же время появились бюджетные «безбагажные тарифы». На самом деле, полностью безбагажными их назвать нельзя: по закону РФ, пассажир имеет право провезти с собой до 10 кг личных вещей. И здесь есть интересный момент: закон не регулирует, каким образом пассажир перевозит эти 10 кг — в салоне самолета или в багажном отсеке. Как известно, в салон нельзя брать множество вещей: например, жидкость более 100 мл, маникюрные ножницы, пилочку и некоторые гаджеты. Даже если тариф включает провоз багажа, каждая авиакомпания сама определяет максимальный вес и размеры багажа и ручной клади на одного пассажира.
Пассажиры путались в тарифах, возникало много вопросов, связанных с провозом багажа и доплатой перевеса. В этой статье я хочу рассказать, что и как мы сделали, чтобы облегчить пользователям Tutu.ru поиск наиболее подходящих авиабилетов среди десятков доступных вариантов.
Цены на билеты многих авиакомпаний не выглядели привлекательно на фоне экономического кризиса, отнюдь не дешевеющих тарифов на поезда и появления «Победы», которая действительно сбила цены на многих направлениях. Например, до появления лоукостера я летал в Чебоксары и обратно за 8–10 тысяч рублей, а сейчас полет обойдется в 3–6 тысяч.
Осенью 2015 года авиакомпании с целью снижения цен начали активно внедрять безбагажные и невозвратные тарифы. Для нас было очень важно предоставить пользователю возможность самостоятельно выбирать интересующие его опции. Люди сталкивались с тем, что в аэропорту требуют доплатить за багаж, или что билет нельзя сдать или обменять. Мы хотели дать человеку возможность выбрать именно то, что ему нужно, максимально облегчив и ускорив поиск билетов. С другой стороны, и сами авиакомпании выдвинули своим агентам, в том числе и Туту.ру, требование показывать информацию об особенностях тарифа уже на этапе поиска.
К тому моменту мы уже показывали клиентам, можно ли сдать или обменять билеты. С багажом все оказалось сложнее.
На вкус и цвет GDS’a нет
Данные по багажу мы получаем от систем бронирования (GDS — Global Distribution System), что накладывает некоторые ограничения. Во-первых, мы работаем с несколькими GDS, а также с агрегаторами GDS, и это требует поддержки решения для каждой из систем.
Во-вторых, исторически сложились два типа авиакомпаний. Одни ограничивают максимальный багаж по весу, а другие — по числу мест. Например, «Аэрофлот» дает ограничение по числу мест, и из GDS нам поступают малоинформативные данные о багаже: «1 piece» без информации о максимальном весе.
И, наконец, самое главное. Информация об ограничениях на багаж приходит из GDS подчас тогда, когда клиент уже выбрал конкретное предложение и приступил к оформлению заказа. Мы же стремились дать клиенту возможность сравнить предложения еще на этапе выбора. Посылать уточняющие запросы к GDS, пока клиент выбирает, было бы слишком накладно и по деньгам, и по времени: на одном направлении в день могут быть десятки и сотни предложений.
Конечно, GDS не стоят на месте, и в новых версиях API интересующей нас информации приходит больше, а для некоторых GDS она доступна уже на этапе поиска. Но в большей степени это относится к крупным авиакомпаниям, которые перешли на систему брендированных тарифов (о ней речь пойдет позже). Мы используем эту информацию, но всё же этого недостаточно, чтобы сделать действительно удобный сервис. GDS не всегда следят за тем, чтобы авиакомпании вносили информацию о багаже, и уж тем более не несут ответственности, если правила изменились, а информацию в GDS ещё не внесли, или если при внесении была допущена ошибка. Поэтому для многих небольших и региональных авиакомпаний этой информации в GDS нет. Данные об ограничениях на ручную кладь не вносит практически ни одна авиакомпания.
Есть и совсем сложные случаи, например, авиакомпания Оренбуржье заносит в GDS информацию, что разрешен багаж весом не более 10 кг. При этом рейсы выполняются на самолётах Ан-2, у которых нет багажного отделения, поэтому взять запрещенные к провозу в салоне вещи не получится. В данном случае мы показываем пользователям, что на рейсе нет багажа, но разрешена ручная кладь весом до 10кг.
С возможностью обмена и возврата на тот момент все было немного лучше, но лишь немного. Информация о возможности возврата и обмена билета (как и о багаже) нередко была доступна только по выбранному предложению, а не на этапе поиска. Причем данные из GDS приходили нам не в виде удобного для обработки XML, а в виде «простыни» текста, в которой единственное форматирование — разное количество пробелов в начале строки.
Мы уже знали, как определять по таким текстам условия обмена и возврата и даже до какого срока они возможны: у одних компаний до окончания регистрации, у других — не позднее, чем за 48 часов до вылета и т.д. Для этого мы сохраняли тексты тарифных правил по всем заказам, которые сделали наши пользователи. Затем простая, но автоматическая система находила в сохраненных текстах меняющиеся от заказа к заказу части, вроде суммы штрафа за возврат, и вырезала их. От полученного текста с пропусками вычислялся некоторый хеш, и затем исходные, т.е. без пропусков, правила группировались по этому хешу. Практически каждый заказ после оплаты просматривался операторами нашего контакт-центра. Операторы читали конкретный текст правил, определяли в нем условия обмена и возврата, и ставили в соответствии с хешем этого текста удобоваримое описание Например, «Возврат возможен не более чем за 24 часа до вылета». Впоследствии, когда очередной клиент делал заказ, и для текста тарифных правил вычислялся хеш, мы уже могли показать понятные условия обмена и возврата. Но на этапе поиска это решение опять-таки не подходило: информация приходила уже на этапе оформления заказа.
Новая система тарифов
Разработку нового решения мы начали с простейшей системы, умеющей показывать ограничения только для авиакомпаний S7 и Уральские Авиалинии. Они первыми в России перешли на новую систему тарифов. Как работала старая система: допустим, авиакомпания открывает продажу на рейс, который будет выполнять самолет на 300 человек. Эти 300 мест разбиваются на 10-20 так называемых классов бронирования (не путать с классами обслуживания: Эконом, Бизнес, Первый и т.д.). Каждый класс фактически определяет услуги, предлагаемые авиакомпанией: норму провоза багажа, включенное питание, возможность выбора места, а также обмена и возврата билета и т.д. В зависимости от набора услуг меняется и стоимость тарифов в этом классе. Причем на разных рейсах внутри одного класса бронирования набор услуг может отличаться.
Новая система тарифных семейств (еще их называют брендированными тарифами) проще. Классы бронирования остаются, но за доступные опции отвечает код тарифа, а именно его название; конкретный класс бронирования и рейс на это уже не влияют. Например, у S7 есть 4 тарифных семейства: Эконом Базовый — невозвратный и только с ручной кладью, Эконом Гибкий — возвратный и с включенным багажом 23 кг, Бизнес Базовый — невозвратный, без доступа в бизнес-зал и с одним местом багажа до 32 кг и Бизнес Гибкий — возвратный, с доступом в бизнес-зал и двумя местами по 32 кг. Отличить их друг от друга очень просто: в коде тарифов семейства Базовый есть подстрока BS, а в коде тарифов семейства Гибкий — подстрока FL. Класс бронирования уже не отвечает за доступные опции. Например, если осталось 9 мест по классу бронирования N, то на эти места можно купить билеты и с багажом, и без него.
Вскоре еще несколько крупных российских авиакомпаний перешли на тарифные семейства. Мы поставили перед собой цель предоставить пользователю возможность выбора в подавляющем большинстве случаев (даже когда нужно долететь из Якутска в Белую Гору). Кроме того, с тарифными семействами все просто только до тех пор, пока клиент летит собственными рейсами авиакомпании, которой эти тарифы принадлежат. Как только возникает пересадка со сменой авиакомпании, начинаются исключения.
Разработка собственного решения
Разработку собственного решения мы начали с тщательного анализа. Мы пошли к операторам нашего контакт-центра и долго выпытывали у них, какая авиакомпания отвечает за предоставление клиенту тех или иных опций. Немного отвлекаясь, отмечу, что в процессе покупки билета участвует до трех авиакомпаний сразу: та, которой принадлежит самолет (мы называем её оперирующей), та, чей номер рейса указан на вашем билете (маркетинговая), и та, которая продала вам билет на своем бланке и будет распределять деньги между остальными (валидирующая).
Например, вы летите из Челябинска в Рим с пересадкам в Москве и Дюссельдорфе. На сегменте Челябинск — Москва вы летите собственным рейсом авиакомпании S7 — S7-8. На сегменте Москва — Дюссельдорф самолет принадлежит S7, но на билете у вас указан рейс авиакомпании AirBerlin и номер AB-5911. Значит, на этом сегменте оперирующий перевозчик — S7, а маркетинговый — AirBerlin и такая комбинация называется codeshare-соглашением. Дальше из Дюссельдорфа до Рима вы летите собственным рейсом AB-8718 AirBerlin. При этом весь перелет из Челябинска в Рим оформлен одним электронным билетом, который продала вам авиакомпания AirBerlin несмотря на то, что на первом сегменте вы летите собственным рейсом S7. В данном случае AirBerlin является валидирующим перевозчиком, т.е. авиакомпанией, которая по взаимному соглашению с другими авиакомпаниями-участниками перелета оформляет билет и будет осуществлять взаиморасчеты. Такое соглашение называется interline. Чаще всего валидирующая компания является и маркетинговой на каком-нибудь из сегментов, однако бывают случаи, когда отличаются все три авиакомпании — оперирующая, маркетинговая и валидирующая.
Так вот, на этапе сбора информации мы выяснили, что обычно опции задает маркетинговая авиакомпания — та, чей номер рейса указан у вас в билете и которой принадлежит тариф. Правда, может оказаться, что самолет оперирующей авиакомпании не рассчитан под нормы маркетинговой. Это относится в основном к багажу. Например, в самолете может не быть багажного отсека, как, например, в Ан-2. Кроме того, на рейсах с пересадками на разных сегментах могут быть разные правила провоза багажа и сомнительно, что пассажир будет рад где-нибудь в промежуточном пункте избавляться от лишних 2 кг багажа. С другой стороны, «Аэрофлот» чаще всего гарантирует своим клиентам свои нормы багажа, даже если у оперирующей авиакомпании нормы меньше.
Даже в рамках одной авиакомпании часто встречаются исключения на конкретном направлении и даже по конкретному аэропорту. Например, у Qatar Airways норма бесплатного провоза багажа в эконом-классе для рейсов из России — 1 место весом не более 30 кг, а для рейсов из США — 2 места не более чем по 23 кг каждое. У многих компаний меняются нормы багажа на рейсах на Ближний Восток — в Турцию и Египет. Есть и совсем исключительные случаи, когда на каком-нибудь отдельном направлении право устанавливать нормы багажа и взимать плату за их превышение выкупает не относящаяся к авиакомпании фирма.
Параллельно с накоплением знаний о проблеме мы начали собирать ту информацию, которая нам приходит из GDS, в надежде вытащить из нее закономерности. Нам нужно было поддерживать нашу базу знаний, поскольку тарифные правила авиакомпаний меняются постоянно. Идея не сработала: только для одного «Аэрофлота» с довольно стандартизированными правилами мы получили дерево решений, занявшее лист A4 очень мелким шрифтом.
Внедряем механизм FRule
В итоге мы решили использовать механизм FRule, который уже давно использовался в нашей команде и изначально представлял собой механизм гибкого конфигурирования. Позднее мы успешно применили его в нескольких прикладных задачах.
FRule — это система гибкого конфигурирования, которую мы разработали для наших сервисов. Впоследствии названием FRule стали называть архитектурный подход для описания системы, в которой необходимо гибко задавать и выбирать частный случай среди множества общих случаев.
Представляет он из себя вот что. Допустим, у нас есть функция от N переменных. Сначала мы задаем
Затем фиксируем какую-нибудь переменную 
и задаем
А, например, для 
задаем
Дальше фиксируем 
и продолжаем процесс, по сути переходя от общего к частному. Затем на вход этой функции подаются какие-либо данные. В случае с определением нормы багажа это данные полетного сегмента: откуда, куда, когда, какие авиакомпании, код тарифа и т. д. Здесь есть один нюанс: переменные в функции 
могут быть неравнозначны между собой. Рассмотрим простейший случай функции двух переменных 
. Пусть мы задали
Для заданной таким образом функции 
не определено. Чтобы избавиться от таких неопределенностей мы используем предустановленную систему приоритетов: мы говорим, что значения определенные для набора, в котором фиксирована только 
, приоритетнее, чем значения, определенные для набора, в котором фиксирована только 
. При этом значения, определенные для набора, в котором фиксированы и , и , приоритетнее значений, определенных для наборов, в которых фиксирована только одна из переменных. Таким образом, 
. Эти приоритеты обычно проистекают из предметной области и бизнес-логики, например, очевидно, что указание города приоритетнее указания страны.
Прежде чем разрабатывать решение для продакшена, мы решили проверить его «на коленке», и не зря. Физически механизм FRule представляет собой набор соответствий «параметры — значение» функции , хранящийся в MySQL. Исходя из приоритетов наборов при обращении к FRule, выполняются нехитрые запросы до того момента, пока не будет найден результат, который затем кэшируется. Для первоначальных задач конфигурирования этого более чем хватало. Выяснилось, что задачу определения опций необходимо дорабатывать. Оказалось, что для расчета багажа всех предложений по маршруту Москва — Санкт-Петербург на один день потребовалось 20 минут. Пересмотрев систему приоритетов и убрав оттуда избыточные и неиспользуемые наборы, мы сократили его до 3 минут. Однако это все равно было много.
Узким местом оказалась MySQL, а точнее, количество и накладные расходы на запросы, которые мы ей посылали в том случае, если результата для конкретного предложения нет в кэше. Для каждого предложения мы начинали искать совпадения: сначала по наиболее частному набору, затем переходили ко все более и более общим наборам. Приведем пример, чтобы представить масштаб бедствия. Сейчас у нас 288 наборов с разным приоритетом. Предложений по поиску на одно направление могут быть сотни и тысячи, и несмотря на то, что не все они будут показаны пользователю, обрабатывать требуется все.
Для решения этой проблемы мы решили перенести вычисления на бэкенд. Вычисление значений состоит из двух частей. Первая — это построение некой специальным образом организованной структуры. Вторая — вычисление значений исходя из этой структуры.
Рассмотрим, что за структуру мы строим. Вернемся к нашему примеру функции от двух переменных. Для нее мы определили такой приоритет наборов:
Напомню, что самый верхний набор является самым частным — если для всех входящих в него полей есть явно заданное значение функции, то оно и будет использовано. По сути, мы преобразуем плоскую табличку, хранящуюся в базе данных, в набор деревьев для каждого набора переменных. Рассмотрим процесс построения набора деревьев для набора 
. Сначала запросом типа
Мы получаем из базы данных все строки, для которых определены и , и . Затем группируем их по значению переменной . Затем правила в каждой группе группируем по переменной , и т.д. Таким образом, для наиболее частного набора строим такой набор деревьев:
Эту процедуру повторяем для каждого набора переменных. Например, для набора 
мы выберем правила запросом
Неиспользуемые в наборе переменные помечаем значением NOT_SPECIFIED. После того, как получены наборы деревьев для каждого набора параметров, складываем их в один массив с сохранением порядка приоритетов наборов.
В итоге для функции получаем такой набор деревьев:
Структура для проверки построена, остается лишь пропустить через нее входные данные функции. Перебираем деревья сверху вниз и обходим каждое их них, для каждой переменной выбирая ту ветвь, которая соответствует её значению. Если же такой ветви нет, то пробуем пройти по ветви NOT_SPECIFIED. Если значение найдено, то возвращаем его.
Кэширование данных
На самом деле, строить набор деревьев при каждом вызове FRule было бы странно — его можно один раз посчитать и запомнить. Кроме того, у нас несколько серверов, на которых может выполняться эта задача, так что неплохо было бы еще и передавать набор деревьев между ними. Для кэширования и синхронизации между серверами вычисленных значений мы используем memcache. Однако обращаться каждый раз к memcache, чтобы забрать из него набор, дорого — реальные наборы занимают несколько мегабайт и нет никакого смысла гонять их по сети. Поэтому кроме memcache мы используем еще и APCu (а до перехода на PHP7 — xCache). Если сервер построил или получил из memcache набор деревьев, то он сохранит его в APCu и в следующий раз возьмет оттуда.
Возникает еще проблема с синхронизацией изменений — ситуация, когда правила были изменены и на одном севере они применились, а на другом всё считается по-прежнему из-за старых данных в APCu, недопустима. Для решения этой проблемы мы храним в memcache текущий номер версии структуры. Он состоит из временной метки и версии кода, который построил структуру. Такая же метка хранится также в APCu каждого из бэкендов. Перед тем, как взять деревья из APCu, бэкенд проверяет, совпадает ли номер версии в его APCu с сохраненным в memcache. И если не совпадает, то перестраивает структуру и устанавливает в memcache и свой APCu новый номер. При редактировании правил из админки номер версии в memcache просто сбрасывается: таким образом все бэкенды узнают о том, что надо перестроить структуру.
Что мы в итоге получили
У пользователя, для выдачи которого нет данных в кэше, вычисление данных о тарифных опциях занимает от долей секунды до 15-20 секунд на очень больших выдачах, где много рейсов и много пересадок. Вскоре после выхода бэкенд-части на бой наши фронтенд-разработчики сделали фильтры по багажу, возможности обмена и возврата, благодаря чему клиенты могут сразу отсечь неинтересные им предложения. По статистике, новыми фильтрами пользуются порядка 10% посетителей, а интересуются параметрами багажа и возвратности 15%. Теперь пользователям не приходится долго искать тот же рейс, но с багажом или возможностью возврата. Мы научились отображать краевые случаи, например, авиакомпания «Полярные авиалинии» суммарно разрешает взять 20 кг багажа, из которых не более 5 — в ручную кладь.
Вот пример результатов нашей работы. Мы помогаем купить билеты не только по традиционным маршрутам в Санкт-Петербург, Сочи или Симферополь, но у нас довольно популярны и региональные направления. Посмотрим на рейс авиакомпании Алроса из Красноярска в Мирный:
Сразу при поиске можно посмотреть все подробности: и возможность обмена или возврата, и норму багажа, и норму ручной клади, и даже особую схему их расчета, когда пассажир может взять именно суммарно 20 кг багажа. Зачастую такую информацию можно получить или на сайте авиакомпании, или только из личного общения с представителем авиакомпании. Стоит отметить, что это не только наше желание показать всю информацию честно и четко — все эти параметры очень важны самим покупателям при выборе, и без них мы получаем обратную связь от пользователей, что этого не хватает.
С технической точки зрения, мы получили базу знаний, содержащую порядка 10 000 правил, что в значительной мере покрывает наш ассортимент. Конечно, остаются еще предложения, для которых у нас пока не заведены правила — особенно это касается тех направлений и предложений, по которым у нас редко ищут и покупают. Для того, чтобы контент-менеджеры могли оперативно узнавать о таких предложениях, мы разработали специальную систему логирования: стоит прийти значению той или иной опции, которая отличается от значения в нашей базе знаний или которой в ней нет, в течение часа контент-менеджеры об этом узнают. Для поддержания базы в актуальном состоянии наши контент-менеджеры постоянно взаимодействуют с авиакомпаниями и проверяют, нет ли изменений на официальных сайтах, созваниваются с их представителями.
Созданный механизм достаточно легко расширяется: мы можем начать показывать информацию о размере доплаты за багаж, возможности провоза спортивного снаряжения, количестве начисляемых бонусных миль и т. д.