订单处理方法、装置、计算机设备及存储介质与流程

1.本技术涉及计算机技术领域，特别涉及一种订单处理方法、装置、计算机设备及存储介质。


背景技术：

2.随着计算机技术的不断发展，即时配送业务已成为人们日常生活的重要组成部分。在即时配送业务中，用户可以通过即时配送的应用程序选择相应的物品进行下单，然后由商家准备该订单，订单准备好后由配送运力进行配送。
3.相关技术中，配送运力接收到订单的配送任务赶往商家店内时，商家可能还未准备好订单。这种情况下往往造成配送运力在商家店内等待订单准备完成，影响配送运力的配送业绩，导致配送运力的配送超时率高。


技术实现要素：

4.本技术实施例提供了一种订单处理方法、装置、计算机设备及存储介质,可以降低配送运力的配送超时率。该技术方案如下：
5.第一方面，提供了一种订单处理方法，所述方法由商家使用的第一终端执行，所述方法包括：
6.展示卡单处理界面，所述卡单处理界面包括多个卡单处理选项，所述卡单处理选项用于触发更改所述商家的运营信息，所述运营信息用于表示所述商家在互联网平台中接受订单的运营模式；
7.响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息；
8.基于所述至少一个运营信息，对订单进行处理。
9.第二方面，提供了一种订单处理方法，所述方法由服务器执行，所述方法包括：
10.接收第一终端发送的卡单处理请求，所述卡单处理请求携带被选择的至少一个卡单处理选项，所述至少一个卡单处理选项用于触发更改商家的运营信息，所述运营信息用于表示所述商家在互联网平台接受订单的运营模式，所述第一终端为所述商家使用的终端；
11.确定每个卡单处理选项对应的运营信息，得到至少一个运营信息；
12.向所述第一终端发送所述至少一个运营信息，以使所述第一终端基于所述至少一个运营信息，对订单进行处理。
13.第三方面，提供了一种订单处理装置，所述装置由商家使用的第一终端执行，所述装置包括：
14.第一展示模块，用于展示卡单处理界面，所述卡单处理界面包括多个卡单处理选项，所述卡单处理选项用于触发更改所述商家的运营信息，所述运营信息用于表示所述商家在互联网平台中接受订单的运营模式；
15.第一获取模块，用于响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息；
16.处理模块，用于基于所述至少一个运营信息，对订单进行处理。
17.第四方面，提供了一种订单处理装置，所述装置由服务器执行，所述装置包括：
18.第一接收模块，用于接收第一终端发送的卡单处理请求，所述卡单处理请求携带被选择的至少一个卡单处理选项，所述至少一个卡单处理选项用于触发更改商家的运营信息，所述运营信息用于表示所述商家在互联网平台接受订单的运营模式，所述第一终端为所述商家使用的终端；
19.第一确定模块，用于确定每个卡单处理选项对应的运营信息，得到至少一个运营信息；
20.第一发送模块，用于向所述第一终端发送所述至少一个运营信息，以使所述第一终端基于所述至少一个运营信息，对订单进行处理。
21.第五方面，提供了一种计算机设备，该计算机设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条指令，该至少一条指令由该一个或多个处理器加载并执行以实现如上述第一方面任一项所述的订单处理方法所执行的操作，或者如上述第二方面任一项所述的订单处理方法所执行的操作。
22.第六方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该至少一条指令由处理器加载并执行以实现如上述第一方面任一项所述的订单处理方法所执行的操作，或者如上述第二方面任一项所述的订单处理方法所执行的操作。
23.第七方面，提供了一种计算机程序产品，该计算机程序产品包括至少一条指令，所述至少一条指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取所述至少一条指令，处理器执行所述至少一条指令，使得该计算机设备能够执行上述第一方面任一项所述的订单处理方法所执行的操作，或者如上述第二方面任一项所述的订单处理方法所执行的操作。
24.本技术实施例提供的技术方案带来的有益效果至少包括：
25.本技术实施例提供了一种订单处理方法，当出现卡单情况时，第一终端展示卡单处理界面，商家可以通过选择卡单处理界面的至少一个卡单处理选项，来更改商家在互联网平台接受订单的运营模式对应的运营信息，基于更改后的运营信息对订单进行处理，以此来缓解卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
附图说明
26.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
27.图1是本技术实施例提供的一种订单处理方法的实施环境的示意图；
28.图2是本技术实施例提供的一种订单处理方法的流程图；
29.图3是本技术实施例提供的一种订单处理方法的流程图；
30.图4是本技术实施例提供的一种订单处理方法的流程图；
31.图5是本技术实施例提供的一种待出单界面的示意图；
32.图6是本技术实施例提供的一种首次展示待出单界面的示意图；
33.图7是本技术实施例提供的一种卡单上报界面的示意图；
34.图8是本技术实施例提供的另一种卡单上报界面的示意图；
35.图9是本技术实施例提供的一种卡单处理界面的示意图；
36.图10是本技术实施例提供的一种缩小配送范围后配送范围界面的示意图；
37.图11是本技术实施例提供的一种置休界面的示意图；
38.图12是本技术实施例提供的一种营业设置界面的示意图；
39.图13是本技术实施例提供的一种接单设置界面的示意图；
40.图14是本技术实施例提供的一种设置承诺出单时长的流程图；
41.图15是本技术实施例提供的一种设置订单高峰时段和出单时长的示意图；
42.图16是本技术实施例提供的一种出单时长设置界面的示意图；
43.图17是本技术实施例提供的一种取消订单界面的示意图；
44.图18是本技术实施例提供的一种订单处理装置的结构示意图；
45.图19是本技术实施例提供的一种订单处理装置的结构示意图；
46.图20是本技术实施例提供的一种终端的结构框图；
47.图21是本技术实施例提供的一种服务器的结构框图。
具体实施方式
48.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施方式作进一步地详细描述。
49.图1是本技术实施例提供的一种订单处理方法的实施环境的示意图。参见图1，该实施环境包括：第一终端101、第二终端102、第三终端103和服务器104，第一终端101为准备订单的商家使用的终端，第二终端102为为配送运力对应的终端，其中，配送运力是指能够进行配送的人力或物力；配送运力可以包括配送人员、无人配送车、无人飞机、配送机器等任一类型的配送运力。第三终端103为请求获取订单的物品的用户使用的终端。第一终端101、第二终端102和第三终端103上均安装有目标应用程序，该目标应用程序可以为即时配送应用，该服务器104为目标应用程序对应的服务器104，且第一终端101、第二终端102、第三终端103均与服务器104通过无线或有线网络连接。
50.在本技术实施例中，该方法可以应用到以下场景中，例如，美食配送、服装配送、家电配送、日用品配送等。在本技术实施例中，仅以美食配送为例进行说明。商家通过第一终端上的美食应用程序展示其出售的物品，并且展示其准备物品的出单时长，用户可以参考出单时长，通过第三终端103选择商家展示的物品，进行下单。服务器104获取用户下单的订单信息，向第一终端发送订单的订单信息，第一终端接收该订单的订单信息，准备该订单对应的物品。并且，服务器104还根据该订单的订单信息以及第一终端准备物品的出单时长指派配送运力，由配送运力向用户配送该订单，从而用户获取该订单对应的物品。
51.第一终端101、第二终端102和第三终端103为手机、平板电脑和pc(personal computer)设备等设备中的至少一种。服务器104可以为一台服务器、由多台服务器组成的
服务器集群、云服务器、云计算平台和虚拟化中心中的至少一种。
52.图2是本技术实施例提供的一种订单处理方法的流程图，参见图2，该方法由商家使用的第一终端执行，该方法包括：
53.步骤201：展示卡单处理界面，卡单处理界面包括多个卡单处理选项，卡单处理选项用于触发更改商家的运营信息，运营信息用于表示商家在互联网平台中接受订单的运营模式。
54.步骤202：响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息。
55.步骤203：基于至少一个运营信息，对订单进行处理。
56.在一种可能的实现方式中，至少一个卡单处理选项包括降低接单量选项，运营信息包括配送范围信息或者物品信息；
57.响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息，包括：
58.响应于基于降低接单量选项被触发的选择操作，向服务器发送配送范围缩小请求，配送范围缩小请求用于请求将当前的第一配送范围缩小为第二配送范围；接收服务器发送的第二配送范围对应的配送范围信息；或者，
59.响应于基于降低接单量选项被触发的选择操作，向服务器发送撤销促销请求，撤销促销请求用于请求撤销正在进行促销的促销物品；接收服务器发送的撤销促销物品后的物品信息。
60.在另一种可能的实现方式中，至少一个卡单处理选项包括置休选项，运营信息包括商家的停业状态信息；
61.响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息，包括：
62.响应于基于置休选项被触发的选择操作，向服务器发送营业状态调整请求，营业状态调整请求用于请求将当前的营业状态调整为停业状态；
63.获取服务器发送的停业状态信息。
64.在另一种可能的实现方式中，至少一个卡单处理选项包括手动接单选项，运营信息包括手动接单模式的模式信息；
65.响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息，包括：
66.响应于基于手动接单选项被触发的选择操作，向服务器发送接单模式调整请求，接单模式调整请求用于请求将自动接单模式调整为手动接单模式；
67.接收服务器发送的手动接单模式的模式信息。
68.在另一种可能的实现方式中，至少一个卡单处理选项包括延长出单时长选项，运营信息包括第一出单时长的时长信息；
69.响应于基于至少一个卡单处理选项被触发的选择操作，获取每个卡单处理选项对应的运营信息，得到至少一个运营信息，包括：
70.响应于基于延长出单时长选项被触发的选择操作，向服务器发送出单时长延长请求，出单时长延长请求用于请求将当前的第二出单时长调整为第一出单时长；
71.接收服务器发送的第一出单时长的时长信息。
72.在另一种可能的实现方式中，方法还包括：
73.展示出单时长设置界面，出单时长设置界面包括设置时长入口；
74.响应于基于设置时长入口被触发的设置操作，确定订单高峰时段的起始时间；
75.基于订单高峰时段的起始时间，确定订单高峰时段的第二出单时长。
76.在另一种可能的实现方式中，基于订单高峰时段的起始时间，确定订单高峰时段的第二出单时长，包括：
77.基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内的订单种类；基于订单种类，确定订单种类的第一平均出单时长；基于第一平均出单时长，确定第二出单时长；和/或，
78.基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内的订单数量；基于订单数量，确定订单数量的第二平均出单时长；基于第二平均出单时长，确定第二出单时长；和/或，
79.基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内的接单时间和配送运力的取单时间；基于接单时间和取单时间，确定第二出单时长；和/或，
80.基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内进行促销的历史促销物品；确定包括历史促销物品的第一历史订单的第三平均出单时长和不包括历史促销物品的第二历史订单的第四平均出单时长；基于第三平均出单时长和第四平均出单时长，确定第二出单时长；和/或，
81.基于订单高峰时段的起始时间，获取输入的第二出单时长。
82.在另一种可能的实现方式中，方法还包括：
83.获取延长出单时长选项被触发后的生效时长；
84.响应于生效时长达到预设生效时长，自动将正在处理的订单的第一出单时长恢复为第二出单时长；
85.响应于生效时长未达到预设生效时长，检测到恢复操作时或接收到服务器发送的恢复指令时，将正在处理的订单的第一出单时长恢复为第二出单时长。
86.在另一种可能的实现方式中，方法还包括：
87.获取服务器发送的调整消息，调整消息为第二终端向服务器上报请求调整第一订单配送时长的消息，且调整消息中包括第二终端上报请求调整第一订单配送时长的上报时间，第二终端为配送运力对应的终端；
88.确定第一订单的实际出单时间；
89.若实际出单时间早于上报时间，响应于基于验证入口被触发的验证操作，向服务器发送验证请求，以使服务器对第一订单的出单时间进行验证。
90.在另一种可能的实现方式中，展示卡单处理界面，包括：
91.展示待出单界面，待出单界面包括卡单上报入口，卡单上报入口用于上报当前出现卡单；响应于基于卡单上报入口被触发的上报操作，从待出单界面跳转到卡单处理界面；或者，
92.接收到服务器发送的卡单提示消息时，在当前显示界面的上层弹出卡单提示消息；基于卡单提示消息，响应于基于卡单上报入口被触发的上报操作，从待出单界面跳转到
卡单处理界面。
93.本技术实施例提供了一种订单处理方法，当出现卡单情况时，第一终端展示卡单处理界面，商家可以通过选择卡单处理界面的至少一个卡单处理选项，来更改商家在互联网平台接受订单的运营模式对应的运营信息，基于更改后的运营信息对订单进行处理，以此来缓解卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
94.图3是本技术实施例提供的一种订单处理方法的流程图，参见图3，该方法由服务器执行，该方法包括：
95.步骤301：接收第一终端发送的卡单处理请求，卡单处理请求携带被选择的至少一个卡单处理选项，至少一个卡单处理选项用于触发更改商家的运营信息，运营信息用于表示商家在互联网平台接受订单的运营模式，第一终端为商家使用的终端。
96.步骤302：确定每个卡单处理选项对应的运营信息，得到至少一个运营信息。
97.步骤303：向第一终端发送至少一个运营信息，以使第一终端基于至少一个运营信息，对订单进行处理。
98.在一种可能的实现方式中，至少一个卡单处理选项包括延长出单时长选项，运营信息包括第一出单时长的时长信息；
99.方法还包括：
100.基于第一出单时长，将第一订单的第一指派时间调整为第二指派时间，第二指派时间晚于第一指派时间；基于第二指派时间，对第一订单进行指派处理；或者，
101.基于第一出单时长，向第三终端发送通知消息，通知消息用于通知第一订单的预计送达时间，第三终端为用户使用的终端；接收第三终端基于通知消息发送的取消订单请求，获取第一订单的订单状态，向第三终端发送第一订单的订单状态，以使用户撤销取消订单请求对应的取消操作；或者，
102.若接收到第二终端基于第一出单时长发送的转单请求，对第一订单进行转单处理，转单请求用于请求将第一订单转给其他配送运力，第二终端为配送运力对应的终端；或者，
103.基于第一出单时长，对第一订单的配送时长进行调整，以使第二终端基于调整后的配送时长，对第一订单进行处理。
104.在另一种可能的实现方式中，基于第一出单时长，对第一订单的配送时长进行调整，包括：
105.接收第二终端基于第一出单时长发送的配送时长调整请求；
106.基于配送时长调整请求，获取第二终端当前的位置信息；
107.若基于位置信息确定第二终端到达第一终端所在的目标场所，对第一订单的配送时长进行调整。
108.在另一种可能的实现方式中，获取第二终端当前的位置信息，包括：
109.对第二终端进行定位，得到定位信息；获取第二终端上传的图像数据，图像数据包括配送运力和目标场所的合照图像；检测图像数据中是否存在目标场所的门头数据，若检测到目标场所的门头数据，将定位信息和图像数据组成位置信息；或者，
110.获取第二终端当前接入网络的网络信息；若网络信息表示第二终端当前接入网络
为目标场所的网络，将目标场所的位置信息作为第二终端当前的位置信息。
111.在另一种可能的实现方式中，方法还包括：
112.确定第二终端上报配送时长调整请求的上报时间；
113.接收第一终端发送的验证请求，验证请求包括第一订单的实际出单时间；
114.若实际出单时间早于上报时间，保持第一订单的配送时长不变。
115.在另一种可能的实现方式中，方法还包括：
116.若第一终端待出单订单的第一数量大于预设订单数量，确定商家出现卡单情况，向第一终端发送第一卡单提示消息，以使第一终端发送卡单处理请求；和/或，
117.若待出单订单的订单资源数值大于预设订单资源数值，确定商家出现卡单情况，向第一终端发送第二卡单提示消息，以使第一终端发送卡单处理请求；和/或，
118.若待出单订单的物品种类大于预设物品种类，确定商家出现卡单情况，向第一终端发送第三卡单提示消息，以使第一终端发送卡单处理请求；和/或，
119.若第二数量中有第三数量个第二终端的等单时间超出预设等单时间，确定商家出现卡单情况，向第一终端发送第四卡单提示消息，以使第一终端发送卡单处理请求，第二数量为到达第一终端所在的目标场所的多个第二终端的数量，第二终端为配送运力对应的终端。
120.在另一种可能的实现方式中，方法还包括：
121.确定预设历史时间范围内商家的准时出单率；
122.若准时出单率小于预设准时出单率，将商家的营业状态强制调整为停业状态。
123.本技术实施例提供了一种订单处理方法，服务器接收商家使用的第一终端在出现卡单情况时发送的卡单处理请求，基于该卡单处理请求更改该商家在互联网平台接受订单的运营模式对应的运营信息，然后向该第一终端发送更改后的运营信息，这样商家就可以基于更改后的运营信息对订单进行处理，以此来缓解商家当前出现的卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
124.图4是本技术实施例提供的一种订单处理方法的流程图，参见图4，该方法由服务器和商家使用的第一终端执行，该方法包括：
125.步骤401：第一终端展示卡单处理界面。
126.该卡单处理界面包括多个卡单处理选项，该卡单处理选项用于触发更改商家的运营信息，该运营信息用于表示该商家在互联网平台中接受订单的运营模式。
127.本步骤中，商家可以在出现卡单情况时主动上报，或者服务器也可以主动监测第一终端待出单订单的订单信息，在监测到第一终端出现卡单情况时，向第一终端发送卡单提示消息，以提醒商家上报卡单。
128.在本技术实施例中，若商家在出现卡单情况时主动上报，该过程可以通过以下步骤(1)至(2)实现，包括：
129.(1)第一终端展示待出单界面，该待出单界面包括卡单上报入口，该卡单上报入口用于上报当前出现卡单。
130.第一终端可以登录即时配送应用，展示该即时配送应用的主界面，该主界面包括待出单入口，第一终端在检测到该待出单入口被触发时，从主界面跳转到待出单界面。
131.在一种可能的实现方式中，参见图5，待出单界面中可以展示待出单订单的第一数
量，若第一数量超过预设订单数量，且第一终端检测到卡单上报入口被触发的触发操作时，上报出现卡单。例如，预设订单数量为10，第一数量为15，第一数量超过预设订单数量，也即该订单超过商家的出单能力时，商家可以通过卡单上报入口上报卡单。
132.在另一种可能的实现方式中，继续参见图5，待出单界面中还可以展示待出单订单的订单资源数值，若该订单资源数值大于预设订单资源数值，且第一终端检测到卡单上报入口被触发的触发操作时，上报出现卡单。例如，待出单订单的订单资源数值为555.55，预设订单资源数值为200，该订单资源数值超过预设订单资源数值，也即该订单超过商家的出单能力时，商家可以通过卡单上报入口上报卡单。
133.在另一种可能的实现方式中，继续参见图5，待出单界面中还可以展示待出单订单的物品种类，若该物品种类大于预设物品种类，且第一终端检测到卡单上报入口被触发的触发操作时，上报出现卡单。例如，待出单订单的物品种类为15件，预设物品种类为10件，该物品种类超过预设物品种类，也即该订单超过商家的出单能力时，商家可以通过卡单上报入口上报卡单。
134.其中，待出单界面中还可以展示每个订单的订单信息以及该订单对应的出单状态，该订单信息可以包括请求获取物品的用户的手机尾号、配送地址、用户名、用户标签、距目标场所的距离、订单金额、物品数量、预计收入等信息，该用户标签为用户是该店的新顾客还是老顾客。该出单状态可以包括备单中和备单用时。
135.待出单界面中还可以包括出单完成入口，每个订单对应一个出单完成入口，当该订单准备完成时，第一终端在检测到出单完成入口被触发的触发操作时，可以更新该订单的出单状态，例如显示订单准备完成，然后由配送运力对该订单进行配送。或者，继续参见图5，待出单界面中展示扫码出单入口，当该订单准备完成时，第一终端在检测到扫码出单入口被触发时，可以跳转到扫码界面，通过扫描出单二维码更新该订单的出单状态即出单完成，然后由配送运力对该订单进行配送。
136.在一种可能的实现方式中，参见图6，当第一终端首次展示该待出单界面时，可以在该界面的上层弹出透明弹层，该弹层上标出卡单上报入口的位置，并弹出提示消息，用于提醒商家卡单上报入口的位置。例如，该提示消息可以为“您可以在这里处理卡单问题哦～”。另外，该弹层上还可以弹出关闭入口，第三终端检测到该关闭入口被触发时，关闭弹层。该关闭入口可以以关闭按钮的形式显示，该关闭按钮可以为“我知道了”或者“关闭”。
137.(2)响应于基于该卡单上报入口被触发的上报操作，第一终端从待出单界面跳转到卡单处理界面。
138.在一种可能的实现方式中，第一终端可以在检测到卡单上报入口被触发时，直接从待出单界面跳转到卡单处理界面，从而展示卡单处理界面。
139.在另一种可能的实现方式中，第一终端也可以在检测到卡单上报入口被触发时，先从待出单界面跳转到卡单上报界面，再从卡单上报界面跳转到卡单处理界面。
140.该实现方式中，卡单上报界面包括多个卡单上报选项，每个卡单上报选项用于表示当前出现卡单的不同因素。当任一卡单上报选项被触发时，第一终端从卡单上报界面跳转到卡单处理界面。
141.例如，参见图7，该多个卡单上报选项包括堂食人数多、外卖单量太多、突然有一金额较大的订单、突然有一个商品数量很多的订单、店里设备出现了问题和其他原因。参见图
8，若当前展示的多个卡单上报选项中没有相应的造成当前出现卡单的因素，商家还可以选择卡单上报选项中的其他原因，手动输入造成当前出现卡单的因素，例如，突然停电。例如，商家手动输入突然停电，然后触发上报按钮，在显示上报成功的提示消息后，自动跳转到卡单处理界面，参见图9。
142.需要说明的一点是，卡单处理界面中除了显示多个卡单处理选项，还可以显示每个卡单处理选项的生效时长，每个卡单处理选项的生效时长可以相同或者不同，该生效时长可以根据需要进行设置并更改，例如，生效时长为10分钟、15分钟或者20分钟。若每个卡单处理选项的生效时长相同，则可以在多个卡单处理选项的上方或者下方显示一个生效时长，例如，生效时长为10分钟，则可以显示“设置后10分钟内有效”，继续参见图9。
143.需要说明的另一点是，卡单处理界面中还可以显示预设历史时间范围该商家的准时出单率，基于该准时出单率与预设准时出单率，弹出提示消息，该提示消息用于表示该准时出单率是否正常。例如，继续参见图5，该商家在上周的准时出单率为70％，预设准时出单率为80％，商家的准时出单率小于预设准时出单率，则该提示消息的内容可以为“异常”，并突出显示该内容。若商家在上周的准时出单率为85％，大于预设准时出单率，也可以弹出提示消息，该提示消息的内容可以为“正常”；或者不弹出提示消息。在本技术实施例中，对此不作具体限定。
144.在本技术实施例中，若服务器通过向第一终端发送卡单提示消息，来提醒商家上报卡单，该过程可以通过以下步骤(3)至(7)实现，包括：
145.(3)服务器获取第一终端待出单订单的第一数量，若第一数量大于预设订单数量，确定该商家出现卡单情况，向第一终端发送第一卡单提示消息。
146.该第一卡单提示消息用于提示第一终端向服务器发送卡单处理请求，该第一卡单提示消息中可以携带该第一数量。服务器可以实时监测或周期性监测第一终端待出单订单的第一数量，在该第一数量大于预设订单数量时，向第一终端发送提示消息。
147.(4)服务器获取第一终端待出单订单的订单资源数值，若该订单资源数值大于预设订单资源数值，确定商家出现卡单情况，向第一终端发送第二卡单提示消息。
148.第一终端每接受一个订单，服务器可以获取该订单的订单资源数值，若该订单资源数值大于预设订单资源数值，说明该订单可能会影响出单时长，这时服务器可以向第一终端发送第二卡单提示消息，第二卡单提示消息中可以携带该订单资源数值。
149.(5)服务器获取第一终端待出单订单的物品种类，若该物品种类大于预设物品种类，确定商家出现卡单情况，向第一终端发送第三卡单提示消息。
150.第一终端每接受一个订单，服务器可以获取该订单的物品种类，若该物品种类大于预设物品种类，说明该订单可能会影响出单时长，这时服务器可以向第一终端发送第三卡单提示消息，第三卡单提示消息中携带该物品种类的数量。
151.(6)服务器获取到达第一终端所在的目标场所的多个第二终端的第二数量，若第二数量中有第三数量个第二终端的等单时间大于预设等单时间，确定商家出现卡单情况，向第一终端发送第四卡单提示消息。
152.第二终端为配送运力对应的终端，以配送运力为网约配送员为例进行说明。
153.在一种可能的实现方式中，每个网约配送员到达商家所在的目标场所后，可以通过触发订单配送界面的到店入口向服务器上报其已到店，服务器将该到店入口被触发的时
间作为其到店时间。对于每个网约配送员，也即每个第二终端，服务器确定该网约配送员的到店时间与当前时刻之间的时间间隔，将该时间间隔作为第二终端的等单时间。若第二数量个第二终端中有第三数量个第二终端的等单时间大于预设等单时间，说明网约配送员等单情况严重，也即当前订单超出商家的出单能力，这时服务器可以向第一终端发送第四卡单提示消息，该第四卡单提示消息中可以携带第二数量和第三数量。
154.例如，服务器获取到达商家店内的网约配送员的第二数量为10，预设等单时间为10分钟，若10个网约配送员中有8个网约配送员的等单时间大于10分钟，说明网约配送员等单情况严重，这时服务器可以向第一终端发送第四卡单提示消息。
155.在另一种可能的实现方式中，服务器获取第二数量和第三数量后，可以确定第三数量所占第二数量的比例，若该比例大于预设比例，也可以说明网约配送员等单情况严重，这种情况下服务器可以向第一终端发送卡单提示消息。
156.(7)第一终端接收服务器发送的卡单提示消息，在当前显示界面的上层弹出该卡单提示消息；基于该卡单提示消息，响应于基于卡单上报入口被触发的上报操作，从待出单界面跳转到卡单处理界面。
157.该卡单提示消息可以为第一卡单提示消息、第二卡单提示消息、第三卡单提示消息或第四卡单提示消息，也可以为基于上述四种卡单提示消息综合触发的卡单提示消息。
158.第一终端接收卡单提示消息后，可以直接在当前显示界面的上层弹出该卡单提示消息。第一终端接收到卡单提示消息后，若当前显示界面为待出单界面，商家可以通过触发待出单界面中的卡单上报入口上报出现卡单。若当前显示界面非待出单界面，商家可以先退出当前显示界面然后进入待出单界面，再通过待出单界面的卡单上报入口上报出现卡单。
159.在一种可能的实现方式中，第一终端在当前显示界面的上层弹出卡单提示消息时，还可以弹出卡单上报入口，商家查看该卡单提示消息时，可以直接触发该卡单上报入口进入卡单处理界面，这样在当前显示界面非待出单界面时，商家就无需退出当前显示界面，重新进入待出单界面，简化了商家操作，提高了商家体验。
160.在一种可能的实现方式中，服务器还可以根据监测第一终端的订单情况生成标识，该标识用于对多个卡单处理选项中的目标卡单处理选项进行标记，为第一终端推荐缓解当前卡单情况的卡单处理选项，该目标卡单处理选项可以为一个也可以为多个。然后向第一终端发送卡单提示消息时，还发送生成的标识。
161.例如，服务器监测到第一终端待出单订单的第一数量大于预设订单数量时，或者监测到网约配送员的等单情况严重时，生成第一标识，该第一标识用于标记降低接单量选项，或者标记降低接单量选项中的缩小配送范围子选项。服务器监测到待出单订单的订单资源数值大于预设订单资源数值时，或者待出单订单的物品种类大于预设物品种类时，生成第二标识，该第二标识用于标记出单时长信息。
162.第一终端除了接收服务器发送的卡单提示消息，还接收到用于标记卡单处理选项的标识，第一终端可以根据该标识，突出显示该标识对应的卡单处理选项。例如，第一终端可以放大显示该标识对应的卡单处理选项。或者，继续参见图9，第一终端在该标识对应的卡单处理选项的左方显示提示消息，该提示消息的内容可以为“荐”，也即推荐商家触发该卡单处理选项。
163.在本技术实施例中，服务器可以基于识别模型识别订单是否为大额订单、订单物品种类数量是否较多、订单数量是否过大、网约配送员等单情况严重等数据中的其中一种进行分析，然后触发向第一终端发送卡单提示消息，也可以基于上述数据进行综合分析，然后触发向第一终端发送卡单提示消息。卡单提示消息中还可以推荐相应的卡单解决措施，也即卡单处理选项，提示用户通过触发相应的卡单处理选项可以缓解当前卡单情况。商家也可以自主选择相应的卡单处理选项来缓解当前卡单情况。并且，多种卡单处理选项可以叠加同时生效，从而满足商家在不同情况下的差异化需求。另外，服务器经过不断的卡单识别以及选择相应措施后的效果分析，积累到卡单相关数据，进而优化迭代识别模型，反哺这套机制。
164.步骤402：响应于基于至少一个卡单处理选项被触发的选择操作，第一终端向服务器发送卡单处理请求。
165.本步骤中，商家可以基于推荐的卡单处理选项触发该卡单处理选项，也可以在触发该卡单处理选项的基础上，触发其他卡单处理选项，从而触发至少一个卡单处理选项。
166.在本技术实施例中，至少一个卡单处理选项可以包括降低接单量选项、置休选项、手动接单选项、延长出单时间选项中的至少一个。
167.若至少一个卡单处理选项包括降低接单量选项，该降低接单量选项包括缩小配送范围子选项和撤销促销物品子选项，若缩小配送范围子选项被触发，第一终端向服务器发送配送范围缩小请求，该配送范围缩小请求用于请求将当前的第一配送范围缩小为第二配送范围。若撤销促销物品子选项被触发，第一终端向服务器发送撤销促销请求，该撤销促销请求用于请求撤销正在进行促销的促销物品。相应的，卡单处理请求为配送范围缩小请求或撤销促销请求。
168.若至少一个卡单处理选项包括置休选项，响应于基于置休选项被触发的选择操作，第一终端向服务器发送营业状态调整请求，该营业状态调整请求用于请求将当前的营业状态调整为停业状态。相应的，卡单处理请求为营业状态调整请求。
169.若至少一个卡单处理选项包括手动接单选项，响应于基于手动接单选项被触发的选择操作，第一终端向服务器发送接单模式调整请求，该接单模式调整请求将自动接单模式调整为手动接单模式。相应的，卡单处理请求为接单模式调整请求。
170.若至少一个卡单处理选项包括延长出单时长选项，该延长出单时长选项包括多个延长出单时长子选项，每个延长出单时长子选项被触发后延长的出单时长不同。在任一延长出单时长子选项被触发时，第一终端向服务器发送出单时长延长请求，该出单时长延长请求用于请求将当前的第二出单时长调整为被触发的延长出单时长子选项对应的第一出单时长。相应的，卡单处理请求为出单时长延长请求。
171.例如，延长出单时长选项包括3个延长出单时长子选项，每个延长出单时长子选项被触发后延长的出单时长分别为10分钟、12分钟和15分钟，若延长至10分钟的子选项被触发，第一终端向服务器发送出单时长延长请求，该出单时长延长请求用于请求将订单的出单时长延长至10分钟，继续参见图9。
172.本步骤中，若至少一个卡单处理选项包括多个卡单处理选项，则卡单处理请求为将每个卡单处理选项对应的请求综合得到的请求。
173.步骤403：服务器接收该卡单处理请求，确定每个卡单处理选项对应的运营信息，
得到至少一个运营信息。
174.本步骤中，卡单处理请求携带被选择的至少一个卡单处理选项，该至少一个卡单处理选项用于触发更改商家的运营信息，该运营信息用于表示商家在互联网平台接受订单的运营模式。
175.在一种可能的实现方式中，服务器可以预先建立卡单处理选项与运营信息之间的对应关系，在接收该卡单处理请求时，基于该对应关系，确定卡单处理请求中每个卡单处理选项对应的运营信息，从而得到至少一个运营信息。
176.多个卡单处理选项包括降低接单量选项、置休选项、手动接单选项和出单时长延长选项，降低接单量选项包括缩小配送范围子选项和撤销促销物品子选项，出单时长延长选项包括多个延长出单时长子选项。服务器可以预先建立缩小配送范围子选项与配送范围信息之间的对应关系，撤销促销物品子选项与物品信息之间的对应关系，置休选项与停业状态信息之间的对应关系，手动接单选项与手动接单模式的模式信息之间的对应关系，延长出单时长子选项与出单时长的时长信息之间的对应关系。
177.步骤404：服务器向第一终端发送该至少一个运营信息。
178.本步骤中，服务器可以直接向第一终端发送该至少一个运营信息，也可以将该至少一个运营信息进行封装，向第一终端发送封装后的运营信息。
179.步骤405：第一终端接收服务器发送的该至少一个运营信息，基于该至少一个运营信息，对订单进行处理。
180.若服务器直接第一终端发送该至少一个运营信息，第一终端接收该至少一个运营信息后，可以直接基于该至少一个运营信息，对订单进行处理。若第一终端接收到的运营信息为封装后的运营信息，则第一终端先对运营信息进行解封装，得到解封装后的至少一个运营信息，然后基于解封装后的至少一个运营，对订单进行处理。
181.在一种可能的实现方式中，若至少一个运营信息包括配送范围信息，则第一终端基于该配送范围信息，将当前的第一配送范围缩小为第二配送范围，基于缩小后的第二配送范围，接受订单。
182.例如，第一配送范围为15平方公里，缩小后的第二配送范围为10平方公里，参见图10，则通过缩小配送范围可以在一定程度上减少用户下单，从而缓解商家准备订单的压力。
183.在本技术实施例中，通过缩小配送范围，在一定程度上可以减少配送范围之外的用户的订单，从而降低接单量，避免在准备订单期间内较多用户下单，导致用户等待较长时间，同时也避免影响自身信誉。
184.在另一种可能的实现方式中，若至少一个运营信息包括物品信息，则第一终端基于该物品信息，撤销当前正在进行促销的促销物品，基于撤销促销物品之后的物品，接受订单。
185.在本技术实施例中，通过撤销促销物品，在一定程度上可以减少用户下单，从而降低接单量，避免在准备订单期间内较多用户下单，导致用户等待较长时间，同时也避免影响自身信誉。
186.在另一种可能的实现方式中，若至少一个运营信息包括商家的停业状态信息，则第一终端将当前的营业状态调整为停业状态，在停业状态下，准备当前的订单。
187.该实现方式中，商家可以通过触发卡单处理界面中的置休入口，将当前的营业状
态调整为停业状态。该置休入口可以以申请置休10分钟的按钮行驶显示，当第一终端检测到该按钮被触发时，跳转到确认置休界面。该确认置休界面中可以弹出提示消息，用于提醒商家是否确认置休，当该确认置休界面中的确认按钮被触发时，第一终端将营业状态调整为停业状态，并弹出设置成功的提示消息，该提示消息的内容可以为“已置休10分钟”。
188.在一种可能的实现方式中，卡单处理界面中还可以显示设置置休时间入口，商家通过触发该设置置休时间入口自行设置置休时间，在本技术实施例中，对置休时间不作具体限定。
189.在一种可能的实现方式中，参见图11，当置休成功后，第一终端可以自动跳转到置休界面，该置休界面中可以显示“本店停业中，10分钟自动恢复营业”的提示消息。该置休界面中还可以显示第一恢复营业入口，该第一恢复营业入口可以以“去恢复营业按钮”的形式显示。当第一终端检测到该去恢复营业按钮被触发时，可以跳转到营业设置界面。参见图12，图12所示界面为营业设置界面，该营业设置界面中显示第二恢复营业入口，该第二恢复营业入口可以以“恢复营业按钮”的形式显示。该营业设置界面还可以显示当前的营业状态，即停业中。当第一终端检测到该恢复营业按钮被触发时，可以将当前的营业状态由停业状态调整为营业状态。该营业设置界面还可以显示已临时置休，18:20自动恢复营业的提示消息。
190.在本技术实施例中，在当前订单未准备完成时，商家可以将营业状态设置为停业，在停业状态下准备当前已接受的订单，避免在准备该订单期间内用户下单，导致用户等待较长时间，影响自身信誉和用户下单。
191.在另一种可能的实现方式中，若至少一个运营信息包括手动接单模式的模式信息，则第一终端将当前的自动接单模式调整为手动接单模式，在手动接单模式下，接受订单。
192.该实现方式中，当第一终端检测到卡单处理界面中的手动接单入口被触发时，可以跳转到接单设置界面。参见图13，图13所示界面为接单设置界面，该接单设置界面中展示自动接单的开关，当手动接单入口被触发时，关闭自动接单。并且，第一终端还可以在该接单设置界面弹出提示消息，该提示消息用于提醒商家已改变接单模式，该提示消息的内容可以为“已临时开启手动接单，18:20自动恢复为自动接单”。
193.该实现方式中，在改变接单模式之前，接单模式为自动接单，自动接单的速度较快，而当用户下单的数量较多，超出商家接单能力时，商家可以将接单模式设置为手动接单，在一定程度上降低接单速度，自主选择接单，避免在准备订单期间内较多用户下单，导致用户等待较长时间，同时也避免影响自身信誉。
194.在另一种可能的实现方式中，若至少一个运营信息包括第一出单时长的时长信息，则第一终端将当前的第二出单时长调整为第一出单时长，基于第一出单时长，准备订单的物品。
195.该实现方式中，当第一终端检测到卡单处理界面中任一延长出单时长子选项被触发时，可以将当前的第二出单时长调整为被触发的延长出单时长子选项对应的第一出单时长。
196.该实现方式中，商家可以请求延长订单的出单时长，根据延长后的出单时长准备订单，避免由于自身准备订单的物品超时，影响网约配送员的配送超时率，并且，还可以避
免对自身信誉造成影响，影响后续用户下单。
197.需要说明的一点是，每个卡单处理选项都有其对应的生效时长，参见图13，第一终端还可以在待出单界面中显示每个运营信息的生效时长，或者显示该生效时长失效时对应的截止时间。在该生效时长达到预设生效时长时，可以自动恢复为原来的运营信息。或者，在该生效时长未达到预设生效时长，但当前的卡单情况得到缓解时，由商家主动恢复为原来的运营信息。或者，在该生效时长未达到预设生效时长，而服务器在监测到第一终端的卡单情况得到缓解时，向第一终端发送提示消息，商家基于该提示消息，主动恢复为原来的运营信息。或者，在该生效时长未达到预设生效时长，而服务器在监测到第一终端的卡单情况得到缓解时，自动将第一终端的运营信息恢复为原来的运营信息。
198.例如，服务器识别到卡单情况得到缓解时，自动将第二配送范围恢复为原来的第一配送范围。再如，服务器识别到卡单情况得到缓解时，自动将手动接单模式恢复为自动接单模式。再如，服务器识别到卡单情况得到缓解时，自动将停业状态恢复为营业状态。
199.在本技术实施例中，仅以延长出单时长选项为例进行说明，该过程可以为：第一终端获取延长出单时长子选项被触发后的生效时长；响应于该生效时长达到预设生效时长，自动将正在处理的订单的第一出单时长恢复为第二出单时长；响应于生效时长未达到预设生效时长，检测到恢复操作时或接收到服务器发送的恢复指令时，将正在处理的订单的第一出单时长恢复为第二出单时长。
200.本技术实施例提供了一种订单处理方法，在出现卡单情况时，第一终端展示卡单处理界面，商家可以通过选择卡单处理界面的至少一个卡单处理选项，触发第一终端向服务器发送卡单处理请求，服务器基于该卡单处理请求更改商家在互联网平台接受订单的运营模式对应的运营信息，然后向第一终端发送更改后的运营信息，这样商家就可以基于更改后的运营信息对订单进行处理，以此来缓解商家当前出现的卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
201.在本技术实施例中，在延长出单时长选项被触发时，服务器将当前的第二出单时长调整为第一出单时长，第一终端基于该第一出单时长对订单进行处理。其中，第二出单时长为商家预先设置的承诺出单时长。
202.在本技术实施例中，第一终端可以通过以下步骤1401至1403来设置承诺出单时长，参见图14，该方法包括：
203.步骤1401：第一终端展示出单时长设置界面。
204.该出单时长设置界面包括：设置时长入口。
205.在本步骤中，第一终端可以登录即时配送应用，在检测到设置操作时，进入该出单时长设置界面。或者，服务器也可以预先检测订单高峰时段及其对应的第二出单时长的设置记录。
206.步骤1402：响应于基于设置时长入口被触发的设置操作，第一终端确定订单高峰时段的起始时间。
207.本步骤中，第一终端在检测到设置时长入口被触发时，向服务器发送设置时长请求，服务器接收该设置时长请求，确定第一终端是否设置过订单高峰时段。参见图15，若检测不到设置记录，说明商家没有设置过订单高峰时段及其对应的第二出单时长，则服务器可以向第一终端发送提示消息，该提示消息用于提醒商家可以设置订单高峰时段及其对应
的第二出单时长。例如，该提示消息的内容可以为“您可以在出单时长设置界面中设置订单高峰时段及出单时长哦～”。商家通过该提示消息可以设置订单高峰时段及其对应的第二出单时长。
208.若检测到设置记录，服务器可以确定设置的订单高峰时段是否为推荐的订单高峰时段。若设置的订单高峰时段不是推荐的订单高峰时段，则服务器可以向第一终端发送提示消息，该提示消息用于提醒商家设置订单高峰时段及对应的第二出单时长。若设置的订单高峰时段是推荐的订单高峰时段，服务器可以确定商家在该订单高峰时段的准时出单率。
209.步骤1403：第一终端基于订单高峰时段的起始时间，确定订单高峰时段的第二出单时长。
210.本步骤中，第一终端可以基于订单高峰时段的起始时间，确定订单高峰时段的第二出单时长，也可以由服务器确定订单高峰时段的第二出单时长，然后向第一终端发送该第二出单时长，第一终端获取服务器发送的第二出单时长。
211.在本技术实施例中，仅以第一终端获取服务器发送的第二出单时长为例进行说明。其中，服务器可以通过以下至少一种实现方式确定第二出单时长。
212.在一种可能的实现方式中，服务器基于订单高峰时段的起始时间，确定该订单高峰时段在历史时间内的订单种类；基于订单种类，确定订单种类的第一平均出单时长；基于第一平均出单时长，确定第二出单时长。
213.该实现方式中，不同的订单种类需要的准备时长不同，对应的出单时长也不同。服务器可以根据订单种类确定同一订单种类的第一平均出单时长，将该第一平均出单时长作为第二出单时长。
214.在另一种可能的实现方式中，服务器基于订单高峰时段的起始时间，确定该订单高峰时段在历史起始时间内的订单数量；基于该订单数量，确定订单数量的第二平均出单时长；基于第二平均出单时长，确定第二出单时长。
215.该实现方式中，服务器可以确定该订单数量对应的总出单时长，然后确定总出单时长与订单数量的比值，得到一个订单对应的第二平均出单时长，将该第二平均出单时长作为第二出单时长。
216.在另一种可能的实现方式中，服务器基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内的接单时间和配送运力的取单时间；基于接单时间和取单时间，确定第二出单时长。
217.该实现方式中，服务器可以确定历史起始时间内的订单数量，对于每个订单，服务器还确定商家的接单时间和配送运力的取单时间之间的时间间隔，然后确定一个订单对应的平均时间间隔，将该平均时间间隔作为第二出单时长。
218.在另一种可能的实现方式中，服务器基于订单高峰时段的起始时间，确定订单高峰时段在历史起始时间内进行促销的历史促销物品；确定包括历史促销物品的第一历史订单的第三平均出单时长和不包括历史促销物品的第二历史订单的第四平均出单时长；基于第三平均出单时长和第四平均出单时长，确定第二出单时长。
219.该实现方式中，服务器可以确定有促销活动时订单的第三平均出单时长和无促销活动时订单的第四平均出单时长，将第三平均出单时长和第四平均出单时长的平均值作为
第二出单时长。
220.在本技术实施例中，服务器可以根据历史商家出单时长、配送运力取单时间、单量波动情况、是否有营销活动等多因素综合考虑，为商家准确推荐第二出单时长。并且，服务器也可以根据商家规模、经营特点、商家类型以及产能情况为商家差异化推荐第二出单时长。
221.需要说明的一点是，终端也可以通过上述至少一种实现方式确定第二出单时长。并且，由终端确定第二出单时长时，终端还可以获取商家输入的第二出单时长，也即由商家根据自身实际情况自定义出单时长。另外，设置好的第二出单时长也会在用户的下单界面显示，例如用户浏览某商家的店面时，在该商家的主界面上显示第二出单时长。这样可以给用户感知到商家的出单能力，也约束商家按承诺出单时长履约。
222.参见图16，图16所示界面为出单时长设置界面，该出单时长设置界面包括设置时长入口，该设置时长入口以管理按钮的形式显示。该出单时长设置界面中显示11:30至12:30的订单高峰时段、该时段的第二出单时长30分钟以及该时段在上周的准时出单率70％，18:30至20:00的订单高峰时段、该时段的第一出单时长8分钟以及该时段在上周的准时出单率80％。该界面中还可以显示除上述订单高峰时段之外的普通时段、该时段对应的第二出单时长以及该时段在上周的准时出单率80％。
223.在一种可能的实现方式中，对于普通时段或者订单高峰时段，服务器可以确定该时段在预设历史时间范围内商家的准时出单率，若该准时出单率小于预设准时出单率时，服务器可以将商家的营业状态强制调整为停业状态，也即强制该商家停业，避免下单的用户每次都等待较长时间，影响用户体验。为了便于区分，将该预设准时出单率称为第一预设准时出单率。若商家的准时出单率大于第一预设准时出单率小于第二预设准时出单率，服务器可以向第一终端发送提示消息，该提示消息用于提醒商家提高准时出单率。或者，第一终端也可以将准时出单率突出显示。并且，在准时出单率大于第一预设准时出单率小于第二预设准时出单率时，服务器可以从商家的账户扣除部分资源，作为惩罚，在准时出单率大于第三预设准时出单率时，服务器向商家的账户转移部分资源，作为奖励。
224.继续参见图16，例如，第一预设准时出单率为60％，第二预设准时出单率为80％，11:30至12:30的订单高峰时段在上周的准时出单率为70％，大于第一预设准时出单率60％但小于第二预设准时出单率80％，则第一终端可以在准时出单率的右方弹出提示消息，该提示消息的内容可以为“异常”。18:30至20:00的订单高峰时段以及普通时段在上周的准时出单率均为80％，均不小于第二预设准时出单率，则可以不显示该提示消息。该出单时长设置界面还可以显示“网约配送员会参考第二出单时长到店取单，用户会参考第二出单时长下单，请根据实际出单情况设置准确出单时长”的消息，提醒商家准确设置第二出单时长。
225.需要说明的一点是，待出单界面中也可以显示当前时间所属的订单高峰时段、第二出单时长以及该时段在预设历史时间范围内的准时出单率。继续参见图5，待出单界面中显示11:30至12:30的订单高峰时段的第二出单时长30分钟，该第二出单时长为商家自定义的出单时长，而第一终端推荐的第二出单时长为10分钟，则在第二出单时长30分钟右方显示“偏长，建议10分钟”的提示消息。该界面中还可以显示11:30至12:30的订单高峰时段在上周的准时出单率70％。
226.在本技术实施例中，服务器可以根据历史订单数据综合为第一终端推荐合理的承
诺出单时长，且不同的时段可能对应的承诺出单时长不同，第一终端支持普通时段和高峰时段设置不同的承诺出单时长。若商家未设置过承诺出单时长，可以引导商家设置。另外，设置好的承诺出单时长会在用户下单过程中展示，给用户感知到商家的出单能力，同时也约束商家按承诺出单时长履约，出单准时率较低的商家将会受到惩罚。
227.在本技术实施例中，对于服务器来说，若至少一个卡单处理选项包括延长出单时长选项，则至少一个运营信息包括第一出单时长的时长信息，则服务器可以在向第一终端发送该至少一个运营信息后，基于该第一出单时长，对订单进行处理。或者，服务器在确定该至少一个运营信息后，向第一终端发送该至少一个运营信息之前，基于该第一出单时长，对订单进行处理。在本技术实施例中，对此不作具体限定。其中，服务器基于该第一出单时长，可以通过以下至少一种实现方式对订单进行处理。
228.在一种可能的实现方式中，服务器可以基于该第一出单时长，将第一订单的第一指派时间调整为第二指派时间，该第二指派时间晚于第一指派时间；基于该第二指派时间，对该第一订单进行指派处理。
229.该实现方式中，第一指派时间和第二指派时间均为指派配送运力的时间，在出单时长延长后，服务器可以基于延长后的第一出单时长，延长第一订单的指派时间，基于延长后的指派时间，指派第一订单，这样可以减少过早指派导致的配送运力到达目标场所，而商家还未准备好订单情况的发生，降低配送运力的配送超时率。
230.在另一种可能的实现方式中，服务器可以基于该第一出单时长，向第三终端发送通知消息，该通知消息用于通知第一订单的预计送达时间，第三终端为用户使用的终端；接收第三终端基于通知消息发送的取消订单请求，获取第一订单的订单状态，为第三终端展示第一订单的订单状态，以使用户撤销该取消订单请求对应的取消操作。
231.该实现方式中，服务器可以基于延长后的第一出单时长向第三终端发送通知消息，若用户接收到该通知消息后，想要取消订单，通过第三终端向服务器发送取消订单请求。服务器基于该取消订单请求获取该订单的订单状态，第三终端展示该订单状态，以使用户撤销该取消订单请求对应的取消操作。
232.其中，第三终端可以在检测到取消订单界面的取消操作时，在取消订单界面的上层弹出提示消息，该提示消息中可以包括该订单的订单状态。例如，该提示消息为“商家正在出单，预计5分钟后开启调度配送运力，请您再耐心等待一下啦～”，该提示消息还可以包括“仍然退款”按钮和“再等等”按钮，当“再等等”按钮被触发时，说明用户撤销该取消操作，继续等待订单的配送，参见图17。
233.在另一种可能的实现方式中，若服务器接收到第二终端基于第一出单时长发送的转单请求，对第一订单进行转单处理，该转单请求用于请求将第一订单转给其他配送运力，第二终端为配送运力对应的终端。
234.该实现方式中，由于第一出单时长延长，可能会影响配送运力的配送业绩，因此，服务器还可以为配送运力对应的第二终端提供转单入口，当配送运力来不及配送该订单时，配送运力通过该转单入口将该订单转给其他配送运力进行配送。当服务器接收到第二终端基于该转单入口发送的转单请求时，可以将第一订单转给其他配送运力进行配送。
235.其中，服务器在进行转单时，可以确定第二终端待配送订单的第四数量，基于该第四数量，确定待配送订单的配送超时率，若配送超时率小于预设超时率，则可以直接在派单
池中发布该第一订单的订单信息，进行转单操作。若配送超时率大于预设超时率，则可以确定该第一订单的第一补贴资源数值，在该第一订单的第一资源数值的基础上增加第一补贴资源数值，得到第二资源数值，然后再发布该第一订单的订单信息，该订单信息中包括该第二资源数值，基于该第二资源数值进行转单操作，这样可以提高转单成功率。
236.其中，配送超时率包括第一配送超时率和第二配送超时率，服务器基于该第四数量，确定配送超时率的过程可以为：服务器基于第四数量，确定第四数量中超过第一预设配送时长的订单的第五数量，确定第五数量与第四数量的第一比值，将该第一比值作为第一配送超时率；或者，确定第五数量中超过第二预设配送时长的订单的第六数量，确定第六数量与第五数量的第二比值，将第二比值作为第二配送超时率，第二配送超时率大于第一配送超时率。
237.该实现方式中，服务器在配送运力待配送的订单中超时订单的数量较多时，或者在超时订单中超时严重的订单的数量较多时，才进行转单操作，从而避免配送运力为提高配送业绩盲目上报。
238.需要说明的一点是，若在预设时间内无其他配送运力接单，也即服务器没有将第一订单转出去，则还是由该配送运力配送该订单。
239.在另一种可能的实现方式中，若服务器基于第一出单时长，接收到第二终端发送的取消配送订单请求，服务器可以从第二终端的待配送订单中删除该第一订单，将该第一订单的订单信息重新添加至派单池中，重新指派其他配送运力。
240.该实现方式中，在出单时长延长时，配送运力还可以请求取消配送该第一订单。服务器接收该取消配送订单请求后，可以将该第一订单的订单信息重新添加至派单池中，然后基于第一出单时长，重新指派其他配送运力。
241.在另一种可能的实现方式中，服务器基于第一出单时长，对第一订单的配送时长进行调整，以使第二终端基于调整后的配送时长，对第一订单进行处理。
242.该实现方式可以通过以下步骤(1)至(3)实现，包括：
243.(1)服务器接收第二终端基于该第一出单时长发送的配送时长调整请求。
244.第二终端可以登录即时配送应用，展示即时配送应用的主界面，该主界面包括遇到问题入口，第二终端在检测到该遇到问题入口被触发时，从主界面跳转到订单处理界面。该订单处理界面包括上报入口，该上报入口用于在第一订单的物品未准备完成时，请求调整配送时长。第二终端在检测到该上报入口被触发时，向服务器发送配送时长调整请求。
245.(2)服务器基于该配送时长调整请求，获取第二终端当前的位置信息。
246.本步骤中，服务器可以通过以下任一实现方式获取第二终端当前的位置信息。
247.第一种实现方式，服务器对第二终端进行定位，得到定位信息；获取第二终端上传的图像数据，该图像数据包括配送运力和目标场所的合照图像；检测该图像数据中是否存在目标场所的门头数据，若检测到目标场所的门头数据，将定位信息和图像数据组成该位置信息。
248.该实现方式中，第二终端通过调用摄像组件来拍摄配送运力和商家门面的合照图像，当该商家门面有门头时，第二终端可以调用摄像组件来拍摄配送运力的人脸和商家门头的合照图像，该商家门头与第一订单中的店名一致。若商家门面因装修或其他因素导致该商家门面无门头，则第二终端可以调用摄像组件来拍摄配送运力和商家门面的外框架。
249.该实现方式中，服务器将定位信息和图像信息结合来判断第二终端是否处于目标场所，可以避免仅通过gps定位时存在定位误差，导致无法准确判断第二终端是否处于目标场所，也可以避免在商家门面无门头时仅通过合照图像也无法准确判断第二终端是否处于目标场所，从而提高确定第二终端位置信息的准确性。
250.需要说明的一点是，该合照图像仅可以调用摄像组件拍摄得到，而无法通过获取相册中预先存储的图像，这样可以避免配送运力上传预先存储的合照图像，提高合照图像获取的准确性。
251.第二种实现方式，服务器获取第二终端当前接入网络的网络信息，若该网络信息表示第二终端的当前接入网络为目标场所的网络，将目标场所的位置信息作为第二终端当前的位置信息。
252.该实现方式中，服务器向第二终端发送网络信息获取指令，第二终端接收该网络信息获取指令，获取当前接入网络的网络信息，向服务器发送当前接入网络的网络信息。其中，第二终端除了向服务器发送当前接入网络的网络信息，还可以发送目标场所的网络信息，服务器基于当前接入网络的网络信息和目标场所的网络信息，确定当前接入网络是否为目标场所的网络。或者，服务器中预先存储目标场所的网络信息，服务器接收第二终端发送的当前接入网络的网络信息后，可以直接确定当前接入网络的网络信息是否为目标场所的网络信息，也即当前接入网络是否为目标场所的网络。
253.该网络可以为wifi(wireless fidelity，无线保真)，也可以为蓝牙。在本技术实施例中，对此不作具体限定。由于wifi和蓝牙均有一定的传输距离，因此，通过第二终端连接的wifi或蓝牙是否为商家店内的wifi或蓝牙来确定第二终端是否处于目标场所，可以提高确定第二终端位置信息的准确性。
254.(3)若服务器基于该位置信息确定第二终端到达第一终端所在的目标场所，对第一订单的配送时长进行调整。
255.本步骤中，若服务器确定第二终端到达目标场所，可以确定配送延长时长，其中，服务器可以在当前的配送时长的基础上，增加该配送延长时长，得到调整后的配送时长，然后向第二终端发送该调整后的配送时长，以使配送运力基于调整后的配送时长，配送第一订单。或者，服务器也可以直接向第二终端发送配送延长时长。
256.在本技术实施例中，在商家出现卡单情况时，配送运力可以上报请求调整第一订单的配送时长，基于调整后的配送时长配送订单，这样可以避免由于商家未准备完成订单，而影响配送运力的配送超时率，从而降低配送运力的配送超时率。
257.在本技术实施例中，商家也可以对配送运力上报的信息进行申诉，进行双向验证，避免配送运力为提高配送业绩，盲目上报。该过程可以通过以下步骤(4)至(6)实现，包括：
258.(4)服务器确定第二终端上报配送时长调整请求的上报时间。
259.服务器可以确定接收到配送时长调整请求的接收时间，将该接收时间作为上报时间。
260.(5)服务器接收第一终端发送的验证请求，该验证请求包括第一订单的实际出单时间。
261.本步骤可以通过以下步骤(5
‑
1)至(5
‑
3)实现，包括：
262.(5
‑
1)第一终端获取服务器发送的调整消息，该调整消息为第二终端向服务器上
报请求调整第一订单配送时长的消息，且该调整消息中包括第二终端上报请求调整第一订单配送时长的上报时间。
263.服务器在基于配送时长调整请求确定上报时间后，可以向第一终端发送调整消息，该调整消息中携带该上报时间。
264.(5
‑
2)第一终端确定当前订单的实际出单时间。
265.本步骤中，第一终端可以获取出单完成入口被触发的时间，将该时间作为实际出单时间。或者，商家在每准备完成一个订单，通过调用摄像组件对该订单进行拍摄，得到订单图像，将拍摄该订单图像的时间作为实际出单时间。
266.(5
‑
3)若实际出单时间早于上报时间，响应于基于验证入口被触发的验证操作，向服务器发送验证请求。
267.若实际出单时间早于上报时间，说明配送运力上报时，商家已准备完成订单，商家可以通过触发已出单界面中该第一订单对应的验证入口向服务器发送验证请求，以使服务器对该第一订单的出单时间进行验证。
268.(6)若实际出单时间早于上报时间，服务器保持第一订单的配送时长不变。
269.服务器基于第一终端发送的实际出单时间和第二终端发送的上报时间，确定第二终端发送配送时长调整请求时，商家是否已准备完成订单，若实际出单时间早于上报时间，说明第二终端发送配送时长调整请求时，商家已准备完成订单，则服务器保持第一订单的配送时长不变。若实际出单时间晚于上报时间，说明第二终端发送配送时长调整请求时，商家未准备完成订单，这时服务器再调整第一订单的配送时长。
270.在本技术实施例中，商家更改运营信息后，会触发服务器进行相应调整。若至少一个运营信息中包括第一出单时长的时长信息，也即商家请求延长出单时长，则服务器会基于该第一出单时长进行预计送达时间的调整、压单时间也即指派时间的调整以及配送运力的配送时长的调整等。其中，服务器可以通过调度模型来进行上述调整，不同程度的出单慢商家，对应的调度模型不同，每个订单都会由调度模型进行合理估算并匹配相应的策略。比如，服务器监测到短时间单量激增场景之后，将会在一段时间内加大压单力度，延长指派时间和预计送达时间，使得在商家维度缓解出单压力。再如，服务器监测到突发大额订单场景，会相应延长该订单的压单时间，在商家出单后再指派配送运力来取单，以避免配送运力和商家出现冲突。
271.对于配送运力来说，在商家出单慢时，可以上报请求调整配送时长，或者将该订单转给其他配送运力或者取消配送该订单，从而降低由于商家出单满对其配送业绩的影响，降低配送超时率。
272.上述所有可选技术方案，可以采用任意结合形成本技术的可选实施例，在此不再一一赘述。
273.图18是本技术实施例提供的一种订单处理装置的示意图，由商家使用的第一终端执行，参见图18，该装置包括：
274.第一展示模块1801，用于展示卡单处理界面，卡单处理界面包括多个卡单处理选项，卡单处理选项用于触发更改商家的运营信息，运营信息用于表示商家在互联网平台中接受订单的运营模式；
275.第一获取模块1802，用于响应于基于至少一个卡单处理选项被触发的选择操作，
获取每个卡单处理选项对应的运营信息，得到至少一个运营信息；
276.处理模块1803，用于基于至少一个运营信息，对订单进行处理。
277.在一种可能的实现方式中，至少一个卡单处理选项包括降低接单量选项，运营信息包括配送范围信息或者物品信息；
278.处理模块1803，用于响应于基于降低接单量选项被触发的选择操作，向服务器发送配送范围缩小请求，配送范围缩小请求用于请求将当前的第一配送范围缩小为第二配送范围；接收服务器发送的第二配送范围对应的配送范围信息；或者，响应于基于降低接单量选项被触发的选择操作，向服务器发送撤销促销请求，撤销促销请求用于请求撤销正在进行促销的促销物品；接收服务器发送的撤销促销物品后的物品信息。
279.在另一种可能的实现方式中，至少一个卡单处理选项包括置休选项，运营信息包括商家的停业状态信息；
280.处理模块1803，用于响应于基于置休选项被触发的选择操作，向服务器发送营业状态调整请求，营业状态调整请求用于请求将当前的营业状态调整为停业状态；获取服务器发送的停业状态信息。
281.在另一种可能的实现方式中，至少一个卡单处理选项包括手动接单选项，运营信息包括手动接单模式的模式信息；
282.处理模块1803，用于响应于基于手动接单选项被触发的选择操作，向服务器发送接单模式调整请求，接单模式调整请求用于请求将自动接单模式调整为手动接单模式；接收服务器发送的手动接单模式的模式信息。
283.在另一种可能的实现方式中，至少一个卡单处理选项包括延长出单时长选项，运营信息包括第一出单时长的时长信息；
284.处理模块1803，用于响应于基于延长出单时长选项被触发的选择操作，向服务器发送出单时长延长请求，出单时长延长请求用于请求将当前的第二出单时长调整为第一出单时长；接收服务器发送的第一出单时长的时长信息。
285.在另一种可能的实现方式中，装置还包括：
286.第二获取模块，用于获取延长出单时长选项被触发后的生效时长；
287.恢复模块，用于响应于生效时长达到预设生效时长，自动将正在处理的订单的第一出单时长恢复为第二出单时长；
288.恢复模块，还用于响应于生效时长未达到预设生效时长，检测到恢复操作时或接收到服务器发送的恢复指令时，将正在处理的订单的第一出单时长恢复为第二出单时长。
289.在另一种可能的实现方式中，装置还包括：
290.第三获取模块，用于获取服务器发送的调整消息，调整消息为第二终端向服务器上报请求调整第一订单配送时长的消息，且调整消息中包括第二终端上报请求调整第一订单配送时长的上报时间，第二终端为配送运力对应的终端；
291.第四确定模块，用于确定第一订单的实际出单时间；
292.第二发送模块，用于若实际出单时间早于上报时间，响应于基于验证入口被触发的验证操作，向服务器发送验证请求，以使服务器对第一订单的出单时间进行验证。
293.本技术实施例提供了一种订单处理装置，在出现卡单情况时，通过选择卡单处理界面的至少一个卡单处理选项，来更改商家在互联网平台接受订单的运营模式对应的运营
信息，这样商家就可以基于更改后的运营信息对订单进行处理，以此来缓解商家当前出现的卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
294.图19是本技术实施例提供的一种订单处理方法的流程图，由服务器执行，参见图19，该方法由服务器执行，该方法包括：
295.第一接收模块1901，用于接收第一终端发送的卡单处理请求，卡单处理请求携带被选择的至少一个卡单处理选项，至少一个卡单处理选项用于触发更改商家的运营信息，运营信息用于表示商家在互联网平台接受订单的运营模式，第一终端为商家使用的终端；
296.第一确定模块1902，用于确定每个卡单处理选项对应的运营信息，得到至少一个运营信息；
297.第一发送模块1903，用于向第一终端发送至少一个运营信息，以使第一终端基于至少一个运营信息，对订单进行处理。
298.在一种可能的实现方式中，至少一个卡单处理选项包括延长出单时长选项，运营信息包括第一出单时长的时长信息；
299.装置还包括：
300.第一调整模块，用于基于第一出单时长，将第一订单的第一指派时间调整为第二指派时间，第二指派时间晚于第一指派时间；基于第二指派时间，对第一订单进行指派处理；或者，
301.第三发送模块，用于基于第一出单时长，向第三终端发送通知消息，通知消息用于通知第一订单的预计送达时间，第三终端为用户使用的终端；接收第三终端基于通知消息发送的取消订单请求，获取第一订单的订单状态，向第三终端发送第一订单的订单状态，以使用户撤销取消订单请求对应的取消操作；或者，
302.转单模块，用于若接收到第二终端基于第一出单时长发送的转单请求，对第一订单进行转单处理，转单请求用于请求将第一订单转给其他配送运力，第二终端为配送运力对应的终端；或者，
303.第二调整模块，用于基于第一出单时长，对第一订单的配送时长进行调整，以使第二终端基于调整后的配送时长，对第一订单进行处理。
304.在另一种可能的实现方式中，第二调整模块，用于接收第二终端基于第一出单时长发送的配送时长调整请求；基于配送时长调整请求，获取第二终端当前的位置信息；若基于位置信息确定第二终端到达第一终端所在的目标场所，对第一订单的配送时长进行调整。
305.在另一种可能的实现方式中，装置还包括：
306.第五确定模块，用于确定第二终端上报配送时长调整请求的上报时间；
307.第二接收模块，用于接收第一终端发送的验证请求，验证请求包括第一订单的实际出单时间；
308.保持模块，用于若实际出单时间早于上报时间，保持第一订单的配送时长不变。
309.在另一种可能的实现方式中，装置还包括：
310.第七确定模块，用于确定预设历史时间范围内商家的准时出单率；
311.第三调整模块，用于若准时出单率小于预设准时出单率，将商家的营业状态强制
调整为停业状态。
312.本技术实施例提供了一种订单处理装置，接收商家使用的第一终端发送的卡单处理请求，基于该卡单处理请求更改该商家在互联网平台接受订单的运营模式对应的运营信息，然后向该第一终端发送更改后的运营信息，这样商家就可以基于更改后的运营信息对订单进行处理，以此来缓解商家当前出现的卡单情况，这样可以避免由于卡单情况影响配送运力的配送业绩，从而降低配送运力的配送超时率。
313.需要说明的是：上述实施例提供的订单处理装置在处理订单时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将第一终端或服务器的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的订单处理装置与订单处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
314.图20示出了本技术一个示例性实施例提供的终端2000的结构框图。该终端2000可以是：智能手机、平板电脑、mp3播放器(moving picture experts group audio layer iii，动态影像专家压缩标准音频层面3)、mp4(moving picture experts group audio layer iv，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端2000还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。
315.通常，终端2000包括有：处理器2001和存储器2002。
316.处理器2001可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器2001可以采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器2001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器2001可以在集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器2001还可以包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
317.存储器2002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器2002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器2002中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器2001所执行以实现本技术中方法实施例提供的订单处理方法。
318.在一些实施例中，终端2000还可选包括有：外围设备接口2003和至少一个外围设备。处理器2001、存储器2002和外围设备接口2003之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口2003相连。具体地，外围设备包括：射频电路2004、触摸显示屏2005、摄像头组件2006、音频电路2007、定位组件2008和电源2009中的至少一种。
319.外围设备接口2003可被用于将i/o(input/output，输入/输出)相关的至少一个外围设备连接到处理器2001和存储器2002。在一些实施例中，处理器2001、存储器2002和外围
based service，基于位置的服务)。定位组件2008可以是基于美国的gps(global positioning system，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。
325.电源2009用于为终端2000中的各个组件进行供电。电源2009可以是交流电、直流电、一次性电池或可充电电池。当电源2009包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。
326.在一些实施例中，终端2000还包括有一个或多个传感器2010。该一个或多个传感器2010包括但不限于：加速度传感器2011、陀螺仪传感器2012、压力传感器2013、指纹传感器2014、光学传感器2015以及接近传感器2016。
327.加速度传感器2011可以检测以终端2000建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器2011可以用于检测重力加速度在三个坐标轴上的分量。处理器2001可以根据加速度传感器2011采集的重力加速度信号，控制触摸显示屏2005以横向视图或纵向视图进行用户界面的显示。加速度传感器2011还可以用于游戏或者用户的运动数据的采集。
328.陀螺仪传感器2012可以检测终端2000的机体方向及转动角度，陀螺仪传感器2012可以与加速度传感器2011协同采集用户对终端2000的3d动作。处理器2001根据陀螺仪传感器2012采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变ui)、拍摄时的图像稳定、游戏控制以及惯性导航。
329.压力传感器2013可以设置在终端2000的侧边框和/或触摸显示屏2005的下层。当压力传感器2013设置在终端2000的侧边框时，可以检测用户对终端2000的握持信号，由处理器2001根据压力传感器2013采集的握持信号进行左右手识别或快捷操作。当压力传感器2013设置在触摸显示屏2005的下层时，由处理器2001根据用户对触摸显示屏2005的压力操作，实现对ui界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。
330.指纹传感器2014用于采集用户的指纹，由处理器2001根据指纹传感器2014采集到的指纹识别用户的身份，或者，由指纹传感器2014根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器2001授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器2014可以被设置终端2000的正面、背面或侧面。当终端2000上设置有物理按键或厂商logo时，指纹传感器2014可以与物理按键或厂商logo集成在一起。
331.光学传感器2015用于采集环境光强度。在一个实施例中，处理器2001可以根据光学传感器2015采集的环境光强度，控制触摸显示屏2005的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏2005的显示亮度；当环境光强度较低时，调低触摸显示屏2005的显示亮度。在另一个实施例中，处理器2001还可以根据光学传感器2015采集的环境光强度，动态调整摄像头组件2006的拍摄参数。
332.接近传感器2016，也称距离传感器，通常设置在终端2000的前面板。接近传感器2016用于采集用户与终端2000的正面之间的距离。在一个实施例中，当接近传感器2016检测到用户与终端2000的正面之间的距离逐渐变小时，由处理器2001控制触摸显示屏2005从亮屏状态切换为息屏状态；当接近传感器2016检测到用户与终端2000的正面之间的距离逐
渐变大时，由处理器2001控制触摸显示屏2005从息屏状态切换为亮屏状态。
333.本领域技术人员可以理解，图20中示出的结构并不构成对终端2000的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
334.图21是本技术实施例提供的一种服务器2100的结构示意图，该服务器2100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，cpu)2101和一个或一个以上的存储器2102，其中，该存储器2102中存储有至少一条指令，该至少一条指令由该处理器2101加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器2100还可以包括其他用于实现设备功能的部件，在此不做赘述。
335.在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由终端或服务器中的处理器执行以完成上述实施例中订单处理方法。例如，该计算机可读存储介质可以是rom、随机存取存储器(ram)、cd
‑
rom、磁带、软盘和光数据存储设备等。
336.在一些实施例中，本技术实施例所涉及的计算机程序可被部署在一个计算机设备上执行，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链系统。
337.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
338.以上所述仅为本技术的可选实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。