ORACEL R12 总账和子账的关系

阅读更多

子模块和GL之间关联的变化
    12i在功能模块上的变化很多，比如，基本每个模块都启用了MOAC特性，新增加了子帐模块，税模块等等很多新的模块，OPM库存和离散库存集成了。不过这些变化中，大部分不是我们需要重点关注的，不过有一个东西需要重点关注那就是子帐模块。子帐模块功能非常强大，现在所有的子模块会计分录都可以使用特定的公式配置出来。但是对技术而言，我们不太关心如何配置生成会计分录，我们只关心子模块的会计分录和GL的会计分路之间的关联性，以方便我们做子模块和GL的对应报表。然而，现在如果你要做对应报表，你就必须要了解子帐。因此，在这里重点只介绍子帐。
    子帐的概念——SLA（Subledger Accounting）
    概念
    子帐是子分类帐会计的简称，字面上的含义就是子分类帐会计分录，但是这东西到底用来干吗的呢？！
    通俗的说：
    1、子分类帐会计其实就是连接子模块会计和GL凭证之间的桥梁，更简单的说，就是子模块和GL之间的桥梁。所有子模块（包括FA）产生的会计分录都是使用SLA产生的，存放在SLA的表中，然后通过过帐程序过帐到GL。有点类gl_interface表的功能。
    2、子分类帐会计的第二层意思：在各个子模块都有一套独立的会计分录，看起来跟GL其实没太大区别，这就意味着在子模块其实就可以计算科目余额了。只是可惜，到目前为止我还没有类似gl_balance的表来存放科目余额。
    3、各子模块目前还是可以有自己的分配帐户（就是以前查看会计科目看到的东西），分别存放在自己的分配表中，比如，AP还是存放在ap_invoices_distributions中，引入SLA后，把这个功能称为“事物处理会计”，和子分类帐会计的不同点在于，事物处理会计是通过自动会计或分配产生，而子分类帐会计是根据定义会计事件等公式产生的，分别存于不同的地方。
    子帐架构
    解释：
    1、 子分类帐的产生有两种方式，一种方式是直接从子模块的事物处理会计，一种是直接从子模块的事物处理上取得。
    2、 子模块的事物处理会计和子分类帐会计是两个不同的东西，一定要区别对待，传送到GL的是子分类帐会计，并非事物处理会计。
    3、 由于子分类帐会计的来源可能是事物处理，也可能是事物处理会计，因此很可能存在差异，这是SLA目前的缺陷。
    子分类帐带来的益处
    1、 灵活的定义会计分录的产生规则，包括摘要，借方和贷方
    2、 一个事物处理可以过帐到多个ledger（就是11i的帐簿），这给跨国集团管理多个帐簿带来很大的好处
    3、 统一了子模块会计分录的存放和产生规则，也就是说，各个子模块都可以根据自身的情况设置会计规则，但是这些规则产生的会计分录都回存放在SLA的表中。
    4、 利于扩展，ORACLE委托外包的子模块产生的会计分录更容易集成到EBS
    SLA的几个重要关键词
    SLA的关键词有很多，不过和我们写程序密切相关的应该是下面几个关键词。这几个关键词是我们弄清楚子模块和GL之间的关键。如果理解了这几关键词在SLA中的具体位置以及作用，加上SLA的的架构图，很容易的就理解了SLA作为子模块和GL的桥梁作用，对过帐程序具有深刻的理解，便于我们以后编写追溯程序以及追溯报表。
    会计事件（account event）
    会计事件，就是一个事物处理的不同事件类型产生的记录，它结合了主要分类帐，事件类型，事件分类。一个事物处理可能会有多个会计时间，因为一个事物处理可能发生多种动作，而每个动作都需要产生相应的会计凭证。因此，我们可以把一个会计事件看成是一张完整的凭证，我们把这张凭证录入到子模块的会计分录表里就形成了完整的会计分录。所以，我对会计事件的理解通俗归纳为以下几点：
    1、 会计事件就相当于一张凭证，录入到GL就是一对会计分录
    2、 同一个事物处理，比如收款可能会对应多个会计事件，因为收款创建会产生会计事件，收款核销也是一个会计事件。
    查看路径：子模块超级用户/查询/会计事件
    主要分类帐（leadger）
    分类帐的概念在12i中表示的是帐簿，也就是11i的SOB，主要分类帐决定了过帐到哪个SOB
    事件实体（EVENT ENTITY）
    事件实体决定了会计分录来源，以应收为例子，事件实体决定了到底是从 “应收事物处理”过来的还是从“收款”过来的。存放在表：xla_entity_types_vl中，会计分录和事物处理关联的表是是xla_transaction_entities ,事件实体同时定义了关联的标识是哪个字段，存放在xla_entity_id_mappings，下面我会详细介绍怎么做关联。
    设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型
    事件分类（EVENT CLASS）
    事件分类是根据事件实体进一步区分会计分录的方法。比如，收款分为“收款”和“杂项收款”，事件分类的表为：xla_event_classes_v，属于xla_transaction_entities的子表。
    设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型
    事件类型（EVENT TYPE）
    事件类型是比事件分类更小的事件划分方法，每个事件分类会细分成多个事件类型。比如：收款会分成：收款已核销，收款未核销，收款已更新等等类型。存放在表：xla_event_types_vl 中。
    设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型
    SLA&GL关系模型
    关联模型中，实际参与的表很多，我们只拿最重要的表来描述，以便大家入门，不至于摸不着头脑，力求简单。
    基础事件关系图
    xla_entity_types_vl（事件实体）
    ｜――xla_entity_id_mappings（实体ID对应表）
    ｜――xla_event_classes_v（事件分类）
    ｜――xla_event_types_vl（事件类型）
    子分类帐关系图
    xla_transaction_entities（会计事物处理实体）
    ｜――xla_events（会计事件）
    ｜――xla_ae_headers（子帐头）
    ｜――xla_ae_lines（子帐行）
    ｜――xla_distribution_links（关联事物处理信息）
    子模块和ＧＬ关系图
    gl_import_references（总帐参考）
    ｜（gl_sl_link_id,gl_sl_link_table）
    xla_ae_lines（子帐行）
    说明：GL和子模块之间的关联是通过gl_import_reference实现的，关键字段是gl_sl_link_id,gl_sl_link_table。
    GL->子模块追溯

    伪代码
    begin

    --根据GL信息找到相关的ae_header_id,ae_line_num,je_source
    --特别注意，这里可能存在一对多关系
    --一对多在业务上表现为汇总过帐
    select xal.ae_header_id,xal.ae_line_num,jh.je_source
    from gl_je_lines jl,
    gl_je_headers jh,
    gl_import_references gir,
    xla_ae_lines xal
    where jl.je_header_id=gir.je_header_id
    and jh.je_header_id=jl.je_header_id
    and jl.je_line_num=gir.je_line_num
    and gir.gl_sl_link_id=xal.gl_sl_link_id
    and gir.gl_sl_link_table=xal.gl_sl_link_table
    and jl.je_header_id=:1
    and jl.je_line_num=:2
    --根据je_header_id找到相应的会计实体，主要是需要实体代码和几个source_id
    --通过source_id…和entity_code的组合判断，可以准确的追溯到具体的事物处理
    select xte.entity_code
    ,xte.source_id_int_1
    ,……
    ,xte.source_id_char_1
    ,……
    ,xte.security_id_int_1
    ,xte.security_id_int_2
    ……
    from xla.xla_transaction_entities xte,
    xla_ae_headers xah
    where xah.ae_header_id=:1
    and xte.entity_id=xah.entity_id
    and xte.application_id=xah.application_id
    --根据日记帐来源查询xla_subledgers表获得drilldown的程序
    --由于这部分是写死的，因此，对程序员来说，只能做参考
    --至于怎么写的灵活和通用，还需要参考琢磨写成一个通用的动态SQL
    select xs.drilldown_procedure_name
    from xla.xla_subledgers xs
    where xs.je_source_name=:je_source_name
    and xs.application_id=:application_id
    --上面的信息查询出来后，组合成一个动态SQL，返回一个准确的结果集
    --当然，通常情况下，我们都没有考虑写成通用程序，因此可以写死是
    --哪些会计事件，会计实体代码
    END;
    一个简单的列子（收款和总帐凭证对应报表，简单写死事件实体）
    SELECT CR.CASH_RECEIPT_ID    CASH_RECEIPT_ID,
    CR.DOCUMENT_NUMBER    GATHER_NUM,
    JH.DOC_SEQUENCE_VALUE DOC_SEQUENCE_VALUE,
    CR.CUSTOMER_NAME      CUSTOMER_NAME,
    CR.REMIT_BANK_BRANCH BANK_NAME,
    CR.REMIT_BANK_ACCOUNT BANK_ACCOUNT,
    CR.RECEIPT_NUMBER     RECEIPT_NUMBER,
    CR.AMOUNT             AMOUNT,
    CR.STATE_DSP          STATE_DSP,
    H.EVENT_TYPE_CODE     EVENT_TYPE_CODE
    FROM XLA_AE_LINES                 L,
    XLA_AE_HEADERS               H,
    XLA.XLA_TRANSACTION_ENTITIES TE,
    GL_IMPORT_REFERENCES         IR,
    GL_JE_HEADERS                JH,
    AR_CASH_RECEIPTS_V           CR
    WHERE CR.CASH_RECEIPT_ID = TE.SOURCE_ID_INT_1（+）
    AND CR.CURRENCY_CODE = P_CURRENCY
    AND TE.ENTITY_CODE（+） = 'RECEIPTS'
    AND TE.ENTITY_ID = H.ENTITY_ID（+）
    AND TE.APPLICATION_ID = H.APPLICATION_ID（+）
    AND H.AE_HEADER_ID = L.AE_HEADER_ID（+）
    AND H.APPLICATION_ID = L.APPLICATION_ID（+）
    AND L.GL_SL_LINK_TABLE = IR.GL_SL_LINK_TABLE（+）
    AND L.GL_SL_LINK_ID = IR.GL_SL_LINK_ID（+）
    AND IR.JE_HEADER_ID = JH.JE_HEADER_ID（+）
    AND L.AE_LINE_NUM（+） = 1
    AND H.ACCOUNTING_ENTRY_STATUS_CODE（+） = 'F'
    AND H.ACCOUNTING_DATE BETWEEN TRUNC（P_START_DATE） AND （TRUNC（P_END_DATE） + 86399 / 86400）
    SLA总结
    通过上面的介绍，我们现在应该至少了解到了如下知识点：
    １、SLA的简单架构，在12i中SLA扮演什么角色？
    2、SLA的几个关键词，并且知道如何从界面上找到他们？
    3、 SLA几个表的关系模型，以及和GL的关系模型？怎样从子模块找到GL的凭证，怎样从GL追溯到子模块？
    由于SLA非常复杂，因此在这里这点篇幅不能全部介绍完，我只是站在技术的角度来看SLA，看我们到底要做些什么变化。