AeroToys
Offer & Order

From PNR and ticket to a single Order spine.

The PNR was invented in the 1960s for telex. The e-ticket arrived in the 1990s. The EMD followed in the 2000s. Each was an answer to the previous bottleneck. Stacked together, they are the bottleneck. Offer & Order replaces the entire stack with two records — and that is harder than it sounds.

The legacy: PNR, e-ticket, EMD, and a lot of glue

A single trip in a legacy airline IT estate touches at least four systems:

  • PNR — the reservation. Holds segments and passengers.
  • e-Ticket — the right to fly, settled through BSP/ARC.
  • EMD — the electronic miscellaneous document, issued for every ancillary (bag, seat, lounge, meal). Each EMD has its own life cycle.
  • Revenue Accounting — reconciles the ticket and EMDs against actual delivery, often weeks later.

Each system has its own state machine. They drift. Servicing a disrupted passenger means touching all of them, often manually. Settlement breaks. Refunds take 30+ days. Ancillaries get lost. The integration tax is enormous and entirely invisible to the customer.

What Offer & Order actually changes

The architectural shift has three pieces:

  • One Order, not three documents. Flight, bags, seats, lounge, refund — one record. Append-only. Servicing operates on the Order, not on the underlying documents.
  • Offer is separated from Order. The Offer is what the airline proposed; the Order is what the customer accepted. Those are different lifecycles. Conflating them (as the legacy stack does) is what makes shopping caches diverge from inventory.
  • Dynamic Offer Construction. Offers are assembled in real time from rules and inventory, not retrieved from a filed-fare table. This is what makes contextual pricing, bundling, and personalisation actually possible.

Why this is hard

Almost every airline process — IRROPS, codeshare, interline, refunds, loyalty accrual, revenue accounting, fraud — is built around the PNR/ticket/EMD model. Replacing that model means replacing or wrapping every one of those processes. You can't do it overnight, and you can't do it without a clean architectural target.

The traps we see most often:

  • Bolting Order on top of PNR. Order becomes a façade over the same legacy data. You get the API surface but none of the architectural benefits.
  • Letting the OMS vendor own the data model. Offer and Order are your most valuable data. They should sit in a database you control.
  • Underestimating settlement. The hardest part of ONE Order is not the order record — it's reconciling it with revenue accounting, interline, and tax authorities that still expect ticket/EMD shapes.

How AeroToys helps

We give you the open foundation: a database (the Open Order Database — DocumentForge) tuned for append-only, time-travel-friendly Order records, and a rules engine (the Open Rules Engine — RuleForge) that makes the Offer side composable and explainable. On top of that we're building Offer Management, Order Management, the Open Shopping Engine, the Open Stock Keeper, and Open Schedules as a coherent suite — but each is independently adoptable.

Pair the airline stack with the community stack — Open Tax Engine and the Open Schedules corpus — and you've replaced most of the licensed plumbing with code you control.

FAQs

Can we run Offer & Order alongside our existing PSS?
Yes — and most airlines will, for years. The pragmatic path is usually to put Order in front of new ancillary and direct-channel flows first, then progressively migrate legacy traffic. Append-only records and event streams make the parallel-run period manageable.
What about interline and codeshare partners still on PNR/ticket?
The Order spine doesn't require the whole industry to move. You translate at the boundary — issue the ticket/EMD when you need to interact with a partner that requires it, while operating internally on the Order. Over time, more partners move; the translation surface shrinks.
Is there a path that avoids replacing revenue accounting?
For a while, yes — you can generate ticket/EMD-shaped settlement events from Order. Long term, revenue accounting itself moves to operate on the Order, but that's a migration measured in years, not quarters.