The DonaTrainer Handbook

Welcome aboard

Amadeus is operated entirely through short, dense commands — "cryptic entries." There's no menu to hunt through; you type an instruction, the system replies, and you build on that reply. It feels unfriendly for about a day and then it feels like the only sane way to work.

Each chapter below pairs a real entry with what it does and what the simulator will say back. Everything is safe to try — DonaTrainer keeps its data in your browser only, and nothing here ever touches a real airline.

The help system

Amadeus is famous for burying its own documentation inside itself. DonaTrainer does the same thing on purpose — type HE for a list of topics, or HE followed by a topic name for a one-line refresher without leaving the terminal.

Think of it as a quick-reference card that lives inside the tool instead of a separate browser tab — this handbook is the long version.

Decode & encode

Everything in a GDS is a code: airports, cities, airlines, countries. Before you can read an availability display fluently, you need to be able to go from code → name and back.

Availability — AN

Every booking starts with a question: what's flying? AN (Availability, Neutral) answers it — date, origin, destination, and it hands back a numbered list of flights you can sell straight from.

Durations and arrival times are calculated from real airport coordinates — a Doha–London flight really does take about seven hours here, and an overnight sector shows +1 on the arrival time when it lands the next day. The header line names the destination airport itself and its country, plus how many days out the search is and the day of the week — ** AMADEUS AVAILABILITY - AN ** LHR HEATHROW.GB 7 TU 15DEC 0000 — the same shape a real display uses.

• /R<DDMMM> — add a return date in the same entry: AN15DECDOHLHR/R22DEC.
• /A<CARRIER> — show one airline only: AN15DECDOHLHR/AQR.
• /D — nonstop flights only, no connections.
• /C<CLASS> — focus the display on one booking class.
• /X<CITY> — exclude a connection city, e.g. /XMCT to avoid routing through Muscat.

If there's no nonstop service between two cities, the terminal offers up to two one-stop routings through a shared hub automatically — real displays commonly show several connecting options side by side rather than just one, and this is where a lot of the apparent carrier variety on a real screen actually comes from.

A codeshare prints as <MARKETING>:<OPERATING><FLIGHT> — e.g. EY:GA9102 means you're selling Etihad inventory on a flight actually operated by GA9102. That's the real notation; there's no separate footnote line. Airport codes carry a terminal when the airline files one for that pairing, e.g. /DAC 2 FCO 3.

Booking-class inventory is shown in full — 7 to 20 RBD codes per flight depending on the route, wrapping onto one continuation line after the 7th exactly like a real screen. The last leg of each option also prints a stop count and equipment code (E0/788) followed by the option's total elapsed time.

Other display orders and follow-ups. SN is the schedule equivalent of AN; AA, AD and AE re-sort the same flights by arrival time, departure time, or elapsed flight time instead of renumbering from scratch.

Building a PNR

A Passenger Name Record needs five mandatory elements before it can be saved. Miss one and ER will refuse to save it — that's deliberate, it's the same rule a real system enforces.

Children and infants ride on the same NM entry, with a qualifier in parentheses:

Groups go in one entry too — bump the leading number and chain more first-name/title pairs after the shared surname:

If your selected class shows 0 seats in the availability display, SS won't refuse the sale — it waitlists it (status HL instead of HK) exactly like the real system would.

Optional PNR elements

Beyond the five mandatory pieces, a PNR can carry free-text remarks, special service requests, frequent flyer numbers and seat assignments.

Seat maps and assignments work the same way you'd expect on a real segment display — the layout depends on the cabin (a 2-2 business layout with lettered A/C/D/F seats, or a 3-3 economy layout with A-F) and which seats are already taken stays consistent every time you look:

Confidential and itinerary remarks, open segments, and reconfirmation.

Retrieving & servicing a PNR

Once a booking is saved you'll spend most of your time retrieving and adjusting it, not creating new ones from scratch.

History codes. RH tags each line with the same short element code a real Amadeus history uses — [AN] Added Name, [AS] Added a status/segment element, [AT] Added Ticketing Arrangement, [CN] Changed Name, [CS] Changed Status, [DL] Deleted Element, [SP] Split Party, [TC] Time Change, and so on — so reading a PNR's history trains you to read a real one.

PNR security, flight-based retrieval, and printing.

Ticketing time limits. Beyond plain TKOK, a PNR can carry a real deadline:

Pricing

Four entries price an itinerary; the difference is whether the result gets stored as a Transitional Stored Ticket (TST) and whether it hunts for the lowest available fare.

All four accept a passenger scope: /P1 (passenger 1 only), /PAX (adults and children), /INF (infant only) — and /R,U anywhere in the entry for a discounted private/corporate (UNI) fare. The fare itself is calculated from real distance, the booking class you sold, and the travel month's seasonality (Jul/Aug/Dec price higher, quieter months lower) — a short hop in a discounted class in February prices well below a long-haul in a full-fare class in August. FXR and FXB additionally re-check the class inventory left open on the segment and price against whichever class is actually cheapest and available, exactly like a real lowest-fare search.

Pricing modifiers. Add a percentage fee or markup at pricing time, before a TST even exists, with /F-P<n> (fee) or /M-P<n> (markup) on any of the four pricing entries — e.g. FXP/F-P10 adds a 10% fee during the calculation, FXB/M-P5 finds the lowest fare and adds a 5% markup on top. Both stack with /R,U and the passenger-scope qualifiers.

Fare-quote follow-ups. Every row an FQD display prints keeps its line number live for these:

Standalone calculators that don't need a fare display first:

Best Buy checks a booked itinerary against the lowest fare actually available, rather than pricing whatever class you already sold:

Payment & ticketing

Three fields have to be on file before TTP will issue anything: a TST (Chapter 08), a validating carrier, and a form of payment.

Once issued, tickets carry a realistic number — the validating carrier's own 3-digit numeric code plus a serial, exactly the format printed on a real e-ticket. TTP and TWD print the same full coupon block a real Amadeus ticket display shows: the flight lines, FARE/TAX/TOTAL, the FC (fare calculation) line — e.g. FC DOH QR LHR350.00EUR350.00END — the FB fare basis with its NVB/NVA validity dates, and an FE endorsement line.

Real e-ticket status codes. Every ticket carries one of the letters a real Amadeus coupon uses: O Open For Use, V Void, R Refunded, E Exchanged/Reissued (plus A/C/F/G/I/L/P/S/T/X for airport control, checked-in, flown, and so on) — shown on TWD, TTP, TJQ and the printed itinerary.

TQT displays the stored TST — passenger list, fare/tax/total, FC, FB with NVB/NVA, FE, FT, additional collection, and commission — exactly what you'd check before deciding what to edit or before issuing. TQT/T<n> selects a specific TST by number when more than one is on file (e.g. after re-pricing more than once).

Editing the TST before ticketing — the same follow-up entries a real reissue or net-fare sale relies on. TTI is the same command as TTK (both names are used in the field):

Reissuing a ticket. A reissue is a change to an already-ticketed itinerary, and it's a genuinely different workflow from a refund:

1. Rebook the affected segment — SB.
2. Re-price the itinerary — FXP.
3. Pull the original ticket's issue data onto the new TST — FO*L<n> (the line of the ticket being replaced).
4. Set the extra amount the passenger owes — TTK/T<amount>. TTU/T<n>/S<segs> can flag which segments the reissue covers on a multi-TST PNR.
5. Issue as usual — TTP. The original ticket flips to status E (exchanged); the new one prints a REISSUE OF line and the additional collection.

Automated refunds are a separate, multi-step record rather than a single command:

Sales reports

TJQ pulls a list of every ticket issued, across every PNR you've saved in this browser.

Queues

A queue is a to-do list PNRs land on automatically — the classic example is queue 5, "Schedule Change." DonaTrainer actually generates that traffic: retrieving a saved, ticketed PNR carries a real chance of triggering a schedule change, which lands it on queue 5 for you to work.

A PNR with a ticketing time limit (TKTL, Chapter 07) lands on queue 8 category C1 automatically the moment it's saved — try QC8CA after setting one. Queue 2 works the same way for waitlists: a segment sold into a full class goes on as HL, and retrieving that PNR carries a chance of clearing it to HK and queuing it to 2 for you to action.

Customer profiles

A profile stores a traveler's — or a company's — name and contact details so they don't have to be retyped on every booking.

Travel documents

The IEP family simulates emailing an itinerary — nothing actually leaves your browser, which is exactly what you want in a training sandbox.

Session & sign-in

DonaTrainer signs you in automatically, but the real transactions still work if you want the full ritual — or if you want to see what "locked out" looks like.

Reference lookups & calculators

A few self-contained utilities that don't touch a PNR at all.

Full command index

Every entry the terminal recognizes, alphabetically. When in doubt, this is the page to search.

Credits

DonaTrainer is built and maintained by Donabil SAS, free for the travel industry, forever.