又一个星期过去，工作累得耽误写文章，妹的，今天继续。

上文书说到系统对账的事情，三家公司一年的帐，其实只搞定了一家，就是粮油总公司的，剩下两家是子公司，处理起来那是相当的棘手，一家我把它叫做粮油香港，另一家叫做粮油美国。

首先是地点问题，一家在香港，一家在美国，只能远程沟通。香港那家还好，时间上基本跟我们这边同步，可以通过电话、邮件、MSN的方式进行即时交流，那边主要联系人是个香港人，通常称她Regina，粮油美国就比较麻烦，虽然是中国人在那边，但是时差对不上，基本上只能通过电子邮件交流，今天发邮件，一般第二天才能回复，沟通效率低下。

然而有一点是比较方便的，两家子公司的问题都一样，解决了一家，同时就可以搞定另外一家，反过来说，很可能两家你都搞不定。

老实讲，用上文书提到的方法，面对这两家已经无效了，客户方在GL模块人为调整过多不算，在子模块也做了很多额外的调整，所有数据乱在一块，没有一个核对的标准，好在客户方搬出了另外一组数据，原来他们另外还有一套财务系统，那里的数据是标准的，之前的系统调整也是为了和这套财务系统相符合。

为了凑对这套数字，当时的执行经理是东东（貌似之前没有详细介绍，以后会提到），建议重新上线，意思就是把这套设置好的系统废掉，重新弄一套新的系统，把业务数据导进去。听到这个建议我犹如五雷轰顶——如果这么干，意味着可能真的要连续一周不睡觉了，尽管不是我一个人在战斗。

出于生理机能的自我保护，我强烈的进行了抵制，技术这边的负责人小永也是跟我一样的意见，于是乎最终一个耍无赖的方案出台了：

第一步，根据那套正确的数据（各个会计科目的科目余额已经确定），先在子模块把科目余额调整正确，之后把数据全部导入到GL。根据会计记账全责发生制原则，一笔业务的发生必然牵扯到借贷方，现在为了纯粹的调整，会出现这样的会计分录：借：应付账款 ，贷：中转科目，或者反过来。这样，子模块的会计科目（比如应付账款）对正确了，但是中转科目会有很多乱七八糟的调整后的数字，不管它，全部导入GL。

第二步，此时的GL各个会计科目的余额已经一团糟了。我们要做的就是录一张大凭证，借贷方相同，但是金额是负数，把原有的科目余额全部抵消掉。这个时候，在GL中，你运行资产负债表和科目余额表，发现所有的科目余额就都是0了。

第三步：又录一张凭证，数据自然是参照正确的那组，相当于给GL系统录入了一张资产负债表和科目余额表。这个时候，子模块和总帐模块的所有会计科目余额数据就全部对上了。此时，GL中是没有中转科目的余额的，而子模块里面的那些中转科目余额，就让它们像烂肉一样继续烂在子模块里面吧，因为只要正式的会计科目余额正确了，是不会有人去关心这一年的财务数据中的中转科目的余额的。

如此这般，这个世界平静了。

2009年夏天的时候，粮油香港和粮油美国2008年的财务数据就被我们这样处理掉了。然而2009年头几个月三家粮油公司的财务数据还是不对的，好在就几个月的数据，按照老办法一个月一个月的勾兑，总算基本处理完毕，客户被我们严打了这么长时间，也认识到问题的严重性，擅自在GL模块调帐的事情也基本上杜绝了——毕竟对不上数据，双方都辛苦。

在那个赶进度的岁月，因为粮油香港的对账问题，香港那边的财务老总几乎就要失去耐心了，加上跟Regina沟通不顺畅（香港人其实也还OK啦），急得这边有过把我扔到香港去处理的念头。现在想起来，假公济私的去旅游一次也没什么不好吧？呵呵。

这里的博客是会被系统同步到人人网的，二十七集的时候有个大学同学提出了问题，其实蛮有针对性的，直接放到这边说吧：

问：在总账模块中不是可以设置不能录入某些科目，一定要在应收或者应付模块做才行，是不是可以避免第二种情况呢？（见第二十七集）

答：做安全性设置，把相关科目在GL模块里面屏蔽掉，让操作者看不到，自然就改不了数据了，但是这样一来，子模块带有这个科目的数据导入GL以后也将看不到。所以最好是做个性化设置，在GL里面录入相关的科目系统会报错。数据访问权限集这个功能或许可以实现，待测试。

目前最好的方案是，做个检查报表，每月检查有没有异常录入的数据，最好每天检查一次，有不良动静就马上邮件通知相关人员，及时做处理，并对违规人员作处罚。