CN110930081A - 订单配送信息处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例公开了订单配送信息处理方法、装置及电子设备，该方法包括：客户端接收将目标订单的订单状态修改为已妥投的操作请求；判断是否需要对该目标订单的妥投情况进行核实；如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。通过本申请实施例，可以更有效地判断是否存在虚拟妥投，降低对定位功能的依赖。

Description

订单配送信息处理方法、装置及电子设备

技术领域

本申请涉及配送信息处理技术领域，特别是涉及订单配送信息处理方法、装置及电子设备。

背景技术

随着“新零售”等服务模式的发展，以及相关技术水平的不断提升，商家能够在更短的时间内完成配送任务。例如，对于一些新零售的门店而言，甚至可以向用户承诺半小时送达的配送时效，使得用户能够更早的收到所定的货品。但是，为了实现这种对配送时效的承诺，对配送员也提出了更高的要求，一般要求其需要在规定的时效内配送到用户指定的地址。

为了使得系统能够获知具体订单是否被按时履约，还需要配送员在完成配送后，向系统提交妥投通知(所谓妥投，也即投递部门将邮件配送到指定的地址，并由收件人或合法代收人按照规定手续签收无误)，系统可以据此更新订单的状态，同时，也可以以此为依据判断配送员是否按时妥投，如果没有按时妥投，可能会对配送员进行一定的处罚。

但是，在实际应用中，有些配送员可能由于某些原因，无法在规定的时效内完成对某订单的配送，而为了逃避处罚，可能会在未真正送到收货地址时，提前在系统中提交妥投通知，以此“欺骗”系统，这种情况称为“虚假妥投”。显然，由于在系统接收到妥投通知的时刻，消费者用户并未真正收到货品，但却可能收到系统发送的订单已完成的通知，因此，可能会引起消费者用户反感，甚至可能会向系统进行投诉。

为了避免配送员进行虚拟妥投，现有技术中的方案是，在配送员点击“妥投”时，同时将配送员实时的经纬度等地理位置信息上传到系统，这样，系统服务端可以根据配送员实时位置与顾客配送地址是否匹配，判断是不是虚假妥投。这种方案可以从一定程度上避免虚拟妥投，但是其缺点在于：此方案严重依赖配送员手机等终端设备的定位功能，但是，如果配送地址是用户家中，楼道里可能存在信号比较差的情况，使得配送员手机定位不准确，此时，将无法判断是不是虚假妥投，或者，产生错误的判断结果，等等。

因此，如何更有效地判断是否存在虚拟妥投，降低对定位功能的依赖，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了订单配送信息处理方法、装置及电子设备，可以更有效地判断是否存在虚拟妥投，降低对定位功能的依赖。

本申请提供了如下方案：

一种订单配送信息处理方法，包括：

客户端接收将目标订单的订单状态修改为已妥投的操作请求；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

一种订单配送信息处理方法，包括：

服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

一种订单配送信息处理方法，包括：

客户端接收将目标订单的订单状态修改为已妥投的操作请求；

将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

一种订单配送信息处理方法，包括：

服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

一种订单配送信息处理装置，应用于客户端，包括：

操作请求接收单元，用于接收将目标订单的订单状态修改为已妥投的操作请求；

判断单元，用于判断是否需要对该目标订单的妥投情况进行核实；

证据信息接收单元，用于如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

一种订单配送信息处理装置，应用于服务器，包括：

操作请求接收单元，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

状态修改单元，用于将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

一种订单配送信息处理装置，应用于客户端，包括：

操作请求接收单元，用于接收将目标订单的订单状态修改为已妥投的操作请求；

提交单元，用于将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

响应消息接收单元，用于接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

一种订单配送信息处理装置，应用于服务器，包括：

操作请求接收单元，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

判断单元，用于判断是否需要对该目标订单的妥投情况进行核实；

通知单元，用于如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收将目标订单的订单状态修改为已妥投的操作请求；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，在接收到将某目标订单的状态修改为已妥投的操作请求后，并不是直接将该请求提交到服务器，而是首先确定是否需要对该目标清单的妥投情况进行核实，如果需要，则会将具体的操作界面置为不可退出状态，并提供相应的操作选项，供配送执行者进行相关妥投证据信息的提交。通过这种抽查的方式，可以更有效地判断是否存在虚拟妥投，降低对定位功能的依赖。

另外，在优选的实施方式中，可以结合配送执行者所在的地理位置与目标订单关联的收货地址信息是否一致这一信息，来确定是否需要对该目标清单的妥投情况进行核实。这样，可以更有效地防止虚假妥投的情况发生，同时，也可以提高判断的准确度，避免由于定位不准等原因导致的误判等情况发生。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的客户端界面的示意图；

图4是本申请实施例提供的工单信息的示意图；

图5是本申请实施例提供的第二方法的流程图；

图6是本申请实施例提供的第三方法的流程图；

图7是本申请实施例提供的第四方法的流程图；

图8是本申请实施例提供的第一装置的示意图；

图9是本申请实施例提供的第二装置的示意图；

图10是本申请实施例提供的第三装置的示意图；

图11是本申请实施例提供的第四装置的示意图；

图12是本申请实施例提供的电子设备的示意图。

具体实施方式

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

在本申请实施例中，为了降低“虚假妥投”的发生率，同时降低对实时定位信息的依赖，提供了相应的解决方案。在该方案中，服务器在接收到配送终端提交的针对某订单已完成妥善投放的消息后，可以首先确定是否需要提交妥投证据信息，以证明其确实是在将具体的货品送达收件人指定的收货地址处，而不是为了避免受到处罚而进行虚假妥投。如果需要，则可以要求配送执行者提交妥投证据信息，之后，还可以生成具体的工单，由相关的管理员等用户进行核实。也就是说，在本申请实施例中，实现了一种基于抽查的、用于防止配送执行者虚假妥投的方案，之所以采用抽查的方式，是因为配送执行者在采集并提交妥投证据信息的过程中，可能会占用一些时间，如果采用每单必查的方案，则可能会造成整体上的时效延误。另外，虚假妥投通常只会在少数情况下发生，为了查处这种少数发生的情况，而要求全部订单都提交证据以证明其没有虚假妥投，显然也是不合理的。总之，本申请实施例中，采用抽查的方式，对订单的妥投真实性进行核查，以此来降低虚假妥投的发生概率。

其中，为了实现上述抽查式的方案，可以预先制定一定的抽查策略。所谓的抽查策略具体用于，在收到具体关于某订单的已妥投的通知消息后，利用该抽查策略，确定出是否需要对应的配送执行者提交相应的证据，以证明其没有虚假妥投。在其中一种实现方式下，可以根据配送者在提交已妥投的通知消息时所处的位置，与对应订单中关联的收货地址的位置进行比对，如果两者一致，则可以根据一些信息进一步判断出该订单被虚假妥投的概率，并根据一定的算法，计算出是否需要对其进行进一步的核查。而如果两者不一致，则主要可能是有两种原因导致的，其一，是配送执行者在配送过程中发现无法按时送达，于是在尚未到达指定的收货地址时，就提前点击了“已妥投”，企图以此逃避处罚。其二，是配送执行者确实将货品送到了指定的收货地址，并由收件人或指定合法人签收，但是，在其点击“已妥投”时，终端设备的定位出现了不准的情况，使得终端设备感知到的位置信息，与配送执行者实际所在的位置之间存在偏差，进而导致前述判断结果为不一致。总之，当终端设备感知到的位置信息与订单中的收货地址之间存在不一致的情况时，该订单可能是虚假妥投，也可能没有虚假妥投，只是由于定位不准导致的误判，但总之，都需要通过进一步的核查来进行确定。此时，可以通过客户端提示配送执行者，如果其想要继续当前操作(也即，确实要将订单的状态修改为已妥投)，则需要提交一定的妥投证据信息。这样，对于前述第一种情况，配送执行者在明知道自己无法提交有效证据的情况下，可以放弃当前操作，也即，无法继续将对应的订单修改为已妥投状态，相应的，在后续真正完成妥投时，如果确实超出了时限，则会被系统记录，该配送执行者将会无法逃避处罚；而如果其执意要继续修改订单状态，但是因为无法提供有效的证据(因为其并不在收货地址所在的位置，无法对门牌号等进行拍照)，则也会在核查的过程中被发现，同样无法逃避处罚。而对于第二种情况，由于只是由于终端设备定位不准导致的判断结果不一致，因此，配送执行者只需要点击“继续”，并提交相应的妥投证据信息，便可以证明其确实是在完成妥投之后才进行了订单状态的修改，此时，经过核查之后，也不会对该配送执行者进行处罚。可见，通过本申请实施例提供的方案，可以更有效地防止虚假妥投的情况发生，另外，也可以提高判断的准确度，避免由于定位不准等原因导致的误判等情况发生。

其中，所述妥投证据信息可以有多种，例如，一种方式下可以是照片等图像数据，例如，在配送员等配送执行者在执行配送的过程中，如果通过配送终端(可以是专用的配送终端设备，也可以是安装有预置的客户端程序的手机等通用性终端设备)将其正在配送的订单的状态修改为已妥善投放，而服务器端确定出需要对该订单的是否真正被妥善投放进行抽查，则可以通过客户端要求配送提供者对其所在位置处的门牌号、小区门口等进行拍照，并将照片等数据提交到服务器。

具体实现时，从系统架构角度而言，参见图1，可以包括客户端以及服务器端两部分，其中，客户端主要是提供给配送执行者使用的客户端，具体可以是安装在手机等终端设备中的应用程序，或者，也可以是固化在专用的终端设备中，等等。而服务器端则可以是用于对订单配送状态等信息进行统一管理的程序，该程序通常运行在云端设备中。在本申请实施例中，关于是否需要进行核实的判断操作，可以由客户端来完成，也可以由服务器来完成，下面分别对各种情况下的具体实现方案进行详细介绍。

实施例一

在该实施例一中，具体可以是由客户端来完成具体的判断过程，服务器只需要接收具体的订单状态修改结果，以及关联的证据信息，并进行订单状态的实际修改等操作即可。具体的，参见图2，该实施例一首先从客户端的角度，提供了一种订单配送信息处理方法，该方法具体可以包括：

S201：客户端接收将目标订单的订单状态修改为已妥投的操作请求；

具体的，配送执行者的客户端中可以在具体的界面中展示具体的配送任务信息，其中，每条配送任务中可以关联一个具体的订单，在领取任务并执行的过程中，可以通过客户端提供的操作界面对具体任务中的订单状态进行修改，以将订单状态同步到服务器端，还可以进一步由服务器同步给具体的消费者用户，等等。其中，对订单状态进行修改的过程中，就包括本申请实施例中的将订单状态修改为已妥投的操作。

S202：判断是否需要对该目标订单的妥投情况进行核实；

在传统方式下，配送执行者在通过客户端将某订单的状态进行了修改之后，客户端直接将修改后的状态信息提交到服务器端即可，而在本申请实施例中，客户端在接收到将目标订单的订单状态修改为已妥投的操作请求后，还可以首先判断是否需要对该目标订单的妥投情况进行核实，如果需要核实，还需要配送执行者提交相关的妥投证据信息之后，才会将具体的修改请求提交到服务器端，执行正式的状态修改操作。

其中，具体在判断是否需要对该目标订单的妥投情况进行核实时，可以有多种方式，例如，在一种方式下，可以直接按照固定的比例进行抽查。例如，抽查比例为10％，则可以每隔十个订单抽查一次，等等。或者，另一种方式下，还可以获得与虚假妥投相关的信息，然后根据所获得的信息确定是否需要对该目标订单的妥投情况进行核实。

其中，具体与与虚假妥投相关的信息也可以有多种，例如，可以包括位置信息、配送执行者或配送站的历史妥投记录，等等。其中一种实现方式下，首先可以确定关联的终端设备当前所处的位置信息，然后，将该终端设备当前所处的位置信息与所述目标订单关联的收货地址进行比对，这样，至少可以根据比对结果确定是否需要对该目标订单的妥投情况进行核实。

具体的，如果比对结果一致，可以直接认为不存在虚假妥投的情况，并判定为不需要进行妥投核实。或者，另一种实现方式下，还可以进一步确定该目标订单被虚假妥投的概率，然后，根据所述概率以及预置的抽取算法，确定是否需要对该目标订单的投放情况进行核实。具体实现时，可以向服务器查询获得所述目标订单关联配送执行者所属的配送站信息，以及所述配送站的历史妥投比例；其中，所述历史妥投比例包括：所述配送站关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例，然后，根据所述配送站的历史妥投比例，确定该目标订单被虚假妥投的概率。也就是说，在判断出配送执行者当前所在的位置与当前目标订单关联的收货地址一致的情况下，还可以进一步根据具体配送站的历史妥投记录来确定其虚假妥投的概率。例如，如果某配送站的实际妥投率比较高，则当前目标订单被虚假妥投的概率会比较低，这样，针对该配送站的抽查比例就可以比较低；否则，如果某配送站的实际妥投率比较低，则对应的抽查比例则会比较高，等等。总之，可以以配送站为单位，对历史妥投记录进行统计，然后确定出各自对应的抽查比例，再根据抽查比例以及对应的算法，确定出是否需要对当前目标订单的妥投情况进行核实。

或者，除了以配送站为单位对历史妥投记录进行统计之外，还可以以具体的配送执行者为单位，对历史妥投记录进行统计，客户端则可以获得所述目标订单关联的配送执行者的历史妥投比例；这里的历史妥投比例包括：所述配送执行者关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例。然后，根据所述配送执行者的历史妥投比例，确定该目标订单被虚假妥投的概率，并进而根据预置的算法以及上述历史妥投比例，确定出是否需要对当前目标订单的妥投情况进行核实。这样，可以为不同的配送执行者设定个性化的抽查比例，历史妥投比例比较高的配送执行者，被抽查的比例会比较低，而历史妥投比例比较低的配送执行者，则被抽查的比例会比较高。

需要说明的是，无论是配送站还是具体配送执行者的历史妥投比例信息，通常都是由服务器进行统计并保存的，因此，在该实施例一中，客户端可以通过向服务器进行查询的方式，获得上述信息，并进而进行计算。

总之，在收到将目标订单状态修改为已妥投的操作请求时，如果配送执行者所在的位置与目标订单关联的收货地址一致，则可以根据具体目标订单被虚假妥投的概率，确定出是否需要进行进一步的核实。其中，这种被虚假妥投的概率，可以根据当前配送执行者的历史妥投记录，或者当前配送者所属配送站的历史妥投记录等确定。这样，可以实现对不同配送执行者或者不同配送站的个性化处理，实现按需抽查，避免大面积的广泛抽查造成的整体配送时效的延迟，等等。

而在配送执行者所在的位置与目标订单关联的收货地址不一致的情况下，如前文所述，要么是配送执行者确实试图进行虚假妥投，要么是终端设备定位不准，总之，这两种情况都需要进行进一步的核实。因此，对于这种情况，可以直接判定需要对该目标订单的妥投情况进行核实。

S203：如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

在判定了需要对目标订单的妥投情况进行核实的情况下，客户端可以将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。例如，在一种方式下，客户端展示出的界面状态可以如图3所示，可以在界面的上层弹出一对话框，其中可以提示“请在2分钟内上传妥投照片，照片未上传将按虚假妥投处理”。也就是说，在确定需要核实后，配送执行者不能退出当前操作界面，无法继续对其他订单或者任务执行操作，只能按照要求提交证据信息之后才能继续。具体的，在将用于执行状态修改操作的界面置为不可退出状态后，还可以提供用于提交妥投证据信息的操作选项，例如，可以是用于拍照的按钮等，然后，配送执行者可以通过该操作选项提交具体的妥投证据信息。如图3中的例子所示，可以提供“去拍照”字样的按钮，作为用于提交证据信息的操作选项。该按钮被点击后，便可以启动终端设备上的相机组件，然后，配送执行者便可以对具体的门牌号、小区名称等进行拍照，以作为妥投的证据。当然，在终端设备当前所处的位置信息与所述目标订单关联的收货地址不一致的情况下，还可以提供是否继续对所述目标订单的状态进行修改操作的提示信息，在接收到继续操作的响应消息后，再将用于执行状态修改操作的界面置为不可退出状态，并且可以提供用于提交妥投证据信息的操作选项。

其中，在以图像数据为证据信息的情况下，客户端还可以为所述采集到的图像数据添加水印信息，所述水印信息包括时间和/或地点信息。这样可以避免配送执行者对提交的证据信息造假。

接收到妥投证据信息后，则可以将所述目标订单的信息以及所述妥投证据信息提交到服务器，由所述服务器则可以将目标订单的状态修改为已妥投，同时，还可以生成审核工单，并提供给对应的审核客户端。其中，审核客户端具体可以是指提供给管理员等用户使用的客户端，管理员用户可以通过其客户端接收到具体需要审核的工单，如图4所示，其中可以包括各个订单对应的收货地址信息、配送执行者信息、提交妥投消息的时间信息、妥投证据信息，等等，管理员用户可以通过人工审核等方式，对具体的妥投情况进行审核，确定具体的订单是否真的被按时妥投。具体的核查结果可以反馈给服务器，由服务器进行记录，以供后续的统计使用。另外，服务器还可以将核查结果通知给对应的配送执行者用户，等等。

总之，通过本申请实施例，在接收到将某目标订单的状态修改为已妥投的操作请求后，并不是直接将该请求提交到服务器，而是首先确定是否需要对该目标清单的妥投情况进行核实，如果需要，则会将具体的操作界面置为不可退出状态，并提供相应的操作选项，供配送执行者进行相关妥投证据信息的提交。通过这种抽查的方式，可以更有效地判断是否存在虚拟妥投，降低对定位功能的依赖。

另外，在优选的实施方式中，可以结合配送执行者所在的地理位置与目标订单关联的收货地址信息是否一致这一信息，来确定是否需要对该目标清单的妥投情况进行核实。这样，可以更有效地防止虚假妥投的情况发生，同时，也可以提高判断的准确度，避免由于定位不准等原因导致的误判等情况发生。

实施例二

该实施例二是与实施例一对应的，从服务器的角度，提供了一种订单配送信息处理方法，参见图5，该方法具体可以包括：

S501：服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

S502：将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

实施例三

在该实施例三中，可以由服务器来执行具体的判断操作，也即，客户端在接收到将订单提交的状态修改为已妥投之后，可以直接提交给服务器，由服务器判断是否需要针对该目标订单进行妥投情况核实，然后，客户端再进入到等待接收证据信息的状态，进行证据信息的接收以及提交。具体的，该实施例三首先从客户端的角度，提供了一种订单配送信息处理方法，参见图6，该方法具体可以包括：

S601：客户端接收将目标订单的订单状态修改为已妥投的操作请求；

S602：将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

S603：接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

其中，由于该实施例三与实施例一的区别仅在于判断操作的执行主体不同，而具体的判断方法，以及具体判断时所依据的参考信息，都可以是与实施例一相同的，因此，具体的实施方式参见前述实施例一中的记载即可，这里不再赘述。

实施例四

该实施例四则是与实施例三相对应的，从服务器的角度，提供了一种订单配送信息处理方法，参见图7，该方法具体可以包括：

S701：服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

S702：判断是否需要对该目标订单的妥投情况进行核实；

S703：如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

在接收到所述客户端提交的妥投证据信息后，可以将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

需要说明的是，关于前述实施例二至实施例四中的未详述部分，请参见前述实施例一中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种订单配送信息处理装置，参见图8，该装置应用于客户端，包括：

操作请求接收单元801，用于接收将目标订单的订单状态修改为已妥投的操作请求；

判断单元802，用于判断是否需要对该目标订单的妥投情况进行核实；

证据信息接收单元803，用于如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

具体实现时，所述判断单元具体可以包括：

信息获得子单元，用于获得与虚假妥投相关的信息；

判断子单元，用于根据所获得的信息确定是否需要对该目标订单的妥投情况进行核实。

其中，所述信息获得子单元具体可以用于，确定关联的终端设备当前所处的位置信息；

此时，所述判断子单元具体可以用于，将该终端设备当前所处的位置信息与所述目标订单关联的收货地址进行比对，至少根据比对结果确定是否需要对该目标订单的妥投情况进行核实。

更为具体的，判断子单元具体可以包括：

概率确定子单元，用于如果比对结果一致，则确定该目标订单被虚假妥投的概率；

计算子单元，用于根据所述概率以及预置的抽取算法，确定是否需要对该目标订单的投放情况进行核实。

其中，所述概率确定子单元具体可以用于，向服务器查询获得所述目标订单关联配送执行者所属的配送站信息，以及所述配送站的历史妥投比例；所述历史妥投比例包括：所述配送站关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例；根据所述配送站的历史妥投比例，确定该目标订单被虚假妥投的概率。

或者，所述概率确定子单元具体可以用于，向服务器查询获得所述目标订单关联的配送执行者的历史妥投比例；所述历史妥投比例包括：所述配送执行者关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例；根据所述配送执行者的历史妥投比例，确定该目标订单被虚假妥投的概率。

另一种情况下，所述判断子单元具体可以用于，如果比对结果不一致，则确定需要对该目标订单的妥投情况进行核实。

另外，具体实现时，该装置还可以包括：

提示单元，用于如果比对结果不一致，则提供是否继续对所述目标订单的状态进行修改操作的提示信息，在接收到继续操作的响应消息后，触发将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

另外，该装置还可以包括：

信息提交单元，用于接收到妥投证据信息后，将所述目标订单的信息以及所述妥投证据信息提交到服务器，由所述服务器生成审核工单，并提供给对应的审核客户端。

其中，所述妥投证据信息包括对关联配送执行者所在地进行拍照得到的图像数据。

为了保证提交的证据信息的真实性，该装置还可以包括：

水印添加单元，用于为所述采集到的图像数据添加水印信息，所述水印信息包括时间和/或地点信息。

与实施例二相对应，本申请实施例还提供了一种订单配送信息处理装置，参见图9，该装置应用于服务器，包括：

操作请求接收单元901，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

状态修改单元902，用于将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

与实施例三相对应，本申请实施例还提供了一种订单配送信息处理装置，参见图10，该装置应用于客户端，包括：

操作请求接收单元1001，用于接收将目标订单的订单状态修改为已妥投的操作请求；

提交单元1002，用于将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

响应消息接收单元1003，用于接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

与实施例四相对应，本申请实施例还提供了一种订单配送信息处理装置，参见图11，该装置应用于服务器，包括：

操作请求接收单元1101，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

判断单元1102，用于判断是否需要对该目标订单的妥投情况进行核实；

通知单元1103，用于如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

具体实现时，该装置还可以包括：

订单状态修改单元，用于在接收到所述客户端提交的妥投证据信息后，将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收将目标订单的订单状态修改为已妥投的操作请求；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

其中，图12示例性的展示出了电子设备的架构，例如，设备1200可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图12，设备1200可以包括以下一个或多个组件：处理组件1202，存储器1204，电源组件1206，多媒体组件1208，音频组件1210，输入/输出(I/O)的接口1212，传感器组件1214，以及通信组件1216。

处理组件1202通常控制设备1200的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1202可以包括一个或多个处理器1220来执行指令，以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件的全部或部分步骤。此外，处理组件1202可以包括一个或多个模块，便于处理组件1202和其他组件之间的交互。例如，处理部件1202可以包括多媒体模块，以方便多媒体组件1208和处理组件1202之间的交互。

存储器1204被配置为存储各种类型的数据以支持在设备1200的操作。这些数据的示例包括用于在设备1200上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1204可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1206为设备1200的各种组件提供电力。电源组件1206可以包括电源管理系统，一个或多个电源，及其他与为设备1200生成、管理和分配电力相关联的组件。

多媒体组件1208包括在设备1200和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1208包括一个前置摄像头和/或后置摄像头。当设备1200处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1210被配置为输出和/或输入音频信号。例如，音频组件1210包括一个麦克风(MIC)，当设备1200处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1204或经由通信组件1216发送。在一些实施例中，音频组件1210还包括一个扬声器，用于输出音频信号。

I/O接口1212为处理组件1202和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1214包括一个或多个传感器，用于为设备1200提供各个方面的状态评估。例如，传感器组件1214可以检测到设备1200的打开/关闭状态，组件的相对定位，例如所述组件为设备1200的显示器和小键盘，传感器组件1214还可以检测设备1200或设备1200一个组件的位置改变，用户与设备1200接触的存在或不存在，设备1200方位或加速/减速和设备1200的温度变化。传感器组件1214可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1214还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1214还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1216被配置为便于设备1200和其他设备之间有线或无线方式的通信。设备1200可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信部件1216经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1216还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1200可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1204，上述指令可由设备1200的处理器1220执行以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的订单配送信息处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

1.一种订单配送信息处理方法，其特征在于，包括：

客户端接收将目标订单的订单状态修改为已妥投的操作请求；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

2.根据权利要求1所述的方法，其特征在于，

所述判断是否需要对该目标订单的妥投情况进行核实，包括：

获得与虚假妥投相关的信息；

根据所获得的信息确定是否需要对该目标订单的妥投情况进行核实。

3.根据权利要求2所述的方法，其特征在于，

所述获得与虚假妥投相关的信息，包括：

确定关联的终端设备当前所处的位置信息；

所述根据所获得的信息确定是否需要对该目标订单的妥投情况进行核实，包括：

将该终端设备当前所处的位置信息与所述目标订单关联的收货地址进行比对，至少根据比对结果确定是否需要对该目标订单的妥投情况进行核实。

4.根据权利要求3所述的方法，其特征在于，

所述至少根据比对结果确定是否需要对该目标订单的妥投情况进行核实，包括：

如果比对结果一致，则确定该目标订单被虚假妥投的概率；

根据所述概率以及预置的抽取算法，确定是否需要对该目标订单的投放情况进行核实。

5.根据权利要求4所述的方法，其特征在于，

所述确定该目标订单被虚假妥投的概率，包括：

向服务器查询获得所述目标订单关联配送执行者所属的配送站信息，以及所述配送站的历史妥投比例；所述历史妥投比例包括：所述配送站关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例；

根据所述配送站的历史妥投比例，确定该目标订单被虚假妥投的概率。

6.根据权利要求4所述的方法，其特征在于

所述确定该目标订单被虚假妥投的概率，包括：

向服务器查询获得所述目标订单关联的配送执行者的历史妥投比例；所述历史妥投比例包括：所述配送执行者关联的历史订单中，实际被妥投的订单在全部历史订单中所占的比例；

根据所述配送执行者的历史妥投比例，确定该目标订单被虚假妥投的概率。

7.根据权利要求3所述的方法，其特征在于，

所述至少根据比对结果确定是否需要对该目标订单的妥投情况进行核实，包括：

如果比对结果不一致，则确定需要对该目标订单的妥投情况进行核实。

8.根据权利要求7所述的方法，其特征在于，还包括：

如果比对结果不一致，则提供是否继续对所述目标订单的状态进行修改操作的提示信息，在接收到继续操作的响应消息后，触发将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

9.根据权利要求1至8任一项所述的方法，其特征在于，还包括：

通过所述操作选项接收到妥投证据信息后，将所述目标订单的信息以及所述妥投证据信息提交到服务器，由所述服务器生成审核工单，并提供给对应的审核客户端。

10.根据权利要求1至8任一项所述的方法，其特征在于，

所述妥投证据信息包括对关联配送执行者所在地进行拍照得到的图像数据。

11.根据权利要求10所述的方法，其特征在于，还包括：

为所述采集到的图像数据添加水印信息，所述水印信息包括时间和/或地点信息。

12.一种订单配送信息处理方法，其特征在于，包括：

服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

13.一种订单配送信息处理方法，其特征在于，包括：

客户端接收将目标订单的订单状态修改为已妥投的操作请求；

将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

14.一种订单配送信息处理方法，其特征在于，包括：

服务器接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

15.根据权利要求14所述的方法，其特征在于，还包括：

在接收到所述客户端提交的妥投证据信息后，将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

16.一种订单配送信息处理装置，其特征在于，应用于客户端，包括：

操作请求接收单元，用于接收将目标订单的订单状态修改为已妥投的操作请求；

判断单元，用于判断是否需要对该目标订单的妥投情况进行核实；

证据信息接收单元，用于如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

17.一种订单配送信息处理装置，其特征在于，应用于服务器，包括：

操作请求接收单元，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求，所述操作请求中携带有妥投证据信息；

状态修改单元，用于将所述目标订单的订单状态修改为已妥投，并根据所述目标订单的信息以及所述妥投证据信息生成核查工单，并提供给核查客户端。

18.一种订单配送信息处理装置，其特征在于，应用于客户端，包括：

操作请求接收单元，用于接收将目标订单的订单状态修改为已妥投的操作请求；

提交单元，用于将该操作请求信息提交到服务器，由所述服务器判断是否需要对该目标订单的妥投情况进行核实；

响应消息接收单元，用于接收到所述服务器返回的需要核实的消息后，将当前界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

19.一种订单配送信息处理装置，其特征在于，应用于服务器，包括：

操作请求接收单元，用于接收客户端提交的将目标订单的订单状态修改为已妥投的操作请求信息；

判断单元，用于判断是否需要对该目标订单的妥投情况进行核实；

通知单元，用于如果需要，则通知所述客户端将用于执行状态修改操作的界面置为不可退出状态，并接收妥投证据信息。

20.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收将目标订单的订单状态修改为已妥投的操作请求；

判断是否需要对该目标订单的妥投情况进行核实；

如果需要，则将用于执行状态修改操作的界面置为不可退出状态，并提供相应的操作选项，以用于接收妥投证据信息。

Images