余额计算方法及装置与流程

1.本发明涉及大数据技术领域，尤其涉及余额计算方法及装置。


背景技术：

2.支付结算有广义和狭义之分。狭义的支付结算是指单位、个人在社会经济活动中使用票据(包括支票、本票、汇票)、银行卡和汇兑、托收承付、委托收款等结算方式进行货币给付及其资金清算的行为，其主要功能是完成资金从一方当事人向另一方当事人的转移。
3.广义的支付结算包括现金结算和银行转账结算。支付结算作为一种要式行为，具有一定的法律特征。
4.对于银行系统中的账户而言，账户的支付结算功能是银行提供给客户的基础服务，银行在账户上开展的各项特色功能，又要求在不同的支付结算场景下提供控制账户可用的资金和限额不同，同时账户监管及账户管理对账户的资金使用有一定的约束限制，从而要求不同场景对于指定账户的各种限制、资金和服务，提供不同的服务。
5.账户余额的计算功能使用非常普遍，银行为客户提供的多种多样的金融服务，以及客户结算多种多样的场景要求和不断变化的监管，对账户余额计算规则变化的要求越来越频繁。
6.目前可用余额计算都是各场景下各自编写自己的可用资金的计算方法，没有统一的计算模式，或者统一的计算模式，仅提供常用的计算，无法提供补偿资金、融资工具所能支配的资金，部分限制的豁免场景使用代码直接写入，无法提供较好的可读性、维护性引入风险的可能性高。
7.因此，现有技术的不足在于，没有技术方案能够为客户提供特定场景下余额的查询。


技术实现要素：

8.本发明实施例提供一种余额计算方法，用以解决没有技术方案能够为客户提供特定场景下余额的查询的问题，该方法包括：
9.确定需计算支付交易后的余额的支付场景；
10.根据支付场景在预先设定的若干场景模式中选择对应的场景模型，其中，所述场景模型根据支付交易要求，对账户上的可用资金，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，在输入场景参数后按设定进行支付计算，所述场景参数是标识可用资金、可用资金的类型、以及支付方式的参数；
11.在场景参数输入后，按场景模型设定计算出支付交易后的余额。
12.本发明实施例还提供一种余额计算装置，用以解决没有技术方案能够为客户提供特定场景下余额的查询的问题，该装置包括：
13.支付模块，用于确定需计算支付交易后的余额的支付场景；
14.场景模块，用于根据支付场景在预先设定的若干场景模式中选择对应的场景模
型，其中，所述场景模型根据支付交易要求，对账户上的可用资金，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，在输入场景参数后按设定进行支付计算，所述场景参数是标识可用资金、可用资金的类型、以及支付方式的参数；
15.余额模块，用于在场景参数输入后，按场景模型设定计算出支付交易后的余额。
16.本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述余额计算方法。
17.本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述余额计算方法。
18.本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述余额计算方法。
19.本发明实施例中，与现有技术中没有技术方案能够为客户提供特定场景下余额的查询的技术方案相比，通过已将账户的资金分类，确定了该类型下的支付方式并与此类型对应的限制也进行了分级，所有类型的资金和限制，在场景中进行了关联，表现为是否可见以及使用的优先顺序，分层次表达了计算中的关联关系，由于充分考虑了关联因素并划分了合理的层次，从而可以提供一致的、高度参数化、可适应多种特殊场景的余额计算。
20.进一步的，基于高度参数化的场景模型，大多数场景的设置无需进行开发，配置参数即可实现，既节约成本又提高交付速度；即使部分要素发生变化时，由于充分考虑了关联因素并划分了合理的层次，在新增或调整某一维度的要素时，必然也会考虑其关联影响，可参照同类因素进行软件设计，因此可提高交付速度，降低开发难度和风险。
附图说明
21.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
22.图1为本发明实施例中余额计算方法实施流程示意图；
23.图2为本发明实施例中余额计算架构示意图；
24.图3为本发明实施例中余额计算实施流程示意图；
25.图4为本发明实施例中余额计算装置结构示意图；
26.图5为本发明实施例中计算机设备示意图。
具体实施方式
27.为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。
28.发明人在发明过程中注意到：
29.对于银行系统中的账户而言，账户的支付结算功能是银行提供给客户的基础服务，银行在账户上开展的各项特色功能，又要求在不同的支付结算场景下提供控制账户可
用的资金和限额不同，同时账户监管及账户管理对账户的资金使用有一定的约束限制，从而要求不同场景对于指定账户的各种限制、资金和服务，提供不同的服务。如何准确为客户提供特定场景下可支配的资金规模查询，成为了一个亟需解决的问题。
30.举例来讲，账户可使用的资金可归纳为下列几类：
31.1、账户自有资金(通用资金)：客户可自由支配的，无任何业务背景的资金；
32.2、账户专项使用资金(专项资金)：账户上有特定业务背景的资金，对于其用途有特殊限制规定。例如银行发放的消费贷款资金，监管部门要求仅用于消费不得用于投资理财和房地产买卖；又如为方便某类客户投资，投资的专项资金汇入后，仅能用于购买理财产品，闭环管理后再汇出；
33.3、账户可调拨的其他账户资金(可调拨资金)：客户与银行通过协议规定，可在一定条件下支配其他账户的资金。例如：a账户在余额不足时，可自动从b账户转入需要金额的资金，协议累计上限为50万元；又如账户a在余额不足时，可自动结清与其关联的多个定期账户，支持其对外支付；又如账户a在余额不足时，可实时触发赎回自己的理财产品，支持其对外支付；
34.4、账户通过融资协议或工具可支配的资金(融资资金)：客户与银行通过协议规定，可在一定条件下使用融资协议或工具为账户提供额外的支付额度。例如：账户a在余额不足时，可自动触发发放贷款的功能，发放款项的多少依据之处要求而定，累计不超过20万，客户若使用则需要支付贷款利息；
35.账户资金的使用又有下列几类限制：
36.1、账户限制：账户的冻结、被监管列入黑名单、灰名单等都会影响账户上的资金使用和服务，其中账户冻结根据其来源不同，效力又有不同，例如有权机关冻结的效力就会比挂失冻结的效力强，有挂失冻结的情况下，账户还能进行信用卡还款、贷款还款等场景使用，有冻结的情况下，无法支配融资类服务。
37.2、部分资金限制：指定资金的限制，例如可以针对指定资金进行限制，其余部分不影响客户使用。例如账户a中有客户存款100万，客户开立20万元存款证明后，还可以支配剩余80万；
38.3、场景限制：由于监管部门要求或协议约束限制的，部分场景才能使用特定的资金，例如消费贷款协议提供的实时融资服务，仅可在账户消费的场景下提供，在理财的场景下无法使用。
39.4、累计限额控制：由于监管部门要求或协议限制，账户最大或最小，单笔或各种周期累计限额控制。例如对于对公一般账户，银行与客户约定一定周期的取现额度为40万，客户已取30万，则再进行取现时，仅可再取10万。
40.5、账户对手限制：由于账户业务背景要求，账户仅能与特定对手发生交易。例如在qdii(qualified domestic institutional investors，合格境内机构投资者)业务中，要求客户的本案账户a的收款账户必须是账户b。
41.但是，账户余额的计算功能使用非常普遍，银行为客户提供的多种多样的金融服务，以及客户结算多种多样的场景要求和不断变化的监管，对账户余额计算规则变化的要求越来越频繁。
42.然而，目前可用余额计算都是各场景下各自编写自己的可用资金的计算方法，没
有统一的计算模式，或者统一的计算模式，仅提供常用的计算，无法提供补偿资金、融资工具所能支配的资金，部分限制的豁免场景使用代码直接写入，无法提供较好的可读性、维护性引入风险的可能性高。
43.另外，形式多样的计算公式，让开发人员对系统现状的掌握本就变得困难重重，在此基础上的频繁变化，一方面，开发测试成本高，周期长；另一方面实施风险非常高，一旦出现问题，就会引发客户体验的投诉及舆情风险，对现代商业银行的形象冲击不可估量。
44.基于此，本发明实施例提供的技术方案考虑了可能影响用款的因素，将它们分类转化为参数，提供了一种新的计算余额的机制，该机制在参数化余额计算中，将影响余额计算的因素分类并参数化，每一种因素的扩展，都会提示考虑其影响，各种因素之间的关系定义变得简便而有序，因而应对变更的时候会提供快速、统一、准确的效果，实施周期短、实施成本低、实施风险小，对于大多数关联关系的变更，无需调整程序仅调整参数即可；从而达到为外部提供多种场景的余额算法，对于新增或调整账户资金分类、账户限制类因素，都会变得清晰、便利并且快速。
45.下面结合具体实例进行说明。
46.图1为余额计算方法实施流程示意图，如图1所示，可以包括：
47.步骤101、确定需计算支付交易后的余额的支付场景；
48.步骤102、根据支付场景在预先设定的若干场景模式中选择对应的场景模型，其中，所述场景模型根据支付交易要求，对账户上的可用资金，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，在输入场景参数后按设定进行支付计算，所述场景参数是标识可用资金、可用资金的类型、以及支付方式的参数；
49.步骤103、在场景参数输入后，按场景模型设定计算出支付交易后的余额。
50.具体的，可以依据影响余额计算的各种因素，对其进行合理的归类并设置恰当的参数模型，用以表述目前以及潜在的关联影响。例如，影响余额计算的限制条件有很多，有各种专项资金对场景的要求例如贷款资金、投资资金，有冻结或圈存对资金的限制，例如司法冻结、挂失冻结，又有特殊场景对冻结或圈存的穿透，例如贷款还款可以穿透挂失冻结，强制扣划可以穿透司法冻结等；然后按照这些关系进行余额计算。
51.图2为余额计算架构示意图，如图2所示，至少一种可以实现可以余额计算的功能架构可以将这种参数化的约计算装置划分为五个模块，分别为场景参数管理模块、账户资金分类管理模块、金额限制检查模块、账户限制检查模块和渠道限制检查模块。
52.实施中，可用资金的类型包括以下类型之一或者其组合：
53.专项资金、通用资金、可调拨资金、融资资金。
54.实施中，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，包括：
55.确定可用资金的类型后，依次进行该类型下的可用资金在进行该类型下的支付时的金额限制检查、账户限制检查、渠道限制检查进行设定。
56.具体的，可以将账户资金主要分为四大类，通过场景参数获取到的参数，确定使用那些资金，以及使用资金的顺序。例如客户快捷消费时，资金使用顺序为：专项资金1(例如消费贷款资金)-专项资金2(例如跨境汇款消费专用资金)-通用资金-可调拨资金1(例如资金实时调拨)-可调拨资金2(资金实时下拨)-融资资金1(例如自助贷款资金)，然后就可以
将这些资金依次获取并进行后续的计算加工。
57.实施时，一个要点是可用资金的类型，另一个要点是检查的顺序，也就是该类型下的可用资金在进行该类型下的支付时的金额限制检查、账户限制检查、渠道限制检查，是有顺序的，这就是对资金的分类以及它们之间的潜在的关联影响，下面主要围绕这两点：资金类型、检查顺序来进行说明。
58.图3为余额计算实施流程示意图，如图3所示，在图2所示的功能架构下，以模块为说明主体，实施时可以如下：
59.一、场景参数管理模块。
60.场景参数，是预先设定好的，以场景维度定义的一组决定使用账户哪部分资金，可以突破哪些限制的参数，具体可以包括：
61.1、特殊场景编号，为默认情况下可使用的资金顺序，无金额、账户和渠道维度的特殊突破和限制。例如特殊场景编号00000，规定的可使用资金顺序为“通用资金
”→“
可调拨资金1”(例如资金实时调拨)
→“
可调拨资金2”(资金实时下拨)；
62.2、指定场景编号，规定场景下的各项资金使用顺序，例如客户快捷消费时，资金使用顺序为“专项资金1”(例如消费贷款资金)
→“
专项资金2”(例如跨境汇款消费专用资金)
→“
通用资金
”→“
可调拨资金1”(例如资金实时调拨)
→“
可调拨资金2”(资金实时下拨)
→“
融资资金1”(例如自助贷款资金)；
63.3、指定场景编号，规定场景下的各项资金限制的突破。每一项资金都可能有各自的限制，例如客户使用投资理财专用资金购买了理财产品，从而对这部分专用资金产生了冻结或圈存，虽然目前资金尚未划转，但它已经不能有客户再使用在投资理财专用资金可使用的地方了，对于这个限制，部分场景可能有突破，例如法院强制扣划的场景，在法律和业务规定允许的情况下，可以突破这种限制，进行扣划。
64.4、指定场景编号，规定场景下各项账户限制的突破。每个账户都可能有各自的限制，例如账户冻结，账户的冻结也会划分不同种类，有司法机关进行的司法冻结，有因凭证或密码丢失进行的挂失冻结，有账户用途所规定的限额等等，部分场景可能需要突破这类限制，例如法院强制扣划，需要突破的限制就很多，它可以穿透多种冻结和限额控制，又例如贷款还款，可以突破挂失冻结，atm(automated teller machine，自动取款机)24小时跨行汇款，可以突破挂失冻结。
65.5、指定场景编号，对渠道限制的突破。账户的渠道限制包括由于账户性质或特殊标识引起的渠道交易限制或限额，部分场景可以突破这类限制，例如有权机关强制扣划场景。
66.二、账户资金分类管理模块。
67.账户资金可以分为四大类，通过场景参数获取到的参数，确定使用那些资金，以及使用资金的顺序。例如客户快捷消费时，资金使用顺序为“专项资金1”(例如消费贷款资金)
→“
专项资金2”(例如跨境汇款消费专用资金)
→“
通用资金
”→“
可调拨资金1”(例如资金实时调拨)
→“
可调拨资金2”(资金实时下拨)
→“
融资资金1”(例如自助贷款资金)，就会将这些资金依次获取并进行后续的计算加工。
68.三、金额限制检查模块。
69.对于账户资金中的每一类金额都可能存在对应的限制，此模块结合这些金额对应
的限制以及场景参数的配置，确定每一项资金可使用的部分。
70.四、账户限制检查模块。
71.对于账户可能存在的各类限制，此模块结合这些限制以及场景参数的配置，计算账户总体可用资金。
72.五、渠道限制检查模块。
73.对于指定的渠道，会有相应的限制，此模块结合这些限制以及产经参数的配置，计算账户最终的可用资金。
74.下面以实例进行说明。
75.实施中，在进行金额限制检查、账户限制检查、渠道限制检查时，包括：
76.检查金额限制，在按限制条件检查通过后进入账户限制检查；
77.检查账户限制，在按限制条件检查通过后进入渠道限制检查；
78.检查渠道限制，在按限制条件检查通过后进入余额计算。
79.具体的，针对每一项可使用的账户资金，逐一按照场景对应的金额限制沿用和突破的要求，若沿用，则根据现有限制计算可用金额，若有突破限制条件，根据突破条件和对应金额的限制确定是否可以突破，以及可突破的比例，最终确定单项资金余额，按照指定的资金类型和顺序完成每一项资金余额和限制的加工，逐条保存可用信息，如有报错信息则存储起来，最后将余额加总起来。
80.具体实施中，在按限制条件检查不通过时，进一步包括：
81.保留不通过的信息，并展示。
82.具体的，对外展示账户的余额，根据交易金额计算当前余额是否足够支持交易金额，若不支持，则记录错误信息，展示渠道限额，展示账户限额，展示每一项资金以及对应的余额与限制，展示所有遇到的错误信息。
83.则在余额计算时，可以如下：
84.1、场景参数管理模块需要提前设定场景参数来确定账户可用资金类型和使用顺序，各项金额的显示是否沿用和突破，账户限制的沿用和突破，渠道限制的沿用和突破条件，至少应包括一个默认场景，供无特殊要求的情况下使用，可不设置任何豁免条件，所有限制都沿用，另外需要包括所有特殊的场景，外部进行余额计算的时候，需要指定场景，而指定的场景必须事先已经维护在场景参数管理模块中。
85.场景参数管理模块的参数维护，在需要的时候进行维护和调整即可，不需要每次都维护，如果没有场景的增加或调整，就不需要调整场景参数。
86.2、余额计算需要外部输入的要素可以包括：1.场景、2.交易金额、3.交易对手、4.交易渠道等。
87.3、场景参数管理模块根据输入的场景，找到场景事先维护好的参数，其中包括账户可用资金类型和使用顺序，各项金额的显示是否沿用和突破，账户限制的沿用和突破，渠道限制的沿用和突破。
88.4、根据场景指定的可用资金类型和使用顺序，逐项获取账户资金。
89.5、针对每一项可使用的账户资金，逐一按照场景对应的金额限制沿用和突破的要求，若沿用，则根据现有限制计算可用金额，若有突破条件，根据突破条件和对应金额的限制确定是否可以突破，以及可突破的比例，最终确定单项资金余额，按照4中指定的资金类
型和顺序完成每一项资金余额和限制的加工，逐条保存可用信息，如有报错信息则存储起来，最后将余额加总起来。
90.6、根据账户限制以及场景指定的账户限制沿用和突破条件，检查5步计算所得到的账户总余额，若沿用，则根据现有账户限制计算可用总金额，若有突破条件，则根据突破条件和对应的账户限制确定是否可以突破，最终确定账户限制后的余额，如有报错信息则存储起来。
91.7、根据渠道限制以及场景指定的渠道限制沿用和突破条件，检查目前账户总余额，若沿用，则根据2中指定的渠道对应的限制参数对6步计算后的余额做检查，若有突破条件，则根据突破条件和对应的渠道限制确定是否可以突破，最终确定渠道限制后的余额，如有报错信息则存储起来。
92.8、对外展示账户的余额，根据2中的交易金额计算当前余额是否足够支持交易金额，若不支持，则记录错误信息，展示渠道限额，展示账户限额，展示5中的每一项资金以及对应的余额与限制，展示所有遇到的错误信息。
93.本发明实施例中还提供了一种余额计算装置，如下面的实施例所述。由于该装置解决问题的原理与余额计算方法相似，因此该装置的实施可以参见余额计算方法的实施，重复之处不再赘述。
94.图4为余额计算装置结构示意图，如图4所示，可以包括：
95.支付模块401，用于确定需计算支付交易后的余额的支付场景；
96.场景模块402，用于根据支付场景在预先设定的若干场景模式中选择对应的场景模型，其中，所述场景模型根据支付交易要求，对账户上的可用资金，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，在输入场景参数后按设定进行支付计算，所述场景参数是标识可用资金、可用资金的类型、以及支付方式的参数；
97.余额模块403，用于在场景参数输入后，按场景模型设定计算出支付交易后的余额。
98.实施中，场景模块进一步用于设定包括以下类型之一或者其组合的可用资金的类型：
99.专项资金、通用资金、可调拨资金、融资资金。
100.实施中，场景模块进一步用于在按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定时，包括：
101.确定可用资金的类型后，依次进行该类型下的可用资金在进行该类型下的支付时的金额限制检查、账户限制检查、渠道限制检查进行设定。
102.实施中，场景模块进一步用于在进行金额限制检查、账户限制检查、渠道限制检查时，包括：
103.检查金额限制，在按限制条件检查通过后进入账户限制检查；
104.检查账户限制，在按限制条件检查通过后进入渠道限制检查；
105.检查渠道限制，在按限制条件检查通过后进入余额计算。
106.实施中，余额模块进一步用于在按限制条件检查不通过时，进一步包括：
107.保留不通过的信息，并展示。
108.在实施本发明实施例提供的技术方案时，可以按如下方式实施。
109.图5为计算机设备示意图，如图5所示，计算机设备中包括：
110.处理器500，用于读取存储器520中的程序，执行下列过程：
111.确定需计算支付交易后的余额的支付场景；
112.根据支付场景在预先设定的若干场景模式中选择对应的场景模型，其中，所述场景模型根据支付交易要求，对账户上的可用资金，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，在输入场景参数后按设定进行支付计算，所述场景参数是标识可用资金、可用资金的类型、以及支付方式的参数；
113.在场景参数输入后，按场景模型设定计算出支付交易后的余额；
114.收发机510，用于在处理器500的控制下接收和发送数据。
115.实施中，可用资金的类型包括以下类型之一或者其组合：
116.专项资金、通用资金、可调拨资金、融资资金。
117.实施中，按照可用资金的类型，以及该类型下的支付方式、各支付方式的支付顺序进行设定，包括：
118.确定可用资金的类型后，依次进行该类型下的可用资金在进行该类型下的支付时的金额限制检查、账户限制检查、渠道限制检查进行设定。
119.实施中，在进行金额限制检查、账户限制检查、渠道限制检查时，包括：
120.检查金额限制，在按限制条件检查通过后进入账户限制检查；
121.检查账户限制，在按限制条件检查通过后进入渠道限制检查；
122.检查渠道限制，在按限制条件检查通过后进入余额计算。
123.实施中，在按限制条件检查不通过时，进一步包括：
124.保留不通过的信息，并展示。
125.其中，在图5中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器500代表的一个或多个处理器和存储器520代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机510可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器500负责管理总线架构和通常的处理，存储器520可以存储处理器500在执行操作时所使用的数据。
126.本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述余额计算方法。
127.本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述余额计算方法。
128.本发明实施例中，与现有技术中没有技术方案能够为客户提供特定场景下余额的查询的技术方案相比，通过已将账户的资金分类，确定了该类型下的支付方式并与此类型对应的限制也进行了分级，所有类型的资金和限制，在场景中进行了关联，表现为是否可见以及使用的优先顺序，分层次表达了计算中的关联关系，由于充分考虑了关联因素并划分了合理的层次，从而可以提供一致的、高度参数化、可适应多种特殊场景的余额计算。
129.进一步的，基于高度参数化的场景模型，大多数场景的设置无需进行开发，配置参数即可实现，既节约成本又提高交付速度；即使部分要素发生变化时，由于充分考虑了关联
因素并划分了合理的层次，在新增或调整某一维度的要素时，必然也会考虑其关联影响，可参照同类因素进行软件设计，因此可提高交付速度，降低开发难度和风险。
130.具体的，方案中将账户的余额因素拆分成基本的四类，包括了账户可能的所有资金形式，并且与此结构对应的限制也进行了分级，对应分为了四级，所有类型的资金和限制，在场景参数中进行了关联，表现为是否可见以及使用的优先顺序，整体分层次恰当表达了计算中的关联关系，由于充分考虑了关联因素并划分了合理的层次，在新增某一维度的要素时，必然也会提醒设计者考虑其关联影响，可参照同类因素进行软件设计，在此装置中的改造可提高交付速度，降低开发难度和风险；
131.通过参数设置，可以快速针对现有资金的顺序、限制进行调整，提高大多数需求的交付速度；因而可提供一致的、高度参数化、可适应多种特殊场景的余额计算。
132.基于高度参数化的场景模型，大多数场景的设置无需进行开发，配置参数即可实现，既节约成本又提高交付速度；部分要素发生变化时，由于充分考虑了关联因素并划分了合理的层次，在新增或调整某一维度的要素时，必然也会提醒设计者考虑其关联影响，可参照同类因素进行软件设计，通过改造即可提高交付速度，降低开发难度和风险。
133.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
134.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
135.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
136.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
137.以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。