报表数据的不一致，必须要涉及到Oracle EBS这套系统的模块式结构。
前几期有谈到模块直接的关系，按照业务流程的一般规律，财务系统可以细分为这么几个模块：AP（应付账款模块）、AR（应收账款模块）、FA（固定资产模块）、CE（现金模块）以及GL（总帐模块）。GL属于总模块，其他的部分属于子模块。所有的子模块相关数据都会在每个月的月末做月结的时候传送到GL，最终相当一部分重要的财务报表将从GL里面输送出来，比如最基本的资产负债表、利润表和现金流量表等。
因此一般来说从子模块导入到GL总模块的数据应该都是一致的，如果子模块是数据A，总模块是数据B，一般来说有两种不一致的可能（也有其他情况）：第一，子模块的数据没有完全导入到GL，导致A>B；第二，客户方擅自在GL模块的相关科目里面录入数据，导致B>A。
举个简单的例子，AP模块里面记录两张应付款的发票信息，一张是30万，一张是70万，那么在AP中，应付帐款这个科目余额就应该是100万，如果导入GL总帐，在GL中，应付账款的余额也应该是100万。可如果GL的报表中应付账款只有30万，说明AP中另外70万的信息没有导入过来，我们就要去AP里面调查为什么这笔70万的应付发票信息没有传送到GL，最终就是要把这张70万的发票处理好，使得数据可以最终顺利传到GL。一般出现这种情况都是因为录入的发票信息有问题，没有最终形成标准的数据导入GL。
性质最恶劣的是第二种，GL里面的应付帐款达到了150万，就是说平白无故的多出了50万。毫无疑问，这笔50万是客户自己在GL里面手工录入加进去的。为什么客户要这么干？很多时候是为了调帐，但是这样一来，AP那边就缺了50万，怎么办？补录一张发票——然而真的有实实在在业务去对应这50万吗？我们就不得而知了。牵扯的问题其实会很多，这里就不一一描述了，解决这个问题，还有很多后续的操作，但是问题产生的主观因素，就是客户方藐视ERP系统业务财务一体化的理念，割裂了总模块和子模块的关系，擅自在GL里面调整会计科目余额。
对此，我们一般都是有严格的要求，在子模块中会产生余额的会计科目，严禁直接在总模块里面额外录入数据进行调整，确实需要调整的，必须现在子模块调整，最终把调整的结果导入GL总帐模块。
我在CT项目上经历的几次性质比较恶劣的对账事件，就属于上述两种情况，刚才举的例子比较简单，你可以拓展一下，如果一家公司一个月的应付发票有500张，也就是说AP的应付帐款明细表有500条数据，GL里面的导入数据的明细有473条，我就只能先从AP里面导出500条数据到EXCEL，从GL里面导出473条数据到EXCEL，利用各种手段逐笔勾兑，查出来到底哪一笔发票的数据导入失败。
你想想啊，如果你把发票的数量变成1000张，时间变成12个月（悲催啊，这家公司连续12个月的应付帐款科目总模块和子模块对不上），公司数量变成3家，会计科目涉及到应收帐款、应付帐款等4个，然后由我一个人来做，这是一个多么庞大的工作量。最终，貌似花了好几个月的时间，三家公司一年的帐上总模块和子模块的相关数据被我整平了。所谓的整平，其实只有其中一家的是一笔一笔数据肉眼看勾出来最终处理平的，剩下的两家已经无法挽救了，用了别的处理办法，下次接着说吧。
这里感慨一下，现在这份银行的工作，刚经历了一次长达半个月的从早上8点到晚上10的所谓的魔鬼式加班，但最近跟以前的ERP同事聊天，一个说到他的项目组人员已经连续42天不休息从早上9点到晚上24点的工作、另一个说有过连续20天不睡觉（其实夸张了，是睡那么两三个小时）的经历，相比之下，现在所谓的魔鬼式，又算什么呢？
都是苦过来的人，我算是经历过，但是最终又逃脱了，选择了一种职业，就选择了一种人生，你认同吗？
