Accepting an offer
When a customer accepts an offer, the system creates an order only if the offer has not expired, contains at least one item, and prices every item in the offer's currency. The order's price is the sum of the item prices.
Proof of concept · built from public IATA ONE Order material · not affiliated with IATA
Every rule, guarantee and candidate, with its status
Every rule and guarantee in the Lean model, and every candidate rule from the ONE Order survey, with the status the build gives it. A proven guarantee holds for every possible input. An open question is a guarantee the rules as written do not meet, with an example that shows the failing case. This page is generated from the model on every build.
73
rules in the model
203
guarantees proven
60
open questions
67
need a business decision
7
ready to build
1
waiting on other rules
Decide these first
These open questions and decisions have the most cards depending on them, so an answer reaches furthest. Each is ranked by the number of cards that use it, directly or through other cards, and ties by the number of areas those cards are in.
- 51 cards in 7 areas: Payment, Change and cancellation, Delivery, Offers and prices, Order creation, Ancillaries, Accounting
- 22 cards in 6 areas: Payment, Change and cancellation, Delivery, Order creation, Ancillaries, Airline change
- 22 cards in 1 area: Accounting
- 16 cards in 5 areas: Change and cancellation, Delivery, Order creation, Ancillaries, Airline change
- 15 cards in 3 areas: Payment, Change and cancellation, Accounting
- 10 cards in 2 areas: Ancillaries, Airline change
- 9 cards in 1 area: Accounting
- 7 cards in 2 areas: Delivery, Ancillaries
- 7 cards in 2 areas: Payment, Change and cancellation
- 7 cards in 1 area: Accounting
Open questions
A guarantee the business expected to hold, and an example where the rules as written break it. Open a question to read the example and the open point. An area's name leads to its summary page.
Payments and refunds1
Refunds never exceed payments15 cards depend on it
If every refund was accepted against one of the order's payments, the total refunded does not exceed the total paid.
Counterexample: two refunds of 60.00 against one payment of 100.00 are each accepted and together return 120.00.
Open point: does the limit apply per refund, cumulatively per payment, or cumulatively per order, and is a refund above the amount paid ever allowed, for example as a goodwill credit?
Order structure and status2
Each item has exactly one status
Every order item with a service has exactly one of the three statuses.
Counterexample: an item whose one service was delivered and then transferred meets the conditions for both CANCELLED and CLOSED. An item whose one service is SUSPENDED has no status at all under a reading where a suspended service holds no value.
Open point: which status wins when the conditions overlap, whether a delivered service may be transferred at all, and what status an item has when none of the conditions holds.
Every order is opened or closed
Every order with at least one service is opened or closed.
Counterexample: under a reading where an expired service holds no value, an order whose only service expired is neither opened nor closed.
Open point: whether EXPIRED and UNABLE TO DELIVER hold value, and whether an order with such a service should be closed.
Payment3
Time limit on unpaid items1 card depends on it
Every order item that is unpaid or partly paid carries a payment time limit, and a paid item carries none. A time limit of zero on an offer item means the item must be paid when the order is created. Case to check: An order created without payment returns no time limit for one item. Under the second reading that item never expires and holds its seat with nothing paid. In the model the guarantee is that an unpaid item does not stay in the order indefinitely. That a paid item has no time limit is a theorem of the outcome rule.
Counterexample: an order whose trip was created without a payment time limit still holds the trip a year later, its flights confirmed and nothing paid.
Open point: The ARMI guidance expects the airline to set a limit on every unpaid item, while the EASD Time Limits page says a missing limit only means no advice was given. The business must decide whether an unpaid item may exist without a limit and, if so, whether it can stay unpaid indefinitely.
Removed items hold no value
An order item removed at its payment time limit holds no value: none of its services holds value afterwards.
Counterexample: when the removed trip's services become EXPIRED, the trip stays active under the cautious reading of the guide, where an expired service holds value. When they become REMOVED HOLD VALUE it stays active under every reading. With REMOVED it is cancelled under both readings.
Open point: which service status and delivery status an item takes when its payment time limit passes unpaid, and whether it then holds value.
Settled payments keep their status
A SUCCESSFUL or FAILED payment keeps its status whatever outcome the airline later reports for one of its methods.
Counterexample: under a reading where a card chargeback turns a successful transaction into a failed one, a card payment for the trip goes from SUCCESSFUL to FAILED. Under a reading where a late redirected payment is recorded, a payment the airline marked FAILED at the time limit becomes SUCCESSFUL a minute later, while the trip it paid for stays removed.
Open point: whether a SUCCESSFUL payment can later fail, whether a FAILED payment can later succeed, and what then happens to the order items it covers.
Change and cancellation6
Due amounts net to the difference1 card depends on it
For every change or cancellation offer, the amount due to the airline minus the amount due by the airline equals the new price minus the old price, plus penalties, plus forfeited amounts. Netting of penalties or taxes changes how this net is split between the two due amounts and never changes the net. In EXM_ORD_003C, 900 minus 1,000 plus a 40 penalty plus 120 forfeited gives 60 due to the airline. Case to check: The sample change record on the Modification of an Order page shows a Refund with old and new prices of zero and 100 due by the airline, in currency XSD against prices in USD; no penalty or forfeit explains it. A Reusable cancellation (EXM_ORD_030E) shows every amount as zero, so the identity holds only if the value kept on the cancelled item counts as the new price.
Counterexample: a paid order at 1,000.00 cancelled with a request to keep the value for later use is typed Reusable with both amounts zero, where the formula gives 1,000.00 due by the airline (Lean example respendCancellation, after EXM_ORD_030E). Under the reading that waives a penalty above the refundable value, a cancellation of 1,000.00 with 20.00 forfeited and a 1,000.00 penalty has nothing due, where the formula gives 20.00 due to the airline (penaltyAboveRefund).
Open point: The equation holds in all eleven worked examples that settle money, but the guide never states it, and C-18 leaves the sign and the penalty term open. The business must adopt this formula, or another one, as the definition of the amount owed on a change.
Transferred originals hold no value1 card depends on it
A service transferred to a new item holds value only in the new item. The original copy, with status TRANSFERRED, holds no value, so its old item can be CANCELLED. Case to check: In EXM_ORD_003B after the change, ORDITM01 is CANCELLED while six of its services show TRANSFERRED with READY TO PROCEED. The same six service IDs appear in ORDITM02_NEW as READY TO PROCEED, so their value is counted twice.
Counterexample: a paid return trip changed to keep the outbound flight leaves the original item with the outbound service TRANSFERRED and READY TO PROCEED. Under both readings the original item is ACTIVE, and the outbound service holds value in both items (Lean example changeKeepingOutbound).
Open point: In the worked examples the original copy keeps delivery status READY TO PROCEED while its item is CANCELLED. C-05 judges value by delivery status alone, under which the cancelled item still holds value and meets the ACTIVE condition of C-06. The business must decide whether the TRANSFERRED status overrides the delivery status.
Cancellation offers stay within payments
A cancellation offer never makes the amount due by the airline larger than the payments received for the order.
Counterexample: an order at 1,000.00 with 300.00 received is cancelled through an offer priced from the order's price, with 1,000.00 due by the airline (Lean example partlyPaidCancellation).
Open point: the business must decide whether the refundable amount is capped at the payments received, and which route applies when some items are paid and others are not.
Cancelling leaves the customer owing nothing
On a cancellation whose forfeited amount is part of the old price, the amount due to the airline is no larger than the amount due by the airline, under both readings of a penalty above the refundable value.
Counterexample: a paid order at 1,000.00 with 20.00 forfeited, cancelled with a netted penalty of 1,000.00, leaves 20.00 due to the airline under the reading that collects the whole penalty (Lean example penaltyAboveRefund).
Open point: under the other reading the guarantee holds, but the due amounts no longer net to the formula of C-82. The business must decide whether a penalty is capped at the refundable value or the excess is collected.
Order balance after servicing
At every point in an order's life, payments minus refunds equal the prices of its live order items plus all recorded penalties plus all recorded forfeited amounts. Value store and reusable items count as live at their price. In EXM_ORD_030B, 1,000 paid minus 930 refunded equals a 50 penalty plus 20 forfeited. Case to check: In EXM_ORD_003C after acceptance and before payment, the old item is still ACTIVE at 1,000 and the new item is ACTIVE at 900 with 1,000 paid, so the equation fails until the old item stops counting. In the Modification of an Order illustration, payments total 3,100 while the new item shows a price of 3,000 against a quoted new price of 3,100.
Counterexample: a paid trip at 1,000.00 changed to a trip at 900.00 that keeps the outbound flight, with a 40.00 penalty and 120.00 forfeited, leaves 1,060.00 paid against 1,900.00 of live items plus 160.00 recorded, because the original item still holds value. The same change keeping nothing balances (Lean example changeBalance).
Open point: The ORDPEN and ORDFOR guidance requires that sellers can reconcile all order values against payments and refunds but gives no equation, and C-19 leaves balance undefined. The business must choose the equation and say how an accepted but unpaid change enters it.
Orders cancelled at once are closed
Under every reading of the guide, an order cancelled at once has every item CANCELLED and is CLOSED.
Counterexample: an unpaid trip whose inbound flight is still REQUESTED from the airline is cancelled at once. The outbound service is removed, but the delivery status table has no move from REQUESTED to REMOVED, so the inbound service stays REQUESTED and its item is not cancelled (Lean example unpaidCancellationWhileRequested). A service UNABLE TO DELIVER, such as one on a flight the airline cancelled, stays too.
Open point: the business must decide whether a REQUESTED or UNABLE TO DELIVER service can be cancelled, and to which delivery status; the question belongs to the table of moves between delivery statuses.
Delivery and fulfilment2
Orders whose services are all final are closed1 card depends on it
Under every reading of the guide, an order whose services have all reached a final delivery status is closed.
Counterexample: an order whose one flight is NOT CLAIMED after a no-show is not closed. Under a reading where NOT CLAIMED holds value the order stays opened for good, since no event leaves a final status; under one where it holds none the order has no status. An order whose one flight is FAILED TO DELIVER gives the same result.
Open point: the guide closes an order only when every service is DELIVERED or REMOVED. The business must decide whether an order closes once every service is final, which changes C-07, and whether EXPIRED, NOT CLAIMED and FAILED TO DELIVER hold value.
Payment before delivery starts
A service reaches READY TO PROCEED, READY TO DELIVER, IN PROGRESS or DELIVERED only after a payment for it succeeds. READY TO PROCEED means the airline has been paid for the service and the customer is entitled to it. Case to check: In the deferred-payment change example, transferred flight services stay READY TO PROCEED inside a new order item that is unpaid and carries a payment time limit, so the flight could be delivered while the item's balance is outstanding.
Counterexample: under a reading that allows delivery before payment, a CONFIRMED bag nobody paid for becomes DELIVERED when the provider reports it. Under a reading where an UNABLE TO DELIVER service returns to READY TO PROCEED once the constraint lifts, an unpaid flight stopped by a force majeure event comes back READY TO PROCEED and is then delivered.
Open point: The sources treat READY TO PROCEED as the payment gate and say a delivery notice to the provider does not by itself allow delivery to start, but they never forbid delivery from CONFIRMED. The business must make that rule, decide whether an UNABLE TO DELIVER service returns to the status it left or to READY TO PROCEED, and say what counts as paid for deposits, zero-amount commitments (C-12) and credit terms.
Offers, prices and conditions7
Every stage with rules has a rule in force
While a journey is in a stage for which an action has rules, a rule is in force for that action.
Counterexample: a journey paid at 10:00 on 1 January whose only flight change rule before departure starts on 2 January has no rule in force at 18:00 on 1 January, under either reading. Under the reading that expiration dates end rules, a rule whose effective and expiration dates are equal is never in force. The example noRuleInForce computes both.
Open point: what applies to a change or cancellation when no rule of the current stage is in force?
Guaranteed prices only on offers that can be accepted
Under every reading, an offer item's price is guaranteed only at instants at which the offer can still be accepted.
Counterexample: an offer valid until 12:00 whose flight's price guarantee also ends at 12:00. At 12:00 the offer is rejected as expired. Under the reading that a guarantee still holds at its instant, the price is guaranteed at that instant. The example guaranteeAtExpiry computes both.
Open point: does a price guarantee still hold at the instant its time limit names?
No order at a lapsed price
Under every reading, no order is created at the offered price while the price guarantee of one of the offer's items has lapsed.
Counterexample: an offer valid from 10:00 to 12:00 whose flight's price is guaranteed until 10:30, accepted at 11:59. Under the reading that keeps the offered price, the order is created with the flight at 300.00 EUR. The example lapsedGuaranteeAccepted computes both readings.
Open point: is acceptance after a lapsed price guarantee refused, sent back for a new offer, or honoured at the offered price?
No order item overdue at creation
No order item starts with a payment time limit before the order's creation.
Counterexample: an offer valid until 12:00 whose bag must be paid by 10:30, accepted at 11:00. The bag's order item must be paid half an hour before the order existed. The example fixedLimitBeforeCreation computes it.
Open point: is an acceptance after a fixed payment time limit refused, or does the order item get a new payment time limit?
Payment due at creation can be made
An order item whose offer item's payment time limit is a duration of zero can be paid at the instant the order is created.
Counterexample: a flight at 300.00 EUR with a payment time limit of zero, accepted at 11:00 and paid in full by card at 11:00. The order item's limit is 11:00, and the payment rule of ONE-304 rejects a payment made at or after the limit. The example zeroDurationPayment computes it.
Open point: is a payment made at the creation instant on time, or must it come with the request that creates the order?
Price total from its parts
A price's total equals its base amount plus surcharges, fees, the tax summary total and any consumption tax not already included. The base amount is stated after discounts: the pre-discount amount minus the discount, where a percentage discount is that share of the pre-discount amount. Case to check: In the Canadian example every HST line is marked as not included, yet each reports zero excluded tax. Adding the excluded tax raises the total by 58.78 CAD; trusting the zero totals leaves it unchanged.
Counterexample: a base of 452.15 with an HST line of 58.78 marked as not included and a stated total of excluded tax of zero, in US dollars since the model has no Canadian dollar. Taking the tax from the lines gives a total of 510.93; trusting the stated total gives 452.15. The example excludedTaxReadings computes both.
Open point: The source names the parts and gives one example that adds up (95.00 base and 20.00 tax give 115.00), but states no formula. The business must decide whether fees and surcharges sit inside the tax summary or add separately, whether a discount applies before taxes are computed, and whether excluded consumption tax adds to the total. The model states discounts as amounts, so a percentage discount and its rounding are not modelled.
Taxes on a non-refundable fare
Each tax, fee and charge on a price carries its own refund flag. When an unused item is cancelled under a rule that forfeits the fare, the customer is still owed the taxes, fees and charges flagged refundable.
Counterexample: a trip at 500.00 EUR with a refundable airport tax of 25.00 EUR, cancelled on 25 January under a rule that forbids cancellation, returns nothing; so does a cancellation after a no show. Under the reading that a refund marked full with a fixed amount of 1.00 EUR returns the fixed amount, the cancellation returns 1.00 EUR. The examples nonRefundableFareTaxes and fullMarkedWithAmount compute them.
Open point: The source gives refund flags per tax and per fee and refund rules per offer item, but never says how they combine. The business must decide whether a no-refund cancel rule also keeps refundable taxes, and whether a no show changes the answer.
Order creation and information9
History rebuilds every version6 cards depend on it
An order's history starts with the whole order at version 1, recorded as one addition, followed by one change group per later version. Applying the groups up to version n to version 1 gives the order as it was at version n, and applying all of them gives the order that retrieval returns. Case to check: Applied newest first, a group that removes an item in version 4 runs before the group that added it in version 3, and the item reappears in the rebuilt current order.
Counterexample: the airline adds a bag to an order at version 2 and removes it at version 3. Listed newest first and applied in that order, the removal runs before the bag was added, and the rebuilt order holds the bag that the current order does not (Lean example newestFirstHistory).
Open point: The guide lists change groups oldest first with each raising the version by one, while the ORDHIS capability page lists them newest first and says each group lowers the version. The business must fix the order, and decide whether a history request from version v includes the group that produced v.
Atomic order creation5 cards depend on it
A create request either produces one order holding every selected item, or produces no order and returns an error. This holds when the selection spans several offers. Case to check: A selection takes items from offer A, still valid, and offer B, expired at the request instant. An airline that creates an order from A alone leaves the customer with half of a trip chosen as a whole.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired).
Open point: The capability pages allow one order from several offers and do not say what happens when one of them has expired or fails validation. The business must decide whether the whole request fails or the valid offers go ahead. The model takes the answer as a parameter with two readings.
Order items match the selection2 cards depend on it
Creating an order yields exactly one order item for each selected offer item and none for the items left out. The new order's price is the sum of the selected items' prices. Case to check: C-02 and the theorem that the order price is the sum of the offer's items both range over the whole offer. A seller who leaves out an optional bag gets an order without the bag, and both statements as written fail.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired). The return flight the seller selected has no order item.
Open point: the business must decide whether a request with a rejected offer fails as a whole or goes ahead with the offers that pass (see C-64).
Order price is the sum of the selected items1 card depends on it
An order created from offers priced in one currency has a total in that currency, the sum of the prices of the selected items, under both readings.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired). The selected items cost 780.00 EUR.
Open point: the business must decide whether a request with a rejected offer fails as a whole or goes ahead with the offers that pass (see C-64).
Changes on a stale version are rejected
A change that carries a version other than the order's current version is rejected, under both readings.
Counterexample: two sellers read an order at version 3. The first seller's change moves it to version 4. The second seller's change still carries version 3, and under the reading where the airline applies it anyway, it is applied over a change its seller never saw (Lean example twoSellersOneVersion).
Open point: the guide permits an error on a mismatch and does not require one. The business must decide whether a mismatch always rejects the change and whether a change may be sent without a version.
Every order holds a mandatory item
Every accepted selection includes at least one item the offer marks mandatory.
Counterexample: an a la carte offer holds a flight and a seat and marks neither mandatory. A seller selects the seat alone, and the selection is accepted with no mandatory item and no flight (Lean example seatWithoutFlight).
Open point: the guidance asks for at least one mandatory item in each offer and exempts a la carte offers. The business must decide which selections are allowed from an offer that marks no item mandatory, and whether a seat or bag may be ordered without its flight.
One order per offer
An offer produces at most one order. A repeated create request for an offer that already produced an order returns the existing order or is rejected. Case to check: A create request times out at the seller and is sent again with a new transaction ID. Nothing in the sources stops the airline creating a second order from the same offer.
Counterexample: a seller sends a create request for the trip offer's flight and gets order ORD-5. The request is sent again after a timeout. Under the reading where the airline creates another order, the seller gets ORD-6 and the trip offer has produced two orders (Lean example repeatedRequest).
Open point: The guide says the airline checks that the offer is valid without listing the checks, and its retransmission ID for recovering a lost response is not tied to order creation. The business must decide whether creating an order uses up the offer and how a repeated request is recognized.
Order total from item prices
Prices are held on order items, and a stored total price at order level is deprecated. An order's total at any version is the sum of its current item prices. Case to check: Items from an offer priced in EUR and an offer priced in USD go into one order. Adding them fails under def:money-add, so the order has no total.
Counterexample: one create request selects a flight at 400.00 EUR from an offer priced in euros and a hotel transfer at 60.00 USD from an offer priced in US dollars. The order is created and has no total in any currency (Lean example twoCurrencies).
Open point: The sources do not say whether one order may hold items in more than one currency, which can happen when items come from several offers. The business must decide, since a mixed-currency total has no value under the current money rules.
Orders holding value stay accessible
An order is kept while it has an active item, under every reading of the guide and every count of months.
Counterexample: an order created on 2026-01-01 holds a flight removed with its value held for the customer and never used. On 2028-01-01 it still holds value under every reading, and the rule no longer requires it to be kept (Lean example storedValueNeverUsed).
Open point: the resolution requires nothing after 13 months from creation and from first usage, and defines neither term. The business must define an open item and first usage, and decide whether an order that still holds value must stay accessible.
Ancillaries, seats and bundles11
One passenger per seat10 cards depend on it
On a given flight, no seat is assigned to two passengers at once. A seat assignment holds a seat and the passenger segment it applies to, and the seat map marks each seat available or occupied. The model checks that a seat request keeps this true when it held before and the seat maps mark no held seat available. Case to check: The seat worked example selects 12B for PAX01 and 12C for PAX02. Nothing in the described rules refuses a request selecting 12B for both on SEG1. A segment flown on two legs with a change of aircraft has two seat maps, so one seat per segment is ambiguous.
Counterexample: two passengers on SEG1 hold no seats, and the seat map marks 12B available. One request chooses 12B for PAX01 and for PAX02. Both choices pass the seat map, and both passengers hold 12B (Lean example sameSeatTwice).
Open point: The source states no uniqueness rule. The business must decide whether uniqueness is checked within one order or across every order on the flight. It must also decide whether the unit is the passenger segment or the operating leg, since an assigned seat sits on a leg while referencing a segment.
A cancellable item can be cancelled1 card depends on it
An order item whose conditions allow cancellation can be cancelled by some request that names it.
Counterexample: in the same order, under the reading where a cancellation is refused until the seller names the dependents too, naming the flight alone is refused for the bag, and naming the flight and the bag is refused by the bag's conditions (Lean example refuseUntilNamedBlocks). The flight cannot be cancelled at all.
Open point: Should a dependent's conditions be able to stop its flight from being cancelled?
Dependents keep their own conditions1 card depends on it
A live service of an item whose conditions do not allow cancellation stays as it was.
Counterexample: in the same order, the extra bag's conditions do not allow cancellation. Under the reading where dependents are cancelled with the flight, cancelling the flight item cancels the bag (Lean example cancelFlightWithBag).
Open point: Whose conditions govern a dependent cancelled with its flight, and its refund: the dependent's own or the flight's?
No live dependent of a cancelled flight1 card depends on it
After a seller cancels a flight, no live service depends on it.
Counterexample: the add bag worked example as an order, a flight for PAX-1 and an extra bag on it in its own item. The seller cancels the flight item alone. Under the reading where dependents stay in place, the flight is cancelled and the bag stays confirmed (Lean example cancelFlightWithBag).
Open point: Should cancelling a flight cancel its bag and seat, be refused until the seller names them, or leave them in place?
A removal returns no more than the bundle price
Removing services from a bundle returns no more than the bundle price, under every reading.
Counterexample: the seat worked example's bundle, one order item at 1,000.00 EUR holding both passengers' flights and bags. Under stand-alone prices of 470.00 EUR a flight and 60.00 EUR a bag, removing every service returns 1,060.00 EUR (Lean example bundleShares).
Open point: How does a bundle price split among its services: by stated component prices, by stand-alone prices, or not at all?
Ancillary needs a flight service
A flight-related ancillary enters an order only together with a flight service for the same passenger and segment, either in the same acceptance or already in the order. A seat map requested for an offer requires the offer to hold a flight and be unexpired. The model proves the first sentence when services are added, under every reading of flight related. This node checks the stronger claim that it stays true for the life of the order: a paid change to an order item keeps a live flight for every live flight-related ancillary. The seat map request is not modelled.
Counterexample: an order holds a paid flight for PAX-1 on SEG-OUT and a paid bag for the same passenger and segment, each in its own item. A paid change moves PAX-1 to a flight on SEG-NEW. The old flight is cancelled and the bag stays confirmed on SEG-OUT with no flight (Lean example bagLeftByFlightChange).
Open point: The source states this as a purchase precondition and never defines flight related. The taxonomy tree gives one answer: codes under Flight (0064) are flight related and codes under Journey (319C), such as insurance, are not. The business must confirm that and say whether the rule holds for the life of the order or only at purchase.
Every ancillary reaches its flight
An ancillary of the order for the same passenger and segment as a flight service is counted as dependent on it, under either reading of the link.
Counterexample: in the seat example order, flights for PAX01 and PAX02 on SEG1, a bag for PAX01 that names its flight, and seats 12B and 12C that name no flight. By reference only the bag depends on PAX01's flight; through passenger and segment the bag and seat 12B do (Lean example seatWithoutReference). Under the reference reading a change to the flight reports no impact on the seat.
Open point: Which link defines the dependency: a reference to the parent, or the shared passenger and segment? And may an ancillary depend on another ancillary, such as a lounge pass on a premium seat?
Moved seats on the new flight
No seat moved by a flight replacement lands on a seat another passenger holds on the new flight.
Counterexample: PAX-1 holds a paid flight on SEG-1, paid seat 12C and a bag. The airline replaces the flight with one on SEG-2, where PAX-9 already holds 12C. Where every dependent moves, seat 12C moves and lands on PAX-9's seat; where seats are reshopped, only the bag moves (Lean example seatMovedOntoTakenSeat).
Open point: What happens to a seat when its flight is replaced: does it move, and to which seat, or is it refunded, stored or reshopped?
One order item per a-la-carte offer item
An a-la-carte offer item becomes exactly one order item, as every offer item does when an offer is accepted (C-02).
Counterexample: the add bag worked example's extra bag at 50.00 EUR a unit, chosen for PAX-1 on the outbound and inbound journeys at quantity 1. The one offer item becomes two order items of 50.00 EUR, and the bag costs 100.00 EUR (Lean example bagOverTwoJourneys).
Open point: Does one offer item become one order item, as the order structure says, or one per passenger and segment, as the worked example shows? And what is the unit of the unit price?
One seat per passenger per segment
A passenger holds at most one active seat assignment on each segment of an order. The model checks that a seat request keeps this true when it held before and the seat maps mark no held seat available. Case to check: A seller adds 14A for PAX01 on SEG1 through a second quote while 12B is still confirmed. Both seat items are ACTIVE, and the passenger holds two seats on one segment.
Counterexample: PAX01 holds 12B on SEG1, and the seat map marks 12C and 14A available. A second request chooses 14A for PAX01. It passes the seat map, and PAX01 holds 12B and 14A, each in its own order item (Lean example secondSeatSamePassenger).
Open point: The business must decide whether a passenger may hold extra seats, for comfort or for a large instrument, and how such a seat is represented. It must also decide whether choosing a new seat cancels the old seat item and with what refund.
Removing a whole bundle returns its price
Removing every service of a bundle, all of them live, returns the whole bundle price, under every reading.
Counterexample: the same bundle. Under a reading that gives no share to any service, removing PAX02's flight and bag returns nothing, and so does removing every service (Lean example bundleShares).
Open point: Does removing part of a bundle return part of its price, and does removing all of it return all of it?
Airline-initiated change9
Cancelled service in an active item
A service with status CANCELLED belongs to an order item with status CANCELLED. The model checks that a flight the airline cancels keeps this true when it held before. Case to check: In the flight cancellation worked example the second segment's flight and bag services become CANCELLED while their order item gets no status change.
Counterexample: a paid return trip whose inbound flight the airline cancels keeps its item ACTIVE, with the inbound flight and its bag CANCELLED, under both readings of value (Lean example cancelInboundFlight). When both flights are cancelled, the item is CANCELLED under the strict reading and stays ACTIVE under the cautious one, where UNABLE TO DELIVER holds value (cancelBothFlights).
Open point: The Order concept ties a CANCELLED service to a cancelled item, and the cancellation page treats cancelling some services of an item as a change. The flight cancellation example cancels one segment's services and leaves the item untouched, so the business must decide which model holds.
No live service is left on a cancelled flight
When the airline cancels a flight and does not move the customer to another one, no live service is left on that flight.
Counterexample: a paid return trip at 1,000.00 EUR whose bag on the inbound flight is still REQUESTED from the airline. When the airline cancels the inbound flight, the flight becomes CANCELLED with UNABLE TO DELIVER, and the bag stays REQUESTED and live, because the delivery status table has no move from REQUESTED to UNABLE TO DELIVER (Lean example cancelFlightWhileRequested).
Open point: The business must decide what delivery status a service takes when its flight is cancelled while it is REQUESTED, IN PROGRESS or SUSPENDED. The open point on the delivery status table asks the same question for every area.
Notices are resolved before departure
A notice that offers follow-up actions is resolved before the affected flight departs, even if the seller never answers.
Counterexample: a notice that offers Cancel with neither a time limit nor a consequence, like the guide's Cancel example, never lapses. A notice that offers Accept with Auto-acceptance and a time limit a day after departure lapses too late. Both are unresolved when the flight departs, under either reading (Lean example noticesAtDeparture).
Open point: The sources make the time limit and the consequence optional and do not tie the time limit to the departure. The business must decide what applies when either is missing, and whether the time limit must fall before the affected flight departs.
Original item kept while Accept is pending
While the seller's Accept of an airline change is pending, the original order item keeps the status it had.
Counterexample: a paid return trip at 1,000.00 EUR whose two flights the airline moves is at version 2 with its original item CANCELLED while Accept is pending, under the reading where the change takes effect at notice (Lean example itineraryReaccommodated).
Open point: The business must decide whether a change awaiting acceptance is provisional, and whether declining it restores the original item.
Paid status after re-accommodation
A service the airline creates to replace a paid service, with no price difference owed, starts with delivery status READY TO PROCEED. Case to check: If CONFIRMED is read as unpaid, a payment time limit could apply to a re-accommodated trip the customer already paid for in full.
Counterexample: a paid return trip at 1,000.00 EUR whose two flights the airline moves at no price difference gets a new item whose services have delivery status CONFIRMED (Lean example itineraryReaccommodated).
Open point: The itinerary worked example gives such services delivery status CONFIRMED, which the Order concept reserves for services still awaiting payment, although the exchange is even. The business must decide whether paid status carries across an airline-initiated change.
Penalty when declining an airline change
A customer who declines an airline-initiated change through the Cancel follow-up action pays no cancellation penalty. Case to check: In the itinerary change worked example the new order item carries a 50 EUR cancellation fee. Applying it to a Cancel follow-up charges the customer for the airline's own change.
Counterexample: a paid trip at 1,000.00 EUR that the airline moved to other flights, declined through Cancel under the reading where the airline's fees apply, is charged the 50.00 EUR cancellation fee and refunded 950.00 EUR (Lean example declineByCancel). A notice that pairs Accept with Auto-cancellation, left unanswered, leads to the same charge (autoCancellation).
Open point: The sources offer Cancel as a response to an airline change but never say whether penalties apply. The cancellation page covers only customer-initiated cancellation and leaves penalties to the airline.
Pending follow-up actions
A follow-up action the seller has not performed appears in every order view until it is resolved. Performing any one of the actions offered for a change resolves all of them. The model checks the second sentence for ContactAirline; order views are not modelled. Case to check: The itinerary example offers Accept, Cancel, Reshop and ContactAirline under one time limit with Auto-acceptance. The seller phones the airline, nothing in the order records it, and auto-acceptance fires.
Counterexample: the seller phones the airline two days before the time limit of the itinerary change notice. Under a reading where the order does not record contacting the airline, Auto-acceptance applies when the limit passes (Lean example contactThenAutoAccept).
Open point: The source says pending actions are shown but not when they stop being pending. The business must decide whether one response clears the rest, and whether ContactAirline, which happens offline, ever clears a pending Accept.
Price of reshopping after airline change
A customer who declines an airline-initiated change through the Reshop follow-up action pays no change fee. Case to check: The new item in the itinerary example carries a 40 EUR change fee. A natural reading charges it when the customer reshops away from flights the airline moved.
Counterexample: a paid trip at 1,000.00 EUR that the airline moved, reshopped to other flights at 1,000.00 EUR under the reading where the airline's fees apply, is charged the 40.00 EUR change fee (Lean example declineByReshop).
Open point: The guide says such a reshop may or may not lead to additional payment and gives no rule. The business must decide whether change fees and fare differences apply, and which alternatives the airline must offer.
Refund for a cancelled flight
When the airline cancels a flight and does not re-accommodate, the flight service and its dependent services become CANCELLED with delivery status UNABLE TO DELIVER. The customer is then owed a refund of the value of those services. Case to check: A two-segment item costs 1000 EUR and the airline cancels the second segment. The item stays ACTIVE because the first segment still holds value, and no rule returns any part of the 1000 EUR.
Counterexample: a paid return trip at 1,000.00 EUR whose inbound flight the airline cancels gets nothing back under the reading the worked example shows, while its item stays ACTIVE at the full price (Lean example cancelInboundFlight). A reading that refunds an equal share per flight returns 500.00 EUR.
Open point: The worked example offers no follow-up action and no refund, and no source says whether UNABLE TO DELIVER caused by the airline entitles the customer to money back. Because price is set per order item, the business must also decide how much of an item's price belongs to one cancelled segment.
Commission, accounting and settlement10
Settled and unsettled clearance amounts9 cards depend on it
For each clearance, the amounts settled across all clearings plus the amount still unsettled equal its agreed net clearance amount. A write-off removes exactly the amount still unsettled. Case to check: The sample clearing shows a partially settled clearance with net clearance amount 250.00 and 50.00 unsettled, beside a 200.00 clearance, with a total of 450.00. The total adds up only if 250.00 is the amount settled, so the agreed amount was 300.00 and appears nowhere.
Counterexample: under a reading where a clawed-back amount does not count as unsettled again, a clearance of 300.00 settled in full and then clawed back by 100.00 keeps 200.00 settled, with nothing unsettled. A later clearing cannot settle the 100.00.
Open point: In a clearing message the net clearance amount field carries the amount settled in that clearing, so the agreed amount travels nowhere. The business must decide where the agreed amount is kept and whether a clawed-back amount counts as unsettled again.
Money balance of an order3 cards depend on it
For each order, the total of successful payments equals the total refunded plus the paid value still held as liability plus revenue recognized plus forfeited amounts. With every term at zero or above, this yields the result that refunds never exceed payments. Case to check: A customer pays 100.00, cancels, and receives 90.00 because a 10.00 tax is non-refundable. Without a forfeited term the 10.00 is neither refunded, held nor earned, and the balance fails.
Counterexample: under the reading where accounting records a cancellation as the airline sends it, a flight paid at 100.00 and cancelled with a goodwill refund of 120.00 leaves 100.00 paid against 120.00 refunded. A refund of 100.00 with a penalty of 25.00 on the same flight leaves 100.00 paid against 125.00 refunded and recognized.
Open point: The sources send payments, refunds as negative payments, penalties and forfeited amounts to accounting but never state a balance. The business must decide whether forfeited non-refundable taxes form their own term, whether a value store counts as held liability, and whether the amounts reported at cancellation must add up to what was paid.
Net position per remittance date1 card depends on it
For each party and remittance date, the Clearance Manager adds the net clearance amounts of clearances where the party is payee and subtracts those where it is payer. A positive result makes the party a settlement payee for that amount and a negative one a remittance payer, and the results across all parties sum to zero. Case to check: A seller owes an airline 100.00 by settlement plan and 50.00 by EasyPay. If both enter the seller's net position, the seller is asked to remit 150.00 while the EasyPay provider also pays the 50.00.
Counterexample: a seller owes an airline 100.00 by settlement plan and 50.00 by EasyPay. Under the reading that leaves EasyPay out of the seller's position and keeps it in the airline's, the seller is a remittance payer for 100.00 and the airline a settlement payee for 150.00, and the positions sum to 50.00.
Open point: The netting rule does not say how EasyPay clearances enter it. The EasyPay provider pays them, so they are left out of the seller's remittance but included in the airline's settlement; the business must decide whether the provider counts as a party in the sum.
Clearing totals are never negative
The total of a clearing to a settlement payee is never negative, so a bank transfer to the payee can carry it.
Counterexample: a payee due 200.00 on one clearance with 300.00 clawed back on another has a clearing total of minus 100.00.
Open point: whether the payee then becomes a remittance payer or the clawback is carried forward to a later clearing.
No liability left at a final status
When a paid service reaches a final delivery status, none of the amount paid for it is held as a liability any more.
Counterexample: under a reading that keeps the amount paid for a no-show as a liability, a flight paid at 100.00 that ends NOT CLAIMED keeps 100.00 of liability on a service that can no longer change. Under a reading that does not recognize a penalty at cancellation, a flight paid at 100.00 and cancelled with a 25.00 penalty keeps the 25.00 as a liability, since no delivery will ever recognize it.
Open point: which final statuses earn revenue, which return the amount as a refund and which keep it, and when a penalty reported at cancellation is recognized.
One allocation for a short remittance
A short payment settles each clearance for the same amount under either source page.
Counterexample: a payer owes airline A 100.00 (older) and airline B 100.00 (newer) and pays 100.00. Under Remittance of Funds each airline receives 50.00; under Transfer of Funds A receives 100.00 and B nothing.
Open point: which allocation the Clearance Manager uses.
One clearance per payment commitment
Every clearance comes from one payment commitment, identified by the order ID and the payment ID, and each commitment has at most one accepted clearance. A payment split across two methods has two commitments and so two clearances. Case to check: The Clearance Manager decides each clearance in a request separately, so one half of a split payment can clear while the other is rejected, though C-13 says the payment fails unless every method succeeds. The source's own sample request also carries two different clearances under one clearance ID and accepts both.
Counterexample: two clearances for the same order and payment, both signed by both parties, with different clearance IDs, are both accepted when signed clearances are checked only for a repeated clearance ID.
Open point: The Clearance Manager checks for a repeated order and payment pair only when the clearance data is not signed by both parties; for signed data it checks only the clearance ID. The business must decide whether two signed clearances with different IDs for one payment are allowed.
Refunds within payments
Accounting never refunds more for an order than was paid for it.
Counterexample: under the reading where accounting records a cancellation as the airline sends it, a goodwill refund of 120.00 on a flight paid at 100.00 is recorded as it is.
Open point: whether a refund may exceed what was paid, for example as goodwill, and how the excess is accounted for.
Seller never pays for a refund
The clearance for a refund through the seller never has the seller paying the ORA: its amount is never negative.
Counterexample: a payment of 75.00 carried 7.50 of commission. Under the reading that recalls the commission in full, a refund of 5.00 gives a clearance of minus 2.50: the seller pays the ORA for the customer's refund.
Open point: how much commission is recalled on a partial refund.
Whole payment allocated
Under every reading and rounding, the amounts settled from a short payment add up to what was paid.
Counterexample: a payer owes three airlines 100.00 each and pays 100.00. Under the Remittance of Funds page each share is 33.333. Rounded down the airlines receive 99.99 in all; rounded up, 100.02.
Open point: how a proportional share is rounded and who receives the remainder.
In the model today
Offers and orders
Delivery transitions
The only allowed transitions are ready to delivered, ready to cancelled, and cancelled to refunded. Every other event is refused.
Order price is the sum of the items
When an offer is accepted, the order's price is exactly the sum of the offer's item prices.
Expired offers are rejected
An offer accepted at or after its expiry instant is rejected as expired.
Delivered services cannot be cancelled
The cancel event is refused for a delivered service, and no event moves a delivered service to cancelled.
Payments and refunds
Accepting a refund
A refund is accepted against a payment only if the refund amount does not exceed that payment's amount. The check looks at one refund at a time.
Refunds never exceed payments
If every refund was accepted against one of the order's payments, the total refunded does not exceed the total paid.
Counterexample: two refunds of 60.00 against one payment of 100.00 are each accepted and together return 120.00.
Open point: does the limit apply per refund, cumulatively per payment, or cumulatively per order, and is a refund above the amount paid ever allowed, for example as a goodwill credit?
Order structure and status
Order structure
An order holds one or more order items, and each order item holds one or more services. A service is for one passenger on one flight segment, and is the smallest part of an order that can be delivered on its own. Each service has a service status, such as CONFIRMED or TRANSFERRED, and a delivery status, such as READY TO PROCEED.
Source: EASD guide, Order.
Creating an order from an offer
Accepting an offer before it expires creates an order with one order item for each offer item, and one confirmed service for each passenger and segment of that item. The checks before creating the order are the same as in the pilot rule: expiry, then an empty offer, then mixed currencies.
Source: EASD guide, Order.
One order item per offer item
Accepting an offer creates exactly one order item for each offer item.
Source: EASD guide, Order.
One service per passenger and segment
Each order item created from an offer item holds one service for each passenger and flight segment of that offer item.
Source: EASD guide, Order.
Order item IDs are unique
Accepting an offer whose item IDs are distinct gives the order's items distinct IDs. Whether every change keeps them distinct belongs with the change rules (C-18).
Source: EASD guide, Order.
Services that hold value
Whether a service still holds value, decided by its delivery status. The source settles five statuses: CONFIRMED, READY TO PROCEED and REMOVED HOLD VALUE hold value, and DELIVERED and REMOVED do not. The model takes the answer for the other eight as a parameter, a reading of the guide, and a guarantee about value counts as proven only when it holds for every reading.
Open point: which of the other eight delivery statuses hold value, for example EXPIRED, NOT CLAIMED and SUSPENDED.
Source: EASD guide, Order.
Order item status
An order item is ACTIVE while at least one of its services holds value. It is CANCELLED once all its services are cancelled or transferred and none holds value. It is CLOSED once at least one service is delivered and every other service is delivered or removed.
Source: EASD guide, Order.
Active items are those holding value
An order item is marked active exactly when at least one of its services holds value.
Source: EASD guide, Order.
Cancelled items as the guide defines them
An order item is marked cancelled exactly when every service is cancelled or transferred and none holds value.
Source: EASD guide, Order.
Closed items as the guide defines them
An order item is marked closed exactly when at least one service is delivered and every service is delivered or removed.
Source: EASD guide, Order.
Active items are never closed
Under every reading of the guide, an active item is not closed.
Source: EASD guide, Order.
Active items are never cancelled
An active item is not cancelled.
Source: EASD guide, Order.
Each item has exactly one status
Every order item with a service has exactly one of the three statuses.
Counterexample: an item whose one service was delivered and then transferred meets the conditions for both CANCELLED and CLOSED. An item whose one service is SUSPENDED has no status at all under a reading where a suspended service holds no value.
Open point: which status wins when the conditions overlap, whether a delivered service may be transferred at all, and what status an item has when none of the conditions holds.
Source: EASD guide, Order.
Order status
An order is OPENED while at least one of its services holds value. It is CLOSED once all its items are closed or cancelled and all its services are delivered or removed.
Source: EASD guide, Order.
Opened orders are those holding value
An order is marked opened exactly when at least one of its services holds value.
Source: EASD guide, Order.
Closed orders as the guide defines them
An order is marked closed exactly when every item is closed or cancelled and every service is delivered or removed.
Source: EASD guide, Order.
New orders are opened
Under every reading of the guide, an order created from an offer whose items each have a passenger and a segment is opened and not closed.
Source: EASD guide, Order.
Orders are never both opened and closed
Under every reading of the guide, no order is both opened and closed.
Source: EASD guide, Order.
Every order is opened or closed
Every order with at least one service is opened or closed.
Counterexample: under a reading where an expired service holds no value, an order whose only service expired is neither opened nor closed.
Open point: whether EXPIRED and UNABLE TO DELIVER hold value, and whether an order with such a service should be closed.
Source: EASD guide, Order.
Offers, prices and conditions
Offer expiry ends other limits
Before an order exists, no price or inventory guarantee on an offer outlasts the offer's expiry. Once the offer's expiry instant has passed, both have lapsed too, unless an order was created from it. A payment time limit takes effect only once an order exists. Case to check: An offer item whose price guarantee ends an hour after the offer expires. A model that reads the guarantee field alone treats the price as guaranteed for an hour after the offer is gone.
Open point: The Offers page also keeps the other limits alive when an order was changed, while the Time Limits page names only order creation. The business must decide whether the expiry of a reshop offer ends limits that would apply to the existing order it changes.
Source: EASD guide, Offers; EASD guide, Time Limits.
Price guarantee at an instant
An offer item's price is guaranteed at an instant only when the item carries a price guarantee time limit and the instant is inside both that limit and the offer's expiry. With no such limit the price is unguaranteed. The offer's expiry on its own guarantees neither price nor inventory. Whether a limit's own instant is inside is a reading of the guide, which the model takes as a parameter. Case to check: An item whose price guarantee ends at the same instant as the offer. Accepted at that instant, the offer is rejected as expired, yet an inclusive reading of the guarantee still calls the price guaranteed. The source does not fix the boundary.
Source: EASD guide, Time Limits; EASD guide, Offers.
No price guarantee without a limit
Under every reading, an offer item with no price guarantee time limit has no guaranteed price at any instant.
Source: EASD guide, Time Limits.
Price guaranteed before its limit
Under every reading, an offer item's price is guaranteed at every instant before both its price guarantee time limit and the offer's expiry.
Source: EASD guide, Time Limits.
Inventory guaranteed before its limit
Under every reading, an offer item's inventory is guaranteed at every instant before both its inventory guarantee time limit and the offer's expiry.
Source: EASD guide, Time Limits.
Guarantee ending at its instant
Under the reading that a guarantee ends at its instant, an offer item's price is guaranteed only at instants at which the offer can still be accepted.
Source: EASD guide, Time Limits.
Guaranteed prices only on offers that can be accepted
Under every reading, an offer item's price is guaranteed only at instants at which the offer can still be accepted.
Counterexample: an offer valid until 12:00 whose flight's price guarantee also ends at 12:00. At 12:00 the offer is rejected as expired. Under the reading that a guarantee still holds at its instant, the price is guaranteed at that instant. The example guaranteeAtExpiry computes both.
Open point: does a price guarantee still hold at the instant its time limit names?
Source: EASD guide, Time Limits.
Accepting after the guarantee lapses
When a customer accepts an unexpired offer after an item's price guarantee has lapsed, the airline decides the order price for that item. The source recommends repricing into a new offer before payment. The model takes the answer as a parameter: the acceptance is refused and sent back for a new offer, or the order is created at the offered price. Case to check: thm:accept-price-eq-sum makes the order price equal the offer item prices. An offer with a 30 minute price guarantee accepted two hours later, one minute before expiry, is sold at a price the airline no longer stands behind.
Open point: The business must decide whether acceptance in this window is rejected, forces a reprice into a new offer, or creates the order at the offered price. If repricing at order creation is allowed, the order price can differ from the offer price.
Source: EASD guide, Time Limits; EASD guide, Pricing Offers.
Payment time limit at creation
An offer item states its payment time limit as a duration or as a fixed date and time. At order creation the order item's limit becomes the creation instant plus the duration, or the fixed date and time. A zero duration means payment is due at creation. Which form applies when an offer item states both is a reading of the guide, which the model takes as a parameter. Case to check: A fixed offer limit that falls before the order is created gives an order item that is overdue the moment it exists.
Open point: The source does not say which form wins if an offer item carries both, or how long an order item with no payment time limit may stay unpaid. The business must decide both.
Source: EASD guide, Time Limits.
Time limits of a new order
Accepting an offer whose items carry time limits runs the checks of ONE-001, then, under the reading that asks for a new offer, refuses the acceptance if an item's price guarantee has lapsed. Each order item takes its payment time limit and its price guarantee from its offer item.
Source: EASD guide, Time Limits.
New order matches ONE-001
An order created from a timed offer, without its time limits, is the order ONE-001 creates from the same offer, so every guarantee of ONE-001 holds for it.
Source: EASD guide, Time Limits.
Payment time limit from a duration
An order item created from an offer item whose payment time limit is stated only as a duration must be paid by the creation instant plus that duration.
Source: EASD guide, Time Limits.
Payment time limit from a fixed instant
An order item created from an offer item whose payment time limit is stated only as a fixed date and time must be paid by that instant.
Source: EASD guide, Time Limits.
Price guarantee carried into the order
Each order item keeps the price guarantee time limit of its offer item. This is the first half of C-27; moving limits after creation is not modelled.
Source: EASD guide, Time Limits.
No order after a lapse when repricing
Under the reading that asks for a new offer, no order is created while the price guarantee of one of the offer's items has lapsed.
Source: EASD guide, Pricing Offers.
No order at a lapsed price
Under every reading, no order is created at the offered price while the price guarantee of one of the offer's items has lapsed.
Counterexample: an offer valid from 10:00 to 12:00 whose flight's price is guaranteed until 10:30, accepted at 11:59. Under the reading that keeps the offered price, the order is created with the flight at 300.00 EUR. The example lapsedGuaranteeAccepted computes both readings.
Open point: is acceptance after a lapsed price guarantee refused, sent back for a new offer, or honoured at the offered price?
Source: EASD guide, Time Limits; EASD guide, Pricing Offers.
No order item overdue at creation
No order item starts with a payment time limit before the order's creation.
Counterexample: an offer valid until 12:00 whose bag must be paid by 10:30, accepted at 11:00. The bag's order item must be paid half an hour before the order existed. The example fixedLimitBeforeCreation computes it.
Open point: is an acceptance after a fixed payment time limit refused, or does the order item get a new payment time limit?
Source: EASD guide, Time Limits.
Payment due at creation can be made
An order item whose offer item's payment time limit is a duration of zero can be paid at the instant the order is created.
Counterexample: a flight at 300.00 EUR with a payment time limit of zero, accepted at 11:00 and paid in full by card at 11:00. The order item's limit is 11:00, and the payment rule of ONE-304 rejects a payment made at or after the limit. The example zeroDurationPayment computes it.
Open point: is a payment made at the creation instant on time, or must it come with the request that creates the order?
Source: EASD guide, Time Limits.
Restriction rule in force
Each change or cancel rule on an offer item belongs to one journey stage (before payment, before departure, after departure, no show) and starts at its effective date. At a given instant the rule in force is the one in the current stage with the latest effective date not after that instant. A rule stops when its stage ends or a later rule takes over. Whether a rule's expiration date also ends it is a reading of the guide, which the model takes as a parameter. Case to check: In the source example (payment 1 Jan 2019, departure 1 Feb 2019) the no-change rule described as 7 days before departure starts on 24 Jan, which is 8 days before. The text gives the middle fee as 1 CHF where the table and diagram give 60 CHF. Another example sets equal effective and expiration dates, so that rule is never in force.
Open point: The message examples also give rules an expiration date, which the stage and override reading never uses. The business must decide which governs, and what applies before the first effective date or in a gap between one rule's expiration and the next rule. The source also does not say which of two rules of a stage applies when they start at the same instant.
Source: EASD guide, Offer Restrictions; EASD guide, Offer Conditions and Restrictions.
Rule in force belongs to the current stage
The rule in force for an action at an instant is one of the rules for that action and for the stage the journey is in at that instant.
Source: EASD guide, Offer Restrictions.
Rule in force has started
The rule in force at an instant has its effective date at or before that instant.
Source: EASD guide, Offer Restrictions.
Latest started rule is in force
When rules for an action and the current stage have started, and have not expired where expiration dates end rules, one of them is in force, and none of them starts later than it.
Source: EASD guide, Offer Restrictions.
Expired rules are not in force
Under the reading that expiration dates end rules, the rule in force at an instant has not reached its expiration date.
Every stage with rules has a rule in force
While a journey is in a stage for which an action has rules, a rule is in force for that action.
Counterexample: a journey paid at 10:00 on 1 January whose only flight change rule before departure starts on 2 January has no rule in force at 18:00 on 1 January, under either reading. Under the reading that expiration dates end rules, a rule whose effective and expiration dates are equal is never in force. The example noRuleInForce computes both.
Open point: what applies to a change or cancellation when no rule of the current stage is in force?
Source: EASD guide, Offer Restrictions; EASD guide, Offer Conditions and Restrictions.
Voluntary change under the rule in force
A voluntary change is refused when the rule in force forbids it. When the rule allows it, the change goes to the airline's pricing of ONE-201 with the old and new prices, the rule's fee as the penalty and nothing forfeited. When no rule is in force, the decision says so.
Source: EASD guide, Offer Restrictions.
Forbidden changes are refused
A change the rule in force forbids is refused.
Source: EASD guide, Offer Restrictions.
Rule's fee is the penalty
A change the rule in force allows with a fee is quoted with that fee as its penalty.
Source: EASD guide, Offer Restrictions.
No fee, no penalty
A change the rule in force allows without a fee is quoted with no penalty.
Source: EASD guide, Offer Restrictions.
Voluntary change under a restriction
A voluntary change of a given type, such as flight or name, is rejected when the rule in force forbids it. When the rule allows it, the customer pays the rule's fee, or nothing if the rule states no fee, plus any fare difference. The model proves the payment for a fee no larger than the price of the items changed, when the seller does not ask to keep the value for later use. Case to check: The source example described as a no-show change with total loss of fare carries a name change rule with a 1 CHF fee and no stage, so its description and its data disagree on what the customer owes.
Open point: The source does not say what applies when no rule covers the current stage, or whether a fee marked approximate binds when the change is made. The business must choose a default for an uncovered stage and decide how an approximate fee is settled.
Source: EASD guide, Offer Restrictions; EASD guide, Offer Conditions and Restrictions.
Refund owed on voluntary cancellation
The cancel rule in force decides what a voluntary cancellation returns. A rule that forbids cancellation returns nothing. A rule that allows it returns a full or a fixed refund, paid to the original form of payment when the rule says so. Which amount a refund marked full and also given a fixed amount returns is a reading of the guide, which the model takes as a parameter. Case to check: Reading that example as the full item price and reading it as 1.00 CHF give two different refunds for the same rule.
Open point: One source example marks a refund as full and also gives a fixed amount of 1.00 CHF. The business must decide which governs when both are present, and how the rule's refund relates to the penalty netting in thm:c16-penalty-net.
Source: EASD guide, Offer Restrictions.
Forbidden cancellation returns nothing
A cancellation the rule in force forbids returns nothing.
Source: EASD guide, Offer Restrictions.
Full refund returns the whole price
A cancellation the rule in force allows with a full refund and no fixed amount returns the item's whole price.
Source: EASD guide, Offer Restrictions.
Fixed refund returns its amount
A cancellation the rule in force allows with a fixed refund not marked full returns that amount.
Source: EASD guide, Offer Restrictions.
Refund to the original form of payment
A cancellation the rule in force allows, with the refund sent to the original form of payment, is refunded to the original form of payment.
Source: EASD guide, Offer Restrictions.
Taxes on a non-refundable fare
Each tax, fee and charge on a price carries its own refund flag. When an unused item is cancelled under a rule that forfeits the fare, the customer is still owed the taxes, fees and charges flagged refundable.
Counterexample: a trip at 500.00 EUR with a refundable airport tax of 25.00 EUR, cancelled on 25 January under a rule that forbids cancellation, returns nothing; so does a cancellation after a no show. Under the reading that a refund marked full with a fixed amount of 1.00 EUR returns the fixed amount, the cancellation returns 1.00 EUR. The examples nonRefundableFareTaxes and fullMarkedWithAmount compute them.
Open point: The source gives refund flags per tax and per fee and refund rules per offer item, but never says how they combine. The business must decide whether a no-refund cancel rule also keeps refundable taxes, and whether a no show changes the answer.
Source: EASD guide, Taxes, Fees, and Charges; EASD guide, Fees; EASD guide, Offer Restrictions.
Totalling a price from its parts
A price stated with its parts is rejected when its amounts are not all in one currency or its discount is larger than the amount before discounts. Otherwise its base amount is the amount before discounts less the discount, its tax summary total is the sum of its entries, and its total adds the base amount, the surcharges, the fees, the tax summary total and the consumption tax not included in it. Whether that tax comes from the lines marked as not included or from the stated total of excluded tax is a reading of the guide, which the model takes as a parameter. Discounts are stated as amounts.
Source: EASD guide, Taxes, Fees, and Charges; EASD guide, Consumption Taxes.
Mixed-currency prices are rejected
A price with an amount in a currency other than that of its amount before discounts is rejected.
Discount above the base is rejected
A price whose discount is larger than its amount before discounts is never totalled.
Source: EASD guide, Discounts.
Base amount after discounts
A totalled price's base amount is its amount before discounts less its discount.
Source: EASD guide, Discounts.
Tax summary total from its entries
A totalled price's tax summary total is the sum of its entries.
Source: EASD guide, Taxes, Fees, and Charges.
Total from base, surcharges, fees and taxes
A totalled price's total is its base amount plus its surcharges, its fees, its tax summary total and the consumption tax not included in it, as the reading takes that tax, all in the price's currency.
Source: EASD guide, Taxes, Fees, and Charges.
Excluded tax from the lines
Under the reading that takes the excluded consumption tax from the lines, a totalled price adds the tax of every line marked as not included.
Source: EASD guide, Consumption Taxes.
Price total from its parts
A price's total equals its base amount plus surcharges, fees, the tax summary total and any consumption tax not already included. The base amount is stated after discounts: the pre-discount amount minus the discount, where a percentage discount is that share of the pre-discount amount. Case to check: In the Canadian example every HST line is marked as not included, yet each reports zero excluded tax. Adding the excluded tax raises the total by 58.78 CAD; trusting the zero totals leaves it unchanged.
Counterexample: a base of 452.15 with an HST line of 58.78 marked as not included and a stated total of excluded tax of zero, in US dollars since the model has no Canadian dollar. Taking the tax from the lines gives a total of 510.93; trusting the stated total gives 452.15. The example excludedTaxReadings computes both.
Open point: The source names the parts and gives one example that adds up (95.00 base and 20.00 tax give 115.00), but states no formula. The business must decide whether fees and surcharges sit inside the tax summary or add separately, whether a discount applies before taxes are computed, and whether excluded consumption tax adds to the total. The model states discounts as amounts, so a percentage discount and its rounding are not modelled.
Source: EASD guide, Taxes, Fees, and Charges; EASD guide, Fees; EASD guide, Discounts; EASD guide, Consumption Taxes.
Ancillaries, seats and bundles
Dependent service and its parent
A dependent service, such as a bag, seat or meal, belongs to a parent flight service for the same passenger on the same passenger segment. The order records the link either as a direct reference from the dependent service to its parent or only through the shared passenger and segment. The model records what each service is and the parent it names, by service reference, and takes the link as a reading of the sources. It counts dependents of flight services only. Case to check: In the seat worked example the seat services carry no reference to a flight service. A rule that follows direct references finds no dependents of the SEG1 flight service and so reports no impact when that flight changes.
Open point: The business must choose which link defines the dependency, and whether one ancillary may depend on another ancillary, such as a lounge pass on a premium seat. The impacted dependent services page shows a direct service reference, while the add ancillary worked examples link bags and seats only to the passenger segment.
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Customer Adds an Ancillary to Existing Order - Service list; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability; EASD guide, Shop for Ancillaries.
Dependents by reference
Under the reference reading, a service is a dependent of a flight service exactly when it is an ancillary of the order that names that flight service as its parent.
Dependents through passenger and segment
Under the passenger and segment reading, a service is a dependent of a flight service exactly when it is an ancillary of the order for the same passenger on the same segment.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
A flight is never a dependent
No flight service is counted as a dependent, under either reading.
Every ancillary reaches its flight
An ancillary of the order for the same passenger and segment as a flight service is counted as dependent on it, under either reading of the link.
Counterexample: in the seat example order, flights for PAX01 and PAX02 on SEG1, a bag for PAX01 that names its flight, and seats 12B and 12C that name no flight. By reference only the bag depends on PAX01's flight; through passenger and segment the bag and seat 12B do (Lean example seatWithoutReference). Under the reference reading a change to the flight reports no impact on the seat.
Open point: Which link defines the dependency: a reference to the parent, or the shared passenger and segment? And may an ancillary depend on another ancillary, such as a lounge pass on a premium seat?
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
Passenger and segment reach every ancillary
Under the passenger and segment reading, every ancillary of the order for the same passenger and segment as a flight service is counted as dependent on it.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Adding services to an order
A seller adds order items to an order. The request is refused if a flight-related ancillary in it has no live flight service for its passenger and segment, in the order or in the request. Which kinds of service are flight related is a reading of the sources. The taxonomy reading counts seats, bags, meals and lounge access and leaves out insurance.
Source: EASD guide, Shop for Ancillaries; EASD guide, Customer Adds an Ancillary to Existing Order.
An ancillary without its flight is refused
A request that adds a flight-related ancillary with no live flight service for its passenger and segment, in the order or in the request, is refused, under every reading of flight related.
Source: EASD guide, Shop for Ancillaries.
Added items follow the existing ones
An accepted request adds its order items after the existing ones, which stay as they were.
Source: EASD guide, Customer Adds an Ancillary to Existing Order.
Services that need no flight are added
A request with no flight-related ancillary is accepted, under every reading of flight related.
Source: EASD guide, Shop for Ancillaries.
Ancillary needs a flight service
A flight-related ancillary enters an order only together with a flight service for the same passenger and segment, either in the same acceptance or already in the order. A seat map requested for an offer requires the offer to hold a flight and be unexpired. The model proves the first sentence when services are added, under every reading of flight related. This node checks the stronger claim that it stays true for the life of the order: a paid change to an order item keeps a live flight for every live flight-related ancillary. The seat map request is not modelled.
Counterexample: an order holds a paid flight for PAX-1 on SEG-OUT and a paid bag for the same passenger and segment, each in its own item. A paid change moves PAX-1 to a flight on SEG-NEW. The old flight is cancelled and the bag stays confirmed on SEG-OUT with no flight (Lean example bagLeftByFlightChange).
Open point: The source states this as a purchase precondition and never defines flight related. The taxonomy tree gives one answer: codes under Flight (0064) are flight related and codes under Journey (319C), such as insurance, are not. The business must confirm that and say whether the rule holds for the life of the order or only at purchase.
Source: EASD guide, Shop for Ancillaries; IATA capability SHPANC; IATA capability SHPSTO; IATA capability ORDRE2; EASD guide, Customer Adds an Ancillary to Existing Order; EASD guide, Airline Taxonomy Codeset.
Cancelling a flight with ancillaries
When a flight service is cancelled, each service that depends on it ends up cancelled, kept, or flagged for the customer. The source shows a seller naming the flight item and the ancillary item together in one cancellation and gives no rule for a flight cancelled alone. The model cancels the live services of the named items, refuses an item whose conditions do not allow cancellation, and takes what happens to the dependents as a reading: they are cancelled with the flight, the request is refused until the seller names them, or they stay in place. An example shows each reading breaking one of three guarantees the business would expect, and Lean proves that each reading keeps the other two. The refund is not modelled. Case to check: In the add bag worked example the extra bag item says cancellation is not allowed. Cancelling the flight then either cancels the bag against its own condition or leaves a confirmed bag on a segment the passenger no longer flies. Included bags held as separate zero-priced items, which the ARMI guidance permits, face the same choice.
Open point: The business must decide whether cancelling a flight cancels its dependents automatically, is refused until the seller names them too, or leaves them in place. It must also decide whose conditions govern the refund of each cancelled dependent: the dependent's own or the flight's.
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer Adds an Ancillary to Existing Order - Service list; ARMI, General Guidance; EASD guide, Inform of Impacted Dependent Services.
Named items are cancelled
When a seller's cancellation is accepted, every named item is in the order with each live service that the delivery status table lets be removed CANCELLED with delivery status REMOVED, under every reading.
Items that may not be cancelled are refused
A request that names an item whose conditions do not allow cancellation is refused, under every reading.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Other services are kept
Every service outside the named items that is not a live dependent of a cancelled flight stays as it was, in the same item, under every reading.
No live dependent of a cancelled flight
After a seller cancels a flight, no live service depends on it.
Counterexample: the add bag worked example as an order, a flight for PAX-1 and an extra bag on it in its own item. The seller cancels the flight item alone. Under the reading where dependents stay in place, the flight is cancelled and the bag stays confirmed (Lean example cancelFlightWithBag).
Open point: Should cancelling a flight cancel its bag and seat, be refused until the seller names them, or leave them in place?
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Two readings leave no live dependent
Under the readings that cancel dependents with their flight or refuse until they are named, no live service depends on a flight the seller cancels.
Dependents keep their own conditions
A live service of an item whose conditions do not allow cancellation stays as it was.
Counterexample: in the same order, the extra bag's conditions do not allow cancellation. Under the reading where dependents are cancelled with the flight, cancelling the flight item cancels the bag (Lean example cancelFlightWithBag).
Open point: Whose conditions govern a dependent cancelled with its flight, and its refund: the dependent's own or the flight's?
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Two readings keep the dependents' conditions
Under the readings that refuse until dependents are named or leave them in place, a live service of an item whose conditions do not allow cancellation stays as it was.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
A cancellable item can be cancelled
An order item whose conditions allow cancellation can be cancelled by some request that names it.
Counterexample: in the same order, under the reading where a cancellation is refused until the seller names the dependents too, naming the flight alone is refused for the bag, and naming the flight and the bag is refused by the bag's conditions (Lean example refuseUntilNamedBlocks). The flight cannot be cancelled at all.
Open point: Should a dependent's conditions be able to stop its flight from being cancelled?
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Two readings let a cancellable item be cancelled
Under the readings that cancel dependents with their flight or leave them in place, an order item whose conditions allow cancellation is cancelled by a request that names it alone.
Dependents when a flight changes
When a flight is replaced, the system decides for each dependent service whether it moves to the new flight, is cancelled with its value refunded or stored, or must be reshopped. The source requires the effect to be stated and does not say which effect applies. The model states for each live dependent the effect a reading gives for its kind of service. A service that moves keeps its reference, and with it its details, on the new segment. Case to check: Moving paid seat 12C from SEG1 to a replacement flight where another passenger holds 12C breaks one passenger per seat. Moving it to a different seat may land on a seat with a different price point.
Open point: The business must give the effect for each service type. Seats are the hard case, because the seat number may not exist or may already be taken on the new flight.
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Shop For Replacement Services; IATA capability ORDRE2; EASD guide, Airline notifies Seller of changes to an Order.
Every dependent gets one effect
When a flight is replaced, the rule states one effect for each live dependent of it, in order, and for no other service.
The effect follows the kind of service
Each stated effect is the reading's effect for the kind of a live dependent of the replaced flight.
A moved service keeps its reference
A dependent whose effect is to move is put on the new segment, for the same passenger and under the same reference, CONFIRMED.
Moved seats on the new flight
No seat moved by a flight replacement lands on a seat another passenger holds on the new flight.
Counterexample: PAX-1 holds a paid flight on SEG-1, paid seat 12C and a bag. The airline replaces the flight with one on SEG-2, where PAX-9 already holds 12C. Where every dependent moves, seat 12C moves and lands on PAX-9's seat; where seats are reshopped, only the bag moves (Lean example seatMovedOntoTakenSeat).
Open point: What happens to a seat when its flight is replaced: does it move, and to which seat, or is it refunded, stored or reshopped?
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Seat Map and Availability.
Choosing seats
A seller chooses seats for passengers from the seat map of each segment, which marks seats available or occupied. A request is refused if a seat chosen is not marked available. Otherwise each seat becomes its own order item at the seat's price, holding one seat service for the passenger on that segment, with no reference to a flight service, as in the seat worked example. The rule checks each choice against the seat map only, which is all the guide describes.
Source: EASD guide, Seat Map and Availability; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
A seat the map does not offer is refused
A request that chooses a seat the seat map of its segment does not mark available is refused.
Each seat becomes its own order item
An accepted seat request keeps the existing order items and adds one item for each seat chosen, at the seat's price, holding one service for that passenger on that segment.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
One passenger per seat
On a given flight, no seat is assigned to two passengers at once. A seat assignment holds a seat and the passenger segment it applies to, and the seat map marks each seat available or occupied. The model checks that a seat request keeps this true when it held before and the seat maps mark no held seat available. Case to check: The seat worked example selects 12B for PAX01 and 12C for PAX02. Nothing in the described rules refuses a request selecting 12B for both on SEG1. A segment flown on two legs with a change of aircraft has two seat maps, so one seat per segment is ambiguous.
Counterexample: two passengers on SEG1 hold no seats, and the seat map marks 12B available. One request chooses 12B for PAX01 and for PAX02. Both choices pass the seat map, and both passengers hold 12B (Lean example sameSeatTwice).
Open point: The source states no uniqueness rule. The business must decide whether uniqueness is checked within one order or across every order on the flight. It must also decide whether the unit is the passenger segment or the operating leg, since an assigned seat sits on a leg while referencing a segment.
Source: EASD guide, Seat Map and Availability; IATA capability SHPSTA; IATA capability SHPSTO; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
One seat per passenger per segment
A passenger holds at most one active seat assignment on each segment of an order. The model checks that a seat request keeps this true when it held before and the seat maps mark no held seat available. Case to check: A seller adds 14A for PAX01 on SEG1 through a second quote while 12B is still confirmed. Both seat items are ACTIVE, and the passenger holds two seats on one segment.
Counterexample: PAX01 holds 12B on SEG1, and the seat map marks 12C and 14A available. A second request chooses 14A for PAX01. It passes the seat map, and PAX01 holds 12B and 14A, each in its own order item (Lean example secondSeatSamePassenger).
Open point: The business must decide whether a passenger may hold extra seats, for comfort or for a large instrument, and how such a seat is represented. It must also decide whether choosing a new seat cancels the old seat item and with what refund.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability; EASD guide, Seat Map and Availability.
A-la-carte offer item
An a-la-carte offer item is always optional and has a unit price, a set of eligible passengers and a set of eligible segments or journeys. It holds no flight service. Each service ordered from it applies to one passenger on one segment. The model records what the item sells, its unit price, and the eligible passengers and segments; a journey is given by its segments.
Source: EASD guide, Offers; IATA capability SHPANC; IATA capability SHPSTP.
Price of an a-la-carte selection
Choosing an a-la-carte item for a passenger with quantity q over n eligible segments creates one order item per passenger and segment. Each order item costs the unit price times q, so the selection costs the unit price times q times n. The model follows the add bag worked example: one order item for each passenger and segment chosen, each at the unit price times the quantity. Case to check: In the add bag worked example the seller selects a 50.00 bag with quantity 1 over two journeys, and the order gains two order items of 50.00, 100.00 in total. Reading quantity 1 as one charge gives 50.00. The example also creates two order items from one offer item, which contradicts C-02 as written. Each journey there has one segment, so it cannot separate per journey from per segment pricing.
Open point: The source calls the price a unit price without naming the unit. The business must decide whether the unit is per passenger per segment, per journey or per order, and how quantity multiplies it.
Source: EASD guide, Offers; EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Ineligible choices are refused
An a-la-carte choice that names a passenger or a segment the offer item does not list as eligible is refused.
Source: EASD guide, Offers.
One order item per passenger and segment
An accepted a-la-carte choice gives one order item for each passenger and segment chosen, each holding one service for that passenger on that segment.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Price of each a-la-carte order item
Each order item of an accepted choice costs the unit price times the quantity.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
Total of an a-la-carte choice
The order items of an accepted choice cost, in total, the unit price times the quantity times the number of passengers and segments chosen.
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list.
One order item per a-la-carte offer item
An a-la-carte offer item becomes exactly one order item, as every offer item does when an offer is accepted (C-02).
Counterexample: the add bag worked example's extra bag at 50.00 EUR a unit, chosen for PAX-1 on the outbound and inbound journeys at quantity 1. The one offer item becomes two order items of 50.00 EUR, and the bag costs 100.00 EUR (Lean example bagOverTwoJourneys).
Open point: Does one offer item become one order item, as the order structure says, or one per passenger and segment, as the worked example shows? And what is the unit of the unit price?
Source: EASD guide, Customer Adds an Ancillary to Existing Order - Service list; EASD guide, Order.
Value of one bundled service
When one service in a bundle is cancelled, removed or not delivered, the system must give it a share of the bundle price to compute any refund, stored value or price difference. The source prices a bundle only as a whole. The model takes a bundle as one order item holding several services, as on the bundles page, and the share of each service as a reading. The bundle keeps its price; repricing the rest is not modelled. Case to check: In the seat worked example one 1000.00 order item holds both passengers' flights and bags. The cancellation page removes a passenger by cancelling that passenger's services inside such an item and notes that the rest must be re-priced, with no rule for the removed share.
Open point: The business must decide how a bundle price splits among its services: by stated component prices, by stand-alone prices, or not at all, so that removing a part returns nothing.
Source: EASD guide, Bundles; EASD guide, Cancellation of Order Items; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
Removed services are cancelled
After an accepted removal the bundle keeps its reference and price, each named live service that the delivery status table lets be removed is CANCELLED with delivery status REMOVED, and every service that is not named is as it was.
A removal returns the services' shares
An accepted removal returns the sum of the shares of the named live services under the reading, in the bundle's currency.
Source: EASD guide, Bundles.
A removal returns no more than the bundle price
Removing services from a bundle returns no more than the bundle price, under every reading.
Counterexample: the seat worked example's bundle, one order item at 1,000.00 EUR holding both passengers' flights and bags. Under stand-alone prices of 470.00 EUR a flight and 60.00 EUR a bag, removing every service returns 1,060.00 EUR (Lean example bundleShares).
Open point: How does a bundle price split among its services: by stated component prices, by stand-alone prices, or not at all?
Source: EASD guide, Bundles; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
Removing a whole bundle returns its price
Removing every service of a bundle, all of them live, returns the whole bundle price, under every reading.
Counterexample: the same bundle. Under a reading that gives no share to any service, removing PAX02's flight and bag returns nothing, and so does removing every service (Lean example bundleShares).
Open point: Does removing part of a bundle return part of its price, and does removing all of it return all of it?
Source: EASD guide, Bundles; EASD guide, Cancellation of Order Items.
Order creation and information
Order version
An order's version starts at 1 and goes up by one for each group of changes, so the version is always one more than the number of change groups applied.
Source: EASD guide, Order Versioning.
Recording changes to an order
The airline keeps an order as created, at version 1, with the change groups applied since, oldest first. A change adds, replaces or removes an order item. Applying a group of changes applies each in turn, records the group and raises the version by one.
Source: EASD guide, Order Versioning.
New orders start at version 1
A new order is at version 1, with no change groups and an empty history.
Source: EASD guide, Order Versioning.
Each change group raises the version by one
Applying a group of changes applies it to the order, records it in the history and raises the version by one.
Source: EASD guide, Order Versioning.
Order retention
An order with an open item stays accessible for at least 13 months from creation. Once all its items reach a final status, it stays accessible for at least 7 more days. The model reads an open item as an active one, and takes how 13 months are counted on UTC instants as a parameter.
Source: IATA Resolution 797.
Orders kept 13 months from creation
An order with an active item is kept until 13 months after its creation, under every reading of the guide and every count of months.
Source: IATA Resolution 797.
Orders kept 7 days after their items are final
An order whose items have all become closed or cancelled is kept for 7 days after that, under every reading of the guide and every count of months.
Source: IATA Resolution 797.
Selecting items from an offer
An order is created from a selection of offer items. The selection must include every item the offer marks mandatory and name the passengers each selected item was built for; optional items may be left out. An item without a mandatory mark counts as optional. Case to check: An offer holds a flight item and a seat item and neither carries the mandatory mark. A seller orders the seat alone, and the order holds a seat service with no flight.
Open point: The guidance says each offer should have at least one mandatory item and exempts a la carte offers, so an offer can have none. The business must decide which selections are allowed then, such as a seat or bag without its flight, and whether an empty selection is rejected.
Source: IATA capability ORDCRE; IATA capability ORDWPM; ARMI, General Guidance; EASD guide, Order; IATA capability SHPANC; IATA capability SHPBND; EASD guide, Offers; ARMI, General Guidance.
Unknown items are rejected
A selection that names an item the offer does not hold is rejected.
Source: IATA capability ORDWPM.
Selections include the mandatory items
A selection that leaves out an item the offer marks mandatory is rejected.
Source: ARMI, General Guidance.
A selection takes the items it names
An accepted selection takes exactly the offer items whose references it names, and every reference it names is an item it takes.
Source: IATA capability ORDWPM.
Every order holds a mandatory item
Every accepted selection includes at least one item the offer marks mandatory.
Counterexample: an a la carte offer holds a flight and a seat and marks neither mandatory. A seller selects the seat alone, and the selection is accepted with no mandatory item and no flight (Lean example seatWithoutFlight).
Open point: the guidance asks for at least one mandatory item in each offer and exempts a la carte offers. The business must decide which selections are allowed from an offer that marks no item mandatory, and whether a seat or bag may be ordered without its flight.
Source: ARMI, General Guidance.
Offers with a mandatory item
When an offer marks at least one item mandatory, every accepted selection includes one.
Source: ARMI, General Guidance.
Order items match the selection
Creating an order yields exactly one order item for each selected offer item and none for the items left out. The new order's price is the sum of the selected items' prices. Case to check: C-02 and the theorem that the order price is the sum of the offer's items both range over the whole offer. A seller who leaves out an optional bag gets an order without the bag, and both statements as written fail.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired). The return flight the seller selected has no order item.
Open point: the business must decide whether a request with a rejected offer fails as a whole or goes ahead with the offers that pass (see C-64).
Source: EASD guide, Order; IATA capability ORDWPM.
Orders hold the selection when the whole request is checked
Under the reading that rejects the whole request, an accepted request becomes an order with one order item for each item selected from each offer and none for the items left out.
Source: EASD guide, Order; IATA capability ORDWPM.
Creating one order from several offers
A create request holds a selection from each of one or more offers. Each offer must be one the airline holds and not expired, each selection must be accepted, and each selected item must be priced in its offer's currency. The sources do not say what happens when one selection is rejected, so the model takes the answer as a parameter with two readings: the whole request is rejected, or the selections that pass go ahead. One order holds the items picked, and a request that picks nothing is rejected.
Source: IATA capability ORDCRE; IATA capability ORDWPM.
Order price is the sum of the selected items
An order created from offers priced in one currency has a total in that currency, the sum of the prices of the selected items, under both readings.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired). The selected items cost 780.00 EUR.
Open point: the business must decide whether a request with a rejected offer fails as a whole or goes ahead with the offers that pass (see C-64).
Source: EASD guide, Order; IATA capability ORDWPM.
Order price when the whole request is checked
Under the reading that rejects the whole request, an order created from offers priced in one currency has a total in that currency: the sum of the prices of the selected items.
Source: EASD guide, Order; IATA capability ORDWPM.
Requests that select nothing are rejected
A request that selects no item from any offer is rejected under both readings, since an order holds at least one item.
Source: EASD guide, Order.
Atomic order creation
A create request either produces one order holding every selected item, or produces no order and returns an error. This holds when the selection spans several offers. Case to check: A selection takes items from offer A, still valid, and offer B, expired at the request instant. An airline that creates an order from A alone leaves the customer with half of a trip chosen as a whole.
Counterexample: one create request at 11:30 UTC selects an outbound flight at 400.00 EUR from an offer valid until 12:00 UTC and a return flight at 380.00 EUR from an offer that expired at 11:00 UTC. Under the reading where the offers that pass go ahead, the order holds the outbound flight alone and costs 400.00 EUR (Lean example oneOfferExpired).
Open point: The capability pages allow one order from several offers and do not say what happens when one of them has expired or fails validation. The business must decide whether the whole request fails or the valid offers go ahead. The model takes the answer as a parameter with two readings.
Source: EASD guide, Create Order Without Payment; EASD guide, Create Order With Instant Payment; IATA capability ORDWPM.
Rejecting the whole request
Under the reading that rejects the whole request, a request that names an offer which has expired at the instant of the request is rejected, and no order is created.
One order per offer
An offer produces at most one order. A repeated create request for an offer that already produced an order returns the existing order or is rejected. Case to check: A create request times out at the seller and is sent again with a new transaction ID. Nothing in the sources stops the airline creating a second order from the same offer.
Counterexample: a seller sends a create request for the trip offer's flight and gets order ORD-5. The request is sent again after a timeout. Under the reading where the airline creates another order, the seller gets ORD-6 and the trip offer has produced two orders (Lean example repeatedRequest).
Open point: The guide says the airline checks that the offer is valid without listing the checks, and its retransmission ID for recovering a lost response is not tied to order creation. The business must decide whether creating an order uses up the offer and how a repeated request is recognized.
Source: EASD guide, Create Order Without Payment; EASD guide, Identifier Usage; EASD guide, Payload Attributes.
Repeated create requests
The airline records each order it creates with the offers it came from. A request that names an offer with an order is a repeated request. The sources are silent on what the airline does with it, so the model takes the answer as a parameter with three readings: return the existing order, reject the request, or create another order.
Source: EASD guide, Create Order Without Payment; EASD guide, Identifier Usage.
New orders are recorded against their offers
A request that names no offer with an order is created as a new order and recorded against every offer it names, under every reading.
Repeated requests get the existing order
Under the reading that returns the existing order, a repeated request is answered with an order recorded for one of the offers it names, and nothing new is recorded.
Repeated requests can be rejected
Under the reading that rejects repeated requests, a request that names an offer with an order is rejected.
Returning or rejecting repeats keeps one order per offer
Under the readings that return the existing order or reject the request, no offer ever appears in two recorded orders.
History rebuilds every version
An order's history starts with the whole order at version 1, recorded as one addition, followed by one change group per later version. Applying the groups up to version n to version 1 gives the order as it was at version n, and applying all of them gives the order that retrieval returns. Case to check: Applied newest first, a group that removes an item in version 4 runs before the group that added it in version 3, and the item reappears in the rebuilt current order.
Counterexample: the airline adds a bag to an order at version 2 and removes it at version 3. Listed newest first and applied in that order, the removal runs before the bag was added, and the rebuilt order holds the bag that the current order does not (Lean example newestFirstHistory).
Open point: The guide lists change groups oldest first with each raising the version by one, while the ORDHIS capability page lists them newest first and says each group lowers the version. The business must fix the order, and decide whether a history request from version v includes the group that produced v.
Source: EASD guide, Order History; EASD guide, Order Versioning; EASD guide, Historical Information on Orders; EASD guide, Retrieve an Order; IATA capability ORDHIS; EASD guide, Order History; EASD guide, Order Versioning; IATA capability ORDOC2.
The history lists each change group once
Under both readings, an order's history holds the order at version 1 and each change group once, labelled with the version it produced.
Source: EASD guide, Order History.
Oldest first, the history rebuilds the order
Under the reading that lists change groups oldest first, applying them in the order listed to the order at version 1 gives the order as it is now.
Source: EASD guide, Order History.
Change against a stale version
A change request may carry the order version the seller believes is current. The airline proceeds when it matches and may return an error when it does not, and a request without a version proceeds. Offers made while servicing an order carry the version they were built on. Case to check: Two sellers read version 3. The first change makes version 4. The second change still carries version 3, and because the guide only permits an error, the airline may apply it over a change its seller never saw.
Open point: The business must decide whether a version mismatch always rejects the change and whether a change without a version is allowed. It must also decide whether an offer built on an older version can still be accepted.
Source: EASD guide, Order Versioning; EASD guide, Order Versioning; IATA capability ORDOC2.
Changes on the current version are applied
A change that carries the order's current version is applied and raises the version by one, under both readings.
Source: EASD guide, Order Versioning.
Changes without a version are applied
A change that carries no version is applied, under both readings.
Source: EASD guide, Order Versioning.
Changes on a stale version are rejected
A change that carries a version other than the order's current version is rejected, under both readings.
Counterexample: two sellers read an order at version 3. The first seller's change moves it to version 4. The second seller's change still carries version 3, and under the reading where the airline applies it anyway, it is applied over a change its seller never saw (Lean example twoSellersOneVersion).
Open point: the guide permits an error on a mismatch and does not require one. The business must decide whether a mismatch always rejects the change and whether a change may be sent without a version.
Source: EASD guide, Order Versioning.
Rejecting stale versions
Under the reading that rejects stale versions, a change that carries a version other than the current one is rejected.
Source: EASD guide, Order Versioning.
Retention after first usage
Building on C-23, the offer responsible airline also keeps an order with an open item accessible for 13 months from its first usage. While an item is open, access is required until the later of 13 months from creation and 13 months from first usage. Case to check: An item whose services are REMOVED HOLD VALUE stays open with the customer's stored value for two years and is never used. After 13 months the resolution no longer requires access, so the order holding that value can be purged.
Open point: Resolution 797 does not define first usage or open item, and requires nothing for an order whose item is still open after both 13 month periods. The business must define both terms, decide how 13 months is counted on UTC instants, and decide whether order history follows the same periods.
Source: IATA Resolution 797.
Orders holding value stay accessible
An order is kept while it has an active item, under every reading of the guide and every count of months.
Counterexample: an order created on 2026-01-01 holds a flight removed with its value held for the customer and never used. On 2028-01-01 it still holds value under every reading, and the rule no longer requires it to be kept (Lean example storedValueNeverUsed).
Open point: the resolution requires nothing after 13 months from creation and from first usage, and defines neither term. The business must define an open item and first usage, and decide whether an order that still holds value must stay accessible.
Source: IATA Resolution 797.
Order total from item prices
Prices are held on order items, and a stored total price at order level is deprecated. An order's total at any version is the sum of its current item prices. Case to check: Items from an offer priced in EUR and an offer priced in USD go into one order. Adding them fails under def:money-add, so the order has no total.
Counterexample: one create request selects a flight at 400.00 EUR from an offer priced in euros and a hotel transfer at 60.00 USD from an offer priced in US dollars. The order is created and has no total in any currency (Lean example twoCurrencies).
Open point: The sources do not say whether one order may hold items in more than one currency, which can happen when items come from several offers. The business must decide, since a mixed-currency total has no value under the current money rules.
Source: ARMI, General Guidance; EASD guide, Order.
Change and cancellation
Cancelling an order
An unpaid order can be cancelled directly. A paid order is cancelled only by accepting a cancellation offer from the airline. The model cancels an order at once when no payment has been received for it, cancelling and removing every service the delivery status table lets be removed. Otherwise it prices a cancellation offer from the price of the items that still hold a live service, as a change whose new price is zero, so an item a change replaced is not refunded a second time.
Unpaid orders are cancelled at once
When no payment has been received for an order, a request to cancel it cancels and removes at once every service the delivery status table lets be removed, and the order keeps its items.
Orders cancelled at once are closed
Under every reading of the guide, an order cancelled at once has every item CANCELLED and is CLOSED.
Counterexample: an unpaid trip whose inbound flight is still REQUESTED from the airline is cancelled at once. The outbound service is removed, but the delivery status table has no move from REQUESTED to REMOVED, so the inbound service stays REQUESTED and its item is not cancelled (Lean example unpaidCancellationWhileRequested). A service UNABLE TO DELIVER, such as one on a flight the airline cancelled, stays too.
Open point: the business must decide whether a REQUESTED or UNABLE TO DELIVER service can be cancelled, and to which delivery status; the question belongs to the table of moves between delivery statuses.
Penalty netted or charged separately
A cancellation penalty is either deducted from the refund or charged separately, and the customer's net amount is the same either way. For example, with 625.00 refundable and a penalty of 100.00, the customer is 525.00 better off in both cases. The model proves the two ways equal for changes and cancellations, under both readings of a penalty larger than the refundable total (C-85).
Changing an order item
Changing an order item cancels the original item's services, creates a new item, and charges or refunds the difference in price. The model covers the change once it is paid: the services the change keeps move to the new item under the same references, their copies in the original item are marked TRANSFERRED with their delivery status unchanged, and the other services are cancelled and removed where the delivery status table lets them be, so a flight already flown stays DELIVERED. The money is priced by the price differential.
Open point: the source shows the difference only in a worked example, and does not define its sign or how penalties enter it.
Source: EASD guide, Modification of an Order.
Kept services keep their references
Every service a change keeps has a copy in the new item with the same reference, passenger, segment and delivery status.
Source: EASD guide, Modification of an Order.
Originals of kept services are transferred
Every service a change keeps stays in the changed item, marked TRANSFERRED, with its delivery status unchanged.
Source: EASD guide, Modification of an Order.
Services not kept are cancelled
Every service of the changed item that the change does not keep, and that the delivery status table lets be removed, is cancelled and removed.
Source: EASD guide, Modification of an Order.
Changes keep item references distinct
If an order's item references are distinct before a change, they are distinct after it. A change whose new item would reuse a reference is refused.
Source: EASD guide, Modification of an Order.
Price differential of a change
Every change or cancellation offer carries a price differential: the old price, the new price (zero for a cancellation), the penalties, the forfeited amounts, and two non-negative amounts, one due to the airline and one due by the airline. A type code names the outcome: EvenExchange, AddCol, Refund, Residual (a value store), Reusable, AddColAndRefund or AddColAndResidual.
Open point: The sign of the differential total is inconsistent. The Cancellation of Order Items page shows a refund with a positive total of 625.00, while the worked examples show refunds with negative totals, such as minus 1,000.00 in EXM_ORD_030A. The business must fix one sign rule, or model only the two non-negative due amounts. The model states only the two due amounts until the business decides.
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer requests a change to an Order containing a paid OrderItem; EASD guide, Customer requests a cancellation to paid Order or OrderItems; IATA capability ORDRSH; EASD guide, Price Differentials.
Amounts due to and by the airline
The price difference of a change is the new price, less the old price, plus the forfeited amount. With a netted penalty, the penalty charged is added to the difference, and the result is due to the airline when positive and by the airline when negative. With a separate penalty, the penalty charged is due to the airline on its own, and the difference is settled on its own. The worked examples fit this formula; the guide does not state it.
Source: EASD guide, Price Differentials.
Mixed currencies are rejected
A change whose prices, penalty and forfeited amount are not all in one currency is rejected unpriced.
Source: EASD guide, Modification of an Order.
Type code names a collection
A differential's type code is AddCol, AddColAndRefund or AddColAndResidual exactly when an amount is due to the airline.
Source: EASD guide, Price Differentials.
Type code names a refund or a value store
A differential's type code is Refund, Residual, AddColAndRefund or AddColAndResidual exactly when an amount is due by the airline.
Source: EASD guide, Price Differentials.
Value kept for later use is typed Reusable
When the seller asks to keep the value of cancelled items for later use, the differential is typed Reusable and both due amounts are zero.
Netted penalty gives one amount
With a netted penalty, the due amounts net to the price difference plus the penalty charged, and at most one of them is above zero.
Separate penalty is added to the amount due
With a separate penalty, the amount due to the airline is the penalty charged plus any price difference the customer pays, and the amount due by the airline is any price difference the airline returns.
Due amounts net to the difference
For every change or cancellation offer, the amount due to the airline minus the amount due by the airline equals the new price minus the old price, plus penalties, plus forfeited amounts. Netting of penalties or taxes changes how this net is split between the two due amounts and never changes the net. In EXM_ORD_003C, 900 minus 1,000 plus a 40 penalty plus 120 forfeited gives 60 due to the airline. Case to check: The sample change record on the Modification of an Order page shows a Refund with old and new prices of zero and 100 due by the airline, in currency XSD against prices in USD; no penalty or forfeit explains it. A Reusable cancellation (EXM_ORD_030E) shows every amount as zero, so the identity holds only if the value kept on the cancelled item counts as the new price.
Counterexample: a paid order at 1,000.00 cancelled with a request to keep the value for later use is typed Reusable with both amounts zero, where the formula gives 1,000.00 due by the airline (Lean example respendCancellation, after EXM_ORD_030E). Under the reading that waives a penalty above the refundable value, a cancellation of 1,000.00 with 20.00 forfeited and a 1,000.00 penalty has nothing due, where the formula gives 20.00 due to the airline (penaltyAboveRefund).
Open point: The equation holds in all eleven worked examples that settle money, but the guide never states it, and C-18 leaves the sign and the penalty term open. The business must adopt this formula, or another one, as the definition of the amount owed on a change.
Source: EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection due to penalty and forfeited amount; EASD guide, Customer requests a change of a paid order prior to travel resulting in a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Refund with a Forfeited amount incurred; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Refund with a Forfeited amount incurred and requiring payment of a penalty; EASD guide, Modification of an Order.
Collecting the whole penalty keeps the formula
Under the reading that collects the whole penalty, the due amounts net to the new price, less the old price, plus the penalty, plus the forfeited amount, whether the penalty is netted or charged separately.
Order balance after servicing
At every point in an order's life, payments minus refunds equal the prices of its live order items plus all recorded penalties plus all recorded forfeited amounts. Value store and reusable items count as live at their price. In EXM_ORD_030B, 1,000 paid minus 930 refunded equals a 50 penalty plus 20 forfeited. Case to check: In EXM_ORD_003C after acceptance and before payment, the old item is still ACTIVE at 1,000 and the new item is ACTIVE at 900 with 1,000 paid, so the equation fails until the old item stops counting. In the Modification of an Order illustration, payments total 3,100 while the new item shows a price of 3,000 against a quoted new price of 3,100.
Counterexample: a paid trip at 1,000.00 changed to a trip at 900.00 that keeps the outbound flight, with a 40.00 penalty and 120.00 forfeited, leaves 1,060.00 paid against 1,900.00 of live items plus 160.00 recorded, because the original item still holds value. The same change keeping nothing balances (Lean example changeBalance).
Open point: The ORDPEN and ORDFOR guidance requires that sellers can reconcile all order values against payments and refunds but gives no equation, and C-19 leaves balance undefined. The business must choose the equation and say how an accepted but unpaid change enters it.
Source: IATA capability ORDPEN; IATA capability ORDFOR; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection due to penalty and forfeited amount; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Refund with a Forfeited amount incurred; EASD guide, Modification of an Order; IATA capability PAYREF; EASD guide, Customer requests a change of a paid order prior to travel resulting in a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in full refund.
Money recorded on an order
An order records everything the customer paid, everything the airline returned, and every penalty and forfeited amount, at order level. Settling a change or cancellation offer adds its amount due to the airline to the payments, its amount due by the airline to the refunds, and its penalty and forfeited amount to those recorded. The live items are the order's active items.
Source: IATA capability ORDPEN.
Settling adds to payments and refunds
Settling an offer adds the amount due to the airline to the payments and the amount due by the airline to the refunds.
Source: IATA capability ORDPEN.
Settling records penalties and forfeits
Settling an offer adds its penalty and forfeited amount to those recorded on the order, and lowers no amount recorded before.
Source: IATA capability ORDPEN.
Penalty larger than the refund
With a netted penalty, the amount due by the airline is the refundable value of the cancelled items minus the penalty. The source has no case where the penalty is larger than the refundable value. Case to check: Take EXM_ORD_030B with a cancellation fee of 1,000 in place of 50. The refundable value is 980, so the netted result is 20 due to the airline on an offer typed Refund.
Open point: The business must decide whether a penalty is capped at the refundable value, so that cancelling never leaves the customer owing money, or whether the excess is collected. The model takes the answer as a parameter with two readings: collect the excess, or waive it.
Source: EASD guide, Cancellation of Order Items; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Refund with a Forfeited amount incurred.
Cancelling leaves the customer owing nothing
On a cancellation whose forfeited amount is part of the old price, the amount due to the airline is no larger than the amount due by the airline, under both readings of a penalty above the refundable value.
Counterexample: a paid order at 1,000.00 with 20.00 forfeited, cancelled with a netted penalty of 1,000.00, leaves 20.00 due to the airline under the reading that collects the whole penalty (Lean example penaltyAboveRefund).
Open point: under the other reading the guarantee holds, but the due amounts no longer net to the formula of C-82. The business must decide whether a penalty is capped at the refundable value or the excess is collected.
Waiving the excess penalty leaves nothing owing
Under the reading that waives a penalty above the refundable value, a cancellation never leaves the customer owing the airline money.
Paid or partly paid orders need an offer
An order with any payment, full or partial, is cancelled through a cancellation offer. Only an order with no payment at all may be cancelled directly. Case to check: Take an order priced 1,000 with 300 paid. The worked examples compute refundable value from the old price, which would show 1,000 due by the airline against 300 received and break the rule that refunds never exceed payments.
Open point: The EASD page speaks only of paid and unpaid orders; the partial case comes from ORDCA2. The business must decide which route applies when some items are paid and others are not, and whether the refundable amount is capped at the amount received.
Source: IATA capability ORDCA2; EASD guide, Cancellation of Order Items.
Cancellation offers stay within payments
A cancellation offer never makes the amount due by the airline larger than the payments received for the order.
Counterexample: an order at 1,000.00 with 300.00 received is cancelled through an offer priced from the order's price, with 1,000.00 due by the airline (Lean example partlyPaidCancellation).
Open point: the business must decide whether the refundable amount is capped at the payments received, and which route applies when some items are paid and others are not.
Source: IATA capability ORDCA2.
Transferred originals hold no value
A service transferred to a new item holds value only in the new item. The original copy, with status TRANSFERRED, holds no value, so its old item can be CANCELLED. Case to check: In EXM_ORD_003B after the change, ORDITM01 is CANCELLED while six of its services show TRANSFERRED with READY TO PROCEED. The same six service IDs appear in ORDITM02_NEW as READY TO PROCEED, so their value is counted twice.
Counterexample: a paid return trip changed to keep the outbound flight leaves the original item with the outbound service TRANSFERRED and READY TO PROCEED. Under both readings the original item is ACTIVE, and the outbound service holds value in both items (Lean example changeKeepingOutbound).
Open point: In the worked examples the original copy keeps delivery status READY TO PROCEED while its item is CANCELLED. C-05 judges value by delivery status alone, under which the cancelled item still holds value and meets the ACTIVE condition of C-06. The business must decide whether the TRANSFERRED status overrides the delivery status.
Source: EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection; IATA capability ORDRSH; EASD guide, Order; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a value store.
Airline-initiated change
Seller follow-up action
A change notice carries zero or more seller follow-up actions drawn from Accept, Reshop, Cancel, ContactAirline and RepriceAndAccept. Each may carry a time limit, a consequence of inaction, and an airline contact link. A notice with no follow-up action needs only acknowledgement. The model leaves out the contact link.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Notification of Airline Initiated Change to an Order.
Answering a change notice
A notice with no follow-up action needs only acknowledgement. A notice with follow-up actions stays pending until the seller takes one of the offered actions or a consequence of inaction applies. The first act of the seller that the order records, taken before any consequence applies, answers the notice, and answering one follow-up action resolves them all. Whether contacting the airline, which happens outside the order, counts as an answer is a reading of the sources.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Notification of Airline Initiated Change to an Order.
A notice without follow-up actions needs only acknowledgement
A change notice with no follow-up action asks the seller only to acknowledge it.
Source: EASD guide, Seller Follow-up Actions.
An offered action answers the notice
When the seller takes an offered Accept, Reshop, Cancel or RepriceAndAccept action before any consequence of inaction applies, the notice is resolved with one of the seller's acts, under every reading.
Source: EASD guide, Seller Follow-up Actions.
Answers are offered actions taken in time
A notice is resolved with an answer only when the seller took that action, the notice offers it, and the seller took it before any consequence of inaction applied.
Source: EASD guide, Seller Follow-up Actions.
Unanswered notices stay pending until they lapse
While no act of the seller answers a notice that offers follow-up actions, the notice is pending until a consequence of inaction applies, and is then resolved with that consequence.
Source: EASD guide, Seller Follow-up Actions.
Pending follow-up actions
A follow-up action the seller has not performed appears in every order view until it is resolved. Performing any one of the actions offered for a change resolves all of them. The model checks the second sentence for ContactAirline; order views are not modelled. Case to check: The itinerary example offers Accept, Cancel, Reshop and ContactAirline under one time limit with Auto-acceptance. The seller phones the airline, nothing in the order records it, and auto-acceptance fires.
Counterexample: the seller phones the airline two days before the time limit of the itinerary change notice. Under a reading where the order does not record contacting the airline, Auto-acceptance applies when the limit passes (Lean example contactThenAutoAccept).
Open point: The source says pending actions are shown but not when they stop being pending. The business must decide whether one response clears the rest, and whether ContactAirline, which happens offline, ever clears a pending Accept.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Airline notifies Seller of changes to an Order.
Recorded contact stops the time limit
Under a reading where the order records contacting the airline, a seller who contacts the airline before any consequence of inaction applies is never overtaken by one.
Source: EASD guide, Seller Follow-up Actions.
Consequence of a missed time limit
If a follow-up action carries a time limit and the seller has not acted by then, the airline applies the stated consequence. Auto-acceptance keeps the changed order and Auto-cancellation cancels it. The time limit and the consequence are both optional. The model applies the consequence of the follow-up action whose time limit passes first, and takes what applies when no consequence is stated as a reading of the sources. Case to check: The concept page pairs Accept with Auto-cancellation. A seller who misses the deadline then costs the customer the whole trip after a change the airline made.
Open point: The business must decide what applies when either the time limit or the consequence is missing (the Cancel example has neither), and what Auto-cancellation cancels and refunds. It must also decide whether the time limit has to fall before the affected flight departs.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Airline notifies Seller of changes to an Order; EASD guide, Inform of Impacted Dependent Services.
The earliest time limit decides the consequence
Once a time limit that carries a consequence of inaction has passed, a consequence applies: that of a follow-up action whose time limit is the earliest.
Source: EASD guide, Seller Follow-up Actions.
No time limit, no consequence
A notice none of whose follow-up actions has a time limit never has a consequence of inaction applied, under every reading.
Source: EASD guide, Seller Follow-up Actions.
No consequence before the time limits
Before every time limit of a notice, no consequence of inaction applies.
Source: EASD guide, Seller Follow-up Actions.
Notices are resolved before departure
A notice that offers follow-up actions is resolved before the affected flight departs, even if the seller never answers.
Counterexample: a notice that offers Cancel with neither a time limit nor a consequence, like the guide's Cancel example, never lapses. A notice that offers Accept with Auto-acceptance and a time limit a day after departure lapses too late. Both are unresolved when the flight departs, under either reading (Lean example noticesAtDeparture).
Open point: The sources make the time limit and the consequence optional and do not tie the time limit to the departure. The business must decide what applies when either is missing, and whether the time limit must fall before the affected flight departs.
Source: EASD guide, Seller Follow-up Actions.
Voluntary and involuntary change
An order change is voluntary when the customer requests it and involuntary when the airline imposes it. Resolution 797 commits One Order to support servicing, delivery and accounting for both kinds. The model takes which kinds of change are involuntary as a reading of the sources. A cancelled flight and a move to other flights count under every reading, and a change the customer made with the airline never does.
Open point: No source defines the two kinds. Change notices also carry changes the customer made directly with the airline, such as a name or contact update, so the business must decide which change reasons count as involuntary and trigger customer protections.
Source: IATA Resolution 797; EASD guide, Inform of Impacted Dependent Services; IATA capability ORDOC2; EASD guide, Airline notifies Seller of changes to an Order.
Declining an airline change
A customer who declines an airline change through Cancel, or whose seller lets it lapse into Auto-cancellation, has the affected order items priced as a cancellation. Through Reshop, they are priced as a change to the new items. The penalty is the item's cancellation or change fee. Whether the fees apply when the change is involuntary is a reading of the sources.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Cancellation of Order Items.
Cancel is priced as a cancellation
Declining an airline change through Cancel is priced as a cancellation of the affected order items, with a new price of zero.
Source: EASD guide, Seller Follow-up Actions.
Reshop is priced as a change
Declining an airline change through Reshop is priced as a change from the affected order items to the new items at their price.
Source: EASD guide, Seller Follow-up Actions.
Waived fees leave no penalty
Under the reading that waives the airline's fees on involuntary changes, declining an involuntary change carries no penalty, through Cancel or Reshop.
Source: EASD guide, Seller Follow-up Actions.
Penalty when declining an airline change
A customer who declines an airline-initiated change through the Cancel follow-up action pays no cancellation penalty. Case to check: In the itinerary change worked example the new order item carries a 50 EUR cancellation fee. Applying it to a Cancel follow-up charges the customer for the airline's own change.
Counterexample: a paid trip at 1,000.00 EUR that the airline moved to other flights, declined through Cancel under the reading where the airline's fees apply, is charged the 50.00 EUR cancellation fee and refunded 950.00 EUR (Lean example declineByCancel). A notice that pairs Accept with Auto-cancellation, left unanswered, leads to the same charge (autoCancellation).
Open point: The sources offer Cancel as a response to an airline change but never say whether penalties apply. The cancellation page covers only customer-initiated cancellation and leaves penalties to the airline.
Source: EASD guide, Seller Follow-up Actions; EASD guide, Inform of Impacted Dependent Services; EASD guide, Cancellation of Order Items; EASD guide, Airline notifies Seller of changes to an Order.
Price of reshopping after airline change
A customer who declines an airline-initiated change through the Reshop follow-up action pays no change fee. Case to check: The new item in the itinerary example carries a 40 EUR change fee. A natural reading charges it when the customer reshops away from flights the airline moved.
Counterexample: a paid trip at 1,000.00 EUR that the airline moved, reshopped to other flights at 1,000.00 EUR under the reading where the airline's fees apply, is charged the 40.00 EUR change fee (Lean example declineByReshop).
Open point: The guide says such a reshop may or may not lead to additional payment and gives no rule. The business must decide whether change fees and fare differences apply, and which alternatives the airline must offer.
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Seller Follow-up Actions; EASD guide, Airline notifies Seller of changes to an Order.
Cancelling a flight without re-accommodation
When the airline cancels a flight and does not move the customer to another one, every live service on that flight, in every order item, becomes CANCELLED with delivery status UNABLE TO DELIVER where the delivery status table allows the move. The table has no such move from REQUESTED, IN PROGRESS or SUSPENDED, so a service in one of those statuses stays live on a flight that will not operate. A service is live when it is neither cancelled nor transferred and not in a final delivery status. The services that depend on the flight, such as a bag on it, are services on the same segment. Order items keep their references and prices. What is refunded for each item is a reading of the sources.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Services on a cancelled flight are cancelled
Every live service on the cancelled flight that the delivery status table lets become UNABLE TO DELIVER is replaced, in the same order item, by the same service marked CANCELLED with delivery status UNABLE TO DELIVER.
Source: EASD guide, Airline notifies Seller of changes to an Order.
No live service is left on a cancelled flight
When the airline cancels a flight and does not move the customer to another one, no live service is left on that flight.
Counterexample: a paid return trip at 1,000.00 EUR whose bag on the inbound flight is still REQUESTED from the airline. When the airline cancels the inbound flight, the flight becomes CANCELLED with UNABLE TO DELIVER, and the bag stays REQUESTED and live, because the delivery status table has no move from REQUESTED to UNABLE TO DELIVER (Lean example cancelFlightWhileRequested).
Open point: The business must decide what delivery status a service takes when its flight is cancelled while it is REQUESTED, IN PROGRESS or SUSPENDED. The open point on the delivery status table asks the same question for every area.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Other flights are unchanged
Every service on another flight stays as it was, in the same order item.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Order items keep their references and prices
When the airline cancels a flight, the order keeps every order item, in the same order, with its reference and price.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Refunds stay within the item's price
Every refund for a cancelled flight is no more than the price of the order item it is for, under every reading.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Refund for a cancelled flight
When the airline cancels a flight and does not re-accommodate, the flight service and its dependent services become CANCELLED with delivery status UNABLE TO DELIVER. The customer is then owed a refund of the value of those services. Case to check: A two-segment item costs 1000 EUR and the airline cancels the second segment. The item stays ACTIVE because the first segment still holds value, and no rule returns any part of the 1000 EUR.
Counterexample: a paid return trip at 1,000.00 EUR whose inbound flight the airline cancels gets nothing back under the reading the worked example shows, while its item stays ACTIVE at the full price (Lean example cancelInboundFlight). A reading that refunds an equal share per flight returns 500.00 EUR.
Open point: The worked example offers no follow-up action and no refund, and no source says whether UNABLE TO DELIVER caused by the airline entitles the customer to money back. Because price is set per order item, the business must also decide how much of an item's price belongs to one cancelled segment.
Source: EASD guide, Airline notifies Seller of changes to an Order; EASD guide, Order.
Cancelled service in an active item
A service with status CANCELLED belongs to an order item with status CANCELLED. The model checks that a flight the airline cancels keeps this true when it held before. Case to check: In the flight cancellation worked example the second segment's flight and bag services become CANCELLED while their order item gets no status change.
Counterexample: a paid return trip whose inbound flight the airline cancels keeps its item ACTIVE, with the inbound flight and its bag CANCELLED, under both readings of value (Lean example cancelInboundFlight). When both flights are cancelled, the item is CANCELLED under the strict reading and stays ACTIVE under the cautious one, where UNABLE TO DELIVER holds value (cancelBothFlights).
Open point: The Order concept ties a CANCELLED service to a cancelled item, and the cancellation page treats cancelling some services of an item as a change. The flight cancellation example cancels one segment's services and leaves the item untouched, so the business must decide which model holds.
Source: EASD guide, Order; EASD guide, Cancellation of Order Items; EASD guide, Airline notifies Seller of changes to an Order.
Re-accommodation before the seller answers
When the airline moves a customer to other flights, it replaces the affected order item with a new item at the same price, holding a service for each passenger on each new flight, CONFIRMED with delivery status CONFIRMED as in the itinerary worked example. The replacement follows the change rule for a paid change. Whether it takes effect when the airline notifies it or once the seller accepts is a reading of the sources.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Change applied before seller response
An airline-initiated change takes effect in the order when it is notified, as the itinerary worked example shows. The version rises, replaced services are cancelled or transferred, and the new order item is ACTIVE while the seller's Accept is still pending. The model makes this one reading of the sources and proves it for that reading only: the order is the order after the change rule for a paid change, one version higher. Whether the original item is kept while Accept is pending is the open theorem Original item kept while Accept is pending. Case to check: In the itinerary example the original item is already CANCELLED at version 2 while Accept is pending. A customer who rejects the change cannot get the original flights back, so Accept offers no real choice.
Open point: This is shown only in a worked example. The business must decide whether a change awaiting acceptance is provisional, and whether declining it restores the original item or only lets the customer cancel or reshop from the changed order.
Source: EASD guide, Airline notifies Seller of changes to an Order; EASD guide, Seller Initiated Change to an Order.
A change awaiting Accept leaves the order as it was
Under the reading where a change waits for the seller's Accept, the order and its version are as they were when the change is notified.
Source: EASD guide, Airline notifies Seller of changes to an Order.
New flights for every passenger at the same price
When the change takes effect, the new order item has the original item's price and a service for each passenger of the original item on each new flight.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Original item kept while Accept is pending
While the seller's Accept of an airline change is pending, the original order item keeps the status it had.
Counterexample: a paid return trip at 1,000.00 EUR whose two flights the airline moves is at version 2 with its original item CANCELLED while Accept is pending, under the reading where the change takes effect at notice (Lean example itineraryReaccommodated).
Open point: The business must decide whether a change awaiting acceptance is provisional, and whether declining it restores the original item.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Waiting for Accept keeps the original item
Under the reading where a change waits for the seller's Accept, the original order item keeps its status when the change is notified.
Source: EASD guide, Airline notifies Seller of changes to an Order.
Paid status after re-accommodation
A service the airline creates to replace a paid service, with no price difference owed, starts with delivery status READY TO PROCEED. Case to check: If CONFIRMED is read as unpaid, a payment time limit could apply to a re-accommodated trip the customer already paid for in full.
Counterexample: a paid return trip at 1,000.00 EUR whose two flights the airline moves at no price difference gets a new item whose services have delivery status CONFIRMED (Lean example itineraryReaccommodated).
Open point: The itinerary worked example gives such services delivery status CONFIRMED, which the Order concept reserves for services still awaiting payment, although the exchange is even. The business must decide whether paid status carries across an airline-initiated change.
Source: EASD guide, Airline notifies Seller of changes to an Order; EASD guide, Order; EASD guide, Inform of Impacted Dependent Services.
Changes that require a customer choice
The airline may change departure times, flight numbers, aircraft, operating carrier or itinerary, or cancel a flight, and apply the change without the customer. For each change it decides whether to attach follow-up actions or send a notice only. In the model the airline chooses the follow-up actions of each notice, whatever the kind of change. Case to check: In the worked examples a 10-minute departure change and a change of operating carrier carry no follow-up action. A customer moved to another carrier has no recorded way to refuse.
Open point: The sources give no threshold. The business must decide which change types and sizes oblige the airline to offer Accept, Cancel or Reshop.
Source: EASD guide, Airline notifies Seller of changes to an Order; EASD guide, Notification of Airline Initiated Change to an Order.
Delivery and fulfilment
Delivery status
The thirteen delivery statuses of a service. A service is CONFIRMED while the airline waits for payment, becomes READY TO PROCEED once paid, and ends DELIVERED or in another final status. This replaces the four delivery states in the pilot model.
Source: EASD guide, Order; IATA capability ORDSTS.
Moves between delivery statuses
The moves a service may make between delivery statuses, read from the status definitions, the ORDSTS guidance and the worked examples. REQUESTED goes to CONFIRMED; CONFIRMED goes to READY TO PROCEED on payment; READY TO PROCEED goes to READY TO DELIVER, IN PROGRESS or DELIVERED; READY TO DELIVER goes to IN PROGRESS or DELIVERED; IN PROGRESS goes to DELIVERED or FAILED TO DELIVER. A service before delivery can be cancelled to REMOVED or REMOVED HOLD VALUE, or end EXPIRED, NOT CLAIMED, UNABLE TO DELIVER or FAILED TO DELIVER. REMOVED HOLD VALUE goes only to REMOVED. Any status that is not final can be suspended. Every other move is refused. The model takes the moves the sources leave undecided as a parameter, a reading of the sources: delivery of a CONFIRMED service before payment, the return of an UNABLE TO DELIVER service to READY TO PROCEED, and the cancellation or NOT CLAIMED end of a service IN PROGRESS. The table lets a READY TO PROCEED service go straight to DELIVERED, as the services in the Order Closing worked example do.
Open point: the sources show only some of these moves; the rest are inferred. The business must confirm the table, decide each undecided move, and decide how a declined REQUESTED service ends; the model has no move for it. The table also has no way to cancel a REQUESTED or UNABLE TO DELIVER service. Every area that cancels services goes through this table, so a service in either status stays as it was when its order, its item or its flight is cancelled. The sources also say that any status that is not final can be suspended and that REMOVED HOLD VALUE moves only to REMOVED. The model follows the second, so the business must say whether a REMOVED HOLD VALUE service can be suspended.
Source: EASD guide, Order; IATA capability ORDSTS; Order Accounting, Order Closing Example.
Confirming a requested service
Under every reading, a REQUESTED service the airline confirms becomes CONFIRMED.
Source: EASD guide, Order.
Payment readies a confirmed service
Under every reading, a CONFIRMED service whose payment succeeds becomes READY TO PROCEED.
Source: EASD guide, Order.
Delivering a paid service
Under every reading, a service that is READY TO PROCEED, READY TO DELIVER or IN PROGRESS becomes DELIVERED when it is delivered. READY TO DELIVER and IN PROGRESS may be skipped.
Source: IATA capability ORDSTS; Order Accounting, Order Closing Example.
Services that end without delivery
A service that is CONFIRMED, READY TO PROCEED or READY TO DELIVER ends REMOVED or REMOVED HOLD VALUE when it is cancelled, EXPIRED when its consumption time limit passes, NOT CLAIMED when the passenger prevents delivery, UNABLE TO DELIVER when legal, regulatory or force majeure constraints prevent it, and FAILED TO DELIVER when the airline or its provider fails to deliver it. A service IN PROGRESS can also end FAILED TO DELIVER. A REMOVED HOLD VALUE service becomes REMOVED once its value is refunded, stored or used.
Source: EASD guide, Order; IATA capability ORDSTS.
Cancellation before delivery
Under every reading, a service that is CONFIRMED, READY TO PROCEED or READY TO DELIVER becomes REMOVED when it is cancelled with none of its value kept, and REMOVED HOLD VALUE when the airline holds its value.
Source: EASD guide, Order.
Delivery prevented by outside constraints
Under every reading, a service that is CONFIRMED, READY TO PROCEED or READY TO DELIVER becomes UNABLE TO DELIVER when legal, regulatory or force majeure constraints prevent its delivery.
Source: EASD guide, Order.
Delivery failed by the airline or its provider
Under every reading, a service that is CONFIRMED, READY TO PROCEED, READY TO DELIVER or IN PROGRESS becomes FAILED TO DELIVER when the airline or its provider fails to deliver it.
Source: EASD guide, Order.
Suspending and resuming a service
A service's delivery record holds its delivery status and, while it is suspended, the status it left. The airline can suspend a service in any status that is not final, except REMOVED HOLD VALUE. Lifting the suspension returns the service to the status it left, and a suspended service can also be removed. Every other event follows the moves between delivery statuses.
Source: EASD guide, Order.
Ending a service from another area
A rule in another area that ends a service, such as a cancellation or a flight the airline cancels, applies its event through the delivery status table. When the table allows the move, the service takes the rule's service status and the delivery status the table gives. When the table refuses it, the service stays as it was. A service is live while it is neither cancelled nor transferred and not in a final delivery status.
Every area moves delivery statuses along the table
Under every reading, each rule that changes a service's delivery status moves it only along a move of the delivery status table and keeps its reference: cancelling an unpaid order, changing an order item, an airline change, cancelling order items, removing services from a bundle, the airline cancelling a flight, removing an unpaid item at its payment time limit, and a successful payment. A final delivery status therefore never changes, whichever area acts on the order.
Suspending a service records where it was
Under every reading, suspending a service that is REQUESTED, CONFIRMED, READY TO PROCEED, READY TO DELIVER, IN PROGRESS or UNABLE TO DELIVER makes it SUSPENDED and records the status it left.
Source: EASD guide, Order.
Lifting a suspension returns the service
Under every reading, lifting the suspension of a service returns it to the delivery status it had when it was suspended, whatever other events arrived in between.
Source: EASD guide, Order.
Cancelling a suspended service
Under every reading, a suspended service that is cancelled becomes REMOVED.
Source: EASD guide, Order.
Suspended services
A suspended service can only return to the status it had before it was suspended, or be removed.
Source: EASD guide, Order.
Other events follow the table
Under every reading, any event but a suspension follows the moves between delivery statuses for a service that is not suspended.
Source: EASD guide, Order.
Payment before delivery starts
A service reaches READY TO PROCEED, READY TO DELIVER, IN PROGRESS or DELIVERED only after a payment for it succeeds. READY TO PROCEED means the airline has been paid for the service and the customer is entitled to it. Case to check: In the deferred-payment change example, transferred flight services stay READY TO PROCEED inside a new order item that is unpaid and carries a payment time limit, so the flight could be delivered while the item's balance is outstanding.
Counterexample: under a reading that allows delivery before payment, a CONFIRMED bag nobody paid for becomes DELIVERED when the provider reports it. Under a reading where an UNABLE TO DELIVER service returns to READY TO PROCEED once the constraint lifts, an unpaid flight stopped by a force majeure event comes back READY TO PROCEED and is then delivered.
Open point: The sources treat READY TO PROCEED as the payment gate and say a delivery notice to the provider does not by itself allow delivery to start, but they never forbid delivery from CONFIRMED. The business must make that rule, decide whether an UNABLE TO DELIVER service returns to the status it left or to READY TO PROCEED, and say what counts as paid for deposits, zero-amount commitments (C-12) and credit terms.
Source: EASD guide, Order; IATA code set directory; EASD guide, Messages; IATA capability ORDDEL; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund.
Payment before delivery when the undecided moves are refused
Under every reading that refuses delivery before payment and keeps an UNABLE TO DELIVER service from returning to READY TO PROCEED, a service reaches READY TO PROCEED, READY TO DELIVER, IN PROGRESS or DELIVERED only after a payment for it succeeds.
Source: EASD guide, Order.
Final delivery statuses
DELIVERED, REMOVED, EXPIRED, NOT CLAIMED and FAILED TO DELIVER are final: no event moves a service out of them. Reaching one is the event the OMS reports to accounting. Case to check: Delivered services are still TRANSFERRED to new order items during a change, so finality can only constrain the delivery status; the service status and the containing item still change.
Open point: The accounting message names these five and leaves out UNABLE TO DELIVER, and the ORDSTS guidance only says the final status depends on the use case. The business must decide whether UNABLE TO DELIVER is final or can return to READY TO PROCEED once the legal or force majeure constraint lifts. The model leaves it out of the final statuses; under a reading where it cannot return, the only way out is to suspend the service and then remove it.
Source: EASD guide, Messages; IATA capability ORDSTS; EASD guide, Order; EASD guide, 25.4 Release Notes.
No event leaves a final status
Under every reading, no event moves a service out of DELIVERED, REMOVED, EXPIRED, NOT CLAIMED or FAILED TO DELIVER: not a delivery, a cancellation or a suspension.
Source: IATA capability ORDSTS.
Every service can reach a final status
Under every reading, a service that is not in a final delivery status can reach one through some sequence of events.
Source: IATA capability ORDSTS.
Closed orders keep their delivery statuses
Under every reading of the sources and of the guide, no event changes the delivery status of a service in a closed order.
Source: EASD guide, Order.
Orders whose services are all final are closed
Under every reading of the guide, an order whose services have all reached a final delivery status is closed.
Counterexample: an order whose one flight is NOT CLAIMED after a no-show is not closed. Under a reading where NOT CLAIMED holds value the order stays opened for good, since no event leaves a final status; under one where it holds none the order has no status. An order whose one flight is FAILED TO DELIVER gives the same result.
Open point: the guide closes an order only when every service is DELIVERED or REMOVED. The business must decide whether an order closes once every service is final, which changes C-07, and whether EXPIRED, NOT CLAIMED and FAILED TO DELIVER hold value.
Source: EASD guide, Order; EASD guide, Messages.
Held value after cancellation
A cancelled service moves to REMOVED HOLD VALUE while the airline keeps its value for reuse, and to REMOVED once that value is refunded, moved into a value store item, or used up by a paid change. The only move out of REMOVED HOLD VALUE is to REMOVED. Case to check: A reusable cancellation leaves the item ACTIVE and the order OPENED; if the customer never reuses the value and nothing moves the service to REMOVED, the order never closes.
Open point: The sources give three meanings: value the seller can reuse later, value held for further servicing, and value not yet refunded because the residual cannot yet be calculated. The business must pick one and decide whether held value expires and what status follows.
Source: EASD guide, Order; EASD guide, 24.1 Release Notes; IATA code set directory; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in a Reusable amount; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Value Store.
Expiry of an unclaimed service
A service with a consumption time limit moves to EXPIRED when the limit passes before the customer claims it, provided the service reached at least CONFIRMED. The OMS may set this automatically when the limit passes, and EXPIRED is final. The model has the move to EXPIRED as an event; it does not model the time limit itself. Case to check: An unpaid CONFIRMED service whose consumption window ends before its payment time limit would become EXPIRED and be reported to accounting as final, though no sale was ever posted for it.
Open point: The sources do not say whether an unpaid CONFIRMED service expires this way or is removed under its payment time limit, whether the limit runs while the service is SUSPENDED, or whether EXPIRED holds value. The code set lets an order close with EXPIRED services and the guide does not, so the business must choose.
Source: EASD guide, Order; IATA code set directory; EASD guide, Messages.
Passenger no-show
A service moves to NOT CLAIMED when the passenger's own action or inaction, such as a no-show, prevents delivery. NOT CLAIMED is final, and its report to accounting lets the airline recognize the revenue. Case to check: Under the French tax rule in the 19.1 release notes, a passenger who does not fly may be owed some taxes back; if NOT CLAIMED holds no value, the order can close with that refund unpaid.
Open point: The sources do not say when NOT CLAIMED is set (at departure, or once the passenger can no longer rebook), which status applies when EXPIRED also fits, or whether NOT CLAIMED holds value. The business must also decide how the No Show stage in cancel and change restrictions applies to such a service.
Source: EASD guide, Order; IATA code set directory; EASD guide, Messages; EASD guide, Offer Restrictions; EASD guide, 19.1 Release Notes.
Payment
Payment time limit
A confirmed service waits for payment until the payment time limit the airline gave the seller. In the model an order item carries its payment time limit, if it has one, and its order carries the payments made for it.
Open point: the source does not say what happens to the service when the limit passes without payment.
Source: EASD guide, Order.
Paying with several methods
Several payment methods can pay for one order item in a single payment. The payment succeeds only if every method succeeds; if any fails, the whole payment fails.
A failed method fails the payment
A payment is FAILED exactly when it has no payment method or the transaction of at least one of its payment methods failed.
A payment succeeds when every method succeeds
A payment is SUCCESSFUL exactly when it has at least one payment method and the transactions of all its payment methods succeeded.
A payment is pending while a method is pending
A payment is PENDING exactly when no method's transaction failed and at least one is still pending.
Amount charged across methods
The amounts charged across the methods cover the item's price plus any surcharges.
Open point: the source's example adds a card surcharge on top of the price and states no rule, so it is unclear whether an item paid in full means the price was paid or the price plus surcharges.
Paid order item
An order item is paid once the successful payments allocated to it, together with any value carried over from the item it replaced, cover its amount due. A PENDING payment does not count. After a change, the original payment stays on record and its allocation moves to the replacing item. The model counts an item paid once a SUCCESSFUL payment covers it, and checks the amounts when the payment is accepted. It does not model value carried over from a replaced item. Case to check: In the change worked example the new item costs 910.00 and the only payment made after the change is 60.00. The item is paid only if the 1000.00 payment made for the old item counts toward it.
Open point: The source speaks of unpaid, partly paid and paid items but never states the test. The business must decide whether surcharges count toward the amount due and how value carried over from a replaced item is counted.
Source: EASD guide, Order; IATA capability PAYORD; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; ARMI, General Guidance.
Only successful payments pay
An order item is counted paid exactly when a SUCCESSFUL payment covers it. PENDING and FAILED payments never count.
Source: IATA capability PAYORD.
Payment status and its moves
A payment transaction is PENDING, SUCCESSFUL or FAILED. SUCCESSFUL means the airline is certain to collect the funds, FAILED means it knows it will not, and PENDING means it cannot yet tell; a redirected payment starts PENDING and later moves to SUCCESSFUL or FAILED. The moment a payment becomes SUCCESSFUL is its payment commitment time. Case to check: A settlement plan payment is SUCCESSFUL at order time, then the seller remits only 75 percent and the platform marks the clearances Not Settled or claws them back. The order still shows the payment as SUCCESSFUL.
Open point: The source does not say whether SUCCESSFUL and FAILED are final. The business must decide whether a SUCCESSFUL payment can later fail, for example after a card chargeback or a seller's default on a settlement plan, and what then happens to the items it paid. The model takes the answer as a parameter, a reading of the guide that says which moves out of SUCCESSFUL and FAILED are allowed.
Source: EASD guide, Payment Codes; EASD guide, Payment Status; EASD guide, Pay Offline Using Redirection; Settlement with Orders, Enhanced and Simplified Distribution; Settlement with Orders, Remittance of Funds.
Outcomes of pending transactions are recorded
Under every reading of the guide, when the airline reports that a pending transaction succeeded or failed, the outcome is recorded.
Other methods keep their outcomes
Reporting the outcome of one method's transaction leaves the transactions of the payment's other methods as they were.
Settled payments under the final reading
Under a reading where no transaction leaves SUCCESSFUL or FAILED, a SUCCESSFUL or FAILED payment keeps its status whatever outcome is reported.
Source: EASD guide, Payment Status.
Settled payments keep their status
A SUCCESSFUL or FAILED payment keeps its status whatever outcome the airline later reports for one of its methods.
Counterexample: under a reading where a card chargeback turns a successful transaction into a failed one, a card payment for the trip goes from SUCCESSFUL to FAILED. Under a reading where a late redirected payment is recorded, a payment the airline marked FAILED at the time limit becomes SUCCESSFUL a minute later, while the trip it paid for stays removed.
Open point: whether a SUCCESSFUL payment can later fail, whether a FAILED payment can later succeed, and what then happens to the order items it covers.
Source: EASD guide, Payment Status; EASD guide, Pay Offline Using Redirection.
Applying a payment outcome
When a payment is SUCCESSFUL, every CONFIRMED service of the order items it covers moves to READY TO PROCEED and the items lose their payment time limits. A FAILED or PENDING payment changes nothing. The guide states these effects for redirected payments; the model applies them to a payment of any method.
Source: EASD guide, Pay Offline Using Redirection; EASD guide, Order.
Effects of a payment outcome
When a payment covering unpaid order items becomes SUCCESSFUL, every service in those items moves from CONFIRMED to READY TO PROCEED and the items lose their payment time limits. When it becomes FAILED, the service statuses and payment time limits stay as they were.
Open point: The source states both outcomes for redirected payments only. The business must confirm they apply to card and settlement plan payments, and decide what a successful payment that covers part of an item's amount does to its services.
Source: EASD guide, Pay Offline Using Redirection; EASD guide, Payment Via Redirection with Airline Notification of Payment Success; EASD guide, Order; EASD guide, Payment Via Redirection with Airline Notification of Payment Success; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund.
Paid items lose their payment time limits
After a SUCCESSFUL payment, no order item it covers has a payment time limit.
Failed and pending payments change nothing
A payment that is FAILED or PENDING leaves every order item, its services and its payment time limit as they were.
Items a payment does not cover are unchanged
A payment's outcome leaves the order items it does not cover as they were.
Time limit on unpaid items
Every order item that is unpaid or partly paid carries a payment time limit, and a paid item carries none. A time limit of zero on an offer item means the item must be paid when the order is created. Case to check: An order created without payment returns no time limit for one item. Under the second reading that item never expires and holds its seat with nothing paid. In the model the guarantee is that an unpaid item does not stay in the order indefinitely. That a paid item has no time limit is a theorem of the outcome rule.
Counterexample: an order whose trip was created without a payment time limit still holds the trip a year later, its flights confirmed and nothing paid.
Open point: The ARMI guidance expects the airline to set a limit on every unpaid item, while the EASD Time Limits page says a missing limit only means no advice was given. The business must decide whether an unpaid item may exist without a limit and, if so, whether it can stay unpaid indefinitely.
Source: IATA capability PAYORD; EASD guide, Time Limits; EASD guide, Create Order Without Payment; EASD guide, Pay Offline Using Redirection; IATA capability ORDWPM; EASD guide, Order.
Unpaid item at its time limit
When an order item's payment time limit passes without a successful payment, the item is removed from the order, and a payment still PENDING for it is marked FAILED. The airline may move the limit when it accepts a redirected payment as PENDING. Case to check: A customer completes a redirected card payment one minute after the limit. The airline has already marked the payment FAILED and removed the item, so the customer has paid for nothing unless the capture is refunded or the item restored.
Open point: This partly answers the open point of C-11: the Time Limits page says removal is expected but names no resulting statuses. The business must decide the delivery status after removal (REMOVED, REMOVED HOLD VALUE or EXPIRED) and what happens when a redirected payment is captured after the limit. The model cancels the removed item's services and takes the delivery status as a parameter, reached through the delivery status table.
Source: EASD guide, Time Limits; EASD guide, Pay Offline Using Redirection; EASD guide, 24.1 Release Notes.
Unpaid items are removed at their time limit
An order item whose payment time limit has passed, with no SUCCESSFUL payment covering it, is removed: its services take the statuses of the removal.
Source: EASD guide, Time Limits.
Pending payments fail at the time limit
When an order item is removed at its payment time limit, every payment covering it that was PENDING is FAILED afterwards.
Paid items are not removed
An order item that a SUCCESSFUL payment covers is never removed at a payment time limit.
Source: EASD guide, Time Limits.
Items before their time limit are unchanged
An order item whose payment time limit has not passed, or that has none, is left as it was.
Source: EASD guide, Time Limits.
Removal to REMOVED leaves no value
When the services of a removed item take the delivery status REMOVED, none of them holds value, under every reading of the guide.
Source: EASD guide, Order.
Removed items hold no value
An order item removed at its payment time limit holds no value: none of its services holds value afterwards.
Counterexample: when the removed trip's services become EXPIRED, the trip stays active under the cautious reading of the guide, where an expired service holds value. When they become REMOVED HOLD VALUE it stays active under every reading. With REMOVED it is cancelled under both readings.
Open point: which service status and delivery status an item takes when its payment time limit passes unpaid, and whether it then holds value.
Source: EASD guide, Time Limits; EASD guide, Order.
No payment at or after the time limit
A payment made at or after the payment time limit of an order item it covers is rejected. This is the time limit part of C-131; the price guarantee part waits on its open point.
Failed payment leaves items unpaid
One payment transaction may cover several order items with several payment methods. If any method's transaction fails, the whole payment fails and none of the items it covers becomes paid. Case to check: A seller who wants item 1 paid even when the card for item 2 is declined must send two payments. One combined payment leaves both items unpaid.
Source: EASD guide, Use of multiple payment methods to pay for a single item; EASD guide, Pay using multiple payment methods for a single item; EASD guide, Payment Simulation.
Surcharge on each payment method
Each method in a payment has a requested amount and a surcharge that depends on the method and that amount, and the amount charged to the method is the requested amount plus its surcharge. The requested amounts of one payment add up to the whole cost of the items it pays. Case to check: Reading paid in full as charged amounts equal to the price fails on the source's own example: a 100.00 item is paid with 20.00 by settlement plan and 82.00 by card, of which 2.00 is the card surcharge. This settles most of the open point of C-14.
Source: EASD guide, Payment Simulation; EASD guide, Use of multiple payment methods to pay for a single item.
Accepting a payment
The airline accepts a payment for order items only before their payment time limits, with every amount in the payment's currency, with any commitment method at zero and only for items with nothing to pay, and with requested amounts that add up to the items' price. Each method is then charged its requested amount plus its surcharge.
Source: EASD guide, Payment Simulation; EASD guide, Pay for an Existing Order; EASD guide, Commitment to pay when no amount due.
Each method is charged its amount plus its surcharge
An accepted payment charges each payment method its requested amount plus its surcharge, added as money in one currency.
Source: EASD guide, Payment Simulation.
Requested amounts add up to the price
An accepted payment's requested amounts add up to the price of the order items it covers.
Source: EASD guide, Payment Simulation.
Commitment only when nothing due
The commitment payment method always carries an amount of zero and may cover only items with nothing to pay or collect. Items with nothing due may also be covered by a normal payment for a payable item, and every item a payment covers, zero priced ones included, is listed on it.
Open point: The EASD guide added a commitment method in release 26.1, while the ARMI guidance and the change worked examples record the same commitment as an OT payment of zero. The business must pick one form and decide whether a zero OT payment counts when testing whether an item is paid.
Source: EASD guide, Commitment to pay when no amount due; EASD guide, 26.1 Release Notes; ARMI, General Guidance; EASD guide, Customer requests a change of a paid order prior to travel resulting in a refund.
Commission, accounting and settlement
Billing after delivery
A service provider does not bill the airline for a service before it has been delivered or consumed, unless the two have agreed otherwise.
Source: IATA Resolution 797.
Settlement value of a service
Each service in an order carries a settlement value for the provider that delivers it: the amount that provider may bill the ORA. The order holds this value from the moment it is created or changed, and financial processes read it from the order without recalculating it. Case to check: A partner's agreed settlement value of 120.00 for a segment sold inside a 100.00 bundled item makes the ORA pay out more than it collected; no source forbids this.
Open point: Resolution 797 uses the term without defining it. The business must decide whether the value is held per service or per order item, whether it includes taxes and fees, and whether a provider's settlement values may exceed the price of the item they sit in.
Source: IATA Resolution 797; Order Accounting, De-specializing Financial Processes; Order Accounting, Principles for Finance with Offer and Order.
Billing by service providers
A service provider's bill for a service is accepted when the provider delivers the service, the service counts as delivered or consumed or the provider has a bilateral agreement allowing earlier billing, and the total billed for the service stays within its settlement value. A delivered service counts and a service not yet delivered or cancelled does not. The model takes the answer for the other statuses, such as NOT CLAIMED and EXPIRED, as a parameter, a reading of the sources.
Source: IATA Resolution 797.
Billing limited to delivered services
At any time, the total a service provider has billed the ORA for an order is at most the sum of its settlement values for services in that order that have been delivered or consumed, unless a bilateral agreement allows earlier billing. The bound covers what the ORA pays providers; the seller's payment to the ORA is cleared within a day of payment and lies outside it. Case to check: A seat whose passenger did not show ends NOT CLAIMED. If that counts as consumed, the provider bills for a seat nobody used; if it does not, the provider can never bill for a seat it held. Lean proves the bound for each service, with each bill checked against the service's delivery status when the bill arrives.
Open point: The resolution says delivered and/or consumed without mapping the words to delivery statuses. The business must decide whether NOT CLAIMED (a no-show), EXPIRED, or a delivered service that is later refunded counts, and how a bilateral exception is recorded.
Source: IATA Resolution 797; Order Accounting, Principles for Finance with Offer and Order; Settlement with Orders, Clearance Overview.
Bills from the delivering provider only
Under every reading, a bill from a provider that does not deliver the service is refused.
Source: IATA Resolution 797.
Bills for delivered services accepted
Under every reading, a bill from the delivering provider for a DELIVERED service within what is left of its settlement value is accepted.
Source: IATA Resolution 797.
Accounting for paid services
Accounting holds the amount paid for a service as a liability until the service reaches a final delivery status. A DELIVERED service then earns its amount as revenue. For the other final statuses reached without cancellation the model takes as a parameter, a reading of the sources, whether the amount earns revenue, is refunded or stays a liability. A cancellation reports a refund, a penalty and a forfeited amount. Whether the penalty is recognized as revenue at cancellation is part of the reading. Whether a report whose three amounts do not add up to the amount paid is refused or recorded as the airline sends it is another parameter, a reading of the sources.
Source: IATA capability ACCSTS; Order Accounting, Service Consumption; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Amount Refunded with a Forfeited amount and a penalty with reporting to Accounting.
Revenue recognized at final status
Revenue for a paid service is recognized only after the airline reports to accounting that the service has reached a final delivery status. Until then the amount paid for it stays a liability. Case to check: A cancellation with a 25.00 penalty moves every service to CANCELLED and REMOVED. No service is delivered, so a rule keyed to delivery never recognizes the penalty.
Open point: The sources tie recognition to final delivery status but do not say which final statuses earn revenue. The business must decide, for DELIVERED, NOT CLAIMED, EXPIRED and REMOVED, whether each recognizes revenue, releases the liability as a refund, or keeps it, and when penalties and forfeited amounts reported at cancellation count as revenue.
Source: IATA capability ACCSTS; Order Accounting, Service Consumption; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Amount Refunded with a Forfeited amount and a penalty with reporting to Accounting; IATA Resolution 797; EASD guide, Messages; Order Accounting, Accounting messages.
Delivered services earn revenue
Under every reading, the amount paid for a DELIVERED service is recognized as revenue.
No liability left at a final status
When a paid service reaches a final delivery status, none of the amount paid for it is held as a liability any more.
Counterexample: under a reading that keeps the amount paid for a no-show as a liability, a flight paid at 100.00 that ends NOT CLAIMED keeps 100.00 of liability on a service that can no longer change. Under a reading that does not recognize a penalty at cancellation, a flight paid at 100.00 and cancelled with a 25.00 penalty keeps the 25.00 as a liability, since no delivery will ever recognize it.
Open point: which final statuses earn revenue, which return the amount as a refund and which keep it, and when a penalty reported at cancellation is recognized.
Source: IATA capability ACCSTS; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Amount Refunded with a Forfeited amount and a penalty with reporting to Accounting.
Money balance of an order
For each order, the total of successful payments equals the total refunded plus the paid value still held as liability plus revenue recognized plus forfeited amounts. With every term at zero or above, this yields the result that refunds never exceed payments. Case to check: A customer pays 100.00, cancels, and receives 90.00 because a 10.00 tax is non-refundable. Without a forfeited term the 10.00 is neither refunded, held nor earned, and the balance fails.
Counterexample: under the reading where accounting records a cancellation as the airline sends it, a flight paid at 100.00 and cancelled with a goodwill refund of 120.00 leaves 100.00 paid against 120.00 refunded. A refund of 100.00 with a penalty of 25.00 on the same flight leaves 100.00 paid against 125.00 refunded and recognized.
Open point: The sources send payments, refunds as negative payments, penalties and forfeited amounts to accounting but never state a balance. The business must decide whether forfeited non-refundable taxes form their own term, whether a value store counts as held liability, and whether the amounts reported at cancellation must add up to what was paid.
Source: Order Accounting, Customer requests a cancellation to paid Order or OrderItems; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Partial Amount Refunded with a Forfeited amount and a penalty with reporting to Accounting; Order Accounting, Customer requests a cancellation to paid Order or OrderItems resulting in Value Store; Order Accounting, Principles for Finance with Offer and Order.
Money balance when cancellation amounts are checked
Under every reading where the airline checks that a cancellation's refund, penalty and forfeited amount add up to the amount paid, an order's payments equal its refunds, plus the amount held as liability, plus the revenue recognized, plus the forfeited amounts.
Source: Order Accounting, Customer requests a cancellation to paid Order or OrderItems.
Refunds within payments
Accounting never refunds more for an order than was paid for it.
Counterexample: under the reading where accounting records a cancellation as the airline sends it, a goodwill refund of 120.00 on a flight paid at 100.00 is recorded as it is.
Open point: whether a refund may exceed what was paid, for example as goodwill, and how the excess is accounted for.
Source: Order Accounting, Customer requests a cancellation to paid Order or OrderItems.
Refunds within payments when cancellation amounts are checked
Under every reading where the airline checks that a cancellation's amounts add up to the amount paid, accounting never refunds more for an order than was paid for it.
Source: Order Accounting, Customer requests a cancellation to paid Order or OrderItems.
Checking a cancellation's amounts
Where the airline checks the amounts of a cancellation, a report whose refund, penalty and forfeited amount do not add up to the amount paid for the service is refused, under every reading of revenue.
Commission on an item
A commission on an item is either a fixed amount or a percentage of a stated base amount, and never both. An item may carry several commissions with different codes, such as a standard, a supplemental and an SwO clearance incentive, and the seller is owed their total. Case to check: In the guide's Italian VAT example the commission of 4.50 already includes 0.41 of tax. A seller reading 4.50 as net expects 4.95; one reading it as gross expects 4.50. The model adds the commissions and takes the rounding of a percentage as a parameter, a reading of the guide.
Open point: The guide says several commissions would be applied without saying they add. The business must decide how they combine, whether the percentage base is the fare alone or includes taxes and fees, how a percentage result is rounded, and whether a commission subject to consumption tax is stated gross or net of that tax.
Source: EASD guide, Commission and Margin; EASD guide, Consumption Taxes; Settlement with Orders, Codeset List; IATA capability PAYCOM.
Fixed commission
A fixed commission comes to its amount.
Source: EASD guide, Commission and Margin.
Percentage commission to within a cent
Under every rounding, a percentage commission comes to its share of the base, in the base's currency, less than one minor unit from the exact share.
Source: EASD guide, Commission and Margin.
Several commissions add up
Under every rounding, an item's commissions in its currency come to their total.
Source: EASD guide, Commission and Margin.
Commissions in another currency
Under every rounding, an item with a commission in another currency gets no total.
Source: EASD guide, Commission and Margin.
Percentage commission within its base
Under every rounding, a commission of no more than 100 percent of a base never comes to more than the base.
Source: EASD guide, Commission and Margin.
Net clearance amount
For each payment commitment, the net clearance amount is the money that moves between the ORA and the seller, with one of them as payer. When the seller collected the customer's money it is the payment amount minus the seller's commission and the seller pays; when the airline collected it, it is the commission and the airline pays. For a refund through the seller it is the refund minus the commission first paid on it, and the airline pays. Case to check: The source's refund example writes 7.50 minus 75.00, gets minus 67.50, and labels it a net settlement amount. Taken literally, the seller pays the airline for the customer's refund. The model takes how much commission a refund recalls as a parameter, a reading of the sources: none, all of it, or the share that matches the share of the payment refunded.
Open point: The standard defines the amount only as what the two parties agreed; the formulas come from worked examples. The business must decide whether the formula is fixed or open to agreement, and how commission is recalled on a refund, since the source recalls it only where the market allows and gives no rule for partial refunds.
Source: Settlement with Orders, Definitions; Settlement with Orders, Enhanced and Simplified Distribution; Settlement with Orders, Request for Clearance; Settlement with Orders, Settlement; Settlement with Orders, Process Overview; Settlement with Orders, Settlement.
Seller collects and nets the commission
A payment the seller collected, with the commission netted, gives one clearance in which the seller pays the ORA the payment amount less the commission.
Seller collects, commission cleared separately
A payment the seller collected, with the commission cleared separately, gives a clearance in which the seller pays the ORA the payment amount and one in which the ORA pays the seller the commission.
Source: IATA capability PAYCMT.
Airline collects
A payment the airline collected gives one clearance in which the ORA pays the seller the commission.
Source: Settlement with Orders, Enhanced and Simplified Distribution.
Refund through the seller
Under every reading, a refund through the seller gives one clearance in which the ORA pays the seller the refund less the commission recalled on it.
Source: Settlement with Orders, Settlement.
Refund clearances without full recall
Under a reading that recalls no commission, or the share of it that matches the share refunded, the clearance for a refund never has the seller paying the ORA.
Source: Settlement with Orders, Settlement.
Seller never pays for a refund
The clearance for a refund through the seller never has the seller paying the ORA: its amount is never negative.
Counterexample: a payment of 75.00 carried 7.50 of commission. Under the reading that recalls the commission in full, a refund of 5.00 gives a clearance of minus 2.50: the seller pays the ORA for the customer's refund.
Open point: how much commission is recalled on a partial refund.
Source: Settlement with Orders, Settlement.
Commission cleared exactly once
For each payment, the seller's commission is cleared exactly once: either netted inside the payment's net clearance amount or in a separate clearance in which the airline pays. Either way, the airline's net receipt for the payment is the payment amount minus the commission. Case to check: An EasyPay payment of 410.00 is authorized and cleared net at 369.00 after a 41.00 commission. If the airline also sends a separate 41.00 commission clearance, the seller receives the commission twice.
Source: IATA capability PAYCMT; Settlement with Orders, Request for Clearance.
Accepting a clearance
The Clearance Manager rejects a clearance whose clearance ID is already accepted, and one not signed by both parties whose order ID and payment ID are already accepted. It records every other clearance after those accepted before. Whether signed clearances are also checked for a repeated order and payment is a parameter, a reading of the sources.
One clearance per payment commitment
Every clearance comes from one payment commitment, identified by the order ID and the payment ID, and each commitment has at most one accepted clearance. A payment split across two methods has two commitments and so two clearances. Case to check: The Clearance Manager decides each clearance in a request separately, so one half of a split payment can clear while the other is rejected, though C-13 says the payment fails unless every method succeeds. The source's own sample request also carries two different clearances under one clearance ID and accepts both.
Counterexample: two clearances for the same order and payment, both signed by both parties, with different clearance IDs, are both accepted when signed clearances are checked only for a repeated clearance ID.
Open point: The Clearance Manager checks for a repeated order and payment pair only when the clearance data is not signed by both parties; for signed data it checks only the clearance ID. The business must decide whether two signed clearances with different IDs for one payment are allowed.
Source: Settlement with Orders, Enhanced and Simplified Distribution; Settlement with Orders, Remittance of Funds; Settlement with Orders, Clearance Manager; Settlement with Orders, Clearance Overview; Settlement with Orders, Clearance Sample Messages; Settlement with Orders, Codeset List; Settlement with Orders, Enhanced and Simplified Distribution; Settlement with Orders, Clearance Overview; Settlement with Orders, Remittance of Funds; Settlement with Orders, Settlement; Settlement with Orders, Cancellation Overview; Settlement with Orders, Definitions.
Repeated clearance ID
Under every reading, a clearance whose clearance ID is already accepted is rejected.
Repeated payment without signatures
Under every reading, a clearance not signed by both parties whose order ID and payment ID are already accepted is rejected.
Accepted clearances recorded
Under every reading, an accepted clearance is added after those accepted before, which stay as they were.
One clearance per payment when signed data is checked
Under every reading that checks signed clearances for a repeated order and payment too, each order and payment has at most one accepted clearance.
Clearance status
A submitted clearance is Accepted or Rejected, and a rejected one is not recorded. An accepted clearance is either Cancelled by the ORA or settled: Fully Settled at once, or first Not Settled or Partially Settled and later Final Settlement. A settled clearance can be Clawed Back, and one the Clearance Manager cannot collect is Written Off; EasyPay clearances show Funds Collected or Funds Partially Collected. Case to check: A clawed-back clearance is included again in a later clearing once the Clearance Manager collects the funds, so Claw Back cannot be final; a model that treats every settlement status as final refuses that move. The model moves a clearance's status and amounts on each event: a cancellation by the ORA, a clearing that pays part or all of what is unsettled, a clawback and a write-off. Whether a clawed-back clearance can be settled again, and whether Final Settlement can be clawed back, are a parameter, a reading of the sources. The EasyPay statuses are not modelled.
Open point: The code list names the statuses but gives no table of allowed moves and no final statuses. The business must decide, for example, whether a clawed-back clearance can be settled again once funds are collected, and whether Final Settlement can be clawed back.
Source: Settlement with Orders, Codeset List; Settlement with Orders, Financial and Accounting Systems; Settlement with Orders, Remittance of Funds; Settlement with Orders, Definitions.
Cancelling an accepted clearance
Under every reading, the ORA's cancellation marks an accepted clearance Cancelled, and every later event for it is refused.
Source: Settlement with Orders, Codeset List.
Settling a clearance in full
Under every reading, a clearing that pays all that is unsettled marks the clearance Fully Settled if it was Accepted and Final Settlement otherwise, and leaves nothing unsettled.
Source: Settlement with Orders, Codeset List.
Settling a clearance in part
Under every reading, a clearing that pays part of what is unsettled marks the clearance Partially Settled, and no clearing settles more than is unsettled.
Source: Settlement with Orders, Codeset List.
Writing off a clearance
Under every reading, a write-off removes exactly the amount still unsettled.
Total of a clearing
A clearing lists clearances with the amounts settled and clawed back in it. Its total is the amounts settled for clearances marked Fully Settled, Partially Settled or Final Settlement, less the amounts clawed back. A clearing to a remittance payer leaves EasyPay clearances out of its total.
Source: Settlement with Orders, Financial and Accounting Systems.
Clearing total
The total in a clearing to a settlement payee is the sum of the amounts settled for clearances marked Fully Settled, Partially Settled or Final Settlement, minus the amounts clawed back, and a separate bank transfer to the payee equals that total. In a clearing to a remittance payer, EasyPay clearances are listed but left out of the total, since the EasyPay provider pays them. Case to check: A payee is due 200.00 in the next clearing and has 300.00 clawed back. The formula gives minus 100.00, which a transfer to the payee cannot carry.
Open point: The source's sentence on clawbacks that exceed what a payee is due in the next clearing is unclear, and such a case makes the total negative. The business must decide whether the payee then becomes a remittance payer or the clawback is carried forward.
Source: Settlement with Orders, Financial and Accounting Systems; Settlement with Orders, Clearing Overview; Settlement with Orders, Remittance of Funds; Settlement with Orders, Transfer of Funds; Settlement with Orders, Clearing Sample Messages.
EasyPay out of a remittance payer's clearing
An EasyPay clearance listed in a clearing to a remittance payer adds nothing to its total.
Source: Settlement with Orders, Financial and Accounting Systems.
Clearing totals are never negative
The total of a clearing to a settlement payee is never negative, so a bank transfer to the payee can carry it.
Counterexample: a payee due 200.00 on one clearance with 300.00 clawed back on another has a clearing total of minus 100.00.
Open point: whether the payee then becomes a remittance payer or the clawback is carried forward to a later clearing.
Source: Settlement with Orders, Financial and Accounting Systems; Settlement with Orders, Transfer of Funds.
Net position of a party
A party's net position for a remittance date is the amounts of the clearances it is paid less the amounts of those it is netted as payer of. A positive position makes it a settlement payee, a negative one a remittance payer. An EasyPay clearance is left out of its payer's position; whether the EasyPay provider takes the payer's place is a parameter, a reading of the sources.
Net position per remittance date
For each party and remittance date, the Clearance Manager adds the net clearance amounts of clearances where the party is payee and subtracts those where it is payer. A positive result makes the party a settlement payee for that amount and a negative one a remittance payer, and the results across all parties sum to zero. Case to check: A seller owes an airline 100.00 by settlement plan and 50.00 by EasyPay. If both enter the seller's net position, the seller is asked to remit 150.00 while the EasyPay provider also pays the 50.00.
Counterexample: a seller owes an airline 100.00 by settlement plan and 50.00 by EasyPay. Under the reading that leaves EasyPay out of the seller's position and keeps it in the airline's, the seller is a remittance payer for 100.00 and the airline a settlement payee for 150.00, and the positions sum to 50.00.
Open point: The netting rule does not say how EasyPay clearances enter it. The EasyPay provider pays them, so they are left out of the seller's remittance but included in the airline's settlement; the business must decide whether the provider counts as a party in the sum.
Source: Settlement with Orders, Clearance Manager; Settlement with Orders, Remittance of Funds; Settlement with Orders, New for release 21.3.
Net position formula
Under every reading, a party's net position is the amounts it is paid less the amounts it is netted as payer of, on the remittance date.
Settlement payees
Under every reading, a party with a positive net position is a settlement payee for that amount.
Remittance payers
Under every reading, a party with a negative net position is a remittance payer for that amount.
EasyPay out of the payer's position
Under every reading, an EasyPay clearance is never netted against its payer.
Positions sum to zero with the EasyPay provider
Under the reading where the EasyPay provider takes the payer's place, the net positions of all parties on a remittance date sum to zero.
Settled and unsettled clearance amounts
For each clearance, the amounts settled across all clearings plus the amount still unsettled equal its agreed net clearance amount. A write-off removes exactly the amount still unsettled. Case to check: The sample clearing shows a partially settled clearance with net clearance amount 250.00 and 50.00 unsettled, beside a 200.00 clearance, with a total of 450.00. The total adds up only if 250.00 is the amount settled, so the agreed amount was 300.00 and appears nowhere.
Counterexample: under a reading where a clawed-back amount does not count as unsettled again, a clearance of 300.00 settled in full and then clawed back by 100.00 keeps 200.00 settled, with nothing unsettled. A later clearing cannot settle the 100.00.
Open point: In a clearing message the net clearance amount field carries the amount settled in that clearing, so the agreed amount travels nowhere. The business must decide where the agreed amount is kept and whether a clawed-back amount counts as unsettled again.
Source: Settlement with Orders, Financial and Accounting Systems; Settlement with Orders, Remittance of Funds; Settlement with Orders, Clearing Sample Messages; Settlement with Orders, Definitions.
Clawed-back amounts unsettled again
Under every reading where a clawed-back amount counts as unsettled again, a clearance's amounts settled less those clawed back, plus the amount unsettled and the amount written off, equal its agreed amount, whatever happens to it.
Allocating a short remittance
When a remittance payer pays short and the Clearance Manager has no credit line, the funds are split across the settlement payees in proportion to what each is owed. Within each payee, clearances are settled oldest first; the first one not fully covered is partially settled and the rest are Not Settled. Case to check: A payer owes airline A 100.00 (older) and airline B 100.00 (newer) and pays 100.00. The proportional rule gives each 50.00; the oldest-first rule gives A 100.00 and B nothing. The model takes the page followed as a parameter, a reading of the sources, and the rounding of a proportional share as another.
Open point: Another page says the Clearance Manager applies any payment to the payer's outstanding obligations in the order they were recorded, whatever the payee. The business must pick one allocation.
Source: Settlement with Orders, Remittance of Funds; Settlement with Orders, Transfer of Funds.
Short remittance within what is owed
Under every reading and rounding, no clearance is settled for more than the payer owes on it.
Each payee's clearances oldest first
Under every reading and rounding, a clearance to a settlement payee is settled only after every older clearance to that payee is settled in full.
Proportional shares
Under the Remittance of Funds page, each settlement payee's clearances are settled for its rounded proportional share, capped at what it is owed.
Oldest first across payees
Under the Transfer of Funds page, the payer's clearances are settled in the order they were recorded, whatever the payee.
Transfer of Funds allocates the whole payment
Under the Transfer of Funds page, a short payment is allocated in full.
Whole payment allocated
Under every reading and rounding, the amounts settled from a short payment add up to what was paid.
Counterexample: a payer owes three airlines 100.00 each and pays 100.00. Under the Remittance of Funds page each share is 33.333. Rounded down the airlines receive 99.99 in all; rounded up, 100.02.
Open point: how a proportional share is rounded and who receives the remainder.
One allocation for a short remittance
A short payment settles each clearance for the same amount under either source page.
Counterexample: a payer owes airline A 100.00 (older) and airline B 100.00 (newer) and pays 100.00. Under Remittance of Funds each airline receives 50.00; under Transfer of Funds A receives 100.00 and B nothing.
Open point: which allocation the Clearance Manager uses.
Source: Settlement with Orders, Remittance of Funds; Settlement with Orders, Transfer of Funds.
Next: candidate rules from the ONE Order survey
Order structure and status
Order items are not split
The price is held on the order item, and no operation changes part of an item. A change replaces whole items.
Source: EASD guide, Order.
Offers, prices and conditions
Order time limits only extend
When an order is created, the time left on an offer item's price guarantee carries into the matching order item. After that the airline may move the order item's price guarantee or payment time limit later and never earlier. Case to check: An order change that recomputes the payment time limit from the change instant with a shorter duration than the original would move the limit earlier.
Source: EASD guide, Time Limits.
Nesting of guarantee time limits
When an item has a price guarantee time limit, that limit is at or after every separate guarantee limit on its base amount, each tax and each fee. Those part limits count only when the overall limit is present. The price guarantee should also end no later than the payment time limit. Case to check: The source's table guarantees the base amount and one tax for 5 days in the order. If the order item's overall guarantee stays at the 30 minutes carried from the offer, the parts outlive the whole.
Open point: The source calls the overall limit the maximum of the parts, which reads either as equal to the latest part or as an upper bound, and the payment limit bound is only a recommendation. The business must pick one reading and decide whether a price guarantee past the payment limit is cut back or refused.
Source: EASD guide, Time Limits; EASD guide, Fees.
Tax summary total and detail
A tax summary's total equals the sum of its individual tax, fee and charge amounts, all in one currency. A shopping response may give only the total, but the order created from an accepted offer must hold the individual entries, including consumption tax detail. Case to check: An offer shopped with only a tax total and accepted without a pricing step has no entries to copy into the order. The source does not say where they come from or require them to add up to the shopped total.
Source: EASD guide, Taxes, Fees, and Charges; EASD guide, Consumption Taxes.
Consumption tax lines add up
In each consumption tax entry, the tax is the rate applied to the taxable base, and the entry's total tax is the sum of its line taxes. A gross amount equals its net amount plus every consumption tax charged on it. All amounts in an entry are in the price's currency. Case to check: Italian example: line tax 1.82 against entry total 1.80. Canadian example: line tax 0.93 against entry total 4.55. Australian example: gross in AUD with tax in EUR. Tahiti example: two taxes on one base, so a per-line check that gross equals net plus that line's tax fails.
Open point: The source shows these relations only through examples, several of which break them, and gives no rounding rule. The business must decide which figure is authoritative when a line and its total disagree, and how to round.
Source: EASD guide, Consumption Taxes.
Seller margin stays outside order
When the seller is merchant of record and adds a margin, the airline's order total equals the airline offer price including taxes, fees and charges. The order holds no record of the margin, and the seller pays the airline the offer price. Case to check: The source places the airline as merchant of record out of scope. In that case the payment recorded on the order would include the margin and exceed the order total, which a rule tying payments to the order total would reject.
Source: EASD guide, Commission and Margin.
Mandatory and optional offer items
Each offer item is mandatory or optional, and its services and price are fixed once offered. Accepting an offer takes every mandatory item whole plus the optional items chosen; a-la-carte items are all optional, priced per unit, and bought in a chosen quantity. Every offer other than an a-la-carte offer should hold at least one mandatory item. Case to check: thm:c02-item-per-offer-item creates one order item per offer item, which fails when the customer skips an optional item. The source's own figure shows an offer total of 80 USD equal to one item while a second item is listed.
Open point: The source does not say whether an offer's total price counts its optional items. The business must decide that, and how acceptance records the chosen items and quantities.
Source: EASD guide, Offers; Interline guide, General Principles and Assumptions.
Offer responsible airline owns order
Each offer has one Offer Responsible Airline, the airline that returns the combined offer; every other airline in it is a Participating Offer Airline. The order created from the offer is owned by the Offer Responsible Airline, which receives the seller's payment commitment and holds the single source of the order's data. Case to check: In the interline ordering flow each participating airline also keeps its own order for its services. Status read from that order can disagree with the owner's order unless every status change reaches the owner.
Source: IATA Resolution 797; Settlement with Orders, Roles; Interline guide, Ordering.
Terms of a combined interline offer
When the Offer Responsible Airline combines a participating airline's offer item into its own offer, it keeps that item whole and accepts the item's settlement value, settlement terms and sales conditions. It sets the customer price itself, and the settlement value, held per service, stays between the two airlines. Case to check: A participating airline's segment is non-refundable while the combined offer item is shown as fully refundable. The customer gets a full refund and the Offer Responsible Airline still owes the settlement value.
Open point: The source does not say how the participating airline's change and cancel rules become the restrictions shown to the customer, or whether the customer price must cover the settlement values. The business must decide both.
Source: Interline guide, Shopping; Interline guide, General Principles and Assumptions; Interline guide, Glossary of Terms; Interline guide.
Currency of an offer's amounts
Every amount carries a currency, zero included. Amounts that add into an offer's totals are in the offer's currency and use that currency's number of decimals (two for GBP, three for TND, none for JPY). Local or equivalent amounts in another currency stay out of totals. Case to check: The source's Tahiti example states XPF amounts to two decimals, although ISO 4217 gives XPF none. A minor-unit model reads 100000.00 XPF as either 100000 or 10000000 units depending on which rule it trusts.
Open point: The source lets a seller request a currency and lets a fee carry a local amount, but never says which amount binds or whether a conversion rate is guaranteed. The business must decide what the customer pays when the requested currency differs from the airline's pricing currency.
Source: EASD guide, Currency in Monetary Amounts; EASD guide, Price Decimals; EASD guide, Fees; IATA capability SHPLOC.
Time limits as UTC instants
Every time limit on an offer or order resolves to one UTC instant before it is compared with the current time. Flight times are local to their airport and need its offset to resolve. Case to check: A payment limit of 2018-01-01 read as midnight UTC and read as the end of that day in a seller zone of UTC-12 differ by 36 hours, so one payment is on time under one reading and late under the other.
Open point: The source prefers UTC, but its own time limit examples include a bare date and a date and time with no offset. The business must decide which instant such a limit denotes, for example the end of that day at the point of sale.
Source: EASD guide, Reference to Times; EASD guide, Time Limits.
Ancillaries, seats and bundles
Dependent impact shown before acceptance
For a customer-initiated change, every reshop offer that would affect a dependent service says so and states the effect. The customer either accepts or reshops with the affected service included, so no dependent service changes without a stated effect the customer accepted.
Open point: The source does not define when a dependent service counts as impacted or what the stated effect must contain. The business must decide whether a change of price, seat number or delivery status counts. It must also decide whether the seller must pass the disclosure to the customer before acceptance, since the source says only that it should.
Dependent service lost by airline change
When an airline-initiated change affects a dependent service, the airline notifies the seller with any follow-up actions, a time limit and the consequence of no action. The customer accepts the change, or declines and cancels or reshops, and the reshop may cost more. Case to check: A customer paid 50.00 for seat 12C. The airline swaps the aircraft and 12C no longer exists. With no automatic refund and Auto-acceptance as the consequence of inaction, a customer who does nothing loses the 50.00, and one who reshops may pay again for a seat.
Open point: The business must decide what the customer is owed when an airline change removes a paid ancillary: an automatic refund, a free replacement, or a reshop at the customer's cost. The source allows extra payment on reshop and sets no limit.
Source: EASD guide, Inform of Impacted Dependent Services; EASD guide, Seller Follow-up Actions.
Seat needs an eligible price point
A seat is assigned to a passenger on a segment only through the price point offer item that the seat references on the seat map, and only if that item lists the passenger and segment as eligible. The seat is available when chosen.
Open point: The source attaches price points to available seats and lists eligible passengers on each price point, and never says a selection is checked against either. The business must decide whether an available seat without a price point can be chosen, and who enforces eligibility such as exit row restrictions.
Source: IATA capability SHPSTP; EASD guide, Seat Map and Price Points; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability.
Bundle of services
A bundle is a set of services sold together at one price that the customer cannot take apart. Conditions set on the offer item apply to every service in it. Case to check: Under the ARMI reading a flight item and a mandatory meal item form one bundle, yet the cancellation page lets a seller delete the meal order item alone as a partial cancellation.
Open point: The EASD bundle page places a bundle inside one offer item, while the ARMI bundle capability treats it as the mandatory offer items of an offer, each with its own price. The business must pick one, because it decides whether removing a bundled ancillary later is a change to one item or a cancellation of a separate item.
Source: EASD guide, Bundles; IATA capability SHPBND; EASD guide, Offers; EASD guide, Cancellation of Order Items.
Pick M of N price
In a pick M of N offer item, the customer chooses at most M of the N listed services. The price is the same whatever the choice. Case to check: Under the fixed price reading a customer who picks no service still pays the full price of the item.
Open point: The source gives a maximum and no minimum. The business must decide whether choosing fewer than M, or none, still costs the full price, and whether unused picks can be claimed after the order exists.
Source: EASD guide, Bundles.
Free seat creates a zero-priced item
Assigning a free seat creates its own order item priced at zero, as a paid seat does. The payment step covers the free seat with a commitment and charges nothing.
Open point: The two pages of the seat worked example disagree: one says payment is processed for free and paid seats alike, the other says a free seat is only committed. The business must decide which, which ties to C-12.
Source: EASD guide, Customer Adds an Ancillary to Existing Order; EASD guide, Customer Adds an Ancillary to Existing Order - Seat Availability; ARMI, General Guidance.
Pooled baggage allowance
A baggage allowance associated with several passengers together is shared among them, and one associated with each passenger separately limits that passenger alone. Under a sum reading, any bags that fit the separate allowances also fit the pooled one. Case to check: Two passengers pool 2 pieces each with a 46 kg total. Under the sum reading they may check 4 bags up to 92 kg. Under the stated totals reading they may check 2 bags up to 46 kg, less than they had separately.
Open point: The pooled example gives each passenger two pieces of 23 kg with a 46 kg total. The business must decide whether the pooled limit is the sum over passengers or the stated totals once, and whether the per-piece maximum still applies to each bag.
Extra baggage weight
Buying extra weight as quantity q of a unit-weight bag service yields one extra allowance of q times the unit weight. The airline returns it as a single extra bag allowance. Case to check: A passenger with one 23 kg bag buys 5 kg extra and checks one 28 kg bag. The bag is allowed if the extra raises the existing limit and refused if the extra is a separate 5 kg piece.
Open point: The source describes the extra weight as added on top of an existing allowance, but its example returns a separate one-piece allowance with its own maximum. The business must decide whether extra weight raises an existing bag's limit or adds a separate piece.
Matching a taxonomy criterion
Taxonomy codes form a tree rooted at code 0000, and a service tagged with a code is also described by every ancestor of that code. A seller's service criterion is Required, Exclude or Preferred, and a criterion with no level counts as Preferred. Case to check: A seller excludes Checked Baggage (13EC). An offer with a service tagged Bag (1450), a child of 13EC, passes an exact-code filter and fails a tree filter.
Open point: The source does not say whether a criterion matches descendants of its code. It also does not say whether Required and Exclude bind the airline, since both capability pages say the airline may consider them and taxonomy use is not mandated. The business must settle both before any filtering guarantee can hold.
Source: EASD guide, Airline Taxonomy; EASD guide, Airline Taxonomy Codeset; EASD guide, Use of Taxonomy; IATA capability SHPSRV; EASD guide, Offer and Order Criteria.
Removing a passenger and dependents
Removing a passenger from an order cancels every service of that passenger, ancillaries included, and keeps every service of the other passengers. Case to check: Removing adult PAX-1 leaves an infant that references PAX-1 with no accompanying adult, and leaves PAX-2 holding a pooled allowance sized for two.
Open point: The source is silent on what depends on the removed passenger through another passenger. The business must decide what happens to an infant on lap whose record references the removed adult, and to a baggage allowance pooled with the removed passenger.
Source: EASD guide, Cancellation of Order Items; ARMI, General Guidance; EASD guide, Baggage Ancillary [CON_SHP_01].
Order creation and information
Failed payment at order creation
When an order is created with instant payment and the payment fails, the airline either returns the order with a warning or returns an error. The guide allows both. Case to check: The airline keeps the order and answers with an error. The seller concludes nothing was created and sends the request again, so the passenger holds two orders on the same flights.
Open point: The business must decide whether an order survives a failed instant payment and, if it does, whether it becomes an unpaid order with a payment time limit. It must also decide whether an error response may ever leave an order behind.
Source: EASD guide, Create Order With Instant Payment; IATA capability ORDCRE.
Statuses of a new order
A new order is OPENED and each of its order items is ACTIVE. Each service starts as CONFIRMED, REQUESTED or WAITLISTED. A confirmed service has delivery status CONFIRMED when the order is created without payment and READY TO PROCEED when it is paid at creation. Case to check: If C-05 rules that delivery status CONFIRMED holds no value, a new unpaid item has no service holding value and fails the ACTIVE condition of C-06 at the moment it is created.
Open point: The guide calls CONFIRMED one of the initial service statuses without listing the others, and gives no delivery status for a requested or waitlisted service. The business must decide those statuses and whether such a service gets a payment time limit or can be paid at creation.
Source: EASD guide, Order; EASD guide, Create Order Without Payment; EASD guide, Create Order With Instant Payment.
Paying for part of an order
A seller can pay for unpaid order items in a later change, so an order can be partly paid. Each payment names the order items it pays for, including items priced at zero. Case to check: A bag item is paid and moves to READY TO PROCEED while the flight item stays unpaid. When the flight item's limit passes, the order holds a paid bag for a flight the passenger no longer has.
Open point: The sources do not say whether a seller may pay one item and leave unpaid another item it depends on, or what happens to the paid item when the other item's time limit passes. The business must also decide whether the price of an unpaid item is held until its time limit.
Source: EASD guide, Order; ARMI, General Guidance.
Order items in a retrieved order
A retrieved order shows every ACTIVE and CLOSED order item. CANCELLED items are left out, except when all items were cancelled in one transaction; those are shown for the retention period. The response to a change also shows the items that change cancelled. Case to check: Items A and B are cancelled in separate transactions. Every item is CANCELLED but the exception does not apply, so the retrieved order shows no items while Resolution 797 still requires access to it and C-01 requires at least one item.
Open point: The business must decide whether the exception covers every order whose items are all cancelled, however many transactions that took. It must also decide which retention period applies, since the guide points to Resolution 797 without saying whether the 7 day or the 13 month period is meant.
Source: EASD guide, Order; IATA Resolution 797.
Read access to an order
A retrieve, list or history request returns an order only to a requester entitled to it. The sources describe these requests as made by the seller and give no rule on which sellers. Case to check: If holding the order ID is enough, anyone who reads it from a receipt can retrieve the order and its history, since the ID is the airline's public codes plus 8 characters.
Open point: The business must decide who is entitled: the seller that created the order, any seller or secondary agent that has acted on it, any party in the distribution chain of a past request, or anyone holding the order ID or booking reference. It must also decide which orders a search across many orders may return.
Source: EASD guide, Retrieve an Order; EASD guide, Historical Information on Orders; EASD guide, Order History; IATA capability ORDLST; IATA capability ORDHIS; IATA Resolution 797.
Group order limits
An order is a group order when the create request names a passenger group. Each airline sets the minimum and maximum number of passengers and the passenger details required at creation and at payment, and refuses creation or payment when these are not met. Case to check: A group order is created with 10 passengers against a minimum of 10. One passenger cancels, and the sources do not say whether the remaining 9 still form a group order.
Open point: The business must set the thresholds and the required details. It must also decide what happens when passengers leave a group order and the count falls below the minimum.
Source: IATA capability ORDGRP.
Version tracks seller-visible changes
The airline raises an order's version whenever an element the seller can see changes. Two views of one order with the same version therefore show the same seller-visible data. Case to check: The airline records a new payment status without raising the version. A seller holding version 4 passes the version check and changes the order on data that no longer holds.
Open point: The guide says the airline should raise the version, and it lets the airline group many changes into one version. The business must decide whether every seller-visible change, including airline-initiated ones, must raise the version before the seller next sees the order.
Source: EASD guide, Order Versioning; EASD guide, Order Versioning; IATA capability ORDOC2.
Service IDs in an order
Service IDs are unique within an order and never change. A service moved to a new order item in a change keeps its ID. Case to check: A change moves service S1 from item A to item B. Item A keeps S1 marked TRANSFERRED and item B holds S1, so the order has two service records with ID S1.
Open point: The identifier rules call unique service IDs and unique order item IDs a best practice, while the Order page states item IDs are unique, which bears on C-03. A transfer leaves the original TRANSFERRED service and the moved service in one order with the same ID, so the business must decide whether uniqueness covers every service record or only those not TRANSFERRED.
Source: EASD guide, Identifier Usage; EASD guide, Order; EASD guide, Order; EASD guide, Airline notifies Seller of changes to an Order; IATA capability ORDOC2.
Order ID
An order ID joins the owning airline's 2 or 3 character designator, its 3 character accounting code (XXX when it has none) and an 8 character reference unique within that airline. The ID is treated as globally unique, never changes, and every later request for the order uses it. Case to check: Two airlines that share a controlled duplicate designator and both use XXX issue the same order ID whenever their 8 character references coincide.
Open point: Global uniqueness follows only if designator and accounting code together name one airline. The business must decide how uniqueness holds when two airlines share a designator and neither has an accounting code, and how long a booking reference may still be used to retrieve an order.
Source: EASD guide, Order ID; EASD guide, Identifier Usage; ARMI, General Guidance.
Order owner is the offer owner
The airline responsible for the accepted offer owns the resulting order. The order's owner code is that airline's designator, which also begins the order ID. Case to check: A seller selects offer A from airline XB and offer B from airline YY in one create request. The resulting order would have two owners.
Open point: Resolution 797 makes each offer responsible airline the owner of the orders for its own offers, and the capability pages allow one order from several offers. The business must decide whether one order may combine offers from different responsible airlines.
Source: IATA Resolution 797; EASD guide, Order ID; EASD guide, Create Order Without Payment.
Verifying distribution chain identities
The carrier accepts a participant's identity only when its credential is authentic, unexpired and unrevoked, carries the identifier the participant uses in the message, is presented by its owner, and is presented for this transaction. Every participant except the one connected to the carrier sends such a presentation, and intermediaries pass on all they receive. Case to check: A seller's credential is revoked at 09:00. An airline that refreshes revocation lists once a day accepts that seller's create request at 10:00.
Open point: The guide does not say what the carrier does when a check fails, and leaves the refresh rate of revocation lists to each airline. The business must decide both.
Source: EASD guide, Verification of Identities in Distribution Chain; EASD guide, Distribution Chain; ARMI, General Guidance.
Change and cancellation
Transferred services keep the order balanced
Services kept through a change move to the new item with the same service ID, and the originals are marked TRANSFERRED. Delivered services move too, so that the order stays balanced.
Open point: the source does not define what keeps an order balanced.
Source: EASD guide, Order.
Stored value stays in its order
Value stored as an order item can only be used in a later change to the same order.
Open point: the source does not cover using part of the stored value, or when it expires.
Source: EASD guide, Value Store.
Change accepted before payment
A seller may accept a change offer and pay later. Until payment, the new item's services are CONFIRMED with a payment time limit, and the old item stays ACTIVE with its replaced services CANCELLED and in REMOVED HOLD VALUE. Payment moves the new services to READY TO PROCEED and the old item to CANCELLED. Case to check: In EXM_ORD_003C the change is accepted late on 18 May 2023 with payment due by 16:00 UTC on 19 May. If the 60.00 is never paid, neither item gives the customer a flight.
Open point: The source does not say what happens if the payment time limit passes. The business must decide whether the old services return to READY TO PROCEED, or the customer is left with an unpaid new item and cancelled old services.
Source: EASD guide, Customer requests a change to an Order containing a paid OrderItem; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection due to penalty and forfeited amount; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in a refund.
Full cancellation keeps no residual
Cancelling a whole order cancels every service and settles any refundable amount. The customer cannot keep residual value in the order for a later reshop. Case to check: If a full cancellation must close the order, 030C conflicts with C-07, because its value store service still holds value and keeps the order OPENED.
Open point: The ORDCA2 guidance states this, but worked example EXM_ORD_030C cancels a whole order through the full cancellation request and keeps the full 1,000 as a Value Store order item, leaving the order OPENED. The business must decide whether a full cancellation may end in a value store or a reusable amount.
Source: IATA capability ORDCA2; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Value Store.
Removing one passenger from an item
When one order item covers several passengers, removing a passenger deletes the whole item and lists the other passengers' services to retain. The retained services move to a new item, which is repriced. Case to check: Two passengers share one item priced 1,000 under a companion fare. Removing one reprices the other at a 900 single fare, so the leaving passenger is refunded 100 where an even split gives 500.
Open point: The source does not say whether the retained services keep their share of the original price or are repriced at current fares, or how a penalty is assigned when one passenger leaves. The same page also classes cancelling services inside an item as a change of order, yet uses that method for passenger removal under cancellation.
Source: EASD guide, Cancellation of Order Items; IATA capability ORDCAN.
Reusable amount on cancellation
A cancellation that asks to respend (RespendInd true) triggers no refund. The item stays ACTIVE at its full price, its services become CANCELLED with delivery status REMOVED HOLD VALUE, the differential is typed Reusable with zero amounts, and the order stays OPENED. The exact amount is computed later, at a refund request or a reshop. Case to check: In EXM_ORD_030E the customer paid 1,000 and holds an ACTIVE item at 1,000. If the airline recomputes the value lower at reuse, nothing in the source protects the 1,000.
Open point: The source sets no floor, ceiling or time limit on the amount computed later. The business must decide whether the customer is owed at least what a refund would have paid on the day of cancellation, and when the held value lapses.
Source: IATA capability ORDREU; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in a Reusable amount; EASD guide, Cancellation of Order Items.
Settling money the airline owes
Money the airline owes after a change or cancellation is settled as a refund (by default to the original form of payment), a Value Store order item, a reusable amount held on the cancelled item, or value on an open accountable document. Non-refundable parts, such as a non-refundable tax, are recorded as forfeited. Case to check: In EXM_ORD_003D and 003E the refund offer and the value store offer are both worth 150. Nothing in the source stops a 150 refund offer alongside a 120 value store offer.
Open point: The sources differ on who picks the form. The change page has the airline choose between refund and value store, the cancellation page lets the seller request respend, and EXM_ORD_003D and 003E show the airline offering both while the seller accepts one. The business must decide who chooses, and whether a value store must equal the refund it replaces.
Source: EASD guide, Seller Initiated Change to an Order; EASD guide, Cancellation of Order Items; EASD guide, Value Store; IATA capability ORDCAN; EASD guide, Customer requests a change of a paid order prior to travel resulting in a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in a value store.
Value store time windows
A Value Store order item carries its own cancel and change restrictions with start and end dates. In EXM_ORD_030C the 1,000 value store may be cancelled at no fee for one year and used in a change for two years, and cancelling is not allowed after the first year. Case to check: A customer who holds the 030C value store for 25 months can neither cancel nor use it, yet the order stays OPENED with a service that still holds value under C-05.
Open point: The source does not say what the customer receives on cancelling a value store, or what happens to unused value when the change window closes: refund, forfeit or a voucher. C-20 leaves expiry open; these windows supply the dates but not the outcome.
Source: EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in Value Store; EASD guide, Customer requests a change of a paid order prior to travel resulting in a value store; EASD guide, Value Store.
Stored value is used once
The total drawn from any stored value, whether a Value Store item, a reusable item or an open accountable document, never exceeds its value across all orders. Value moved to a new order leaves the order it came from. Case to check: A seller reallocates 500 from an open ticket to a new order through OrderCreate, then quotes a change on the original order naming the same ticket. Nothing in the source marks the 500 as spent.
Open point: The Value Store page lets value on an open document be reallocated to a new order or within the changed order, recalculated on reuse, but states no rule against using it twice. The business must decide how stored value is tracked and when it is used up, including the partial use that C-20 leaves open.
Source: EASD guide, Value Store.
Refund waits for separate penalty
When a penalty is charged separately, the airline releases the refund, or makes the value store usable, only after the penalty is paid. A netted penalty leaves nothing to wait for. Case to check: C-16 treats netted and separate penalties as equivalent. In EXM_ORD_003G the separate penalty means the customer pays 60 in cash and receives a 160 value store; netted, the customer would pay nothing and receive 100 stored. The net is equal, but 60 of cash becomes restricted stored value.
Source: EASD guide, Customer requests a cancellation to paid Order or OrderItems; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a value store; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a value store.
Penalties and forfeits persist
From release 24.1, penalties and forfeited amounts are recorded at order level with links to order items. Once recorded, each keeps its amount and stays on the order when its order item is later replaced, cancelled or dropped from the order view. Case to check: In the change worked examples the change penalty points at the new item ORDITM02_NEW, and the next retrieval no longer shows the cancelled item. A model that stores penalties on items would lose them at the next change.
Source: IATA capability ORDPEN; IATA capability ORDFOR; EASD guide, Customer requests a change to an Order containing a paid OrderItem.
Name change through an offer
A name change or correction is made by accepting a name change offer, free or paid. It adds a name change order item priced at the fee, whose service is DELIVERED at once; it overwrites all name elements of the same passenger and leaves the flight items and their services unchanged. Birthdate, gender, birthplace and additional names cannot be changed this way. Case to check: In the paid name change example the fee item ORDITM02 is CLOSED at 100 and the flight item ORDITM01 is unchanged. A full cancellation the next day would refund the flight item under its own rules and keep the 100.
Open point: The source does not separate correcting a name from handing the booking to another person. It also does not say whether a paid name change fee is refunded if the order is later cancelled; because its service is DELIVERED, the existing rule forbids cancelling it.
Source: IATA capability ORDNAM; EASD guide, Customer Changes Their Name; EASD guide, Paid name changes.
Changes made without an offer
A change goes through an offer when it replaces, adds or cancels items of an order with any payment, removes a passenger, or changes a name. Other passenger details, sharing preferences, cancelling an unpaid order and accepting a follow-up action are made directly; they keep the passenger ID and have no payment step.
Open point: The direct path has no price, yet the sample change record on the Modification of an Order page pairs an Accept follow-up action with 100 due by the airline. The business must decide whether a direct change can create an amount owed and, if so, how it is priced.
Source: EASD guide, Seller Initiated Change to an Order; IATA capability ORDPAX; EASD guide, Modification of an Order.
Full cancellation equals item cancellations
Cancelling a whole order produces the same refundable amounts and penalties as cancelling each of its items under the same rules. Case to check: An order has two items and a cancellation fee of 50 per transaction. Cancelling the order costs 50; cancelling the items one at a time costs 100.
Open point: ORDCA2 says the calculation mechanisms are identical but does not say the totals must match. The business must decide whether order-level fees apply once per transaction or once per item, and whether item-by-item cancellation may keep reusable value that a full cancellation may not.
Source: IATA capability ORDCA2.
Stored value belongs to payer
A value store is held by the airline for the payer of the transactions that created it.
Open point: The source does not say whose value it is when several payers or payment methods paid the original item, or when the payer is not the passenger. The business must decide who may use, move or reclaim it.
Source: EASD guide, Value Store.
Airline-initiated change
Unacknowledged change notice
A follow-up consequence takes effect only after the seller has acknowledged the notice that carried it. Case to check: A notice carrying Accept with Auto-cancellation is lost. The seller sees the pending action only if it retrieves the order, and the order may be cancelled before it does.
Open point: The guide names an unreceived or unacknowledged notice as the failure case but attaches no rule to it: no retry, no fallback, and no effect on the time limit. The business must decide whether the time limit runs from sending or from acknowledgement.
Source: EASD guide, Notification of Airline Initiated Change to an Order; EASD guide, Seller Follow-up Actions.
Repricing after waitlist confirmation
When a waitlisted service is confirmed, the airline may ask the seller to reprice the order item and accept. The guide's example pairs this with Auto-acceptance if the seller does not act. Case to check: The waitlist clears at a higher fare. The seller misses the deadline, auto-acceptance confirms the service, and the customer is bound to a price never quoted.
Open point: The source does not say at what price an auto-accepted waitlist confirmation stands, or whether the customer must pay a difference before the service becomes READY TO PROCEED.
Source: EASD guide, Seller Follow-up Actions.
Who is told of a change
A service provider reports every service status change to the airline that owns the order. That airline notifies the seller of airline-initiated changes and the seller acknowledges. The seller is expected to inform the customer when a change needs action. Case to check: Agency A creates the order and agency B services it later. The disruption notice goes only to A, and B keeps selling changes against an old version.
Open point: The sources do not say which seller is notified when several sellers have serviced the order, whether the airline must reach the customer when the seller does not acknowledge, or whether the seller's duty to inform the customer is binding.
Source: EASD guide, Notification of Airline Initiated Change to an Order; EASD guide, Inform of Impacted Dependent Services; EASD guide, Order History; IATA capability STPNTF; IATA Resolution 797.
Delivery and fulfilment
Refunds while delivery is in progress
A service whose delivery is IN PROGRESS may block refunds and other financial actions.
Open point: the source leaves this to each airline. The business decides whether these rules block them.
Source: EASD guide, Order.
Who sets each delivery status
The ORA's order management system holds the single record of each service's delivery status. The airline sets REQUESTED, CONFIRMED, READY TO PROCEED, SUSPENDED, REMOVED, REMOVED HOLD VALUE and EXPIRED; the delivery provider sets READY TO DELIVER, IN PROGRESS, DELIVERED, UNABLE TO DELIVER, FAILED TO DELIVER and NOT CLAIMED and must report every change to the ORA. Case to check: A lounge provider reports DELIVERED for a service the airline has SUSPENDED for suspected fraud; if the OMS records every report as received, the suspension is lost.
Open point: The split comes from status definitions, and FAILED TO DELIVER names either party. The business must decide whether the OMS rejects a provider report that breaks the transition table, and whether the airline may overwrite a status the provider set.
Source: IATA Resolution 797; EASD guide, Messages; EASD guide, Order; IATA capability ORDSTS; IATA code set directory.
Refund after a failed delivery
FAILED TO DELIVER records a delivery the airline or its provider could not perform because of its own limits. UNABLE TO DELIVER records a delivery the provider cannot perform because of legal, regulatory or force majeure constraints. The sources set no rule on what the customer is owed after either. Case to check: If both statuses hold no value, an order whose paid flight the airline failed to deliver can close with the customer's money kept.
Open point: The business must decide whether each status holds value, whether a refund, value store or re-accommodation follows, and whether the airline-fault case owes more than the force majeure case.
Source: EASD guide, Order; IATA code set directory; EASD guide, 25.4 Release Notes.
Seller told of status changes
When a service's delivery status changes, the airline sends the seller an order change notification carrying the new status, the seller acknowledges it, and the seller tells the customer. Case to check: If payment time limit expiry is shown only on retrieval, a seller that never retrieves keeps showing the customer a CONFIRMED service that no longer exists.
Open point: ORDST2 asks only that the airline can notify; no source says which of the thirteen statuses must be pushed. The business must decide, for example, whether READY TO DELIVER and IN PROGRESS are pushed, and whether removal at the payment time limit is pushed or only shown as error 918 when the seller retrieves the order.
Source: IATA capability ORDST2; EASD guide, Notification of Airline Initiated Change to an Order; EASD guide, Payment Via Redirection with Airline Notification of Payment Success; EASD guide, Airline notifies Seller of changes to an Order; EASD guide, 24.1 Release Notes.
Announced future delivery status
When the airline offers a change or cancellation, it tells the seller the future service status and delivery status of every affected service. Once the change is accepted and completed, each affected service is in the announced status. Case to check: In the deferred-payment change example the reshop offer announces REMOVED, but after acceptance the services sit in REMOVED HOLD VALUE until payment arrives.
Open point: The field was added so the seller can see the outcome, and no source says the outcome must match it or by when. The business must decide whether the announced status binds at acceptance or only once any payment completes.
Source: EASD guide, 24.1 Release Notes; EASD guide, Modification of an Order; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in a Reusable amount; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund.
No changes after closing
Once an order is CLOSED it accepts no further change, including any change to a service's delivery status, though it can still be retrieved. In the worked example the order closes when its last services are reported DELIVERED.
Open point: The sources disagree on what closes an order: the guide requires services DELIVERED or REMOVED, the code set requires items fully paid and services DELIVERED, refunded or EXPIRED, and the closing message once named as the only trigger was withdrawn in 25.4. The business must pick one trigger for C-07. The model proves only that no event changes the delivery status of a service in a closed order; changes to items and service statuses are not modelled.
Source: EASD guide, Messages; Order Accounting, Order Closing Example; EASD guide, 25.4 Release Notes; IATA code set directory; EASD guide, Order.
Transfer keeps delivery status
When a service moves to a new order item it keeps its ServiceID and its delivery status, and delivered services move too so the order stays balanced. The copy left in the original item takes service status TRANSFERRED.
Open point: The guide states that the ServiceID is kept; that the delivery status is kept appears only in worked examples. The business must confirm that a transfer never changes delivery status.
Source: EASD guide, Order; Order Accounting, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a value store.
Delivery milestones and status
A delivery milestone report, such as a passenger boarded or a bag loaded, records progress and does not change the service's delivery status by itself. A status change needs its own status report.
Open point: The source says a milestone does not necessarily change status and gives boarding as a case that does not. The business must decide which milestone, if any, moves a flight service to IN PROGRESS or DELIVERED.
Source: EASD guide, Messages.
Payment
Committing to pay nothing
An order item with nothing to pay goes ahead when the seller commits to pay zero.
Open point: the source does not say which delivery status the item's services move to.
Refunds across payment methods
A refund goes back to the payment methods that paid.
Open point: the source does not say how a refund is split across several methods, or whether surcharges are refunded. If surcharges are refunded, a refund can exceed the item's price, which bears on the open question about refunds and payments.
Source: EASD guide, Use of multiple payment methods; EASD guide, Cancellation of Order Items.
No payment after the limits
The airline accepts a payment for an order item only before the item's payment time limit and, when the item has a price guarantee, before that guarantee expires. A payment attempted after the price guarantee has expired fails with a price guarantee error. Case to check: The airline extends an item's price guarantee two days past its payment time limit, which the source allows. The item can no longer be paid while its price is still guaranteed.
Open point: The payment time limit part is clear, but for the price guarantee the source also says repricing is only recommended. The business must decide whether an expired guarantee blocks payment or only lets the airline change the price, and whether a guarantee may outlast the payment time limit, which the source says it should not.
Source: EASD guide, Pay for an Existing Order; EASD guide, Payment Errors; EASD guide, Time Limits.
Allocating a payment across items
When one payment with several methods covers several order items, the airline decides how much of each method goes to each item and the seller has no say. A seller who wants a fixed split sends one payment per item. Case to check: Items of 800.00 and 100.00 are paid with 400.00 by settlement plan and 500.00 by card. If the 100.00 item is cancelled, its refund goes to the card under one allocation and to the settlement plan under another.
Open point: The source gives the airline the allocation and states no rule for it. The business must fix the rule, because it decides which method is refunded when one of the items is later cancelled.
Source: EASD guide, Payment Simulation; EASD guide, Use of multiple payment methods to pay for a single item; IATA capability PAYMIX.
Combinable payment methods
The payment catalogue places each accepted method in one or more groups, and two methods may be combined in one payment when they share a group. The airline refuses a payment that combines methods it does not accept together. Case to check: Method A is in groups 1 and 2, B in groups 2 and 3, and C in groups 1 and 3. Every pair shares a group, but no group holds all three.
Open point: The source defines combinability for pairs only. The business must decide whether three or more methods need one group that holds them all or only a shared group for each pair.
Source: EASD guide, Use of multiple payment methods to pay for a single item; EASD guide, Pay using multiple payment methods for a single item.
Quoted surcharge at payment time
When the airline has quoted a precise surcharge for a stated card brand and card type, the payment must use that brand and type and is charged that surcharge. A payment with a different brand, scheme, or consumer or commercial card type fails with a mismatch error. Case to check: The offer is priced with a 3.00 surcharge for a consumer Visa debit card, and at payment the airline charges 5.00 for the same card. Nothing in the source forbids it.
Open point: The mismatch errors exist, but no page says a quoted surcharge binds the airline, and the catalogue calls its ranges estimates. The business must decide whether the charged surcharge may differ from the quote or fall outside a published minimum and maximum.
Source: EASD guide, Payment Catalogue; EASD guide, Payment Preference; EASD guide, Payment Errors; ARMI, General Guidance.
Refundable payment surcharges
Each payment surcharge carries an indicator saying whether it is refundable. A refund of an item's payment returns a surcharge only when its indicator marks it refundable. Case to check: A 100.00 item is paid with 20.00 by settlement plan and 82.00 by card, including a non-refundable 2.00 surcharge. A full refund of 102.00 returns the surcharge, while the cap under the indicator is 100.00.
Open point: The indicator appears in every simulation example, always marked non-refundable, and no page says how a refund uses it. The business must decide whether the indicator binds refunds; with refundable surcharges a refund can exceed the item's price, which bears on C-17 and the open refund question.
Source: EASD guide, Payment Simulation; EASD guide, Use of multiple payment methods to pay for a single item.
Refund as a negative payment
A refund appears in the order as a payment transaction of its own, with a new payment ID, a negative amount, a payment method and its own status. In the worked examples the method is the one that paid, but the record does not point to the payment it returns. Case to check: An order holds a 1000.00 settlement plan payment. Cancelling it adds a payment of minus 1000.00 with its own ID and no reference to the first.
Open point: The source does not link a refund to the payment it reverses, while our model attaches each refund to one payment. The business must decide whether to keep that link; without it the per payment limit in the open refund question cannot be checked and only an order level limit remains.
Source: IATA capability PAYREF; IATA capability PAYSUM; EASD guide, Customer requests a cancellation to paid Order or OrderItems resulting in full refund; EASD guide, Customer requests a change of a paid order prior to travel resulting in additional collection and a refund.
Retrying a failed payment
After a payment fails, its items stay unpaid with services and time limits unchanged, and the seller may try again in a new payment transaction before the time limit. The error tells the seller whether to correct the card details, add payer authentication, use another method, or stop; after a hard stop the airline accepts no payment from that payer. Case to check: A payer flagged for suspected fraud on one order pays for a second order with the same card. The source does not say whether the stop carries over.
Open point: The source calls recovery optional and does not say whether the airline must accept a retry. The business must decide how many retries are allowed, whether a hard stop applies to the payer, the order or the method, and whether the order is then cancelled.
Source: EASD guide, Payment Status; EASD guide, Payment Errors; EASD guide, Pay Offline Using Redirection; EASD guide, Payer Authentication; IATA capability PAYRCV.
Paying with a voucher
A voucher is a payment method that spends value the airline holds for the payer, alone or combined with other methods. Value stored as an order item can be spent in another order only after the airline issues it as a voucher. Case to check: An 800.00 item is paid with a 300.00 voucher and 500.00 by card, then cancelled with a 100.00 penalty. Refunding the card first returns 500.00 to the card and 200.00 to the voucher; a pro rata split returns 437.50 and 262.50.
Open point: The voucher capability has no guidance beyond its name. The business must decide whether a voucher can be partly spent, whether it expires, and whether a refund of a voucher paid amount goes back to the voucher or to another method.
Source: IATA capability PAYVCH; IATA capability PAYMIX; EASD guide, Value Store; EASD guide, Payment Concepts.
Commission, accounting and settlement
First accounting posting after payment
The airline's accounting system receives nothing about an order until at least one of its items has a successful payment. The first posting records a liability for the services' values, including taxes and fees, and a receivable for the amount paid. Case to check: An order has two items, one paid and one still waiting for payment. If the first posting books liability for both, accounting shows an obligation for a service nobody has paid for.
Open point: The source does not say whether that liability covers only the paid items or every item in the order. The business must decide, and must say whether a commitment to pay zero (C-12) counts as a successful payment here.
Source: Order Accounting, Order Accounting Home; Order Accounting, New Order Creation; Order Accounting, Account for Order with Payment; Order Accounting, Principles for Finance with Offer and Order; Order Accounting, Introduction; EASD guide, Order; IATA code set directory; EASD guide, Messages.
Clearance request matches the order
The amount, currency, payer, payee and payment method in a clearance request equal the clearance data agreed in the order at payment commitment. The seller proposes its role and the amount, the ORA adds a clearance ID and the commitment time only if it agrees, and the order keeps that ID permanently. Case to check: With deferred EasyPay payment the airline quotes an expected net clearance amount at order creation. If the seller adds a bag before paying and reuses the old figure, the clearance disagrees with the order unless the ORA checks it again at payment.
Source: Settlement with Orders, Request for Clearance; Settlement with Orders, Clearance Information During Shopping; Settlement with Orders, Enhanced and Simplified Distribution.
Cancelling a clearance
Only the ORA may cancel a clearance, and only one the Clearance Manager has accepted. A cancelled clearance is never settled and the seller is notified; a refused cancellation leaves the clearance in its current status with a reason. Case to check: An order is cancelled with a full refund before the remittance date. If the ORA cancels the original clearance and also clears the refund to the seller, the seller receives a refund for money it never remitted.
Open point: When a clearance can still be cancelled is left to each Clearance Manager. The business must decide the cutoff, such as before the clearing notice or before the remittance date, and whether cancelling a paid order item cancels its clearance or raises a reverse refund clearance.
Source: Settlement with Orders, Cancellation Overview; Settlement with Orders, Cancellation Sample Messages; Settlement with Orders, Codeset List; Settlement with Orders, Settlement.
Netting on a change
When a ticketed flight order item is changed, the airline may offset the old item's residual value against the new item's fare and taxes, against a change penalty, or both; one of the guide's modes lets the penalty use fare residual only. The result is a single amount due to the airline, a single amount due by the airline, or nothing. Netting never crosses order items or orders, and does not apply to non-flight items with an EMD or to unticketed flight items. Case to check: The old item leaves 50.00 of fare residual and 50.00 of tax residual, and the penalty is 100.00. If the penalty may use fare residual only, 50.00 of penalty stays due to the airline while 50.00 of tax residual is due by it: two amounts where the guide promises one.
Open point: The guide says the amount due is calculated correctly but gives no formula. The business must decide the formula, including how forfeited amounts and a penalty larger than the fare residual enter it; the answer also settles part of C-18's open point on the sign of the difference.
Source: EASD guide, Netting; EASD guide, Netting in Ticketing; Order Accounting, Customer requests a change to an Order containing a paid OrderItem.
Order of accounting postings
Accounting posts an order's notifications in the sequence in which the order changed, with no gaps; a missed notification is recovered before any later one is posted. Each posting uses the values the order held at that change, and accounting never corrects or recalculates them outside the order. Case to check: The cancellation notification arrives before the creation notification. Posting it first records a refund against an order that has no receivable.
Open point: The source requires chronological posting and a recovery process but does not say what fixes the sequence. The business must decide whether the order version (C-21), a timestamp or a per-order counter orders the postings, and whether a later notification waits for a missing one.
Source: Order Accounting, Principles for Finance with Offer and Order; Order Accounting, De-specializing Financial Processes; IATA Resolution 797.
Commission from offer to order
The commission the airline disclosed on an offer item is the commission recorded on the order item created from it. A commission stated once for a whole shopping response applies to every offer in that response. Case to check: An aggregator merges a response carrying a 5% commission at response level with offers from a second airline. The merged offers then seem to carry the first airline's commission.
Open point: The capability asks the airline to repeat the commission in the order confirmation but does not say it must equal what was shown when shopping. The business must decide whether commission may change at pricing or order creation, and what the seller is owed if the order shows less.
Source: IATA capability PAYCOM; EASD guide, Commission and Margin.
Requesting a clearance
Only the ORA sends clearance requests, and it must be the payer or the payee of each clearance it sends. It sends the request no later than the day after payment commitment, the moment the payment became successful. The Clearance Manager rejects an EasyPay clearance whose commitment is more than 48 hours older than the request. Case to check: A payment committed at 23:55 on day 1 and requested at 23:50 on day 3 breaks the next-day rule yet passes the 48-hour check.
Open point: The next-day limit applies to all payment methods, but the only enforced limit is 48 hours and only for EasyPay. The business must decide what happens to a late settlement plan clearance and whether the limit is a calendar day or a duration.
Source: Settlement with Orders, Clearance Overview; Settlement with Orders, Clearance Manager; Settlement with Orders, Codeset List; Settlement with Orders, Roles; Settlement with Orders, Enhanced and Simplified Distribution.
How the rules depend on each other
A rule can only be written in Lean once everything it depends on is, so the dependencies show what to build next. The Explore page shows them as a map of the areas, a matrix of dependencies between areas, every card with an arrow to the cards that build on it, and the history of the model. Click a card there to see what it depends on and what builds on it.
ModelledProvenOpen questionNeeds a decisionReady to buildWaiting