一种费用报销管理方法及装置

本发明涉及系统集成领域，尤其涉及一种费用报销管理方法及装置。

随着计算机技术的发展，一些单位开始采用线上方式来完成员工差旅费用的报销审批流程，这样一来可以大大提高工作的效率。而随着公司规模的发展，很多公司开始在不同地点分别设立独立的组织，不同组织具有独立的财务系统。为了实现线上方式完成员工差旅费用报销审批的流程，则每个独立的财务系统都需要对应一套独立的报销系统来完成上述功能，这样一来不仅影响用户的使用体验，还增加了单位购买、维护系统的成本。

本发明提供一种费用报销管理方法及装置，能够简化费用报销的程序，提高工作效率。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明实施例提供一种费用报销管理方法，该方法应用于报销审批平台；报销审批平台与至少两个财务系统连接，至少两个财务系统中每个财务系统分别对应一个报销单位；该方法包括：获取费用申请；确定费用申请对应的报销单位；判断费用申请是否符合支付要求；若费用申请符合支付要求，则生成报销单，并将报销单发送至与报销单位对应的财务系统。

第二方面，本发明实施例提供一种报销审批平台，该报销审批平台与至少两个财务系统连接，至少两个财务系统中每个财务系统分别对应一个报销单位；该报销审批平台包括：获取单元，用于获取费用申请；单位确定单元，用于确定费用申请对应的报销单位；审核单元，用于判断费用申请是否符合支付要求；单据生成单元，用于若费用申请符合支付要求，则生成报销单，并将报销单发送至与报销单位对应的财务系统。

第三方面，本发明实施例提供一种报销审批平台，包括：处理器、存储器、总线和通信接口；存储器用于存储计算机执行指令，处理器与存储器通过总线连接，当报销审批平台运行时，处理器执行存储器存储的计算机执行指令，以使报销审批平台执行如上述第一方面所提供的费用报销管理方法。

第四方面，本发明实施例提供一种计算机存储介质，包括指令，当其在报销审批平台上运行时，使得报销审批平台执行如上述第一方面所提供的费用报销管理方法。

本发明实施例中，通过在获取费用申请之后自动确定费用申请对应的报销单位，然后将费用申请对应的报销单发送给相应的财务系统，以便财务系统根据报销单完成相应的付款、做账等流程，这样一来各个报销单位的财务系统就不需要建立独立的报销系统来完成费用报销审批的功能，仅仅需要通过预设的接口接收生成的报销单即可，简化了各个报销单位的财务系统的负荷，提高了工作效率。并且当用户需要在不同组织进行费用报销时，由于本方法中在获取到费用申请之后会自动确定费用申请的报销单位，进而将生成的报销单发送给对应的报销单位的财务系统，而不需要用户再分别向不同报销单位提交报销单，简化了用户在费用报销审批时需要进行的步骤，提高用户使用体验。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本发明实施例提供的一种费用管理系统的结构示意图；

图2为本发明实施例提供的一种费用报销管理方法的流程示意图像；

图3为本发明实施例提供的一种报销审批平台的结构示意图；

图4为本发明实施例提供的一种报销审批平台的结构示意图；

图5为本发明实施例提供的一种报销审批平台的结构示意图。

下面结合附图，对本发明的实施例进行描述。

在本发明实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。此外，在本发明实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。

首先，对本发明的发明原理进行介绍：目前，一些单位已经开始采用线上方式完成员工差旅费用的报销审批流程。其中，对于很多规模较大的单位,由于有多个独立的分支组织或机构，如子公司、分公司，都需要有独立的财务系统，因此就需要建立独立的报销审批程序与财务系统进行集成。

对此，本发明中考虑到如果能够通过同一平台来完成不同分支组织、机构的报销审批程序，则可以省去为每个财务系统集成报销审批程序的工作。同时，员工还可以根据需要选择相应的分支组织的财务系统完成报销。例如，员工在分支组织之间调动时，不需要重新适应新的报销审批程序，而依然使用之前的报销审批程序就可以完成报销审批的流程，进而可以大大提高工作效率。

为了实现上述技术效果，本发明实施例提供一种费用管理系统，如图1所示，该费用管理系统包括：费用报销管理平台101以及至少两个财务系统102a、102b(图1中仅示例性画出两个财务系统，可以理解的是费用管理系统10中还可以有更多的财务系统，对此本发明不做限制)。其中，报销管理平台101与财务系统102a以及财务系统102b分别连接。财务系统102a和财务系统102b分别对应不同的报销单位。其中，报销单位具体可以指建立独立财务系统的子公司、分公司等单位机构。

例如，以某大型国有企业A为例，财务系统102a可以为企业A的北京分公司的财务系统，财务系统102b可以为企业A的上海分公司的财务系统，另外基于相同原理还可以有更多的财务系统分别对应企业A的其他分公司，在此不再赘述。

其中，报销管理平台101可以通过预设通信接口，向财务系统102a、102b发送报销单等数据。

另外，如图1所示，该费用管理系统还可以包括用户终端103。用户终端103与报销管理平台101连接。用户终端103可以用于向报销管理平台101发送费用申请等信息。

此外，图1中，该费用管理系统还可以包括至少两个审批系统，审批系统104a、审批系统104b(图1中仅示例性画出两个审批系统，可以理解的是费用管理系统10中还可以有更多的审批系统，对此本发明不做限制)。其中，与上述财务系统102a、102b类似，审批系统104a和审批系统104b分别对应不同的报销单位，并且审批系统与财务系统一一对应。审批系统104a和审批系统104b分别用于审批对应的报销单位的费用申请，并将审批结果反馈给报销管理平台101。在一种实现方式中，报销管理平台101在接收到审批系统104a或者104b的审批结果后，可直接向第三方系统105完成采购操作。例如，第三方系统105可以是航空公司购票系统、酒店预订系统等，报销管理平台101在接收到审批系统104a的审批结果后，可直接向航空公司购票系统、酒店预订系统完成机票购买、酒店预订等操作。

实施例一：

参照如图1所示的费用管理系统，本发明实施例提供一种费用报销管理方法，可以应用于如图1所示管理系统10中的报销审批平台101或者原理类似的管理系统的报销审批平台。如图2所示，该方法包括：

S201、报销审批平台获取费用申请。

具体的，用户在出差等需要花费单位资金的情况下，会向报销审批平台发送费用申请。在一种实现方式中，步骤S201具体包括：

获取用户终端发送的费用申请指令；费用申请指令中包括费用信息以及用户终端的账户信息。

示例性的，用户可以利用如图1中的用户终端103，通过对用户终端103的相应操作，来触发向报销审批平台101发送费用申请指令，报销审批平台即可解析出费用申请指令中的费用申请以及发送指令的用户终端的账户信息。

本发明实施例中所称获取费用申请，在具体实现时，可以是获取到一条包含用户本次花费的金额、类型等信息的数据，或者是获取到能够解析出用户本次花费的金额、类型等信息的标识，例如报销审批平台获取到一条订单编码，通过该订单编码可以解析出相应的用户本次花费的金额、类型等信息。具体获取费用申请的方式，本领域技术人员可以在具体实现时根据需要选择相应的具体方式。对此本发明可以不做限制。

S203、报销审批平台确定费用申请对应的报销单位。

在报销审批平台获取到费用申请之后，报销审批平台会确认本次费用申请对应的报销单位。如图1所示，报销审批平台101需要确定本次费用申请对应的财务系统102a对应的报销单位还是财务系统102b对应的报销单位。

在一种实现方式中，报销审批平台可以通过解析费用申请中的信息，确定费用申请对应的报销单位。

例如，在报销审批平台接收到的费用申请中包括有本次费用申请对应的报销单位代码。进而通过解析费用申请中的信息，确定费用申请对应的报销单位。例如，确定费用申请对应的报销单位为企业A的某个子公司。

在另一种实现方式中，步骤S203包括：报销审批平台通过根据发送费用申请的用户终端的账户信息，在报销审批平台的数据库中查询该账户信息对应的报销单位。因此，为了实现上述技术效果，在报销审批平台确定费用申请对应的报销单位之前，该方法还可以包括以下S202的步骤：

S202、按照预设周期将至少两个财务系统的主数据同步至报销审批平台的数据库。其中，主数据用于确定报销单位所对应的账户信息。

例如，与报销单位X对应的财务系统中存储的主数据中就记录了与报销单位X对应的账户a、账户b、账户c……等账户的账户信息。

进而报销审批平台即可以通过解析发送费用申请的用户终端的账户信息，在报销审批平台的数据库中查询该账户信息对应的报销单位。

可选的，考虑到之后在生成报销单时，报销单中需要包括：报销单位名称、财务系统名称、报销单位的部门名称、工程项目名称、工程项目中子项目名称、员工名称以及本次费用申请对应的费用类型等信息。因此，可以在步骤S2021至少两个财务系统将主数据同步至报销审批平台的数据库时，同时将上述数据同步至报销审批平台的数据库中。因此本发明实施例的主数据中，还包括：账户信息对应的报销单位标识、财务系统标识、报销单位的部门标识、工程项目标识、工程项目中子项目标识、员工标识以及本次费用申请对应的费用类型标识。由此，报销审批平台就可以利用上述数据生成报销单中的报销单位名称、财务系统名称、报销单位的部门名称、工程项目名称、工程项目中子项目名称、员工名称以及本次费用申请对应的费用类型等信息。

其中，至少两个财务系统将主数据同步至报销审批平台的数据库，具体可以包括全量同步、增量同步两种同步方式，其中：

全量同步，具体指同步数据先存入临时表中，然后清空销审批平台的数据库中对应类型的主数据，再将临时表中的数据同步至销审批平台的数据库中。增量同步，具体指同步数据先存入临时表中，根据每条数据的标识(新增，修改，删除)对销审批平台的数据库中的数据进行对应操作。

全量同步方式用于在报销审批平台与至少两个财务系统中的一个财务系统第一次进行数据同步时，通过全量同步的方式将财务系统总的主数据导入报销审批平台的数据库。增量同步方式用于当财务系统中的主数据更新时，将更新后的主数据同步至销审批平台的数据库。

另外，在一种实现方式中，考虑到当报销单位的数量较大时，报销管理平台的数据库中存储的主数据的数据量也很大。因此，为了方便数据的查询和管理，本发明实施例中报销管理平台的数据库可以采用将不同报销单位的主数据分表存储的方式，使数据量大的报销单位不会拖慢数据量小的报销单位的系统运行效率。示例性的，因为每家报销单位都有唯一的公司代码，所以用公司代码进行区分。

表规则如下：

以ERP系统的主数据存储为例

主表名：erp_masterdata_base_6600

前缀+公司代码

前缀：erp_masterdata_base

公司代码(例)：6600

临时表名：erp_masterdata_base_6600_temp

前缀+公司代码

前缀：erp_masterdata_base

公司代码(例)：6600

后缀：temp

识别逻辑如下：不同报销单位的财务系统在调用报销管理平台提供的主同步接口时，会首先判断调用方是ERP还是其他类型的财务系统，针对不同的财务系统类型走对应的存储逻辑。传递的参数中有一项公司代码，报销管理平台根据公司代码存储在数据库中对应的报销单位的主数据表中。

此外，本发明实施例中为了进一步提高报销审批平台的数据库的查询效率，在一种实现方式中，至少两个财务系统将主数据同步至报销审批平台的数据库，具体还包括：

报销审批平台接收至少两个财务系统发送的主数据，并将主数据进行分条存储在数据库中。其中，每条数据分别包括：报销单位标识、财务系统标识、报销单位的部门标识、工程项目标识、工程项目中子项目标识、员工标识以及本次费用申请对应的费用类型标识。

示例性的，报销审批平台的数据库中的数据模型如下：

其中，公司代码指报销单位的标识,利润中心指财务系统的标识,成本中心指报销单位的部门的标识,内部订单指工程项目标识,WBS指工程子项目的标识,供应商指员工标识,费用类型指费用申请对应的费用类型的标识。

在确定费用申请对应的报销单位之后，本发明实施例所提供的方法还包括：

S204、报销审批平台判断费用申请是否符合支付要求。

考虑到可以采用报销审批平台根据预设判断规则，确定费用申请是否符合支付要求。进而在一种实现方式中，报销审批平台判断费用申请是否符合支付要求，具体的：

1)获取费用申请对应的的报销单位的报销总额度以及单次报销额度；

2)判断本次费用申请是否在报销总额度之内，以及判断本次费用申请的数额是否满足单次报销额度的限制。

3)若满足上述2)的条件，则确定符合支付要求。

在另一种实现方式中，考虑到通常每次员工的费用报销都需要相关领导的审批，因此本发明实施例中步骤S104具体可以包括：

S2041、根据费用申请生成审批请求。

S2042、将审批请求发送至报销单位对应的审批系统，以便审批系统响应于审批请求生成审批结果。

具体的，审批系统在接收到审批请求后，可以将审批请求发送至相应的客户端，以便报销单位的相关领导通过客户端审批本次费用申请。

在审批系统响应于审批请求生成审批结果后，本发明实施例该包括：

S205、接收审批结果。

S206、根据审批结果，执行采购操作。

具体的，审批结果可以包括：同意支付全部费用、同意支付部分费用以及拒绝支付费用三种审批结果。报销审批平台在接收到审批结果之后，会根据审批结果，向第三方系统发出采购指令。

以图1所示的费用管理系统为例，报销管理平台101在接收到审批结果之后，会向第三方系统105发出购买机票、预定酒店等操作。从而实现自动化采购的效果。

本发明实施例中通过获取到费用申请之后自动确定费用申请对应的报销单位，并将审批请求发送至报销单位对应的审批系统中进行审批，从而可以使用户在同一操作界面内完成对不同报销单位的差旅费用的报销审批，简化了报销审批的流程。并且还能根据审批系统发送的审批结果，完成支付费用的操作，从而可以同时完成多个报销单位的支付任务，免除了用户分别向不同报销单位提交审批请求再由不同报销单位分别完成支付费用操作的繁杂流程，提高用户使用体验。

需要说明的是，在具体实现时，若不需要报销管理平台直接完成采购功能，也可以不执行上述步骤S205和S206的内容。

另外，在费用申请符合支付要求之后，本发明实施例还包括：

S207、若费用申请符合支付要求则生成报销单，并将报销单发送至与报销单位对应的财务系统。

具体的，在费用审批平台通过向报销单位对应的审批系统发送审批请求，并接收审批结果的方式，来判断费用申请是否符合支付要求的情况下，费用申请符合支付要求则生成报销单，具体包括：根据审批结果，生成报销单，并将报销单发送至与报销单位对应的财务系统。

本发明实施例中，可以通过在获取费用申请之后自动确定费用申请对应的报销单位，然后将费用申请对应的报销单发送给相应的财务系统，以便财务系统根据报销单完成相应的付款、做账等流程，这样一来各个报销单位的财务系统就不需要建立独立的报销系统来完成费用报销审批的功能，仅仅需要通过预设的接口接收生成的报销单即可，简化了各个报销单位的财务系统的负荷，提高了工作效率。并且当用户需要在不同组织进行费用报销时，由于本方法中在获取到费用申请之后会自动确定费用申请的报销单位，进而将生成的报销单发送给对应的报销单位的财务系统，而不需要用户再分别向不同报销单位提交报销单，简化了用户在费用报销审批时需要进行的步骤，提高用户使用体验。

具体的，为了保证报销单能够准确的发送至报销单位对应的财务系统中，将报销单发送至与报销单位对应的财务系统时，可以建立单据重发机制。具体的，报销审批平台向报销单位的财务系统发送报销单时，为保障数据传输成功率，提供了自动和人工两种重试机制。其中，

自动重试，包括报销单发送时记录传输次数，如果报销单发送失败，则自动发起重试，同时传输次数+1，依此重试预设次数后当天不再发起重试；次日定时任务查询前一天失败的任务，发起一次重试，依此重复预设天数直至成功，如果预设天数内依然没有成功则由生成提示信息。

人工重试：报销审批平台可以提供可视化页面，可针对单据发起人工重试，并设置人工重试次数的上限，当超过上限次数后将不予许人工重试。此时应考虑到数据错误，应修复数据。

S208、报销审批平台根据预设时间段内获取到的费用申请，并按照预设方式生成结算单发送至至少两个财务系统中的对应财务系统。

本发明实施例中，报销审批平台还能够按照预设方式，根据预设时间段内获取到的费用申请，生成相应的结算单，以便财务系统直接可以根据接收到的结算单完成向第三方系统支付费用的操作。

另外，本发明实施例中，报销审批平台可根据报销单位主数据类型查询同步过来的主数据，可对条数以及数据进行校验。财务系统在组织需要同步的主数据时,会对要同步的数据条数,当前批次,总批次进行统计并同步传输给报销审批平台,报销审批平台接收到同步主数据的请求时,会对接收到的主数据条数统计与财务系统同步主数据之前统计的数据条数,当前批次,总批次进行比较,如果数据不一致则拒收数据并对财务系统进行相应的提示。

公司信息集成页提供PI、ESB、UEP、FAC共4中集成方式，同时维护报销单位的报销单和结算单的创建地址，接口验证类信息，报销单位基本信息。

具体的，报销审批平台可以根据不同财务系统的接口协议不同，选择PI、ESB、UEP、FAC，4种集成方式中的一种来与特定报销单位的财务系统进行数据传输。

实施例二：

本发明实施例还提供一种报销审批平台，用于执行上述实施例一所提供的费用报销管理方法。该报销审批平台，应用于如图1所示的费用管理系统中。如图3所示，为本发明实施例提供的报销审批平台的一种可能的结构示意图。具体的，该报销审批平台30，包括：获取单元301、单位确定单元302、审核单元303以及单据生成单元304。其中：

获取单元301，用于获取费用申请；

单位确定单元302，用于确定费用申请对应的报销单位；

审核单元303，用于判断费用申请是否符合支付要求；

单据生成单元304，用于若费用申请符合支付要求，则生成报销单，并将报销单发送至与报销单位对应的财务系统。

可选的，

获取单元301，具体用于获取用户终端发送的费用申请指令；费用申请指令中包括费用信息以及用户终端的账户信息；

单位确定单元302，具体用于根据用户终端的账户信息，确定费用申请对应的报销单位。

可选的，报销审批平台还包括：主数据同步单元305；

主数据同步单元305，用于在单位确定单元302确定费用申请对应的报销单位之前，按照预设周期将至少两个财务系统的主数据同步至报销审批平台的数据库；其中，主数据中包括财务系统中存储的报销单位所对应的账户信息。

可选的，主数据中还包括：账户信息对应的报销单位标识、财务系统标识、报销单位的部门标识、工程项目标识、工程项目中子项目标识、员工标识以及本次费用申请对应的费用类型标识；单据生成单元304，具体用于根据报销单位标识、财务系统标识、报销单位的部门标识、工程项目标识、工程项目中子项目标识、员工标识以及本次费用申请对应的费用类型标识，生成报销单。

可选的，单据生成单元304，还用于根据预设时间段内获取到的费用申请，并按照预设方式生成结算单发送至至少两个财务系统中的对应财务系统。

本发明实施例中提供的报销审批平台中各模块所的功能以及所产生的效果可以参照上述实施例一费用报销管理方法中的对应的描述内容，在此不再赘述。

在采用集成的单元的情况下，图4示出了上述实施例中所涉及的报销审批平台的一种可能的结构示意图。报销审批平台40包括：处理模块401、通信模块402和存储模块403。处理模块401用于对报销审批平台40的动作进行控制管理，例如，处理模块401用于支持报销审批平台40执行图1中的过程S201-S208。通信模块402用于支持报销审批平台与其他实体的通信。存储模块403用于存储报销审批平台的程序代码和数据。

其中，处理模块401可以是处理器或控制器，例如可以是中央处理器(centralprocessing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块402可以是收发器、收发电路或通信接口等。存储模块403可以是存储器。

当处理模块401为如图5所示的处理器，通信模块402为图5的收发器，存储模块403为图5的存储器时，本发明实施例所涉及的报销审批平台可以为如下的报销审批平台50。

参照图5所示，该报销审批平台50包括：处理器501、收发器502、存储器503和总线504。

其中，处理器501、收发器502、存储器503通过总线504相互连接；总线504可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器501可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。

存储器503可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器502用于存储执行本发明方案的应用程序代码，并由处理器501来控制执行。收发器502用于接收外部设备输入的内容，处理器501用于执行存储器403中存储的应用程序代码，从而实现本发明实施例中所述费用报销管理方法。

应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。