ORACLE ERP consolidation流程(一)

原文地址：ORACLE ERP consolidation流程(一) 作者：wolfyuan

ORACLE EBS by transaction consolidation的详细流程（一）[@more@]

1.       用户做 consolidation可以选择两种consolidation的方法,by transaction或者by balance.

取决于用户构建consolidation mapping时候method的选择.

By transaction指的是以journal batch为单位, 将相应batch里面的journal line按照mapping原则进行consolidation. 用户在by transaction run consolidation的时候, 可以选择需要run consolidation的journal batch, 有四种选择, unconsolidated, consolidated, all, 或者用户直接选中相应的journal batch.

而by balance指的是以account为单位, 将源会计期间以内所有的符合account条件的line按照mapping原则进行consolidation. 用户在by balance run consolidation的时候, 可以选择需要的account, 可以用include all选所有的account, 也可以以range方式选入多个范围的account, 或者key入多个account(from to相等的range).

2.       无论用户选择哪种 consolidation方法,系统会首先插入一条记录进入GL_CONSOLIDATION_HISTORY. 这个table里面存有consolidation_id, consolidation_run_id, 以及一些consolidation的参数.

这个表中有一个status的栏位, 会详细记录这个consolidation的状态:

STATUS CONSOLIDATION_STATUS GL_LOOKUPS

DD Journal Deleted

ID Imported

IF Import Failed

IG Importing

ND No Data Transferred

NI No Data Imported

NT Not Transferred

PD Posted

PF Posting Failed

PG Posting

PS Selected for Posting

RV Reversed

TD Transferred

TF Transfer Failed

TG Transferring

TS Selected for Transfer

Request_id栏位存储的是这次consolidation动作的最后一个request_id, 有可能是consolidation transfer的, 也有可能是journal import或者posting的.

Group_id指的是数据进入gl_interface的group_id.

Je_batch_id存储的是目标sob下产生的journal的batch_id, 只有journal import成功以后这个栏位才会有值.

Run_posting_flag存的是这次consolidation动作有没有做post的标志.

3.       插入记录进 GL_CONSOLIDATION_HISTORY以后, 系统会根据用户conlolidation方法的选择,而进行不同的操作.

如果method是by transaction, 那么会为每一条需要consolidation的journal batch插入一条记录进入gl_cons_batches, 这张表的结构比较简单,主要存有consolidation_id, consolidation_run_id, je_batch_id.

如果用户选择的是by balance, 并且用户在选择account的时候,选择的不是include all account, 而是手动key入了range的account, 那么系统会为每一条range插入一条记录进入gl_consolidation_accounts, 记录每一条range的from to.

4.       用户一旦提交 consolidation的request, 系统就会按照所选consolidation的mapping原则,开始过帐过程.

如果用户的method是by transaction, 系统会取出所有目标batch中的line,按照mapping原则,产生目标SOB的journal进入gl_interface, 每一条源SOB的journal line产生一条目标SOB的记录进入gl_interface. 并且,这些gl_interface记录的group_id,都是一样的,表示最后会在目标SOB产生一条journal, 当所有记录产生完毕以后, 这个group_id会被回写到GL_CONSOLIDATION_HISTORY的group_id栏位.

Gl_interface的每条记录都会存有源SOB的sob_id, je_batch_id, je_header_id, je_line_num等栏位, 用以drilldown所用.

如果用户选的method是by balance, 系统会选出所有源SOB会计期间内code_combination_id符合account_range条件的journal_line, 产生目标SOB的jounal进入gl_interface. 注意,此时,若用户counsolidation map上面的的create summary journal勾选的话, 对于目标SOB的每个account只会产生一条记录, 也就是说, 如果account mapping时候存在多个源SOB ACCOUNT mapping到一个目标SOB account, 那么会将源SOB下所有这些account的line sum起来,产生一条目标SOB的journal line.

如果create summary journal没有勾选的话, 对于源SOB的每个account会产生一条目标SOB的记录. 也就是说, 系统会sum所有该account的journal line产生一条目标SOB的journal.

5.       如果用户的 consolidaiton mapping里面run journal import有勾选的话, consolidation transfer跑完以后, 会跑journal import的动作,真正产生目标SOB的journal.

注意，如果run journal import有勾选，consolidation transfer的request产生的数据进入的不是GL_INTERFACE, 而是gl_cons_interface_(group_id)的table，request会自动根据group_id创建table，并将consolidation产生的数据insert入这个table。如果没有勾选的话，consolidation结果会直接进入gl_interface。

Consolidation完毕之后，系统首先会插一笔记录进入gl_interface_control, 标志出这次run journal import的相关信息, 然后提交journal import的request, 这个request会到gl_interface_control中取记录,并取interface数据并产生journal.