Представляем вашему вниманию вторую часть (вот первая) из серии статей об информационных технологиях в авиаперевозках. Что, на самом деле, скрывается за PNR-кодами на посадочных талонах? Почему в строке расчёта тарифа используется несуществующая валюта? Поищем сегодня ответы на эти вопросы.

В моём электронном билете, выданном авиакомпанией Air India, имеется строка, которая выглядит как типографская ошибка:

NAG AI X/DEL AI LON Q DELLON14.00Q DELLON21.00 228.08 NUC263.08END ROE88.687919

Но это совсем не ошибка. Это — строка расчёта тарифа, при составлении которой используется система нотации, разработанная ещё в 1970-х годах. В расчётах используется несуществующая валюта NUC (Neutral Units of Construction, нейтральная единица расчёта). Тариф определяется для кода города (LON, система аэропортов Лондона), а не для конкретного аэропорта. Каждое поле этой строки имеет значение. Когда вы доберётесь до конца статьи — сможете читать такие строки.

Но для начала поговорим о шести символах которые можно найти в билете.

DDTCIV

Это — мой код PNR (Passenger Name Record, запись регистрации пассажира). Номер бронирования. Код подтверждения. Это — те самые шесть символов, по которым меня идентифицирует авиакомпания Air India, система регистрации аэропорта и сканер у выхода на посадку в Лондоне. Этот код имеется на каждом документе, который связан с моим рейсом: на электронном билете, на подтверждении в системе myBiz, на посадочном талоне, на багажной бирке.

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

Дело в том, что PNR-коды не являются уникальными в глобальном масштабе.

Что такое, на самом деле, PNR?

PNR — это каноническая структура данных сферы коммерческих авиаперевозок. По сути, PNR имеется у каждого бронирования пассажирского билета, оформленного в авиакомпании, входящей в состав IATA. Сама идея PNR появилась в IATA (International Air Transport Association, Международная ассоциация воздушного транспорта) в 1960-х годах. Формальное описание PNR дано в документе «Recommended Practice 1830» (Рекомендуемая практика 1830). Коды PNR сохраняют структурную целостность со времён их появления и до наших дней.

PNR, в привычном понимании — это не запись в базе данных. Это — структурный документ, по своему устройству близкий к лог-файлу, поддерживающий только добавление данных в его конец, хранимый в GDS (Global Distribution System, глобальная дистрибьюторская система), в которой он был создан. В моём случае роль GDS играет Amadeus. PNR связан с индивидуальным кодом бронирования (locator, локатор). Это — короткий идентификатор, сгенерированный GDS в момент сохранения бронирования.

Длина идентификатора, в нашем случае — DDTCIV, составляет шесть символов. Он, в пределах системы Amadeus, уникален. Но его уникальность в глобальном масштабе, во всех существующих GDS, не гарантируется. Так, например в системах Sabre и Amadeus может иметься один и тот же идентификатор — DDTCIV, но принадлежать он будет абсолютно разным пассажирам, забронировавшим билеты в разных авиакомпаниях.

DDTCIV (Amadeus) → Ajitem Sahasrabuddhe, NAG→LHR, 08 Feb 2026
DDTCIV (Sabre)   → Тут может быть кто угодно, совершающий какой угодно перелёт в любую дату.

Именно поэтому авиакомпании применяют собственные идентификаторы записей (Record Locator). Это — отдельные коды, существующие в их собственных PSS (Passenger Service System, система обслуживания пассажиров) и связанные перекрёстными ссылками с GDS-идентификаторами. Когда пассажир регистрируется напрямую в Air India — ему могут показать другой идентификатор. GDS-идентификаторы — это то, что видят продавцы авиабилетов. А идентификаторы записей, применяемые авиакомпаниями — это коды, которыми бронирования обозначаются в собственных системах этих авиакомпаний. В результате разные идентификаторы соответствуют одним и тем же перелётам. А вот их внешний вид друг от друга отличается.

Пять обязательных элементов

В «Рекомендуемой практике 1830» указаны пять обязательных элементов, которые должны присутствовать в документе до того момента, когда PNR можно будет «финализировать», то есть — сохранить и присвоить ему идентификатор. Без наличия всех этих пяти элементов бронирования не существует.

1. NM: Имя пассажира (фамилия пассажира/имя/форма обращения)
2. IT: Путь следования (как минимум один полётный сегмент)
3. AP: Адрес/Телефон (контактный номер телефона или адрес электронной почты)
4. TK: Элемент выпуска билета (ограничение по времени или подтверждение)
5. RF: От кого получено (кто авторизовал бронирование)

Эти пять элементов представляют собой контракт между системой бронирования билетов и авиакомпанией. Их существование объясняется тем, что в 1964 году компании American Airlines была нужна минимально достаточная структура данных. Такая, которую можно было передавать по телетайпной сети, обрабатывать за миллисекунды и хранить в ячейке памяти фиксированного размера.

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

Расшифровка моего PNR

Вот как выглядит моё бронирование с кодом DDTCIV в системном формате вывода данных Amadeus. Я реконструировал эти данные из сведений, взятых из моего электронного билета. Это — то, что увидел бы продавец авиабилетов, если бы он, работая в терминале, попытался бы получить соответствующие данные с помощью команды RTDDTCIV.

--- RLR ---
RP/NAGAI2101/NAGAI2101 AI/SU 05DEC25/0000Z DDTCIV
 1.SAHASRABUDDHE/AJITEM MR
 2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 01A
 3 AI 2015 Z 08FEB 7 DELLHR HK1 1515 2030 E 0 04K
 4 APM-9XXXXXXXXXX
 5 APE-AJITEM@TECHNOGISE.COM
 6 TKOK
 7 RF-MYBIZ ONLINE
 8 SSR HNML AI HK1/SEG2
 9 SSR UPGP AI HK1/SEG2

А теперь разберём отдельные поля:

--- RLR ---
  Record Locator Retrieved: подтверждение того, что мы просматриваем активный PNR
 
RP/NAGAI2101/NAGAI2101
  RP = Запись создана в данном офисе
  NAGAI2101 = Идентификатор офиса: NAG (Nagpur) + AI (Air India) + 2101 (номер офиса)
  Второе поле NAGAI2101 = последний офис, который модифицировал запись
 
AI/SU 05DEC25/0000Z DDTCIV
  AI = авиакомпания (Air India)
  SU = код модификатора (идентификатор агента MakeMyTrip)
  05DEC25/0000Z = создано 5 декабря 2025 года, полночь по UTC
  DDTCIV = код бронирования (локатор)
 
1. SAHASRABUDDHE/AJITEM MR
 Элемент NM: фамилия пассажира/имя/форма обращения
Первой всегда идёт фамилия. Это — обязательное требование IATA.
 
2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 01A
  AI=перевозчик  Z=класс  7=Воскресенье  NAG=аэропорт вылета  DEL=аэропорт назначения
  HK=подтверждено  1=1 пассажир 0840=время вылета  1030=время прилёта
  E=электронный билет 0=рейс без пересадок  01A=место
 
4 APM-9XXXXXXXXXX  ← Элеемент AP, M=Номер мобильного телефона
5 APE-...          ← Элемент AP, E=Адрес электронной почты
6 TKOK             ← Элемент TK: Билет OK (нет ограничений по времени)
7 RF-MYBIZ ONLINE  ← Элемент RF: получено от MakeMyTrip
 
8 SSR HNML AI HK1/SEG2  ← индуистское питание, подтверждено, сегмент 2
9 SSR UPGP AI HK1/SEG2  ← платное повышение класса обслуживания через PlusGrade, подтверждено

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

Когда мой рейс был отменён в феврале — коды HK превратились в коды XX. Затем в системе появились новые записи, касающиеся альтернативного маршрута. Мы подробно поговорим об этом в пятой части этой серии статей.

Номер электронного билета

В верхней части моего электронного билета, выданного авиакомпанией Air India, можно найти сведения о номере билета:

TICKET NUMBER: 098 5801178331

Этот номер имеет особую структуру:

098        → Цифровой код IATA, присвоенный Air India
5801178331 → 10-значный серийный номер, глобально уникальный в пределах AI
 
Полный номер: 098-5801178331

У каждой авиакомпании имеется 3-значный числовой код IATA. 098 = Air India. Компании British Airways назначен код 125. Компании IndiGo — код 526. Эти коды появились до всем известных 2-символьных кодов IATA (AI, BA, 6E). Они использовались в те времена, когда телетайпы не могли надёжно передавать перемешанные друг с другом алфавитные и цифровые символы.

Именно номер электронного билета, а не идентификатор PNR — это настоящий первичный ключ бронирования. У PNR может меняться статус, может меняться состав сегментов этой структуры данных, её могут передавать между офисами. А номер электронного билета, будучи однажды созданным, не меняется. Он хранится в ETD (Electronic Ticket Database, база данных электронных билетов) авиакомпании Air India, а не в GDS. Когда пассажир проходит на посадку в самолёт, сканер у выхода сверяет номер билета этого пассажира с ETD. Код PNR — это то, что видят продавцы авиабилетов. А номер электронного билета — это то, чем пользуются, и чему доверяют системы авиакомпаний.

На обратном пути у меня был другой номер билета: 098-5801178359. Использовался он для всех трёх полётных сегментов: рейс BA1361 (выполняемый British Airways), рейс AI112 (LHR→DEL) и рейс AI415 (DEL→NAG). Даже сегмент, обслуживаемый British Airways, был оформлен с использованием цифрового кода Air India. Дело в том, что авиакомпания Air India играла роль оформляющего перевозчика (ticketing carrier) всего маршрута. А компания BA была лишь фактическим перевозчиком (operating carrier) на подвозящем рейсе.

Когда, после столкновения самолёта с птицей, мои билеты пришлось переоформлять, номер билета не изменился. Изменились лишь сегменты PNR. Электронный билет был перевыпущен на новые рейсы. А вот его номер, 098-5801178359, остался таким же, каким был. Номер электронного билета — это единственный по-настоящему стабильный идентификатор в системах авиакомпаний.

Строка расчёта тарифа

Предлагаю вернуться к таинственной строке из моего электронного билета:

NAG AI X/DEL AI LON Q DELLON14.00Q DELLON21.00 228.08 NUC263.08END ROE88.687919

Это — описание расчёта тарифа, применяемое IATA. Здесь используется предметно-ориентированный язык, с помощью которого описывается расчёт стоимости билета, основанный на сведениях об отдельных компонентах маршрута. Этот формат был стандартизирован в 1970-х годах. Его описание входит в состав глобальных правил расчёта тарифов IATA.

Разберём эту строку:

NAG
 Город отправления: Нагпур
 
AI
  Перевозчик для данного тарифного компонента: Air India
 
X/DEL
  X/ префикс = пункт транзита (не является промежуточной остановкой, не приводит к разделению тарифа)
  DEL = Дели
  Здесь X  — это очень важный символ: он означает, что в Дели расчёт тарифа не сбрасывается.
  А без этого символа, если бы тут были только символы "DEL", этот пункт разделил бы маршрут на две части, тариф для каждой из которых рассчитывался бы отдельно.
 Благодаря конструкции X/DEL стоимость всего маршрута рассчитывается как один тарифный компонент.
 
AI
  Тот же перевозчик: Air India
 
LON
  Пункт назначения: Лондон. Код города, а не код аэропорта.
 Код LON включает в себя коды аэропортов Хитроу (LHR), Лондон-Сити (LCY), Гатвик (LGW), Станстед (STN).
  Тарифы IATA рассчитываются на основании сведений о городах, а не об аэропортах.
  Мой самолёт приземляется в аэропорту LHR, но при расчёте тарифа используется город LON.
 
Q DELLON14.00
  Q = надбавка, применяемая при построении тарифа для сектора DEL→LON, NUC 14.00
  Надбавки с кодом Q — это наследие старой системы конструирования тарифов из 1970-х годов.
  Они представляют собой доплаты, которые нельзя включить в расчёт базового тарифа.
 
Q DELLON21.00
  Вторая Q-надбавка в том же секторе, NUC 21.00
 
228.08
  Базовый тарифный компонент, выраженный в NUC
 
NUC263.08
  Всего: 228.08 + 14.00 + 21.00 = 263.08 NUC
  NUC = Neutral Unit of Construction, нейтральная единица расчёта
  Это — условная расчётная единица, не являющаяся настоящей валютой и не существующая в виде реальных денег.
  Любой тариф IATA сначала рассчитывается в NUC, а потом конвертируется в нужную валюту.
 
END
  Конец расчёта тарифа
 
ROE88.687919
Обменный курс: 1 NUC = INR 88.687919
  Курс публикуется IATA еженедельно. Он применяется в момент оформления билета.

Вот как выглядит расчёт тарифа:

263.08 NUC × 88.687919 = INR 23,330 ≈ Базовый тариф в INR 23,335

Система NUC существует из-за того, что в авиакомпаниях применяются международные тарифы, а курсы валют подвержены колебаниям. Формируя тарифы, выраженные в условных расчётных единицах и пересчитывая их в соответствии с курсами реальных валют на момент оформления билета, IATA позволяет организовать единообразный расчёт тарифов на разных рынках, не делая их зависимыми от движений валютных курсов между моментом объявления тарифов и моментом покупки билетов. Это — решение задачи формирования тарифов в условиях, когда используется множество валют, созданное в 1970-х годах. Оно до сих пор применимо для решения специфических задач, стоящих перед IATA: централизованная публикация курсов, их еженедельное обновление, обеспечение того, что стоимость билетов преобразуется из NUC в реальную валюту лишь единственный раз — при их оформлении.

Q-надбавки — 14.00 и 21.00 — это не топливные сборы (они даются под кодом YQ и указываются в билете отдельно). Это — надбавки, которые применяются при построении тарифа: сборы, обусловленные правилами тарификации IATA, необходимые при определённых комбинациях маршрутов. Они всё ещё существуют из-за того, что изменение правил расчёта тарифов IATA требует многостороннего соглашения между авиакомпаниями-членами IATA. Добавить надбавку нового типа легче, чем избавиться от существующей.

Строка расчёта тарифа обратного билета: другая валюта

В моём обратном билете (DHB4AL) имеется другая строка расчёта тарифа:

MAN BA X/LON AI X/DEL AI NAG 282.67 NUC282.67END ROE0.763485

Структура у неё такая же, как у той, что мы разбирали выше. Главное отличие — поле ROE:

ROE0.763485
  1 NUC = GBP 0.763485

Цена за билет была указана в GBP, а не в INR. Из-за того, что моё обратное путешествие начиналось в Манчестере, стоимость билета была выражена в валюте страны вылета: Соединённого Королевства. Вычисление базового тарифа — GBP 216.00 — выглядит так:

282.67 NUC × 0.763485 = GBP 215.8 ≈ GBP 216.00

Потом, для выхода на итоговую стоимость билета, эта сумма конвертирована в INR 25,880. В результате у нас имеется два билета. Их стоимость измеряется в двух разных валютах, а связывает их воедино единый механизм расчёта, основанный на NUC.

Сведения о маршруте в этой записи подчинены той же самой X/-логике:

MAN BA X/LON AI X/DEL AI NAG
          |         |
    LON - транзитный аэропорт (X/): тариф не разделяется
                    DEL - транзитный аэропорт (X/): тариф не разделяется

Один тариф. Четыре города. Две авиакомпании. Единая система расчёта стоимости поездки, основанная на NUC.

Тур-код

Нам стоит обратить внимание на ещё одно поле, Tour Code (тур-код) спрятанное глубоко в разделе оплаты:

Tour Code: INNT010

Это — идентификатор корпоративной учётной записи Technogise в системе MakeMyTrip. Когда был создан PNR — этот код был внедрён в элемент оформления билета. Затем этот код путешествует вместе с записью о бронировании через систему взаиморасчётов BSP. BSP (Billing and Settlement Plan, Планирование выставления счетов и урегулирования взаиморасчетов) — это механизм, который используется в IATA. С его помощью авиакомпании выставляют счета продавцам билетов, а продавцы выставляют счета корпоративным клиентам.

Тур-код — это то, что позволяет системе учёта доходов Air India узнать о том, что ей, при расчётах, нужно применить договорной корпоративный тариф Technogise. Именно этот код сообщает финансистам MakeMyTrip о том, что счёт нужно выставить Technogise, а не частному лицу. Он же позволяет службе расчётов с контрагентами Technogise сверить начисление с внутренними документами компании. Получается, что всего одна строка, находящаяся в одном из полей PNR, связывает финансовые системы четырёх организаций.

Итоги

Не все идентификаторы могут играть роль первичных ключей. Код PNR — это лишь идентификатор сессии. Он уникален в пределах одной GDS, а не во всех подобных системах. Настоящий первичный ключ — это номер электронного билета. Он отличается глобальной уникальностью в пределах выдавшей его авиакомпании, он не меняется при переоформлении маршрута. Если воспринимать их как равнозначные сущности — это будет всё равно, что считать URL идентификатором строки в базе данных. В авиации их различие определяет работоспособность системы переоформления билетов: номер билета не меняется даже в том случае, если весь маршрут, соответствующий билету, будет полностью перестроен.

Применение NUC позволяет решить задачу ценообразования при использовании множества валют в специфических условиях, в которых работает IATA. А именно — речь идёт о централизованных курсах, о еженедельной публикации обновлений, о единственном моменте, когда цена, выраженная в NUC, преобразуется в реальную цену. Применяемый здесь подход, обеспечивающий стабильность системы в условиях колебаний курсов валют, может быть перенесён и в другие сферы деятельности. Речь идёт о формировании цен в нейтральных единицах расчёта и о преобразовании их в реальные деньги в момент транзакции. Надо отметить, что применение этого подхода требует соблюдения определённых ограничений. А именно, его работоспособность обеспечивается тем, что IATA контролирует периодичность публикации курсов валют, и тем, что конвертация проводится в строго определённый момент.

Q-надбавки, применяемые при построении тарифов, похожи скорее не на полезные данные, а на «информационный шум». Они — наследие прошлого, от которого очень сложно избавиться. Каждое поле в материалах IATA существует не просто так. Кто-то когда-то сел не на тот рейс, или заплатил не ту цену, или не смог доказать того, что имеет право на место в самолёте. Когда такое случалось, в систему добавляли соответствующие правила. Поэтому для того, чтобы убрать какое-то поле, необходимо достижение многостороннего соглашения между всеми теми, кто работает по стандартам IATA. А вот добавление новых полей не сопряжено с подобными сложностями.