具体实施方式
首先对本发明实施例的电信业务结算方法进行说明,该方法包括:
获取业务定制需求,所述业务定制需求中包括对业务属性的取值要求;
获取业务属性的结算优先级;
按照所获取的业务属性的结算优先级顺序,将业务定制需求与业务结算规则进行匹配,根据匹配结果进行业务结算。其中,所述业务结算规则,是包含于业务结算规则集合中的,业务结算规则集合是预先根据业务属性所制订的,在一个业务结算规则集合中,可以包含一条结算规则,也可以包含多条结算规则。
上述方法中,所述按照所获取的业务属性的结算优先级顺序,将业务定制需求与业务结算规则进行匹配,根据匹配结果进行业务结算,具体包括以下步骤:
根据第一优先级属性,将业务定制需求与所述集合中的业务结算规则进行匹配;如果匹配成功的业务结算规则唯一,或完全匹配成功的业务结算规则唯一,则根据该匹配成功的结算规则,进行业务结算;
否则,进一步根据下一优先级属性,将业务定制需求与上一步骤中匹配成功的业务结算规则进行匹配;重复本步骤直至匹配成功的业务结算规则唯一,或完全匹配成功的业务结算规则唯一,则根据该匹配成功的结算规则,进行业务结算;
由于在结算规则中引入了“通配”的取值,因此,上述的匹配成功可以分为两类:完全匹配成功和通配匹配成功。完全匹配成功,是指定制需求中的业务属性的取值与结算规则中的属性取值完全一致;而通配匹配成功,是指定制需求中的业务属性的取值包含于结算规则中属性的通配取值。例如,以“颜色”属性作为匹配依据,则定制需求“红色的Y机型定制终端”与表1a中的规则2完全匹配成功,而与规则3通配匹配成功。
下面将结合附图,对本发明的具体实施例作详细说明。
实施例一:
首先以表1a所示的结算规则集合为例进行说明,假设定制需求为“红色的Y机型终端”,则其定价结算的过程如下:
1)获取各个业务属性的优先级。
业务属性的优先级,可以在制订结算规则时一并进行指定,则该优先级就是由系统的内部获取;也可以根据实际的业务定制需求临时进行指定:例如系统在业务结算之前,向操作人员询问各属性的优先级关系,再根据用户的输入进行后续的结算处理。
优选地,在系统内部会预置一个默认的优先级关系,在结算处理之前,系统会向操作人员展示该默认优先级关系,操作人员可以根据实际业务需求对该优先级关系进行修改,如果不做修改,则系统将根据该默认优先级关系进行后续的结算处理。
对于表1a所示的结算规则集合,其涉及的属性包括“机型”和“颜色”两种,显然,用户在选择终端时,首先应确定要选择的终端类型。因此在本实施例中,属性“机型”的为第一优先级,“颜色”为第二优先级属性。
2)将定制需求与各条结算规则逐级匹配。
首先根据第一优先级属性“机型”,将业务定制需求与结算规则集合中的每条业务结算规则进行匹配。能够匹配成功的规则有规则2和规则3,并且均为完全匹配。由于结果不唯一,因此需要继续进行下一优先级的匹配。
下一优先级属性为“颜色”,由于在上一步中,已经排除了规则1,因此根据“颜色”属性所进行的匹配,仅针对规则2和规则3进行。可以看出,定制需求与规则2和规则3都能够匹配成功,但是能够完全匹配成功的仅有规则2,那么,根据规则2即可以得到最终的结算结果:红色的Y机型终端,结算单价为1050元。
其中,对于某个业务属性的匹配流程,可以参见图1所示,主要包括以下两个判断步骤:
S101,判断当前属性匹配成功的结果是否唯一,如果是,则根据该结果进行结算;如果否,则执行S102。
S102,判断当前属性完全匹配成功的结果是否唯一,如果是,则根据该结果进行结算;如果否,则进一步根据下一优先级属性进行匹配。
根据图1所示及以上描述,我们可以针对不同的定制需求,得到相应的结算方法,举例如下:
如果定制需求为“X机型终端”,则在第一步优先级匹配中,仅有规则1能够匹配成功,因此根据规则1进行结算:结算单价为800元。
如果定制需求为“Y机型终端”或“蓝色的Y机型终端”,则在第一步优先级匹配中,规则2和规则3能够成功匹配并且均为完全匹配成功;在第二步优先级匹配中,规则3能够匹配成功,虽然规则3为通配匹配,但是由于其满足结果唯一的要求,因此根据规则3即可进行结算:结算单价为1000元。
可见,应用本实施例技术方案,每一级的匹配操作仅根据一种属性来进行,并且每一级的匹配操作都是仅针对上一次匹配成功的结算规则来进行,这样,就不需要定制需求中的每种属性与每条结算规则进行逐一对比,从而有效地提高了业务结算的处理效率。
实施例二:
为了便于本技术领域的人员理解,下面将结合定价规则的树形展示图,对实施例一中的结算过程进行描述。
对于表1a所示的结算规则集合,我们首先根据第一优先级属性“机型”将所有的规则划分子集,由于所有规则中涉及到两种“机型”,因此,规则被划分两个子集,其中,子集一包括规则编号1;子集二包括规则编号2、3;如表1b所示:
子集一:
规则编号 |
机型 |
颜色 |
结算单价 |
1 |
X |
任意 |
800 |
子集二:
规则编号 |
机型 |
颜色 |
结算单价 |
2 |
Y |
红色 |
1050 |
3 |
Y |
任意 |
1000 |
表1b
按照上述两个规则子集,可以构建出如图2a所示的判定树。其中,节点A为根节点,表示判定的起点,节点B与节点C为节点A的子节点,分别代表“机型X”和“机型Y”。
在图2a所示的判定树中,节点C中包含两条规则,因此,需要对其进一步细化:将节点C中的规则按照优先级最高的属性“颜色”进行划分,则上述子集二被进一步划分成两个子集,如表1c所示:
规则编号 |
机型 |
颜色 |
结算单价 |
2 |
Y |
红色 |
1050 |
规则编号 |
机型 |
颜色 |
结算单价 |
3 |
Y |
任意 |
1000 |
表1c
按照上述划分,为C节点添加两个子节点:节点D和节点E,分别代表“红色”和“任意颜色”,如图2b所示,此时节点D和节点E中都不再包括其他属性,因此图2b即为最终的价格判定树。
依据判定树的结算过程可以参见图2c所示:由根节点的第一个子节点开始,将定制需求依次与当前节点进行匹配,主要包括以下两个判断步骤:
S201,判断当前节点所代表的属性是否与定制需求匹配,如果是,则执行S202;否则,转到当前节点的兄弟节点,重复执行本步骤。
S202,判断当前节点是否为叶子节点,如果是,则进行业务结算;否则,转到当前节点的子节点,然后执行S201。
需要注意的是,为了遵循“优先匹配特殊规则”的原则,在定制需求与同级的亲兄弟节点进行匹配时,应该保证取值为“任意”的节点是最后一个进行匹配的。
我们依然以定制需求为“红色的Y机型终端”为例,则根据图2b所示的判定树,其定价结算的过程如下:
1)将定制需求与判定树的第一级子节点进行匹配。
第一级子节点的划分所依据的属性为“机型”,需求“红色的Y机型终端”与节点C相匹配。由于节点C不是叶子节点,因此继续将定制需求与节点C的子节点相匹配。
2)将需求与相匹配节点(即节点C)的子节点进行匹配。
节点C的子节点划分所依据的属性为“颜色”,需求“红色的Y机型终端”与节点D相匹配(节点E取值为“任意”,因此优先匹配节点D)。节点D是叶子节点,因此得到“红色的Y机型终端”的结算价格为1050元。
同理,如果定制需求为“X机型终端”,则节点的匹配路径为A-B,节点B为叶子节点,因此得到结算单价为800元。
如果定制需求为“Y机型终端”或“蓝色的Y机型终端”,则节点的匹配路径为A-C-E,节点B为叶子节点,因此得到结算单价为1000元。
可见,本实施例所述的结算流程,其实质思想与实施例一中所描述结算流程是一致的,其中,“判断当前节点是否为叶子节点”对应于实施例一中所述的“判断当前属性匹配成功的结果是否唯一”;“最后对取值为‘任意’的节点是进行匹配”对应于实施例一中的“在匹配成功的结果不唯一的情况下,如果完全匹配成功的结果唯一,则根据该结果进行结算”。
因此,本实施例所描述的内容,其目的是将实施例一所述的结算方法以更为直观的形式表现出来:树形的结构可以更为清晰地展示各种属性的优先级关系;而根据判定树的结算过程,相当于寻找一条从根节点到叶子节点之间的匹配路径。在后面的实施例中,我们也会结合结算判定树来进行相关描述。
实施例三:
以上两个实施例的结算规则及优先级关系比较简单,在本实施例中,将针对一套更为复杂的结算规则及优先级关系,对本发明的业务结算方法进行说明。
假设某结算规则的集合如表2a所示,并且其优先级关系为:
对于Y机型:“供应商”优先级高于“颜色”优先级;
对于Z机型:“颜色”优先级高于“供应商”优先级。
规则编号 |
机型 |
供应商 |
颜色 |
结算单价 |
1 |
X |
任意 |
任意 |
800 |
2 |
Y |
任意 |
任意 |
1000 |
3 |
Y |
省代理 |
任意 |
950 |
4 |
Y |
任意 |
红色 |
1050 |
5 |
Z |
任意 |
任意 |
2100 |
6 |
Z |
省代理 |
任意 |
2000 |
7 |
Z |
任意 |
红色 |
2180 |
表2a
显然,上述优先级关系中,依然隐含着“属性‘机型’的优先级最高”这一信息。并且对于Y机型和Z机型,其后续优先级不同,(由于X机型仅对应一条结算规则,因此不需要考虑后续优先级)。
确定业务属性的优先级之后,就可以通过将定制需求与各条结算规则逐级匹配,得到最终的规则,举例如下:
1)红色的、由“省代理”提供的Y机型定制终端;
首先根据第一优先级属性“机型”,将业务定制需求与所述集合中的每条业务结算规则进行匹配。能够匹配成功的规则有规则2、3和4,并且均为完全匹配。由于结果不唯一,因此需要继续进行下一优先级的匹配。
对于Y机型,其第二优先级属性为“供应商”。根据“供应商”属性所进行的匹配,仅针上一次匹配成功的规则2、3、4进行。其中,规则2、3、4都能够匹配成功,但是能够完全匹配成功的仅有规则3,则根据规则3即可以得到最终的结算结果:红色的、由“省代理”提供的Y机型定制终端,结算单价为950元。
2)蓝色的、由“省代理”提供的Z机型定制终端;
首先根据第一优先级属性“机型”,将业务定制需求与所述集合中的每条业务结算规则进行匹配。能够匹配成功的规则有规则5、6和7,并且均为完全匹配。由于结果不唯一,因此需要继续进行下一优先级的匹配。
对于Z机型,其第二优先级属性为“颜色”。根据“颜色”属性所进行的匹配,仅针上一次匹配成功的规则5、6、7进行。其中,规则5和规则6都能够匹配成功,并且都不是完全匹配,因此需要继续进行下一优先级的匹配。
对于Z机型,其第三优先级属性为“供应商”。根据“供应商”属性所进行的匹配,针对上一次匹配成功的规则5、6进行。其中,规则5和6都能够匹配成功,并且仅有规则6为完全匹配成功,因此根据规则6进行结算:蓝色的、由“省代理”提供的Z机型定制终端,结算单价为2000元。
如果根据实施例二所描述的方法,可以将本实施例的结算规则及属性优先级关系表现为如图3所示的判定树。
需要说明的是,当结算规则比较复杂时,为了避免二义性,我们在生成判定树的过程住,应该注意以下几点:
a.任何一个节点只确定一种属性;
b.亲兄弟节点所判定的属性类型必须相同;
c.对于任意一个节点,最多只能有一个取值为“任意”的子节点。
这样所生成的判定树,就能够保证正确地展现结算规则及属性优先级关系。仍以本实施例中的定制需求1)和2)为例,其根据图3所示判定树的结算过程如下:
1)红色的、由“省代理”提供的Y机型定制终端;
定制需求与判定树的第一级子节点(节点B、C、D)中的节点C相匹配,由于节点C不是叶子节点,因此继续将定制需求与节点C的子节点相匹配。
节点C的子节点包括节点E和节点F,定制需求与节点E相匹配(由于节点F取值为“任意”,因此优先匹配节点E),并且节点E是叶子节点,因此得到:红色的、由“省代理”提供的Y机型定制终端,其结算单价为950元。
2)蓝色的、由“省代理”提供的Z机型定制终端;
定制需求与判定树的第一级子节点(节点B、C、D)中的节点D相匹配,由于节点D不是叶子节点,因此继续将定制需求与节点D的子节点相匹配。
节点D的子节点包括节点G和节点H,定制需求与节点H相匹配,由于节点H不是叶子节点,因此继续将定制需求与节点H的子节点相匹配。
节点H的子节点包括节点K和节点L,定制需求与节点L相匹配,并且节点L是叶子节点,因此得到:蓝色的、由“省代理”提供的Z机型定制终端,其结算单价为2000元。
通过本实施例可以清楚地看到,除了对于第一优先级的属性,需要对每一条结算规则都进行匹配操作之外,对于后续的优先级,都是仅在上一级匹配成功的规则范围内进行匹配。通过判定树,可以更直观地体现这一点:例如对于定制规则1),在整个匹配过程中无需涉及节点G、H、I、J、K和L;而对于定制规则2),在匹配过程中无需涉及节点E、F、I和J。与现有技术相比,其处理效率必然会有显著提高。
实施例四:
以上三个实施例,都是基于“预先制订的业务结算规则,能够满足所有的定制需求”这样一个前提的,因此针对上述每一个定制需求的例子,最终都能够成功匹配到合适的规则进行结算。但是,在实际的业务操作过程中,这个前提经常是无法满足的。如果在结算规则的集合中,针对某个业务属性,其取值全部为确定值而不包括“通配”值,则在结算匹配过程中,就有可能出现匹配不成功的情况。
以实施例三中的结算规则集合为例,参见表2a所示,在所有的规则中,针对“机型”这一属性,三种取值均为确定值。由于没有“任意”这样的通配值,因此,如果定制需求是这三种机型之外的型号,则根据机型属性所进行的匹配将会失败。
如果匹配失败,系统可以反馈失败信息,通知用户或管理员匹配失败的原因。例如定制需求为“W机型的定制终端”,则系统在匹配“机型”属性失败之后,可以输出“找不到W机型终端的结算规则”。进一步的,系统还可以通过人机交互的方式来学习新的结算规则:例如在上述结算失败之后,系统可以进一步向管理员询问该定制需求的结算规则,管理员可以通过键盘等输入设备进行回答。假设管理员输入“1500元”,则系统会在表2a所示的结算规则集合中,添加一条新的规则,如表2b所示,由于定制需求仅涉及“机型”属性,因此在新添加的规则中,只有该属性为具体取值,而对于“供应商”及“颜色”属性,因此系统会为其赋予通配值“任意”。
规则编号 |
机型 |
供应商 |
颜色 |
结算单价 |
8 |
W |
任意 |
任意 |
1500 |
表2b
可以理解的是,应用本发明技术方案之后,系统反馈失败信息的效率也能相应提高。例如定制需求为“红色的W机型的定制终端”,则系统在“机型”这一优先级的匹配过程中即可得出结算失败的结论,而无需再进行“颜色”属性的匹配。
以上各实施例都是以对终端的定价结算为例,事实上,本发明技术方案适用于各类要求高度可定制、规则复杂的业务结算。例如电信业务中的话单批价结算,业务处理措施判定等等,图4所示为一种用于话单批价的结算规则判定树,涉及的业务属性包括:话单类型、漫游类型、通话类型等。例如,定制需求为“省内漫游”,则在匹配过程中,无需涉及节点C、D、F、I、G、H,通过A-J-K的匹配路径,即可得到该定制需求的结算结果:费率为0.6,并且费用类型为“漫游费”。
图5所示为一种用于欠费业务处理的判定树,涉及的业务属性包括欠费金额和客户等级,例如,定制需求为“欠费100元的普通客户”,则在匹配过程中,无需涉及节点C、D、通过A-E-F的匹配路径,即可得到结算结果为“采取双向停机的处理措施”。
上述两个例子在这里仅用作示意,并且,参见之前实施例的介绍,本领域普通技术人员能够得到应用于其他具体业务的结算方法,本说明书不再进行一一列举。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
相应于上面的方法实施例,本发明实施例还提供一种电信业务结算装置,参见图6所示,所述装置包括:
定制需求获取单元610,用于获取业务定制需求;所述业务定制需求中,包括对业务属性的取值要求;
优先级获取单元620,用于获取业务属性的结算优先级;
结算单元630,用于按照所获取的各个业务属性的结算优先级顺序,将业务定制需求与业务结算规则进行匹配,根据匹配结果进行业务结算。
其中,所述业务结算规则,包含于预先根据业务属性所确定的业务结算规则集合中。
参见图7所示,所述结算单元630,可以包括:属性选择子单元631、匹配子单元632和结算子单元633;
属性选择子单元631,用于按照所获取的各个业务属性的结算优先级顺序,为所述匹配子单元632选择用于匹配的业务属性;
匹配子单元632,用于根据所述属性选择子单元631所选择的属性,将业务定制需求与所述集合中的业务结算规则进行匹配;如果匹配成功的业务结算规则唯一,或完全匹配成功的业务结算规则唯一,则将该匹配成功的业务结算规则发送至结算子单元;否则触发所述属性选择子单元,选择下一优先级的业务属性;
结算子单元633,用于根据所述匹配子单元632发送的结算规则,进行业务结算。
参见图8所示,所述电信业务结算装置还可以包括:
结算状态反馈单元640,用于在所述匹配子单元没有成功匹配到业务结算规则时,输出结算失败信息。
学习单元650,用于在所述结算状态反馈单元输出结算失败信息后,根据用户输入,向所述业务结算规则的集合中添加新的业务结算规则。
本发明实施例还提供了一种运营支撑系统,该终端设备包括上述实施例中所述的电信业务结算装置。
以上所提供的装置,按照各种业务属性的优先级顺序,将定制需求与结算规则进行逐级匹配,根据最终匹配成功的计算规则即可进行业务结算。其中,每一级的匹配操作仅根据一种属性,并且每一级的匹配操作都是仅针对上一次匹配成功的结算规则来进行,与现有技术相比,无需将定制需求中的每种属性与每条结算规则进行逐一对比,从而有效地提高了业务结算的处理效率。
对于装置实施例而言,由于其基本相应于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
以上所述仅是本发明的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。