CN111681060A - 应用的订单处理方法及装置 - Google Patents

Abstract

本发明提供一种应用的订单处理方法及装置，包括：接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用；根据第一操作请求，跳转至第二应用的用户界面；在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。本发明提供的应用的订单处理方法，可以使第一应用的服务器直接记录第二应用的订单的信息，从而提高获取报销所用信息的准确性和及时性。

Description

应用的订单处理方法及装置

技术领域

本发明涉及网络技术领域，尤其涉及一种应用的订单处理方法及装置。

背景技术

随着互联网技术的发展和智能终端的普及，越来越多的企业会为员工提供员工应用，便于员工进行各种餐饮、娱乐、约车、机票(含高铁等)、酒店、购物等商务出行消费活动，同时具有报销、借款、发票管理等业务功能。因此，通过该员工应用，员工无需垫付自有资金，可以更加简单方便的进行消费、报销等一系列操作。

目前，员工在员工应用上对商务消费活动进行报销时，需要员工将商务消费活动产生的订单的信息手动填写入报销所用的应用上，以触发该商务消费活动的报销流程。

然而，上述手动输入订单的信息的方式，使得输入订单的信息的准确率无法保证，导致报销应用获取报销所用的信息的及时性和准确率不高。

发明内容

本发明提供一种应用的订单处理方法及装置，以提高获取报销所用信息的准确性和及时性。

本发明第一个方面提供一种应用的订单处理方法，包括：

接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，所述第一操作请求用于启动第二应用；

根据所述第一操作请求，跳转至所述第二应用的用户界面；

在所述第二应用的用户界面上完成所述第二应用的订单后，获取所述订单的信息，并向所述第一应用的服务器发送请求消息，所述请求消息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的信息。

可选的，所述向所述第一应用的服务器发送请求消息之后，还包括：

接收用户在所述第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，所述第二操作请求包括用户输入所述第二用户界面的第一输入框内的报销类型，所述报销类型与所述第二应用对应，所述第二操作请求用于请求获取所述第二应用的记录列表；

根据所述第二操作请求，获取包括所述第二应用的记录列表的悬浮窗口，并在所述第二用户界面上显示所述悬浮窗口；

接收用户在所述第二应用的记录列表中通过点击所述订单的信息触发的第三操作请求，所述第三操作请求用于在所述第二用户界面的所述第二控件对应的第二输入框中添加所述订单的信息；

接收用户在所述第二用户界面上通过点击第三控件触发的第四操作请求，所述第四操作请求用于根据所述订单的信息发起所述订单的报销流程。

可选的，所述请求消息还包括：所述订单的发票数据；

所述在所述第二应用的用户界面上完成所述第二应用的订单后，所述方法还包括：

接收所述第二应用的服务器发送的所述订单的发票数据，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的发票数据。

可选的，在所述第二应用的用户界面上完成所述第二应用的订单后之后，还包括：

接收用户在所述第二应用的用户界面通过点击第四控件触发的第五操作请求，所述第五操作请求用于向所述第一应用的服务器发送退单信息，所述退单信息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中删除所述订单的信息。

可选的，所述第二应用为网约车应用，所述第二应用的订单为网约车出行订单；

所述订单的信息包括下述至少一项：

所述网约车出行订单的出行时间、所述网约车出行订单的起始点、所述网约车出行订单的目的地、所述网约车出行订单的费用数据、所述网约车出行订单的发票索引。

本发明的第二个方面提供一种应用的订单处理装置，包括：

第一接收模块，用于接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，所述第一操作请求用于启动第二应用；

跳转模块，用于根据所述第一操作请求，跳转至所述第二应用的用户界面；

第一发送模块，用于在所述第二应用的用户界面上完成所述第二应用的订单后，获取所述订单的信息，并向所述第一应用的服务器发送请求消息，所述请求消息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的信息。

可选的，还包括：

第二接收模块，用于接收用户在所述第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，所述第二操作请求包括用户输入所述第二用户界面的第一输入框内的报销类型，所述报销类型与所述第二应用对应，所述第二操作请求用于请求获取所述第二应用的记录列表；

窗口获取模块，用于根据所述第二操作请求，获取包括所述第二应用的记录列表的悬浮窗口，并在所述第二用户界面上显示所述悬浮窗口；

第三接收模块，用于接收用户在所述第二应用的记录列表中通过点击所述订单的信息触发的第三操作请求，所述第三操作请求用于在所述第二用户界面的所述第二控件对应的第二输入框中添加所述订单的信息；

第四接收模块，用于接收用户在所述第二用户界面上通过点击第三控件触发的第四操作请求，所述第四操作请求用于根据所述订单的信息发起所述订单的报销流程。

可选的，所述请求消息还包括：所述订单的发票数据；

所述装置，还包括：

第五接收模块，用于接收所述第二应用的服务器发送的所述订单的发票数据，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的发票数据。

可选的，还包括：

第六接收模块，用于接收用户在所述第二应用的用户界面通过点击第四控件触发的第五操作请求，所述第五操作请求用于向所述第一应用的服务器发送退单信息，所述退单信息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中删除所述订单的信息。

可选的，所述第二应用为网约车应用，所述第二应用的订单为网约车出行订单；

所述订单的信息包括下述至少一项：

所述网约车出行订单的出行时间、所述网约车出行订单的起始点、所述网约车出行订单的目的地、所述网约车出行订单的费用数据、所述网约车出行订单的发票索引。本发明的第三方面提供一种电子设备，包括：存储器与处理器；

所述存储器，用于存储所述处理器的可执行指令；

所述处理器配置为经由执行所述可执行指令来执行第一方面及其可选方案涉及的方法。

本发明的第四方面，提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面及其可选方案涉及的方法。

本发明提供的应用的订单处理方法及装置，通过接收用户点击第一控件触发的第一应用，进而跳转第二应用的用户界面，用户通过第二应用产生订单，并在完成订单后，向第一应用的服务器发送请求消息，以使第一应用根据请求消息中包含的第二应用的标识、订单的信息和第一应用对应的用户标识，在第二应用的记录列表中添加订单的信息，从而使第一应用的服务器自动获取订单的信息，这样，后期用户在第一应用上触发针对该订单的报销流程时，可以从第一应用的服务器中获取到该订单的信息，无需用户手动添加，避免用户手动填写报销所用的订单的信息，进而提高了报销信息获取的准确性和及时性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种应用的订单处理方法的应用场景示意图；

图2为本发明实施例提供的一种应用的订单处理方法的流程示意图；

图3为本发明实施例提供的一种第一用户界面的示意图；

图4为本发明实施例提供的一种第二应用的用户界面的示意图；

图5为本发明实施例提供的另一种应用的订单处理方法的流程示意图；

图6为本发明实施例提供的一种第二用户界面的界面示意图；

图7为本发明实施例提供的再一种应用的订单处理方法的流程示意图；

图8为本发明实施例提供的又一种应用的订单处理方法的流程示意图；

图9为本发明实施例提供的一种应用的订单处理装置的结构示意图；

图10为本发明实施例提供的另一种应用的订单处理装置的结构示意图；

图11为本发明实施例提供的再一种应用的订单处理装置的结构示意图；

图12为本发明实施例提供的又一种应用的订单处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

应当理解，在本发明的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

应当理解，在本发明中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本发明中，“与A相对应的B”、“A与B相对应”或者“B与A相对应”，表示B与A相关联，根据A可以确定B。根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其他信息确定B。

取决于语境，如在此所使用的“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图1为本发明实施例提供的一种应用的订单处理方法的应用场景示意图。

请参考图1，本发明实施例可适用的场景中，当用户需要在终端上进行商务消费时，可以首先打开终端11的第一应用，第一应用用于记录商务消费的订单信息并进行报销，此外，第一应用还内嵌有为用户提供商业活动的第二应用，例如，第一应用设置有进入第二应用的调用接口；其次，用户可以通过点击第一应用的第一用户界面上的第一控件来触发第一操作请求，进而跳转至第二应用的用户界面，第二应用为用户进行商务消费的应用；再次，用户通过终端11上的第二应用与第二应用的第二服务器13产生交互，进行商务消费，并生成订单；最后，终端11可以根据订单的信息向第一应用的第一服务器12发送请求消息，以使第一应用的第一服务器12将第二应用产生的订单信息添加到用户标识对应的第二应用的记录列表中。

其中，终端11和第一服务器12之间，以及终端11和第二服务器13之间均可以通过网络连接。

终端，可以是任意配置了处理器、存储器的电子设备，可例如：手机、平板电脑、计算机等设备。

服务器，可以是任意配置了处理器与存储器的电子设备，或者电子设备的集合。

实施本发明涉及方法的主体，可以为以上所称的终端11。

图2为本发明实施例提供的一种应用的订单处理方法的流程示意图。

请参照如图2，应用的订单处理方法，包括步骤S21-S23，具体如下：

S21：接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用。

S22：根据第一操作请求，跳转至第二应用的用户界面。

第一应用，可以是报销应用，其可以具有报销、借款、发票管理等业务功能。当用户通过第二应用完成消费后，可以通过第一应用记录订单信息并从第二应用中获取电子发票以完成报销；此外，第一应用还可以提供跳转至其他提供商务活动的应用的接口。第一应用可以例如，前述所说的员工应用。

第二应用，可以是消费应用，例如：网约车应用、酒店订购应用、机票订购应用、订餐应用、娱乐消费应用和外卖应用等企业消费服务。管理员可以在第一应用中添加第二应用的控件，从而预先将第二应用与第一应用进行挂钩，进而限定用户的可报销的应用的种类。或者，也可以由用户进行申请，并由管理者审核后将第二应用的控件添加到第一应用中。

第一控件，可以是第一用户界面上指向第二应用的任一控件，具体可以在第一用户界面上显示为具体应用的图标，或者，也可以是应用类型的图标，例如：用汽车图标来表示网络打车应用，用飞机图标来表示机票订购应用。

图3为本发明实施例提供的一种第一用户界面的示意图。

请参照图3，在实际应用中，用户可以根据具体想要使用的应用类型，点击第一用户界面上的对应的第一控件31触发第一操作请求。第一操作请求可以包含第二应用的标识，当终端接收到第一操作请求后，可以识别第一操作请求中包含的第二应用的标识，启动与标识对应的第二应用，进而将第一用户界面跳转至第二应用的用户界面。

S23：在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。

在实际应用中，第二应用的用户界面开启后，用户可以根据实际情况在第二应用上生成订单，当用户完成订单后，终端自动获取订单的信息，包括：第二应用的标识、订单的信息和第一应用对应的用户标识。随后，终端将订单的消息发送给第一应用的服务器，第一应用的服务器根据用户标识和第二应用的标识找到用户标识对应的第二应用的记录列表，并将订单信息进行添加。

可选的，第二应用为网约车应用，第二应用的订单为网约车出行订单。

可选的，订单的信息包括下述至少一项：

网约车出行订单的出行时间、网约车出行订单的起始点、网约车出行订单的目的地、网约车出行订单的费用数据、网约车出行订单的发票索引。

图4为本发明实施例提供的一种第二应用的用户界面的示意图。

请参考图4，结合实际情况举例来说，当用户需要进行网约车出行时，可以首先打开第一应用，并在第一应用的用户界面上点击与网约车应用对应的第一控件，第一控件在触发后生成第一操作请求进而使用户终端打开网约车应用并将跳转至第二应用的应用界面。随后，用户在第三输入框41中输入或定位起始点，在第四输入框42中输入或定位目的地，进而通过点击第五控件43生成网约车订单，终端采集订单信息并将其发送给第一应用的服务器，以使第一应用的服务器在用户标识对应的网约车应用的记录列表中添加订单的信息。最后，用户还可以点击第二应用的用户界面上的第六控件44返回第一应用。

在另一种可实施方式中，第二应用可以为机票订购应用，第二应用的订单为机票订单；

机票订单的信息包括下述至少一项：

机票订单的出行时间、机票订单的起始点、机票订单的目的地、机票订单的费用数据、机票订单的发票索引。

结合实际情况举例来说：当用户需要进行机票订购时，可以首先打开第一应用，并在第一应用的用户界面上点击与机票订购应用对应的第一控件，第一控件在触发后生成第一操作请求进而使终端打开机票订购应用并将跳转至机票订购应用的应用界面。随后，用户通过机票订购应用产生机票订单，终端采集订单信息并将其发送给第一应用的服务器，以使第一应用的服务器在用户标识对应的机票订购应用的记录列表中添加订单的信息。

本实施例提供的应用的订单处理方法，通过接收用户点击第一控件触发的第一应用，进而跳转第二应用的用户界面，用户通过第二应用产生订单，并在完成订单后，向第一应用的服务器发送请求消息，以使第一应用根据请求消息中包含的第二应用的标识、订单的信息和第一应用对应的用户标识，在第二应用的记录列表中添加订单的信息，以避免用户手动添加报销所用的订单的信息，从而提高了报销信息获取的准确性和及时性。

图5为本发明实施例提供的另一种应用的订单处理方法的流程示意图。

请参照如图5，应用的订单处理方法，包括步骤S51-S58，具体如下：

S51：接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用。

S52：根据第一操作请求，跳转至第二应用的用户界面。

S53：在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。

步骤S51至步骤S53的技术名词、技术效果、技术特征，以及可选实施方式，可参照图2所示的步骤S21至S23理解，对于重复的内容，在此不再累述。

S54：接收用户在第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，第二操作请求包括用户输入第二用户界面的第一输入框内的报销类型，报销类型与第二应用对应，第二操作请求用于请求获取第二应用的记录列表。

图6为本发明实施例提供的一种第二用户界面的界面示意图。

请参照图6，在实际应用中，当用户需要用之前产生的订单进行报销时，可以打开第一应用的第二用户界面，从而在第二用户界面的第一输入框61中选择报销类型，随后用户可以通过点击第二用户界面上的第二控件62获取与报销类型对应的第二应用的记录列表。此外，用户还可以在第二用户界面上输入申请人、同行人员、费用部门、备注等信息。

S55：根据第二操作请求，获取包括第二应用的记录列表的悬浮窗口，并在第二用户界面上显示悬浮窗口。

S56：接收用户在第二应用的记录列表中通过点击订单的信息触发的第三操作请求，第三操作请求用于在第二用户界面的第二控件对应的第二输入框中添加订单的信息。

在实际应用中，当用户点击第二用户界面上的第二控件后，在第二用户界面上可以弹出悬浮窗口，悬浮窗口中包含了第二应用的记录列表，用户可以从记录列表中选择待报销的订单，并通过点击将订单的信息添加到第二控件对应的第二输入框中。

S57：接收用户在第二用户界面上通过点击第三控件触发的第四操作请求，第四操作请求用于根据订单的信息发起订单的报销流程。

在实际应用中，当用户在第二用户界面上填写完所有报销所需的信息后，用户可以点击第二用户界面上的第三控件，进而将用户所填信息以及用户添加的订单信息添加并进行提交，从而完成报销。

本实施例提供的应用的订单处理方法，用户通过在第一应用的第二用户界面上选择报销类型并通过第二控件添加订单的信息，进而使第一应用可以根据用户的选择从记录的订单信息中确定出待报销的订单信息，从而避免了用户手动填写订单信息，提高了用户的体验。

图7为本发明实施例提供的再一种应用的订单处理方法的流程示意图。

请参照如图7，应用的订单处理方法，包括步骤S71-S74，具体如下：

S71：接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用。

S72：根据第一操作请求，跳转至第二应用的用户界面。

S73：在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。

步骤S71至步骤S73的技术名词、技术效果、技术特征，以及可选实施方式，可参照图2所示的步骤S21至S23理解，对于重复的内容，在此不再累述。

S74：接收第二应用的服务器发送的订单的发票数据，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的发票数据。

其中，请求消息还包括：订单的发票数据。

在实际应用中，当第二应用添加订单完成后，第二应用的服务器会生成与订单相应的发票数据，随后，第二应用的服务器会将发票数据发送给第一应用的服务器，发送过程可以先发送给终端再由终端发送给第一应用的服务器，或者，也可以直接发送给第一应用的服务器。第一应用的服务器接收到发票数据后，会将其添加到用户标识对应的第二应用的记录列表中，以便用户进行报销操作时使用。

本实施例提供的应用的订单处理方法，当第二应用的服务器生成发票数据后，会将发票数据发送给第一应用的服务器，第一应用的服务器将发票数据添加到用户标识对应的第二应用的记录列表中，从而使用户在进行报销时无需查询和输入发票数据，简化了报销流程，避免了因输错发票数据而无法报销的情况，提高了报销效率和用户体验。

图8为本发明实施例提供的又一种应用的订单处理方法的流程示意图。

请参照如图8，应用的订单处理方法，包括步骤S81-S84，具体如下：

S81：接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用；

S82：根据第一操作请求，跳转至第二应用的用户界面；

S83：在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。

步骤S81至步骤S83的技术名词、技术效果、技术特征，以及可选实施方式，可参照图2所示的步骤S21至S23理解，对于重复的内容，在此不再累述。

S84：接收用户在第二应用的用户界面通过点击第四控件触发的第五操作请求，第五操作请求用于向第一应用的服务器发送退单信息，退单信息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中删除订单的信息。

本实施例提供的应用的订单处理方法，当用户发送退单操作时，可以通过点击第四控件来触发第五操作请求，从而使第一应用的服务器可以删除对应的订单信息，从而防止添加错误的订单信息，提高了用户的体验。

图9为本发明实施例提供的一种应用的订单处理装置的结构示意图。

请参照如图9，应用的订单处理装置，包括：

第一接收模块91，用于接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，第一操作请求用于启动第二应用。

跳转模块92，用于根据第一操作请求，跳转至第二应用的用户界面。

第一发送模块93，用于在第二应用的用户界面上完成第二应用的订单后，获取订单的信息，并向第一应用的服务器发送请求消息，请求消息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的信息。

可选的，第二应用为网约车应用，第二应用的订单为网约车出行订单。

可选的，订单的信息包括下述至少一项：

网约车出行订单的出行时间、网约车出行订单的起始点、网约车出行订单的目的地、网约车出行订单的费用数据、网约车出行订单的发票索引。

本实施例提供的应用的订单处理装置，通过接收用户点击第一控件触发的第一应用，进而跳转第二应用的用户界面，用户通过第二应用产生订单，并在完成订单后，向第一应用的服务器发送请求消息，以使第一应用根据请求消息中包含的第二应用的标识、订单的信息和第一应用对应的用户标识，在第二应用的记录列表中添加订单的信息，以避免用户手动添加报销所用的订单的信息，从而提高了报销信息获取的准确性和及时性。

图10为本发明实施例提供的另一种应用的订单处理装置的结构示意图。

请参照如图10，在图9的基础上，应用的订单处理装置，还包括：

第二接收模块104，用于接收用户在第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，第二操作请求包括用户输入第二用户界面的第一输入框内的报销类型，报销类型与第二应用对应，第二操作请求用于请求获取第二应用的记录列表。

窗口获取模块105，用于根据第二操作请求，获取包括第二应用的记录列表的悬浮窗口，并在第二用户界面上显示悬浮窗口。

第三接收模块106，用于接收用户在第二应用的记录列表中通过点击订单的信息触发的第三操作请求，第三操作请求用于在第二用户界面的第二控件对应的第二输入框中添加订单的信息。

第四接收模块107，用于接收用户在第二用户界面上通过点击第三控件触发的第四操作请求，第四操作请求用于根据订单的信息发起订单的报销流程。

本实施例提供的应用的订单处理装置，用户通过在第一应用的第二用户界面上选择报销类型并通过第二控件添加订单的信息，进而使第一应用可以根据用户的选择从记录的订单信息中确定出待报销的订单信息，从而避免了用户手动添加订单信息，提高了用户的体验。

图11为本发明实施例提供的再一种应用的订单处理装置的结构示意图。

请参照如图11，在图9的基础上，应用的订单处理装置，还包括：

第五接收模块114用于接收第二应用的服务器发送的订单的发票数据，以使第一应用的服务器在用户标识对应的第二应用的记录列表中添加订单的发票数据。

其中，请求消息还包括：订单的发票数据。

本实施例提供的应用的订单处理装置，当第二应用的服务器生产发票数据后，会将发票数据发送给第一应用的服务器，第一应用的服务器将发票数据添加到用户标识对应的第二应用的记录列表中，从而使用户在进行报销时无需查询和输入发票数据，简化了报销流程，避免了因输错发票数据而无法报销的情况，提高了用户体验。

图12为本发明实施例提供的又一种应用的订单处理装置的结构示意图。

请参照如图12，在图9的基础上，应用的订单处理装置，还包括：

第六接收模块124，用于接收用户在第二应用的用户界面通过点击第四控件触发的第五操作请求，第五操作请求用于向第一应用的服务器发送退单信息，退单信息包括：第二应用的标识、订单的信息和第一应用对应的用户标识，以使第一应用的服务器在用户标识对应的第二应用的记录列表中删除订单的信息。

本实施例提供的应用的订单处理方法，当用户发送退单操作时，可以通过点击第四控件来触发第五操作请求，从而使第一应用的服务器可以删除对应的订单信息，从而防止添加错误的订单信息，提高了用户的体验。

本发明还提供一种电子设备，包括：存储器与处理器；

存储器，用于存储处理器的可执行指令；

处理器配置为经由执行可执行指令来执行图2-图7所涉及的应用的订单处理方法。

其中，可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何介质。例如，可读存储介质连接到处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application SpecificIntegrated Circuits，简称：ASIC)中。另外，该ASIC可以位于用户设备中。当然，处理器和可读存储介质也可以作为分立组件存在于通信设备中。

本发明还提供一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现图2-图7的应用的订单处理方法。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的保护范围。

Claims (10)

1.一种应用的订单处理方法，其特征在于，包括：

接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，所述第一操作请求用于启动第二应用；

根据所述第一操作请求，跳转至所述第二应用的用户界面；

在所述第二应用的用户界面上完成所述第二应用的订单后，获取所述订单的信息，并向所述第一应用的服务器发送请求消息，所述请求消息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的信息。

2.根据权利要求1所述的方法，其特征在于，所述向所述第一应用的服务器发送请求消息之后，还包括：

接收用户在所述第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，所述第二操作请求包括用户输入所述第二用户界面的第一输入框内的报销类型，所述报销类型与所述第二应用对应，所述第二操作请求用于请求获取所述第二应用的记录列表；

根据所述第二操作请求，获取包括所述第二应用的记录列表的悬浮窗口，并在所述第二用户界面上显示所述悬浮窗口；

接收用户在所述第二应用的记录列表中通过点击所述订单的信息触发的第三操作请求，所述第三操作请求用于在所述第二用户界面的所述第二控件对应的第二输入框中添加所述订单的信息；

接收用户在所述第二用户界面上通过点击第三控件触发的第四操作请求，所述第四操作请求用于根据所述订单的信息发起所述订单的报销流程。

3.根据权利要求1所述的方法，其特征在于，所述请求消息还包括：所述订单的发票数据；

所述在所述第二应用的用户界面上完成所述第二应用的订单后，所述方法还包括：

接收所述第二应用的服务器发送的所述订单的发票数据，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的发票数据。

4.根据权利要求1所述的方法，其特征在于，在所述第二应用的用户界面上完成所述第二应用的订单后之后，还包括：

接收用户在所述第二应用的用户界面通过点击第四控件触发的第五操作请求，所述第五操作请求用于向所述第一应用的服务器发送退单信息，所述退单信息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中删除所述订单的信息。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述第二应用为网约车应用，所述第二应用的订单为网约车出行订单；

所述订单的信息包括下述至少一项：

所述网约车出行订单的出行时间、所述网约车出行订单的起始点、所述网约车出行订单的目的地、所述网约车出行订单的费用数据、所述网约车出行订单的发票索引。

6.一种应用的订单处理装置，其特征在于，包括：

第一接收模块，用于接收用户在第一应用的第一用户界面通过点击第一控件触发的第一操作请求，所述第一操作请求用于启动第二应用；

跳转模块，用于根据所述第一操作请求，跳转至所述第二应用的用户界面；

第一发送模块，用于在所述第二应用的用户界面上完成所述第二应用的订单后，获取所述订单的信息，并向所述第一应用的服务器发送请求消息，所述请求消息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的信息。

7.根据权利要求6所述的装置，其特征在于，还包括：

第二接收模块，用于接收用户在所述第一应用的第二用户界面上通过点击第二控件触发的第二操作请求，所述第二操作请求包括用户输入所述第二用户界面的第一输入框内的报销类型，所述报销类型与所述第二应用对应，所述第二操作请求用于请求获取所述第二应用的记录列表；

窗口获取模块，用于根据所述第二操作请求，获取包括所述第二应用的记录列表的悬浮窗口，并在所述第二用户界面上显示所述悬浮窗口；

第三接收模块，用于接收用户在所述第二应用的记录列表中通过点击所述订单的信息触发的第三操作请求，所述第三操作请求用于在所述第二用户界面的所述第二控件对应的第二输入框中添加所述订单的信息；

第四接收模块，用于接收用户在所述第二用户界面上通过点击第三控件触发的第四操作请求，所述第四操作请求用于根据所述订单的信息发起所述订单的报销流程。

8.根据权利要求6所述的装置，其特征在于，所述请求消息还包括：所述订单的发票数据；

所述装置，还包括：

第五接收模块，用于接收所述第二应用的服务器发送的所述订单的发票数据，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中添加所述订单的发票数据。

9.根据权利要求6所述的装置，其特征在于，还包括：

第六接收模块，用于接收用户在所述第二应用的用户界面通过点击第四控件触发的第五操作请求，所述第五操作请求用于向所述第一应用的服务器发送退单信息，所述退单信息包括：所述第二应用的标识、所述订单的信息和所述第一应用对应的用户标识，以使所述第一应用的服务器在所述用户标识对应的第二应用的记录列表中删除所述订单的信息。

10.根据权利要求6-8任一项所述的装置，其特征在于，所述第二应用为网约车应用，所述第二应用的订单为网约车出行订单；

所述订单的信息包括下述至少一项：

所述网约车出行订单的出行时间、所述网约车出行订单的起始点、所述网约车出行订单的目的地、所述网约车出行订单的费用数据、所述网约车出行订单的发票索引。

Images