子模块帐与GL的不相符

sunofbeach

最初由 yegiant 发布
[B]
Oracle就是会出现BUG导致不能过帐从而使子模块与总帐科目余额不符,另外还有一种情况就是子模块过帐到总帐中修改会计期间.为了对比数据,我这里是开发了报表 [/B]

不能过帐不会导致子模块和总帐科目余额不符，而修改会计期的情况本身就是核对不上的，报表也没有什么意义哪！我倒是遇到过凭证和子模块的数据是一致的，但是帐户查询余额和子模块的数据不一致，累计帐户余额的时候出现错误，原因未明。

whb

谢谢各位的热心回复，大家说的都有道理。首先我提出此问题的初衷确实是因为客户操作不规范，应该进AP/AR的业务直接在GL中做了，正如sunofbeach所说，

quote:
--------------------------------------------------------------------------------
最初由 sunofbeach 发布
总帐是各子模块财务信息的汇总，因此只要子模块都传送到总帐，那么没有不相符的道理（BUG除外，我确实碰到过帐户查询余额和子模块数据不相符的情况），因此我们要关心的是各子模块数据是否都传送到总帐，而子模块如应付根据供应商来区分应付是有道理的，应付要关心的是对某个供应商有多少应付款，什么时候要付，关键是要改变客户的传统观念。
--------------------------------------------------------------------------------

不过即使如此也有个转变的时间，检验子模块帐户余额与总帐相应帐户余额是否相符还是很有必要的，这样客户能够及时发现问题。 另外yegiant说的情况也有可能发生，这也是需要双方对帐的一个原因。
至于sunofbeach说的 “但是帐户查询余额和子模块的数据不一致，累计帐户余额的时候出现错误”，可能是汇总模板的问题。

sunofbeach

我估计是过帐过程控制出错，回滚段没有做好！

zppp

AP中的应付帐试算表就是主要用来与GL核对余额的，要是对不上那就出问题了，这样如何过审计关

tomtang

对于子模块与总帐模块的余额核对，我觉得可以利用子模块的系统报表与总帐模块的科目余额进行核对，不知各位有没有用过，像应收模块有帐户状态报表，应付模块有供应商余额重估报表等，它们都是有汇总余额的，直接与总帐模块相对应的科目进行核对。如果在应收、应付设置了其他应收款、其他应付款等科目，那么只能通过开发或者手工将余额分开了。

woodsays

-------------
最初由 sunofbeach 发布
总帐是各子模块财务信息的汇总，因此只要子模块都传送到总帐，那么没有不相符的道理
-----------
我們的做法是在總帳中有開發相關明細分類帳報表，及在AP中有相關余額報表。看來真的只有開發報表了？

ABCIIACE

似乎是题外话：为什么ORACLE APPLICATIONS允许子模块帐与GL不相符的情况存在。据我所知安永的业务范围有ORACLE APPLICATIONS实施顾问的内容，是否他们的审计也有这部分内容？楼主提的问题值得重视。

Motton

总帐和子模块不平，原因很多
我的经验大概有以下几种：

1、子模块存在未过到总帐的凭证
2、总帐接口表存在子模块传送过来的凭证，没有导入
3、总帐来源是子模块的凭证还没有过帐
4、会计手工在总帐中做了应该在子模块做的业务
5、子模块系统设置存在问题，比如库存某一个帐户别名的科目设成了库存成本科目
6、业务录入时，碰到科目的地方输入错误，比如发票的分配科目做成了负债科目
7、子模块传到总帐的凭证在接口表中被人为的删除了

其中：
1、2、3比较好查，只要把业务做完即可；
4也比较好查，只要在科目查询界面看看是否存在来源是手工的凭证
5、6需要在子模块通过打印会计分录报表来看，不过最好能sql查
7这种错误最不应该犯，如果真的犯了，要充分利用gl_import_references这张表，把当时被删掉的记录补回来

yegiant

我现在遇到一个问题：开发AR的帐户余额报表取数表到底是
AR_AEL_GL_REV_V 还是AR_AEL_SL_REV_V呢？我觉得AR_AEL_SL_REV_V与查看会计分录是一致的，但是如果需要检查与总帐是否一致，好像用AR_AEL_GL_REV_V更好一些
已经开发报表的能否写个SQL给我啊

蝶恋花

你们用oracle系统还在并行吗？每个月做核对吗？相信并行一年核对一年你就不会认为总帐模块和应收应付模块模块数据不一致了。