CN106096957A - 业务属性值的更新方法及系统 - Google Patents

Abstract

本发明涉及信息处理技术领域，公开了一种业务属性值的更新方法，包括：提取指定页面内预设位置区域的业务属性值；检测提取的业务属性值是否满足至少一个预设条件；如果提取的业务属性值满足至少一个预设条件，根据预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正；其中，预设条件至少包括：当前时刻处于预设条件的有效期内，提取的业务属性值大于或等于第一数值中最大的数值。本发明还提供了一种业务属性值的更新系统。与现有技术相比，本发明可以自动对业务属性值进行修正，避免用户忘记对业务属性值进行修正或者不知道如何对业务属性值进行修正而给用户带来的利益损失。

Description

业务属性值的更新方法及系统

技术领域

本发明涉及信息处理技术领域，特别涉及业务属性值的更新方法及系统。

背景技术

随着互联网技术的日益发展以及人们生活节奏的加快，很多人都希望足不出户就可以购买到心仪的商品，因此，在购物网站上购买商品越来越趋势化且越来越流行。商家为了回馈客户通常会向用户的账户发放优惠券，目前，在购物时如果用户在结算商品时要使用优惠券，则需要用户手动绑定优惠券才可以在结算时使用优惠券。或者，如果用户账户里预先就有优惠券，要点击优惠券才可以在结算时使用优惠券。

但是，用户在付款时，可能忘记绑定优惠券、忘记选择优惠券或者根本不知道在哪里选择已经存在于账户的优惠券，而直接付款。当用户想起账号里面还有优惠券时，可能优惠券已经过期了，导致用户的利益受到损失，用户体验不好。

发明内容

本发明的目的在于提供一种业务属性值的更新方法及系统，可以自动对业务属性值进行修正，避免用户忘记对业务属性值进行修正或者不知道如何对业务属性值进行修正而给用户带来的利益损失。

为解决上述技术问题，本发明实施例提供了一种业务属性值的更新方法，包括：提取指定页面内预设位置区域的业务属性值；检测提取的业务属性值是否满足至少一个预设条件；如果提取的业务属性值满足至少一个预设条件，根据预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正；其中，预设条件至少包括：当前时刻处于预设条件的有效期内，提取的业务属性值大于或等于第一数值中最大的数值。

本发明实施例还提供了一种业务属性值的更新系统，包括：提取模块、判断模块、修正模块；提取模块，用于提取指定页面内预设位置区域的业务属性值；判断模块，用于判断提取模块提取的业务属性值是否满足至少一个预设条件；修正模块，用于在判断模块判定所述提取的业务属性值满足至少一个预设条件，根据预设条件获取第一数值，并根据获取的第一数值对所述业务属性值进行修正；其中，所述预设条件至少包括：当前时刻处于预设条件的有效期内，所述提取的业务属性值大于或等于所述第一数值中最大的数值。

本发明的实施例相对于现有技术而言，通过提取指定页面内预设位置区域的业务属性值，检测提取的业务属性值是否满足至少一个预设条件，并在提取的业务属性值满足至少一个预设条件时，获取预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正，使得，可以自动对业务属性值进行修正，避免用户忘记对业务属性值进行修正或者不知道如何对业务属性值进行修正而给用户带来的利益损失。

另外，指定页面为用户的付款界面，业务属性值为订单中的应付款金额，预设条件为优惠券的使用条件，第一数值包括：优惠券的面值、优惠券的优惠金额；在根据获取的第一数值对所述业务属性值进行修正时，具体包括：将应付款金额减去优惠券的优惠金额作为实际付款金额。通过在用户的付款界面，监测用户订单中的应付款金额，并且在应付款金额满足至少一个优惠券的使用条件时，将应付款金额减去优惠券的优惠金额作为实际付款金额，使得可以在订单结算时，自动帮用户填充符合使用条件的优惠券，避免用户忘记选择优惠券或者不知道如何使用优惠券给用户带来的利益损失。

另外，在应付款金额满足至少两个优惠券的使用条件时，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。有多个优惠券可以使用时，自动帮用户填充优惠力度最大的优惠券，可以使用户在购买商品时能够获得最大的优惠金额，有助于进一步提升用户体验。

另外，在应付款金额满足至少两个优惠券的使用条件时，将至少两个优惠券显示出来供用户选择；将应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。有多个优惠券可以使用时，根据用户的选择使用优惠券，使用户可以选择更加满意的优惠券，有助于进一步提升用户体验。

另外，优惠券的使用条件还包括：应付款金额大于或者等于至少两个优惠券的面值之和；在将应付款金额减去优惠券的优惠金额作为实际付款金额时，计算满足使用条件的至少两个优惠券的优惠金额之和，将应付款金额减去优惠金额之和作为实际付款金额。在用户订单中的应付款金额满足至少两个优惠券叠加的使用条件时，直接将该至少两个优惠券叠加使用，使对优惠力度最大化。

另外，优惠券的使用条件还包括：一个订单只能使用一张优惠券；应付款金额大于或者等于至少两个优惠券的面值之和；对订单进行拆分，拆分形成的子订单的最大应付款金额大于或者等于其中至少两个优惠券的面值；在将应付款金额减去优惠券的优惠金额作为实际付款金额时，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。如果一个订单只能使用一张优惠券，且用户订单中的应付款金额满足至少两个优惠券叠加的使用条件时，可以对订单进行拆分，使拆分形成的每一个子订单对应一张优惠券；从而，可以使对优惠力度最大化，有助于进一步提升用户体验。

另外，在对订单进行拆分时，形成至少2种使用至少两个优惠券的组合方案；在将应付款金额减去优惠券的优惠金额作为实际付款金额时，根据优惠力度最大的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。对订单进行拆分时，会形成不止一个满足条件的子订单组合，将优惠力度最大的子订单组合方案提供给用户，可以使提供给用户的优惠最大化，从而有助于进一步提升用户体验。

另外，在对订单进行拆分时，形成至少2种使用至少两个优惠券的组合方案，并且将至少2种组合方案显示在界面供用户选择；在将应付款金额减去优惠券的优惠金额作为实际付款金额时，根据用户选择的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。对订单进行拆分时，会形成不止一个满足条件的子订单组合，将这些子订单组合显示出来供用户选择。由于从而使得用户可以选择更加满意的组合方案，可以进一步保障用户利益的最优化，有助于进一步提升用户体验。

另外，指定页面为用户的付款界面，业务属性值为订单中的应付款金额，预设条件为优惠券的使用条件，第一数值包括：优惠券的面值、优惠券的优惠金额；修正模块在根据获取的所述第一数值对所述业务属性值进行修正时，具体包括：修正模块将所述应付款金额减去优惠券的优惠金额作为实际付款金额。

另外，判断模块，还用于判断应付款金额是否满足至少两个优惠券的使用条件；修正模块，还用于在判断模块判定应付款金额满足至少两个优惠券的使用条件时，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。有多个优惠券可以使用时，自动帮用户填充优惠力度最大的优惠券，可以使得用户在购买商品时能够获得最大的优惠金额，有助于进一步提升用户体验。

另外，业务属性值的更新系统还包含显示模块；判断模块，还用于判断应付款金额是否满足至少两个优惠券的使用条件；显示模块，用于在判断模块判定应付款金额满足至少两个优惠券的使用条件时，将至少两个优惠券显示出来供用户选择；修正模块，还用于将应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。有多个优惠券可以使用时，根据用户的选择使用优惠券，使得用户可以选择更加满意的优惠券，有助于进一步提升用户体验。

附图说明

图1是根据本发明第一实施方式中业务属性值的更新方法的流程图；

图2是根据本发明第二实施方式中业务属性值的更新方法的流程图；

图3是根据本发明第三实施方式中业务属性值的更新方法的流程图；

图4是根据本发明第四实施方式中业务属性值的更新方法的流程图；

图5是根据本发明第五实施方式中业务属性值的更新方法的流程图；

图6是根据本发明第六实施方式中业务属性值的更新方法的流程图；

图7是根据本发明第七实施方式中业务属性值的更新方法的流程图；

图8是根据本发明第八实施方式中业务属性值的更新系统框图；

图9是根据本发明第十实施方式中业务属性值的更新系统框图；

图10是根据本发明第十一实施方式中终端设备的框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种业务属性值的更新方法，具体流程，如图1所示：

步骤S1，提取指定页面内预设位置区域的业务属性值。

步骤S2，判断提取的业务属性值是否满足至少一个预设条件。如果是，则进入步骤S3，否则结束。

步骤S3，获取预设条件获取第一数值，并根据获取的所述第一数值对所述业务属性值进行修正。

通过上述内容，不难发现，通过提取指定页面内预设位置区域的业务属性值，检测提取的业务属性值是否满足至少一个预设条件，并在提取的业务属性值满足至少一个预设条件时，获取预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正，使得，可以自动对业务属性值进行修正，避免用户忘记对业务属性值进行修正或者不知道如何对业务属性值进行修正而给用户带来的利益损失。

本发明的第二实施方式涉及一种业务属性值的更新方法，包括：指定页面为用户的付款界面，业务属性值为订单中的应付款金额，预设条件为优惠券的使用条件，第一数值包括：优惠券的面值、优惠券的优惠金额；在根据获取的第一数值对所述业务属性值进行修正时，具体包括：将应付款金额减去优惠券的优惠金额作为实际付款金额。

比如说，用户的账户仅有一张优惠券，且这张优惠券满足使用条件，那么直接用应付款金额减去优惠券的优惠金额作为实际付款金额。具体流程，如图2所示：

步骤101，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤102，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤103，否则结束。

其中，优惠券的使用条件可以包括但不限于：在有效期内；应付款金额大于或者等于优惠券的面值。具体地说，在优惠券的使用期限内，如果订单中的应付款金额为100元；且仅有一张优惠券的面值为60元，优惠券的优惠金额为30元，即优惠券为满60元减30元的优惠券。应付款金额100元大于优惠券的面值60元，故应付款金额满足优惠券的使用条件，进入步骤103。

步骤103，将应付款金额减去优惠券的优惠金额作为实际付款金额。将应付款金额100元减去优惠券的优惠金额30元作为实际付款金额，即实际付款金额为70元。

与现有技术相比，本实施方式可以在结算商品时，自动帮用户填充符合使用条件的优惠券，避免用户忘记选择优惠券或者不知道如何使用优惠券而带来的利益损失，从而有助于提升用户体验。

本发明的第三实施方式涉及一种业务属性值的更新方法，第三实施方式在第二实施方式基础上作了进一步改进，主要改进之处在于：在第三实施方式中，当存在不止一张满足使用条件的优惠券时，选择使用优惠力度最大的优惠券。

具体流程如图3所示，包括：

步骤201，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤202，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤203，否则结束。

其中，优惠券的使用条件可以包括但不限于：在有效期内；应付款金额大于或者等于优惠券的面值。具体地说，在优惠券的使用期限内，如果订单中的应付款金额为100元；有一张优惠券的面值为60元，优惠券的优惠金额为30元，即优惠券为满60元减30元的优惠券。应付款金额100元大于优惠券的面值60元，故应付款金额满足优惠券的使用条件，进入步骤203。

步骤203，监测满足上述使用条件的优惠券的个数。

步骤204，判断优惠券的个数是否大于1。如果是，则进入步骤205，否则，进入步骤206。

比如说，如果在用户的账号里面不仅有一张满60元减30元的优惠券，还有一张满70减40的优惠券，则进入步骤205。如果只有一张满60元减30元的优惠券，则进入步骤206。

步骤205，将各优惠券的优惠金额做比较，得出优惠力度最大的优惠券。

满60元减30元的优惠券优惠金额为30元，满70减40的优惠券优惠金额为40元。由于优惠金额40元较优惠金额30元的优惠力度大，因此满70元减40元的优惠券的优惠力度最大。

步骤206，将应付款金额减去优惠券的优惠金额作为实际付款金额。将应付款金额100元减去优惠券的优惠金额30元作为实际付款金额，即实际付款金额为70元。

步骤207，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。将应付款金额100元减去优惠力度最大的优惠券的优惠金额40元作为实际付款金额，即实际付款金额为60元。

与现有技术相比，本实施方式中，当有多个优惠券可以使用时，自动帮用户填充优惠力度最大的优惠券，可以使用户在购买商品时能够获得最大的优惠金额，有助于进一步提升用户体验。

此外，值得说明的是，当存在不止一张优惠力度最大的优惠券时，可以按照有效期先到期的方式选择使用其中一张优惠力度最大的优惠券，也可以将这些优惠力度最大的优惠券显示出来供用户选择，也可以从这些优惠力度最大的优惠券中随机选择一张供用户使用。

本发明的第四实施方式涉及一种业务属性值的更新方法。第四实施方式与第三实施方式大致相同，主要区别之处在于：在第三施方式中，在应付款金额满足至少两个优惠券的使用条件时，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。而在本发明第四实施方式中，在应付款金额满足至少两个优惠券的使用条件时，将至少两个优惠券显示出来供用户选择。

具体流程，如图4所示：

步骤301，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤302，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤303，否则结束。

步骤303，监测满足上述使用条件的优惠券的个数。

步骤304，判断优惠券的个数是否大于1。如果是，则进入步骤305，否则，进入步骤306。

步骤305，将满足上述使用条件的优惠券显示出来供用户选择。

步骤306，将应付款金额减去优惠金额作为实际付款金额。

步骤307，将应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。

通过上述内容，不难发现，本实施方式中有多个优惠券可以使用时，根据用户的需要从显示的多个优惠券中选择用户满意度最大的优惠券，从而用户选择的优惠券是用户更加满意的优惠券，进一步提升了用户体验。

本发明的第五实施方式涉及一种业务属性值的更新方法。第五实施方式在第三或第四实施方式的基础上做了改进，主要改进之处在于：在第五式中，应付款金额大于或者等于至少两个优惠券的面值之和时，计算满足使用条件的至少两个优惠券的优惠金额之和，将应付款金额减去优惠金额之和作为实际付款金额。

具体流程，如图5所示：

步骤401，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤402，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤403，否则结束。

步骤403，监测满足上述使用条件的优惠券的个数。

步骤404，判断优惠券的个数是否大于1。如果是，则进入步骤405，否则，进入步骤406。

步骤405，判断应付款金额是否大于或者等于至少两个满足上述使用条件的优惠券的面值之和。如果是，则进入步骤407，否则，进入步骤409。

步骤406，将应付款金额减去优惠金额作为实际付款金额。

步骤407，计算满足使用条件的至少两个优惠券的优惠金额之和。

步骤408，将应付款金额减去优惠金额之和作为实际付款金额。

步骤409，将各优惠券的优惠金额做比较，得出优惠力度最大的优惠券。

步骤410，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

通过上述内容，不难发现，本实施方式中，在用户订单中的应付款金额满足至少两个优惠券叠加的使用条件时，直接将该至少两个优惠券叠加使用，使对用户的优惠力度最大化。

本发明的第六实施方式涉及一种业务属性值的更新方法。第六实施方式在第三、第四或第五实施方式的基础上做了改进，主要改进之处在于：在第六实施方式中，应付款金额大于或者等于至少两个优惠券的面值之和；对订单进行拆分，拆分形成的子订单的最大应付款金额大于或者等于其中至少两个优惠券的面值；将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

具体流程，如图6所示：

步骤501，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤502，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤503，否则结束。

步骤503，监测满足上述使用条件的优惠券的个数。

步骤504，判断优惠券的个数是否大于1。如果是，则进入步骤505，否则，进入步骤506。

步骤505，判断应付款金额是否大于或者等于至少两个满足上述使用条件的优惠券的面值之和。如果是，进入步骤507，否则，进入步骤511。

步骤506，将应付款金额减去优惠券的优惠金额作为实际付款金额。

步骤507，对订单进行拆分，拆分形成的子订单的最大应付款金额大于或者等于其中至少两个优惠券的面值。

比如：订单中的应付款金额为80元，优惠券分别为：一张满40元减20元，一张满30元减10元，一张满50元减30元。根据订单中的商品对订单进行拆分时，如果拆分形成两个子订单，那么拆分形成的子订单的最大应付款金额应该大于或者等于40元。

步骤508，判断形成的使用至少两个优惠券的组合方案是否大于1种。如果是，则进入步骤509，否则，进入步骤510。

比如：根据订单中的商品对订单进行拆分时，如果拆分形成两个子订单，并且两个子订单的应付款金额只能为：35元和45元，则优惠券的组合方案只有一种，35元的子订单使用一张满30元减10元的优惠券，45元的子订单使用一张满40元减20元的优惠券，进入步骤410。

如果拆分形成两个子订单，并且两个子订单的应付款金额可以为：35元和45元；30元和50元。则优惠券的组合方案为：第一种组合方案，35元的子订单使用一张满30元减10元的优惠券，45元的子订单使用一张满40元减20元的优惠券。第二种组合方案，30元的子订单使用一张满30元减10元的优惠券，50元的子订单使用一张满40元减20元的优惠券。第三种组合方案，30元的子订单使用一张满30元减10元的优惠券，50元的子订单使用一张满50元减30元的优惠券，则进入步骤409。

步骤509，根据优惠力度最大的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

第一种组合方案的优惠总金额为(10+20)元，第二种组合方案的优惠总金额为(10+20)元，第三种组合方案的优惠总金额为(10+30)元。第三种组合方案的优惠力度最大。

30元的子订单使用一张满30元减10元的优惠券之后，实际付款金额为应付款金额30元减去优惠券的优惠金额10元作为子订单的实际付款金额。50元的子订单使用一张满50元减30元的优惠券之后，实际付款金额为应付款金额50元减去优惠券的优惠金额30元作为子订单的实际付款金额。因此，总的实际付款金额为(30-10+50-30)元。

步骤510，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

35元的子订单使用一张满30元减10元的优惠券之后，实际付款金额为应付款金额35元减去优惠券的优惠金额10元作为子订单的实际付款金额。45元的子订单使用一张满40元减20元的优惠券之后，实际付款金额为应付款金额45元减去优惠券的优惠金额20元作为子订单的实际付款金额。因此，总的实际付款金额为(35-10+45-20)元。

步骤511，将各优惠券的优惠金额作比较，得出优惠力度最大的优惠券。

步骤512，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

通过上述内容，不难发现，本实施方式中，如果一个订单只能使用一张优惠券，且用户订单中的应付款金额满足至少两个优惠券叠加的使用条件时，可以对订单进行拆分，使拆分形成的每一个子订单对应一张优惠券；从而，可以使对用户的优惠力度最大化。

本发明的第七实施方式涉及一种业务属性值的更新方法。第七实施方式与第六实施方式大致相同，主要区别之处在于：在第六实施方式中，根据优惠力度最大的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。而在本发明第七实施方式中，对订单进行拆分时，将拆分形成的至少2种组合方案显示在界面供用户选择。并根据用户选择的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

具体流程，如图7所示：

步骤601，在用户的付款界面，监测用户订单中的应付款金额。其中，应付款金额指的是订单中各商品的总金额。

步骤602，判断应付款金额是否满足优惠券的使用条件。如果是，则进入步骤603，否则结束。

步骤603，监测满足上述使用条件的优惠券的个数。

步骤604，判断优惠券的个数是否大于1。如果是，则进入步骤605，否则，进入步骤606。

步骤605，判断应付款金额是否大于或者等于至少两个满足上述使用条件的优惠券的面值之和。如果是，进入步骤607，否则，进入步骤612。

步骤606，将应付款金额减去优惠券的优惠金额作为实际付款金额。

步骤607，对订单进行拆分，拆分形成的子订单的最大应付款金额大于或者等于其中至少两个优惠券的面值。

步骤608，判断形成的使用至少两个优惠券的组合方案是否大于1种。如果是，则进入步骤609，否则，进入步骤611。

步骤609，将上述组合方案显示在界面供用户选择。

步骤610，根据用户选择的组合方案，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

步骤611，将每个子订单的应付款金额减去满足应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

步骤612，将各优惠券的优惠金额作比较，得出优惠力度最大的优惠券。

步骤613，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

通过上述内容，不难发现，本实施方式中，对订单进行拆分时，会形成不止一个满足条件的子订单组合，将这些子订单组合显示出来供用户选择。由于从而用户选择的组合方案通常是用户更加满意的，所以可以进一步保障用户利益的最优化，提升了用户体验。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包含相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第八实施方式涉及一种业务属性值的更新系统，如图8所示，包括：提取模块81、判断模块82、修正模块83；提取模块81，用于提取指定页面内预设位置区域的业务属性值；判断模块82，用于判断提取模块81提取的业务属性值是否满足至少一个预设条件；修正模块83，用于在判断模块82判定提取的业务属性值满足至少一个预设条件，根据预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正；其中，预设条件至少包括：当前时刻处于预设条件的有效期内，提取的业务属性值大于或等于第一数值中最大的数值。

不难发现，本实施方式为与第一实施方式相对应的系统实施例，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第九实施方式涉及一种业务属性值的更新系统，指定页面为用户的付款界面，业务属性值为订单中的应付款金额，预设条件为优惠券的使用条件，第一数值包括：优惠券的面值、优惠券的优惠金额；修正模块在根据获取的所述第一数值对所述业务属性值进行修正时，具体包括：修正模块将所述应付款金额减去优惠券的优惠金额作为实际付款金额。

进一步地，判断模块，还用于判断应付款金额是否满足至少两个优惠券的使用条件；修正模块，还用于在判断模块判定应付款金额满足至少两个优惠券的使用条件时，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

不难发现，本实施方式为与第三实施方式相对应的系统实施例，本实施方式可与第三实施方式互相配合实施。第三实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第三实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第十实施方式涉及一种业务属性值的更新系统，第十实施方式与第九实施方式大致相同，主要区别之处在于：在第九实施方式中，在应付款金额满足至少两个优惠券的使用条件时，将应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。而在本发明第十实施方式中，在应付款金额满足至少两个优惠券的使用条件时，将至少两个优惠券显示出来供用户选择。

如图9所示，业务属性值的更新系统还包含显示模块93；提取模块91，用于提取指定页面内预设位置区域的业务属性值；判断模块92，还用于判断应付款金额是否满足至少两个优惠券的使用条件；显示模块93，用于在判断模块92判定应付款金额满足至少两个优惠券的使用条件时，将至少两个优惠券显示出来供用户选择；修正模块94，还用于将应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。

由于第四实施方式与本实施方式相互对应，因此本实施方式可与第四实施方式互相配合实施。第四实施方式中提到的相关技术细节在本实施方式中依然有效，在第四实施方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第四实施方式中。

本发明的第十一实施方式涉及一种终端设备。本实施方式的终端设备可以是智能手机、电脑或平板等设备，以下以智能手机为例进行说明，如图10所示，智能手机包括处理器114、存储器113和人机交互设备，人机交互设备通常会包括显示屏112和触摸屏111。

在本实施方式中，用户通过触摸屏111点击相关按钮对业务属性进行操作时，处理器114提取指定页面内预设位置区域的业务属性值，并在检测到提取的业务属性值满足至少一个预设条件，根据预设条件获取第一数值，并根据获取的第一数值对业务属性值进行修正。显示屏112可以显示业务数据的操作信息。

不难发现，本实施方式中，可以使在结算商品时，自动帮用户填充符合购买条件的优惠券，避免用户忘记选择优惠券或者不知道如何使用优惠券给用户带来的利益损失，从而可以提高用户的体验。

由于第八实施方式与本实施方式相互对应，因此本实施方式可与第八实施方式互相配合实施。第八实施方式中提到的相关技术细节在本实施方式中依然有效，在第八实施方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第八实施方式中。

本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (12)

1.一种业务属性值的更新方法，其特征在于，包括：

提取指定页面内预设位置区域的业务属性值；

检测所述提取的业务属性值是否满足至少一个预设条件；

如果所述提取的业务属性值满足至少一个预设条件，根据所述预设条件获取第一数值，并根据获取的所述第一数值对所述业务属性值进行修正；

其中，所述预设条件至少包括：当前时刻处于预设条件的有效期内，所述提取的业务属性值大于或等于所述第一数值中最大的数值。

2.根据权利要求1所述的业务属性值的更新方法，其特征在于，

所述指定页面为用户的付款界面，所述业务属性值为订单中的应付款金额，所述预设条件为优惠券的使用条件，所述第一数值包括：优惠券的面值、优惠券的优惠金额；

在根据获取的所述第一数值对所述业务属性值进行修正时，具体包括：将所述应付款金额减去优惠券的优惠金额作为实际付款金额。

3.根据权利要求2所述的业务属性值的更新方法，其特征在于，

在所述应付款金额满足至少两个优惠券的使用条件时，将所述应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

4.根据权利要求2所述的业务属性值的更新方法，其特征在于，

在所述应付款金额满足至少两个优惠券的使用条件时，将所述至少两个优惠券显示出来供用户选择；

将所述应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。

5.根据权利要求2所述的业务属性值的更新方法，其特征在于，

优惠券的使用条件还包括：所述应付款金额大于或者等于至少两个优惠券的面值之和；

在将所述应付款金额减去优惠券的优惠金额作为实际付款金额时，计算满足使用条件的至少两个优惠券的优惠金额之和，将所述应付款金额减去所述优惠金额之和作为实际付款金额。

6.根据权利要求2所述的业务属性值的更新方法，其特征在于，

优惠券的使用条件还包括：一个订单只能使用一张优惠券；所述应付款金额大于或者等于至少两个优惠券的面值之和；

对所述订单进行拆分，拆分形成的子订单的最大应付款金额大于或者等于其中至少两个优惠券的面值；

在将所述应付款金额减去优惠券的优惠金额作为实际付款金额时，将每个子订单的应付款金额减去满足所述应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

7.根据权利要求6所述的业务属性值的更新方法，其特征在于，

在对所述订单进行拆分时，形成至少2种使用至少两个优惠券的组合方案；

在将所述应付款金额减去优惠券的优惠金额作为实际付款金额时，根据优惠力度最大的组合方案，将每个子订单的应付款金额减去满足所述应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

8.根据权利要求6所述的业务属性值的更新方法，其特征在于，

在对所述订单进行拆分时，形成至少2种使用至少两个优惠券的组合方案，并且将所述至少2种组合方案显示在界面供用户选择；

在将所述应付款金额减去优惠券的优惠金额作为实际付款金额时，根据用户选择的组合方案，将每个子订单的应付款金额减去满足所述应付款金额条件的优惠券的优惠金额作为每个子订单的实际付款金额。

9.一种业务属性值的更新系统，其特征在于，包括：提取模块、判断模块、修正模块；

所述提取模块，用于提取指定页面内预设位置区域的业务属性值；

所述判断模块，用于判断所述提取模块提取的业务属性值是否满足至少一个预设条件；

所述修正模块，用于在所述判断模块判定所述提取的业务属性值满足至少一个预设条件，根据所述预设条件获取第一数值，并根据获取的所述第一数值对所述业务属性值进行修正；

其中，所述预设条件至少包括：当前时刻处于预设条件的有效期内，所述提取的业务属性值大于或等于所述第一数值中最大的数值。

10.根据权利要求9所述的业务属性值的更新系统，其特征在于，

所述指定页面为用户的付款界面，所述业务属性值为订单中的应付款金额，所述预设条件为优惠券的使用条件，所述第一数值包括：优惠券的面值、优惠券的优惠金额；

所述修正模块在根据获取的所述第一数值对所述业务属性值进行修正时，具体包括：所述修正模块将所述应付款金额减去优惠券的优惠金额作为实际付款金额。

11.根据权利要求10所述的业务属性值的更新系统，其特征在于，

所述判断模块，还用于判断所述应付款金额是否满足至少两个优惠券的使用条件；

所述修正模块，还用于在所述判断模块判定所述应付款金额满足至少两个优惠券的使用条件时，将所述应付款金额减去优惠力度最大的优惠券的优惠金额作为实际付款金额。

12.根据权利要求10所述的业务属性值的更新系统，其特征在于，所述业务属性值的更新系统还包含显示模块；

所述判断模块，还用于判断所述应付款金额是否满足至少两个优惠券的使用条件；

所述显示模块，用于在所述判断模块判定所述应付款金额满足至少两个优惠券的使用条件时，将所述至少两个优惠券显示出来供用户选择；

所述修正模块，还用于将所述应付款金额减去用户选择的优惠券的优惠金额作为实际付款金额。