36 cards in the blueprint's section Delivery and fulfilment: 28 are in Lean, 2 are open questions and 8 need a business decision.
Each with the number of cards that depend on it, directly or through other cards, most first. Click one to see what it
depends on and what builds on it.
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.
2 cards depend on it, directly or through other cards, in 1 area.
checks ONE-103.4!Open questionUnder 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.
1 card depends on it, directly or through other cards, in 1 area.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
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.
No card depends on it yet.
An open guarantee fails under some reading of the sources. For these, Lean proves a version under one reading, named
with _of_. The model leaves the choice of reading to the business.
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.
Lean proves the guarantee for one reading of the sources. If the business settles the question this way, it holds for every input:
Under every reading that refuses delivery before payment and keeps an UNABLE TO DELIVER service from returning to READY TO PROCEED, a service that starts REQUESTED or CONFIRMED never reaches READY TO PROCEED, READY TO DELIVER, IN PROGRESS or DELIVERED while no payment for it has succeeded.
Proven as paid_before_delivery_of_gate; open as paid_before_delivery.
The requirements whose rules or guarantees are on this area's cards. Each opens its chapter in the review document.
The capabilities of IATA's Airline Retailing Maturity Index that this area's candidate cards belong to. The codes and
names are IATA's.