ORACLE ERP consolidation流程(一)

標籤：自動   沒有   ril   batch   nal   key   select   構建   四種   

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

 

ORACLE EBS by transaction consolidation的詳細流程（一）[@[email protected]]

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.

ORACLE ERP consolidation流程(一)