认识对象
    总帐管理模块是 ERP 系统里的信息最下游, ERP 系统中, 多数的模块信息最终会反映在总帐管理模块!
    从逆向角度来看, 总帐管理模块里的每一个科目, 都可以与上游的某个管理模块(如果该模块已被开发的话) 对应, 这就是 "总帐" 的意义!
    事实上, 许多 ERP 厂商也是从总帐管理模块开始他们的故事!
   
    ERP 系统里, 上游的所有交易细节在进入总帐模块时都会被约化, 只剩下少数概念上的信息: 科目, 预算, 传票交易!
    "科目" 代表交易的原因, "预算" 是预定的交易, "传票" 则代表实际的交易! 每个交易都有原因, 所以预算与传票都是以科目做为依据; 而且, 所有的系统输出项目 (Output, 包含: 报表, 统计图表, 查询) 亦都以科目为依据, 呈现出各种不同角度的结果!
   
    交易原因可以一直细究, 例如: 企业在 X 家银行里存款, 而且在这些银行各有 Y 组账户, 每个账户里可能有 Z 种币别的存款!
    当每一种"原因" 都被赋予一个科目的编号后, 集合这些科目就可以形成枝繁叶茂的巨树结构, 几个类似的交易原因("科目") 可以总结为较为抽象的因素(父阶科目), 而每个科目的交易(预算, 传票) 也被纳入其父阶科目的交易统计!    
    
    肥胖并不健康
    在手工做帐时, 大抵会同时准备几本账册, 当传票窗体/ 预算数据确认后, 其交易数据会被额外登录在各个科目的个别账册中(以下简称"过帐"), 其主要的目的在使科目交易的统计(以下简称"归阶") 分散在日常的作业时完成, 避免在查阅报表时耗费大量人工或时间去进行统计!
    在关系型数据库被应用前, 多数的信息系统也会模仿手工作业的行为: 储存交易, 并且过帐(异动相关账册内容)!
    事实上, "过帐" 动作可视为交易数据被复制到几份账册! 数据一旦被复制到两处(以上) 的位置储存, 即会衍生以下几个问题:
    一. 难以分辨真伪: 不论手工做帐或者应用信息系统, 在为数甚多的过帐动作中, 一丁点的人为失误或程序错误(人难免失手, 马难免失蹄), 就会造成窗体与相关报表之间无法勾稽, 而这些不吻合的差异并不容易厘清, 就像以下的 W 问句: 哪些数据是不正确的? 何时发生过帐错误? 什么原因造成数字不符? .....回答这些W 问句并不容易, 即使投入了大量资源!
    二. "信息不吻合" 的隐忧: 系统输出项目的条件或范围不一, 因此可能分别取用不同账册的内容做为数据来源! 当不同位置的信息不一致时, 会导致这些输出项目的结果也彼此矛盾, 毁及系统的可信任度!
    过帐的动作愈多, 发生失误而造成信息不符的的可能性愈高! 因此, 我们可以将"过帐" 视为高风险性的操作!   
    
    瘦身的良药妙方
    在关系型数据库面世之后, 由于SQL 语法可以在相关数据之间产生关联, 并且迅速统计大量数据, 这些能力合适地贴切过帐动作, 因此, 我们可以考虑尝试舍弃"过帐" , 改采应用 SQL 语法实时统计交易数据, 来达成总帐管理模块里数据归阶的需求!
    如何以 SQL 语法实现交易数据的归阶呢? 在总帐管理模块中, 有三份关键数据, 包括: (a) 科目与父阶科目之从属数据, (b) 交易数据(可能为传票/ 预算/ 两者皆有), 以及 (c) 统计过程中暂存的多维度资料!
    只要能够撰写精确的SQL 语法, 由科目阶层的最末端(交易科目) 开始, 根据阶层逐步统计交易数据, 并且纳入共同的父阶科目, 再将之写入暂存资料, 直到最高阶科目(主科目) 为止! 这个过程包含两层循环, 内层只需要比科目长度还少的循环次数即可完成! 下面是程序性的表达方式:
   
        ┌ 依次处理 (1)期初, (2)期前, (3)本期, (4)期末 不同时段
        │   1. 将指定条件内的 (b)交易数据(传票数据或预算) 写入 (c)暂存资料
        │┌ 自 (a)交易科目起, 至主科目止
        ││ 2. 由 (c)暂存数据中统计科目交易数据, 结合 (a)这些科目的父阶科目后, 写入 (c)暂存资料
        │└ 往上一阶父阶科目
        └ 处理次一时段    
    
    瘦得健康
    这个机制完全透过SQL 语法实现归阶, 因此, 灵活运用SQL 语法是归阶机制成功的必要条件!
   
    在实现以SQL 实时运算替代交易伴随过帐之后, 只要付出几秒钟的成本, 执行这个共享机制以完成交易数据的归阶, 即可以提供所有输出项目一份统计后的完整科目交易信息! 这些输出内容由于全部根源自相同的归阶结果, 所以一定"表表相符" (除非SQL 语法有误)! 此外, 只要将交易数据(传票数据或预算) 稍加整合统计, 即可轻易地验证这份归阶机制的结果!     
    
    有效的减肥
    对于许多已经存在的总帐管理模块而言, 如果经常发生上述"总帐肥胖症" 病征但仍束手无策的话, 改写的负荷并不沉重!
    最重要的, 要先根据原有的数据表结构与关联, 实现上述可以共享的归阶机制! 只要验证归阶结果正确无误后, 接着只需要在总帐管理模块中所有的输出项目内改变数据来源, 转而由归阶机制的结果(暂存数据表) 取出所需要的数据, 然后就完成一套稳定的总帐管理模块了!
   
    最后, 您相信让总帐管理模块从"病恹恹" 变成窈窕健康真的可行吗? 笔者确实实现了! 需要付出多少成本呢? 这就需要视您是否重视总帐管理模块的问题了!