现代航空零售基础知识。本系列短文将为您解读MAR——相关术语、架构，以及当航空公司从PNR系统转向订单系统时会发生哪些变化。
从 PNR 到订单的转变，从根本上改变了您对客户购买行为的建模方式，并对您在客户旅程的每个阶段所能做和不能做的事情产生了切实的影响。
报价转为订单
在 OOSD 系统中，一切都始于搜索。查询可用性会返回相关报价。当客户选择并接受某项报价时，该报价即转化为订单。报价 ID 通常会成为订单 ID。与旧逻辑生成的六位字母数字 PNR 不同，新逻辑生成的订单 ID 长度可能更长，且包含对使用该 ID 的系统具有实际意义的内部结构。
一个订单中可以包含哪些内容？
接下来就变得有趣了。在同一个订单编号下，您可以拥有：
- 多名乘客，出发地和目的地各不相同
- 同一订单中不同舱位的乘客
- 航空配套服务、机场配套服务、零售附加服务
- 与航班完全无关的产品和服务，如果航空公司想销售，可以放在这里
这与传统的预订系统有显著不同。在传统模式下，同一预订中的所有乘客必须前往同一目的地并乘坐同一舱位。而按顺序预订的模式则完全取消了这一限制。
订单 → 订单明细 → 服务
该结构分为三层。
订单是最高级别的容器——它包含订单 ID、客户姓名和支付记录。
订单项目位于中间位置。它们通常代表一段旅程（稍后会详细说明这个词），也是将订单拆分为有意义的组成部分的方式。正如优惠会转化为订单一样，优惠项目也会转化为订单项目。当您向现有订单添加新内容（例如快速通道或贵宾室使用权）时，您需要搜索该选项，获取一个优惠项目，接受它，这样就会在现有订单中生成一个新的订单项目。
服务是具体细致的：乘机权利、座位安排、行李限额、贵宾室使用权、餐食偏好、轮椅协助。乘客应享有的所有权益都体现在这一层面。
服务还会处理那些由旧系统作为 SSR（特殊服务请求）处理的内容。 如果您需要与期望接收 SSR 的遗留系统进行通信，可以将服务映射到 PADIS SSR 代码。但这并非强制要求，该映射是可选的。这一点很重要，因为这意味着您不再受限于 PADIS 代码集中的内容——您可以表示那些在遗留系统中没有对应项的服务，并且不必将内容硬塞进原本并非为此设计的代码中。
关于“旅程”的说明
在这个领域中，“旅程”一词具有特定的技术含义，这常让人感到困惑。旅程是指从起点到终点的行程。它可以包含多个阶段或路段。往返行程通常由两个旅程组成。一个订单项通常代表一个旅程，但后续添加的附加服务会生成各自的订单项，这些订单项会引用同一个基础旅程。
这对行李追踪也很重要：您需要追踪行李在整个旅程中的动向，而不是按航段或航程部分来追踪。
问：单笔订单的乘客人数或航班数量是否有上限？
该标准中并未设定绝对上限。实际上，存在一个约200人的软上限，但这更多是出于性能考虑，而非模式限制。其初衷显然是希望远超传统系统的限制——过去，PNR预订通常限制在约20名乘客。
问：关于时间方面，提前预订是否有时间限制？或者行程时长是否有上限？
标准中没有任何条款对此加以限制。理论上，您可以将200名拥有复杂多目的地行程的旅客全部归入同一笔订单，且这些旅客的行程路线各不相同。关于提前购买时段或日期范围的任何限制，均由具体实施方自行决定——并非由数据模型强制规定。
问：这对那些基于旧限制条件构建的系统意味着什么？
这意味着你必须小心，不要将过时的假设硬编码进去。一家航空公司的系统可能会设置限制，而另一家则不会。处理订单的系统必须能够从容应对这种变化。