ORACLE ERP Consolidation Process (i)

Original address: ORACLE ERP consolidation process (i) Wolfyuan

Detailed process of ORACLE EBS by transaction Consolidation (i) [@[email protected]

1. Users do consolidation can choose two methods of consolidation, by transaction or by balance.

Depends on the choice of method when the user constructs consolidation mapping.

By transaction refers to journal batch as the unit, the corresponding batch inside the journal line in accordance with the mapping principle consolidation. When the user is transaction run consolidation, you can choose Journal batch, which requires run consolidation, with four options, unconsolidated, consolidated, all, Or the user directly selects the appropriate journal batch.

By balance refers to the account as the unit, the source during the accounting period of all the accounts that meet the conditions of the line in accordance with the mapping principle consolidation. Users can select the desired account in the by Balance run consolidation, either by using the Include all option, or by selecting multiple ranges in range. Or key into more than one account (the range from to equal).

2. Regardless of which consolidation method the user chooses, the system first inserts a record into the gl_consolidation_history. This table contains consolidation_id, consolidation_run_id, and some consolidation parameters.

There is a status field in this table, which records the state of this consolidation in detail:

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

The request_id field stores the last request_id of this consolidation action, which may be consolidation transfer or journal import or posting.

GROUP_ID refers to the group_id of data entering the gl_interface.

JE_BATCH_ID stores the batch_id of Journal generated under the target sob, and only if journal import succeeds will this field have a value.

Run_posting_flag saved is this consolidation action has not done post sign.

3. After inserting the record into gl_consolidation_history, the system will perform different actions according to the choice of the user Conlolidation method.

If method is by transaction, then insert a record into gl_cons_batches for each journal batch that needs consolidation, the structure of this table is relatively simple, the main existence consolidation _id, consolidation_run_id, je_batch_id.

If the user chooses by balance, and the user chooses the account, the option is not the include all account, but the manual key into the account of range, then the system will insert a record for each range into the Gl_ Consolidation_accounts, record the from-to of each range.

4. Once the user submits consolidation request, the system will begin the posting process in accordance with the mapping principle of the selected consolidation.

If the user's method is by transaction, the system will take out all the target batch line, according to mapping principle, produce the target sob journal into Gl_interface, each source SOB journal Line generates a record of the target sob into the gl_interface. Also, the group_id of these gl_interface records are the same, indicating that a journal will eventually be generated in the target sob, and when all records have been generated, the group_id will be written back to Gl_consolidation_ The group_id field of history.

Each record of Gl_interface will have the source sob sob_id, je_batch_id, je_header_id, Je_line_num and other fields, used for drilldown.

If the user chooses the method is by balance, the system will select all the source SOB accounting period code_combination_id meet the Account_range conditions Journal_line, the target sob jounal into Gl_ Interface. Note that at this point, if the user counsolidation the Create summary journal on the map, only one record will be generated for each account of the target sob, that is, if the account Mapping there are multiple sources sob account mapping to a target sob account, the source sob all of these account lines sum up, resulting in a target sob line.

If create summary journal is not checked, a target sob record is generated for each account of the source sob. That is, the system will sum all of the account's journal line to produce a target SOB journal.

5. If the user's Consolidaiton mapping inside run journal import is checked, consolidation transfer run, will run journal Import action, the real target sob J Ournal.

Note that if run journal import is checked, the data generated by consolidation transfer request is not gl_interface, but Gl_cons_interface_ (group_id) The table,request automatically creates a table based on group_id and inserts the data produced by the consolidation into the table. If not checked, consolidation results will go straight to gl_interface.

After consolidation, the system will first insert a record into the Gl_interface_control, mark the run journal Import related information, and then submit journal import request, This request will be recorded in the Gl_interface_control and fetch interface data and generate journal.

ORACLE ERP Consolidation Process (i)