CN111582526B - 网约车订单处理方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本发明提供一种网约车订单处理方法、装置、设备及计算机可读存储介质。方法包括：接收并显示预约回程订单的消息，第一订单为生成时间距离当前时间最近的用户的订单；响应于接收到用户的预约回程订单查看指令，显示预约回程订单；响应于接收到用户的确认回程订单指令，向订单处理服务器发送回程订单请求消息；预约回程订单的消息是订单处理服务器根据第一订单的信息和用户的第二订单的信息，确定第一订单与第二订单不是往返订单，并且根据用户的历史订单记录确定用户存在预约第一订单的回程订单的需求发送的。本发明的方案解决了用户实时约车时存在没有司机应答接单，导致打车难的问题。

Description

网约车订单处理方法、装置、设备及计算机可读存储介质

本发明是2018年07月05日提交的申请号为201810732137.4、发明名称为《网约车订单处理方法、装置、设备及计算机可读存储介质》的发明专利申请的分案申请。

技术领域

本发明涉及互联网技术，尤其涉及一种网约车订单处理方法、装置、设备及计算机可读存储介质。

背景技术

目前，在人们的日常出行中，网约车已经成为很多用户的选择，用户可以通过手机预约出租车，无需站在路边拦截出租车。由于网约车能够给用户带来快捷方便的用户体验，使得越来越多的用户出行时选择网约车。

现有技术中，由用户发起约车订单，从而使司机能够接受该预约订单。

但是，现有技术中的约车方案仅能够由用户主动发起，而用户主动约车存在着没有司机应答接单，进而导致用户打车难的问题。

发明内容

本发明提供一种网约车订单处理方法、装置、设备及计算机可读存储介质，用以解决用户主动约车存在着没有司机应答接单，进而导致用户打车难的问题。

本发明的第一个方面是提供一种网约车订单处理方法，包括：

接收用户的第一订单的信息；

根据所述第一订单获取所述用户的第二订单的信息，其中，所述第二订单的生成时间在所述第一订单之前并紧邻所述第一订单；

根据所述第一订单的信息、所述第二订单的信息判断第一订单与第二订单是否为往返订单；

若不是往返订单，则根据所述用户的历史订单记录确定所述用户是否存在预约所述第一订单的回程订单的需求；

若存在所述需求，则向所述用户的终端发送预约回程订单的消息；

其中，所述回程订单的起点与所述第一订单的终点相同，所述回程订单的终点与所述第一订单的起点相同。

本发明的另一个方面是提供一种网约车订单处理装置，包括：

接收模块，用于接收用户的第一订单的信息；

获取模块，用于根据所述第一订单获取所述用户的第二订单的信息，其中，所述第二订单的生成时间在所述第一订单之前并紧邻所述第一订单；

判断模块，用于根据所述第一订单的信息、所述第二订单的信息判断第一订单与第二订单是否为往返订单；

若不是往返订单，则确定模块根据所述用户的历史订单记录确定所述用户是否存在预约所述第一订单的回程订单的需求；

若存在所述需求，则发送模块向所述用户的终端发送预约回程订单的消息；

其中，所述回程订单的起点与所述第一订单的终点相同，所述回程订单的终点与所述第一订单的起点相同。

本发明的又一个方面是提供一种网约车订单处理设备，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并配置为由所述处理器执行以实现如上述第一方面所述的网约车订单处理方法。

本发明的再一个方面是提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如上述第一方面所述的网约车订单处理方法。

本发明提供的网约车订单处理方法、装置、设备及计算机可读存储介质的技术效果是：

本发明提供的网约车订单处理方法、装置、设备及计算机可读存储介质，包括接收用户的第一订单的信息；根据第一订单获取用户的第二订单的信息，其中，第二订单信息的生成时间在第一订单信息之前并紧邻第一订单；根据第一订单的信息、第二订单的信息判断第一订单与第二订单是否为往返订单；若不是往返订单，则根据用户的历史订单记录确定用户是否存在预约第一订单的回程订单的需求；若存在需求，则向用户的终端发送预约回程订单的消息；其中，回程订单的起点与第一订单的终点相同，回程订单的终点与第一订单的起点相同。本实施例提供的方法、装置、设备及计算机可读存储介质，通过确定用户最近生成的两个订单是否为往返订单，若不是往返订单，则进一步的根据用户的历史订单记录确定用户是否有预约第一订单的回程订单的需求，若有，则向用户推送预约回程订单的消息，即本发明所提供的方案中，能够根据用户最近两个订单的信息以及历史订单信息确定用户是否存在预约回程订单的需求，进而根据确定结果引导用户提前预约回程订单，能够解决用户在需要回到第一订单的出发地时不容易约到车的问题，同时还能够提高运力调控力度。

附图说明

图1为本发明一示例性实施例示出的网约车订单处理方法的流程图；

图1A-图1D为图1示例性实施例在实施时的界面示意图；

图2为本发明另一示例性实施例示出的网约车订单处理发送方法的流程图；

图2A为图2示例性实施例在实施时的界面示意图；

图3为本发明一示例性实施例示出的预约订单的消息发送装置的结构图；

图4为本发明另一示例性实施例示出的预约订单的消息发送装置的结构图；

图5为本发明一示例性实施例示出的网约车订单处理设备的结构图。

具体实施方式

图1为本发明一示例性实施例示出的网约车订单处理方法的流程图。

如图1所示，本实施例提供的网约车订单处理方法包括：

步骤101，接收用户的第一订单的信息。

其中，订单的信息可以是用户发出的用于预约出租车的订单请求，还可以是已经完成的订单的信息。可以由执行本实施例提供的方法的推送装置实时向接收订单请求的设备发送获取订单信息的请求，从而能够使接收订单请求的设备向推送装置发送第一订单信息，以使推送装置能够接收到最新的第一订单的信息。

具体的，若第一订单的信息是请求预约出租车时发送的订单请求，则可以在用户通过终端向订单处理服务器发送该订单请求时，同时向推送装置也发送该订单请求。还可以由订单处理服务器向推送装置发送该订单请求。另外，也可以是推送装置主动向订单处理服务器发送请求消息，以使订单处理服务器向推送装置发送的第一订单的信息。

进一步的，若第一订单的信息是已经完成的订单的信息，则可以在该订单完成后将其发送至推送装置，以使推送装置能够及时的获取最新的第一订单的信息。

实际应用时，第一订单的信息是指在众多订单的信息中，生成时间距离当前时间最近的订单的信息。例如，用户甲共有3个订单，生成的日期依次为2018年3月2日、2018年3月5日、2018年3月7日，那么在2018年3月7日生成的订单为第一订单，相应的，该订单的信息即为第一订单的信息。本实施例提供的方法中，可以通过将产生的订单实时发送至推送装置的方式，使推送装置能够及时获取第一订单的信息。另外，也可以由推送装置读取用户的全部订单信息，再在其中根据订单生成时间确定出第一订单的信息。

步骤102，根据第一订单获取用户的第二订单的信息，其中，第二订单的生成时间在第一订单之前并紧邻第一订单。

其中，可以获取第一订单的生成时间，再根据该生成时间，在用户的订单信息中获取生成时间在第一订单的生成时间之前并紧邻第一订单的第二订单，也就是除了第一订单以外的最新的订单，再获取第二订单对应的信息。

具体的，还可以根据用户标识信息获取该用户的订单信息，再在其中确定出满足要求的第二订单的信息。

进一步的，还可以直接按照生成时间对用户的订单进行排序，获取与第一订单相邻的订单。由于按生成时间排序，且第一订单是最新接收的订单，因此通过此方式获取的第二订单的生成时间在第一订单之前并与第一订单紧邻。

实际应用时，第二订单也可以理解为第一订单的上一个订单，即第一订单是最新生成的订单，第二订单是次新生成的订单。

步骤103，根据第一订单的信息、第二订单的信息判断第一订单与第二订单是否为往返订单。

其中，往返订单是指第一订单的出发地与第二订单的目的地相同，第二订单的出发地与第一订单的目的地相同的两个订单。例如，第一订单是从A前往B，第二订单是从B前往A，则可以认为这两个订单是往返订单。

具体的，第一订单的信息以及第二订单的信息中均包括出发地、目的地信息，可以根据两个订单中的出发地以及目的地，确定二者是否为往返订单。

进一步的，乘客乘坐出租车出行一般为短途出行，且当天就会往返。因此，还可以进一步的结合时间信息确定第一订单与第二订单是否为当天往返订单。此时，第一订单的信息以及第二订单的信息中还可以包括时间信息，该时间信息可以是用户发单时间，可以是司机接单时间，还可以是订单完成时间。确定第一订单的信息中包括的时间与第二订单中包括的时间是否为同一天，若是，则确定第一订单与第二订单是当天往返订单。也就是说，若第一订单的出发地与第二订单的目的地相同，第二订单的出发地与第一订单的目的地相同，且两个订单中包括的时间信息是同一天，则可以确定第一订单与第二订单是当天往返订单。

若步骤103中的判断结果为否，也就是不是往返订单，则执行步骤104，若步骤103中的判断结果为是，则执行步骤106。相应的，若步骤103中确定的为第一订单与第二订单是否为当天往返订单，则在确定二者不是当天往返订单时，执行步骤104。

步骤104，根据用户的历史订单记录确定用户是否存在预约第一订单的回程订单的需求。

实际应用时，用户的出行存在多种可能。例如下班后天气不好，用户可能打车从公司回家，此时，若用户上班时未打车，则会判断出该用户最近的两个订单并非往返订单，进而向用户推送预约该订单的回程订单的消息，因此，若仅根据往返订单确定用户是否存在预约第一订单的回程订单的需求，容易在很多情况下出现误判。因此，本实施例提供的方法在确定用户最近的两个订单并非往返订单后，还可以进一步的根据用户的历史订单记录，确定用户是否存在预约回程订单的需求。

其中，可以获取第一订单中的出发地，并确定该出发地在历史订单记录中出现的频率，若频率大于预设值，则可以确定用户存在预约回程订单的需求。若该地点出现在历史订单记录中的次数较多，则可以认为用户经常到这个地点去，例如家庭地址。因此，可以预测用户回到这个地点的几率较大。

具体的，还可以获取第一订单中出发地A和目的地B，在历史订单中查看是否存在以B为出发地，以A为目的地的历史订单，若存在，则可以预测用户需要返回A的几率较大。

若确定用户存在预约第一订单的回程订单的需求，则执行步骤105，否则执行步骤106。

步骤105，向用户的终端发送预约回程订单的消息。

若用户最近的两个订单，也就是第一订单和第二订单不是往返订单时，则可以确定用户可能存在从第一订单的目的地回到出发地的需求。此时，可以进一步根据用户历史订单记录确定用户是否存在预约回程订单的需求，若是，则向用户的终端发送预约回程订单的消息，引导用户提前预约回程单，避免实时约车引起打车难的问题。

实际应用时，可以由推送装置向用户终端发送消息，提醒用户可以预约回程订单。回程订单是指从第一订单的目的地回到出发地的约车订单，其中，回程订单的起点与第一订单的终点相同，回程订单的终点与第一订单的起点相同。

其中，可以以多种形式向用户终端发送消息，例如在用户打开网约车软件时，以卡片形式展现，或者以软件通知的形式展现，还可以通过短信、微信等多种方式向用户终端推送消息。当用户看到预约回程订单的消息后，可以根据该消息决定是否预约回程订单，若是，则可以直接点击该消息，从而触发终端内的网约车软件自动生成回程订单，并经过用户修改确认后，发出该回程订单。从而使用户能够提前预约出租车，避免在需要返回第一订单的出发地时，不容易打到车的问题；同时，引导用户提前预约车辆，还能够使一部分运力被提前占有，从而更有效的调控运力。

具体的，向用户终端发送消息的时机可以是用户发送了第一订单后，可以是第一订单的执行期间，还可以是第一订单完成以后。

步骤106，结束。

图1A-图1D为图1示例性实施例在实施时的界面示意图。

如图1A所示，可以在终端上显示推送预约回程订单的消息，从而使用户能够对其进行操作，预约回程订单。

用户对推送消息进行操作后，终端的显示界面可以如图1B所示。在该界面中，可以向用户展示回程订单对应的出发地以及目的地。此处的出发地以及目的地可以是服务器或终端后台根据第一订单进行确定的。

用户可以对图1B中的界面进行操作，修改出发地和目的地。根据第一订单确定的回程订单的出发地和目的地可能与用户实际的出发地和目的地有一定的偏差，因此，可以由用户对服务器或终端确定的回程订单进行调整，从而得到准确的回程订单。用户在调整完成后，可以操作确认按钮。

用户确认完成出发地以及目的地后，终端可以向用户展示图1C的界面，该界面用于向用户展示预约时间。由于推送预约回程订单的时间与用户实际出发的时间可能不一致，因此，可以由用户对出发时间进行设置，从而确定实际的出发时间。在用户设置了出发时间以后，用户可以操作确认按钮。

其中，可以向用户展示用于输入时间的输入框，用户可以在输入框中输入具体的时间，还可以向用户显示多个时间选项，由用户在其中进行选择。

在用户设置了出发时间以及出发地、目的地后，终端还可以向用户展示1D界面，在1D界面中可以展示该订单的详细信息，如不同类型车辆对应的价格，如车辆1为35元，车辆2为45元等。还可以展示出发时间、支付方式、乘车人是否为本人等信息。用户可以选择其中的车型，并对订单进行核对，最终确认回程订单。其中，框选的车型是指当前选中的车型。

具体的，图1D的界面中可以包括返回按钮，从而使用户可以返回到之前的设置页面对订单进行调整，用户还可以直接操作显示的各个内容，对其进行设置，例如，可以点击出发时间，进入到时间设置的展示界面，进而对出发时间进行调整。

需要说明的是，上述图1B与图1C的时序可以改变，即也可以先向用户展示用于设置出行时间的界面，再向用户展示设置出发地、目的地的界面。

本实施例提供的方法用于处理网约车订单，该方法由存储有本实施例提供的方法的设备执行，该设备通常以硬件和/或软件的方式来实现。

本实施例提供的网约车订单处理方法，包括接收用户的第一订单的信息；根据第一订单获取用户的第二订单的信息，其中，第二订单的生成时间在第一订单之前并紧邻第一订单；根据第一订单的信息、第二订单的信息判断第一订单与第二订单是否为往返订单；若不是往返订单，则根据用户的历史订单记录确定用户是否存在预约第一订单的回程订单的需求；若存在所述需求，则向用户的终端发送预约回程订单的消息；其中，回程订单的起点与第一订单的终点相同，回程订单的终点与第一订单的起点相同。本实施例提供的方法，通过确定用户生成时间相连的两个订单是否为往返订单，初步确定用户是否存在预约回程订单的需求，再根据用户的历史订单记录进一步的确定用户是否有预约回程订单的需求，若有，则向用户推送预约回程订单的消息，从而使用户能够引导用户提前预约回程单，避免用户在需要回到第一订单的出发地时不容易约到车的问题，同时还能够提高运力调控力度。

图2为本发明另一示例性实施例示出的网约车订单处理方法的流程图。

如图2所示，本实施例提供的网约车订单处理方法，包括：

步骤201，接收用户的第一订单的信息。

步骤202，根据第一订单获取用户的第二订单的信息，其中，第二订单的生成时间在第一订单之前并紧邻第一订单。

步骤201-202与步骤101-102的具体原理和实现方式类似，此处不再赘述。

步骤203，获取第一订单的信息中包括的第一出发地，第一目的地，获取第二订单的信息中包括的第二出发地，第二目的地。

其中，第一订单的信息中包括第一出发地、第一目的地。例如，用户从地点A前往地点B，则A为第一出发地，B为第一目的地。相似的，还可以获取第二订单信息中包括的第二出发地，第二目的地。

步骤204，判断是否同时满足以下条件：

第一出发地与第二目的地相同，第一目的地与第二出发地相同。

若同时满足上述条件，则可以认为第一订单与第二订单是往返订单，即用户从第一出发地出发以后，又返回到第一出发地，此时不需要向用户推送预约回程订单的消息。例如，第一订单中，用户从地点A出发前往地点B，第二订单中，用户从地点B出发前往地点A。此时，可以认为第一订单与第二订单是一对往返订单，用户已经返回了地点B，没有乘坐出租车再返回地点B的需求。因此，若本步骤的判断结果为是，则可以执行步骤205，并结束本方法。

若未同时满足上述条件，则认为第一订单与第二订单不是往返订单，此时，可以初步确定用户可能存在着返回第一出发地的需求，因此，可以根据用户的历史订单信息进一步的确定其是否存在返回第一出发地的需求。例如，第一订单中，用户从地点A出发前往地点B，第二订单中，用户从地点C出发前往地点D，可以认为此时的第一订单与第二订单没有关联关系，用户可能存在着从地点B返回地点A的需求。因此，若本步骤的判断结果为否，则执行步骤206，继续执行本实施例提供的方法。

步骤205，确定第一订单、第二订单为往返订单。

步骤206，根据用户的历史订单记录确定用户是否存在预约第一订单的回程订单的需求。

步骤206与步骤104的具体原理和实现方式类似，此处不再赘述。

本实施例提供的方案中，若确定用户存在预约第一订单的回程订单的需求，则可以进一步的根据其他信息确定是否满足向用户终端发送预约回程订单的消息的条件。若根据用户的历史订单记录确定用户不存在预约第一订单的回程订单的需求，则可以执行步骤211。

步骤207，获取第一订单的信息中包括的位置信息。

其中，可以获取第一订单的信息中包括的出发地、目的地信息，也可以直接使用步骤203中获取的第一出发地、第一目的地信息。

步骤208，根据位置信息确定环境信息，并根据环境信息判断是否满足向终端发送预约回程订单的消息的条件。

其中，环境信息可以包括以下至少一种：天气信息、历史路况信息、历史运力信息。

若环境信息满足以下至少一种条件，则可以判断满足向终端发送预约回程订单的消息的条件：

天气信息属于预设的恶劣天气情况、历史路况信息属于预设的拥堵路况情况、历史运力信息属于预设的运力不足情况。

具体的，可以通过接口查询天气信息，具体查询第一订单的信息中包括的位置信息未来一段时间内所对应的天气信息，具体时间段长度可以根据需求进行设置。例如，第一订单信息中包括的位置包括地点A、地点B，则查询这两个地点在未来四小时内的天气信息。还可以查询从地点A到地点B途径区域的天气信息。

进一步的，在确定了位置信息对应的天气信息后，可以判断天气信息是否属于预设的恶劣天气，若是，则判断满足向用户发送回程单的条件。可以预设恶劣天气，例如大风、下雨、下雪、冰雹、龙卷风等。若天气情况恶劣，就会造成打车需求增多，进而造成打车困难的问题，因此，在恶劣天气的情况下判断满足向用户发送预约回程订单消息的条件。

实际应用时，可以根据全部的历史路况信息，确定出第一订单信息中包括的位置信息在未来一段时间内的历史路况信息。具体可以结合地点信息以及时间确定该位置信息对应的历史路况信息。例如，可以确定四个小时后地点A、B的路况信息，根据当前时间确定四个小时后的目标时间，再在历史数据库中获取目标时间地点A、B的路况信息。另外，还可以结合节假日、是否有特殊活动的多维度的信息确定路况信息。

还可以预设拥堵路况标准，将获取的历史路况信息与拥堵路况标准比对，确定历史路况信息是否属于拥堵范围，具体可以按照车流量等数据进行确定。

其中，还可以根据历史数据信息，预测第一订单信息中包括的位置信息对应的历史运力信息。运力是指运输能力，例如某一区域内空载的出租车数量信息等。

具体的，还可以预设运力不足的标准，将获取的历史运力信息与运力不足的标准比对，确定历史运力信息是否属于运力不足的范围。

若路况拥堵或是运力不足，都会造成用户难以打到车的情况发生，因此，可以根据历史信息确定路况、运力信息，当确定未来一段时间存在路况不好或是运力不足的情况时，则确定满足向用户终端发送预约回程订单的消息的条件。

若步骤208的判断结果为是，也就是满足向用户终端发送预约回程订单的消息的条件，则执行步骤209，否则执行步骤211。

步骤209，根据环境信息确定约车难度等级。

其中，可以根据满足步骤208中条件的个数确定约车难度等级。例如，满足其中一个条件，则确定约车难度等级为低；满足其中两个条件，则确定约车难度等级为中；满足其中三个条件，则确定约车难度等级为高。

具体的，还可以根据具体的环境信息设定分值，再计算最终的总分值，并根据总分值确定约车难度等级。例如，可以将拥堵情况、运力情况、天气情况均分为多个级别，每个级别有相应的分值，再根据环境信息确定具体的分值，最终计算总分值。

步骤210，根据约车难度等级确定推送策略，根据推送策略向用户的终端发送预约回程订单的消息。

进一步的，可以预先设定多个推送策略，例如软件内推送、软件外推送等。再将其与设定的约车难度等级相匹配，当根据环境信息确定出相应的约车难度等级后，再获取相应的推送策略，并根据该推送策略向用户终端发送预约回程订单的消息。

实际应用时，若约车难度等级为低，则可以在软件内发送文字消息。例如，在用户打开软件后，可以弹出包括“请提前预约回程车”的对话框样。可以通过用户手动操作关闭该对话框，也可以设定对话框持续时间，使对话框自动关闭。

其中，若约车难度等级为中，则可以在软件内弹出包括环境信息的文字消息。例如，用户打开软件后，可以弹出“晚上8点到10点有大雨，提前预约回程车，避免高峰打车困难”。还可以弹出包含上述字样的预约卡片，卡片中除了这些内容外，还可以包括自动为用户设置的出发地、目的地、出发时间，若用户确认信息无误，可以通过预约卡片直接发送预约订单。

具体的，若约车难度等级为高，则还可以在软件外向用户发送预约卡片。例如通过短信、微信等多种方式发送，用户可以点击这些消息中的链接打开预约卡片，并调整、确认其中包括的内容，从而直接发送预约订单。

根据不同的约车难度等级确定相应的推送策略，能够在引导用户预约回程车的情况下，更加合理的利用推送资源。

步骤211，结束。

图2A为图2示例性实施例在实施时的界面示意图。

如图2A所示，本实施例在向用户推送预约回程订单的消息时，还可以展示具体的环境信息，如有大雨等。

图3为本发明一示例性实施例示出的网约车订单处理装置的结构图。

如图3所示，本实施例提供的网约车订单处理装置，包括：

接收模块31，用于接收用户的第一订单的信息；

获取模块32，用于根据第一订单获取所述用户的第二订单的信息，其中，所述第二订单的生成时间在所述第一订单之前并紧邻所述第一订单；

判断模块33，用于根据所述第一订单的信息、所述第二订单的信息判断第一订单与第二订单是否为往返订单；

若不是往返订单，则确定模块34根据所述用户的历史订单记录确定所述用户是否存在预约所述第一订单的回程订单的需求；

若存在所述需求，则发送模块35向所述用户的终端发送预约回程订单的消息；

其中，所述回程订单的起点与所述第一订单的终点相同，所述回程订单的终点与所述第一订单的起点相同。

本实施例提供的网约车订单处理装置，包括接收模块，用于接收用户的第一订单的信息；获取模块，用于根据第一订单获取用户的第二订单的信息，其中，第二订单的生成时间在第一订单之前并紧邻所述第一订单；判断模块，用于根据第一订单的信息、第二订单的信息判断第一订单与第二订单是否为往返订单；若不是往返订单，则确定模块根据用户的历史订单记录确定用户是否存在预约第一订单的回程订单的需求；若是，则发送模块向用户的终端发送预约回程订单的消息；其中，回程订单的起点与第一订单的终点相同，回程订单的终点与第一订单的起点相同。本实施例提供的装置，通过确定用户生成时间相连的两个订单是否为往返订单，若不是往返订单，则根据用户的历史订单记录确定用户是否有预约回程订单的需求，若有，则向用户推送预约回程订单的消息，从而使用户能够引导用户提前预约回程单，避免用户在需要回到第一订单的出发地时不容易约到车的问题，同时还能够提高运力调控力度。

本实施例提供的网约车订单处理装置的具体原理和实现方式均与图1所示的实施例类似，此处不再赘述。

图4为本发明另一示例性实施例示出的网约车订单处理装置的结构图。

如图4所示，在上述实施例的基础上，本实施例提供的预约订单的消息发送装置，所述获取模块32还包括：位置获取单元321，用于获取所述第一订单的信息中包括的位置信息；

所述判断模块33包括第一判断单元331，用于根据所述位置信息确定环境信息，并根据所述环境信息判断是否满足向所述终端发送所述预约回程订单的消息的条件；

若是，则所述发送模块35执行向所述用户的终端发送预约回程订单的消息的步骤。

可选的，所述环境信息包括以下至少一种：天气信息、历史路况信息、历史运力信息；

相应的，所述第一判断单元331具体用于：

若所述环境信息满足以下至少一种条件，则判断满足向所述终端发送所述预约回程订单的消息的条件：

所述天气信息属于预设的恶劣天气情况、所述历史路况信息属于预设的拥堵路况情况、所述历史运力信息属于预设的运力不足情况。

可选的，确定模块34，还用于根据所述环境信息确定约车难度等级；

相应的，所述发送模块35包括：

第一确定单元351，用于根据所述约车难度等级确定推送策略；

发送单元352，用于根据所述推送策略向所述用户的终端发送预约回程订单的消息。

可选的，所述判断模块33包括：获取单元332，第二判断单元333、第二确定单元334；

所述获取单元332用于获取所述第一订单的信息中包括的第一出发地，第一目的地，获取所述第二订单的信息中包括的第二出发地，第二目的地；

所述第二判断单元333用于判断是否同时满足以下条件：所述第一出发地与第二目的地相同，所述第一目的地与所述第二出发地相同；

若是，则所述第二确定单元334确定所述第一订单、所述第二订单为所述往返订单

本实施例提供的网约车订单处理装置的具体原理和实现方式均与图2所示的实施例类似，此处不再赘述。

图5为本发明一示例性实施例示出的网约车订单处理设备的结构图。

如图5所示，本实施例提供的网约车订单处理设备，包括：

存储器51；

处理器52；以及

计算机程序；

其中，所述计算机程序存储在所述存储器51中，并配置为由所述处理器52执行以实现如上所述的任一种网约车订单处理方法。

本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，

所述计算机程序被处理器执行以实现如上所述的任一种网约车订单处理方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (16)

1.一种网约车订单处理方法，其特征在于，包括：

接收并显示预约回程订单的消息，所述回程订单为从用户的第一订单的目的地回到出发地的约车订单，所述第一订单为生成时间距离当前时间最近的所述用户的订单；

响应于接收到用户的预约回程订单查看指令，显示预约回程订单；

响应于接收到用户的确认回程订单指令，向订单处理服务器发送回程订单请求消息；

其中，所述预约回程订单的消息是所述订单处理服务器根据所述第一订单的信息和所述用户的第二订单的信息，确定第一订单与第二订单不是往返订单，并且根据所述用户的历史订单记录确定所述用户存在预约所述第一订单的回程订单的需求发送的；所述第二订单的生成时间在所述第一订单之前并紧邻所述第一订单。

2.根据权利要求1所述的方法，其特征在于，接收预约回程订单的消息，包括：

在向所述订单服务器发送所述第一订单的请求消息后，接收预约回程订单的消息；或者，

在所述第一订单的执行期间，接收预约回程订单的消息；或者，

在所述第一订单完成后，接收预约回程订单的消息。

3.根据权利要求1所述的方法，其特征在于，所述响应于接收到用户的确认回程订单指令，向订单处理服务器发送回程订单请求消息之前，还包括：

响应于接收到用户的回程订单修改指令，对所述回程订单进行修改，获得修改后的回程订单；

响应于接收到用户的确认回程订单指令，向订单处理服务器发送回程订单请求消息，包括：

响应于接收到用户的确认回程订单指令，向订单处理服务器发送修改后的回程订单请求消息。

4.根据权利要求3所述的方法，其特征在于，对所述回程订单进行修改，包括：

对所述回程订单中的如下一项或多项进行修改：

出发地；

目的地；

出发时间；

预约车型；

乘车人。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述显示预约回程订单的消息，包括：

以网约车软件的卡片形式显示所述预约回程订单的消息；或者，

以网约车软件通知的形式显示所述预约回程订单的消息；或者，

通过短信息方式显示所述预约回程订单的消息。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述预约回程订单的消息包括环境信息，所述环境信息为与所述第一订单的位置信息有关的环境信息。

7.根据权利要求6所述的方法，其特征在于，所述环境信息包括如下一项或多项：天气信息、历史路况信息、历史运力信息。

8.根据权利要求7所述的方法，其特征在于，所述天气信息属于预设的恶劣天气情况，所述历史路况信息属于预设的拥堵路况情况，所述历史运力信息属于预设的运力不足情况。

9.根据权利要求6所述的方法，其特征在于，约车难度等级与所述环境信息有关；

所述显示预约回程订单的消息，包括：

若所述约车难度等级为第一等级，以网约车软件通知的形式显示所述预约回程订单的消息；或者，

若约车难度等级为第二等级，则以网约车软件的卡片形式显示所述预约回程订单的消息；或者，

若所述约车难度等级为第三等级，通过短信息方式显示所述预约回程订单的消息。

10.根据权利要求1-4任一项所述的方法，其特征在于，所述根据所述用户的历史订单记录确定所述用户存在预约所述第一订单的回程订单的需求，包括：

确定所述第一订单的出发地在所述历史订单记录中出现在的频率；

若所述频率大于预设值，则确定所述用户存在预约所述第一订单的回程订单的需求。

11.根据权利要求1-4任一项所述的方法，其特征在于，所述根据所述用户的历史订单记录确定所述用户存在预约所述第一订单的回程订单的需求，包括：

根据所述第一订单的出发地和目的地，确定所述历史订单记录中是否存在以所述第一订单的出发地为目的地以及以所述第一订单的目的地为出发地的历史订单；

若存在，则确定所述用户存在预约所述第一订单的回程订单的需求。

12.根据权利要求1-4任一项所述的方法，其特征在于，所述根据所述第一订单的信息和所述第二订单的信息，确定第一订单与第二订单不是往返订单，包括：

获取所述第一订单的信息中包括的第一出发地和第一目的地，获取所述第二订单的信息中包括的第二出发地和第二目的地；

如果未同时满足以下条件：所述第一出发地与所述第二目的地相同，所述第一目的地与所述第二出发地相同，则确定所述第一订单、所述第二订单不是所述往返订单。

13.根据权利要求1-4任一项所述的方法，其特征在于，所述根据所述第一订单的信息和所述第二订单的信息，确定第一订单与第二订单不是往返订单，包括：

获取所述第一订单的信息中包括的第一出发地、第一目的地和第一时间信息，获取所述第二订单的信息中包括的第二出发地、第二目的地和第二时间信息；

如果未同时满足以下条件：所述第一出发地与所述第二目的地相同，所述第一目的地与所述第二出发地相同，所述第一时间信息与所述第二时间信息属于同一天，则确定所述第一订单、所述第二订单不是所述往返订单。

14.一种网约车订单处理装置，其特征在于，包括：

接收模块，用于接收预约回程订单的消息，所述回程订单为从用户的第一订单的目的地回到出发地的约车订单，所述第一订单为生成时间距离当前时间最近的所述用户的订单；

显示模块，用于显示预约回程订单的消息；以及响应于接收到用户的预约回程订单查看指令，显示预约回程订单；

发送模块，用于响应于接收到用户的确认回程订单指令，向订单处理服务器发送回程订单请求消息；

其中，所述预约回程订单的消息是所述订单处理服务器根据所述第一订单的信息和所述用户的第二订单的信息，确定第一订单与第二订单不是往返订单，并且根据所述用户的历史订单记录确定所述用户存在预约所述第一订单的回程订单的需求发送的；所述第二订单的生成时间在所述第一订单之前并紧邻所述第一订单。

15.一种网约车订单处理设备，其特征在于，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并配置为由所述处理器执行以实现如权利要求1-13任一种所述的方法。

16.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，

所述计算机程序被处理器执行以实现如权利要求1-13任一种所述的方法。

Images