概述

对接方申请单常用包含的信息，按照滴滴企业版的申请单结构，下文将对于对接建议做详细的说明。

第三方申请单常见构成，层级结构在不同的场景下会有差异：

滴滴的差旅卡片：

对接准备：

在对接申请单前，先需要做好出差场景的收集，和预期管控的效果以及依赖的主数据前期准备工作。

前序确认：

事项/接口	说明	必要程度
人员信息，新增，修改，删除	对接人员主数据接口	必要
部门信息，新增，修改，删除	对接组织信息接口	必要
城市数据	接口中按照滴滴的城市ID落地管控城市	必要
制度查询接口	第三方获取滴滴ES后台制度信息，用于人员信息绑定	重要
项目同步	需要使用滴滴成本中心字段，预订页面选择	视方案而定
外部出行人，职级，角色	辅助流程完善的接口信息	视方案而定

申请单场景：

场景	说明	需要确认方向
无代订：个人出行	标准出行场景，单据的提单人，申请人即为滴滴账号单点人员，且为预订人	对接无需要强调的限制，需要注意关联的制度为预订人的制度。
代订：多人人出行，全内部员工	标准出行场景，单据的提单人，申请人即为滴滴账号单点人员，单据设计中无明确预订人人员信息的，取提单人或申请人作为预订人对接	多人出行时，需要考虑代订同行人可预订的关系，出差的差标使用，酒店同住房，预订品类的最大预订人人数（申请单落地上线20人）以及账单的拆分和费用归属问题。
代订：多人人出行，内部员工和外部员工	标准出行场景，单据的提单人，申请人即为滴滴账号单点人员，单据设计中无明确预订人人员信息的，取提单人或申请人作为预订人对接	多人出行时，存在外部出行人时，需要注意预订时的差标管控（外部人员跟随预订人，或不管控），酒店同住房，费用归属，预订品类的最大预订人人数（申请单落地上线20人）以及账单的拆分和费用归属问题。
超标预订	超标预订流程	检查超标审批方式，审批流设计。
紧急预订	申请单对接无紧急模式。	确认申请单填写不可预订时流程或明确强制不可预订。

单据主键映射关系：

外部申请单	对接使用说明	滴滴对应字段
TA 单号	第三方单据的单号，是外部单据的唯一值，是否能作为滴滴差旅卡片的唯一值，取决于单据传输滴滴接口时，是否能在一个单号下完成所有的对接字段，包含品类，制度，管控，入口等所有信息的对接	能完整包含时，使用out_approval_id
行程单号	第三方行程明细的单号，具有行程的唯一性，用于定义一段行程的信息，多个行程单号聚合成一个TA单号，单据处理的颗粒度在行程上	映射out_approval_id，此时，解决对应的行程管控颗粒度问题，但是滴滴首页会有多个卡片，out_approval_id为卡片的唯一主键。存在多入口时，可以使用TA单号映射out_trip_id，滴滴将聚合卡片入口，但是无法在层级结构上于单据保持一致。鉴于管控和行程展示需求和实际的客观因素，对接方需要评估使用那种方式映射out_approval_id字段

申请单城市cityid使用

      企业版申请单接口cityid使用的是城市维度。

      举例：需要预定“昆山”的酒店，在申请单落地时需要落地“苏州”对应的城市ID。

       在城市接口中，机票和火车票有场站信息，使用接口时需要根据机场或火车票对应的城市进行落地。

常用的单据映射方式

类型一

示例1：

申请单的单号直接包含多个品类（机票，酒店，火车票，用车），按照整个单子的完整性进行对接。

在对接层面，TA单号作为管控品类的关联主键。理解成为一个完整的对象。且滴滴企业版使用的制度在与TA单号在同一个维度。
示例2：

外部单据在展示上存在行程，但是整体的管控和主键仍以申请单TA单号为唯一值，且滴滴企业版使用的制度在与TA单号在同一个维度。

类型二

申请单的在行程下包含多个品类（机票，酒店，火车票，用车），按照行程的完整性进行对接。

在对接层面，行程理解成为一个完整的对象。且滴滴企业版使用的制度在行程在同一个维度。下游订单关联主键为行程单号时适用此类映射关系。

展示差异：

TA 单号映射：首页直接入口跳转品类预订页面

行程单号映射：弹层行程展示，再按照选择品类进入品类查询页面

首页显示差异：

对接需求梳理：

使用滴滴对接申请单前，需要先了解滴滴制度。了解滴滴制度可以更好的找到适合对接的方式。

滴滴的制度，包含了设置，审批，差标等很多综合性的功能。类比一下第三方的表单，接近于，差旅申请单，报销申请单，预提申请单的概念。直观上理解一下，就是在差旅单上通过一个标识（制度）告知滴滴如何处理这个申请单。如果你是OA系统设计或者开发，可以理解成这是不同的表单类型的集合。对于在和滴滴对接时，从单据这个维度换成了预订，从单据对象到了滴滴预订方式对象的转变。

关于制度列表简单的分类

制度分类	说明
用车制度：品类用车	按时间
	按次数
差旅制度：机酒火，用车	制度管控方式：不管控，轻度，中度，严格

有了制度的概念之后，现在要梳理需要对接的方式了。

判断顺序可以参考：

   1，需要对接的品类

   2，申请单的使用场景

   3，管控方式，按照品类，城市，时间这样的顺序大致罗列出管控的诉求。比如，只能自己预订。时间只要范围，城市只要范围。这样具象的要求。

   4，制度的配置，收集完需求之后，先要确认制度是不是可以满足，决定自己使用的是什么管控方式。

   5，单据上制度的绑定：单据设计时可以绑定制度，比如费用类型，成本中心映射制度。管控一般跟随审批流，和人，成本中心，部门，都有关系，这个按照对接方自行设计，在接口中给到滴滴对应的制度即可。

从需求出发完成对接：

       申请单对接不止有字段的对接，其中承接主数据，预订管控，生成订单之后影响账单拆分和订单数据对接等一系列流程。

       枚举全需求，在对接过程中按照明确的规则验证对接效果是保证上线的捷径。上线前保存对接时接口请求与返回报文，便于后续查询是否由于配置导致的失效和报错。

       每对接一个字段，都是在明确和收窄后期调整的范围。

       管控代表禁止，体验往往与管控相对立，平衡两者是对接方案的核心。