订单数据的定义：

反应订单特定节点（订单预订变化）时，呈现的订单相关的预订信息。

特点：

尽量体现预订行为到结算前的订单信息。大部分字段会随着预订操作变更字段返回。

对接场景建议与用法：

1，预订分析（报表需求）：

      适用订单列表查询（按照时间轮询）获取订单号。按照订单号查询订单详情。

      建议的更新频率：轮询2天的数据（上限1W条订单号，超过调整查询的时间），落地本地数据库，进行本地的查询展示操作。


2，关联信息展示：

      适用于外部对接的表单，申请单单号关联订单信息。展示时获取关联的订单号+订单号详情信息更新展示。

      可以根据展示的设计支持：按照订单，人维度，票/房间维度的展示，展示信息需要对接方自行设计。

       
3，报销与对账需求：

      使用费用报销相关时，一般按照人程（票）的维度处理金额，使用票相关的金额计算，按照报销系统设计的报销场景，汇总或者增量，需要对接方按照实际预订的生命周期设计方案。报销系统应明确

      使用的费用分类和费用组成，和对应的支付方式和报销节点。需求不同，对应的金额组成需要对接方自行计算。

      使用对账需求时，订单数据不是结算数据，无法作为对账或结算数据的完全替代。可以用于确认订单信息补充和预订行为的监管。

4，预算需求：

 订单数据预占预算时，无法提供退改的金额。所以，只能作为出票的预算自动化判断。后续的退改金额预算调整无法按照出票的实时操作，考虑到跨月，线下退改和票号的状态更新，较高要求的预算占用

 无法满足。建议使用单据占预算，结算数据做最后的调整，如果是报销系统可以通过报销单的方式处理预算需求。

5，审批信息展示：

订单详情数据可以作为审批信息的展示补充，接口提供的方式为轮询，不足以作为触发下游系统的节点。

6，消息通知：

订单详情接口可以作为消息通知的补充，接口提供的方式为轮询，不足以作为触发下游系统的节点。

关于数据结构

滴滴企业版的订单详情数据多用于特定点的分析或展示，由于接口变更和迭代，使用场景应聚焦和细化。比如费用构成或人员维度的报表展示。订单结构不完全等同于报表，在更新频率和展示字段处理上会有差异，对接方应细化展示需求，按照返回评估是否可以使用订单数据处理。

关于数据的时效：

滴滴企业版数据最长可追溯时间为2年。出于数据量和接口效率考量，查询不返回当前时间点两年之前的列表接口中的订单号。