能力不足，就让牛人来看

  这个月结账，碰到了两个棘手问题：

1.库存总账明细不一致，开始仅仅以为本月做了一些错误操作而已，比如帐户别名设置成库存科目，资产仓、数量仓做子库存转移类似问题，检查了半天，一点问题都没有，然后想起来检查细1月的库存对帐，发现1月也有问题，再和总账MM一起往前推，我当时有点预感估计上线期初可能都有问题，果然，当时还没查出是什么操作，想破脑袋都没想明白是什么操作导致了这个问题，想想库存周期都关了，还能有问题？这又拖了2天，昨天财务的有点着急，非要我给个原因，只好请教集团大佬们，果然，根据提示，查了查期间关闭调节报表，发现果然有相同数目的差异，吐血。。。大佬说是应该在总账调账，又查了这个物料从上线至今的事务处理汇总值与余额不同，是不是发生额与余额不同？继续查下去

2.一条子装配件，因为急着下任务，给了一个手工的冻结成本A，然后这个物料后期做了累计，标准成本累计后为A、B、C，更新，结果出现了这种情况，手工的冻结成本仍然存在，累计成本少了一条，就是同时存在手工的A，累计的B、C，按我的理解，应该是A、B、C都是累计，手工成本被覆盖掉，不存在的，这个问题真够头疼的，也是没有头绪。

所以说，要是要多找ORACLE啊，事情压在自己身上不好啊，绞尽脑汁没个头绪，还不然扔给牛人，毕竟别人月薪顶我几个月工资，拿多少钱，干多少钱的事，再贴一份今天在metalink上的资料，关于期间关闭调节报表的，以后要多用英文系统啊，看metalink还要先切换成英文再查，太水了，翻译下吧，现在连哑巴英语的水平都快没有了

Questions on Period Close Reconciliation Report and tables used [ID 332250.1]
		修改时间 29-NOV-2008     类型 HOWTO     状态 PUBLISHED

In this Document
  Goal
  Solution
  References

---

Applies to:

Oracle Cost Management - Version: 11.5.10
Information in this document applies to any platform.
Checked for Relevance 15-JUL-2007

Goal

目标

How does the accounted value get calculated for the Period Close process?

期间关闭流程中入账值如何计算？

Additionally:
1--What is the impact on this if no period close was completed since 1999?

如果从1999年期间都没有关闭会有什么影响
2--Are the june numbers for this one org an issue the customer needs to
correct since July is correct?

这句有点疑惑，是说6月产生的错误，7月更正了，6月的错误要不要更正呢？

不敢确定
3--What are some diagnostics that can be used to determine where
transactions are not being accounted for...i.e, intransit, etc

有哪些诊断方法可以决定是否一些事务处理没有被入账，例如：在途
4--What is the impact of some orgs with summarization and some without?

有些组织做了汇总有些没有会不会有影响？

Solution

The new process will use only one table: CST_PERIOD_CLOSE_SUMMARY.

关闭周期这个流程用到这个表CST_PERIOD_CLOSE_SUMMARY

This table will be the only one used to store information for the period close process and the
reconciliation report. The information will be stored using the following columns:

这个表是唯一的用来储存期间关闭调节报表的信息，这些信息用下列列来表示：

ACCOUNTING_PERIOD_ID
ORGANZATION_ID
SUBINVENTORY_CODE
COST_GROUP_ID
INVENTORY_ITEM_ID

Each row in the table will store the following values:
ACCOUNTED_VALUE - This is the distribution value. This is calculated by adding the sum of the
current period’s distributions (this is from the MTL_TRANSACTION_ACCOUNTS table) to the
rollback_value of the previous period.
入账值-这个是分配值，这个计算是有当期的MTL_TRANSACITON_ACCOUNTS里的值加上前期的rollback_value，这个rollback_value不懂。。。

ONHAND_VALUE (This is the quantity value)
PERIOD_CLOSE_QUANTITY (This is the snapshot value)

现有值 这个是现有量表乘以成本吧

期间关闭数量 这个是快照值

In this new process the value of the ONHAND_VALUE will become the baseline for the next period.

在新的周期,onhand_value将成为基准，明天继续，太晚了

1--What is the impact on this if no period close was completed since 1999?

The period close reconciliation report was designed as a tool for matching
the accounted value to the onhand value on a period-by-period basis. The fact
that no period close was completed since 1999 should not result in any
problems for current periods, because the information for each period is
mostly calculated independently.

For each period, we must arrive at two values: accounted and onhand.

For the case of onhand value, we take the current onhand quantity out of
Inventory's information table MTL_ONHAND_QUANTITY and revert transaction
quantities in MTL_MATERIAL_TRANSACTIONS for all transactions after the end of
the period being reconciled. After multiplying with historical cost at the
end of the period, we can arrive at an ending onhand value for this period.

For the case of accounted value, we need a baseline value and delta. The
delta is obtained from rows in the MTL_TRANSACTION_ACCOUNTS distributions
table for the respective period. The baseline value is from the previous
period's ending onhand value. The reason we use onhand value instead of
accounted value, as one might expect, is for the independence of each
period's values.

The usage of this value ensures that each period begins with a "clean slate"
and it is easier to find where discrepancies result from since we don't have
to worry about mismatches in value being propagated from one period to the
next.

2--Are the june numbers for this one org an issue the customer needs to
correct since July is correct?

From the explanation above, you can see that each period's reconciliation
values are independent of the previous period reconciliation values, in the
sense that a discrepancy will not be propagated to make period comparisons
easier. This is why the July numbers can be correct even though the June
numbers are off. The June numbers will not complicate the reconciliation of
any future periods.

3--What are some diagnostics that can be used to determine where
transactions are not being accounted for...i.e, intransit, etc

Generally, it is best to begin by looking at the items with the largest
discrepancies and their transactions. For those items, you would want to look
at the onhand quantities table, the transactions table, and the transaction
accounting distributions table as mentioned above. This method is better for
periods that have fewer discrepancies (which is assumed to be the usual case)
rather than the June period, for example.

Some possible causes for discrepancies are as follows (please keep in mind
that the discrepancies, even when they do exist, are still constrained within
each period's boundaries):

 -backdated transactions across period boundaries. These can cause some
miscalculations of the cost and therefore the value of onhand quantities. For
example, a transaction could have been stamped with a more recent cost than
was available at the end of a previous period, yet it is inserted back into
that same period.

 -usually, oracle support does not fix subledger distribution tables for
accounting datafixes. Rather, oracle tends to recommend manual GL
adjustments. There could be some apparent discrepancies resulting from this
type of datafix even though the root cause has been fixed, because the fix in
these cases would have occurred downstream from our subledger tables.

 -"old data" in subledger tables (i.e. from previous versions that may have
had bugs that have been corrected by now).

 -purged transaction records

4--What is the impact of some orgs with summarization and some without?

This is okay. There will not be any cross-organizational impact based on
whether the period values are summarized or not.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10301327/viewspace-629184/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10301327/viewspace-629184/