轻量级统一会计系统
版权声明：本文可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者署名及本版权声明。
和几个同事（其中一位做会计方面的工作很长时间，有很丰富的经验）对原有会计系统进行了一番改造，可以说是彻底的重写，用了一些新的思想在里面。最终这个系统由于种种原因没有上线采用，而只是束之高阁，所以我在这里才能够把它公开，抛砖引玉，供大家研究、思考。
[功能特点]
1、功能集中
本系统只专注于会计记账模块，其外围功能及设计皆围绕会计记账。
其目的是为了保证会计记账准确、配置方便、有较强扩展性。
在保证会计记账准确的前提下，额外的或者项目自身特殊的会计核算功能以外围扩展的方式补充进记账模块。
2、功能齐全
目前的会计系统的功能主要有如下几块：
基础配置类
代码配置，科目配置，分录配置（含手工事项配置），交易-分录设置
会计交易类
记账流水查询，汇总凭证查询，分户余额查询、手工事项登记，通用记账
批量处理类
分录拆分，余额汇总，总分校验，凭证汇总
应用API
c接口，java接口
报表统计类
3、易于整合扩展
记账模块功能集中，所需功能基本在本模块内即可实现，与其他模块松耦合；本模块可提供java版本的API和c版本API，与其他系统较易整合。
如果将后台批量功能也由java实现，则在部分项目中无需c环境即可轻松实现会计记账功能。
模块中的很多配置采用xml格式存储，可以通过增加xml标签和增加标签属性来满足扩展的需要。
4、配置为主
在会计记账模块设计之初的一个原则就是尽量采用配置的方法实现部分功能，尤其是分录的配置。
目前1.0的版本已经实现了会计分录的完全配置化实现，可以在线增改科目、更改会计分录、更改交易码对应分录码等。
5、多币种支持
由于本模块在设计上的考虑，对于币种可以先天支持，对于有外币要求或虚拟币种要求的系统能有很好的支持。
6、轻量级
记账模块的全部功能通过10张数据表实现；
底层记账API只提供一个函数；
业务层API所需函数较少；
配置功能和会计交易在java控制台上实现；
用了一个免费第三方xml解析库支持（c环境下需要，java环境不需要额外类库）；
适合中小型系统（目前在2CPU，4G内存的UNIX下，速度在100笔/秒左右）；
[功能设计]
1、基础信息设置
此类功能主要是设置会计模块相关的基础信息，包括：
代码设置：会计配置中用的一些代码，比如业务属性、金额属性、币种等。
业务要素集设置：每个交易可以指定携带的不同业务要素，从而增加核算和统计维度。
科目维护：维护会计科目，增删改。
2、分录设置及交易-分录匹配设置
此配置功能是此会计模块的核心配置功能。主要包括：
分录设置
设置分录借贷方科目及借贷方科目可携带的业务要素，每条分录的识别码称为事件码。分录设置的时候，可以指明该分录是用于联机交易还是手工事项。
交易码-事件码设置
将系统中交易码与对应的会计事件码进行匹配。
3、会计交易
此类功能主要是为了满足会计人员的日常一些管理工作，主要包括会计流水查询，汇总凭证查询，余额查询，手工事项，通用记账。
其中余额查询可以查询科目余额不同的分户余额；通用记账是为了满足特殊情况的调帐进行使用的，可以有人工随意选择借贷方科目。
4、批量处理
对于批量需要处理的会计功能，主要有如下几个：
1.分录拆分：其功能是为了将分录中携带的业务要素拆分出来，为下一步的明细核算提供数据基础。
2.汇总凭证：将相同事件码的记录进行汇总，从而对于财务人员来讲，每天看到的凭证很少，只有出现帐务问题的时候才会去查会计流水；至于凭证汇总的粒度是可调的。
3.总分核对
4.业会核对
5.科目汇总
6…..
5、报表统计
会计中的报表统计较少，比较关键的是资产负债表、科目余额表等。
另外，本系统中的会计数据含有大量的业务要素，可以为一些统计提供另外一个角度的数据，在后续”综合应用”里再详细说明。
[技术设计及实现]
1、设计理念
“会计是一项服务性的活动。它的职能是提供有关经济个体的数量信息,主要是财务性质方面的。这些信息,在企图作出经济决策时肯定是有用的。”
–美国注册会计师协会
本系统设计的目的是为了准确、详细、全面的处理和揭示各种交易中的财务性质。
对于财务性质的描述，在本系统中称之为”要素”。
本系统中的要素分为两类：
业务要素
指的是能够体现和区分不同交易业务背景的东西，这些东西在具体表现中应该是交易的一些属性，明的或是暗的，那么当这些属性在会计记账的时候，跟随着会计科目进行会计系统的时候，那么这些交易属性就变成的财务属性。
它可以是任何东西或其组合：机构、往来机构、客户、部门、人员、产品、业务种类、币种、供应商、合作机构、银行、账户、卡种、国家、地区、分销商、货物代码、卡号、条形码、汇票号、支票号、自定义要素等等。
金额要素
金额要素较好理解，在一个交易中会含有不同的业务要素，同时交易的金额也同样会根据用途的不同也会被拆分开。一般来讲，通过交易金额以及部分业务要素，我们直接或者间接可以得到如下的金额要素：交易金额、业务主要收入、业务附属收入、应付金额、应收金额、应分利润、应付成本等等。
2、功能逻辑
添加业务要素和金额要素代码：
必须设置代码形式。（长度限制在12个字符以内）
比如业务要素
项目 TxnPrj
往来项目 CurtPrj
产品 ProdCd
往来产品 CurtProd
客户 TxnCust
往来客户 CurtCust
渠道 TxnChnl
帐号 AcctId
参考号 RefId
比如金额要素
交易金额 ATSAmt
业务主收入 TxnMReve
业务副收入 TxnSReve
交易成本 TxnExps
应付金额 ATSPaye
应分金额 ATSDivs
备用金额1 ATSFAmt
备用金额2 ATSSAmt
3、数据库设计
[系统整合示例]
在本示例中，将按照在实施会计记账过程中的流程进行说明每一步骤中所需需要承担的工作。
为简化过程，我挑选商户汇款业务和支付网关业务作为讲解对象。
整合步骤
1、分析业务流程和资金流程，确定客户会计核算要求
商户汇款业务流程
商户汇款资金流程
流程中涉及的成本、收入，债权、债务
支付网关业务流程
支付网关资金流程
流程中涉及的成本、收入，债权、债务
客户针对会计系统的核算要求
明细核算应收应付款
明细核算各个银行存款及现金流
明细核算收入和成本
自动生成会计汇总凭证
将汇总凭证提供公司财务，满足财务并表需求
2、研究确认会计分录及交易流程关联关系
具体分析讨论需要客户积极的全程参与
需要客户认可
考虑全面，替客户着想
要经过多笔评审
涉及业务流程变动的，要协调业务部门
3、整理会计科目
需要客户认可科目名称
以客户会计部门为主
会计科目一旦确定，上线后不得随意进行修改
4、编制会计分录事件及交易关联表
仔细分析交易过程，区分单个交易中的辅助识别码
认真测试，必须将涉及的分录在测试案例中全部体现
5、确定业务-会计接口方案
会计接口的执行方案是实施会计记账功能的关键。
不要拘泥一种形式，需要根据项目情况灵活考虑。
在考虑接口方案的时候，有几个原则：
业务交易程序改变最小
与业务逻辑耦合最小
业务开发人员逻辑参与最少
此种会计接口实现方案的特点：
对原有系统的改动较小，只是扩展了交易信息表的属性
原有业务交易的程序逻辑不需要做任何改动，会计记账对业务交易是透明的，避免业务交易开发人员由于对会计不熟悉而造成记账错误。
会计记账根源统一，便于会计记账问题查找溯源。
6、编码和会计数据配置
其后进行编码和会计数据的配置
[综合应用举例]
本系统虽然较为轻量，但由于在记账凭证中可以携带大量的业务要素，因此通过对现有模块中的数据进行”挖掘”和部分扩展，可以为部分非会计的功能提供帮助。
在以下的内容中，简单的将这类的数据应用展现出来。只是一个抛砖引玉的作用，希望大家能够尽量的去扩展这部分的应用，从而将会计记账模块的功能完善的更彻底充分。
辅助业务统计
在记账流水表中，有交易流水，根据交易流水和会计事件码，我们可以得到该笔交易的做了何种交易逻辑。
根据这种方式，我们可以通过记账流水完成部分业务统计。
例如：需要统计银行退汇和重汇的数据，但是银行退汇的数据来源于多个交易，由于设计初并未将该部分数据做重点考虑，导致系统在该类统计数据时存在困难。
在记账流水中，通过统计几种事件码的数据，就可以获得此类数据。
清算处理
在记账流水中，如果将交易机构、交易对象，甚至是交易对象下的子对象都作为业务要素携带。
在根据业务要素分拆记账凭证后，我们就可以很容易的获得各个层次的对象在各个科目上的发生额。
以这个数据为基础，可以较为容易的提供清算报表使用。
而且由于这个清算是以会计为基础的，在保证会计记账完全正确的前提下，不会发生业会不符的问题。
财务指标统计（利润贡献率等）
如果携带的业务要素中有渠道代码、部门代码、操作员代码、合作机构代码、分支机构代码，那么根据业务要素进行统计的时候，我们很容易得到任何一个层次对象的利润贡献率、成本消耗，成本费用率， 净资产收益率等等。
在比如根据每天的发生额，在进行一些序列分析的时候，根据业务要素统计的粗粒度，可以统计各个对象的交易指标分析数据。
而且保证是业会一致的。
多币种游戏
…
[待完善功能]
本系统中缺少收入分配的功能，虽然收入分配可以作为会计外挂功能，但如果集成了收入分配，将更加完善。
本系统暂未提供总分核对的功能，因为目前的设计中已经将分户的数据从同一个数据源汇集的，只要程序无bug，总分在先天上是一致的。
本系统暂未开发业会核对的功能，如果后续需要完善，应该将业会核对以规则的形式在系统中实现。
在业务核算上，希望能够将核算规则通过配置的方式实现，目前在本版本中暂未实现。
[FAQ]
Q：为什么说本系统先天是支持多币种的？
A：因为币种其实就是交易附带而来的一个业务要素而已。如果有需要，甚至一个交易可以附带好几个币种进行表示都可以，这并不会增加任何额外的会计记账功能。
Q：为何要用字母设定元素？
A：原因是因为在分录存储数据时是采用xml格式的，所以最好采用较易理解的名称，另外，这些设定是比较底层的功能，这些代码一旦设定，在后台的程序代码处理逻辑中是直接coding的，所以一旦设置完成，就不能随意修改。
Q：为什么要采用xml？
A：xml格式作为载体，其信息变现丰富；格式较为灵活，扩展性好；解析方式较为成熟，比如在java中不需要额外类库就能实现xml的解析使用，在一些配置功能中能够满足复杂的应用要求和扩展要求，而c环境中xml解析库libxml2也是比较成熟的。
对于xml的解析效率低和数据传输量较大是一个缺点，如果此要求很高，可以考虑如何在会计模块中用Google的protocol buffers替换xml。它的介绍可以参考如下网页：
http://www.yeeyan.com/articles/view/sevenever/11040
Q：xml格式数据存放在什么地方？
A：目前xml数据全部存放在数据库字段中，字段长度是varchar2(2048)。排除xml标签，最多可以容纳大概有150个左右的业务要素和标签，可以满足大部分业务的需要。存储在数据库中也是为了方便管理，暂不引入任何外部配置或数据存储文件。
Q：为什么要支持设置多个要素集？
A：在一个项目或系统中，一般来讲业务要素和金额要素都是有限的，完全可以设置一个大的全集，从这个角度来讲，没有必要设置多个集合，甚至一个配置文件就可以搞定了，但在设计时，考虑到这种业务场景：如果是一个会计记账核心平台，他支持的交易的业务背景很多，每个交易携带的业务要素也有可能差别很大，在这种情况下，如果完全是一个大的全集的形式，在管理和理解上会增加困难，此时最好是不同业务背景不同的要素集合。另外，在及其复杂的应用下，将要素集分开管理，也可以在要素集上扩展校验功能，比如，要求某类交易必须携带某种要素的值；或者某个要素的值必须是某个数据序列中，否则报错等等，通过在xml的里增加属性，比较容易达成这种校验。
Q：产品码有用吗？
A：一般来讲，产品码在很多地方是没有设计的，其实质意义指的是一个企业中推出的不同应用（服务）。有可能一个系统提供好几种产品，也有可能一个产品是由好几个系统协助完成的。
只有在多种产品要求不同的记账规则和手段的时候，用产品码进行区分是比较清晰的。
#更新记录
| 日期 | 版本 | 说明 |
| 2008-09-15 | 0.1 | 初稿 |
| 2008-09-16 | 0.2 | 增加待完善功能、FAQ |
最新评论