技术领域
[0001] 本申请涉及互联网应用技术领域,尤其涉及一种商品加购方法和装置、电子设备及存储介质。
相关背景技术
[0002] 在人们的日常生活中,通过线上选购商品,然后下单来购买商品,已经成为人们日常生活的一部分。在实际场景中,用户下单购买商品后,可能存在需要增加其它商品的情况,这种情况下需要重新下单,效率较低,对用户体验十分不友好。
[0003] 以外卖场景为例,在订外卖时,有时因为少点餐品需要增加时,需要整单取消重新下单,或者致电商家沟通协商。例如,用户在点烤鸭时,下完单,发现配料少点了,需要加购一份,目前需要整单取消重新下单,或者致电商家沟通协商支付方式进行加购,效率较低。因此,亟需解决这一技术问题。
具体实施方式
[0101] 下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例,然而应当理解,可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本申请,并且能够将本申请的范围完整的传达给本领域的技术人员。
[0102] 需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”及其变体要被解读为意味着“包括但不限于”的开放式术语。
[0103] 如前文介绍,目前在实际场景中,用户下单购买商品后,可能存在需要增加其它商品的情况,这种情况下需要重新下单,效率较低,对用户体验十分不友好。为了解决这一技术问题,本申请实施例提供了一种商品加购方法,可以应用于用户客户端,例如智能手机、平板电脑、智能手表等终端设备的客户端。如图1所示,该应用于用户客户端的商品加购方法可以包括以下步骤S101至S105:
[0104] 步骤S101,用户客户端响应于订单信息的查询指令,获取订单的当前状态;
[0105] 步骤S102,用户客户端判断订单的当前状态是否为满足商品加购条件的状态,若是,则继续执行步骤S103;
[0106] 步骤S103,用户客户端生成订单的包括加购入口的信息页面;
[0107] 步骤S104,用户客户端响应于对加购入口的触发操作,向服务器发送获取订单的可追加商品信息的请求,接收服务器返回的订单的可追加商品信息,并展示;
[0108] 步骤S105,用户客户端响应于在展示有订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车。
[0109] 本申请实施例可以在订单的当前状态为满足商品加购条件的状态时,生成订单的包括加购入口的信息页面,这样用户可以通过加购入口的信息页面进行商品加购,无需整单取消重新下单或者致电商家沟通协商,提高了购买商品的效率,提升了用户购买商品的体验。
[0110] 本申请实施例中提供了一种可能的实现方式,上面步骤S101用户客户端响应于订单信息的查询指令,获取订单的当前状态,具体可以包括以下步骤A1或者步骤A2:
[0111] 步骤A1,用户客户端响应于订单信息的查询指令,向服务器发送获取订单的当前状态的请求,接收服务器返回的订单的当前状态;
[0112] 步骤A2,用户客户端响应于订单信息的查询指令,获取用户客户端本地的来自服务器推送的订单的当前状态。
[0113] 本实施例用户客户端可以获取实时的订单的当前状态,以便于准确地判断订单的当前状态是否为满足商品加购条件的状态。
[0114] 本申请实施例中提供了一种可能的实现方式,上面步骤S102提及的满足商品加购条件的状态可以是配送资源取货之前的状态;而配送资源取货之后的状态,即不满足商品加购条件的状态。
[0115] 以外卖订单为例,整个订单的状态可以包括订单已提交、支付成功、商家已接单、配送资源已接单、配送资源已到店、配送资源已取货、商品已送达、订单已完成等状态,那么,可以将订单已提交、支付成功、商家已接单、配送资源已接单、配送资源已到店这些状态作为满足商品加购条件的状态;将配送资源已取货、商品已送达、订单已完成这些状态作为不满足商品加购条件的状态。需要说明的是,此处列举仅是示意性的,并不对本实施例进行限制。
[0116] 本申请实施例中提供了一种可能的实现方式,上面步骤S102中用户客户端判断订单的当前状态是否为满足商品加购条件的状态,如果订单的当前状态为不满足商品加购条件的状态,则可以执行下列步骤B1至B3中任意一项:
[0117] 步骤B1,用户客户端生成订单的未包括加购入口的信息页面;
[0118] 步骤B2,用户客户端删除订单的信息页面的加购入口;
[0119] 步骤B3,用户客户端将订单的信息页面的加购入口变灰,以表示无法对加购入口进行触发操作。
[0120] 本实施例中,如果订单的当前状态为不满足商品加购条件的状态,则可以执行相应的操作,以使得无法进行商品加购,保证订单的准确配送。
[0121] 本申请实施例中提供了一种可能的实现方式,在步骤S105用户客户端响应于在展示有订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车的过程中,还可以包括以下步骤C1和C2:
[0122] 步骤C1,用户客户端监控订单的当前状态;
[0123] 步骤C2,若订单的当前状态从满足商品加购条件的状态进入到不满足商品加购条件的状态,则用户客户端生成表示无法加购商品的提示信息,并将加购购物车页面的提交按键变灰,以表示无法加购商品。
[0124] 本实施例可以在将加购商品保存到加购购物车的过程中,用户客户端监控订单的当前状态,若订单的当前状态从满足商品加购条件的状态进入到不满足商品加购条件的状态,则生成表示无法加购商品的提示信息,并将加购购物车页面的提交按键变灰,以表示无法加购商品,保证订单的准确配送。
[0125] 本申请实施例中提供了一种可能的实现方式,上面步骤C1用户客户端监控订单的当前状态,具体可以包括以下步骤C11或者C12:
[0126] 步骤C11,用户客户端按照预设周期向服务器发送获取订单的当前状态的请求,接收服务器返回的订单的当前状态;或者
[0127] 步骤C12,用户客户端监控用户客户端本地的来自服务器推送的订单的当前状态。
[0128] 本实施例用户客户端可以获取实时的订单的当前状态,以便于准确地判断订单的当前状态是否为满足商品加购条件的状态。
[0129] 本申请实施例中提供了一种可能的实现方式,在步骤S105用户客户端响应于在展示有订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车之后,还可以包括以下步骤D1至D4:
[0130] 步骤D1,用户客户端响应于对加购购物车中的加购商品的结算指令,获取订单的当前状态;
[0131] 步骤D2,用户客户端判断订单的当前状态是否为满足商品加购条件的状态;若是,则继续执行步骤D3;若否,则继续执行步骤D4;
[0132] 步骤D3,用户客户端向服务器发送订单的包括加购商品的结算请求,接收服务器返回的结算响应信息;
[0133] 步骤D4,用户客户端生成表示无法加购商品的提示信息。
[0134] 本实施例用户客户端可以在结算时,继续判断订单的当前状态是否为满足商品加购条件的状态,进而根据不同的状态执行相应的操作,保证订单的准确和高效配送。
[0135] 本申请实施例中提供了一种可能的实现方式,步骤D3中提及的结算响应信息中可以包括基于加购商品重新计算得到的配送时间和配送费用,这样清晰地展示结算响应信息,以便用户根据结算响应信息确定是否进一步下单,保证订单的准确和高效配送。
[0136] 本申请实施例中提供了一种可能的实现方式,上面步骤D3中用户客户端接收服务器返回的结算响应信息之后,还可以包括以下步骤F1至F4:
[0137] 步骤F1,用户客户端响应于对加购商品的确认下单指令,获取订单的当前状态;
[0138] 步骤F2,用户客户端判断订单的当前状态是否为满足商品加购条件的状态;若是,则继续执行步骤F3;若否,则继续执行步骤F4;
[0139] 步骤F3,用户客户端向服务器发送订单的包括加购商品的确认下单请求,接收服务器返回的订单的加购信息。
[0140] 步骤F4,用户客户端生成表示无法加购商品的提示信息。
[0141] 本实施例用户客户端可以在确认下单时,继续判断订单的当前状态是否为满足商品加购条件的状态,进而根据不同的状态执行相应的操作,保证订单的准确和高效配送。
[0142] 基于同一发明构思,本实施例还提供了一种商品加购方法,可以应用于服务器。如图2所示,该应用于服务器的商品加购方法可以包括以下步骤S201至S202:
[0143] 步骤S201,服务器接收来自用户客户端的获取订单的可追加商品信息的请求,根据订单的订单信息确定可追加商品信息;
[0144] 步骤S202,服务器向用户客户端返回订单的可追加商品信息。
[0145] 本实施例中,可追加商品信息可以是非时效类的商品信息,即已经制作完成的商品的商品信息,如日用品等;也可以是时效类的商品信息,即未制作完成的商品的商品信息,如炒菜、西红柿鸡蛋面等。需要说明的是,此处列举仅是示意性的,并不对本实施例进行限制。
[0146] 本实施例服务器可以向用户客户端返回订单的可追加商品信息,这样用户客户端的用户可以在展示有订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车,无需整单取消重新下单或者致电商家沟通协商,提高了购买商品的效率,提升了用户购买商品的体验。
[0147] 本申请实施例中提供了一种可能的实现方式,服务器还可以接收来自用户客户端的获取订单的当前状态的请求,查询订单的当前状态;进而向用户客户端返回订单的当前状态。本实施例用户客户端可以获取实时的订单的当前状态,以便于准确地判断订单的当前状态是否为满足商品加购条件的状态。
[0148] 本申请实施例中提供了一种可能的实现方式,服务器还可以接收来自用户客户端的订单的包括加购商品的结算请求,基于加购商品重新计算得到配送时间和配送费用,并生成结算响应信息;向用户客户端返回结算响应信息。这样,用户客户端可以清晰地展示结算响应信息,以便用户根据结算响应信息确定是否进一步下单,保证订单的准确和高效配送。
[0149] 本申请实施例中提供了一种可能的实现方式,服务器还可以接收来自用户客户端的订单的包括加购商品的确认下单请求,执行下单操作,并生成订单的加购信息;将订单的加购信息推送给商户客户端和/或配送客户端。这样,用户客户端、商户客户端或者配送客户端,能够及时准确获取到订单的信息,保证订单的准确和高效配送。
[0150] 以上介绍了图1和图2所示实施例的各个环节的多种实现方式,下面将结合用户客户端和服务器通过具体实施例对本申请实施例的商品加购方法做进一步说明。
[0151] 图3示出了本申请实施例提供的应用于用户客户端和服务器的商品加购方法的流程图;如图3所示,该应用于用户客户端和服务器的商品加购方法可以包括以下步骤S301和S308:
[0152] 步骤S301,用户客户端响应于订单信息的查询指令,获取订单的当前状态。该步骤具体可以通过前文的步骤A1或者步骤A2来实现,此处不再详细赘述。
[0153] 步骤S302,用户客户端判断订单的当前状态是否为满足商品加购条件的状态,若是,则继续执行步骤S303。
[0154] 该步骤中,如果订单的当前状态为不满足商品加购条件的状态,则用户客户端生成订单的未包括加购入口的信息页面,或者用户客户端删除订单的信息页面的加购入口,或者用户客户端将订单的信息页面的加购入口变灰,以表示无法对加购入口进行触发操作。
[0155] 步骤S303,用户客户端生成订单的包括加购入口的信息页面。
[0156] 如图4所示,在订单的信息页面41上包括加购入口42。
[0157] 步骤S304,用户客户端响应于对加购入口的触发操作,向服务器发送获取订单的可追加商品信息的请求。
[0158] 步骤S305,服务器接收来自用户客户端的获取订单的可追加商品信息的请求,根据订单的订单信息确定可追加商品信息。
[0159] 步骤S306,服务器向用户客户端返回订单的可追加商品信息。
[0160] 步骤S307,用户客户端接收服务器返回的订单的可追加商品信息,并展示。
[0161] 如图5所示,订单的可追加商品信息页面51,展示有订单的可追加商品信息52和对应的加购按钮“加购”53,当触发相应的加购按钮后,可以加购对应的可追加商品信息。在实际场景中,订单的可追加商品信息页面51可以置于订单的信息页面41的最上方,可以以弹窗的形式,方便用户进行加购操作。
[0162] 步骤S308,用户客户端响应于在展示有订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车。
[0163] 在将加购商品保存到加购购物车的过程中,还可以包括步骤C1和C2,可以参见前文介绍,此处不再赘述。
[0164] 在将加购商品保存到加购购物车之后,还可以包括步骤D1至D4,也可以参见前文介绍,此处不再赘述。
[0165] 本实施例结合用户客户端和服务器,可以在订单的当前状态为满足商品加购条件的状态时,生成订单的包括加购入口的信息页面,这样用户可以通过加购入口的信息页面进行商品加购,无需整单取消重新下单或者致电商家沟通协商,提高了购买商品的效率,提升了用户购买商品的体验。
[0166] 需要说明的是,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。实际应用中,上述所有可能的实施方式可以采用结合的方式任意组合,形成本申请的可能的实施例,在此不再一一赘述。
[0167] 基于上文各个实施例提供的商品加购方法,基于同一发明构思,本申请实施例还提供了一种商品加购装置。
[0168] 图6是本申请实施例提供的应用于用户客户端的商品加购装置的结构图。如图6所示,该应用于用户客户端的商品加购装置具体可以包括获取模块610、判断模块620、生成模块630、展示模块640以及加购模块650。
[0169] 获取模块610,用于响应于订单信息的查询指令,获取订单的当前状态;
[0170] 判断模块620,用于判断所述订单的当前状态是否为满足商品加购条件的状态;
[0171] 生成模块630,用于若所述订单的当前状态为满足商品加购条件的状态,则生成所述订单的包括加购入口的信息页面;
[0172] 展示模块640,用于响应于对加购入口的触发操作,向服务器发送获取所述订单的可追加商品信息的请求,接收服务器返回的所述订单的可追加商品信息,并展示;
[0173] 加购模块650,用于响应于在展示有所述订单的可追加商品信息的页面,对可追加商品的加购操作,将加购商品保存到加购购物车。
[0174] 本申请实施例中提供了一种可能的实现方式,所述获取模块610还用于:
[0175] 响应于订单信息的查询指令,向服务器发送获取订单的当前状态的请求,接收服务器返回的所述订单的当前状态;或者
[0176] 响应于订单信息的查询指令,获取用户客户端本地的来自服务器推送的订单的当前状态。
[0177] 本申请实施例中提供了一种可能的实现方式,所述生成模块630还用于:
[0178] 生成所述订单的未包括加购入口的信息页面;
[0179] 删除所述订单的信息页面的加购入口;
[0180] 将所述订单的信息页面的加购入口变灰,以表示无法对加购入口进行触发操作。
[0181] 本申请实施例中提供了一种可能的实现方式,所述商品加购条件的状态包括配送资源取货之前的状态。
[0182] 本申请实施例中提供了一种可能的实现方式,如图7所示,上文图6展示的装置还可以包括监控模块710,用于:
[0183] 在将加购商品保存到加购购物车的过程中,监控所述订单的当前状态;
[0184] 若所述订单的当前状态从满足商品加购条件的状态进入到不满足商品加购条件的状态,则生成表示无法加购商品的提示信息,并将加购购物车页面的提交按键变灰,以表示无法加购商品。
[0185] 本申请实施例中提供了一种可能的实现方式,所述监控模块710还用于:
[0186] 按照预设周期向服务器发送获取所述订单的当前状态的请求,接收服务器返回的所述订单的当前状态;或者
[0187] 监控用户客户端本地的来自服务器推送的所述订单的当前状态。
[0188] 本申请实施例中提供了一种可能的实现方式,如图7所示,上文图6展示的装置还可以包括加购结算模块720,用于:
[0189] 响应于对加购购物车中的加购商品的结算指令,获取所述订单的当前状态;
[0190] 判断所述订单的当前状态是否为满足商品加购条件的状态;
[0191] 若所述订单的当前状态为满足商品加购条件的状态,则向服务器发送所述订单的包括加购商品的结算请求,接收服务器返回的结算响应信息;
[0192] 若所述订单的当前状态为不满足商品加购条件的状态,则生成表示无法加购商品的提示信息。
[0193] 本申请实施例中提供了一种可能的实现方式,所述结算响应信息包括基于加购商品重新计算得到的配送时间和配送费用。
[0194] 本申请实施例中提供了一种可能的实现方式,如图7所示,上文图6展示的装置还可以包括加购下单模块730,用于:
[0195] 在接收服务器返回的结算响应信息之后,响应于对加购商品的确认下单指令,获取所述订单的当前状态;
[0196] 判断所述订单的当前状态是否为满足商品加购条件的状态;
[0197] 若所述订单的当前状态为满足商品加购条件的状态,则向服务器发送所述订单的包括加购商品的确认下单请求,接收服务器返回的所述订单的加购信息。
[0198] 图8是本申请实施例提供的应用于服务器的商品加购装置的结构图。如图8所示,该应用于服务器的商品加购装置具体可以包括确定模块810和发送模块820。
[0199] 确定模块810,用于接收来自用户客户端的获取订单的可追加商品信息的请求,根据所述订单的订单信息确定可追加商品信息;
[0200] 发送模块820,用于向用户客户端返回所述订单的可追加商品信息。
[0201] 本申请实施例中提供了一种可能的实现方式,如图9所示,上文图8展示的装置还可以包括查询模块910,用于接收来自用户客户端的获取所述订单的当前状态的请求,查询所述订单的当前状态;
[0202] 所述发送模块820,还用于向用户客户端返回所述订单的当前状态。
[0203] 本申请实施例中提供了一种可能的实现方式,如图9所示,上文图8展示的装置还可以包括第一生成模块920,用于接收来自用户客户端的所述订单的包括加购商品的结算请求,基于加购商品重新计算得到配送时间和配送费用,并生成结算响应信息;
[0204] 所述发送模块820,还用于向用户客户端返回所述结算响应信息。
[0205] 本申请实施例中提供了一种可能的实现方式,如图9所示,上文图8展示的装置还可以包括第二生成模块930,用于接收来自用户客户端的所述订单的包括加购商品的确认下单请求,执行下单操作,并生成所述订单的加购信息;
[0206] 所述发送模块820,还用于将所述订单的加购信息推送给商户客户端和/或配送客户端。
[0207] 基于同一发明构思,本申请实施例还提供了一种电子设备,包括处理器和存储器,存储器中存储有计算机程序,处理器被设置为运行计算机程序以执行上述任意一个实施例的应用于用户客户端的商品加购方法或者应用于服务器的商品加购方法。
[0208] 基于同一发明构思,本申请实施例还提供了一种存储介质,该存储介质中存储有计算机程序,其中,计算机程序被设置为运行时执行上述任意一个实施例的应用于用户客户端的商品加购方法或者应用于服务器的商品加购方法。
[0209] 所属领域的技术人员可以清楚地了解到,上述描述的系统、装置、模块的具体工作过程,可以参考前述方法实施例中的对应过程,为简洁起见,在此不另赘述。
[0210] 本领域普通技术人员可以理解:本申请的技术方案本质上或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,其包括若干程序指令,用以使得一电子设备(例如个人计算机,服务器,或者网络设备等)在运行所述程序指令时执行本申请各实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
[0211] 或者,实现前述方法实施例的全部或部分步骤可以通过程序指令相关的硬件(诸如个人计算机,服务器,或者网络设备等的电子设备)来完成,所述程序指令可以存储于一计算机可读取存储介质中,当所述程序指令被电子设备的处理器执行时,所述电子设备执行本申请各实施例所述方法的全部或部分步骤。
[0212] 以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:在本申请的精神和原则之内,其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案脱离本申请的保护范围。