一份差旅行程、多个预订与多段记录：Concur文档为什么分三层

企业差旅资料里，一份行程可以包含航班、住宿等多个预订，而一个预订记录也可能有多个segment。SAP Concur官方仓库中的Itinerary API文档，把这些对象分为三个层次。所读文件位于preview分支，明确标示Version 1.0；本篇解释该版本的公开资料，不把它当作今天系统行为的实测。[1]

在这份文档中，itinerary和trip是同义词，Trip是表示行程的服务资源名称。行程是一次旅行中所有预订的容器，可以包含不止一个booking。由此，“取得一份行程”并不等于只得到一笔预订，也不宜用预订条数直接替代行程数量。

Booking record又有自己的边界：它把来自一个来源、具有相同唯一标识的segments放在一起。原文将record locator和confirmation number列为这种标识的例子。来源与确认标识共同帮助理解这层记录，不是仅凭某项内容同一天发生，就把它任意归到同一预订中。

Segment位于预订记录之内，包含差旅预订的具体信息。一个booking可以有多个segments，因此，行程、预订和段落记录之间并非天然一对一。资料中即使出现相同的旅行者和日期，也仍需要保留记录属于哪一层，才能理解所统计的数量或所说明的变化。

日期重叠的处理尤其显示这种区别。文档的FAQ说，提交的bookings在日期重叠时会并入已有trips；提交的trips则即使与已有行程日期重叠，也不会按这条规则合并。同样出现日期重叠，输入对象不同，原文给出的关系就不同。这是版本文档的定义，不是本文执行了一次上传或处理真实行程。

文档还限制了数据覆盖：接口只返回已经送到Concur Travel的行程，包括文中列举的Concur Travel、TripIt、TripLink供应商网站、邮件及多数旅行社预订。某些客户可能有多种预订选项，所以员工的所有出行未必都在这里可得。数据来源渠道清单与企业全部出行事实，是需要分开的范围。

多来源也带来记录差异。原文说明，不同行程的数据可能不一致，而且行程经常变化，变化未必表示旅行者亲自修改了它。因此，资料更新时间可以如实保留，但不能在缺少对应证据时，替每次变化补上一个由员工主动改动的原因。

这种层次关系让差旅交接更具体：Trip汇集bookings，booking record围绕来源及唯一标识组织segments；日期重叠是否合并，又取决于提交的是哪一种对象。本文未调用接口、配置账户或作真实预订，不涉及费用报销与旅行安全。该文档首次公开日期未知，也不以公开代码仓库的分支名称推断当前产品上线状态。