订单数据处理方法和装置与流程

文档序号:11459112阅读:333来源:国知局
订单数据处理方法和装置与流程

本申请涉及互联网技术领域,具体涉及一种订单数据处理的方法及装置。



背景技术:

电商高频消费的场景下,用户可能长期购买相同的产品。而现有电商用户下单的方式或场景比较复杂,用户需要选择商品,确认收货地址,确认联系人,选择送达时间等等,最后还需要选择支付方式等才能下单付款。创建一笔订单的时间比较长,而针对用户经常或长期需要购买的相同产品,用户需要每次下单时候都填写大量的信息才能完成订单,而每次的订单的信息几乎相同,且产品的信息也几乎相同。

因此,针对如上述下单业务,对频繁下单的产品进行下单操作属于用户的频繁应用的业务,需要一种简单的方式可以使用户在短时间的完成下单的操作,以为用户的日常生活带来便利。



技术实现要素:

本申请提供一种订单数据处理方法,以解决现有技术中存在的上述问题。

本申请还提供一种订单数据处理装置。

本申请提供一种订单数据处理方法,该方法包括:

预先设置有与用户关联的订单模板以及所述订单模板的触发条件;

接收用户输入信息;

根据输入信息,判断是否满足所述触发条件;

当满足所述触发条件时,生成所述订单模板对应的订单请求。

可选的,所述预先设置有与用户关联的订单模板以及所述订单模板的触发条件,包括:

预先设置与用户关联的若干个订单模板;

为相应的订单模板设置与该订单模板对应的触发条件。

可选的,所述为相应的订单模板设置与该订单模板对应的触发条件中,所述订单模板与所述触发条件之间的对应关系采用列表方式记录。

可选的,所述为相应的订单模板设置与该订单模板对应的触发条件中,所述触发条件是引导获取对应的订单模板的指令,启动触发条件的指令,将获取对应的订单模板。

可选的,所述当满足所述触发条件时,生成所述订单模板对应的订单请求包括:

基于订单模板,获得所述订单模板上包含的用户信息;

根据获得的所述用户信息生成对应的订单请求。

可选的,在所述获得所述订单模板上包含的用户信息之后,执行以下操作:

接收对获得的用户信息的修改操作,获得修改后的用户信息;

所述根据获得的所述用户信息生成对应的订单请求,是根据修改后的用户信息生成对应的订单请求。

可选的,所述预先设置所述订单模板的触发条件包括:

预设若干个触发类型;其中每个触发类型包括具有相同类型的不同的指令;

接收针对若干个触发类型的选定操作,获得选定的触发类型;

将所述选定的触发类型中所包含的指令作为订单模板的触发条件。

可选的,所述接收针对若干个触发类型的选定操作,获得选定的触发类型包括:

预先设置触发类型选择按钮;

接收对所述触发类型选择按钮的操作,展示预设的触发类型;

接收针对展示的触发类型的选定操作,获得选定的触发类型。

本申请还提供一种订单数据处理装置,该装置包括:

设置单元,用于预先设置有与用户关联的订单模板以及所述订单模板的触发条件;

接收单元,用于接收用户输入信息;

判断单元,用户根据输入信息,判断是否满足所述触发条件;

订单请求生成单元,用于当满足所述触发条件时,生成所述订单模板对应

的订单请求。

可选的,所述设置单元包括:

设置子单元,用于预先设置与用户关联的若干个订单模板;

触发条件设置子单元,用于为相应的订单模板设置与该订单模板对应的触发条件。

可选的,所述订单请求生成单元包括:

用户信息获取子单元,用于基于订单模板,获得所述订单模板上包含的用户信息;

订单请求获取子单元,用于根据获得的所述用户信息生成对应的订单请求。

可选的,该装置还包括:

修改子单元,用于在所述获得所述订单模板上包含的用户信息之后,接收对获得的用户信息的修改操作,获得修改后的用户信息;

修改订单请求生成子单元,用于所述根据获得的所述用户信息生成对应的订单请求,是根据修改后的用户信息生成对应的订单请求。

可选的,所述设置单元还包括:

类型设置子单元,用于预设若干个触发类型;其中每个触发类型包括具有相同类型的不同的指令;

选定操作接收子单元,用于接收针对若干个触发类型的选定操作,获得选定的触发类型;

触发条件设定子单元,用于将所述选定的触发类型中所包含的指令作为订单模板的触发条件。

本申请另外还提供一种订单数据处理方法,该方法包括:

接收订单请求;

根据所述订单请求,生成订单;

所述订单请求为当用户输入信息满足触发条件时,根据订单模板生成的,所述触发条件与用户的订单模板相关联。

可选的,所述接收订单请求,包括:

接收用户针对订单请求的输入信息;

判断所述输入信息是否满足预先设置的触发条件;

当满足所述触发条件时,接收所述订单请求。

可选的,所述触发条件与用户的订单模板相关联中,所述触发条件与所述订单模板的设置包括:

预先设置与用户关联的若干个订单模板;

为相应的订单模板设置与该订单模板对应的触发条件。

可选的,所述为相应的订单模板设置与该订单模板对应的触发条件中,所述订单模板与所述触发条件之间的对应关系采用列表方式记录。

本申请另外还提供一种订单数据处理装置,该装置包括:

订单请求接收单元,用于接收订单请求;

订单生成单元,用于根据所述订单请求,生成订单;

所述订单请求为当用户输入信息满足触发条件时,根据订单模板生成的,所述触发条件与用户的订单模板相关联。

可选的,所述订单请求接收单元包括:

输入信息接收子单元,用于接收用户针对订单请求的输入信息;

判断子单元,用于判断所述输入信息是否满足预先设置的触发条件;

接收子单元,用于当满足所述触发条件时,接收所述订单请求。

与现有技术相比,本申请具有以下优点:本申请提供一种订单数据处理方法,该方法包括:预先设置有与用户关联的订单模板以及所述订单模板的触发条件;接收用户输入信息;根据输入信息,判断是否满足所述触发条件;当满足所述触发条件时,生成所述订单模板对应的订单请求。

该方法预先设置有触发条件以及可通过该指定的触发所能够触发的订单模板,根据用户输入信息可以判断该输入信息是否满足上述触发条件,当满足触发条件时,说明用户输入的信息是作为相应订单模板的启动信号,可启动根据上述订单模板启动对应的订单请求的指令任务。所述订单模板将包含有与用户具有关联性的一些信息,因此,采用该方法可以根据输入信息的不同,将启动不同的订单模板,进而生成不同的订单请求,为用户完成指定订单任务提供便利。例如,当用户需要购买某一产品时,只需要通过在线输入相应的输入信息,如果该输入信息与预设的触发条件匹配,则可以直接对该产品进行下单操作,并且由于每个指令对应的产品不同,因此,输入每个不同的指令,将对应不同的产品,通过输入信息的不同可以对不同的产品进行下单。总之,用户只需要输入相应输入信息就可能完成下单任务,因此,节省了用户需要输入大量产品或用户信息的时间,从而为用户的使用带来便利。该方法结合智能手机等移动终端使用时,能够有效利用移动终端与使用者之间的一一对应关系,充分利用移动终端已经包含的使用者的身份、账户等特定信息,有效简化在移动终端的信息输入过程。

附图说明

图1是本申请第一实施例提供的订单数据处理方法在客户端执行时的流程图。

图2是本申请第一实施例提供的存储订单指令的流程图。

图3是本申请第一实施例提供的生成订单的流程图。

图4是本申请第二实施例提供的订单数据处理装置的结构示意图。

图5是本申请第三实施例提供的订单数据处理方法在服务端执行时的流程图。图6是本申请第四实施例提供的订单数据处理装置的结构示意图。

具体实施方式

本申请第一实施例提供一种订单数据处理方法,该方法主要的应用场景如下:用户经常需要处理的一些订单业务,或者是用户在间隔相同时间便需要下单的产品等,针对该类型的下单请求任务,本申请第一实施例通过该方法,可以为用户节省下单操作的时间,并且,减少了用户下单操作所需要执行的步骤,给用户的生活提供相当大的便利。

以下通过具体的实施例对该方法进行介绍和说明。首先介绍该方法在客户端执行时的过程。图1是本申请第一实施例提供的订单数据处理方法在客户端执行时的流程图。请参照图1,该操作方法包括步骤s101-步骤s104,以下分别通过每个步骤对该操作方法进行说明。

步骤s101,预先设置有与用户关联的订单模板以及所述订单模板的触发条件。

该步骤是用于预先设置与用户关联的订单模板以及与该订单模板所对应的触发条件的过程,预设的触发条件可以用于当满足触发条件时,可以根据所述订单模板生成相应的订单信息。因此,所述预设的订单模板与触发条件之间应该设置有对应关系。而该对应关系可以为一对一的对应关系,即每个订单模板将会对应一个触发条件,相应的触发条件可用于引导触发相应的订单模板。

所述触发条件是引导获取对应的订单模板的指令,启动触发条件的指令,将获取对应的订单模板。具体的,所述触发条件可以是指令的标识,执行相应的指令时即可开启触发相应订单模板的情况。

另外,所述订单模板中记录的信息是执行订单请求时所需要的与用户具有关联性的一些基本信息。由于该基本信息是与具体的用户具有关联性的,所以,所述基本信息可以称为用户信息,即所述订单模板主要包含有所述用户信息。

该方法应用的场景一般为下单操作,也就是针对指定的产品进行下单操作业务。以下均以该应用场景为例进行说明。

在该下单操作业务的环境下,用户可能需要对某些产品进行定期的下单操作,而针对频繁下单的产品,采用该方法可避免用户在每次下单时填写复杂的信息,该信息一般也是固定不变的,但每次下单都需要填写的操作比较繁琐,因此,该方法通过设置相应的订单模板及可以触发该订单模板的触发条件以方便用户方便快捷的进行下单操作。

相应的,针对下单操作这一业务,所述订单模板是指固定记录有用户经常下单购买的某些产品的相关信息,以及用户的个人基本信息,所述订单模板上记录的信息是完成下单业务所需要填写的一些信息,用户一旦获取或加载该订单模板上的信息,该加载的信息足以满足用户针对相应产品的下单需求,因此,在该订单模板中记录的是用户预先设置的一些信息,以方便用户根据该信息进行下单操作。

具体的,该订单模板所包含的用户信息可以包括以下信息中一种或者多种的组合:订单的产品种类及产品数量、订单收货地址、送达时间、支付方式、用户的联系方式等等。

在实际的下单业务中,上述列举的信息一般在订单模板中都是预先设置填写好的,所述订单的产品种类及产品的数量是指,用户经常购买的产品,以及每次下单时购买的该产品的数量。所述产品可以是单一种类的产品,也可是由多种产品种类构成的产品组。例如,单一种类产品可以是指单一的苹果一种水果,而多种产品种类构成的产品组合的该组合中可包含有苹果和柠檬的组合,所以,每次可进行单一产品的下单,也可以是针对一个组合中包含有多种产品的下单。另外,针对产品的数量是指,该数量是广义的概念,例如,该数量可以是苹果的个数,也可以是苹果的斤数。不管该数量是以何种单位计量的,用户均可以对该数量进行设置,相应的,订单模板中记录的产品的数量即为用户按照合适的计量单位设置的数量。

所述订单收货地址是指,该次订单所要送达的地址,一般情况下,该地址为用户的居住地址或工作地址,也可以是用户的经常收货的地址,该订单收货地址是用户预先设定的。该订单形成之后,订单的产品将直接送达该地址。

所述送达时间是指,用户要求的该订单送达的时间,根据一般用户的习惯,当订单收货地址为居住地址时,一般要求送达时间是非工作日时间,而当订单收货地址为工作地址时,一般要求送达时间为工作日时间。并不是所有送达时间均是这样设置的,用户可以根据实际需要,填写要求的送达时间为具体的某一个日期。该送达时间也可以指,每天的几点至几点可以送货等类似信息。例如,该送达时间设定为每周五下午4点,或者该送达时间设定为下单当天中午12点等。

所述支付方式是指,用户下达此次的订单是采用的支付方式,一般支付方式为在线支付和到付。而针对在线支付,可以在相应的购物平台上绑定用户的银行卡,并允许快捷支付或小金额的自动支付等,用户设定为在线支付之后,系统将从用户绑定的银行卡中自动扣除此次下单产品的金额。针对到付,用户可做在线支付,也不需要绑定银行卡,但是该产品或该购物平台是支付到付这种方式的,用户设定到付之后,收货时才需要支付此次下单产品的相应费用。

所述用户的联系方式是方便订单的发货方能够与下单的用户进行沟通。

一般情况下,上述信息均需要记录在所述订单模板上,形成固有的信息模式,以供用户进行下单操作时可省略这些信息的填写。

以上是对订单模板的介绍和说明,以下对所述触发条件进行介绍和说明。

所述触发条件是指,预先设置用于作为后续用户输入的输入信息的比对标准。具体的,该触发条件可以是以下相应的指令,例如:语音指令、口令指令、字符指纹指令、图片指令等等。可以预先录入一段语音作为下单指令,该语音指令对应相应的所要下单的产品。

由于触发条件还可以根据指令的类型进行分类,其具体情况可在对触发条件的设置的步骤进行详细的说明,在此先介绍有触发条件即为可以引导获取对应的订单模板的指令,启动触发条件的指令,将获取对应的订单模板。

以上是对订单模板和触发条件进行的简单说明,另外,还需要对订单模板与触发条件之间的对应关系采用何种方式进行记录进行详细的说明和介绍。

所述订单模板与所述触发条件之间的对应关系采用列表方式记录。

具体的,每个订单模板对应一个触发条件,而该对应关系可采用列表的方式进行记录。例如:针对一个用户,在该用户的账户下设置有多个订单模板及相应数量的触发条件,并且订单模板与触发条件之间采用列表形式进行记录,订单模板一对应触发条件一,订单模板二对应触发条件二,订单模板三对应触发条件三等,按照此方式,将该用户账号下的所有订单模板均对应相应的触发条件,在该记录列表中,左侧列中均为订单模板,右侧列中均为触发条件,并且用户还可以根据应用习惯,对订单模板与触发条件之间对应关系进行更改和调整,只要保证相应的订单模板是具有对应的触发条件的即可。

例如,在用户a的账户下,共有三个订单模板,订单模板一记录的信息为:购买三斤苹果和一斤桃,相应的,可触发该订单模板的触发条件设置为识别左手食指指纹;订单模板二记录的信息为:购买两桶4l的矿泉水,相应的,可触发该订单模板的触发条件设置为识别右手食指的指纹;订单模板三记录的信息为:购买一箱酸奶,相应的,可触发该订单模板的触发条件设置为识别右手拇指的指纹。所以,针对上述情况,用户a只要在可接收上述触发指令的位置,输入相应的手指指纹,就可以对相应订单模板上所要购买的产品下订单,当用户a输入左手食指指纹时,可引用获取订单模板一中购买三斤苹果和一斤桃的信息,因此,可实现一键下单的操作,并且由于订单模板与触发条件之间的对应关系,可设置多个触发条件及订单模板,根据不同的触发条件开启不同的订单模板。

另外,为了防止触发条件在某种限定情况下无法识别的情况,可为一个订单模板设置多个触发条件,并且,一个订单模板与多个触发条件之间的对应关系依然采用列表方式进行记录。

当触发条件与订单模板是多对一的对应关系时,对应一个订单模板设置一个以上不同的触发条件,每个触发条件均能独立触发与该触发条件对应的订单模板。多个触发条件中的任意一个触发条件均可以触发相应的订单模板。进而,用户可以采用不同的输入信息(手势、图片或语音等)针对同一个订单模板进行下单操作,该设置方式一方面可以防止触发条件在某种限定情况下无法识别的情况,另一方面还可以防止用户忘记某一个订单模板对应的唯一的触发条件的情况。

总之,采用列表方式记录所述订单模板与触发条件的方式可以很明确的了解与每个订单模板所对应的触发条件,方便用户对两者之间的对应关系的调整或整改等的管理。

另外,为了丰富触发条件的类型,所述预先设置所述订单模板的触发条件中设置触发条件的方式包括以下方式触发条:

预设若干个触发类型。其中每个触发类型包括具有相同类型的不同的指令;

所述触发类型包括以下类型中的一种或多种的组合:语音指令类型、口令指令类型、字符串指令类型、指纹指令类型、按钮指令类型、手势指令类型、笔迹指令类型、图片指令类型。上述列举的类型并不是穷举,任何可以使用的指令方式均属于本申请保护范围。

预设若干个触发类型之后,接收针对若干个触发类型的选定操作,获得选定的触发类型。

该步骤是在若干个触发类型中选择一个触发类型,从而获得选定的触发类型的过程,通过上述设置多个触发类型,并允许用户选择其一的触发类型设置相应的触发条件,因此,一方面丰富触发条件的种类,不同种类的触发条件对应相应的订单模板,也就是不同种类的触发条件对应不同的下单的产品,因此,可以为用户提供更多产品与触发条件之间的对应关系。另外,应用的触发条件种类越多,越可以提高用户对下单操作的安全性。

具体的,所述接收针对若干个触发类型的选定操作,获得选定的触发类型包括:

预先设置触发类型选择按钮。之后,接收对所述触发类型选择按钮的操作,展示预设的触发类型,最后接收针对展示的触发类型的选定操作,获得选定的触发类型。

根据接收的选取的某一触发类型的操作,以该触发类型对应的方式接收操作输入,将所接收的操作输入作为所述用于触发所述订单模板的触发条件。

另外,根据所述触发类型的不同,不同的触发类型对应不同的操作输入,将接收的该输入操作作为的触发条件也不同。

例如,所述触发类型为图片指令时,所述将该选取的触发类型下的预设信息设置生成触发条件,是将图片指令类型中的图片设置该下单对象对应的触发条件。

或者,所述触发类型为语音指令类型时,所述将该选取的触发类型下的预设信息设置生成触发条件,是将语音指令类型中的语音设置该下单对象对应的触发条件。

或者,所述触发类型为按钮指令类型时,所述将该选取触发类型下的预设信息设置生成触发条件,是将按钮指令类型中的按一键下单按钮设置该下单对象对应的触发条件。

上述列举的其他类型也是如语音指令、图片指令或者按钮指令的设置方式相同,在此不一一举例说明。

相应的,不同种类的触发类型对应的不同的触发条件可以是一下指令中的一种或者多种的组合:语音输入下单、输入口令下单、上下、左右、圆弧轨道滑动下单、不同触摸手势下不同订单、不同笔迹下不同订单、不同图形密码下不同订单、app内点击按钮一键下单、3dtouch按钮一键下单、预授权给十指指纹,不同指头的指纹下不同订单、预授权给不同的图片,扫描不同的图片下不同的订单。

当触发类型为口令指令时,采用口令作为触发条件时,可方便用户根据具体的口令明确所要下单的产品,给用户提供便利。并且采用口令下单时,口令的输入可以采用语音输入,也可以采用文字输入等方式。

具体的,例如,如果用户每周周会之前都需要购买一定数量的水果的情况下,可以提前设置好水果种类和数量,要求每周周五下午四点送到公司等。因此,设置这一订单模板上记录的信息可以是:产品为十斤苹果,送货地址为公司具体地址,送货时间为每周五下午四点,对应的口令可以设置为“周会水果”。用户在每周五可以打开相应的订购app应用,输入口令“周会水果”,app应用将会自动加载该订单信息,生成订单请求。

采用口令下单的方式简单且容易记忆,例如,用户a每天中午回订外卖,因此,可以将周一至周五的午餐所要订的餐分别设置为订单模板,相应的口令分别设置为“周一午餐”、“周二午餐”、“周三午餐”、“周四午餐”和“周五午餐”,这样用户a至需要确定订外卖的当天为周几,就可以通过输入相应的口令下单,方便用户可以通过简单明了的口令将不同的订单模板对应的不同的触发条件。

上述口令可以是多种形式,例如:“”可以通过文字输入,也可以通过语音输入,但无论通过何种方式输入,只要用户输入的口令是正确的,则可触发相应的订单模板,进而生成对应的订单请求。

上述通过预设的方式已经形成触发条件和订单模板,进而需要将该触发条件和订单模板存储起来。

所述预先设置有与用户关联的订单模板以及所述订单模板的触发条件之后,执行以下操作:存储所述与用户关联的订单模板以及所述订单模板的触发条件

具体的,所述存储所述订单模板和触发条件步骤中,存储的方式包括两种方式,该两种方式可以单独实施,也可以两种方式结合实施。

第一种方式是,将所述与用户关联的订单模板以及所述订单模板的触发条件存储在用户登录的客户端本地的存储器中。

存储到客户端本地的存储器中很容易理解,用户将该预设的信息存储到客户端本地的文件夹中,后续需要调用该信息时直接从该本地缓存的文件夹中调用即可。

第二种方式是,将所述与用户关联的订单模板以及所述订单模板的触发条件以用户的id信息为依据存储在该id对应的服务端的存储器中。

存储到服务端的方式需要依赖于用于的id信息,用户登录客户端的个人账户,该账户以id信息唯一标识,用户在该客户端预设的订单模板和触发条件之后,将该设置的信息存储在id信息对应的服务端的存储器中,后续需要调用该信息时,用户登录该个人账号,就可以从服务端调取该之前存储的触发条件和订单模板。

上述两种存储方式可以共存,也可以单独存在,即该订单模板及对应的触发条件可以同时存储在客户端和服务端,也可以单独存储在客户端或服务端。

另外,客户端可以是ios客户端,也可以是android客户端,或者是浏览器html页面,还可以是windows客户端等。

以下通过具体的例子对该存储过程进行说明,图2是本申请第一实施例提供的存储订单指令的流程图。请参照图2,首先用户访问客户端,用户可以登录个人id,也可以应用客户端id,然后选择一个或多个产品及产品的数量,之后在客户端上选择或填写订单收货地址,再选择送达时间,之后再选择支付方式,最后选择指令类型,并录入触发条件,最终客户端将用户或客户端id,产品的信息、收货地址、送达时间、支付方式、指令类型、触发条件存储到服务器或者客户端本地缓存。

步骤s102,接收用户的输入信息。

该步骤是用于让用户输入指令的过程,用户通过输入的输入指令如果与触发条件相配合,则可以直接进行下单操作,下单所需要填写的信息已经记录在订单模板上了,而不需要用户再填写下单所需信息,为用户的下单操作提供便利。

另外,用户是如何进行输入信息的,一般情况下,可以在购物平台的客户端上预先设置指令下单单元,所述指令下单单元用于接收输入指令。例如,在淘宝app上设置一个功能模块,该功能模块可称为指令下单单元,用户进入该指令下单单元,可以在该指令下单单元上输入相应的输入指令。

此外,在所述接收用户的输入信息步骤之前,需要执行以下操作:

根据客户端和/或服务器的存储器中存储的信息获取当前用户所预先设置所述信息模板和指令。

不管触发条件和订单模板存储在客户端本地还是存储在服务端,还是在客户端本地与服务端均有存储,在用户输入指令之前,应该首先存储的上述信息加载在用户所操作的客户端的本地。

步骤s103,根据输入信息,判断是否满足所述触发条件。当该步骤的判断结果为是时,即输入信息满足所述触发条件,则进入步骤s104。

用户输入某一输入信息之后,判断该输入信息与预设的触发条件是否匹配,所述预设的触发条件是固定的,该触发条件是用户已经预先设置好的,并且对应相应的订单模板,因此,用户可以通过输入信息的方式实现该下单操作业务,并且,由于输入信息相匹配的预设的触发条件是与订单模板中记录的用户信息对应的,因此,根据订单模板及预设的触发条件的不同,用户可以输入不同的输入信息,以实现不同的下单操作业务。

该步骤是一个判断过程,判断输入信息与预设的触发条件是否匹配的过程,当判断结果为是时,说明用户输入的输入信息在预设的触发条件之中,用户采用该输入信息即是为了对该相应的触发条件对应的订单模板上的产品进行下单操作的过程。所以,当判断结果为是时,可以将所述触发条件对应的订单模板呈现给用户。

上述介绍了判断输入信息与触发条件是否匹配的方式,当该判断结果为是时,即输入信息满足所述触发条件,则进入步骤s104,若判断结果为否,则说明此次输入的输入信息是无效的,匹配失败。

步骤s104,当满足所述触发条件时,生成所述订单模板对应的订单请求。

该步骤是指当用户输入的输入信息与预设的触发条件相匹配时,说明用户是需要执行与该预设的触发条件对应的订单模板启动之后,根据该订单模板生成对应的订单请求的过程。

所述当满足所述触发条件时,生成所述订单模板对应的订单请求包括:

基于订单模板,获得所述订单模板上包含的用户信息;根据获得的所述用户信息生成对应的订单请求。

上述已经对订单模板中的具有的信息进行了说明,因此,针对某一触发条件,该触发条件所能触发的订单模板中的信息是,用户准备购买的产品的信息,以及针对该订单所涉及的收货地址、送达时间等信息,在界面上展示该信息供用户参考或审核,之后再需要用户做出进一步的确定操作。

另外,当展示给用户的订单模板中的信息之后,可能用户会对该展示的信息进行较小程度的修改,则需要设置相应的修改功能。

具体的,在所述获得所述订单模板上包含的用户信息之后,执行以下操作:

接收对获得的用户信息的修改操作,获得修改后的用户信息相应的,所述根据获得的所述用户信息生成对应的订单请求,是根据修改后的用户信息生成对应的订单请求。

可以通过设置修改按钮的方式,设置的修改按钮接收用户对订单模板的修改操作之后,原始的订单模板上的信息将被修改,从而获得修改后的订单模板。

所述修改后的订单模板可以作为新的订单模板存储在存储器中,也可以并不存储为新的订单模板,该修改后的订单模板仅限于此次下单操作使用,并不会将修改的内容记录形成新的模板。

如果将修改后的订单模板形成新的订单模板,则需要用户再次对该新的订单模板设置可以触发该新的订单模板的新的触发条件,所述新的触发条件的形成过程与上述中介绍的触发条件的形成过程相同。

另外,所述接收对呈现给用户的订单模板的修改操作步骤中,所述修改操作所采用的方式包括以下方式中的任意一种或多种的组合:

对订单模板上产品的种类或产品的数量进行修改。

对订单模板上订单收货地址进行修改。

对订单模板上送达时间进行修改。

对订单模板上支付方式进行修改。

其中,对订单模板上产品的种类或产品的数量进行修改的方式可以是多种情况,例如,用户本本来预设的订单模板上的产品是一箱a4纸,但在此下订单时,当前状况下需要两箱a3纸,因此,用户可以通过手动的方式将产品修改为a4纸,而将产品的数量由原来的一箱修改为两箱。

针对订单模板上的产品种类进行修改时,结合实际应用,用户一般是将订单模板上的产品种类修改为与该产品具有相同属性的产品。也就如上述事例,产品的属性仍然为纸,只是纸的型号发生了变化,这样也便于对预设的订单模板与触发条件的管理。

对订单模板上订单收货地址进行修改是指临时需要修改收货地址的情况,这些情况都是可能存在的,用户可能需要将原来居住地址修改为工作地址等,但该修改是临时的,如果该段时间内均需要修改收货地址,则可以重新设置该触发条件对应的订单模板,而在该订单模板中记录的订单收货地址则是修改后的地址。

对订单模板上送达时间进行修改以及对订单模板上支付方式进行修改与上述修改的原理是相同的,根据此次下单的实际需求,相应的修改送达时间或支付方式。

上述列举的修改一般是一种或两种信息需要修改,而订单模板中所有的信息均需要修改时,则需要重新设置订单模板中的信息,因此,该订单模板可根据用户不同时期的不同需求进行更换。

该方法通过预先设置东大门模板,并且该订单模板通过用户输入与触发条件相匹配的输入信息之后,根据相应的触发条件对应的订单模板,生成与该订单模板相对应的订单请求,并且用户还可以对订单模板进行相应的修改后并核实,确认该订单模板上的信息无误之后,将该订单模板上的信息生成相应的订单请求,以执行下单操作。

但是,如果用户需要对展示的订单模板上的信息进行修改时,则所述接收用户对所述订单模板的确认操作,是接收对所述修改后的订单模板的确认操作。也就是,如果用户需要修改信息,则等用户修改完成后,根据修改后的订单模板进行下一步的下单操作,以实现下单这一业务。

以下通过具体的实例对生成订单的过程进行说明,图3是本申请第一实施例提供的生成订单的流程图。请参照图3,首先用户访问客户端,之后客户端根据用户账户的id或者客户端id,从服务端或客户端本地读取配置的订单模板,之后用户通过输入信息触发相应的触发条件,客户端可根据用户输入的信息,与预先保存的触发条件进行匹配判断,若判断结果为否,则匹配失败,结束;若判断结果为是,匹配成功,用户还可以修改订单的信息,最后完成下单操作。

该方法预先设置有触发条件以及可通过该指定触发的订单模板,并且该触发条件是与每个订单模板对应的,用户可以根据输入信息触发相应的订单模板,并将订单模板中的用户信息呈现给用户,用户根据该呈现的信息为基础,并对该信息进行确认之后,可根据该订单信息中用户信息生成相应的订单请求。

因此,采用该方法可以根据输入信息的不同,生成不同的清单请求。例如,当用户需要购买某一产品时,只需要通过在线输入相应的信息,就可以直接对该产品进行下单操作,并且由于每个触发条件对应的产品不同,因此,输入每个不同的信息,将对应不同的产品,通过输入信息的不同可以对不同的产品进行下单操作。

总之,用户只需要输入相应信息即可下单,节省了用户需要输入大量产品或用户信息的时间,从而为用户的使用带来便利。例如,高频消费下,用户可能长期购买相同的产品。可以在客户端预先设置好所有订单模板,并设定对应该订单模板的触发条件,通过指令识别预先设定的订单模板,用户发出信息后直接读取对应的订单模板。提前设置用户信息,一次操作完成下单。不同触发条件(输入信息)匹配不同订单模板,生成不同的订单请求。

另外,本申请提供的方法结合智能手机等移动终端使用时更能体现该方法的有益效果。例如,用户的手机上本身就存储有用户的一些私人信息,手机与用户的一些私人信息结合比较紧密,而该私人信息也是预先设置订单模板的基础,即可以通过手机上存储的一些基本信息(例如用户的联系方式、办公地址等信息)自动填充至订单模板中,订单模板中需要预先设置的信息的获取更方便快捷和准确。并且,在下单操作中一般都涉及到支付方式及绑定银行卡情况,该信息的获取或记载是手机等移动终端所特有的功能,当该操作方法结合手机使用时,涉及到支付方式时,可自动绑定用户手机上已经绑定的银行卡,而不需要再次绑定,或者重新输入银行卡号等相关信息,所以,将该方法结合手机使用时,能够有效利用手机与使用者之间的一一对应关系,有效简化在移动终端的信息输入过程。

用户在使用手机进行下单操作时,用户可以通过特定的app应用输入指令,也可以简单的在手机界面上通过手势方式输入信息,该输入的信息对应相应的订单模板,对应的该订单模板将展示在用户界面上,用户可以对该订单模板进行修改,核实下单的产品及用户信息无误后,用户可通过点击确定下单按钮,完成下单操作。由于该操作方法结合手机使用时,该订单模板上的某些信息可以不用手动填写,可以将用户手机上记载有的特定信息自动加载到订单模板上,以有效的简化在手机上进行信息输入的过程,提高用户体验。

此外,本申请第一实施例提供的订单数据处理方法不仅限于下单业务这一场景,由于下单业务这一场景最能说明该指定业务的类型,所以上述通过下单业务这一应用场景对该操作方法进行了具体的说明和介绍。但是,该操作方法可以应用到任何需要周期性或频繁执行的业务,例如,如果某餐厅每周一向指定客户发送这一周中午的主打菜单,该项业务是指定客户提前将联系方式以及办公位置(送餐地址)提供给该餐厅。

因此,向每个指定客户推送菜单信息的业务称为该指定业务,餐厅可以将指定客户中的每个客户的联系方式及办公位置建立信息模板,并针每个客户的业务预先设置指令,每周一餐厅业务人员通过相应的app应用输入指令,当该输入指令与预先设置的指令相匹配时,该app应用可以将该推送菜单的信息发送给指定的客户。所以,该操作方法可以应用在很多场景中,只要是为了实现指定业务的场景均属于本申请保护的范围。

本申请第二实施例还提供一种订单数据处理装置,图4是本申请第二实施例提供的订单数据处理装置的结构示意图。请参照图4,该装置包括:

设置单元401,用于预先设置有与用户关联的订单模板以及所述订单模板的触发条件;

接收单元402,用于接收用户输入信息;

判断单元403,用户根据输入信息,判断是否满足所述触发条件;

订单请求生成单元404,用于当满足所述触发条件时,生成所述订单模板对

应的订单请求。

可选的,所述设置单元包括:

设置子单元,用于预先设置与用户关联的若干个订单模板;

触发条件设置子单元,用于为相应的订单模板设置与该订单模板对应的触发条件。

可选的,所述订单请求生成单元包括:

用户信息获取子单元,用于基于订单模板,获得所述订单模板上包含的用户信息;

订单请求获取子单元,用于根据获得的所述用户信息生成对应的订单请求。

可选的,所述装置还包括:

修改子单元,用于在所述获得所述订单模板上包含的用户信息之后,接收对获得的用户信息的修改操作,获得修改后的用户信息;

修改订单请求生成子单元,用于所述根据获得的所述用户信息生成对应的订单请求,是根据修改后的用户信息生成对应的订单请求。

可选的,所述设置单元还包括:

类型设置子单元,用于预设若干个触发类型;其中每个触发类型包括具有相同类型的不同的指令;

选定操作接收子单元,用于接收针对若干个触发类型的选定操作,获得选定的触发类型;

触发条件设定子单元,用于将所述选定的触发类型中所包含的指令作为订单模板的触发条件。

可选的,所述装置还包括:

存储单元,用于在所述预先设置有与用户关联的订单模板以及所述订单模板的触发条件之后,存储所述与用户关联的订单模板以及所述订单模板的触发条件;

其中,存储的方式采用以下方式:

将所述与用户关联的订单模板以及所述订单模板的触发条件存储在用户登

录的客户端本地的存储器中;和/或,

将所述与用户关联的订单模板以及所述订单模板的触发条件以用户的id信

息为依据存储在该id对应的服务端的存储器中。

本申请第三实施例还提供一种订单数据处理方法,该方法是在服务端执行的操作,其具体的方式与本申请第一实施例提供的订单数据处理方法执行在客户端上对应的,因此,其具体的实施方式可参考本申请第一实施例的实施方式。

图5是本申请第三实施例提供的订单数据处理方法在服务端执行时的流程图。请参照图5,该方法包括:

步骤s501,接收订单请求;

步骤s502,根据所述订单请求,生成订单;

所述订单请求为当用户输入信息满足触发条件时,根据订单模板生成的,所述触发条件与用户的订单模板相关联。

可选的,所述接收订单请求,包括:

接收用户针对订单请求的输入信息;

判断所述输入信息是否满足预先设置的触发条件;

当满足所述触发条件时,接收所述订单请求。

可选的,所述触发条件与用户的订单模板相关联中,所述触发条件与所述订单模板的设置包括:

预先设置与用户关联的若干个订单模板;

为相应的订单模板设置与该订单模板对应的触发条件。

可选的,所述为相应的订单模板设置与该订单模板对应的触发条件中,所述订单模板与所述触发条件之间的对应关系采用列表方式记录。

另外,本申请第四实施例还提供一种订单数据处理装置,图6是本申请第四实施例提供的订单数据处理装置的结构示意图。请参照图6,该装置包括:

订单请求接收单元601,用于接收订单请求;

订单生成单元602,用于根据所述订单请求,生成订单;

所述订单请求为当用户输入信息满足触发条件时,根据订单模板生成的,所述触发条件与用户的订单模板相关联。

可选的,所述订单请求接收单元包括:

输入信息接收子单元,用于接收用户针对订单请求的输入信息;

判断子单元,用于判断所述输入信息是否满足预先设置的触发条件;

接收子单元,用于当满足所述触发条件时,接收所述订单请求。

本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1