业务规则管理系统

2024-06-09

业务规则管理系统（精选8篇）

业务规则管理系统第1篇

不断变化的业务需求是软件技术发展的动力, 这种动力不断地改变着软件技术的设计思想、开发方法、软件体系结构和软件管理。目前, 一种新的软件技术——业务规则管理技术正在兴起。实际上, 业务规则并不陌生, 它渗透在企业的每个角落, 随处可见。但是, 目前企业中的业务规则大多数存在于企业业务人员的大脑中, 或者程序手册、合同、协议等非结构化的文档中。即使企业有了信息系统, 规则逻辑也是作为一个过程写进了程序代码中, 当业务和需求发生变化的时候, 不能做出相应的响应变化, 必须伤筋动骨修改原有的程序代码, 带来极大的不便。

业务规则管理 (Business Rules Management) 技术将使我们重新认识业务规则, 重新认识业务规则在整个软件系统中的地位, 以新的方式来表示、运行、管理业务规则, 从而为企业和软件开发商在处理业务规则的问题上提供新的解决方式, 目的就是希望以管理数据的方式管理业务规则[1]。

业务规则管理的研究目前还处于探索阶段, 研究的困难主要在业务规则的模型定义较为抽象[2,3], 无法应用于实际的信息系统开发, 并不能达到缓解“业务规则的不断变化, 不停地修改程序代码”的预期。出现这个问题的关键在于业务规则定义基础不具体, 国外业务规则定义主要集中在使用与业务不相关的纯粹的规则定义方法, 主要包括:规则定义语言[4];描述模版, 如IF…THEN…ELSE…;决策表和决策树[5]。这些方法不能与信息系统中的概念相结合, 无法在信息系统中准确归纳定义业务规则, 进而也就无法将业务规则从程序中抽取出来, 进行类似数据库管理系统对数据的管理。国内关于业务规则管理的研究刚刚兴起, 研究成果相对较少。因此, 对信息系统中业务规则的捕获和定义是整个业务规则管理研究和发展的基础, 具有重要的理论意义和应用价值。

2 业务规则

2.1 业务规则的含义

不同的人群对于业务规则的理解不完全一样, 对于企业管理者而言, 业务规则是企业目标, 是企业战略, 对于企业一般人员而言, 业务规则又可以是企业战术, 而对于做编程的IT人员, 它又可能是业务逻辑。

那么究竟如何对业务规则进行定义呢?业务规则专家组 (BRG) 从不同的角度给出了业务规则的两个定义。第一个定义是从企业的角度来进行定义, 而第二个定义是从IT计算机专业人员的角度出发的:

企业角度的业务规则定义:“从业务的角度看, 业务规则是一种原则, 包含在特定活动或范围内关于指导、操作、实践或过程的行为规范。IT角度的业务规则定义:“从信息系统的角度看, 业务规则是一个定义或限制业务某些方面的声明。业务规则旨在用于断言业务结构, 或者控制或影响业务行为。

2.2 业务规则管理系统

业务规则管理系统是一套用于开发和维护业务规则的工具集合, 包括:规则引擎、规则库、规则语言框架、规则管理集成开发环境等, 提供规则定制和设计、管理、部署、分析等功能。其基本原理是:用一个或多个规则引擎替换以程序代码“固化”在应用系统中的业务逻辑:被提取的业务逻辑就是业务规则;业务规则存储在规则库中;开发人员和业务人员可以使用规则开发工具来创建、修改、查询、部署和管理业务规则。

(l) 规则引擎 (RuleEngine) 规则引擎是嵌入在程序中的执行业务规则的软件组件, 是业务规则管理系统的核心元素。其基本机制是:对提交给引擎的数据对象进行检索, 根据这些对象的当前属性值和对象之间的关系, 从规则集中发现符合条件的规则, 创建这些规则的执行实例, 在引擎接到执行指令时, 依照某种优先顺序依次执行。

规则引擎分3部分构成:

工作区 (WorkingMemory) 用于存放被规则引擎引用的数据对象的集合。

规则执行队列 (Agenda) 用于存放被激活的规则执行实例。

静态规则区用于存放所有被加载的业务规则。

(2) 规则库 (Rule posito) 业务规则存储在规则库中, 完全独立于数据和程序。管理业务规则如同管理数据库的数据一样, 使用规则查询语言, 可以对业务规则进行查询、添加、更新、统计、提交等操作;使用带锁机制能在线修改业务规则;还包含历史记录、权限管理、设定规则的有效期和版本控制等服务。规则库可以依托于文件系统或数据库系统, 文件格式一般符合可扩展标记语言的元数据交换 (XMI) 标准, 遵循与元数据 (MetaData) 表示和交换相关的规范。

一个完整的业务规则管理系统 (BRMS) 应该具有如下功能:

(l) 规则管理功能;

(2) 规则部署功能;

(3) 规则分析功能;

(4) 规则定制和设计功能。

3 业务规则建模

3.1 业务规则分类

业务规则根据不同的分类标准有多种分类方法, 根据以上的分类原则可对业务规则分类如下:约束类规则、派生类规则以及行为规则。

3.1.1 约束规则

约束规则被用来检查关于某一主题的事件的执行结果, 在约束规则中, 主题要么是术语 (即与业务相关的词或短语) , 要么是事实 (即对于两个术语间关系的断言) 。约束规则又被细分为强制性约束规则和指导性业务规则。它们之间的区别在于, 当发生的业务事件违反强制性约束规则时, 规则拒绝继续向下执行, 而当违反指导性业务规则时, 规则给用户以警告, 可以继续执行。

3.1.2 行为规则

行为规则是关于业务的动态方面的规则。它指定了当某一事件发生或当需要满足的条件满足时动作应该被激活。测试事件及条件可以不只一个, 它可以用逻辑连接词连结起来, 逻辑连接词包括AND、OR、NOT。行为规则可以进一步被分类为使能规则, 复制规则以及触发规则。使能规则可以根据一些条件, 使一个规则、操作、流程或程序段有效或无效。它也可以在一个特定的条件下创建或删除一些数据。复制规则涉及到现有的数据或值, 例如, 利用某一个值给一个对象的属性设置初始值或者决定如何呈现现有的数据。触发规则是当给定的条件成真或者某一特定的事件发生时, 可以引起操作、过程、程序段或规则的执行。在多数情况下, 动作断言可以改变一个主题实例的状态。

3.1.3 派生规则

派生规则是根据现有的术语或事实, 可以派生出一个新的事实。派生规则又被进一步细分两类规则, 计算规则和推导规则。计算规则是利用算术运算可以派生出一个新的算术值, 推导规则是利用逻辑推理或推断可以派生出一个新的事实。推导规则也可以用来表述许可策略, 如用户数据的安全策略。

3.2 业务规则的表示

业务规则的表达方法可以被用来捕获、存储和实现业务规则。我们利用具有良好结构形式, 即模板形式来表示业务规则。每种类型的规则都可以和一个或多个模板相联系, 分类模板提供了用类自然语言描述业务规则的标准格式。

4 业务规则实现

系统开发方法的一个基本目的就是允许用户对于业务规则的管理以及提供业务规则的追溯能力。开发方法的另一个基本目的就是软件组件的冲击影响降低到最低程度, 虽然业务规则是经常发生变化的, 但是我们可以把由于这种变化所引起的对于软件组件的影响降低为最小化。例如, 当业务规则发生变化时, 能够自动的迅速定位到仅与变化业务规则相关的软件组件, 对这些组件的改变就可以完成对于系统的升级维护。

为了达到上述两个基本目标, 我们主要使用三个组件来开发一种易于维护的软件系统。这三个组件分别是业务规则组件、软件设计组件以及连接组件。通过连接组件把业务规则组件与软件设计组件联系起来, 就可以达到开发易于升级维护的软件系统。其中相关联的业务规则组件与软件设计组件之间的关系是软件设计组件对业务规则组件的软件实现。

4.1 业务规则组件

业务规则组件以结构化的形式或模板表示和储存, 这样有利于与相关的软件设计组件相关联。除此之外, 业务规则组件还应该包括与该业务规则相关的管理信息, 如业务过程及业务规程的创建者的信息。

4.2 软件设计组件

软件设计组件的初步模型可以由在业务规则获取活动中得到的术语和事实而得到。一般情况下, 这些术语和事实可以标识为软件设计中的类、属性和它们之间的关系。由于要把业务规则与相关的软件设计组件关联起来, 可能在关联时, 要扩充一些类、属性和操作增加到软件设计模型中, 这些类、属性和操作主要是包含一个必需的映射信息。

4.3 连接组件

连接组件的模型的功能主要是把业务规则与相关的软件设计组件关联起来, 并包含一些映射信息, 同时还要把因为这些映射信息而新增加的类、属性和操作增加到先前的软件设计模型中。

我们给出映射活动的结构图, 如图1所示:

其中, 业务规则模型规定了业务规则的结构和语义。连接模型负责把业务规则模型与软件设计元模型关联起来。业务规则模型、连接模型以及软件设计元模型三者以及它们之间的关系就组成了规则映射的元模型。图1中给出了映射元模型以及该元模型的实例。

5 总结

本文就业务规则管理的优点、业务规则的概述、业务规则映射模型进行比较详细的介绍。我们有理由相信, 在不久的将来, 基于业务规则的信息系统开发方法将成为主流的软件开发方法, 到那时, 企业的信息系统将会随着业务需求的变化做出即时的响应, 使得企业的软件维护费用降至最低。

摘要：业务规则管理技术成为当前的研究热点。本文全面介绍了业务规则管理技术的基本原理、基本概念。重点介绍了对于业务规则建模和业务规则的实现两个方面的技术, 介绍了当前比较公认的一种业务规则模型, 通过把业务规则映射到相应的软件组件来实现, 业务规则与软件组件通过连接组件联系起来, 这样当业务规则发生变化时, 可以通过连接组件, 迅速定位到相应的软件程序代码部分, 对其做出少量修改甚至不做任何修改。

关键词：业务规则,业务规则建模,业务规则实现,业务规则管理系统

参考文献

[1]Morgan T.Business Rules and Information Systems.Boston:Ad-dison-Wesley, 2002.

[2] GUIDE Business Rules Project, "Defining Business Rules - What are they are really", 2000.

[3] Business Rules Group.The Business Motivation Model Business Governance in a Volatile World.January 2005.

[4]Jan Demey, Mustafa Jarrar, Robert Meersman:"Markup Lan-guage for ORMBusiness Rules", In International Workshop on Rule Markup Languages for Business Rules on the Semantic Web, First International Semantic Web Conference, ISWC, (2002) .

上公司税务风险内控管理业务规则第2篇

（征求意见稿）

第一章总则

第一条【制定依据】为了规范涉税专业服务机构及其涉税服务人员从事上市公司税务风险内控管理业务的执业行为，明确上市公司税务风险内控管理业务执业责任，根据《中华人民共和国税收征收管理法》及其实施细则和《涉税专业服务监管办法(试行)》、《涉税专业服务业务规范基本准则》、《税收策划业务准则》等税收法律、法规、规章及规范性文件和业务规范的规定，制定本规则。

第二条【适用范围】税务师事务所、会计师事务所、律师事务所及其税务师、注册会计师、律师承接上市公司税务风险内控管理业务适用本规则。承接其他企业、单位税务风险内控管理业务参照适用。

第三条【概念定义】本准则所称上市公司税务风险内控管理业务是指税务师事务所、会计师事务所、律师事务所接受委托，从事建立、完善上市公司税务风险内控管理制度的业务。其他涉税内控管理、咨询、评估等业务适用其他业务规则。

第四条【信息填报】涉税专业服务机构在纳税申报代理完成后应当向税务机关征管系统中涉税专业服务管理信息库填报《涉税专业服务机构实名信息采集表》、《从事涉税服务人员实名信息采集表》、《涉税专业服务协议信息采集表》、《涉税专业服务专项报告采集表》、《涉税专业服务机构年度报告表》等资料。第五条【信任保护】涉税专业服务机构在执行业务时，应确立信任保护规则，对自身的合法执业权益加以保护。如委托人作出违反法律法规及其规定行为，提供不真实、不完整资料信息行为，不按业务结果进行申报事项行为，或存在其他限制业务实施的行为，涉税专业服务机构及其从事涉税服务人员有权终止业务，并就已经完成事项进行免责性声明，由委托人自行承担相应后果。

第二章业务承接

第六条【承接规则】涉税专业服务机构承接上市公司税务风险内控管理服务业务，应当按照《涉税专业服务程序准则》的规定执行。

第七条【沟通调查】涉税专业服务机构及其专业服务人员应当与委托方进行沟通，确保其已经清楚理解上市公司税务风险内控管理业务执业程序和业务约定条款，并从以下方面进行分析评估，决定是否接受委托：

（一）上市公司的基本情况；

（二）上市公司内部税收环境、内控管理建立情况以及公司外部环境；

（三）本涉税专业服务机构是否具有相应的专业服务能力；

（四）本涉税专业服务机构是否可以承担相应的风险；

（五）其他相关因素。

第八条【签订协议】涉税专业服务机构决定承接上市公司税务风险内控管理服务业务的，应根据《涉税专业服务程序准则》的规定，与委托方书面签订业务委托协议。第九条【协议条款】上市公司税务风险内控管理服务业务委托协议应当对下列事项进行约定，包含但不限于：

（一）委托事项；

（二）具体服务内容；

（三）双方的权利和义务：

（四）委托服务费用的约定；

（五）保密条款；

（六）协议变更与违约责任；

（七）法律适用的争议解决；

（八）其他约定事项。

第十条【风险控制】涉税服务人员发现委托人提供的数据及信息严重偏离业务委托协议内容，对服务内容形成有重大影响时，专业服务人员应与委托人讨论修改业务委托协议的相关内容，如不能达成共识，则协商终止项目。

第三章业务计划

第十一条【遵循规则】涉税专业服务机构承接业务后，应当按照《业务计划规则》的规定，合理制定工作计划，以有效执行上市公司税务风险内控管理业务。

第十二条【胜任人员】涉税专业服务机构应当指派胜任上市公司税务风险内控管理业务的人员，作为项目负责人具体承办。

第十三条【了解情况】在制定工作计划前，项目负责人应当了解以下事项：

（一）委托目的及范围；

（二）委托人的基本概况、经营状况、行业涉税特点、执行会计政策和相关税收政策情况等；

（三）对项目进行风险评估，包括委托人的财务风险、纳税风险、管理风险以及政策风险等；

（四）合理估计完成工作需要的时间；

（五）其他事项。

第十四条【计划内容】上市公司税务风险内控管理业务工作计划一般应包括下列内容：

（一）委托人基本情况。主要包括委托人所属行业及行业涉税特点、基本业务情况、内控管理建议及执行情况、执行的会计管理等；

（二）业务小组成员。在确定业务小组成员，特别是确定项目负责人时，应充分考虑其从业经验、专业素质等方面；

（三）建立税务风险内控管理工作进度及完成时间。项目负责人应对工作的进度及完成时间做出规划，明确各阶段的执行人及执行日期，资料的交接方式、时间、及预计服务完成时间等；

（四）其他相关内容。

第四章业务实施

第一节建立内控管理要求及实施程序

第十五条【基本要求】涉税服务人员建立税务风险内控管理时，应全面、系统、持续地、收集内部和外部相关信息，了解公司内部环境，查找及评估公司经营活动及业务流程中的税务风险，建立有效的内部控制机制，合理设计税务管理、信息沟通的流程及风险控制、监督以及改进方法。

第十六条【内部信息采集】充分收集、了解公司内部的各项管理管理、业务流程、组织架构、会计管理的选择和运用、纳税申报资料、财务信息、税务检查情况等资料。

第十七条【外部信息采集】充分收集、了解公司近年来的公告等披露信息、所属行业经营状况及特点、外部监督评价情况、法律环境、监管环境等资料。

第十八条【整理分析】对收集的资料进行整理，按照税务风险内部控制管理的内容进行分类，制作工作底稿。

第十九条【分析评估】通过现场核查、座谈或其他多种方式，对现有的与税收相关的内部控制管理进行实质性测试，通过数据比对以及测试指标情况，复查涉税异常事项，识别纳税风险点，对公司现有税务风险内控管理管理及情况进行评价。

第二十条【建立控制模型】根据公司的基本情况、业务流程、组织架构以及纳税风险点建立税务风险内控管理架构，梳理内控管理应包括的内容。

第二十一条【信息化系统】根据双方合同约定，提供税务风险控制信息系统的业务需求，通过信息化系统管控税务风险。

第二十二条【具体内容】税务风险内部控制管理主要包括：税务风险管理组织机构、岗位和职责；日常业务税务管理；参与公司战略规划和重大经营决策管理；信息与沟通管理；监督和改进管理等。

第一节税务风险管理组织机构

第二十三条【机构设置内容】综合考虑委托方管理架构、生产经营特点和内部税务风险管理的要求设立税务管理机构和岗位，明确岗位的职责和权限。

第二十四条【资料收集重点】信息资料的采集主要包括：董事会及管理层的决策文件、组织结构图、业务流程图、岗（职）位说明书和权限指引等内部管理管理或相关文件。

第二十五条【税务机构职责】结合公司实际情况，确定税务管理机构职责，重点包含以下内容：

1．制订和完善公司税务风险管理制度和其他涉税规章制度； 2．参与公司战略规划和重大经营决策的税务影响分析，提供税务风险管理建议；

3．组织实施公司税务风险的识别、评估，监测日常税务风险并采取应对措施；

4．指导和监督有关职能部门、各业务单位以及全资、控股公司开展税务风险管理工作；

5．建立税务风险管理的信息和沟通机制；

6．组织税务培训，并向本公司其他部门提供税务咨询； 7．承担或协助相关职能部门开展纳税申报、税款缴纳、账簿凭证和其他涉税资料的准备和保管工作；

8．其他税务风险管理职责。

第二十六条【岗位设置要点】岗位设置重点关注以下方面： 1.岗位人员应具备相应的胜任能力；

2.建立税务事项审批岗位，制定相应的审批流程；

3.建立科学有效的职责分工和制衡机制，确保税务管理的不相容岗位相互分离、制约和监督；

税务管理的不相容职责包括:税务规划的起草与审批；税务资料的准备与审查；纳税申报表的填报与审批；税款缴纳划拨凭证的填报与审批；发票购买、保管与财务印章保管；税务风险事项的处置与事后检查；其他应分离的税务管理职责；

4、岗位设置应科学、适当，以简捷、高效为原则。

第二节日常业务税务管理制度

第二十七条【日常业务税务管理内容】分析整理收集的资料，根据相关法律、法规及上市公司监管要求，构建日常业务税务管理流程及控制制度。主要包括税务登记管理、涉税资格及资质申请或备案管理、发票管理、税收优惠管理、税款核算申报与缴纳管理、税务档案管理制度。

第二十八条【税务登记事项管理制度】税务登记事项管理制度主要规范以下事项：

1．设立分支机构税务登记；

2．公司登记内容变更、发生解散、撤销或其他情形的税务登记； 3．税务登记证件及代扣代缴或代收代缴税款凭证的管理； 4．外出经营活动税收管理证明的管理； 5．其他税务登记方面内容。第二十九条【涉税资格、资质申请或备案管理制度】涉税资格、资质申请或备案管理制度主要规范以下事项：

1．增值税资格申请、办理管理制度； 2．出口退（免）申请备案管理制度； 3．其他资格、资质申请或备案管理制度。

第三十条【发票管理制度】发票管理制度主要规范以下事项： 1．按照《中华人民共和国发票管理办法》和当地税务机关的相关规定以及公司的具体情况制定发票的购买、领用、开具、保管流程；

2．根据岗位职责分离的原则，设置发票管理相关岗位。第三十一条【税收优惠管理制度】税收优惠管理制度主要规范以下事项：

1．明确专人负责税收优惠政策研究，制定税收优惠方案； 2．税收优惠方案审批权限及流程。3．税收优惠方案实施过程的管理控制。

第三十二条【税款核算申报与缴纳制度】税款核算申报与缴纳涉税资格、资质申请或备案管理制度主要规范以下事项：

1．制定各项涉税会计事务的处理流程，明确各自的职责和权限； 2．分析采购、生产、销售、工资方法、费用报销、资产处理、利润分配等环节存在(或潜在)的纳税风险点，制定控制制度；

3．制定各类资产损失(坏帐损失、投资损失、存货跌价损失、固定资产处理损失)的收集、核销、审批程序；

4．制定税金的计提和缴纳应履行的审批程序； 5．完善纳税申报表编制、复核和审批以及税款缴纳的程序。第三十三条【税务档案管理制度】税务档案管理制度主要规范以下事项：建立涉税档案制度，保管好各类涉税资料、凭证，并按相关规定进行报备。

第三十四条【日常业务税务管理制度要点】建立日常业务税务风险内控制度，重点关注：

1．内控制度的设计应当涵盖公司日常业务的决策、审批、执行、结果的各个税务风险点，明确各部门、环节的协作机制；

2．合理权衡成本和效益的关系，制度的设计应讲求控制效率和效果；

3．内控制度应随着外部环境的变化、经营业务的调整和创新、管理要求的提高而改进和完善。

4．内控制度应与公司信息管理系统匹配。

第三节重大经营事项税务管理

第三十五条【基本内容】制定税务风险管理机构参与公司战略规划、重大经营决策、重大经营活动（以下简称重大经营事项）制度，赋予税务风险管理机构参与前述重大事项相关权限、制度相关程序跟踪和监控重大事项决策中的相关税务风险的。

公司战略规划包括全局性组织结构规划、产品和市场战略规划、竞争和发展战略规划等。

公司重大经营决策包括重大对外投资、重大并购或重组、经营模式的改变以及重要合同或协议的签订等。公司重要经营活动包括关联交易价格的制定、跨国经营业务的策略制定和执行等。

第三十六条【资料收集】税务风险管理机构在参与重大事项过程中应当收集以下资料及信息：

1．公司管理机构的设置情况；

2．董事会、监事会等企业治理层以及管理层的税收遵从意识和对待税务风险的态度；

3．公司重大事项研究决策制度；

4．经济形势、产业政策、市场竞争及行业惯例可能产生的重大涉税事项；

5．根据监管部门对上市公司的要求，公司重大事项披露情况； 6．其他有关资料

第三十七条【制定要点】税务风险管理机构参与重大经营事项的制度要点主要包括：

1．明确税务风险管理机构参与的重大事项范围、权限与流程； 2．重大事项涉税方案的研究、拟定等权利及责任； 3．重大事项涉税方案的审批及执行流程； 4．负责重大事项实施过程的涉税风险控制。

第四节信息与沟通

第三十八条【基本要求】建立税务风险管理的信息与沟通制度，明确税务相关信息的收集、处理和传递程序，确保税务信息在公司内部顺畅沟通、及时反馈，以确保涉税问题及时发现并采取应对措施。第三十九条【制定要点】建立税务风险管理的信息与沟通机制重点关注以下内容：

1．内部控制信息在公司内部各管理级次、责任单位、业务环节之间传递的程序及责任。

2．公司涉税信息与外部投资者、债权人、客户、供应商、中介机构和监管部门等有关方面之间沟通和反馈的责任人、流程、渠道。

3．重要涉税信息的处理流程及信息披露流程； 4．涉税信息与企业信息管理系统之间的协调机制。

第五节监督和改进

第四十条【监督和改进制度内容】制定监督和改进制度，明确内部监督机构的职责权限以及风险管理改进的控制程序。监督和改进制度包括：税务自查、税务风险评估、税务风险管理评价、绩效评价制度等。

第四十一条【监督和改进制度制定要点】监督和改进制度的建立重点关注以下内容：

1．明确应委托中介机构或者内部税务机构定期进行税务自查及税务风险评估，并形成内部控制自我评价报告。

2．对内部监督的方式、范围、程序和频率进行确定，并可根据经营业务调整、经营环境变化、业务发展状况、实际风险水平进行调整。

3．制定税务风险管理评价结果的审批、报告、改正流程，建立绩效评价制度。

第四章报告及说明

第四十二条【质量控制】涉税专业服务机构为保证上市公司税务风险内控制度业务质量，应当实施有效的质量控制程序，建立分级复核制度。

第四十三条【遵循规则】完成约定服务业务事项后，需要出具报告的由项目负责人按照《涉税专业服务程序准则》的要求，编制上市公司税务风险内控制度业务报告。

第四十四条【报告内容】涉税服务业务报告应包含:

（一）报告背景及目的

专业服务人员承接本次业务的具体背景和委托人所要达到的具体目的。

（二）责任说明

（1）资料责任：详细列明委托人所提供的具体资料，并应注明专业服务人员将根据委托人所提供的资料发表结论分析。

（2）报告使用及局限性：告知委托人应注意的报告使用方式、以及出具报告的目的和责任。

（3）报告的更新：列明本次委托所执行的工作程序并应根据委托范围注明在报告出具后税收法律、法规出现变化更新报告的责任与义务。

（三）执行程序:应列明本项目过程中具体的所操作的执行程序过程等。

（四）对委托业务的理解、业务分析及结论、相关建议等内容。专业服务人员应列明对委托事项的理解以及围绕实现委托目标，税收法律、法规所规定的条件，并提出明确的结论及建议

第四十五条【报告确认】对上市公司税务风险内控管理业务报告应当取得纳税人或委托方的确认。

第四十六条【保密要求】涉税专业服务机构及其从事代理办税人员应对国家秘密、委托方的商业秘密、不宜公开的情况及个人隐私予以保密。

第六章附则

第四十七条【解释权限】本规则由中国注册税务师协会负责解释

第四十八条【执行日期】本规则自发布之日起执行。

附件1：

上市公司税务风险内控管理业务委托协议(参考文本)

编号：

甲方（委托方）：税务登记号：

乙方（受托方）：税务师事务所执业证编号：

根据《中华人民共和国合同法》、《涉税专业服务业务规范基本准则》、《税收策划业务准则》、《上市公司税务风险内控管理业务规则》等法律法规的规定，甲、乙双方就“XXXXXXXXXX事项”涉税事宜，经协商一致，订立本服务协议。

一、服务范围(一)事项背景(二)委托内容

包括但不限于：委托服务内容、服务成果（体现方式、提交时间、提交方式）等

二、双方的责任及义务

（一）甲方的责任及义务

1．甲方对乙方开展专项服务工作应给予充分的合作，提供必要的条件，并按乙方的要求，提供相关协议、账册、凭证、报表以及其他需要查看的各种文件资料。

2．甲方应对建立健全企业内部控制，保证会计资料的真实、合法、完整，保证会计报表及账册、凭证充分披露有关信息和保护资产的安全、完整承担全部责任。

3．甲方应按照约定的条件，及时、足额的支付服务费。

（二）乙方的责任及义务

1．乙方接受委托后，应及时委派专业人员为甲方提供约定的服务。

2．按照国家有关税收法规的要求，对甲方提供的相关资料信息，实施必要的程序以确保工作结果与项目目标保持一致。

3．乙方对在执行业务过程中知悉的甲方信息负有保密责任，保密协议详见附件。除法律另有规定者外，未经甲方同意，乙方不得将甲方提供的资料及信息对外泄漏。

三、服务费用及支付方式

（一）按照甲乙双方约定，完成本次“XXXXXXX委托事项”专项报告费用为人民币（大写）XXXXXX万元整（￥XXXXXXXXXX元）。

（二）上述费用自本约定书签订之日后甲方应分二期支付乙方，即：

（1）甲方应予本约定书签订之日起5日内，支付乙方组织调查、分析资料所需咨询费用XXXXXXXXXXX元整；

（2）甲方应于乙方《税务风险内控管理咨询报告》提交后5日内，支付乙方咨询费用XXXXXXXXXX元整；

（三）发生的与本次委托事项有关的其他费用（包括差旅、食宿费等），由甲方据实承担。

四、违约责任

（一）如乙方未按期提供本协议项下服务，则甲方有权要求乙方在合理期限内改正。乙方未按期改正的，甲方有权拒绝支付相应费用，并扣除本协议项下费用的5%作为违约金；如乙方发生三次以上（含本数）上述未按期改正的违约行为的，甲方有权解除本合同，乙方应在收到甲方书面解除通知之日起5日内将甲方已付款项退还。

（二）由于甲方责任导致乙方未能按期完成本协议规定，给甲方造成损失的，应由甲方承担全部责任。

（三）如因乙方原因造成甲方的经济损失，乙方应给予赔偿。

五、其他事项

（一）协议书签定后，双方应积极按约履行，不得无故终止。如有法定情形或特殊原因确需终止的，提出终止的一方应及时通知另一方，并给对方以必要的准备时间。

（二）协议书履行中如有争议，双方应协商解决，协商不成，可向本协议签订地（）有管辖权的人民法院起诉。

（三）本协议书未尽事宜，经双方协商同意后，可另行签订补充协议。

本协议书一式两份，甲乙双方各执一份，并具有同等法律效力。

甲方:

（盖章）法人代表（授权人）签字：签字：

地址： 20XX年XX月XX日 20XX

:（盖章）法人代表（授权人）

年 XX月XX日乙方地址：附件2：

税务风险内控管理业务报告（参考文本）

报告号：备案号：

致：XXXXX有限公司

我们接受委托，对XXXXXXXXXXXX公司(以下简称“贵公司”)将XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX提供税务风险内控管理咨询。

在咨询过程中，我们主要依据《中华人民共和国税收征收管理法》、《企业内部控制基本规范》（财会[2008]7号）、《企业内部控制应用指引》、《大企业税务风险管理指引(试行）（国税发[2009]60号）》、《中国人

民

共

和

国

发

票

管

理

办

法

》xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx等税收法律、法规文件的规定，对贵公司提供的合同（协议）、凭证、账册、会计报告等有关会计及税务资料实施我们认为必要的程序，形成了适用于贵公司的税务风险内部控制制度。

本咨询意见书仅提供给贵公司管理层内部参考使用，并不为其他任何目的。未经我们事先书面同意之前，贵公司不得在向公众或任何第三方披露的任何文件中使用或引述本意见书。在编写任何引述我们或本意见书内容的文件时，贵公司应事先征得我们对于相关被引用内容的同意，我们保留拒绝的权利。

XXXXXX涉税专业服务机构 20XX年XX月XX日

XXXXXXXXXXXXXXXXXXXXXX公司

税务风险内控管理业务报告说明（参考文本）

一、报告背景及目的

二、责任说明

（一）资料责任

本报告所依赖的数据、信息等相关资料全部由贵公司提供。保证相关资料的合法性、真实性、准确性、全面性是贵公司的责任。本次“XXXXXXXXX”X项目贵公司所提供的财税资料具体包括：

1.2.3.4.…… …… ……

（二）报告使用及局限性

本报告仅供贵公司内部参考和使用。在任何情况下，未经我们的书面同意，请勿将本报告的全部或部分内容在其他场合使用、或以任何方式复制、提供给第三方使用。

我们的服务不同于审计（鉴证）服务，不对报告中所含的信息发表审计（鉴证）意见。

我们的服务仅是对贵公司税务风险方面拟定内部控制制度，并不构成全面的税务复核或纳税审查。因此，对于本报告未涉及到的税务风险和其它经营管理风险，以及这些风险所带来的影响，我们不承担任何责任。

（三）报告的更新

本报告的专业意见，是我们对现行的中国税收法律法规及税务实务的理解和贵公司提供的相关资料的基础上而形成的。如果这些基础以后发生变化，有可能影响我们的专业意见。在我们正式向贵公司递交本报告之后，因以上基础的变更导致影响本报告专业意见，我们不负主动更新和修正的责任。

在此，我们建议贵公司能够定期与我们联系，以征询以上基础的变更是否影响到本报告专业意见。

三、执行程序 1.2.3.4.…… …… ……

四、对本次涉税业务的理解

五、本次涉税服务业务分析

业务规则管理系统第3篇

目前，大多档案管理信息系统中，业务处理逻辑均被写成多个程序段，分别隐藏在代码、数据库、或者触发器中。当需求发生变化时，必须修改程序代码，使得系统维护成本增加，难于升级更新。

针对上述问题，本文提出了规则管理技术在档案信息资源管理中的应用，该方法通过对档案管理业务规则进行规范化业务规则存储、集中管理和维护、灵活部署、高效执行，将档案管理业务中不确定的业务策略和流程从应用程序中分离出来，使得业务规则可以灵活方便地进行管理和修改。

一、业务规则技术概念

业务规则技术随着软件技术不断发展而日趋成熟，并以极快的速度渗透到软件行业的每个角落。同时，业务规则技术的出现为软件界也带来了新的思想。包括业务规则和业务规则管理两方面。

1. 业务规则。

业务规则（Business Rules）是对业务定义和约束的描述, 用于维持业务结构或控制和影响业务的行为。业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来, 将其转变为简单的业务规则, 以结构化的业务规则数据来表示业务行为, 采用类自然语言来描述, 并集中存储在规则库中。业务规则由业务人员创建、实时更新和调试, 业务规则之间的复杂逻辑关系由规则引擎处理。业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。

业务规则具有以下特性： (1) 原子性。业务规则不可再分, 每条规则只定义一种判断和操作, 复杂的业务逻辑由多条规则协同处理。 (2) 独立性。业务规则彼此之间独立, 复杂的逻辑关系由规则引擎来处理。业务规则存储在规则库中, 独立于数据和程序。 (3) 简单性。业务规则用简单直接的类自然语言来描述, 很容易被业务人员和技术人员所理解。 (4) 动态性。业务人员可以实时地修改业务规则, 快捷地更新系统, 低成本地维护系统。 (5) 逻辑性。业务规则至少包含条件和执行两个部分, 条件是对业务数据作用的判定, 执行是对业务数据的处理。在基于业务规则的软件系统中，业务规则存储在规则库中，业务人员可以进行查询、添加、更新、统计，可以不断积累经验，实现对业务行为的知识管理，这使得业务规则与单位的数据信息一样成为单位的重要资产。

通常业务规则的表示形式为：如果（If），对象或对象之间的条件测试；那么（Then），执行某些对象的操作。规则还可以用决策表和决策树两种表现形式。决策表是以表格的形式表示业务规则, 每一行表示一条规则, 列表示条件及动作, 当所有条件满足时, 执行动作;决策树是将一组业务规则以树型结构来表示, 树的分支表示判断条件, 叶子节点表示结果或动作。

2. 业务规则管理技术。

业务规则管理技术（Business Rules Management，简称BRM）是伴随着面向对象技术、软件构件技术、人工智能、数据库、XML（数据库的表示）等相关技术的发展而出现的，是目前国内新的，非常热门的一项技术。业务规则管理技术就是基于上述业务规则的情形下应运而生的一种高效管理业务规则的技术。它包括了：规则的查询、规则生命周期管理、版本管理等。

针对个性化服务系统中业务规则复杂多变的特点，引入业务规则管理技术来对系统中使用的业务规则实行动态管理，即将其业务规则从应用程序代码中抽象出来放到规则库中进行独立维护。

二、业务规则技术在档案管理系统中的应用

1. 档案业务规则的获取。

(1）档案业务规则的分类。与档案业务相关的规范、制度、标准等内容，称为档案业务规则，特别是档案管理部门制定的档案收集、归档范围、保管期限表等。如： (1) 机关文件材料归档范围和文书档案保管期限规定； (2) 归档文件整理规则； (3) DA/T18-1999档案著录规则； (4) DA/T19-1999档案主题标引规则； (5) GB/T50328-2001建设工程文件归档整理规范； (6) GB/T50323-2001城市建设档案著录规范； (7) 国档发（1987) 27号机关文件材料归档和不归档的范围等。对不同的档案门类，也都颁发了相关规定，如会计档案、信贷档案、科研档案等。档案业务规则大多存在于档案人员的大脑中，或者程序手册、合同、协议等文档中。而档案业务规则库的建立是档案业务规则管理系统建设的重中之重。通过对与档案管理相关的各项经验、专业知识分门别类地进行综合分析，将档案信息管理业务规则分为三类： (1) 针对外部的业务规则库：以《档案法》为主的相关法律、法规和制度等。 (2) 针对非正式的内部规则库：档案指导长期实践的经验，单位经验丰富的档案从业人员的知识总结以及以往所开发的档案信息管理系统使用者的反馈和建议等。 (3) 针对结构化的内部规则库：对综合档案以立档单位为基础的《归档范围》、《保管期限表》，对工程档案以工程性质为基础的《建设工程竣工档案归档范围》等。

(2）档案业务规则的获取。档案信息管理业务规则主要来源于档案管理业务相关的条例法规，档案信息管理业务相关人员的需求调查以及档案管理工作人员平时的经验积累，旧档案信息管理系统的文档等方面。大体来说，档案信息管理业务规则的来源分为三类： (1) 与档案管理业务有关的法律法规和制度中包含着大量档案管理业务的操作指南、操作流程、约束与限制等，隐含了大量的业务规则，对其加以分析与整理可以得到相应的业务规则。 (2) 通过访谈用户、开座谈会、问卷调查、跟班作业、搜集用户资料等方式进一步获取与用户关系密切的业务规则。 (3) 旧信息系统文档中的系统分析、需求说明书、数据字典、详细设计、程序代码、操作手册等也包含了大量的业务规则。通过以上三个来源获取的业务规则会存在许多重复或与规则无关的信息，必须通过挖掘整理从中获取有用的业务规则，然后按规则类型将业务规则进行分门别类。规则类型分为约束、计算、推导和事件规则五类。要实现业务规则的功能必须明确此业务规则的主体以及对其主体的判断、约束、推导和计算。最后对整理出来的规则进行一致性、完整性与冗余分析。

2. 档案业务规则管理系统的总体模型架构。

本文构建了一个基于业务规则的档案管理系统，将业务规则技术应用到了系统的设计中，已达到对传统的档案管理系统架构进行较大改进。通过对整个档案管理系统中与档案管理相关过程涉及的业务规则实行自动维护、处理和使用，实现对档案的过程管理和个性化管理服务。基于业务规则的档案管理平台是一个贯穿档案轨迹全过程的完善的档案业务管理平台，包含： (1) 传统档案的收集、整理、鉴定、保管、统计、检索、编研、开发利用与移交接收等； (2) 档案业务规则管理系统（BRMS）； (3) 集成化的档案数字化加工系统； (4) 多媒体档案与电子文件的管理、存储、固化与元数据提取等； (5) 基于单位内部网的档案目录中心； (6) 智能的档案采集信息雷达； (7) 基于人工智能档案监督指导系统、绩效考核系统、从业人员自学系统。

3. 基于业务规则档案管理系统的意义。

(1）为社会保险构造业务逻辑知识库, 便于知识的积累和传递。随着变化效率的加快, 社会机构的人员必须不断学习, 尽可能全面地熟悉政策和规程。但是由于人员变更造成的业务经验流失是目前比较普遍的现象。将业务逻辑以规则的形式表示, 不但解决了规则流失的问题, 更提供了一个机构内部知识交流和学习的平台。（2）可以更好地适应系统的扩展性, 降低变更成本。对于一个以服务满意度为使命的保险机构来说, 政策的正确、及时的体现和处理对其使命的完成起着关键作用。政策和规则总是在不断变化, 但一旦把业务规则像数据一样从程序中剥离, 无疑在技术上为业务应用的实施团队提供了更大的灵活性, 加快了跨IT和业务部门的决策速度, 缩短了新政策和规则的部署实施时间。（3）业务逻辑的设计可以交由业务经办人员自行维护, 操作方便。由于业务规则已经与程序分离开来, 业务规则的修改不需要修改程序, 同时我们基于业务人员熟悉的术语实现规则编辑功能, 就可以实现业务人员自行维护规则。这样就更加快了变更的速度, 消除了业务人员与IT部门之间交流的困难。

基于业务规则的档案管理信息系统可以较大地提高档案管理系统的性能和效率，增强档案管理系统的交互性能和可维护性，特别是增强了档案管理个性化服务的优势。将业务规则技术应用于目前档案管理系统中，有两方面的内容还要进一步的探索和研究：一是业务规则的深入挖掘，使档案管理系统的业务规则逐步完善；二是业务规则的全面使用，使各子系统间的业务规则有序融合。

摘要：业务规则技术是随着软件技术不断发展而出现的一个新兴的技术。本文主要阐述了业务规则技术的概念, 介绍了传统档案管理软件存在的问题, 业务规则技术在档案管理软件中的应用以及所带来的好处。

关键词：业务规则,档案管理系统,应用

参考文献

[1]包铁.基于业务规则的电信网络数据处理框架[J].计算机应用研究, 2006 (12) .

[2]何霆.业务规则企业质量成本核算[J].计算机集成制造系统, 2007, 13 (2) .

[3]徐德英.业务规则信息系统建模方法[J].计算机应用与软件, 2004, 21 (5) .

[4]于淼.信息系统业务规则的设计模式[J].计算机工程, 2006, 30 (6) .

[5]贺凯.业务规则方法在社会保险信息系统中的应用[J].企业家天地, 2007 (1) .

[6]李静波.业务规则在电信计费系统应用[J].信息工程大学学报, 2005, 6 (4) .

[7]郑晓晖.业务规则管理技术在信贷系统中应用[J].中国金融电脑, 2006 (2) .

业务规则管理系统第4篇

首先，在“企业配置”大模块下的“业务规则定义”子模块中选择新建或者选择一个文件夹，然后在列表区点击右键，并依次选择【新建】―【业务规则】(如图1)：

图1

系统会弹出业务规则设置窗体，在此窗体中，我们需要输入业务规则的名称与所用的文件模板(可以是表单模板也可以是文档模板)和流程模板(如图2)，

图2

其中，“文件编码器”可以支持我们绑定一个编码器，自动对该业务使用的表单(如本例的《文件派发记录单》)编码;“附件位置”可以支持我们绑定一个文件夹，该业务完成之后，其所有附件都将自动转移到该文件夹下(如图3)。

图3

设置完成之后点击确定，便完成了业务规则的创建。

业务规则管理系统第5篇

1 档案信息资源管理系统

1.1 建立档案信息管理系统

现代化是档案信息资源管理的新目标,首先,体现在管理手法、理论方面,档案信息管理现代化必须以信息论、控制论、系统论作为基础,结合现代的管理手段和技术方法才能得以实现。因此,要将档案信息资源建立成一项管理系统,根据不同的管理模式和管理层次进行管理,由多种不同的管理层次所构成的子系统,才能使得各子系统的档案工作安全运行,以及保证所有档案管理系统的稳定,各系统与子系统之间是相互制约、相互依赖的,所以,档案管理系统具备统一、完整、相关等特性。

1.2 建立信息通道,保障信息通道的畅通

在档案信息资源管理系统建成之后,我们必须应用信息理论知识确保信息畅通,从而使得整个档案信息资源管理系统正常地运行,因此,信息通道是建立在子系统正常运行的基础之上的。集合各子系统所有的信息资源,归纳、整理、编制而成。所以,我们要求系统内各子系统的信息资源的内容和格式必须按规范来,统一整理,才能保障信息资源的畅通。同时,档案信息资源在流通过程中要运用到控制理论作为指导理论,并且及时对信息流通加以控制,来确保档案信息资源系统的正常运行。控制的目的,是保证信息资源的准确和系统运行正常,控制在日常信息资源管理的工作中,主要表现在信息资源管理制度化、规范化、程序化这三个方面,只有落实“三化”的方针,才能保障信息资源通道的畅通无阻。

2 档案信息资源管理系统所存在的问题

2.1 没有突破传统管理模式的局限

虽然在档案信息资源管理方面计算机技术的应用日渐广泛,但是仍然没有完全突破传统管理模式的局限。尤其是受到一些部门管理者管理思想的影响,很多档案管理人员的工作都无法得到有效的落实,文件信息的归档工作无法顺利开展,这些问题都是现今档案信息资源管理发展的阻碍。也可以说,受到传统档案管理模式的残留影响,对于现代档案管理效率和质量的提升仍然存在一个停滞的阶段,需要持续不断的努力。

2.2 档案信息资源管理系统的有效使用期较短

为了有效的促进档案信息资源管理效率的提升,档案部门把整个档案信息资源管理系统包给IT公司,但是很快就发现并不如预期的好,并没有取得如期的效果。而当前的档案管理工作的开展仍然处于快速发展的使其,在管理制度和管理方法等方面都不断发生各种变化,这对于档案信息资源管理系统所提出的要求也越来越高。但是业务规则却是代码的形式、留存于计算机系统。通常情况下,当业务规则发生变化时,那么管理系统的相应软件和功能也要随之发生变化,这也使得很多收集和调整工作无法适应,导致关系系统有效性的持续时间收到影响。

2.3 档案信息资源管理系统效率低

对于档案信息资源管理系统来说,档案部门的人员是主要的使用和操作者,他们对于系统的运行以及规则等都必须要很了解,才能保证各项工作的有序进行。但是在实际工作中,由于很多信息都是以代码的形式存在,系统不够灵活,很多调整工作都必须要依靠IT人员来完成,这不仅影响了信息资源的管理效率,同时也增加了系统运行和维护的成本。

3 档案业务规则管理系统的应用

3.1 业务规则集成开发环境

在档案业务规则开发过程中,集成了编译工具和规则编辑器,以此来实现信息管理系统的管理与部署工作。界面用户则可以按照实际管理的需要,利用图形的方式构建模型和实施各项操作,这样便能够有效的促进系统运行规则检查的有效性。同时,将编译工具中用户输入的信息作为系统运行规则引擎,也能增加系统的可造型。

3.2 档案业务的对象模型

对象模型指的是一种业务对象,其主要是通过对档案管理工作的业务进行描述,从而完成记录的过程,将每一项管理业务的名称、属性以及不同业务对象之间的关系进行明确,以此来促进档案管理的有效性不断提升。另外,业务对象模型的建立也能够为档案管理系统提供更多可参考的词汇,其中,大部分由档案业务系统的分析员所设计,再通过系统开发员具体实现。

3.3 档案业务规则语言

在面对不同的使用用户时,在管理系统中所表现的语言表达形式之间也存在着一定的差异性。业务规划管理系统对于IT人员和档案部门人员也分别设计了不同的语言系统,而所有的语言系统都将被转化为规则引擎中的执行代码。另一方面,因为熟练档案业务规则的业务人员在计算机网络编程方面大多较为薄弱,所以必须要通过自然语言实现对系统管理的薄弱,但是使用中文进行信息处理仍然是很难实现的。所以必须要对规划管理系统的语言使用进行必要的学习与培训,从而保证系统的有效运行。

3.4 档案业务的规则引擎

档案业务规则引擎是一种执行档案业务规则的软件,在其嵌入过程中,处于档案业务规则系统中的核心地位。开发系统的人员在程序使用过程中,基本的步骤应为:创建引擎对象,在引擎中加载或更换规则集,再向引擎提交需规则集处理的对象数据,最后命令引擎执行,导出执行结果,撤出之前处理的数据记录。

4 结语

随着科学技术的不断发展,档案信息资源管理的效率也将受到越来越多的重视,业务规则管理系统的应用已经成为了一种必然的趋势,对此,我们必须要有针对性的进行改进与完善,才能促进业务规则管理系统的有效运用,从而促进档案信息资源管理效率的持续增长。

参考文献

[1]王新才,李雯,丁时征.业务规则管理在档案信息资源管理系统中的应用[J].档案学通讯,2010(4).

[2]张彩凤.论档案信息资源现代化管理[J].时代教育,2008(6).

[3]张华.档案信息资源管理社会化建设模式与作用绩效[J].黑龙江科技信息,2012(13).

[4]金波,覃哲.网格技术与档案信息资源管理[J].档案学通讯,2007(03).

业务规则管理系统第6篇

本文所研究的教师教学评价系统是教务管理系统的一个子系统。教学评价是教务管理工作的重要方面, 把好教学质量关就需要建立一套公正、科学的教学评价系统。在许多传统的教学评价系统中, 存在着规划和设计不尽合理的问题[1]。首先系统核心的评价规则以程序代码的方式"固化"在系统中, 缺乏真正的灵活性, 而在实际的教学评价过程中, 随着教学要求的不断变化, 教学管理者要不断地调整教学评价的指标权值, 参考的参数等等, 这就必须通过技术人员编写代码的方式来修改相关评价规则, 然后经过繁杂的测试才能部署实施。这导致评价业务策略的变动不能适应实际的需求。其次, 评价规则是面向技术人员的程序代码, 业务策略无法被业务人员真正的掌握和管理。这样就导致系统的规划者与程序的研制者的意图不完全一致。为解决传统的教学评价系统中存在的问题, 本文研究并设计了基于业务规则的教学评价系统。本系统的核心思想是利用业务规则技术使系统核心的业务规则与程序代码分离, 使得业务人员能够对业务规则进行有效的管理和灵活的运用。

2、业务规则和业务规则管理技术介绍

一条业务规则包含一组条件和在此条件下执行的操作, 它们表示应用程序的一段业务逻辑。业务规则管理 (Business Rules Management, 简称BRM) 技术随着业务规则出现应运而生。它包括规则的查询、规则生命周期管理、版本管理以及规则模板等的管理[2]。像数据从程序中分离一样, 它使业务规则也同样从程序中分离。业务规则管理技术使应用程序中程序代码的简化为IF{对象或对象之间的条件测试}THEN{执行某些对象的操作}ELSE{执行其它分支操作}的语句格式。例如:IF{教师参与授课}THEN{计算授课工作量}。因此, 业务规则语言的表述通俗易懂, 即使普通用户也能实现对规则的完全控制。BRM技术需要借助企业级的业务规则管理系统 (Business Rule Management System, 简称BRMS) 实现。所谓BRMS就是实现业务规则管理、维护、部署和开发的信息系统。它由一组工具集组成, 包括:规则引擎、规则库、规则语言框架和规则集成开发环境。

业务规则管理系统的基本原理:用一个或多个规则引擎替换"固化"在应用程序不同位置的业务规则 (逻辑) 的程序代码。被替换的业务规则 (逻辑) 存储在程序之外的规则库中;规则库中的规则可以通过图形化规则管理工具实现定制、修改和部署[3]。

3、基于业务规则管理技术的教学评价系统的设计

3.1 系统总体结构

传统的评价系统体系结构常被划分成三个层次:表示层、应用服务层和数据层。其中, 应用服务层几乎集中了系统全部的业务逻辑的处理。虽然, 可以采用构件技术分别组装实现应用服务层的各个功能模块, 降低耦合度, 提高系统的整体可靠性。但是, 业务逻辑仍然分散在程序代码中, 不便于系统维护和管理。基于业务规则技术改进的教学评价系统的体系结构为"四层二库" (四层:接入层、业务规则层、应用层和数据层, 二库:数据库和规则库) 结构 (如图1所示) 。这种结构比传统的"三层一库"多了一个"业务规则层"和一个"规则库", 业务规则层主要是处理关于业务规则的操作, 包括创建、检验、修改和维护等, 直接由业务人员操作, 增强了业务处理的透明度, 提高了业务灵活性, 减少了对技术开发人员的依赖。业务规则层的引入, 简化了应用服务层的设计, 方便了系统整合。增加规则库使业务规则以文件的形式单独存储, 使业务规则得到有效管理, 便于业务逻辑的文档化。

3.2 系统的开发流程

基于业务规则技术的系统开发方法使得系统的开发流程有了较大的改变 (如图2所示) 。首先, 参与开发的人员已不再局限在IT开发人员, 业务人员也将扮演非常重要的角色。其次, 系统开发不仅仅是程序的开发, 更是业务规则的开发, 而且规则开发和程序开发可以同时展开。第三, 系统的开发不再是"一锤子"的过程, 而是一个逐渐完善和发展的过程。

3.3 系统业务规则设计

业务规则的设计是把业务规则逻辑模型转换为可实现的业务对象模型, 根据业务规则逻辑模型选择规则容器、用规则容器所支持的规则语言描述逻辑规则集, 还要考虑业务规则模型与应用服务层中各个功能模块的交互[5]。

3.3.1 业务规则的抽取

本系统中以教师的教学评价规则为例, 主要是从业务行为中抽取相应的规则, 包括教学评价管理者的经验, 以及已往的评价方案实例等。抽取的规则根据内容分为五类:

1) 事实规则:指的是按常理的逻辑关系, 或定量规则描述教师和教师的工作量 (授课量, 批改作业量, 指导学生量等) 的状态信息等, 如:

教师的职称授课系数:助教-0.8, 讲师-1.1, 副教授-1.0, 教授-0.9

2) 约束性规则:表示方案中教师和课程等必须满足的要求, 如:

教师的授课质量的评价分数必须大于0分小于100分

3) 预警型规则:描述方案中出错的信息, 如:

如果教师的授课质量的评价分数大于100分, 弹出警告

4) 计算型规则:一般是对定量信息的计算, 如:

教员授课质量评价分数=机关和教学督导评分*25%+教研室评分*30%+学生评分*45%

5) 推理型规则:描述事实之间的推理关系, 如:

如果教师的授课质量的评价分数是75～90分, 则教师的授课质量的评价等级为良好

3.3.2 业务对象模型BOM (Business Object Model) 的建立

BOM的设计是基于业务规则系统设计的关键步骤, 它影响到整个系统是否能够真正灵活的运转起来。BOM为业务规则语言提供了绝大多数的"词汇"。它是由一组类 (Class) 构成, 每个类包含类名、类的属性 (Property) 和一些方法 (Method) 。类的属性、类与类的关系将会出现在业务规则的条件部分 (Condition) , 类中的属性值与导入到引擎中的许多规则的条件进行匹配, 如果某些对象 (或对象之间的关系) 满足某个规则的条件, 那么引擎将触发规则的执行部分。

以教师教学评价为例, 若想得出教师教学评价意见, 需要抽象出教师、课程、考试、指导论文、教研室和Vector (容器) 等业务对象。教师这个业务对象是整个系统的主体, 其教学行为直接与系统中的其它对象实体相关联。根据以上分析抽象系统的业务对象模型 (如图3所示) (类图中省略了对属性的基本的get和set方法) 。

3.4.2 设计系统业务规则集

ILOG JRules提供了一个规则创建工具Rule Builder对规则库和规则进行管理。首先将根据基本"词汇"做成基础类放入BOM中, 并利用JRules提供的"转义"和"别名"机制, 将这些基础类的属性和方法转换成业务人员所熟悉的"词汇"放入规则库中, 然后业务人员根据JRules提供的业务执行语言 (BAL) 和库中提供的这些"词汇"做成规则模板, 制成最后的规则并做成规则集, 供技术人员在应用程序系统中开发阶段调用[4]。

在本系统中, 采用"面向业务"的业务规则语言定义业务规则, 如:

规则:CountTeaching

如果课程类型是室内课

并且授课类型是主讲

并且合堂方式是四个班级

那么设置授课系数[10]

然后设置合堂系数[14]

然后设置授课工作量[授课学时*授课系数/10*合堂系数/10]

很显然, 上述的规则语言是业务人员能够看懂得。而开发人员要实现"面向业务人员"的规则语言到"面向程序"的规则语言的映射。 (例如:规则条件部分的"课程类型"将对应BOM中"Lesson"类的lessonType属性, 而执行部分的"设置授课系数"将对应BOM中"Lesson"类的setK () 的方法, 如此, 评价规则与BOM中定义的属性, 方法一一对应起来。) BRMS的规则语言框架将提供对这种"翻译"机制的支持。而规则之间的关系可以利用规则的优先级和BRMS提供"规则流 (RuleFlow) "的定制功能来实现[4]。另外, 一般情况下, 规则的条件和执行部分均可以由业务人员根据评价策略的变化, 直接在Rule Builder中修改, 实现起来非常的方便。少数情况下, 如果需要添加的规则条件或执行部分与BOM中的类的属性或方法没有对应项, 则需要先在BOM中添加相关的内容后, 即可在Rule Builder中创建该规则。

3.5 规则服务的部署

在应用程序中部署业务规则, 必须先从规则库中提取规则, 然后以某种形式 (文件、数据库或实体bean数据库) 传递给嵌入到业务规则应用程序中的规则引擎。

规则服务部署过程包括三个阶段[3]:

·提取:从规则库中选取需要部署的业务规则集。

·发布:发布所生成的规则集 (通常是通过文件、常规数据库或实体bean数据库之类的外部数据源进行发布) , 将其提供给嵌入到应用程序中的业务规则引擎。

·执行:对加载了规则集的规则引擎进行初始化, 并执行规则。

具体代码如下:

1) 创建一个规则引擎对象 (这是ILOG JRules提供的对象)

2) 从规则库中取得与评价规则相关的规则包, 并加载到规则引擎中。这里教学评价规则包存储在名字是"EES-rules"的文件中。 (如果规则包保存在数据库中, 需要使用其它的API)

3) 使用引擎的API, 将对象导入规则引擎的工作存储器中。引擎将对导入的所有对象的属性值与当前加载的规则包中的教学评价规则进行匹配比对, 把匹配的规则放在一个规则序表 (A-genda) 中。

4) 使用引擎API, 将对象导入规则引擎的工作内存。引擎将对导入的所有对象的属性值与当前加载的规则包中的规则进行匹配比对, 把匹配的规则放在一个规则序表 (Agenda) 中。引擎最终会清空"执行队列"。

5) 使用引擎的API把引擎中的对象取出并导出 (如回存数据库等)

6) 从引擎中撤除所有对象, 为下一个评价规则处理作准备

4、结束语

本系统采用了基于业务规则技术的信息系统开发方法, 将系统中复杂易变的评价规则与应用程序分离, 使得业务逻辑独立于程序代码之外, 便于管理和维护。通过嵌入在应用程序中的规则引擎来处理业务规则之间复杂的逻辑关系, 根据任务信息快速地做出科学的评价意见。本系统具有良好的灵活性、易用性和可维护性, 不足之处为系统的业务规则抽取仍然是由技术人员在分析系统的业务需求的基础上手工抽取的, 还没有实现自动化的规则抽取, 尚有待于进一步的研究。

本文充分利用了业务规则简单、易于理解的特点把业务规则技术引入教学评价系统。这是将业务规则技术应用于评价领域的初步尝试, 为教学评价系统的设计提供了新的思路和借鉴。

摘要：本文介绍了业务规则和业务规则管理技术, 并设计了业务规则技术在教学评价领域的应用。提出了一个适合该系统的业务对象模型, 设计了系统的业务规则, 采用业务规则管理系统 (BRMS) 在应用程序之外单独管理, 使传统系统的总体结构改进为更加灵活的"四层两库"结构。该系统具有良好的灵活性、易操作性和易维护性。

关键词：教学评价系统,业务规则,业务规则管理技术,业务对象模型,规则引擎

参考文献

[1].邱文教, 潘晓卉.高校教务管理信息化过程中存在的问题及对策[J].《前沿》.2005年第11期.

[2].梁冰.业务规则成资产[N].计算机世界报.2004年第14期B4、B5.

[3].何仁杰, 梁冰.用规则引擎替换代码[N].计算机世界报.2004年第14期B6、B7.

[4].ILOG强化企业优势的业务规则管理系统[R].http://ftp.zdnet.com.cn/zdnet/ilog/white_paper.pdf

基于电信全业务话单处理的规则引擎第7篇

目前各本地网业务规则不统一, 各种业务类型种类繁多, 处理规则也都不一样, 针对不同的业务规则及业务类型, 需要开发出不同的程序进行适应。针对这个问题, 开发了规则引擎, 实现了基于业务规则配置, 实现同一程序可实现不同业务规则的情况。

1 规则引擎方案

规则引擎通过在进程模块内配置调用规则, 实现模块内执行步骤的定制。执行步骤主要通过预先在配置中注册的过程和决策实现, 模块内部指定需要执行的步骤的ID, 主模块通过专门的接口对相应的过程和决策进行调用。本文重点描述过程和决策的实现;

1.1 规则引擎架构

后台应用进程采用统一的公用库, 供其他程序进行调用, 作为程序调用公用接口, 保证程序的稳定性和一致性。系统引入规则引擎的设计思想, 对不同本地网的配置上可能产生调整的环节采用规则配置的方式。

规则引擎示意图如下:

注:DataA ccess 为对象数据记录特定的存放方式, 将数据结构抽象化, 使得结构内的字段可配置, 程序只需指定字段 ID, 即可对相应字段进行存取操作。

1.2 过程的实现

过程的调用是以共享库的动态加载方式实现的 (通过UNIX提供的共享库访问函数) 。过程可以通过直接编写C++代码, 或通过规则脚本语言编写, 再翻译为C++代码后编译实现, 在编译生成共享库后, 必须对相应过程名在配置中进行注册, 才能够被规则引擎识别和调用。

1.2.1 过程的定义和使用

用于过程调用的函数定义必须如下形式声明:

void ProcedureN ame (DataA ccess::Record& record, int&retC ode) ;

其中ProcedureN ame须用具体指定的过程名替换;参数record为传入的数据实体记录, 如话单、帐单记录等, 包含输入和输出信息;retC ode为过程处理结果返回码, 为0则表示过程执行成功。函数体内主要编写相关的业务实现代码。

对过程的调用按如下步骤进行:

(1) 通过Procedure类的构造函数初始化过程实例;

(2) 调用加载方法传入需要访问和处理的记录;

(3) 调用call方法, 在参数中指定过程ID和过程名调用相应的过程函数, 实现过程如下:

将所有已调用过的过程函数指针都存放在集合中, 当传入一个需要调用的过程ID时, 先判断集合中是否已有相应的过程被调用过, 若已存在, 则直接使用该过程函数指针, 否则通过UNIX提供的共享库调用接口从相应库文件中取得该函数指针用于调用。

(4) 当共享库需要更新时, 调用update方法清空内存中的过程函数集合和释放所有共享库操作句柄的连接。

1.2.2 过程的使用和注册

对于一个新增过程, 在编译生成共享库后, 必须在配置中对该过程进行注册才可以被规则引擎识别调用, 注册过程如下:

(1) 过程作为一个对象类型, 须先在数据字典的对象定义表中进行标识;

(2) 在规则库过程定义表中加入访问过程函数所必须的条件信息, 即函数所在的共享库的访问路径, 及调用该过程的模块号和适用业务类型。

过程注册后, 只需要在模块执行步骤表中指定调用对象ID就可以自动调用执行该过程。

1.3 决策的实现

对于只需要通过数据实体内部字段内容的操作和判断, 就可以处理实现的业务规则, 可以放在决策中定义。决策是由一系列的条件判断和赋值语句组成, 但无法保留中间计算结果和访问外部配置信息, 只能根据已有的字段, 或其衍生信息, 直接进行计算和判断, 来推出所需字段的结果。

1.3.1 决策的组成

决策是由一系列IF…THEN… [ELSE…]语句组成的简单规则构成, 在IF中进行条件判断, THEN与ELSE中执行赋值动作或嵌套规则。规则中允许以下数据对象:

(1) 常量:32位整型, 64位整型, 实数型, 字符串型和时间日期型;

(2) 变量:由接口传入的单条记录的成员字段;

(3) 函数:必须是数据字典中已注册的函数。函数必须有返回值, 参数只能为常量或变量, 且只能作为输入, 无输出参数;

(4) 表达式:由常量、变量和函数组成的计算式, 支持加、减、乘、数、取余和括符配对的四则运算。

允许的操作类型有:

(1) 比较操作:两个数据对象间进行比较, 返回布尔量。支持相等、不等、大于、不大于、小于、不小于的比较操作;

(2) 逻辑运算:对比较结果运算的布尔表达式。支持与、或和括符配对, 使用短路判断原则;

(3) 赋值操作:将一个表达式的计算结果赋值给变量。

1.3.2 决策脚本的定义和编译

决策脚本格式遵循C语言语法, 其中变量以$后加字段ID的方式表达, 脚本经过编译程序编译后, 生成伪指令语句, 用于表示执行步骤, 其中常量前缀为i、l、r、s、t, 变量前缀为$, 函数前缀为F, 寄存器前缀为@、参数前缀为#, 指令格式为OP OPND1, OPND2, OUTPUT, NEXT形式, 再直接对应生成到决策步骤定义表中。

1.3.3 决策的使用和注册

决策的调用和注册与过程的调用和注册相似。决策必须先提供实现脚本, 经过编译后, 将执行步骤存放在决策步骤表中, 在数据字典中注册后, 才能够被规则引擎识别调用, 也可通过过程也可以访问决策。

2 结论语

规则引擎实现了基于业务规则配置, 实现同一程序可实现不同业务规则的情况, 适应电信目前业务种类繁多、业务发展快等特点。

3 附录:表结构定义

(1) 规则库过程定义表

包含字段:过程对象ID、事件类型标识、模块ID、库文件路径、源文件路径;

(2) 规则库决策定义表

包含字段:决策对象ID、事件类型标识、模块ID;

(3) 模块执行步骤定义表

包含字段:模块ID、执行步骤、调用对象ID;

(4) 属性定义表

包含字段:对象属性标识、所属类标识、名称、属性类型标识、属性大小;

(5) 决策步骤定义表

包含字段:决策ID、执行步骤、操作符类型、操作符、操作数1类型、操作数1的值、操作数2类型、操作数2的值、输出结果、下一个步骤;

摘要：当前电信计费话单预处理普遍采用处理方式有, 根据特定的业务话单编写相应的计费话单预处理程序进行处理, 对业务话单处理规则的增、删、改都需要开发人员需要修改代码。

基于规则的业务流程描述算法的研究第8篇

业务流程是企业运营的核心和本质, 其重要性毋庸置疑。随着经济全球化、信息网络化、需求多样化, 市场和客户需求都在快速变化之中, 这必然导致业务流程呈现变化、动态的新特点。传统的软件系统是以程序代码形式处理业务逻辑, 业务逻辑的实现严重依赖于过程性的语言。当需求发生变化时, 必须修改程序的代码, 从而使系统的维护成本增加, 系统升级更新变得更为困难。另一个问题在于, 软件实现过程中, 软件系统的业务逻辑分散在不同的各个模块之中, 这种分散和隐蔽的业务逻辑的处理使得软件系统的业务逻辑模糊不清, 在维护的过程中增加了对业务逻辑的调整, 不能对业务逻辑进行统一的处理, 提高了业务处理过程中各个模块之间的耦合程度。

在文献[1]中用时间驱动的过程分析方法来建立业务过程的概念模型, 强调了在分析过程中逐步求精的方法。文中说:“建立业务规则的过程是一个渐进分解的过程, 分解的结果将形成一个具有树状结构的层次规则库”。由于文中的业务语法繁多和复杂, 使得人们很难理解业务规则。

在机器学习的会议上, 文献[2]中指出人工智能和机器学习领域的研究对软件工程领域也有很多可以应用的技术, 并且强调应该多应用相关领域的研究成果。而自动化程序设计所涉及的基本问题与定理证明和机器人学都息息相关, 要实用人工智能的方法来实现, 是软件工程和人工智能的紧密结合[3]。

基于以上软件工程中部分软件系统实现方法的缺点以及人工智能领域的研究成果, 提出了在使用流程图对业务流程进行描述的基础上[4], 使用产生式规则对业务逻辑进行描述, 实现了业务逻辑的形式化和显式的描述和存储, 并且可以利用形式化的描述, 对业务逻辑进行部分自动化处理, 从而为智能程序设计的发展做了奠基石。

1流程图

程序流程图又称为程序框图, 它是传统的、使用最广泛的描述程序逻辑结构的方法, 也是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言, 能比较直观和清晰地描述过程的控制流程, 易于学习和掌握。并且流程图的表达方式比较接近人的思维方式。在程序流程图中, 用表示起止端点, 矩形框表处理, 表示控制流, 表示选择或决策以电子邮箱的登录界面为例, 用流程图描述该模块的业务逻辑如图1所示。在图1中, 顺序结构执行的条件为该处理执行完毕。例如从输入账号到输入密码的控制条件是账号输入完毕。

2产生式规则

知识表示是研究用计算机表示知识的可行性、有效性的一般方法, 是数据结构与系统控制结构的统一[3]。知识表示的研究既要考虑知识的表示与存储, 又要考虑知识的使用。知识表示可看成是一组事物描述的约定, 是把人类知识表示成机器能处理的数据结构。不同的知识之间, 存在着或多或少的联系, 其中部分是一些必然联系。产生式规则是用来表示事物间的因果关系, 以ifconditionthenaction的单一形式来描述, 将规则作为知识的单位, 是一种知识描述或约定法则, 具有和图灵机一样的表达能力。

产生式规则的一般表示形式为:前件→后件。其中前件和后件都是由逻辑运算符组成的表达式。条件部分常是一些事实的析取或合取, 结论通常是某一事实。产生式规则的语义是:如果前件满足, 则可得到后件的结论或者执行后件的相应动作, 即后件由前件来触发。

在自然界的各种知识单元之间存在着大量的因果关系。这些因果关系转化为前与结论, 用产生式表示非常方便。用产生式来表达知识的特点是格式固定、形式单一、规则之间相互独立, 整个过程只是前件匹配, 后件动作。匹配信息只是成功或是不, 一般无递归, 没有复杂的计算。模块性好。产生式规则中各规则之间不相互调用, 有利于对知识的增加、修改和删除。

3 业务规则

产生式规则是动作函数的简单表达形式之一[5], 业务规则就是采用产生式规则的形式来描述系统的业务逻辑。业务规则的BNF描述如下:

其中, F表示永假值, T表示永真值, Object可以是一个事件, 也可以是由若干个小事件组成的一个复合事件。

基于规则的逻辑描述是使用业务规则来形式化地描述系统的业务流程, 业务规则采用的是产生式规则的形式。现基于业务规则的业务流程的描述, 主要通过对流程图进行转换而来。定义Φ为从流程图G到业务规则集合BR的一个映射即Φ:G→BR, 映射的算法如下:

1) 把流程图G中的处理和选择映射为规则集合中规则所包含的状态;

2) 把流程图中的控制流映射规则集合中的一条规则;

3) 把流程图中控制流执行的条件映射为规则中的一个条件。

用产生式语法可以写作:BR1:IF逻辑表达式 THEN 执行事件。使用Φ把图1中的流程图映射为产生式规则如下:

BR1:IF用户登录系统∧进入登录系统界面THEN输入账号;

BR2:IF输入账号∧账号输入完毕THEN输入密码;

BR3:IF输入密码∧密码输入完毕THEN账号密码是否正确;

BR3:IF账号密码是否正确∧Y THEN进入系统;