CN112581228B - 一种多维线上下单方法、装置和系统 - Google Patents

Abstract

本发明涉及一种多维线上下单方法、装置和系统，获取购物对象的订单请求；判断所述订单请求中的产品类型，若所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；若所述产品类型判定为第二类产品，则将所述订单请求发送至业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。本发明实现了多维化的线上下单方式，包括客户自主下单和代客下单，购物效率高，同时满足客户和业务员不同的业务需求，方便业务员拓展新的业务线，提升了客户的购物体验。

Description

一种多维线上下单方法、装置和系统

技术领域

本发明涉及电子商务技术领域，尤其涉及一种多维线上下单方法、装置和系统。

背景技术

随着移动互联网技术的发展，目前很多企业以互联网为依托，通过运用大数据、人工智能等先进技术手段，对产品的零售和批发等过程进行升级改造，为顾客带来了线上购物的新型购物模式，提高客户购物的便利性。

然而，某些行业的产品包括无限制流通产品（也称为普通产品）和控销产品，控销产品是需要根据行业相关的流通规则设定控销数量的产品，例如药品行业，包括普药和控销药品两类。目前的线上购物方式，普通产品可以作为购物系统的自营商品，客户自行下单购买，客户所有的购买需求，需自行完成，购买方式单一；在购买控销产品时，通常是产品厂商直接入驻购物系统，作为购物系统的店铺，产品厂商同样不能帮助客户下单，且需客户自行和产品厂商进行沟通后再进行购买，沟通过程繁琐，效率差，极大地影响了客户的购物体验。

发明内容

本发明所要解决的技术问题是针对上述现有技术的不足，提供一种多维线上下单方法、装置和系统，既支持客户线上自主下单购买普通产品，又能通过业务员帮助客户，采取代客下单的方式购买控销产品，符合控销原则，避免了产品滥买的现象，省去了产品厂商与客户之间的繁琐沟通过程，提升了客户的购物体验。

本发明解决上述技术问题的技术方案如下：

一种药品多维线上下单方法，包括以下步骤：

获取购物对象的订单请求；

判断所述订单请求中的产品类型，若所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

若所述产品类型判定为第二类产品，则将所述订单请求发送至业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

依据本发明的另一方面，还提供了一种多维线上下单装置，应用于本发明中的多维线上下单方法中，包括请求获取模块、判断模块、第一订单生成模块和第二订单生成模块；

所述请求获取模块，用于获取购物对象的订单请求；

所述判断模块，用于判断所述订单请求中的产品类型；

所述第一订单生成模块，用于若所述判断模块将所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

所述第二订单生成模块，用于若所述判断模块将所述产品类型判定为第二类产品，则将所述订单请求发送至业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

依据本发明的另一方面，还提供了一种多维线上下单系统，包括客户端、业务端以及本发明中的多维线上下单平台，所述多维线上下单平台分别与所述客户端和所述业务端通信连接；

所述客户端，用于向所述多维线上下单平台发送购物对象的订单请求；

所述多维线上下单平台，用于接收所述订单请求，并判断所述订单请求中的产品类型，当所述产品类型判定为第一类产品时，根据所述订单请求生成第一类订单；当所述产品类型判定为第二类产品时，将所述订单请求发送至所述业务端；

所述业务端，用于当所述产品类型判定为第二类产品时，接收所述多维线上下单平台发送的所述订单请求，并根据所述订单请求生成待确认订单请求，将所述待确认订单请求发送至所述多维线上下单平台；

所述多维线上下单平台，还用于将所述待确认订单请求发送至所述客户端；

所述客户端，还用于接收所述多维线上下单平台发送的所述待确认订单请求，根据所述待确认订单请求生成确认信息，并提供给所述多维线上下单平台；

所述多维线上下单平台，还用于当接收到所述客户端发送的所述确认信息时，根据所述待确认订单请求生成第二类订单；当未接收到所述客户端发送的所述确认信息时，生成下单失败信息。

本发明的多维线上下单方法、平台和系统的有益效果是：首先获取客户端提供的购物对象的订单请求，该订单请求通常会包含产品基本信息，包括产品类型、产品数量等，若产品类型是第一类产品（具体为无需进行管控的普通产品），可以直接根据第一类产品生成对应的第一类订单，该第一类订单可以直接进入支付流程并上传到后台服务器，进入财务审核流程和出货流程，实现客户自主下单；若产品类型是第二类产品（具体指需要产品厂商管控的控销产品），则需要将订单请求发送至业务端，而业务端通常是产品厂商授权的业务员，可以根据订单请求和相关的管控规则生成与订单请求匹配的待确认订单请求，再反馈至购物对象（即客户端），当接收到购物对象根据待确认订单请求生成的确认信息，说明该待确认订单请求通过了客户的审核，符合客户的需求，则根据待确认订单请求生成第二类订单；该第二类订单同样可以进入支付流程并上传到后台服务器，进入财务审核流程和出货流程，进而实现代客下单；

本发明中的多维线上下单方法、平台和系统，既支持客户线上自主下单购买普通产品，又能通过业务员帮助客户，采取代客下单的方式购买控销产品，符合控销原则，避免了产品滥买的现象，省去了产品厂商与客户之间的繁琐沟通过程，购物效率高，提升了客户的购物体验；多维化的线上下单方式，同时满足客户和业务员的业务需求，在满足客户的个性化需求之外，方便业务员拓展新的业务线，尤其适用于具有严格控销原则的药品行业。

附图说明

图1为本发明实施例一中一种多维线上下单方法的流程示意图；

图2为本发明实施例一中将订单请求发送至业务端的流程示意图；

图3为本发明实施例二中一种多维线上下单装置的结构示意图；

图4为本发明实施例二中另一种多维线上下单装置的结构示意图；

图5为本发明实施例三中一种多维线上下单系统的结构示意图；

图6为本发明实施例三中另一种多维线上下单系统的结构示意图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

下面结合附图，对本发明进行说明。

实施例一、如图1所示，一种多维线上下单方法，包括以下步骤：

S1：获取购物对象的订单请求；

S2：判断所述订单请求中的产品类型，若所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

S3：若所述产品类型判定为第二类产品，则将所述订单请求发送至业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

首先获取客户端提供的购物对象的订单请求，该订单请求通常会包含产品基本信息，包括产品类型、产品数量等，若产品类型是第一类产品（具体为无需进行管控的普通产品），可以直接根据第一类产品生成对应的第一类订单，该第一类订单可以直接进入支付流程并上传到后台服务器，进入财务审核流程和出货流程，实现客户自主下单；若产品类型是第二类产品（具体指需要产品厂商管控的控销产品），则需要将订单请求发送至业务端，而业务端通常是产品厂商授权的业务员，可以根据订单请求和相关的管控规则生成与订单请求匹配的待确认订单请求，再反馈至购物对象（即客户端），当接收到购物对象根据待确认订单请求生成的确认信息，说明该待确认订单请求通过了客户的审核，符合客户的需求，则根据待确认订单请求生成第二类订单；该第二类订单同样可以进入支付流程并上传到后台服务器，进入财务审核流程和出货流程，进而实现代客下单；

本实施例中的多维线上下单方法，既支持客户线上自主下单购买普通产品，又能通过业务员帮助客户，采取代客下单的方式购买控销产品，符合控销原则，避免了产品滥买的现象，省去了产品厂商与客户之间的繁琐沟通过程，购物效率高，提升了客户的购物体验；多维化的线上下单方式，同时满足客户和业务员的业务需求，在满足客户的个性化需求之外，方便业务员拓展新的业务线，尤其适用于具有严格控销原则的药品行业。

具体地，本实施例应用到药品行业，根据药品管控的相关规则，本实施例中第一类产品品具体为无需进行管控的普药，第二类产品具体指需要药品厂商管控的控销药品。

优选地，在S1之前，还包括以下步骤：

S0：获取所述购物对象的客户资料，并根据所述客户资料对所述购物对象进行身份验证，若验证通过，则获取所述购物对象的所述订单请求；若验证不通过，则生成客户验证失败信息并反馈至所述购物对象。

由于客户或购物对象在实现自主下单和交由业务员实现代客下单时，一方面为避免出现客户滥买、恶意采购等现象，另一方面为便于后续分配业务员进行代客下单，均需要通过验证客户资料，保证客户或购物对象是平台中已经注册过的用户；同时，由于客户资料中通常包含客户姓名、电话和联系地址，因此根据客户资料对购物对象进行身份验证，相当于实名制过程，通过实名制还可以便于追溯产品流通方向，特别是针对药品行业，通过追溯药品流通方向，有利于对一些特殊事件（例如重大疫情）的追溯求源。

具体地，客户资料中至少包含客户姓名、电话和身份证号码，且购物对象若想实现正常下单，需事先在平台中进行注册，注册时需提供姓名、电话、身份证号码和联系地址。

具体地，购物对象在身份验证通过后，输入订单请求到平台中，订单请求中至少包括姓名、电话、客户地址、产品类型和产品数量。

优选地，如图2所示，在S3中，若所述产品类型判定为第二类产品，则将所述订单请求发送至业务端，具体包括以下步骤：

S31：若所述产品类型判定为所述第二类产品，获取所述订单请求中的客户地区数据；

S32：在预设的业务员管理数据库中，查找与客户地区数据相匹配的业务员数据，得到目标业务员数据；

S33：将所述订单请求发送至所述目标业务员数据对应的所述业务端。

订单请求中的客户地址可以反映购物对象的客户地区数据，因此，当产品类型为第二类产品时，更具体地，当药品类型为第二类药品时，提取订单请求中的客户地区数据，然后在业务员管理数据库中查找出与该客户地区数据相匹配的业务员数据，即能够为该购物对象匹配出负责代客下单的业务员的数据信息，具体为目标业务员数据；然后将该购物对象的订单请求发送至匹配出的业务员所属的业务端；上述方法能便于在客户购买控销产品时，分配对应的业务员实现代客下单，避免出现业务员恶意竞争的现象，保证代客下单的良性运营。

优选地，S2中，在判断所述订单请求中的药品类型之前，还包括以下步骤：

创建所述业务员管理数据库；其中，所述业务员管理数据库中包含有业务员数据与客户地区数据一一对应的关系表。

通过上述关系表，能便于平台快速而准确地匹配出与客户地区数据对应的业务员，进而提高代客下单的效率，提升客户的购物体验感。

具体地，业务员管理数据库中包括每个业务员的业务员基本信息以及产品厂商为每个业务员分配的唯一工号，业务员基本信息包括姓名、身份证号码和电话等信息，业务员管理数据库中还包括为每个唯一工号的业务员分配的管辖地区范围，每个业务员的业务员基本信息、唯一工号和对应的管辖地区范围统称为对应的业务员的业务员数据。此外，按照管辖地区范围，为所有业务员创建一个关系表，关系表中体现出管辖地区范围与工号的映射关系，该关系表即为业务员数据与客户地区数据一一对应的关系表。因此，通过查询业务员数据，可以查询到与客户地区数据相匹配的管辖地区范围，进而查询到对应的业务员的工号，进而将订单请求发送至对应工号的业务端。

具体地，在一个示例中，李四代理的是县一级的三九药业、仁和药业、葵花药业等厂商的销售业务，王五是县某某药店，厂商管理员将王五所在的地区分配到李四。王五可通过平台快速购买普药，支付后进入出货流程；而李四可通过同一平台帮助王五快速购买控销药品，李四通过平台帮助王五下单，王五在平台中收到待确认订单请求后，输入确认消息后即进入出货流程。

需要说明的是，本发明中的第一类订单和第二类订单可以是在客户支付后生成的订单，该种情况下客户支付既可以采取线上支付，也可以采取线下支付，支付的方法为现有技术，具体细节此处不再赘述；然后将支付后的第一类订单或第二类订单发送至后台服务器，进行财务审核后安排出货。第一类订单和第二类订单也可以是在客户支付前的订单，该种情况下，将第一类订单或第二类订单再分别利用平台反馈至客户端，在客户采取线上支付或线下支付后，再发送至后台服务器，同样进行财务审核后安排出货。

优选地，S3中，在所述业务端根据所述订单请求生成待确认订单，并反馈至所述购物对象之前，还包括以下步骤：

所述业务端获取上传的业务员资料，判断所述业务员资料与所述目标业务员数据是否相符，若是，则根据所述订单请求生成所述待确认订单，并反馈至所述购物对象；若否，则生成业务员验证失败信息并反馈至所述业务端。

通过上述判断上传的业务员资料与目标业务员数据是否相符的方法，能一方面确保业务员是产品厂商授权的业务员，另一方面保证业务员是与发起代客下单的购物对象或客户是对应匹配的，进一步保证代客下单的良性运营。

实施例二、如图3所示，一种多维线上下单装置，应用于实施例一中的多维线上下单方法中，包括请求获取模块、判断模块、第一订单生成模块和第二订单生成模块；

所述请求获取模块，用于获取购物对象的订单请求；

所述判断模块，用于判断所述订单请求中的产品类型；

所述第一订单生成模块，用于若所述判断模块将所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

所述第二订单生成模块，用于若所述判断模块将所述产品类型判定为第二类产品，则将所述订单请求发送至业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

本实施例的药品多维线上下单平台，既支持客户线上自主下单购买普通产品，又能通过业务员帮助客户，采取代客下单的方式购买控销产品，符合控销原则，避免了产品滥买的现象，省去了产品厂商与客户之间的繁琐沟通过程，购物效率高，提升了客户的购物体验；多维化的线上下单方式，同时满足客户和业务员的业务需求，在满足客户的个性化需求之外，方便业务员拓展新的业务线，尤其适用于具有严格控销原则的药品行业。

优选地，如图4所示，还包括客户验证模块；

所述客户验证模块，用于获取所述购物对象的客户资料，并根据所述客户资料对所述购物对象进行身份验证，若验证通过，则获取所述购物对象的所述订单请求；若验证不通过，则生成客户验证失败信息并反馈至所述购物对象。

通过客户验证模块，一方面避免了出现客户滥买、恶意采购等现象，另一方面便于后续分配业务员进行代客下单，还可以便于追溯产品流通方向，特别是针对药品行业，通过追溯药品流通方向，有利于对一些特殊事件（例如重大疫情）的追溯求源。

优选地，所述第二订单生成模块具体用于：

若所述产品类型判定为所述第二类产品，获取所述订单请求中的客户地区数据；

在预设的业务员管理数据库中，查找与客户地区数据相匹配的业务员数据，得到目标业务员数据；

将所述订单请求发送至所述目标业务员数据对应的所述业务端。

通过上述第二订单生成模块，能便于在客户购买控销产品时，分配对应的业务员实现代客下单，避免出现业务员恶意竞争的现象，保证代客下单的良性运营。

优选地，如图4所示，还包括创建模块；

所述创建模块，用于创建所述业务员管理数据库；其中，所述业务员管理数据库中包含有业务员数据与客户地区数据一一对应的关系表。

通过创建模块创建包含有业务员数据与客户地区数据一一对应的关系表的业务员管理数据库，能便于平台快速而准确地匹配出与客户地区数据对应的业务员，进而提高代客下单的效率，提升客户的购物体验感。

优选地，如图4所示，还包括业务验证模块；

所述业务验证模块，用于所述业务端获取上传的业务员资料，判断所述业务员资料与所述目标业务员数据是否相符，若是，则根据所述订单请求生成所述待确认订单，并反馈至所述购物对象；若否，则生成业务员验证失败信息并反馈至所述业务端。

通过业务验证模块，能一方面确保业务员是产品厂商授权的业务员，另一方面保证业务员是与发起代客下单的购物对象或客户是对应匹配的，进一步保证代客下单的良性运营。

本实施例中的未尽细节，参见实施例一及图1至图2的描述，此处不再赘述。

实施例三、如图5所示，一种多维线上下单系统，包括客户端、业务端以及实施例二中的多维线上下单平台，所述多维线上下单平台分别与所述客户端和所述业务端通信连接；

所述客户端，用于向所述多维线上下单平台发送购物对象的订单请求；

所述多维线上下单平台，用于接收所述订单请求，并判断所述订单请求中的产品类型，当所述产品类型判定为第一类产品时，根据所述订单请求生成第一类订单；当所述产品类型判定为第二类产品时，将所述订单请求发送至所述业务端；

所述业务端，用于当所述产品类型判定为第二类产品时，接收所述多维线上下单平台发送的所述订单请求，并根据所述订单请求生成待确认订单请求，将所述待确认订单请求发送至所述多维线上下单平台；

所述多维线上下单平台，还用于将所述待确认订单请求发送至所述客户端；

所述客户端，还用于接收所述多维线上下单平台发送的所述待确认订单请求，根据所述待确认订单请求生成确认信息，并提供给所述多维线上下单平台；

所述多维线上下单平台，还用于当接收到所述客户端发送的所述确认信息时，根据所述待确认订单请求生成第二类订单；当未接收到所述客户端发送的所述确认信息时，生成下单失败信息。

本实施例中的多维线上下单系统，既支持客户线上自主下单购买普通产品，又能通过业务员帮助客户，采取代客下单的方式购买控销产品，符合控销原则，避免了产品滥买的现象，省去了产品厂商与客户之间的繁琐沟通过程，购物效率高，提升了客户的购物体验；多维化的线上下单方式，同时满足客户和业务员的业务需求，在满足客户的个性化需求之外，方便业务员拓展新的业务线，尤其适用于具有严格控销原则的药品行业。

具体地，本实施例中的多维上下单系统还包括后台服务器，系统每个版块所实现的功能如图6所示。

本实施例中的未尽细节，参见实施例一、实施例二及图1至图4的描述，此处不再赘述。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种多维线上下单方法，其特征在于，包括以下步骤：

获取购物对象的订单请求；

判断所述订单请求中的产品类型，若所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

若所述产品类型判定为第二类产品，则将所述订单请求发送至业务端，具体包括以下步骤：

若所述产品类型判定为所述第二类产品，获取所述订单请求中的客户地区数据；

在预设的业务员管理数据库中，查找与客户地区数据相匹配的业务员数据，得到目标业务员数据；

将所述订单请求发送至所述目标业务员数据对应的所述业务端；

获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

2.根据权利要求1所述的多维线上下单方法，其特征在于，在获取购物对象的订单请求之前，还包括以下步骤：

获取所述购物对象的客户资料，并根据所述客户资料对所述购物对象进行身份验证，若验证通过，则获取所述购物对象的所述订单请求；若验证不通过，则生成客户验证失败信息并反馈至所述购物对象。

3.根据权利要求1所述的多维线上下单方法，其特征在于，在判断所述订单请求中的产品类型之前，还包括以下步骤：

创建所述业务员管理数据库；其中，所述业务员管理数据库中包含有业务员数据与客户地区数据一一对应的关系表。

4.根据权利要求1所述的多维线上下单方法，其特征在于，在所述业务端根据所述订单请求生成待确认订单，并反馈至所述购物对象之前，还包括以下步骤：

所述业务端获取上传的业务员资料，判断所述业务员资料与所述目标业务员数据是否相符，若是，则根据所述订单请求生成所述待确认订单，并反馈至所述购物对象；若否，则生成业务员验证失败信息并反馈至所述业务端。

5.根据权利要求1至4任一项所述的多维线上下单方法，其特征在于，所述第一类产品具体为无限制流通产品，所述第二类产品具体为控销产品。

6.一种多维线上下单装置，其特征在于，应用于权利要求1至5 任一项所述的多维线上下单方法中，包括请求获取模块、判断模块、第一订单生成模块和第二订单生成模块；

所述请求获取模块，用于获取购物对象的订单请求；

所述判断模块，用于判断所述订单请求中的产品类型；

所述第一订单生成模块，用于若所述判断模块将所述产品类型判定为第一类产品，则根据所述订单请求生成第一类订单；

所述第二订单生成模块，用于若所述判断模块将所述产品类型判定为第二类产品，则将所述订单请求发送至业务端，若所述产品类型判定为所述第二类产品，获取所述订单请求中的客户地区数据；在预设的业务员管理数据库中，查找与客户地区数据相匹配的业务员数据，得到目标业务员数据；将所述订单请求发送至所述目标业务员数据对应的所述业务端；获取所述业务端根据所述订单请求生成的待确认订单请求，并反馈至所述购物对象；判断是否接收到所述购物对象根据所述待确认订单请求生成的确认信息，若是，则根据所述待确认订单请求生成第二类订单；若否，则生成下单失败信息。

7.根据权利要求6所述的多维线上下单装置 ，其特征在于，还包括客户验证模块；

所述客户验证模块，用于获取所述购物对象的客户资料，并根据所述客户资料对所述购物对象进行身份验证，若验证通过，则获取所述购物对象的所述订单请求；若验证不通过，则生成客户验证失败信息并反馈至所述购物对象。

8.一种多维线上下单系统，其特征在于，包括客户端、业务端以及如权利要求6至7任一项所述的多维线上下单装置 ，所述多维线上下单装置 分别与所述客户端和所述业务端通信连接；

所述客户端，用于向所述多维线上下单装置 发送购物对象的订单请求；

所述多维线上下单装置 ，用于接收所述订单请求，并判断所述订单请求中的产品类型，当所述产品类型判定为第一类产品时，根据所述订单请求生成第一类订单；当所述产品类型判定为第二类产品时，将所述订单请求发送至所述业务端；

所述业务端，用于当所述产品类型判定为第二类产品时，接收所述多维线上下单装置发送的所述订单请求，并根据所述订单请求生成待确认订单请求，将所述待确认订单请求发送至所述多维线上下单装置 ；

所述多维线上下单装置 ，还用于将所述待确认订单请求发送至所述客户端；

所述客户端，还用于接收所述多维线上下单装置 发送的所述待确认订单请求，根据所述待确认订单请求生成确认信息，并提供给所述多维线上下单装置 ；

所述多维线上下单装置 ，还用于当接收到所述客户端发送的所述确认信息时，根据所述待确认订单请求生成第二类订单；当未接收到所述客户端发送的所述确认信息时，生成下单失败信息。

Images