本申请涉及互联网信息处理技术以及计算机技术领域，尤其涉及一种订单任务处理、提供差旅服务的方法及装置。
背景技术：
随着计算机技术的飞速发展，诸如即时通讯(instantmessaging，im)、商旅应用(application，app)等软件正逐步融入到人们的日常生活中，这些软件不仅给人们的生活方式提供了多种选择，还给人们的日常生活带来了极大的便利。
当前，企业管理软件由于其能够向企业提供便捷的企业管理方式，使得各企业争相使用企业管理软件来对企业实施管理，如，通过企业管理软件向各企业员工发送通知、通过企业管理软件完成对各企业员工的考勤管理等。而企业员工的差旅管理作为企业管理中的重要一部分，在当前的企业管理软件中并不能向企业提供关于差旅管理方面上的帮助，而当前企业员工向企业提交差旅申请时则需要经过较为繁琐的审批流程才能完成，因此，如何通过企业管理软件实现对企业员工的便捷差旅管理，则是一个亟待解决的问题。
技术实现要素：
本申请实施例提供一种订单任务处理、提供差旅服务的方法，用以解决现有技术中企业无法对企业员工的差旅实施便捷管理的问题。
本申请实施例提供了一种订单任务处理方法，包括：
第一应用接收订单任务处理请求；
所述第一应用根据所述第一应用与至少一个第二应用之间的合作关系以及所述订单任务处理请求中包含的订单类型，从与所述订单类型相匹配的所述第二应用中获取数据；
所述第一应用基于获取到的数据对所述订单任务处理请求进行处理。
本申请实施例提供了一种订单任务处理设备，包括：
接收模块，接收订单任务处理请求；
获取模块，根据所述第一应用与至少一个第二应用之间的合作关系以及所述订单任务处理请求中包含的订单类型，从与所述订单类型相匹配的所述第二应用中获取数据；
处理模块，基于获取到的数据对所述订单任务处理请求进行处理。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：
在本申请实施例中，对于第一应用接收到订单任务处理请求，通过第一应用与其他应用之间的合作关系，能够快捷从其他应用中获取到相关数据，进而实现对订单任务处理请求的快速处理。这样，对于一些企业管理软件，通过本申请所提供的方案，能够很好的与旅行软件建立互联互通，便捷地从旅行软件中获取与差旅相关的信息，进而在企业管理软件中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
本申请实施例提供的一种提供差旅服务的方法，包括：
接收用户发送的差旅处理请求；
根据所述差旅处理请求，生成对应的差旅订单；
当监测到所述差旅订单满足预设的条件时，从第二应用中获取与所述差旅订单相关的差旅数据，并根据所述差旅数据为所述用户提供差旅服务。
本申请实施例提供一种差旅服务处理装置，用以解决现有技术中企业无法对企业员工的差旅实施便捷管理的问题。
本申请实施例提供的一种提供差旅服务的装置，包括：
接收模块，接收用户发送的差旅处理请求；
订单生成模块，根据所述差旅处理请求，生成对应的差旅订单；
获取信息模块，当监测到所述差旅订单满足预设的条件时，从第二应用中获取与所述差旅订单相关的差旅数据，并根据所述差旅数据为所述用户提供差旅服务。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：
由于应用于企业管理的第一应用在获取到用户发送的差旅处理请求后，可根据该差旅处理请求生成对应的差旅订单，并通过该差旅订单，从用于差旅服务的第二应用中获取与该差旅订单相关的差旅数据，这样，通过企业管理的第一应用即可调用第二应用，并从第二应用中获取与差旅订单相关的差旅数据，进而在第一应用中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的一种订单任务处理方法的流程示意图；
图2为本申请实施例提供的一种订单任务处理设备的结构示意图；
图3为本申请实施例提供的差旅服务处理的过程；
图4a、4b、4c为本申请实施例提供的第一应用向用户展示的界面示意图；
图5为本申请实施例提供的以行程卡片的方式展示差旅订单的示意图；
图6a、6b为本申请实施例提供的差旅订单的审核状态显示示意图；
图7a、7b为本申请实施例提供的第一应用从第二应用中获取与差旅订单相关的差旅数据的示意图；
图8为本申请实施例提供的各子差旅订单的展示方式示意图；
图9a、9b为本申请实施例提供的差旅订单结算示意图；
图10a、10b为本申请实施例提供的查看预设差旅标准的示意图；
图11为本申请实施例提供的差旅服务处理的详细过程示意图；
图12为本申请实施例提供的差旅服务处理的结构示意图。
具体实施方式
为了实现本申请的目的，本申请实施例提供了一种订单任务处理、提供差旅服务的方法及装置，对于第一应用接收到订单任务处理请求，通过第一应用与其他应用之间的合作关系，能够快捷从其他应用中获取到相关数据，进而实现对订单任务处理请求的快速处理。这样，对于一些企业管理软件，通过本申请所提供的方案，能够很好的与旅行软件建立互联互通，便捷地从旅行软件中获取与差旅相关的信息，进而在企业管理软件中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
需要说明的是，本申请实施例中所记载的第一应用在与用户交互时可以是第一应用客户端，也可以是第一应用客户端对应的服务器；第一应用在与其他应用进行交互时可以是第一应用客户端，也可以是第一应用客户端对应的服务器，为了减少服务器的处理压力，可以将一些功能配置的客户端上，在本申请实施例中不具体限定客户端与服务器的具体功能。
在本申请实施例中，为了保证不同应用之间能够进行数据交互，可以预先在多个不同应用之间建立合作关系，这种合作关系可以通过用户账户进行关联，也可以通过应用接口进行关联，即通过一个指定的应用接口能够实现至少两个不同应用之间的数据传输，还可以通过其他方式(链接地址、跳转控件等等)建立合作关系，这里不再一一赘述。
本申请实施例中所记载的第一应用可以为用于企业管理的应用，也可以为即时通信应用，还可以为集成了企业管理功能的各种应用，这里不做具体限定。若第一应用中具备了企业管理功能，那么一旦企业在第一应用中创建企业群，在所创建的企业群中包含了企业的组织架构以及人事管理关系，那么第一应用可以根据企业群中包含的企业组织架构以及人事管理关系，确定不同用户的管理权限或者出差标准或者审核权限等。
而第二应用为能够满足订单任务需要的应用，这里的“第一”和“第二”仅用于区分不同的应用，没有特殊含义。
本申请实施例中所记载的订单类型可以根据订单内容确定，例如：若订单内容是购物，那么第二应用应属于一个提供购物服务的应用；若订单内容是旅行，那么第二应用应属于一个提供旅行服务的应用，或者属于一个提供交通服务的应用，或者属于一个提供住宿服务的应用；也可以根据订单性质确定，例如：订单的性质属于支付订单，那么第二应用应属于一个能够提供支付服务的应用，这里不做限定。
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图1为本申请实施例提供的一种订单任务处理方法的流程示意图。所述方法可以如下所示。
步骤101：第一应用接收订单任务处理请求。
在本申请实施例中，第一应用可以接收用户通过其他应用触发的订单任务处理请求，也可以通过第一应用上的对外接口接收用户触发的订单任务处理请求，还可以通过第一应用中安装的其他微应用接收用户触发的订单任务处理请求。
例如：第一应用接收用户通过其他微应用(需要说明的是，这里的微应用可以是指以一个应用为基础，在其搭建的应用平台上实现的其他应用功能，微应用的开发者可以与第一应用的开发者相同，也可以与第一应用的开发者不同，这里不做具体限定)触发的订单任务处理请求。再例如：在一个即时通信应用软件中增加了用于差旅管理的微应用，那么可以通过该微应用创建与差旅有关的任务(例如：在该任务中填写出差时间、出差地点等)，用户将创建的与差旅有关的任务对应的订单任务通过微应用向第一应用发送订单任务处理请求。第一应用接收到该订单任务处理请求之后需要为订单任务进行处理。
这里的处理包含但不限于：推送交通信息、推送住宿信息、推送天气信息、审核处理、支付处理等等。
步骤102：所述第一应用根据所述第一应用与至少一个第二应用之间的合作关系以及所述订单任务处理请求中包含的订单类型，从与所述订单类型相匹配的所述第二应用中获取数据。
在本申请实施例中，所述第一应用根据所述订单任务处理请求中包含的订单类型，从与所述第一应用之间建立合作关系的第二应用集合中确定出与所述订单类型相匹配的第二应用。
作为一个应用能够处理的订单任务的订单类型多种多样，那么第一应用可以预先与多个第二应用建立合作关系，这样，第一应用在接收到订单任务处理请求时能够从建立合作关系的第二应用集合中筛选出与确定出与所述订单类型相匹配的第二应用，并从确定的所述第二应用中获取数据。
可选地，在本申请实施例中，所述第一应用根据所述订单任务处理请求中包含的生成订单所使用的第一账户，确定生成所述订单所使用第一账户的账户类型，所述第一账户为所述用户在所述第一应用中注册的；
所述第一应用根据所述账户类型，从与所述订单类型相匹配的所述第二应用中获取数据。
具体地，若所述账户类型为非企业账户类型，则所述第一应用在确定所述第一账户与第二账户之间建立映射关系时，利用所述第二账户访问所述第二应用，并从所述第二应用中获取数据，所述第二账户为所述用户在确定的所述第二应用中注册的。
即由于所述账户类型为非企业账户类型，说明该订单任务由用户通过个人账户产生，那么此时第一应用可以利用用户在第二应用中注册的第二账户访问第二应用，这里访问第二应用可以理解为向第二应用对应的应用服务器发送数据获取请求，该数据获取请求中包含订单类型和/需要获取的数据类型，使得第二应用对应的应用服务器在接收到数据获取请求时，将第一应用需要的数据返回给第一应用对应的应用服务器，并显示在第一应用的显示界面中；也可以理解为生成激活第二应用运行的消息，跳转至第二应用的显示界面中，以从所述第二应用的显示页面中获取数据。
若所述账户类型为企业账户类型，则所述第一应用在确定所述第一账户注册在所述第二应用中时，根据所述第一账户在所述第二应用中的用户权限，从所述第二应用中获取与所述用户权限相应的数据。
由于在实际生活中企业与各种服务商之间协商，建立不同权限的合作关系，那么若所述账户类型为企业账户类型，则说明该订单任务由用户通过企业账户产生，那么此时第一应用可以利用该企业账户确定该企业账户在第二应用中的用户权限，进而从第二应用中获取与该用户权限相应的数据。
例如：在订单任务处理时需要获取订酒店的数据，那么假设该企业与第二应用开发者之间协商，该企业从第二应用平台上预定酒店可以享受8折优惠，那么从第二应用中获取到的酒店数据中的价格数据也可以享受8折优惠。
可选地，在实际应用中，对于出差者来说，可以自己生成差旅订单，但是为了保证出差者所生成的差旅订单中的差旅数据不超出出差者的差旅标准，还需要对出差者生成的差旅订单进行审核，即需要对用户发送的订单任务进行审核。
具体地，若所述账户类型为非企业账户类型且所述订单为因公差旅订单，那么所述第一应用在从所述第二应用中获取数据之前，确定所述第一账户所属的企业群，并根据所述第一账户的用户权限，从所述企业群中选择用户权限高于所述第一账户的第三账户；并向所述第三账户发送订单处理审核请求。
所述第一应用在接收到所述第三账户返回的审核通过消息时，从所述第二应用中获取与所述第一账户的差旅标准相匹配的差旅数据。
步骤103：所述第一应用基于获取到的数据对所述订单任务处理请求进行处理。
在本申请实施例中，所述第一应用基于获取到的所述差旅数据，生成差旅支付订单；并按照预设的支付规则，对所述差旅支付订单执行支付操作。
需要说明的是，这里预设的支付规则可以根据生成订单任务的账户权限进行设置，即非企业账户类型的账户可以个人进行支付，也可以在审核通过之后由企业进行支付；企业账户类型的账户由企业进行支付，这里不做具体限定。
这里的支付方式可以采用预支付的方式、实缴方式等等，这里不做具体限定。
具体地，所述第一应用确定所述第一账户所属的企业群的支付账户以及拥有支付权限的第四账户；所述第一应用向所述第四账户发送支付请求，所述支付请求中包含所述支付账户和所述差旅支付订单；所述第一应用在接收到所述第四账户发送的确认支付消息时，对所述差旅支付订单执行支付操作。
可选地，所述第一应用在确定对所述差旅支付订单完成支付操作时，生成差旅服务卡片，以为所述用户提供差旅服务。
在本申请实施例中对于基于该差旅服务卡片为用户提供差旅服务的相关的内容可以参见图3中所示的内容，这里不再详细描述。
通过本申请实施例提供的技术方案，对于第一应用接收到订单任务处理请求，通过第一应用与其他应用之间的合作关系，能够快捷从其他应用中获取到相关数据，进而实现对订单任务处理请求的快速处理。这样，对于一些企业管理软件，通过本申请所提供的方案，能够很好的与旅行软件建立互联互通，便捷地从旅行软件中获取与差旅相关的信息，进而在企业管理软件中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
图2为本申请实施例提供的一种订单任务处理设备的结构示意图。所述订单任务处理设备包括：接收模块21、获取模块22和处理模块23，其中：
接收模块21，接收用户发送的订单任务处理请求；
获取模块22，根据所述第一应用与至少一个第二应用之间的合作关系以及所述订单任务处理请求中包含的订单类型，从与所述订单类型相匹配的所述第二应用中获取数据；
处理模块23，基于获取到的数据对所述订单任务处理请求进行处理。
在本申请的另一个实施例中，所述获取模块22从与所述订单类型相匹配的所述第二应用中获取数据，包括：
根据所述订单任务处理请求中包含的订单类型，从与所述第一应用之间建立合作关系的第二应用集合中确定出与所述订单类型相匹配的第二应用。
在本申请的另一个实施例中，所述获取模块22从与所述订单类型相匹配的所述第二应用中获取数据，包括：
根据所述订单任务处理请求中包含的生成订单所使用的第一账户，确定生成所述订单所使用第一账户的账户类型，所述第一账户为所述用户在所述第一应用中注册的；
根据所述账户类型，从与所述订单类型相匹配的所述第二应用中获取数据。
在本申请的另一个实施例中，所述获取模块22根据所述账户类型，从与所述订单类型相匹配的所述第二应用中获取数据，包括：
若所述账户类型为非企业账户类型，则在确定所述第一账户与第二账户之间建立映射关系时，利用所述第二账户访问所述第二应用，并从所述第二应用中获取数据，所述第二账户为所述用户在确定的所述第二应用中注册的；
若所述账户类型为企业账户类型，则在确定所述第一账户注册在所述第二应用中时，根据所述第一账户在所述第二应用中的用户权限，从所述第二应用中获取与所述用户权限相应的数据。
在本申请的另一个实施例中，所述订单任务处理设备还包括：发送模块24，其中：
若所述账户类型为非企业账户类型且所述订单为因公差旅订单，那么所述发送模块24在从所述第二应用中获取数据之前，确定所述第一账户所属的企业群，并根据所述第一账户的用户权限，从所述企业群中选择用户权限高于所述第一账户的第三账户；向所述第三账户发送订单处理审核请求；
所述获取模块22从所述第二应用中获取数据，包括：
在接收到所述第三账户返回的审核通过消息时，从所述第二应用中获取与所述第一账户的差旅标准相匹配的差旅数据。
在本申请的另一个实施例中，所述处理模块23基于获取到的数据对所述订单任务处理请求进行处理，包括：
基于获取到的所述差旅数据，生成差旅支付订单；并按照预设的支付规则，对所述差旅支付订单执行支付操作。
在本申请的另一个实施例中，所述处理模块23按照预设的支付规则，对所述差旅支付订单执行支付操作，包括：
确定所述第一账户所属的企业群的支付账户以及拥有支付权限的第四账户；
向所述第四账户发送支付请求，所述支付请求中包含所述支付账户和所述差旅支付订单；
在接收到所述第四账户发送的确认支付消息时，对所述差旅支付订单执行支付操作。
在本申请的另一个实施例中，所述订单任务处理设备还包括：生成模块25，其中：
所述生成模块25，在确定对所述差旅支付订单完成支付操作时，生成差旅服务卡片，以为所述用户提供差旅服务。
需要说明的是，本申请实施例提供的订单任务处理设备可以通过软件方式实现，也可以通过硬件方式实现，这里不做具体限定。订单任务处理设备对于接收到的订单任务处理请求，通过第一应用与其他应用之间的合作关系，能够快捷从其他应用中获取到相关数据，进而实现对订单任务处理请求的快速处理。这样，对于一些企业管理软件，通过本申请所提供的方案，能够很好的与旅行软件建立互联互通，便捷地从旅行软件中获取与差旅相关的信息，进而在企业管理软件中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
下面实施例以订单任务为差旅任务为例进行详细说明。
图3为本申请实施例提供的提供差旅服务的过程，具体包括以下步骤：
s301：接收用户发送的差旅处理请求。
为了实现对企业员工差旅的便捷管理，在本申请实施例中，当用户接收到企业领导下发的出差通知时，可通过自己所持有的用户终端，登录到用于企业管理的第一应用中，具体的实现方式可以是：用户可通过预先在该第一应用中注册的第一账号，在该第一应用的登录窗口中进行登录，其中，所述用户终端可以是诸如智能手机、电脑等终端设备，这里提到的第一应用为用于企业管理的应用。
当用户通过自己所持有的用户终端登录到该第一应用中后，可在该第一应用的界面中，根据自身的出差需求，在该界面中实施操作，而该第一应用在此过程中可对该用户在第一应用界面中实施的操作进行监测，并根据用户实施的操作，生成相应的差旅处理请求，即用户根据出差需求在第一应用提供的出差信息填写界面中输入出差信息，并将该出差信息提交给所述第一应用，此时第一应用能够接收到用户发送的差旅处理请求。其中，该第一应用向用户展示的界面如图4a、4b、4c所示。
图4a、4b、4c为本申请实施例提供的第一应用向用户展示的界面示意图。
当用户需要向企业申请出差时，可通过预先在第一应用中注册的第一账号，登录到该第一应用中，而后，该第一应用可向该用户显示如图4a所示的显示界面；用户可通过点击图4a中所示的差旅服务控件，跳转至如图4b所示的差旅服务界面中；用户可点击图4b中所示的差旅申请控件，跳转至如图4c所示的差旅选择界面中，在图4c所示的差旅选择界面中列有包含差旅往返时间、差旅出行形式(飞机、火车、客车、轮船)以及差旅往返地点等不同的内容，用户可通过在图4c所示的差旅选择界面中输入此次差旅的往返时间、往返地点、以及此次差旅的出行形式等内容。
用户在图4c所示的差旅选择界面中输入完与此次差旅相关的内容，可点击图4c中所示的确定控件，而该第一应用一旦监测到用户对确定控件执行操作，将对用户在图4c所示的差旅选择界面中输入的与此次差旅相关的内容进行确认，从而根据确定的内容，生成相应的差旅处理请求。从整个过程中来看，该第一应用相当于通过监测图4c所示的差旅选择界面中的确定控件是否被操作，一旦被操作视为接收用户发送的差旅处理请求，而该差旅处理请求则是根据用户在图4c所示的差旅选择界面中输入的内容生成的。
需要说明的是，第一应用除了可通过上述方式接收用户发送的差旅处理请求外，还可通过接收第三应用发送的差旅服务信息，获取用户发送的差旅处理请求。具体的，用户可在能够提供差旅服务的第三应用中输入与差旅相关的信息(如，差旅往返时间、差旅往返地点、差旅出行方式等信息)，并通过该第三应用生成相应的差旅数据单，该差旅数据单中记录用户此次差旅的出行信息，而后，用户可将该差旅数据单通过该第三应用发送至该第一应用中，该第一应用在接收到该差旅数据单后，可根据该差旅数据单中所记录的差旅数据，生成对应的差旅处理请求，即，相当于接收到用户通过第三应用发送的差旅处理请求，其中，通过第三应用向第一应用发送差旅数据单时，需要预先将该用户在第一应用中所使用的第一账号与该用户在该第三应用中所使用的账号进行关联，这样，第三应用才能根据预先建立的账号关联关系，将差旅数据单发送至该第一应用中。
例如，假设用户a通过预先注册在第三应用中的用户账号a登录到该第三方应用后，可在该第三应用的差旅数据界面中选取各差旅控件(当然也可以在差旅数据界面中直接输入差旅数据)，当用户a在该第三应用中确定自己所选取的各差旅控件后，该第三应用将根据用户所选取的差旅控件，生成对应差旅数据单，并呈现给用户。而后，用户可在该第三应用中发送选择列表中选取该差旅数据单的发送目的地，当用户在该发送选择列表中选取了需要将该差旅数据单发送至第一应用中，则该第三应用可根据预先建立的用户账号a与用户a在第一应用中注册的第一账号之间的关联关系，将该差旅数据单发送至该第一应用的第一账号中，相应的，当该第一应用通过该第一账号接收到第三应用发送的差旅数据单时，可根据该差旅数据单中所记录的信息，生成对应的差旅处理请求，从而相当于接收用户通过第三应用发送的差旅处理请求。
需要说明的是，这里记载的第三应用可以是除了本申请实施例中记载的第一应用、第二应用之外的其他应用，也可以是本申请实施例中记载的第二应用，也就是说，差旅任务产生不限于在第一应用中产生，也可以是在第一应用中的某一个微应用中产生，这里不做具体限定。
在实际应用中，企业领导在委派企业员工出差时，通常都会预先通过第一应用向该企业员工发送一个出差通知，该出差通知中通常都会记录有整个出差的详细信息，如，差旅往返时间、差旅往返地点等信息，所以，为了进一步的方便用户的出差申请，在本申请实施例中，用户(即企业员工)通过第一应用接收到其他用户(这里的其他用户可以是企业领导，也可以是其他企业员工)发送的关于差旅通知的信息后，该第一应用可根据该信息中所包含内容，识别出该信息为差旅通知，当该第一应用监测到用户对该差旅通知执行指定操作时(如点击该差旅通知中的确认执行控件，或长按该差旅通知的文本显示框等)，该第一应用可提取出该差旅通知中涉及的差旅数据，并根据提取出的差旅数据，生成对应的差旅处理请求，即相当于当监测到用户对该差旅通知执行指定操作时，接收到用户发送的差旅处理请求。
除了上述说明的几种方式外，在本申请实施例中，该第一应用中还可设置有关于差旅的语音接收功能，当用户启动该语音接收功能时，可将差旅数据通过语音的方式输入的该第一应用中，在此过程中，该第一应用可采集该用户的语音信息，并通过预设的语音识别模型，识别出该语音信息中所包含的差旅数据，如，差旅往返时间、差旅往返地点、差旅出行方式等，并根据识别出的差旅数据，生成对应的差旅处理请求，即，相当于通过语音采集的方式接收到用户发送的差旅处理请求。
s302：根据所述差旅处理请求，生成对应的差旅订单。
当第一应用接收到用户发送的差旅处理请求后，可根据该差旅处理请求中所涉及的差旅内容，生成对应的差旅订单并进行显示，例如，第一应用接收到用户发送的差旅处理请求后，可确定出该差旅处理请求所涉及的差旅内容为：差旅往返时间为2016年5月4日～2016年5月19日，差旅往返地点为北京-上海，差旅出行方式为飞机，则第一应用可根据这些差旅内容，生成2016年5月4日～2016年5月19日，飞机往返北京-上海的差旅订单，并进行显示。
为了更加清楚、简洁、规整的显示出生成的差旅订单，在本申请实施例中，第一应用可根据接收到的差旅处理请求，生成以行程卡片的方式进行展示的差旅订单，如图5所示。
图5为本申请实施例提供的以行程卡片的方式展示差旅订单的示意图。
第一应用可根据接收到的差旅处理请求，生成如图5所示的差旅订单，该差旅订单以行程卡片的方式展示在该第一应用的界面中，用户可通过行程卡片直观的查看到此次差旅的往返信息以及出行方式，从而给用户带来了方便。
当然，除了以行程卡片的方式来展示差旅订单外，也可采用其他的展示方式，如以一个单独的页面来显示整个差旅订单等，在此就不进行一一说明了。
s303：当监测到所述差旅订单满足预设的条件时，从第二应用中获取与所述差旅订单相关的差旅数据，并根据所述差旅数据为所述用户提供差旅服务。
对于一个企业来说，企业员工的出差申请通常都需要经过审核，一来是防止企业员工利用企业资源办理私事，二来是为了保证企业员工的上班出勤，防止企业员工利用上班时间来私自外出，当然，除此之外，出差申请的审核还能为企业后续进行出差统计提供有利的依据，总而言之，出差申请的审核在企业管理中占有至关重要的地位。
基于上述原因，在本申请实施例中，当第一应用根据接收到的差旅服务出来请求，生成对应的差旅订单后，并不是立刻就从第二应用中获取与该差旅订单相关的差旅数据的，而是需要监测该差旅订单是否满足预设的条件，若是，则从第二应用中获取与该差旅订单相关的差旅数据，若否，则可向用户提示修改该差旅订单，其中，这里提到的该差旅订单是否满足预设的条件指的是当生成该差旅订单后，第一应用需要监测该差旅订单是否通过出差申请的审核，若该差旅订单通过出差审核，则确定出该差旅订单满足预设的条件，继而从第二应用中获取与该差旅订单相关的差旅数据。
对于差旅订单的审核方式，可采用以下方式：企业员工出差申请的审核工作通常都需要企业领导或企业主管来完成，企业领导或企业主管需要核实企业员工所提出的出差申请，以确保该出差申请是否为企业指派的出差申请。因此，在本申请实施例中，若第一应用根据接收到的差旅处理请求，生成对应的差旅订单，可将该差旅订单发送给该第一应用中的第一指定用户，其中，该第一指定用户即为能够对该差旅订单进行审核的企业领导或企业主管，而该第一应用在将该差旅订单发送给第一应用中的第一指定用户的过程中，用户可在该第一应用所保存的企业通讯录中找到能够对该差旅订单进行审核的第一指定用户，进而通过该第一应用，将该差旅订单发送给该第一指定用户。
除了上述说明的方式以外，在本申请实施例中，该第一应用也可自动将该差旅订单发送给该第一指定用户，无需用户主动进行操作，这是因为，在实际应用中，企业领导或是企业主管通常都是在该第一应用中具有特殊权限用户，如群组中的群主、管理员等，因此，在本申请实施例中，该第一应用在生成该差旅订单后，可将该差旅订单发送至该第一应用中该用户所属的企业群组中的群主或管理员(即第一指定用户)，并对该差旅订单的审核状态进行监测，当第一指定用户对该差旅订单进行审核并执行审核通过操作时，该第一应用可监测到该差旅订单的审核状态为已通过，则可确定出该差旅订单满足预设的条件，进而在后续过程中从第二应用中获取与该差旅订单相关的差旅数据，其中，对于差旅订单审核状态的显示方式如图6a、6b所示。
图6a、6b为本申请实施例提供的差旅订单的审核状态显示示意图。
当用户通过第一应用发起一个出差申请(即相当于该第一应用接收用户发送的差旅处理请求)时，该第一应用可根据该出差申请，生成如图6a中所示的行程卡片(该行程卡片即为差旅订单)并进行展示，该行程卡片上标有如图6a所示的审核状态，从图6a中可以看出，该行程卡片当前正处于审核过程中，而一旦第一应用监测到该行程卡片企业领导或企业主管(即第一指定用户)的审核后，可将该行程卡片上所标注的审核状态更新为已审核状态，如图6b所示，这种显示可以使用户直观的查看到自己提出的出差申请当前时刻的审核状态，为用户后续的出差申请操作提供了便利。
需要说明的是，第一应用除了可将生成的差旅订单发送给第一应用中的第一指定用户来审核该差旅订单外，在本申请实施例中，该第一应用也可自动完成对该差旅订单的审核工作。具体的，在实际应用中，企业领导或企业主管通常都会通过第一应用来向用户发送出差通知，该第一应用中通常都会对该出差通知进行保存，因此，在本申请实施例中，第一应用可根据保存的各出差通知，来审核当前生成的差旅订单是否为有效的差旅订单，具体的实施方式可以是：当第一应用根据接收到的差旅处理请求，生成对应的差旅订单后，可将该差旅订单中的差旅特征信息进行提取(差旅特征信息可以是差旅往返时间、差旅往返地点、差旅出行形式等信息)，而后，该第一应用可将该差旅特征信息与保存的各出差通知的内容进行比对，若监测到某一出差通知与该差旅特征信息相匹配，则确定差旅订单审核通过，即，该差旅订单满足预设的条件，而若该第一应用未在各出差通知中查找到与该差旅特征信息相匹配的出差通知，则可将该差旅订单再发送给该第一应用中的第一指定用户(即企业领导或企业主管)，并通过该第一指定用户来完成该差旅订单的审核工作。
对于从第二应用中获取与该差旅订单相关的差旅数据的获取方式来说，在本申请实施例中，当第一应用监测到该差旅订单满足预设的条件时(即该差旅订单审核通过)，则可激活该差旅订单中的指定控件(当然也可以生成该指定控件)，若监测到用户对该指定控件执行操作，则激活第二应用，并加载该第二应用的差旅数据提供界面，其中，加载的该第二应用的差旅数据提供界面中包含有该第二应用根据该第一应用中所呈现的差旅订单，向该第一应用提供与差旅订单相关的差旅数据，如图7a、7b所示。
图7a、7b为本申请实施例提供的第一应用从第二应用中获取与差旅订单相关的差旅数据的示意图。
在图7a中，差旅订单中设有两个指定控件，该指定控件可以根据差旅订单的内容进行生成，如，当该差旅订单涉及的内容为乘飞机出差时，则第一应用可在该差旅订单中生成订飞机的指定控件、订酒店的指定控件，而当该差旅订单涉及的内容为乘火车出差时，则第一应用可在该差旅订单中生成订火车的指定控件、订酒店的指定控件。该指定控件的状态是与差旅订单的审核状态相对应的，即，当第一应用监测到该差旅订单处于审核中或审核未通过时，在该指定控件处于未激活状态，即，用户无法对该指定控件执行操作(当然也可以是在该差旅订单未通过审核时，该第一应用不会生成这两个指定控件)，而若第一应用监测到该差旅订单处于审核已通过，则第一应用将激活该指定控件，用户可对处于激活状态的指定控件执行操作，从而当该第一应用监测到用户对该指定控件执行了控件操时，则激活第二应用，并跳转到如图7b所示的该第二应用的差旅数据提供界面中。
第二应用可根据第一应用所提供的差旅订单，向用户显示与该差旅订单相关的差旅控件，如在图7b中，当用户选取了差旅订单中的订飞机控件后，则第一应用会将第二应用中订飞机的控件界面跳转出来，以供用户进行选取，其中，第二应用向用户所展示的控件界面是已根据差旅订单筛选过的，如，当差旅订单中的内容为2016年6月3日～2016年6月23日，北京-杭州，飞机出行时，第二应用向用户所展示的控件界面应为如图7b所示的2016年6月3日～2016年6月23日，北京-杭州，飞机航班控件的界面，用户可直接在该飞机班次控件中需求适合的班次，而无需再手动输入差旅往返时间、差旅往返地点等信息，从而为用户提供了方便。
当然，除了上述说明的方式外，在本申请实施例中，若第一应用监测到差旅订单满足预设的条件(即该差旅订单审核通过)，则可向第二应用发送用于获取与该差旅订单相关的差旅数据的消息，而该第二应用在接收到第一应用中发送的该消息后，可根据该消息，向第一应用提供与该差旅订单相关的差旅数据，从而使得该第一应用获取到第二应用根据该消息所返回的与该差旅订单相关的差旅数据。整个过程相当于第一应用与第二应用之间通过预先设置的接口，实现差旅数据的传输。
除了上述说明的两种方式以外，在本申请实施例中，第一应用在监测到差旅订单满足预设的条件后，可通过h5的方式，获取到第二应用的差旅网页，该差旅网页是根据差旅订单的内容而生成的，用户可在该在该差旅网页中选取差旅控件，从而使得该第一应用可根据用户在该差旅网页中选取的控件，获取到与该差旅订单相关的差旅数据，即相当于从第二应用中获取到与该差旅订单相关的差旅数据。
用户除了可通过第二应用所展示的差旅数据提供界面手动选择各差旅内容外，第二应用还可根据第一应用中的差旅订单，自动生成与该差旅订单相关的差旅数据，以供用户后续进行选择。例如，假设第一应用生成的差旅订单的内容为2016年6月3日～2016年6月23日，北京-杭州，飞机出行时，第二应用可根据该差旅订单直接替用户筛选出合适的各航班，并对应生成各差旅数据，而后，第一应用可从该第二应用中获取到各差旅数据并显示，以供用户进行选择。
需要说明的是，第一应用从第二应用中获取与该差旅订单相关的差旅数据的一个前提条件是第一应用中具备能够访问第二应用的接口，在此基础之上，可选地，还可以建立用户在第一应用中的第一账号与该用户在第二应用中的第二账号之间的关联关系，所以，在本申请实施例中，第一应用在从第二应用中获取与该差旅订单相关的差旅数据之前，需要首先确定第一应用中具备能够访问第二应用的接口，其次判断该第一账号与第二账号是否存在关联关系，其中，第一账号为该用户预先在该第一应用中注册的用户账号，而该第二账号为该用户预先在该第二应用中注册的用户账号。
当第一应用确定该第一账号与第二账号存在关联关系时，该第一应用可通过该第二账号登录到该第二应用，即相当于通过该第二账号激活该第二应用，使得该第二应用将与该差旅订单相关的差旅数据提供界面显示给用户。除此之外，该第一应用也可直接通过该第二账号，向第二应用发送用于获取与该差旅订单相关的差旅数据的消息，从而在后续过程中接收第二应用根据该消息所返回的与该差旅订单相关的差旅数据。而若第一应用确定出第一账号与第二账号未存在关联关系，则可获取第二应用的登录窗口并展示给用户，使得用户通过在该登录窗口中输入第二账号来登录该第二应用。与此同时，该第一应用可将用户输入的第二账号进行记录并建立与该第一账号的关联关系，以备后续使用。
在实际应用中，用户的一次出差可能会需要往返多个地方，如一个用户的出差行程可能是先由北京至上海，再由上海至广州，再由广州至南京，最后再从南京返回北京，针对这种一次出差涉及多个行程的情况来说，为了使用户后续能够清楚的对各行程进行查看以及操作，在本申请实施例中，当第一应用从第二应用中获取到与该差旅订单中相关的差旅数据后，可进一步根据该差旅数据，生成对应该差旅订单中各行程的各子差旅订单。
各子差旅订单正常状态下可隐藏在差旅订单中，当第一应用监测到用户对该差旅订单执行诸如长按、点击等指定操作后，该第一应用可将隐藏在该差旅订单中的各子差旅订单按照差旅订单中各行程的时间顺序进行排列并展示给用户，其中，各子差旅订单也可以各行程卡片的方式进行显示，如图6所示。
图8为本申请实施例提供的各子差旅订单的展示方式示意图。
在图8中，第一应用以行程卡片的方式展示了差旅订单以及各子差旅订单，其中，标有北京-南京的行程卡片为差旅订单，而标有北京-上海、上海-广州、广州-南京、南京-北京的行程卡片则为第一应用根据从第二应用中获取的与该差旅订单相关的差旅数据所生产的各子差旅订单，除了差旅订单所对应的行程卡片，其他的行程卡片平时可隐藏在该差旅订单所对应的行程卡片中，当第一应用监测到用户对该差旅订单所对应的行程卡片执行了点击操作时(即用户对该差旅订单执行了指定的操作)，则隐藏的行程卡片可从差旅订单所对应的行程卡片中弹出，并按照各行程的时间顺序从上到下依次排列并显示。这种展示方式对于用户来说一目了然，用户只需简单的操作，即可直观的查看到此次差旅过程中所涉及到的各行程卡片，从而给用户提供了方便。
对于企业的差旅管理中，差旅费用结算则是至关重要的一个环节。为了提供灵活多变的方式，企业可通过第一应用对企业员工的差旅结算制定多种结算规则，如企业负责结算、企业员工个人结算以及企业与个人混合结算等规则，这些规则用户可自行选择，企业也可根据企业员工的等级来规定该企业员工所能使用的结算规则。所以，第一应用在对差旅订单进行结算时，可先确定出该用户在第一应用中的结算规则，而后，该第一应用可根据该结算规则，对该差旅订单所需的费用进行结算，其中，第一应用当监测到该用户对该差旅订单执行了结算操作时，则可根据该用户在第一应用中的结算规则，对该差旅订单所需的费用进行结算，如图9a、9b所示。
图9a、9b为本申请实施例提供的差旅订单结算示意图。
图9a所示的差旅订单所对应的行程卡片中设有一个支付控件，若第一应用监测到用户对该支付控件执行操作时，可根据该用户在第一应用中的结算规则，对该差旅订单所需的费用进行结算。而对于图9b来说，由于图9b中显示有多个子差旅订单所对应的行程卡片，每个子差旅订单所对应的行程卡片中都设有支付控件，针对每个子差旅订单所对应的行程卡片来说，当第一应用监测到用户对该行程卡片上设置的支付控件执行点击操作时，可根据该用户在该第一应用中的结算规则，对该行程卡片所对应的子差旅订单所需的费用进行结算。
由于企业针对企业员工所制定的结算规则中包含有企业结算、个人结算、企业与个人混合结算等规则，因此，当第一应用在对差旅订单进行结算的过程中，确定出该差旅订单所需的费用需要用户自行结算时，则可通过该用户的第一账号对该差旅订单所需用户进行结算的费用进行结算。而对于企业结算和企业与个人混合结算的结算规则来说，负责对企业员工的差旅费用进行企业结算的人员通常都是企业中的资金管理人员，如会计等，所以，当第一应用根据用户在第一应用中的结算规则确定出该差旅订单的费用(全部费用或部分费用)需要该用户所属的企业进行结算时，则当该用户对该差旅订单执行了结算操作时，该第一应用可将该差旅订单发送给第一应用中的第二指定用户(该第二指定用户即为负责管理企业资金的人员)，该第二指定用户在接收到该差旅订单后可利用企业资金对该差旅订单所需的费用(全部费用或部分费用)进行结算，而第一应用一旦监测到该第二指定用户完成了对该差旅订单的结算工作后，则可将该差旅订单的结算状态更新为已结算状态，从而完成该差旅订单的结算工作。
需要说明的是，在企业账户在第一应用进行注册时，还可以通过提交发票信息，这样不管是企业完成支付还是个人完成支付，能够自动获取发票信息，以便于获取报账需要的发票。
这样不管是企业支付还是个人支付，能够自动获取发票数据，为后续财务报销做准备。
在本申请实施例中，第一应用在完成差旅订单的支付之后，将生成差旅服务卡片，以便于后续为用户提供差旅服务。那么第一应用在完成差旅订单的支付之后，将差旅订单中的数据存储至服务器中，并建立差旅订单中的数据与企业账户之间的映射关系。
若差旅订单中包含的账户类型为非企业类型，则根据账户名称确定该账户名称所属的企业账户，进而建立差旅订单中的数据与企业账户之间的映射关系，使得财务人员详细了解本次差旅的消费数据，以准确地为用户差旅报销。
一方面，对于企业用户，可以由企业的管理者利用企业账户在第一应用所提供的管理平台中查询历史差旅数据，使得差旅管理流程化；另一方面，第一应用所提供的管理平台(即服务器)还可以基于企业用户的历史差旅数据，为企业用户提供差旅分析报告，并根据差旅分析报告的结果为企业用户提供差旅优化策略，以提升企业差旅管理的精确性。
需要说明的是，在实际应用中，每个企业员工所对应的差旅标准均存在差异，有些企业员工的差旅标准较高，有些则较低，为了有效的控制企业的差旅费用，企业可通过该第一应用对该企业的每个企业员工进行差旅标准的设置，该差旅标准的设置工作通常都是由该企业的企业领导或企业主管设置的，而对于每个企业员工来说，各自的预设差旅标准均可在第一应用中进行查看，如图10a、10b所示。
图10a、10b为本申请实施例提供的查看预设差旅标准的示意图。
在图10a中显示有差旅标准的控件，当用户通过自己预先在该第一应用中注册的第一账号登录到该第一应用中时，点击该差旅标准的控件将弹出该用户的预设差旅标准，如图10b所示，该用户不仅能够通过图10b所示的差旅标准界面查看到自己的预设差旅标准，第一应用在后续过程中也可通过该预设差旅标准对差旅订单的结算费用实施管控。
为了实现对差旅订单结算费用的有效管控，第一应用在对该差旅订单进行费用结算之前，可先根据用户所对应的预设差旅标准，判断该差旅订单所需的结算费用是否超出该预设差旅标准，若是，则确定出该差旅订单的结算费用已超标，并提示用户修改该差旅订单，若否，则确定出该差旅订单的结算费用符合标准，进而根据该用户在第一应用中的结算规则，对该差旅订单所需的费用进行结算。
考虑到差旅订单所需的费用会随着月份、节日等因素发生变化，如，当航班紧张时，差旅订单的费用可能会相应的提供，再如，当遇到节假日时，酒店的费用可能会随着上涨，从而影响差旅订单的结算费用发生变化。换句话说，差旅订单所需的费用除了因用户没有注意预设差旅标准而出现超标外，客观因素同样会对差旅订单所需的费用造成影响。
为了避免客观因素对差旅订单费用结算过程中所产生的不利影响，在本申请实施例中，当第一应用根据用户的预设差旅标准，确定出该差旅订单所需的结算费用已超标时，则可将该差旅订单发送给第一应用的第一指定用户(如企业领导或企业主管等)进行二次审核，若监测到该差旅订单通过该第一指定用户的二次审核，则该第一应用可根据该用户在第一应用中的结算规则，对该差旅订单所需的费用进行结算。而若该第一应用监测到该差旅订单未通过该第一指定用户的二次审核，则可提示该用户对该差旅订单进行修改，已使修改后的差旅订单所需的结算费用符合预设差旅标准。
为了进一步为用户的差旅过程中提供方便，在本申请实施例中，当第一应用完成对差旅订单的结算工作后，该第一应用可对用户当前的状态信息实施监测，该状态信息包含但不限于用户当前的时间信息、用户当前的位置信息等。第一应用可根据预设的提醒规则，确定与该状态信息相匹配的子差旅订单，进而根据该子差旅订单以及确定出的用户当前的状态信息，向用户推送与该子差旅订单相关的服务信息。其中，该子差旅订单为用户未完成的行程所对应的子差旅订单。
例如，假设第一应用中的一个子差旅订单中显示用户b需要在2016年7月8日19点23分从北京飞机场乘坐飞机去上海，由于该子差旅订单处于未进行状态(即该子差旅订单为用户还未完成的行程所对应的子差旅订单)，所以第一应用需要时刻获取该用户当前的状态信息，当监测到当前时间为2016年7月8日16点时，则可提示该用户赶往飞机场准备乘机，并根据用户b当前所处的位置，向该用户b推送去往飞机场的乘车信息等。
再如，假设第一应用中的一个子差旅订单显示用户c需要在2016年8月13日20点入住某酒店，因此，当第一应用确定出当前的时间信息为2016年8月13日18点时，则可根据用户当前所处的位置信息，以及该酒店的位置信息，向该用户c提供乘车路线信息，并与此同时向该用户c推送一些关于该酒店的餐饮信息，以供用户c进行参考。
第一应用除了可根据用户当前的状态信息，向用户推送一些关于差旅订单的服务信息外，还获取与子差旅订单相关的一些状态变更信息，如航班延误等，该第一应用可将获取到的诸如航班延误等状态变更信息显示在相应的子差旅订单上，以提醒用户该子差旅订单所涉及的行程出现状况，使得用户可根据显示在该子差旅订单上的状态变更信息提前进行行程变更的准备工作。
还需说明的是，在实际应用中，用户在差旅的过程中时常会遇到行程变更的情况，这时，用户可在该第一应用中对涉及行程变更的子差旅订单或差旅订单进行修改并执行确定操作，而第一应用在监测到用户对该差旅订单中的行程执行变更操作后，可先根据先前的差旅订单，确定出用户变更的行程以及未变更的行程，并重新生成新的差旅订单，而后，该第一应用可将该重新生成的差旅订单发送给该第一应用中的第一指定用户(即企业领导或企业主管等)进行审核，当监测到该重新生成的差旅订单通过该第一指定用户的审核后，则可根据该用户在第一应用中的结算规则，对该重新生成的差旅订单中还未结算的费用进行结算，而对已经结算当用户后续将不再进行的行程所对应的费用实施退款。
从上述方法中可以看出，由于应用于企业管理的第一应用在获取到用户发送的差旅处理请求后，可根据该差旅服务请求生成对应的差旅订单，并通过该差旅订单，从用于差旅服务的第二应用中获取与该差旅订单相关的差旅数据，这样，通过企业管理的第一应用即可调用第二应用，并从第二应用中获取与差旅订单相关的差旅数据，进而在第一应用中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
为了进一步的清楚的说明差旅服务处理的整个过程，在本申请实施例中该提供了详细的差旅服务处理过程的示意图，如图11所示。
图11为本申请实施例提供的差旅服务处理的详细过程示意图。
图11中示出了企业领导出差、企业员工因公出差、企业员工因私出差的三种差旅服务处理过程中，对于，企业领导的差旅服务处理过程来说，由于企业领导负责其他企业员工的差旅申请(即差旅订单)审核工作，因此，无需对自己所提出的差旅申请进行审核，而是可直接通过第一应用生成相应的差旅订单，无需对该差旅订单进行审核，后续过程中，第一应用可对该差旅订单所需的结算费用进行判断，若确定出该差旅订单所需的结算费用已超出该企业领导自身所对应的预设差旅标准时，则可将该差旅订单发送至第一应用中的其他第一指定用户(如同级或级别更高的企业领导或企业主管)，当监测到该差旅订单通过第一应用中的其他第一指定用户的审核通过后，则可对该差旅订单所产生的费用进行结算，其中，该第一应用在对该差旅订单进行结算时，需要依据该企业领导在该第一应用的结算规则进行结算，而结算的方式可以是从企业的账户或个人的账户中扣取相应的费用，或是，该第二应用所基于的平台在对该差旅订单所产生的费用进行垫付，并以月结或季结等方式后续与企业或个人进行结算。
对于企业员工的差旅服务处理过程来说，当企业员工通过第一应用申请差旅时，第一应用可接收该用户发送的差旅处理请求，并根据该差旅处理请求生成对应的差旅订单，而后，该第一应用可将该差旅订单发送至该第一应用的第一指定用户(即企业领导或企业主管等)进行审核，当监测到该差旅订单通过该第一指定用户的审核后，则可从第二应用中获取与该差旅订单相关的差旅数据，该第一应用可根据获取到的该差旅数据，对差旅订单所产生的费用结算，在结算过程中，第一应用可根据该企业员工在第一应用中的预设差旅标准，判断该差旅订单所产生的费用是否超标，若是，则将该差旅订单发送给第一指定用户进行二次审核，并当审核通过后对该差旅订单所产生的费用进行结算，而当第一应用确定出该差旅订单所产生的费用已超标，或该差旅订单的二次审核未通过时，则可向该用户提示修改该差旅订单，已使用户修改后的差旅订单所产生的费用符合标准。
对于企业员工或企业领导因私出差的情况来说，用户可通过该第一应用直接进行差旅的预定工作以及差旅订单费用的结算工作，无需其他人员进行审核。
例如：以员工出差为例说明第一应用所提供的差旅服务。
第一步，需要出差的用户利用在第一应用中注册的账户登录至第一应用，在第一应用(或者与第一应用关联的微应用)提供的差旅申请界面中输入出差信息(例如：出差时间、出差地点、出差原因等等)，提交至第一应用。此时第一应用在接收到出差信息时生成出差申请单。
可选地，第一应用在接收到出差信息时，确定该用户所在的企业群，并从所述企业群对应的企业人员管理数据库中确定该用户的审核权限，进而基于该审核权限判断该用户的出差申请是否需要审核，若需要，提示用户确定审核人的账户，并在接收到用户输入的审核人的账户时，将出差申请单发送至审核人的账户。
可选地，第一应用在接收到审核人的账户返回的审核通过消息时，提示该用户出差申请通过，并生成差旅订单。
需要说明的是，这里的出差申请审核可以在出差申请的时候执行，也可以是在差旅订单生成之后执行，这里不做具体限定。
第二步，第一应用在确定用户的出差申请单审核通过时，生成/激活指定控件。该指定控件用于建立第一应用与第二应用之间的数据传输通道。
第三步，第一应用当监测到用户触发指定控件时，从第二应用(这里的第二应用可以是能够通过差旅服务的应用)中获取与差旅订单相关的差旅数据。
这里在获取与差旅订单相关的差旅数据时，第二应用可以向第一应用发送差旅标准数据请求，即请求获取该用户的差旅标准数据，这样能够帮助用户过滤一些超差旅标准的差旅数据，提高用户体验。这样当第二应用从第一应用中获取该用户的差旅标准数据时，根据该差旅标准数据向第一应用推送与差旅订单相关的差旅数据。
可选地，第一应用当监测到用户触发指定控件时，从所述企业群对应的企业人员管理数据库中获取该用户的差旅标准数据，并将该差旅标准数据携带在数据获取请求中发送给第二应用。
第四步，第一应用接收用户触发的差旅数据确认消息，并生成差旅支付订单。
第五步，第一应用在差旅支付订单生成时，提示用户选择支付方式以及支付审核人的账户。
若第一应用接收到用户发送的企业支付请求时，需要从所述企业群对应的企业人员管理数据库中获取具备支付功能的审核人的账户，执行第六步。
第六步，第一应用将差旅支付订单发送给支付审核人，并提示支付审核人进行支付。
第七步，第一应用接收支付审核人选择的支付账户以及支付方式，并根据支付方式，跳转至与该支付方式相匹配的界面，已完成支付。
第八步，第一应用在接收到支付应用发送的支付完成消息时，生成差旅服务卡片，以后续为该用户提供差旅服务。
若第五步中，当第一应用接收到用户发送的个人支付请求时，需要从个人支付请求中确定支付审核人的账户，并将差旅支付订单发送给支付审核人。所述第一应用接收到支付审核人发送的确认支付信息时，提示用户执行支付操作。
当第一应用在接收到支付完成消息时，生成报销订单，并从所述企业群对应的企业人员管理数据库中确定具备报销权限的审核人的账户，并将报销订单发送给确定的审核人的账户。
以上为本申请实施例提供的差旅服务处理方法，基于同样的思路，本申请实施例还提供一种差旅服务处理的装置，如图12所示。
图12为本申请实施例提供的差旅服务处理的结构示意图，具体包括：
接收模块1201，接收用户发送的差旅处理请求；
订单生成模块1202，根据所述差旅处理请求，生成对应的差旅订单；
获取信息模块1203，当监测到所述差旅订单满足预设的条件时，从第二应用中获取与所述差旅订单相关的差旅数据，并根据所述差旅数据为所述用户提供差旅服务。
所述接收模块1201，确定用户通过第一账号登录所述第一应用，所述第一账号为所述用户预先在所述第一应用注册的用户账号；接收所述用户通过所述第一账号发送的差旅处理请求。
所述获取信息模块1203，判断所述第一账号与第二账号是否存在关联关系，所述第二账号为所述用户预先在所述第二应用注册的用户账号；若存在，则从第二应用中获取与所述差旅订单相关的差旅数据；若不存在，则获取所述第二应用的登录窗口并展示，并在所述用户成功登陆所述第二应用时从第二应用中获取与所述差旅订单相关的差旅数据。
所述获取信息模块1203，若监测到所述差旅订单通过审核，则确定所述差旅订单满足预设的条件。
所述获取信息模块1203，将所述差旅订单发送给所述第一应用中的第一指定用户进行审核；若当监测到所述第一指定用户对所述差旅订单执行审核通过操作，则确定所述差旅订单通过审核。
所述获取信息模块1203，当监测到所述差旅订单满足预设的条件时，则生成/激活所述差旅订单中的指定控件；当监测到所述用户对所述指定控件执行相应操作时，则从所述第二应用中获取与所述差旅订单相关的差旅数据。
所述获取信息模块1203，向第二应用发送差旅数据获取消息，并接收所述第二应用根据所述差旅数据获取消息返回的与所述差旅订单相关的差旅数据；或，
激活第二应用，并加载所述第二应用的差旅数据提供界面，以从所述差旅数据提供界面中获取与所述差旅订单相关的差旅数据。
所述装置还包括：
子订单生成模块1204，根据获取的所述差旅数据，生成对应所述差旅订单中各行程的各子差旅订单。
所述子订单生成模块1204，将所述各子差旅订单隐藏在所述差旅订单中；当监测到所述用户对所述差旅订单执行指定操作后，则将隐藏在所述差旅订单中的各子差旅订单按照所述差旅订单中各行程的时间顺序进行排列并展示。
所述订单生成模块1202，根据所述差旅处理请求，生成以行程卡片的方式进行展示的差旅订单；
所述子订单生成模块1204，根据从所述第二应用中获取的与所述差旅订单相关的差旅数据，生成对应所述差旅订单中各行程的，以行程卡片方式进行展示的各子差旅订单。
所述装置还包括：
结算模块1205，确定所述用户在所述第一应用中的结算规则；根据所述结算规则，对所述差旅订单所产生的费用进行结算。
所述结算模块1205，当监测到所述用户对所述差旅订单执行结算操作时，则根据所述结算规则，对所述差旅订单所需的费用进行结算。
所述结算模块1205，当所述结算规则为所述差旅订单需要所述用户进行结算时，通过所述第一账号对所述差旅订单所产生的费用进行结算；当所述结算规则为所述差旅订单需要所述用户所属的企业进行结算时，则将所述差旅订单发送给所述第一应用中的第二指定用户，使得所述第二用户对所述差旅订单所产生的费用进行结算。
所述结算模块1205，判断所述差旅订单所产生的费用是否超出所述用户对应的预设差旅标准；若是，则提示所述用户对所述差旅订单进行修改；若否，则根据所述结算规则，对所述差旅订单所需的费用进行结算。
所述结算模块1205，判断所述差旅订单所产生的费用是否超出所述用户对应的预设差旅标准；若是，则将所述差旅订单发送给所述第一指定用户进行审核，并当监测到所述第一指定用户对所述差旅订单执行审核通过操作时，根据所述结算规则，对所述差旅订单所产生的费用进行结算；若否，则根据所述结算规则，对所述差旅订单所需的费用进行结算。
所述结算模块1205，当监测到所述第一指定用户对所述差旅订单执行审核通过操作时，提示所述用户对所述差旅订单进行修改。
所述装置还包括：
信息推送模块1206，确定所述用户当前的状态信息，所述状态信息包括当前的时间信息、所述用户当前的位置信息中的至少一种；根据预设的提醒规则，确定与所述状态信息相匹配的子差旅订单；根据确定出的所述子差旅订单以及所述状态信息，向所述用户推送与所述子差旅订单相关的服务信息。
所述获取信息模块1203，获取所述用户未完成的行程所对应的子差旅订单相关的状态变更信息；将所述状态变更信息展示在所述子差旅订单中。
所述订单生成模块1202，当监测到所述用户对所述差旅订单中的行程执行变更操作时，则根据变更的行程以及未变更的行程，重新生成差旅订单，并将所述重新生成的差旅订单发送给所述第一指定用户进行审核；当监测到所述第一指定用户通过所述重新生成的差旅订单的审核后，则根据预设的结算规则，对所述重新生成的差旅订单还需结算的费用进行结算。
本申请实施例提供一种差旅服务处理方法及装置，该方法中第一应用接收用户发送的差旅处理请求；根据该差旅处理请求，生成对应的差旅订单；当监测到该差旅订单满足预设的条件时，从第二应用中获取与该差旅订单相关的差旅数据。通过上述方法可以看出，由于应用于企业管理的第一应用在获取到用户发送的差旅处理请求后，可根据该差旅服务请求生成对应的差旅订单，并通过该差旅订单，从用于差旅服务的第二应用中获取与该差旅订单相关的差旅数据，这样，通过企业管理的第一应用即可调用第二应用，并从第二应用中获取与差旅订单相关的差旅数据，进而在第一应用中有效地实现对企业员工的差旅管理，以提升企业管理效率，同步也为企业的差旅管理提供了便利的途径，进而改善了用户对企业管理软件的用户体验。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。