出行订单处理方法、装置、设备、存储介质以及产品

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种出行订单处理方法、装置和设备，以及存储有可供计算机读取的程序的存储介质以及计算机程序产品。

背景技术

在出行业务中，为了便于准确地了解司机的运营情况，需要针对每次的出行任务创建订单，并将与对司机相关联出行数据记录的订单中，通过对订单中的数据进行统计来掌握司机的运营数据。

然而，对于一些能够允许司机多种途径创建订单的出行业务，可能会出现针对同一个出行任务，通过不同的途径创建两个重复订单的情况，这会导致重复订单严重地影响司机的运营数据的准确性。

发明内容

有鉴于此，本公开实施例提供了一种出行订单处理方法、装置、设备、存储介质以及产品，至少部分解决现有技术中存在的问题。

第一方面，本公开实施例提供了一种出行订单处理方法，方法包括：

接收服务提供方发送的第一订单请求；

在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单；

若确定所述未完成订单与所述待创建订单为重复订单，基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单，包括：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单的订单生成时间，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的订单创建时间；

确定所述订单生成时间与所述订单创建时间之间的时间差是否小于第一预设时间间隔；

若所述时间差小于所述第一预设时间间隔，确定所述未完成订单与所述待创建订单为重复订单。

在一种可选的实施方式中，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求，所述订单请求包括所述第一订单请求和所述未完成订单对应的第二订单请求。

在一种可选的实施方式中，所述在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单，包括：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单对应的预估出行起始时间所处的第一预估时间段，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的预估出行起始时间所处的第二预估时间段；

若所述第一预估时间段与所述第二预估时间段存在重叠时间，确定所述未完成订单与所述待创建订单为重复订单。

在一种可选的实施方式中，所述基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单，包括：

将所述第一订单请求确定为无效请求，并将所述未完成订单确定为所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单，包括：

获取所述第一订单请求对应的订单号；

在将所述未完成订单的订单号替换为所述第一订单请求对应的订单号之后，将所述未完成订单确定为所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求；在确定出所述服务提供方的目标服务订单后，所述方法还包括：

在所述目标服务订单对应的出行过程中，从所述车载终端获取第一行驶轨迹数据，以及从所述移动终端获取第二行驶轨迹数据；

基于所述第一行驶轨迹数据和所述第二行驶轨迹数据，确定出所述目标服务订单对应的目标行驶轨迹数据。

第二方面，本公开实施例提供了一种出行订单处理装置，装置包括：

请求接收模块，用于接收服务提供方发送的第一订单请求；

重复订单确定模块，用于在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单；

目标订单确定模块，用于在确定所述未完成订单与所述待创建订单为重复订单时，基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述重复订单确定模块在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单时，具体用于：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单的订单生成时间，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的订单创建时间；

确定所述订单生成时间与所述订单创建时间之间的时间差是否小于第一预设时间间隔；

若所述时间差小于所述第一预设时间间隔，确定所述未完成订单与所述待创建订单为重复订单。

在一种可选的实施方式中，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求，所述订单请求包括所述第一订单请求和所述未完成订单对应的第二订单请求。

在一种可选的实施方式中，所述重复订单确定模块在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单时，具体用于：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单对应的预估出行起始时间所处的预估时间段，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的乘客用车时间段；

若所述未完成订单的乘客用车时间段与所述待创建订单的乘客用车时间段存在重叠时间，确定所述未完成订单与所述待创建订单为重复订单。

在一种可选的实施方式中，所述目标订单确定模块在用于基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单时，具体用于：

将所述第一订单请求确定为无效请求，并将所述未完成订单确定为所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述目标订单确定模块在用于基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单时，具体用于：

获取所述第一订单请求对应的订单号；

在将所述未完成订单的订单号替换为所述第一订单请求对应的订单号之后，将所述未完成订单确定为所述服务提供方的目标服务订单。

在一种可选的实施方式中，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求；所述装置还包括目标轨迹确定模块，所述目标轨迹确定模块用于：

在所述目标服务订单对应的出行过程中，从所述车载终端获取第一行驶轨迹数据，以及从所述移动终端获取第二行驶轨迹数据；

基于所述第一行驶轨迹数据和所述第二行驶轨迹数据，确定出所述目标服务订单对应的目标行驶轨迹数据。

第三方面，本公开实施例提供了一种电子设备，电子设备包括处理器、存储器和总线；所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器运行时执行上述第一方面，或第一方面中任一种可能的出行订单处理方法的步骤。

第四方面，本公开实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的出行订单处理方法的步骤。

第五方面，本公开实施例提供了一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现上述第一方面，或第一方面中任一种可能的出行订单处理方法的步骤。

本公开实施例提供的出行订单处理方法、装置、电子设备以及存储介质，可以在基于接收到的第一订单请求创建新的订单之前，确定第一订单请求对应的待创建订单与服务提供方可能存在的未完成订单为重复订单，在确定出未完成订单与待创建订单为重复订单时，基于第一订单请求和未完成订单确定出一个目标服务订单，并仅以目标服务订单来记录出行数据，不再响应第一订单请求创建新的订单，从而即可以避免出现同一个服务提供方被创建两个重复订单的情况，保证司机的运营数据的准确性，又可以避免在两个重复订单中重复记录出行数据，节约了计算资源。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本公开实施例提供的一种出行订单处理系统的架构图；

图2为本公开实施例提供的一种出行订单处理方法的流程图；

图3为本公开实施例提供的一种出行订单处理装置的示意图之一；

图4为本公开实施例提供的一种出行订单处理装置的示意图之二；

图5为本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

经研究发现，在出行业务中，为了便于准确地了解司机的运营情况，需要针对每次的出行任务创建订单，并将与对司机相关联出行数据记录的订单中，通过对订单中的数据进行统计来掌握司机的运营数据。然而，对于一些能够提供多种途径创建订单的出行业务，可能会出现针对同一个出行任务，通过不用的途径创建两个重复订单的情况。例如，对于能够提供网约车服务的出租车，司机可以通过车载终端或安装有出行应用的移动终端来发送订单请求，使得服务器根据订单请求来创建订单针对同一个出行任务，司机可以分别通过车载终端和移动终端发送订单请求，服务器会分别根据车载终端和移动终端发送的订单请求创建两个订单，这两个订单便属于重复订单。重复订单会导致同一个出行任务的出行数据被重复记录两次，严重地影响司机的运营数据的准确性。

基于上述研究，本公开实施例提供了一种出行订单处理方法，可以在基于接收到的第一订单请求创建新的订单之前，确定第一订单请求对应的待创建订单与服务提供方可能存在的未完成订单为重复订单，在确定出未完成订单与待创建订单为重复订单时，基于第一订单请求和未完成订单确定出一个目标服务订单，并仅以目标服务订单来记录出行数据，不再响应第一订单请求创建新的订单，从而即可以避免出现同一个服务提供方被创建两个重复订单的情况，保证司机的运营数据的准确性，又可以避免在两个重复订单中重复记录出行数据，节约了计算资源。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种出行订单处理方法进行详细介绍，本公开实施例所提供的出行订单处理方法的执行主体一般为具有一定计算能力的计算机设备，该计算机设备例如包括终端设备、服务器或其它处理设备。终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端设备、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该出行订单处理方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面以执行主体为服务器为例，对本公开实施例提供的出行订单处理方法加以说明。本公开实施例提供的出行订单处理方法可以应用在出行订单处理系统，参见图1所示，为本公开实施例提供的一种出行订单处理系统的架构图，出行订单处理系统包括服务器和服务提供方，其中，服务提供方可以向服务器发送订单请求，服务器能够基于订单请求创建订单。具体来说，服务提供方可以具备至少一个终端设备，服务提供方可以通过终端设备向服务器发送订单请求。

可选地，至少一个终端设备可以包括移动终端，移动终端安装有司机端出行应用(如司机端的网约车应用)。司机可以通过移动终端的司机端出行应用，接受服务乘客通过乘客端出行应用(如乘客端的网约车应用)请求的出行任务，从而使移动终端向服务器发送订单请求，以便服务器根据移动终端发送的订单请求创建线上订单。另外，移动终端可以具有定位模块，定位模块可以记录司机所驾驶的车辆的行驶轨迹数据，并将行驶轨迹数据上传至服务器。

可选地，至少一个终端设备可以包括车载终端，车载终端可以包括计价器，司机可以在通过巡游的方式接到乘客之后对计价器进行扣表，从而使车载终端向服务器发送订单请求，以便服务器根据车载终端发送的订单请求创建线下订单。另外，车载终端可以具有定位装置，定位装置可以记录司机所驾驶的车辆的行驶轨迹数据，并将行驶轨迹数据上传至服务器。

参见图2所示，为本公开实施例提供的一种出行订单处理方法的流程图，所述方法包括步骤S110～S130，其中：

S110：接收服务提供方发送的第一订单请求。

这里，为了便于描述和理解，将服务器最新收到的订单请求定义为第一订单请求。服务提供方可以通过终端设备向服务器发送订单请求，如前文所述，服务提供方可以具有移动终端和车载终端之中的至少一个，因此，服务提供方发送订单请求的途径包括通过车载终端发送订单请求，以及通过安装有出行应用的移动终端发送订单请求。也就是说，第一订单请求可以是由车载终端或移动终端发送的；其中，若第一订单请求是由车载终端发送，则第一订单请求对应的待创建订单为线下订单；若第一订单请求是由移动终端发送，则第一订单请求对应的待创建订单为线上订单。

S120：在确定服务提供方存在未完成订单的情况下，基于未完成订单的订单信息与第一订单请求的请求信息，确定未完成订单与第一订单请求对应的待创建订单是否为重复订单。

未完成订单可以是是服务器在接收到第一订单请求之前所创建的、并且在接收到第一订单请求时仍然未结束的订单。服务器在接收到第一订单请求之后，可以确定第一订单请求所对应的服务提供方的身份信息，根据服务提供方的身份信息检索该服务提供方所对应的订单，确定服务提供方是否存在未完成订单。若服务提供方存在未完成订单，则需要确定未完成订单与第一订单请求对应的待创建订单是否为重复订单。这里，重复订单可以指对应于同一次出行任务的两个订单，也可以指因客观因素(如出行时间存在冲突)无法均被完成的两个订单。

在此需要说明的是，未完成订单是服务器根据第二订单请求创建的，第二订单请求可以是由车载终端或移动终端发送的。其中，若第二订单请求是由车载终端发送，则未完成订单为线下订单；若第二订单请求是由移动终端发送，则未完成订单为线上订单。可以理解，第一订单请求和未完成订单对应的第二订单请求可以由同一个途径发送，也可以由不同的途径发送。

可选地，第一订单请求是通过车载终端发送的，而未完成订单对应的第二订单请求是通过的移动终端发送的；或者，第一订单请求是通过移动终端发送的，未完成订单对应的第二订单请求是通过的车载终端发送的。例如，在司机通过移动终端的司机端出行应用，接受服务乘客通过乘客端出行应用请求的出行任务的情况下，司机还需要按照规范对计价器进行扣表，这就会导致移动终端和车载终端先后发送订单请求，服务器基于第一个订单请求创建一个订单，并且在该订单未完成的情况下，接收到第二个订单请求，在这种情况下，未完成订单和第一订单请求对应的待完成订单属于重复订单。

可选地，第一订单请求和未完成订单对应的第二订单请求可以均是通过的移动终端发送的。例如，在司机通过移动终端的司机端出行应用，接受服务乘客通过乘客端出行应用请求的出行任务之后，在未执行该出行任务或该出行任务未执行完成的情况下，服务提供方存在未完成订单。在这种情况下，司机又继续通过移动终端的司机端出行应用接受服务乘客通过乘客端出行应用请求的出行任务，此时移动终端向服务器发送的订单请求为上述的第一订单请求。可以理解，第一订单请求和未完成订单对应的第二订单请求所对应的乘客可以是同一个人，也可以是不同的人。第一订单请求和未完成订单对应的第二订单请求所对应的出行任务的类型可以死相同的，也可以是不同的，其中，出行任务的可以包括预约车出行任务、快车出行任务和顺风车出行任务等。在这种情况下，未完成订单和第一订单请求对应的待完成订单既可能属于重复订单，也可以属于非重复订单。

在本公开实施例中，第一订单请求和未完成订单对应的第二订单请求可以均是通过的车载终端发送的。例如，司机在通过巡游的方式接到乘客之后，对计价器连续进行了两次扣表，因此车载终端会向服务器连续发送两次订单请求，由于设备故障(例如车载终端或服务器)导致在第二次扣表之前，服务器并未将基于第一次扣表所创建的订单结束，这就导致在服务提供方存在未完成订单的情况下，服务器会接收到车载终端因第二次扣表而发送的订单请求，其中，车载终端因第二次扣表而发送的订单请求为上述未完成订单对应的第二订单请求，车载终端因第二次扣表而发送的订单请求为上述的第一订单请求。在这种情况下，未完成订单和第一订单请求对应的待完成订单属于重复订单。

可选地，服务器在确定服务提供方存在未完成订单的情况下，可以根据未完成订单的订单信息，确定未完成订单的订单生成时间，并根据第一订单请求的请求信息，确定第一订单请求对应的待创建订单的订单创建时间。之后确定订单生成时间与订单创建时间之间的时间差是否小于第一预设时间间隔。若时间差小于第一预设时间间隔，确定未完成订单与待创建订单为重复订单；若时间差不小于第一预设时间间隔，确定未完成订单与待创建订单为非重复订单。例如，第一预设时间间隔可以根据实际的设计需要而定，例如，可以将第一预设时间间隔设置为2分钟。若上述的时间差小于2分钟，确定未完成订单与待创建订单为重复订单；若上述的时间差大于或等于2分钟，确定未完成订单与待创建订单为非重复订单。

可选地，对于针对第一订单请求和未完成订单对应的第二订单请求可以均是通过的移动终端发送的情况，服务器在确定出时间差小于第一预设时间间隔之后，还可以根据未完成订单和待创建订单的乘客信息、任务类型信息和乘车地点等至少一种信息，进一步确定未完成订单与待创建订单是否为重复订单。例如，在时间差小于第一预设时间间隔的情况下，如果未完成订单和待创建订单的对应于同一个乘客、且任务类型相同(例如均为快车出行任务)，则可以确定未完成订单与待创建订单为重复订单。或者，在时间差小于第一预设时间间隔的情况下，如果未完成订单和待创建订单的对应的乘车地点相同，则可以确定未完成订单与待创建订单为重复订单。

可选地，服务器在确定服务提供方存在未完成订单的情况下，可以根据未完成订单的订单信息，确定未完成订单对应的预估出行起始时间所处的第一预估时间段，并根据第一订单请求的请求信息，确定第一订单请求对应的待创建订单的预估出行起始时间所处的第二预估时间段；若第一预估时间段与第二预估时间段存在重叠时间，确定未完成订单与待创建订单为重复订单。

第一预估时间段和第二预估时间段所对应的时间范围可以根据实际的设计需要而定，例如，可以将未完成订单对应的预估出行起始时间的前后两分钟的时间段确定为第一预估时间段；将待创建订单的预估出行起始时间的前后两分钟的时间段确定为第二预估时间段。

可以理解，若未完成订单对应的预估出行起始时间为9:00，则第一预估时间段为8:58至9:02；若待创建订单的预估出行起始时间为9:03，则第二预估时间段为9:01至9:05。在上述情况下，第一预估时间段与第二预估时间段存在重叠时间，可以确定未完成订单与待创建订单为重复订单。

S130：若确定未完成订单与待创建订单为重复订单，基于未完成订单和第一订单请求，确定服务提供方的目标服务订单。

在服务器确定未完成订单与待创建订单为重复订单的情况下，需要对未完成订单与待创建订单进行去重，从而避免数据重复。应当理解，若确定未完成订单与待创建订单为非重复订单，服务器可以根据第一订单请求创建新订单。

可选地，服务器可以将第一订单请求确定为无效请求，可以理解，当第一订单请求被确定为无效请求时，服务器将不再根据第一订单请求创建新订单(即上述的待创建订单)，因此，可以将未完成订单确定为服务提供方的目标服务订单，从而使司机继续服务该目标服务订单对应的出行任务。

可选地，服务器可以获取第一订单请求对应的订单号；在将未完成订单的订单号替换为第一订单请求对应的订单号之后，将未完成订单确定为服务提供方的目标服务订单。

其中，将未完成订单的订单号替换为第一订单请求对应的订单号的方式可以应用在以下场景中：司机通过移动终端接收到出行任务通知，此时司机在接到乘客之后，先对计价器进行扣表，此时车载终端向服务器发送订单请求，服务器根据车载终端发送的订单请求创建线下订单；之后，在司机通过移动终端的司机端出行应用，接受服务乘客通过乘客端出行应用请求的出行任务，此时车载终端向服务器发送第一订单请求，服务器确定上述线下订单与第一订单请求对应的待创建订单为重复订单。在这种场景下，服务器可以获取第一订单请求对应的订单号；在将线下订单的订单号替换为第一订单请求对应的订单号之后，使得线下订单被修改成第一订单请求对应的线上订单。

在步骤S130之后，服务器可以在目标服务订单记录出行数据，其中，出行数据可以包括司机信息、车辆信息、乘客信息、乘车时间数据、费用数据和行驶轨迹数据等。如前文所述，车载终端和移动终端均可以记录记录司机所驾驶的车辆的行驶轨迹数据，为了便于理解和表述，可以将车载终端记录的行驶轨迹数据定义为第一行驶轨迹数据，将移动终端记录的行驶轨迹数据定义为第二行驶轨迹数据，将需要记录在目标服务订单中的行驶轨迹数据定义为目标行驶轨迹数据。为了确保目标行驶轨迹数据的准确性，可以服务器可以在目标服务订单对应的出行过程中，从车载终端获取第一行驶轨迹数据，以及从移动终端获取第二行驶轨迹数据；基于第一行驶轨迹数据和第二行驶轨迹数据，确定出目标服务订单对应的目标行驶轨迹数据。

可选地，可以将第一行驶轨迹数据和第二行驶轨迹数据进行融合，将融合后得到的行驶轨迹数据作为目标行驶轨迹数据。当然，也可以在确定第一行驶轨迹数据和第二行驶轨迹数据之中的一个行驶轨迹数据出现异常时，将未出现异常的行驶轨迹数据作为目标行驶轨迹数据。例如，第一行驶轨迹数据能够被记录在线下订单中，第二行驶轨迹数据能够被记录在线上订单中。在确定所述第一行驶轨迹数据出现异常时，以所述第二行驶轨迹数据代替所述第二行驶轨迹数据，将第二行驶轨迹数据作为目标行驶轨迹数据并记录在线下订单中；或者，在确定所述第二行驶轨迹数据出现异常时，以所述第一行驶轨迹数据代替所述第二行驶轨迹数据，将第一行驶轨迹数据作为目标行驶轨迹数据并记录在线上订单中。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与出行订单处理方法对应的出行订单处理装置，由于本公开实施例中的出行订单处理装置解决问题的原理与本公开实施例上述的出行订单处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图3和图4所示，图3为本公开实施例提供的一种出行订单处理装置的示意图之一，图4为本公开实施例提供的一种出行订单处理装置的示意图之二。如图3所示，出行订单处理装置包括请求接收模块、重复订单确定模块和目标订单确定模块。

请求接收模块用于接收服务提供方发送的第一订单请求。

重复订单确定模块用于在确定服务提供方存在未完成订单的情况下，基于未完成订单的订单信息与第一订单请求的请求信息，确定未完成订单与第一订单请求对应的待创建订单是否为重复订单。

目标订单确定模块用于在确定未完成订单与待创建订单为重复订单时，基于未完成订单和第一订单请求，确定服务提供方的目标服务订单。

在一种可选的实施方式中，重复订单确定模块在确定服务提供方存在未完成订单的情况下，基于未完成订单的订单信息与第一订单请求的请求信息，确定未完成订单与第一订单请求对应的待创建订单是否为重复订单时，具体用于：

在确定服务提供方存在未完成订单的情况下，根据未完成订单的订单信息，确定未完成订单的订单生成时间，并根据第一订单请求的请求信息，确定第一订单请求对应的待创建订单的订单创建时间；

确定订单生成时间与订单创建时间之间的时间差是否小于第一预设时间间隔；

若时间差小于第一预设时间间隔，确定未完成订单与待创建订单为重复订单。

在一种可选的实施方式中，服务提供方发送订单请求的途径包括通过车载终端发送订单请求，以及通过安装有出行应用的移动终端发送订单请求，订单请求包括第一订单请求和未完成订单对应的第二订单请求。

在一种可选的实施方式中，重复订单确定模块在确定服务提供方存在未完成订单的情况下，基于未完成订单的订单信息与第一订单请求的请求信息，确定未完成订单与第一订单请求对应的待创建订单是否为重复订单时，具体用于：

在确定服务提供方存在未完成订单的情况下，根据未完成订单的订单信息，确定未完成订单对应的预估出行起始时间所处的第一预估时间段，并根据第一订单请求的请求信息，确定第一订单请求对应的待创建订单的预估出行起始时间所处的第二预估时间段；

若第一预估时间段与第二预估时间段存在重叠时间，确定未完成订单与待创建订单为重复订单。

在一种可选的实施方式中，目标订单确定模块在用于基于未完成订单和第一订单请求，确定服务提供方的目标服务订单时，具体用于：

将第一订单请求确定为无效请求，并将未完成订单确定为服务提供方的目标服务订单。

在一种可选的实施方式中，目标订单确定模块在用于基于未完成订单和第一订单请求，确定服务提供方的目标服务订单时，具体用于：

获取第一订单请求对应的订单号；

在将未完成订单的订单号替换为第一订单请求对应的订单号之后，将未完成订单确定为服务提供方的目标服务订单。

在一种可选的实施方式中，服务提供方发送订单请求的途径包括通过车载终端发送订单请求，以及通过安装有出行应用的移动终端发送订单请求。如图4所示，出行订单处理装置还包括目标轨迹确定模块，目标轨迹确定模块用于：在目标服务订单对应的出行过程中，从车载终端获取第一行驶轨迹数据，以及从移动终端获取第二行驶轨迹数据；基于第一行驶轨迹数据和第二行驶轨迹数据，确定出目标服务订单对应的目标行驶轨迹数据。

关于装置中的各模块的处理流程，以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

基于同一发明构思，对应于图2中的出行订单处理方法，本公开实施例还提供了一种电子设备，如图5所示，为本公开实施例提供的电子设备的结构示意图。电子设备500包括处理器510、存储器520和总线530。存储器520用于存储执行指令，包括内存521和外部存储器522。这里的内存521也称内存储器，用于暂时存放处理器510中的运算数据，以及与硬盘等外部存储器522交换的数据，处理器510通过内存521与外部存储器522进行数据交换，当电子设备500运行时，处理器510与存储器520之间通过总线530通信，使得处理器510执行以下指令：

接收服务提供方发送的第一订单请求；

在确定服务提供方存在未完成订单的情况下，基于未完成订单的订单信息与第一订单请求的请求信息，确定未完成订单与第一订单请求对应的待创建订单是否为重复订单；

若确定未完成订单与待创建订单为重复订单，基于未完成订单和第一订单请求，确定服务提供方的目标服务订单。

基于同一发明构思，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的出行订单处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现上述的出行订单处理方法的步骤。其中，计算机程序产品可以是任何能实现上述出行订单处理方法的产品，该计算机程序产品中对现有技术做出贡献的全部或部分方案可以以软件产品(例如软件开发包(Software Development Kit，SDK))的形式体现，该软件产品可以被存储在一个存储介质中，通过包含的计算机指令使得相关设备或处理器执行上述出行订单处理方法的全部或部分步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

本公开实施例提供了一种出行订单处理方法、装置、设备、存储介质以及产品，具体如下：

TS1、一种出行订单处理方法，其特征在于，所述方法包括：

接收服务提供方发送的第一订单请求；

在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单；

若确定所述未完成订单与所述待创建订单为重复订单，基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单。

TS2、根据TS1所述的方法，其特征在于，所述在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单，包括：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单的订单生成时间，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的订单创建时间；

确定所述订单生成时间与所述订单创建时间之间的时间差是否小于第一预设时间间隔；

若所述时间差小于所述第一预设时间间隔，确定所述未完成订单与所述待创建订单为重复订单。

TS3、根据TS1所述的方法，其特征在于，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求，所述订单请求包括所述第一订单请求和所述未完成订单对应的第二订单请求。

TS4、根据TS1所述的方法，其特征在于，所述在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单，包括：

在确定所述服务提供方存在未完成订单的情况下，根据所述未完成订单的订单信息，确定所述未完成订单对应的预估出行起始时间所处的第一预估时间段，并根据所述第一订单请求的请求信息，确定所述第一订单请求对应的待创建订单的预估出行起始时间所处的第二预估时间段；

若所述第一预估时间段与所述第二预估时间段存在重叠时间，确定所述未完成订单与所述待创建订单为重复订单。

TS5、根据TS1所述的方法，其特征在于，所述基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单，包括：

将所述第一订单请求确定为无效请求，并将所述未完成订单确定为所述服务提供方的目标服务订单。

TS6、根据TS1所述的方法，其特征在于，所述基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单，包括：

获取所述第一订单请求对应的订单号；

在将所述未完成订单的订单号替换为所述第一订单请求对应的订单号之后，将所述未完成订单确定为所述服务提供方的目标服务订单。

TS7、根据TS1所述的方法，其特征在于，所述服务提供方发送订单请求的途径包括通过车载终端发送所述订单请求，以及通过安装有出行应用的移动终端发送所述订单请求；在确定出所述服务提供方的目标服务订单后，所述方法还包括：

在所述目标服务订单对应的出行过程中，从所述车载终端获取第一行驶轨迹数据，以及从所述移动终端获取第二行驶轨迹数据；

基于所述第一行驶轨迹数据和所述第二行驶轨迹数据，确定出所述目标服务订单对应的目标行驶轨迹数据。

TS8、一种出行订单处理装置，其特征在于，所述装置包括：

请求接收模块，用于接收服务提供方发送的第一订单请求；

重复订单确定模块，用于在确定所述服务提供方存在未完成订单的情况下，基于所述未完成订单的订单信息与所述第一订单请求的请求信息，确定所述未完成订单与所述第一订单请求对应的待创建订单是否为重复订单；

目标订单确定模块，用于在确定所述未完成订单与所述待创建订单为重复订单时，基于所述未完成订单和所述第一订单请求，确定所述服务提供方的目标服务订单。

TS9、一种电子设备，其特征在于，包括：处理器、存储器和总线；所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器运行时执行如TS1至7中任一项所述的出行订单处理方法的步骤。

TS10、一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如TS1至TS7中任意一项所述的出行订单处理方法的步骤。

TS11、一种计算机程序产品，包括计算机指令，其特征在于，所述计算机指令被处理器执行时实现如TS1至TS7中任意一项所述的出行订单处理方法的步骤。