建立事项驱动财务信息系统需要分析业务过程，识别重要的业务活动及其基本特征。目前常用的描述业务事项基本特征的方法是REA、REAL模型。

（一）REA模型

建立一个业务过程模型需要识别重要的战略性业务活动，并对这些业务事项的基本特征进行描述。业务事项的基本特征可以用5W（what，when，who，where，why）来描述，即何事、何时、何人、何地及为何。事项的描述还可以进一步深入，如描述事项为什么发生、执行过程中有什么风险、风险程度如何等。

REA模型描述了资源（Resource）、事项（Event）和参与者（Agent）三个实体及三者之间的联系。

资源被定义为稀缺的并为企业所控制的有形实物对象，它能为企业带来经济价值而且可以辨认和受组织控制。在传统会计中确认为资产的大多数项目都属于资源，但该定义又不同于传统会计中资产的定义，因为它不包括像应收账款这样可以推导计算出来的资产。应收账款是指顾客的销售额与所收到的货款之间的差额信息，因此它不是REA模型的基本元素，建模时不必包括应收账款这样的实体。

事项是指能从某方面影响组织资源变动的业务活动。生产、交换、消费、分配方面的活动都是事项。事项不限于能够进入传统会计簿记体系的经济事项，还包括其他不进行会计确认与计量的经营活动，如市场调研活动等对管理决策提供所需信息的经营活动。但它不包括明显为纯信息处理或管理决策等的事项，因为它们是对原始的经营事项信息进行的操作或分析、选择，是由经营业务产生出的进一步的结果。

参与者是参与事项的单位、部门或个人。收集参与者数据是为了更好地计划、控制和评价其基本活动。参与者包括内部参与者（如销售员、采购员、生产人员、生产或业务部门）和外部参与者（如客户、供应商等）。

资源、事项和参与者合称REA模型中的实体。这三个实体之间存在以下四种联系。

（1）资源一事项联系，又称存量一流动关系。其中资源为存量，事项为流动，包括资源流入和流出的事项，以及用于表示那些增加或减少资源的事项。

（2）事项一事项联系。这种联系又称二元联系，是指组成一个业务循环的导致两组资源一增一减的两组事项之间的关系，即一组事项导致一组资源流入，另一组事项导致另一组资源流出，流入和流出的资源总是相互联系着的。如在销售与收款循环中，销售事项引起存货的减少，而收款事项引起现金的增加，减少的存货与增加的现金相联系，故销售事项与收款事项的联系就是二元联系。

（3）事项一参与者联系，又称控制关系。控制关系是内部参与者、外部参与者和事项之间的多元联系。为便于理解，这种多元联系常常被分解成两个二元联系，即事项一内部参与者联系和事项一外部参与者联系。

（4）内部参与者一内部参与者联系。这也是二元联系，又称责任关系，描述的是上级对下级进行管理和下级对上级负责的关系。

上述各种联系如图3-3所示。

图3-3　REA实体的基本联系图

采用REA模型建立财务信息系统，需要采集业务事项的多方面信息，而不是只记录汇总后的结果。例如，不能把几张领料单汇总后记入系统，而应如实地反映这几张领料单的发生及其具体内容。这样，在财务数据仓库中记录了经济事项的多方面数据以后，通过专用或通用的报告过程（加工程序）支持用户所需的信息视图（个性化或常规报表）就非常简单了。因此，在基于REA模型建立的财务信息系统中，并不存在传统财务信息系统中的日记账、分类账、会计科目表、借贷记账法等元素。基于REA模型建立的信息系统不仅能利用业务事项的详细数据生成财务报表和报告，还允许信息用户自己定义所需的信息视图，确定需要哪方面的信息，汇总程度如何，以何种形式输出，从而支持各种层次、各种职能领域的信息需求。此外，REA模式不重复存储同一事项、资源、参与者的属性数据，因此避免了数据存储冗余和不一致。

1.基于REA的系统实现机制体系

本节基于REA的系统实现机制体系指的是在模型构建完成后如何去具体的实现系统构建任务，完成系统的目标，核心是如何完成业务流程的处理、信息的处理、实时控制和管理决策、并通过报告工具生成用户所需的全方位视图。

系统实现首先应该考虑的就是分类后的信息如何进行采集，需要设计一个输入界面，也就是下面详述的事项凭证设计，各环节业务人员将本业务过程的相关事项记录在系统中；之后会计人员对于经济事项信息进行审核，得出抽象的财务数据，进行相关的信息存储工作，以原始数据形式向语义结构、数据结构转变，自动存储在系统中进行相关的模块化归类处理，并将财务处理结果和分类处理结果统一转存至数据库中，由会计从业人员进行集中管理，因为信息量特别大，所以需要借助大容量数据库来完成；当内部人员有信息需求时，就可以借助这一基于REA的会计信息系统应用平台，采用事项驱动方式，通过输入设备敲击相关信息代码即产生多种类视图文件、财务报表等；在信息输出过程中，要进行授权管理以保护信息安全，按照不同的级别分类，只有拥有相关级别的权限，才能使用口令或者盾牌进入系统查询，而控制反馈通过实时控制过程来实现；最后应该设计信息的输出界面，完成系统构建。由此整个业务过程与REA会计信息系统过程实现了财务业务一体化管理，模型构建具有了理论上的可行性。

（1）基于REA的会计信息系统事项凭证设计

在对业务流程的具体信息收入过程中，我们应该注意的是虽然REA系统要求录入的是全面、未经修改的原始数据，但也并不是说应该事无巨细的穷举所有特征，我们要做的是把握一些关键特征即可，也就是不描述这些特征可能会使我们不能准确的还原信息，本书认为，特征可以分为以下几类：发生的事项名称、编号、时间、地点、参与完成者、使用的企业资源、数量、金额以及计量方式；采集记录这9项通用特征，对于一些事项的某些重要的、非通用的特征（另外记录即可）另外加入即可，可制作一个事项输入表，用于信息输入界面。输入界面如图3-4所示。

图3-4　事项输入表

（2）基于REA的会计信息系统数据库构建

在信息输入完成后，要进行存储工作，信息按照类别存储在事项数据库中，数据库由事项库、参与者库、资源库等构成，每一个库中存储的是各自的资源，但是单单使用这种普通数据库难以满足系统的大量信息输入，实现不了系统的可持续发展。为了满足信息的多维、大量存储，需要借助数据仓库技术，其主要用于支持决策、面向分析类的信息处理，并且可以实现对于不同数据源的信息有效集成，按各自主题重组，也就是物理存放于其他数据库，最大限度的存储财务、非财务信息，可用于决策支持体系的系统构建。

（3）基于REA的会计信息系统实时处理模型构建(www.daowen.com)

实时的会计信息系统分析是体现在数据的处理上，对于实时的信息系统构建也就是对数据库的实时构建研究，当数据存储到数据库中之后，进一步将数据库划分为模型库、知识库和方法库，设定一系列的数据处理规则和标准化程序进行数据的抽取转化装载处理，将之装载至元数据库和数据仓库中，进而在系统输出接口有相关的指令要求时，进行一定的数据分析得出所需的视图。实时数据库模型如图3-5所示。

图3-5　实时数据库模型图

由图3-5，我们知道，数据库中数据是实时动态性的更新，其包含所企业业务流程中的所有相关数据，也可以认为包含所有的财务、非财务信息。其中的模型库主要用于提供标准的、定制的模型，如预测、投/筹资管理模型等；而其中常用的模型算法则用方法库存储，如数学统计方法、各种管理成本计算方法以及针对一些前景预测所运用的方法等；知识库则用于存储管理决策过程中可能会使用的会计专业类知识、模型相关的特性等知识；数据仓库用于存储大量的财务、非财务数据，以此多样性信息支持不同用户需求。联机分析处理是依次深入、循序渐进的一种分析处理方法，其根据提出的假设，提取具体的数据信息，并采用较为直观的方式提供给用户。数据挖掘则采用的是在存储的数据中提取有效信息，帮助决策者寻求不同数据间的联系或者一些隐藏的、对决策有用的信息。人机交互平台则是通过人机交互界面，通过用户的信息需求进一步分析确定用户所需的信息输出模板。

2.基于REA的会计信息系统信息处理模型构建

传统的会计信息系统采取的是功能驱动方式，也就是以实现报表的输出功能为中心来推动信息系统运作。而事项驱动信息系统采取的则是指当某一事件发生时，参与者输入相关代码，系统程序指令依照既定的规则去执行业务流程；而当需要某一业务流程信息时，只要输入相关代码，系统的程序指令就开始执行搜集输出信息任务。我们可以通俗的理解为日常使用电脑过程中，当需要某个界面时，用鼠标点击即可自动搜罗所需信息，这个过程就是事件驱动的过程。本书接下来要研究的REA会计信息系统构建过程，通过加入事件驱动技术，平时并不处理数据库，数据仍是原始状态保存，当用户需要某个信息时，通过使用相关代码，输入系统即可输出所需的信息。事件驱动会计信息系统与传统DCA会计系统的区别在于事项驱动方式并不是按照事先既定的最终报表视图来设定程序，而是构建系统之初先定义基础性的事件，整理成各种基础性视图，这也是数据库中的最小组成单元，以此满足用户的多样化需求。其基本图示如图3-6。

图3-6　事件驱动模型图

事项驱动信息系统实际上是将企业中所有事件的信息集中存储在一个逻辑数据库中，数据库的设计首要的是在逻辑上划清各种事件，并按照前述方式将事件分成基础事件，基础事件是数据库中的最小存储单元，设定好系统的处理规则，当触发该业务处理规则的事件发生时，系统可以自动启动相应的程序处理信息，实现自动加工；企业内部各部门包括生产、业务、人事、财务等都可以通过系统网络在共享数据库中实时存取信息。

参照REA模型建立的事项驱动会计信息系统中，用户不仅可以在数据库中得到详细的财务数据生成三大报表，还能根据自己所需定义不同的非传统视图，确定信息的集散程度、输出方式等，支持各种信息需求。

3.基于REA的会计信息系统输出方式分析

鉴于单一的会计报告模式难以满足不同用户的需求，那么按需的实时报告模式必然派上用场，本书选用交互式实时报告会计模式构建基于REA的会计信息系统，交互式实时财务报告模式在基于REA的模型构建中极易实现，因为二者的目标是一致的，旨在将财务和非财务要素按照一定的会计方法和不同的表达方式处理，通过报告生成器自动输出所需报告，提供实时报告，实现用户与企业的业务沟通。这种灵活、实时、交互式的方式能很好地满足用户需求，减轻不同用户的信息不对称现象；也使得用户在任何时点都可以及时获取最新报告，满足决策需要。

（二）REAL模型

REAL模型是REA模型的一个扩展。它在REA模型中增加了一个新的要素—地点（Location），即业务事项发生的位置。在全球经济一体化的背景下，经济事项可能在任何地点发生，而管理者又需要收集业务发生地点的信息，则在模型中表示出业务事项发生的位置，在系统设计时就可以合理地决定数据的采集地点、处理地点、使用地点和传输路径，从而提高系统的效率了。

图3-7为表示资源、事项、参与者、地点及它们之间联系的REAL模型。

图3-7　REAL模型

建立REAL模型的依据是企业的生产经营业务流程。由于一个业务流程由若干业务环节上的事项组成，故建立REAL模型前首先要界定企业的业务流程，识别每一流程中重要的战略性业务事项，然后对每一个业务流程分别建立REAL模型。

利用REAL模型对企业业务流程建模的一般步骤如下。

（1）明确要建模的业务流程，确定流程的范围、起点和终点。

（2）识别应包括在REAL模型中的业务事项。对要建模的业务流程进行分析，找出需要把握的业务事项，包括主要事项和辅助事项，但不包括信息处理、管理或决策事项。这是因为记录的有关经营业务活动涉及的资源、事项、参与者及其属性的数据，已经足以生成管理和决策所需的信息。

（3）识别进入REAL模型中的事项动用的资源、参与者和发生地点。

（4）识别事项、资源、参与者、地点之间的相互行为、特征，以及它们的属性。

（5）识别资源、事项、参与者和地点之间的直接联系。

（6）根据上述分析和识别的结果，画出业务过程实用的REAL模型图，并进行验证、修改和完善。