CN111028053B - 一种订单处理的方法、装置、电子设备及存储介质 - Google Patents

一种订单处理的方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN111028053B
CN111028053B CN201911222028.9A CN201911222028A CN111028053B CN 111028053 B CN111028053 B CN 111028053B CN 201911222028 A CN201911222028 A CN 201911222028A CN 111028053 B CN111028053 B CN 111028053B
Authority
CN
China
Prior art keywords
order
service
service request
target
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911222028.9A
Other languages
English (en)
Other versions
CN111028053A (zh
Inventor
郄小虎
孙满利
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201911222028.9A priority Critical patent/CN111028053B/zh
Publication of CN111028053A publication Critical patent/CN111028053A/zh
Application granted granted Critical
Publication of CN111028053B publication Critical patent/CN111028053B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0833—Tracking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0837—Return transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0838—Historical data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

本申请提供了一种订单处理的方法、装置、电子设备及存储介质，其中，该方法包括：在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；若是，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。采用上述方案，能够结合乘客触发的关单指示以及订单取消条件的判断结果，实现订单的自动取消，避免了人工介入所存在的费时费力的问题，省时省力。

Description

一种订单处理的方法、装置、电子设备及存储介质
技术领域
本申请涉及计算机技术领域，具体而言，涉及一种订单处理的方法、装置、电子设备及存储介质。
背景技术
近些年，由于网约车的便捷性和实用性，网约车规模迅速扩张。乘客可以通过网约车服务平台发起出行订单，以便司机接单后到达指定地点接乘客到目的地，从而方便乘客出行。
在司机接到乘客之后，网约车服务平台即可通过司机触发的“乘客已上车”按钮开始出行订单的计费操作，还可以通过司机触发的“乘客已到达”按钮结束出行订单的计费操作。可知，上述触发操作均是由司机执行的。
这样，一旦乘客对订单存在异议(如乘客并未上车但产生计费)，往往需要借助网约车服务平台上的客服人员来解决问题，也即乘客首先需要将问题反馈给客服人员，客服人员再线下分别对乘客、司机进行求证，整个过程耗时耗力。
发明内容
有鉴于此，本申请的目的在于提供至少一种订单处理的方案，能够结合乘客触发的关单指示以及订单取消条件的判断结果，实现订单的自动取消，省时省力。
主要包括以下几个方面：
第一方面，本申请提供了一种订单处理的方法，所述方法包括：
在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
若是，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。
在一种实施方式中，检测所述目标订单对应的服务请求端是否符合订单取消条件之前，还包括：
接收所述服务请求端触发的关单指示信息。
在一种实施方式中，检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，还包括：
向所述服务请求端推送是否取消订单的提示信息；
基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
在一种实施方式中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
在一种实施方式中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据；
和/或，
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
在一种实施方式中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
在一种实施方式中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述服务特征数据包括所述目标订单对应的服务提供端的当前轨迹点位置信息、以及所述目标订单对应的服务请求端的当前轨迹点位置信息，所述根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，确定所述目标订单对应的服务请求端符合订单取消条件。
在一种实施方式中，所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
在一种实施方式中，基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，还包括：
向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
在一种实施方式中，基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
第二方面，本申请还提供了一种订单处理的方法，所述方法包括：
接收服务器推送的是否取消订单的提示信息；
将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
在一种实施方式中，所述方法还包括：
接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
第三方面，本申请还提供了一种订单处理的装置，所述装置包括：
数据获取模块，用于在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
条件检测模块，用于根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
订单取消模块，用于若符合所述订单取消条件，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。
在一种实施方式中，所述条件检测模块，还用于：
在检测所述目标订单对应的服务请求端是否符合订单取消条件之前，接收所述服务请求端触发的关单指示信息。
在一种实施方式中，所述订单取消模块，还用于：
检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，向所述服务请求端推送是否取消订单的提示信息；
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
在一种实施方式中，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据；
和/或，
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述服务特征数据包括所述目标订单对应的服务提供端的当前轨迹点位置信息、以及所述目标订单对应的服务请求端的当前轨迹点位置信息，所述条件检测模块，用于按照如下步骤检测所述目标订单对应的服务请求端是否符合订单取消条件：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，确定所述目标订单对应的服务请求端符合订单取消条件。
在一种实施方式中，所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述条件检测模块，用于按照如下步骤检测所述目标订单对应的服务请求端是否符合订单取消条件：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
在一种实施方式中，所述装置还包括：
订单生成模块，用于基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
在一种实施方式中，所述订单取消模块，用于按照如下步骤取消所述目标订单：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
第四方面，本申请还提供了一种订单处理的装置，所述装置包括：
信息接收模块，用于接收服务器推送的是否取消订单的提示信息；
信息发送模块，用于将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
在一种实施方式中，所述装置还包括：
下单提示模块，用于接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
第五方面，本申请还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面及其各种实施方式、第二方面及其各种实施方式中任一所述订单处理的方法的步骤。
第六方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面及其各种实施方式、第二方面及其各种实施方式中任一所述订单处理的方法的步骤。
采用上述方案，服务器在确定目标订单对应的行程开启之后，可以获取与所述目标订单对应的服务特征数据，并根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，在确定符合订单取消条件之后，即可以根据服务请求端触发的关单指示信息，取消所述目标订单。上述方案可以利用服务特征数据确定目标订单对应的行程开启操作是否合理，也即，可以对司机的服务行为进行监控，并能够在确定出行程开启不合理时，认定乘客符合订单取消条件，这时，即可以根据乘客触发的关单指示信息进行订单的自动取消，整个订单取消过程无需客服人员的介入，省时省力，从而进一步提升了网约车服务平台的服务质量。
为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种服务系统的架构示意图；
图2示出了本申请实施例一提供的一种订单处理的方法的流程图；
图3(a)～3(b)示出了本申请实施例提供的一种订单处理的方法的应用示意图；
图4(a)～4(b)示出了本申请实施例提供的一种订单处理的方法的应用示意图；
图5示出了本申请实施例一提供的一种订单处理的方法中，确定服务特征数据的具体方法的流程图；
图6示出了本申请实施例一提供的一种订单处理的方法中，一种检测订单取消条件的具体方法的流程图；
图7示出了本申请实施例一提供的一种订单处理的方法中，另一种检测订单取消条件的具体方法的流程图；
图8示出了本申请实施例一提供的一种订单处理的方法中，生成新的订单的具体方法的流程图；
图9示出了本申请实施例一提供的一种订单处理的方法的应用示意图；
图10示出了本申请实施例二提供的一种订单处理的方法的流程图；
图11示出了本申请实施例三提供的一种订单处理的装置的结构示意图；
图12示出了本申请实施例三提供的另一种订单处理的装置的结构示意图；
图13示出了本申请实施例四提供的一种电子设备的结构示意图；
图14示出了本申请实施例四提供的另一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网约车出行服务中的订单处理”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕网约车出行服务中的订单处理进行描述，但是应该理解，这仅是一个示例性实施例。
需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
本申请中的术语“乘客”、“请求方”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”和“供应商”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户可以是乘客、驾驶员、操作员等，或其任意组合。在本申请中，“乘客”、“乘客终端”、“服务请求端”可以互换使用，“驾驶员”、“驾驶员终端”、“司机”、“司机终端”、“服务提供端”可以互换使用。
本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合发起的请求。接受该“服务请求”或“订单”的可以是乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合。服务请求可以是收费的或免费的。
值得注意的是，在提出本申请之前，相关技术中一旦乘客对订单存在异议，往往需要借助网约车服务平台上的客服人员来解决问题，也即乘客首先需要将问题反馈给客服人员，客服人员再线下分别对乘客、司机进行求证，整个过程耗时耗力。有鉴于此，本申请的一个方面涉及一种服务系统，该系统一方面能够结合乘客触发的关单指示以及订单取消条件的判断结果，实现订单的自动取消，省时省力。
图1是本申请实施例提供的一种服务系统的架构示意图。例如，服务系统可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统可以包括服务器101、网络102、服务请求端103、服务提供端104、和数据库105中的一种或多种。
在一些实施例中，服务器101可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务请求端103获得的服务请求来确定目标车辆。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(Application Specific IntegratedCircuit,ASIC)、专用指令集处理器(Application Specific Instruction-setProcessor,ASIP)、图形处理单元(Graphics Processing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field Programmable Gate Array,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(ReducedInstruction Set Computing,RISC)、或微处理器等，或其任意组合。
在一些实施例中，服务请求端103和服务提供端104对应的设备类型可以是移动设备，比如可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动车辆中的内置设备等。
在一些实施例中，数据库105可以连接到网络102以与服务系统中的一个或多个组件(例如，服务器101，服务请求端103，服务提供端104等)通信。服务系统中的一个或多个组件可以经由网络102访问存储在数据库105中的数据或指令。在一些实施例中，数据库105可以直接连接到服务系统中的一个或多个组件，或者，数据库105也可以是服务器101的一部分。
下面结合上述图1示出的服务系统中描述的内容，通过如下几个实施例对本申请提供的至少一种订单处理的方案进行详细说明。
实施例一
参照图2所示，为本申请实施例一提供的一种订单处理的方法的流程示意图，该方法可以由服务系统中的服务器来执行，具体执行过程为：
S201、在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据。
这里，为了便于理解本申请提供的订单处理的方法，首先对网约车出行服务对应的应用场景进行简单说明。目前，在乘客需要利用网约车服务平台出行时，一旦启动发单按钮发出服务请求，网约车平台的后台服务器便能够基于乘客的打车信息生成对应的服务订单，将服务订单派送给对应的司机以方便司机为乘客提供网约车出行服务。在司机针对服务订单触发上车按钮之后，即可以开启订单对应的行程，这时通常会对订单开始计费。
本申请实施例中的目标订单可以是在预设出行服务范围内产生的服务订单，这样，针对行程开启的目标订单而言，可以获取与该目标订单对应的服务特征数据，以便后续进行订单取消条件的检测。
其中，上述与目标订单对应的服务特征数据可以是订单的基本属性数据(即订单属性数据)，该基本属性数据可以是订单发车时间、距离终点的时间和距离、打车费用等相关属性信息；还可以是司乘的相关统计数据，如司机服务分及其历史投诉量、乘客信用分等；还可以是司乘的出行轨迹点位置等信息；还可以是司机和乘客的交流数据，如电话沟通内容、线上文本沟通内容等，还可以是其它有助于进行订单取消条件检测的服务特征数据，本申请实施例对此不做具体的限制。
此外，上述服务特征数据可以是直接从目标订单中获取的，如基本属性数据，还可以是基于目标订单对应的司乘标识从订单数据库中调取的相关司乘数据，还可以是与目标订单绑定的行车设备发送的相关数据，本申请实施例对此不做具体的限制。
值得说明的是，有关出行轨迹点位置可以是基于定位技术确定的，本申请中使用的定位技术可以基于全球定位系统(Global Positioning System,GPS)、全球导航卫星系统(Global Navigation Satellite System,GLONASS)，罗盘导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(Quasi-Zenith Satellite System,QZSS)、无线保真(WirelessFidelity,WiFi)定位技术等，或其任意组合。一个或多个上述定位系统可以在本申请中互换使用。
S202、根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件。
这里，在获取到服务特征数据之后，可以根据上述服务特征数据中的一种或多种，来检测服务请求端是否符合订单取消条件。如在确定司机和乘客之间的距离较大时，可以基本判断出司机触发行程开启的操作是不合理的，也即，可以基本确定乘客满足取消订单的要求。再如，在确定乘客的信用分较低时，有关针对上述距离判断方式进行订单取消条件的检测时，即使司机和乘客的距离较大，也可能不会被认定为满足取消订单的要求，以避免乘客信用对订单取消条件的正确检测带来不利影响。再如，本申请实施例还可以综合利用上述各种服务特征数据来确定乘客是否满足取消订单的要求，以进一步提升订单取消条件检测的准确性。
为了提升本申请实施例提供的订单处理的方法在各种应用场景中的适用性，本申请实施例中，服务器一方面可以一旦确定司机触发行程开启的按钮，则直接进行服务请求端是否符合订单取消条件的检测，以能够提前预判乘客是否具有取消订单的需求，从而提升网约车服务平台的服务质量，另一方面，可以在确定司机触发行程开启的按钮之后，确定是否接收到乘客触发的关单指示信息，基于这一关单指示信息再进行服务请求端是否符合订单取消条件的检测，以能够在满足用户对订单取消的需求的前提下，降低服务器的检测工作量。
S203、若是，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。
这里，本申请实施例中，在确定出乘客符合订单取消条件之后，即可以基于乘客通过服务请求端触发的关单指示信息进行目标订单的取消。
考虑到本申请实施例中有关订单取消条件的检测时机与乘客触发的关单指示信息之间存在着一定的联系，可以结合如下两个方面对取消目标订单的过程进行说明。
第一方面，服务器可以在确定司机触发行程开启的相关按钮后，直接进行服务请求端是否符合订单取消条件的检测，这时，需要在确定符合订单取消条件之后，向服务请求端推送是否取消订单的提示信息，这样，服务器在接收到服务请求端基于提示信息触发的关单指示信息时，即可以基于关单指示信息，取消目标订单。
在具体应用中，在向服务请求端推送是否取消订单的提示信息之后，服务请求端可以根据该提示信息生成取消订单按钮，如图3(a)所示，这时，在乘客触发该取消订单按钮之后，服务器可以基于该取消订单按钮响应的关单指示信息，取消订单，如图3(b)为服务请求端取消订单之后所显示的页面。
第二方面，服务器在确定司机触发行程开启的相关按钮之后，可以先确定是否接收到乘客触发的关单指示信息，然后再基于接收到的关单指示信息进行服务请求端是否符合订单取消条件的检测，而后执行订单的取消操作。
在具体应用中，在确定司机触发行程开启的相关按钮之后，可以直接向服务请求端推送是否上车的提示信息；服务请求端可以根据该提示信息生成我没上车按钮，如图4(a)所示，这时，在乘客触发我未上车按钮之后，可以进入订单取消界面，如图4(b)所示，若乘客在订单取消界面触发取消订单按钮，则服务器可以在接收到该取消订单按钮响应的关单指示信息之后，进行服务请求端是否符合订单取消条件的检测。
值得说明的是，上述第一方面涉及的有关订单处理的方法，可以直接向服务请求端推送是否取消订单的提示信息，也可以基于上述图4(a)所示的我没上车按钮的触发前提下，再向服务请求端推送是否取消订单的提示信息，本申请对此不做具体的限制。
为了进一步提升网约车出行服务平台的服务质量，本申请实施例在推送订单取消界面的时候，还可以将司机电话确认等相关提醒按钮一同呈现，如图3(a)和4(b)所示，以缓和由于司机误操作等情况所可能存在的订单取消问题。
为了在满足乘客取消订单的需求的前提下，避免恶意取消行为对网约车服务平台的服务质量造成的不良影响，本申请实施例在取消目标订单时，除了需要基于服务请求端触发的关单指示信息，还可以查找该服务请求端在最近预设时长(如一天、一个月等时长)内触发的历史关单指示信息，以基于查找到的历史关单指示信息的个数来约束当前次对目标订单的取消操作，如乘客在最近一个月内已经取消过5次订单，这时，在该乘客针对目标订单再次进行关单指示信息的触发时，可以提示乘客关单失败，从而兼顾了大多数乘客的订单取消需求和网约车服务平台的服务质量。
考虑到本申请实施例中有关服务特征数据的获取操作是实现订单取消条件检测的关键步骤，接下来通过如下几个方面，对本申请实施例中可以利用到的服务特征数据的获取过程进行具体说明。
第一方面：本申请实施例可以直接从目标订单中提取订单属性数据，并将该订单属性数据作为一种服务特征数据。有关订单属性数据的相关内容在上述内容中已经进行了相关描述，在此不再赘述。
第二方面：本申请实施例中可以将服务提供端的服务评分数据作为一种服务特征数据，还可以将服务请求端的乘车信用数据作为一种服务特征数据。有关服务评分数据和乘车信用数据的获取过程类似，接下来以服务评分数据的获取进行示例。如图5所示，上述服务评分数据的获取方法具体包括如下步骤：
S501、针对与目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
S502、通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
S503、将所述服务评分数据确定为一种服务特征数据。
这里，可以从各个历史订单中查找与服务提供端对应的历史订单，基于对各个历史订单的分析，即可以确定服务提供端的服务评分数据，该服务评分数据可以基于乘客对各个历史订单中有关司机的服务行为进行打分或打星等确定，还可以结合着司机的历史投诉等情况来确定，还可以结合着司机的其它服务行为来确定。本申请实施例中的服务评分数据可以是一个平均服务评分值。
与上述有关服务评分数据类似的是，本申请实施例可以基于服务请求端对应的各个历史订单，确定服务请求端的乘车信用数据，该乘车信用数据可以是基于司机对各个历史订单中有关乘客的乘车行为进行打分或打星等确定，还可以结合着乘客是否如约定时间上车、是否经常在派单之后取消订单等行为来确定，还可以结合着乘客的其它乘车行为来确定。本申请实施例中的乘车信用数据可以是一个平均乘车信用值。
第三方面：本申请可以获取与目标订单对应的服务提供端与服务请求端之间的乘车记录信息，并将该乘车记录信息，确定为一种服务特征数据。
其中，上述乘车记录信息可以是语音沟通记录信息，还可以是利用终端设备输入的文本沟通记录信息。其中，有关语音沟通记录信息，可以是基于服务请求端开启的语音记录功能获取的，还可以是基于行车设备获取的，而后通过行车设备与服务器的连接关系上传的，本申请实施例对此不做具体的限制。
本申请实施例中，可以对上述文本沟通记录信息进行分析，如在到达乘客上车点时，是否发送我已到达上车点等信息给到乘客，从而确定司乘之前的沟通情况。除此之外，本申请实施例中，还可以对上述语音沟通记录信息进行分析，以进一步确定司乘双方的沟通情况，如确定司机在出发行程开启的按钮时，是否提前与乘客进行了电话沟通，再如，在乘客上车后，是否获取到乘客已上传的语音应答信息。
第四方面：本申请实施例还可以获取服务提供端的轨迹点位置信息，和/或服务请求端的轨迹点位置信息，并将轨迹点位置信息确定为一种服务特征数据。
其中，有关轨迹点位置信息的获取，可参照上述描述内容，在此不在赘述。
值得说明的是，本申请实施例中利用的轨迹点位置信息可以是一个轨迹点位置信息，如当前轨迹点位置信息，还可以是一段行驶轨迹的位置信息，从而提升取消订单检测的全面性。
这里，有关服务请求端的轨迹点位置信息可以是服务器在确定乘客打开服务请求端上的打车软件时，向该服务请求端发出定位请求后确定的位置，还可以是服务请求端在向服务端发出关单指示信息时，主动上报的轨迹点位置信息，本申请实施例对此不做具体的限制。
基于上述四个方面所描述的各种服务特征数据，本申请实施例可以基于各种服务特征数据中的一种或多种来确定服务请求端是否符合订单取消条件。可以基于不同应用场景的需求来选取不同的服务特征数据进行有关订单取消条件的检测。
考虑到乘客距离司机的距离将会对乘客的上车行为带来直接影响，基于此，本申请实施例可以按照如下步骤实现未上车情况的检测，如图6所示。
S601、基于服务提供端的当前轨迹点位置信息、以及服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
S602、在确定出所述距离信息大于预设距离阈值时，确定目标订单对应的服务请求端符合订单取消条件。
这里，可以在司机触发行程开启的按钮之后，基于服务提供端的当前轨迹点位置信息和服务请求端的当前轨迹点位置信息，确定服务提供端和服务请求端之间的距离，在该距离大于预设距离阈值(如500米)时，可以确定服务请求端符合订单取消条件，这时，即可以根据服务请求端触发的关单指示信息取消目标订单。
考虑到在网约车出行服务平台进行网约车服务时，往往会出现各种复杂情形，因此，本申请实施例除了可以基于距离来进行订单取消条件的检测，还可以结合上述其它各种服务特征数据进行检测。如图7所示，本申请实施例可以按照如下步骤实现订单取消条件的检测。
S701、基于服务提供端的当前轨迹点位置信息、以及服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
S702、在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
S703、若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
S704、若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
S705、若是，则确定所述服务请求端符合订单取消条件。
这里，本申请实施例可以在服务提供端与所述服务请求端之间的距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件。
其中，在距离信息大于预设距离阈值，如果根据乘车记录信息发现司机与乘客并无任何沟通等操作，这时，可以确定初步符合订单取消条件，但如果根据乘车记录信息可以确定司机与乘客进行了预先沟通等操作，即使距离信息大于预设距离阈值，可以确定初步不符合订单取消条件，这主要是考虑到这时司机的开启行程操作很大概率可能是误操作。
在确定服务请求端初步符合订单取消条件之后，可以根据服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值，也即，如果服务提供端的服务评分数据远远高于服务请求端的乘车信用数据，这时，需要进一步对乘客的乘车行为进行分析，如果服务请求端的乘车信用数据远远高于服务提供端的服务评分数据，可以一定程度上认为乘客的订单取消行为是由于真实发生的未上车事件所触发的。
这里，如果进一步确定接驾时长小于预设时长阈值(如3分钟)，则可以进一步确定上述乘客的订单取消行为是由于真实发生的未上车事件所触发的行为，从而确定服务请求端符合订单取消条件。
值得说明的是，上述有关基于各种服务特征数据进行订单取消条件的检测方案仅仅是示例内容，在具体应用中，有关利用的服务特征数据的个数、先后顺序等均可以基于不同的应用需求进行调整，本申请实施例对此不做具体的限制。
为了进一步提升网约车出行服务平台的服务质量，本申请实施例在取消目标订单之后，还可以为乘客重新叫车，优先排队派单，提升乘客体验。如图8所示，有关上述优先派单的方法可以包括如下步骤：
S801、向服务请求端推送是否再次下单的提示信息；
S802、接收所述服务请求端基于所述提示信息触发的下单指示信息；
S803、基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
这里，在服务器取消目标订单之后，可以向服务请求端推送是否再次下单的提示信息，在接收到服务请求端基于所述提示信息触发的下单指示信息之后，可以基于下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。也即，本申请实施例可以为由于未上车所导致的订单取消的乘客优先派单，从而确保乘客的乘车体验。
值得说明的是，为了进一步提升服务效率，本申请实施例一旦取消目标订单，即可以直接从目标订单中获取乘客的出行起始位置和出行终止位置为其生成新的订单，而无需乘客触发下单指示信息。
与此同时，本申请实施例提供的订单处理的方法还可以在确定取消目标订单之后，向该目标订单对应的司机播放订单已取消的通知，还可以对该司机进行管控，如可以通过扣除司机的服务分等方式约束司机的服务行为，以进一步提升网约车出行服务平台的服务质量。
值得说明的是，本申请实施例中，如果服务器基于上述订单处理的方法判定乘客不符合订单取消条件，即使接收到服务请求端触发的关单指示信息，也不执行目标订单的取消操作。这时，可以通知乘客，无法自动进行订单取消，可以联系客服取消订单(如图9所示)，从而确保乘客对订单的取消操作。
实施例二
参照图10所示，为本申请实施例二提供的一种订单处理的方法的流程示意图，该方法可以由服务系统中的服务请求端来执行，具体执行过程为：
S1001、接收服务器推送的是否取消订单的提示信息；
S1002、将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
这里，本申请实施例中的服务请求端可以基于服务器推送的是否取消订单的提示信息，触发关单指示信息，从而便于服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
其中，有关关单指示信息的触发过程、以及有关服务器执行目标订单的取消操作的具体过程，具体可参见实施例一中的相关内容，在此不再赘述。
本申请实施例中的服务请求端还可以接收服务器推送的是否再次下单的提示信息，并将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
其中，有关生成新的订单的具体过程，具体也可参见实施例一中的相关内容，在此不再赘述。
实施例三
基于同一发明构思，本申请实施例中还提供了与订单处理的方法对应的订单处理的装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述订单处理的方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
参照图11所示，为本申请实施例三提供的一种订单处理的装置的示意图，所述装置包括：
数据获取模块1101，用于在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
条件检测模块1102，用于根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
订单取消模块1103，用于若符合所述订单取消条件，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。
在一种实施方式中，所述条件检测模块1102，还用于：
在检测所述目标订单对应的服务请求端是否符合订单取消条件之前，接收所述服务请求端触发的关单指示信息。
在一种实施方式中，所述订单取消模块1103，还用于：
检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，向所述服务请求端推送是否取消订单的提示信息；
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
在一种实施方式中，所述数据获取模块1101，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块1101，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据；
和/或，
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块1101，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块1101，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述数据获取模块1101，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述服务特征数据包括所述目标订单对应的服务提供端的当前轨迹点位置信息、以及所述目标订单对应的服务请求端的当前轨迹点位置信息，所述条件检测模块1102，用于按照如下步骤检测所述目标订单对应的服务请求端是否符合订单取消条件：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，确定所述目标订单对应的服务请求端符合订单取消条件。
在一种实施方式中，所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述条件检测模块1102，用于按照如下步骤检测所述目标订单对应的服务请求端是否符合订单取消条件：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
在一种实施方式中，所述装置还包括：
订单生成模块1104，用于基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
在一种实施方式中，所述订单取消模块1103，用于按照如下步骤取消所述目标订单：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
参照图12所示，为本申请实施例三提供的另一种订单处理的装置的示意图，所述装置包括：
信息接收模块1201，用于接收服务器推送的是否取消订单的提示信息；
信息发送模块1202，用于将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
在一种实施方式中，所述装置还包括：
下单提示模块1203，用于接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
实施例四
本申请实施例四提供了一种电子设备，该电子设备可以是服务器，还可以是服务请求端，在服务器作为电子设备时，如图13所示为本申请实施例提供的一种电子设备的结构示意图，该电子设备可以包括：处理器1301、存储介质1302、和总线1303。所述存储介质1302存储有所述处理器1301可执行的机器可读指令(比如，图11中的订单处理的装置中数据获取模块1101、条件检测模块1102、以及订单取消模块1103对应的执行指令)，当电子设备运行时，所述处理器1301与所述存储介质1302之间通过总线1303通信，所述机器可读指令被所述处理器1301执行时执行如上述实施例一所述的订单处理的方法的如下指令：
在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
若是，则基于所述服务请求端触发的关单指示信息，取消所述目标订单。
在一种实施方式中，检测所述目标订单对应的服务请求端是否符合订单取消条件之前，上述处理器1301执行的指令还包括：
接收所述服务请求端触发的关单指示信息。
在一种实施方式中，检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，上述处理器1301执行的指令还包括：
向所述服务请求端推送是否取消订单的提示信息；
上述处理器1301执行的指令中，基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
在一种实施方式中，上述处理器1301执行的指令中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
在一种实施方式中，上述处理器1301执行的指令中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据；
和/或，
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
在一种实施方式中，上述处理器1301执行的指令中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
在一种实施方式中，上述处理器1301执行的指令中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，上述处理器1301执行的指令中，可以按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
在一种实施方式中，所述服务特征数据包括所述目标订单对应的服务提供端的当前轨迹点位置信息、以及所述目标订单对应的服务请求端的当前轨迹点位置信息，上述处理器1301执行的指令中，所述根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，确定所述目标订单对应的服务请求端符合订单取消条件。
在一种实施方式中，所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，上述处理器1301执行的指令中，所述根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
在一种实施方式中，基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，上述处理器1301执行的指令还包括：
向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
在一种实施方式中，上述处理器1301执行的指令中，基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
在服务请求端作为电子设备时，如图14所示为本申请实施例提供的另一种电子设备的结构示意图，该电子设备可以包括：处理器1401、存储介质1402、和总线1403。所述存储介质1402存储有所述处理器1401可执行的机器可读指令(比如，图12中的订单处理的装置中信息接收模块1201、以及信息发送模块1202对应的执行指令)，当电子设备运行时，所述处理器1401与所述存储介质1402之间通过总线1403通信，所述机器可读指令被所述处理器1401执行时执行如上述实施例一所述的订单处理的方法的如下指令：
接收服务器推送的是否取消订单的提示信息；
将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器在检测到目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单。
在一种实施方式中，上述处理器1401执行的指令还包括：
接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器1301运行时执行上述实施例一所述的订单处理的方法步骤，以及被处理器1401运行时执行上述实施例二所述的订单处理的方法步骤。
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述订单处理的方法，能够结合乘客触发的关单指示以及订单取消条件的判断结果，实现订单的自动取消，省时省力。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (28)

1.一种订单处理的方法，其特征在于，所述方法包括：
在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
若是，则基于所述服务请求端触发的关单指示信息，取消所述目标订单；
所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
2.根据权利要求1所述的方法，其特征在于，检测所述目标订单对应的服务请求端是否符合订单取消条件之前，还包括：
接收所述服务请求端触发的关单指示信息。
3.根据权利要求1所述的方法，其特征在于，检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，还包括：
向所述服务请求端推送是否取消订单的提示信息；
基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
4.根据权利要求2或3所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
5.根据权利要求2或3所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据。
6.根据权利要求2或3所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
7.根据权利要求2或3所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
8.根据权利要求2或3所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
9.根据权利要求2所述的方法，其特征在于，按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
10.根据权利要求1所述的方法，其特征在于，基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，还包括：
向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
11.根据权利要求1所述的方法，其特征在于，基于所述服务请求端触发的关单指示信息，取消所述目标订单，包括：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
12.一种订单处理的方法，其特征在于，所述方法包括：
接收服务器推送的是否取消订单的提示信息；
将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器根据目标订单对应的服务特征数据，在检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单；
所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述服务器根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
13.根据权利要求12所述的方法，其特征在于，所述方法还包括：
接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
14.一种订单处理的装置，其特征在于，所述装置包括：
数据获取模块，用于在确定目标订单对应的行程开启之后，获取与所述目标订单对应的服务特征数据；
条件检测模块，用于根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件；
订单取消模块，用于若符合所述订单取消条件，则基于所述服务请求端触发的关单指示信息，取消所述目标订单；
所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述条件检测模块，用于按照如下步骤检测所述目标订单对应的服务请求端是否符合订单取消条件：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
15.根据权利要求14所述的装置，其特征在于，所述条件检测模块，还用于：
在检测所述目标订单对应的服务请求端是否符合订单取消条件之前，接收所述服务请求端触发的关单指示信息。
16.根据权利要求14所述的装置，其特征在于，所述订单取消模块，还用于：
检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述服务请求端触发的关单指示信息，取消所述目标订单之前，向所述服务请求端推送是否取消订单的提示信息；
接收所述服务请求端基于所述提示信息触发的关单指示信息，并基于关单指示信息，取消所述目标订单。
17.根据权利要求15或16所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
从所述目标订单中提取订单属性数据；
将提取的订单属性数据确定为一种服务特征数据。
18.根据权利要求15或16所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务提供端，从各个历史订单中确定与该服务提供端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务提供端的服务评分数据；
将所述服务评分数据确定为一种服务特征数据。
19.根据权利要求15或16所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
针对与所述目标订单对应的服务请求端，从各个历史订单中确定与该服务请求端对应的历史订单；
通过对确定出的所述历史订单进行统计分析，得到所述服务请求端的乘车信用数据；
将所述乘车信用数据确定为一种服务特征数据。
20.根据权利要求15或16所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端与服务请求端之间的乘车记录信息；
将获取的所述乘车记录信息，确定为一种服务特征数据。
21.根据权利要求15或16所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
获取与所述目标订单对应的服务提供端的轨迹点位置信息；以及与所述目标订单对应的服务请求端的轨迹点位置信息；
将获取的所述服务提供端的轨迹点位置信息和所述服务请求端的轨迹点位置信息，确定为一种服务特征数据。
22.根据权利要求15所述的装置，其特征在于，所述数据获取模块，用于按照如下步骤确定与所述目标订单对应的服务特征数据：
在接收到所述服务请求端触发的关单指示信息时，接收所述服务请求端上报的轨迹点位置信息；
将上报的所述轨迹点位置信息，确定为一种服务特征数据。
23.根据权利要求14所述的装置，其特征在于，所述装置还包括：
订单生成模块，用于基于所述服务请求端触发的关单指示信息，取消所述目标订单之后，向所述服务请求端推送是否再次下单的提示信息；
接收所述服务请求端基于所述提示信息触发的下单指示信息；
基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
24.根据权利要求14所述的装置，其特征在于，所述订单取消模块，用于按照如下步骤取消所述目标订单：
基于所述服务请求端触发的关单指示信息以及该服务请求端在最近预设时长内触发的历史关单指示信息的个数，取消所述目标订单。
25.一种订单处理的装置，其特征在于，所述装置包括：
信息接收模块，用于接收服务器推送的是否取消订单的提示信息；
信息发送模块，用于将基于所述提示信息触发的关单指示信息发送给所述服务器，以使所述服务器根据目标订单对应的服务特征数据，在检测到所述目标订单对应的服务请求端符合订单取消条件之后，基于所述关单指示信息，取消所述目标订单；
所述服务特征数据包括订单属性数据、所述目标订单对应的服务提供端的当前轨迹点位置信息和服务评分数据、所述目标订单对应的服务请求端的当前轨迹点位置信息和乘车信用数据、以及所述服务提供端与所述服务请求端之间的乘车记录信息，所述服务器根据所述服务特征数据，检测所述目标订单对应的服务请求端是否符合订单取消条件，包括：
基于所述服务提供端的当前轨迹点位置信息、以及所述服务请求端的当前轨迹点位置信息，确定所述服务提供端与所述服务请求端之间的距离信息；
在确定出所述距离信息大于预设距离阈值时，根据所述服务提供端与所述服务请求端之间的乘车记录信息，确定所述服务请求端是否初步符合订单取消条件；
若是，则基于所述服务提供端的服务评分数据与所述服务请求端的乘车信用数据，确定所述服务请求端相对所述服务提供端的评价差值；
若所述评价差值大于预设评价值，则确定所述订单属性数据包括的接驾时长是否小于预设时长阈值；
若是，则确定所述服务请求端符合订单取消条件。
26.根据权利要求25所述的装置，其特征在于，所述装置还包括：
下单提示模块，用于接收服务器推送的是否再次下单的提示信息；
将基于所述提示信息触发的下单指示信息发送给所述服务器，以使所述服务器基于所述下单指示信息，生成新的订单，并将该新的订单的派单时间置于其它订单的派单时间之前。
27.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至13任一所述订单处理的方法的步骤。
28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至13任一所述订单处理的方法的步骤。
CN201911222028.9A 2019-12-03 2019-12-03 一种订单处理的方法、装置、电子设备及存储介质 Active CN111028053B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911222028.9A CN111028053B (zh) 2019-12-03 2019-12-03 一种订单处理的方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911222028.9A CN111028053B (zh) 2019-12-03 2019-12-03 一种订单处理的方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN111028053A CN111028053A (zh) 2020-04-17
CN111028053B true CN111028053B (zh) 2020-12-01

Family

ID=70207853

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911222028.9A Active CN111028053B (zh) 2019-12-03 2019-12-03 一种订单处理的方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN111028053B (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10395333B2 (en) * 2016-06-07 2019-08-27 Uber Technologies, Inc. Hierarchical selection process
KR20180024591A (ko) * 2016-08-30 2018-03-08 김성준 주문형 운수 서비스 제공 방법 및 서버
CN108009650A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器
CN109409970A (zh) * 2017-05-09 2019-03-01 北京嘀嘀无限科技发展有限公司 异常订单处理系统及方法
CN108805660A (zh) * 2018-05-24 2018-11-13 北京三快在线科技有限公司 订单处理方法、装置及服务器
CN110033346A (zh) * 2019-03-20 2019-07-19 北京三快在线科技有限公司 一种提示取消订单的方法及装置、电子设备

Also Published As

Publication number Publication date
CN111028053A (zh) 2020-04-17

Similar Documents

Publication Publication Date Title
US11386359B2 (en) Systems and methods for managing a vehicle sharing facility
US11392861B2 (en) Systems and methods for managing a vehicle sharing facility
US20190376804A1 (en) Providing Alternative Routing Options To A Rider Of A Transportation Management System
CN111325374B (zh) 一种订单取消概率的预测方法、装置和电子设备
EP3262831B1 (en) Telephone call placement
CN111324824B (zh) 一种目的地推荐方法、其装置、电子设备及可读存储介质
US11132626B2 (en) Systems and methods for vehicle resource management
CN111832788B (zh) 一种服务信息生成的方法、装置、计算机设备及存储介质
CN110782301A (zh) 一种拼单方法、装置、电子设备及计算机可读存储介质
CN111932428B (zh) 乘车服务方法、装置、设备及存储介质
CN111080048A (zh) 预约打车订单的派单方法、装置、电子设备及储存介质
CN111861081A (zh) 一种订单分配方法、装置、电子设备及存储介质
CN111861624A (zh) 一种车辆的推荐方法、装置、电子设备及可读存储介质
CN111831967A (zh) 一种到店识别方法、装置、电子设备及介质
CN111859176B (zh) 一种信息推荐方法、装置、电子设备及存储介质
CN111651687B (zh) 上车点信息推送方法及装置、下车点信息推送方法及装置
CN111028053B (zh) 一种订单处理的方法、装置、电子设备及存储介质
CN111768254A (zh) 一种订单处理方法及装置
CN112001516B (zh) 一种信息处理方法、装置、电子设备及存储介质
CN110751304A (zh) 一种服务提供端的信息交互同步方法以及装置
CN110718087B (zh) 数据融合处理方法及装置
CN111915043A (zh) 服务数据处理方法、装置、服务器及存储介质
CN112465331A (zh) 乘车安全控制方法、模型训练方法、装置、设备及介质
CN111369311A (zh) 一种在用户端发起订单的控制方法及装置
CN111652666B (zh) 一种出行订单处理方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant