Concurrent Processing
Before you decide which types of activities occur concurrently within General Ledger, you must understand which tables are accessed by background and reporting processes. The tables accessed by various processes can affect the processes that you run concurrently with online activity or with other background programs.
Concurrency is important in the usage of both physical and functional tables:
Physical usage.
Certain processes bar access to tables required of other processes, so those processes cannot be run concurrently. Physical usage is based on an analysis of the unit of work anticipated in the environment, along with the type of table access a background or reporting process performs. This depends on the SQL access type. Multiple processes can perform Select access against a table. Delete, Update, and Insert access can cause table or row locking (depending on the platform). In turn, this might cause a conflicting and concurrently running process to pause or take a time-out.
Functional usage.
Although a table may be physically available, it might cause problems if changes are made while a process is running. Consider the elimination set tables used by the Consolidation background process. Functionally, you do not want a user to modify the elimination set definitions online while another user runs the Consolidation process to generate elimination entries. This can result in unexpected or inaccurate results for the user running the background process. User and object security are two system tools that can provide segregation of functional access to tables online and in the background.
Most of the General Ledger batch processes are designed to enable efficient concurrent processing by using nonshared temporary tables to minimize contention on these tables. Each process has its own temporary table when multiple jobs run concurrently. For example, if two Currency Translation jobs (FSPCCURR) are running, the first job uses CURR_WRK_TBL001 and the second job uses CURR_WRK_TBL002.
For COBOL processes, the nonshared tables are maintained in table TEMP_TBL_ASGNM. General Ledger provides a set of four nonshared tables for each temporary table. The system administrator can add more nonshared temporary tables if necessary. If all temporary tables are in use—for example, one job is submitted while four other jobs run concurrently—the shared temporary table (CURR_WRK_TBL in the case of the Currency Translation process) is shared by the fifth job and by subsequent jobs submitted.
For Application Engine processes, the nonshared tables are maintained in the tools tables. The number of instances of nonshared temporary tables is specified in the Application Engine properties. For example, the number of temporary table instances for the Combo Edit process is set to 4.
The General Ledger Utility processes perform Update, Delete, and Insert functions, so you must take concurrency into account. These processes directly modify and load data into transaction and system tables. If you run these processes, you should be aware of the tables affected and you should run the processes only at appropriate times. This table lists identifies the tables used by each function of the process:
Utility |
Function |
Tables Used |
When to Run |
Locked Tables |
Commit After Loading |
---|---|---|---|---|---|
GL_EXCL_BATC |
Insert, Update, and Delete |
PS-JRNL_HEADER PS_JRNL_LN PS_OPEN_ITEM_GL |
Anytime |
Journal tables |
All data |
GL_JRNL_IMP |
Insert |
PS_JRNL_HEADER, PS_JRNL_LN, PS_JRNL_VAT, PS_OPEN_ITEM_GL, PS_JRNAL_CF_BAL_TBL |
Anytime |
Journal tables |
All data |
GL_LED_IMP |
Insert and Delete |
PS_LEDGER, PS_LEDGER_BUDG |
Alone |
Ledger tables |
All data |
GL_JRNL_COPY |
Copy |
PS_JRNL_HEADER, PS_JRNL_LN, PS_JRNL_VAT, PS_OPEN_ITEM_GL |
Anytime |
None |
|
GL_SJE |
Create standard journal entries |
PS_JRNL_HEADER PS_JRNL_LN |
Anytime |
None |
None issued |
FIN9001 |
Update |
PS record system table PS field system table Prompt tables |
Alone |
PeopleSoft Application Designer |
|
COMBO_BUILD_REQ |
Build combo data |
COMBO_DATA_TBL and selector tables (depending on the setup) |
Alone |
COMBO_DATA_TBL and selector tables (depending on the setup) |
The processes FIN9001 has a name similar to reports, but it is a processes. Because reports only perform Select access against the database, reports do not cause table or row locking, and they do not change data. Consequently, reports do not encounter concurrency issues. The FIN9001 has restrictions in that it must be run alone.
FIN9001.SQR
This utility performs updates on information in both the PeopleSoft record and field system tables. Security implementation should ordinarily be a one-time activity during system configuration. Run this utility by itself, because it modifies prompt tables and locks tables referenced by PeopleSoft Application Designer. The total start-to-finish time of this process is normally less than five minutes.
This section discusses the relationship between tables that each process uses and the effects the process can have on concurrent activity within General Ledger. This refers to running different processes concurrently.
The online process definition and request pages for each process control the actual data accessed from the following process information. These processes are all Application Engine processes: Allocations, Combination Edit, Journal Edit, Journal Post, and Summary Ledger . The processes are presented here in alphabetical order by process name.
Allocations Application Engine Process (FS_ALLC)
The Allocations process references this functional data: record and field definitions, calendar data, allocation definitions, ledger information, tree definitions, TimeSpans, and ChartField table values. SELECT SQL access is used to retrieve this data.
The result of an allocation is the updating of ledger rows, the creation of journal entries, or both. Insert and Update activity required for these outputs occurs against the JRNL_HEADER, JRNL_LN, and LEDGER tables. The unit of work for an allocation is the allocation step.
Note: General Ledger supports multiple journal and ledger tables. General Ledger table allocation enables Insert and Update functions to specified target and offset tables.
It is important to evaluate the time required to complete an allocation step. This is based on the functional requirements and the size of the basis, pool, and target for a given step. The estimated time to complete the unit of work determines the impact that allocation journal entry creation and ledger update activity has on other concurrently running processes.
You can request that a calculation log be generated when an allocation step is processed in the background. This results in Insert functions being performed against the ALLOC_CALC_LOG table. The Structured Query Report (SQR) that generates a report of the allocations calculation log, GLS6002.SQR, selects against this table. Therefore, you should not run the SQR GLS6002.SQR concurrently with the Allocations background process if the steps being processed generate a calculation log.
Alternate Account Edit Application Engine Process (GL_AA_EDIT)
The Alternate Account Edit process is an Application Engine process that updates the records you specify in the Combo Edit Template Line Record field and Line Error Log field. The Line Error Log record only is updated if you set the ERRORHANDLER flag to true. (You must pass this field with a value of Y.)
The only system table that is used for transaction set editing is PSRECFIELD. This is only accessed if the ERRORHANDLER flag is true.
Application tables used for SELECT SQL or editing are:
PS_INSTALLATION
PS_COMBO_EDIT_TMPL
PS_BUS_UNIT_TBL_GL
PS_COMBO_EDIT_LNS
PS_LED_GRP_LED_TBL
PS_LED_FLDS_TBL
PS_BU_LED_GRP_TBL
PS_ALTACCT_XREF
Average Daily Balance Calculation Process (GL_ADB_CALCX)
The Average Daily Balance process uses information from record and field definitions, average daily balance (ADB) definitions, ledger definitions, calendar data, tree definitions, and the average daily balance request record. SELECT SQL access is used to retrieve this data.
The main activity of the Average Daily Balance process is calculating average balances from the ADB ledger of the specified period. The calculation results are inserted into the ADB target ledger table. The Average Daily Balance process supports two different methods of calculating the averages: ad hoc and incremental.
With the ad hoc method, the process extracts the data from the ADB ledger to calculate the average balances. Run the Average Daily Balance process any number of times. The process deletes any previously calculated average balances of the same period before it recalculates the new average balances.
With the incremental method, the process uses the prior period averages and the data from the ADB ledger. The process extracts only the data from the ADB ledger that is necessary to calculate the average balances. This includes any transactions that are posted between the prior and current requested period. The process automatically applies adjustments to prior period averages. Run the Average Daily Balance process any number of times. The process uses an activity log table to determine the required processing. If the averages were already calculated for a given period, only the adjustments are applied. The process also used a date-time stamp on the log table to ensure that the adjustments are not applied more than once. This enables you to adjust averages as many times as needed.
The request record of the Average Daily Balance process enables you to specify multiple periods of average balances to calculate, so that the commit point is a subset of the request record. A commit is issued after each period for which average balances are calculated and adjusted.
ChartField Combination Build Process (FS_CEBD)
The ChartField Combination Build process references the following data: record and field definitions as defined on the combination template, combination rule and group definitions, tree definitions, and ChartField table values SELECT SQL access is used to retrieve this data.
The result of the ChartField Combination Build process is a refresh of the valid ChartField combinations in the PS_COMBO_DATA_TBL or the COMBO_SEL nn selector tables.
The ChartField Combination Build background process uses these tables:
ChartField Combination Table |
Usage |
---|---|
COMBO_DATA_TBL |
Stores all the valid or invalid ChartField combinations (based on definition) as maintained by the Combination Build process (FSPECBLD). SQL Selects are done against this table to determine which combinations are defined by the combination rule. |
COMBO_SEL_nn (nn is a number between 01 and 30) |
Stores the ranges of tree values used by the combination rules for reference during core processing. SQL Selects are done against these to determine which combinations are defined by the combination rule. |
ChartField Combination Editing Process (FS_CEDT_PROC)
The ChartField Combination Editing process references the same functional data, as does the ChartField Combination Build process in the previous section. Likewise, SELECT SQL access is used to retrieve this data.
To enhance the performance of the editing, you can build the COMBO_SEL_nn master selector tables before using the Combination Edit process.
Alternatively, you might decide not to build the selector tables. This causes the editing process to build them dynamically at the time of the edit.
If you prefer to edit directly against the COMBO_DATA_TBL without using the selector tables at all, you can do so by indicating this on the Combo Group definition. On the Combo Group definition, there is an Editing option for indicating whether the COMBO_DATA_TBL or the selector tables can be used. However, if you select COMBO_DATA_TBL as the editing option, the batch editing does not dynamically build the COMBO_DATA_TBL. In this case, you must run the Combination Build process to create the combinations before the edit.
The background processing performs several updates to the accounting line tables defined in the Combination Template definition. Set processing logic is used to determine the validity of the ChartField combinations. The result of ChartField combination editing is the updating of accounting lines with the status Invalid if ChartField combination errors are found.
Closing Process (GLPCLOSE or GL_YC)
The Closing process uses information defined for record and field definitions, account types, account attributes, calendars, ChartField value sets, ledger definitions, and closing rule definitions. It also uses ledger and journals data to perform the closing. SELECT SQL access is used to retrieve this data.
The primary activity of the Closing process is to create closing ledger entries and journal entries for year-end close, or closing journal entries for interim close. (Creation of journal entries to maintain an audit trail is optional for year-end close (COBOL) However, interim close and year-end close (Application Engine) always create journals.) The Closing process uses Insert, Update, and Delete activity against several temporary tables in addition to LEDGER, JRNL_HEADER, and JRNL_LN tables. The unit of work for the Closing process is the same as the request itself—the closing of the ledger specified on the request. The closing process locks activity on the LEDGER table on accounting period 999 and 0, as well as JRNL_HEADER and JRNL_LN if journals are to be created. Consider this when planning activities that might be run concurrently with closing. In the event that processing is interrupted, periodic commits occur for a large volume of rows.
Additionally, if the close to multiple retained earnings option is activated, processing time depends heavily on the ChartField value set definitions. Generally, the fewer ChartFields processed, the more efficient the processing. On the other hand, it takes less time if there are fewer ChartField combinations among the ChartField value sets included in the closing rule definition.
Note: When processing interim close, the journals for the specified period are locked. You should not run other activities that require access to these journals. Interim close is only available as a COBOL process.
Commitment Control Budget Closing Process (FSPYCLOS)
The LEDGER_KK table, which holds the Commitment Control budget balances, is selected and updated during the Budget Closing process. Calculation log entries in tables KK_CLOSE_CALC_S, KK_CLOSE_CALC_T, and KK_CLOSE_OFFSET are created to provide the supporting information on how the remaining balances are updated and rolled forward to a new budget period. One or more rows are created for the process log table KK_CLOSE_PR_LOG, which can be reviewed online and undoes the Budget Close process. KK_BD_ATTRB_MST, KK_BD_ATTRIB, and KK_BD_ATTRIB_BP are updated for the budget status. Insert and Update functions are performed against this table within the unit of work interval. KK_CLOSE_STATUS is maintained by both the Budget Closing process and the Run Control Validation process (GLS1211) to track the closing status of Budget Ledgers by Budget Period, and it can be reported or reviewed online.
The Budget Closing process creates Commitment Control journals in KK_BUDGET_HDR and KK_BUDGET_LN tables, and it calls the Budget Journal Posting process (FS_BP) to update the LEDGER_KK table.
Commitment Control Budget Process (FS_BP)
Background budget processing updates the Commitment Control ledger, activity, source transaction, liquidation, log and exception tables, as well as various application header and line tables as defined in the Commitment Control Source Transaction Definition component. It also accesses various Commitment Control definition tables and PeopleSoft record definition tables.
The Commitment Control Budget process also updates these Commitment Control tables:
PS_KK_SOURCE_HDR
PS_KK_SOURCE_LN
PS_KK_ACTIVITY_LOG
PS_LEDGER_KK
PS_LIQUIDATION
PS_KK_REFERENCED
PS_KK_TRANS_LOG
PS_KK_EXCPTN_TBL
PS_KK_CHECK_REQ
PS_KK_CHECK_REQ2
The process accesses these Commitment Control tables:
PS_KK_BUDGET_TYPE
PS_KK_SUB_TYPE
PS_KK_KEY_CF
PS_KK_CF_VALUE
PS_KK_EX_ACCT_TYPE
PS_KK_EX_ACCT_VAL
PS_KK_BD_DFLT_ACCT
PS_KK_BD_OFFSET
PS_KK_TRX_OFFSET
PS_KK_BD_ATTRIB
PS_KK_BD_ATTRIB_BP
PS_KK_REV_XREF
PS_KK_EX_XREF
PS_KK_FS_VALUE
PS_KK_SOURCE_TRAN
PS_KK_TRAN_SELECT
PS_KK_STATUS_FLDS
PS_KK_REFREC_KEYS
The process accesses these application definitional tables:
PS_BU_LED_GRP_TBL
PS_BUL_CNTL_BUD
PS_LED_GRP_TBL
PS_LED_FLDS_TBL
PS_CAL_DETP_TBL
PS_CAL_BP_TBL
PS_GL_ACCOUNT_TBL
The process accesses these PeopleTools definitional tables:
PSDBFIELD
PSRECFIELD
Depending on the product calling Budget Processor, the Commitment Control budget process accesses certain application records and updates their status flags. The source tables are defined in the source transaction page under menu Commitment Control, Define Control Budgets.
Consolidations Process (GLPOCONS)
The Consolidations process uses this functional information: tree definitions, calendar data, elimination sets, minority interest sets, ledger information, and ChartField table values. SELECT SQL access is used to retrieve this data.
The primary Insert, Update, and Delete activity against multiple use tables occurs when generating elimination entries for consolidations. Inserting rows into the JRNL_HEADER and JRNL_LN tables creates journal entries. The Journal Edit (GL_JEDIT) process and the Journal Post (GL_JP) process are called to edit and post the journals. Please refer to those sections for details on tables that are accessed.
The request record for the Consolidations process enables you to review elimination results by running the process in Log mode. In this mode, the Consolidations process performs all the calculations necessary to generate consolidated results and stores that information in the CONSOL_LOG table. Run the Consolidations process any number of times until you have resolved all discrepancies. Once you obtain the desired results, run the process a final time to actually generate the elimination journal entries. Potential locking problems are not applicable while in Log mode. One row is inserted into the process log table, CONSOL_PROC_LOG, which can be reviewed online. You use it to undo the Consolidation process.
The Consolidation process also maintains the process status in CONSOL_ND_STAT. The status appears on the Consolidation Process Monitor page.
Equitization Process (GLPQEQTZ)
The Equitization process is similar to the Consolidation process with regard to tables that are used or affected.
The primary Insert, Update, and Delete activity against multiple-use tables occurs when generating equitization entries. Inserting rows into the JRNL_HEADER and JRNL_LN tables creates journal entries. The Journal Edit (GL_JEDIT) process and the Journal Post (GL_JP) process are called to edit and post the journals. Refer to those sections for details on tables that are accessed.
These activities occur within the Equitization process unit of work interval, which is the same as the request. It is important to evaluate the size of equitization source and the expected number of journal entries to be created to estimate the unit of work interval. If the interval is short, there should be little impact on other parts of the system that enable journal entry creation or ledger updating. If the interval of the unit of work is long, then you should avoid other journal entry creation and ledger updating activity when creating equitization journal entries.
The request record for equitization enables you to review equitization results by creating the calculation log and store that information in the EQTZ_CALC_LOG table. Unlike the Consolidation process, the Equitization process does not have a Calculation Log Only mode. The calculation log is a side-product for each successful equitization run.
One entry to EQTZ_PROC_LOG is also created to retain the request information for the Undo process. The Undo option in the equitization request causes the process to delete the entry from last process request.
Flat File Journal Import Process (GL_JRNL_IMP)
This import process interfaces with third-party systems that produce flat files containing journal entries.
This process inserts rows into the journal tables from data in a flat file. A commit is used after all data in the file is loaded. You can separate journal data into smaller flat files and run several instances of this process concurrently.
Flat File Ledger Import Process (GL_LED_IMP)
This import process interfaces with third-party systems that produce flat files containing ledger entries.
This process inserts rows into the PS_LEDGER and PS_LEDGER_BUDG tables from data in a flat file. A commit is issued after all the data in the file is loaded.
You should run this process by itself because it locks ledger tables while it is running.
HRMS Account Code Interface Process (HR_ACCT_CD)
This process reads information and sends it out as a message to another user ID. When the HRMS Account Code Interface (Human Resources Management account code interface) process (HR_ACCT_CD) runs, no contention for system tables occurs.
This process runs the Build Combination Data process and then the HRMS/SA extract Application Engine process. The latter extracts data out of the combo data table and sends it to the Human Resources subsystem by using PeopleSoft Application Messaging. Because this process also runs the Build Combination Data process, do not run HR_ACCT_CD concurrently with any other background process that use the combination data table, the selector tables or the exploded combination table.
Journal Copy Application Engine Process (GL_JRNL_COPY)
This Application Engine process copies journal line information to a new journal. It inserts new rows into PS_JRNL_HEADER and PS_JRNL_LN. There is minimal risk of concurrency issues with this process.
Journal Edit Process (GL_JEDIT)
Background journal editing updates the journal header, journal line, journal value-added tax (VAT), InterUnit and IntraUnit journal anchor, journal totals, TSE journal header log, and TSE journal line log tables. It also accesses various tools (PeopleSoft Application Designer for record definition), system definition tables, ChartField tables, and ChartField combination data and rules tables.
The system tables used for transaction set editing are PSDBFIELD, PSRECDEFN, and PSRECFIELD.
Other tables used to edit individual journals are:
PS_BUS_UNIT_TBL_GL
PS_BU_LED_TBL
PS_BU_LED_GRP_TBL
PS_CAL_DEFN_TBL
PS_CAL_DETP_TBL
PS_RT_TYPE_TBL
PS_LED_DEFN_TBL
PS_OPEN_ITEM_GL
PS_GL_POS_ACT_DEF
PS_GL_POS_ACT_CFS
PS_GL_POS_ACT_DETL
PS_SET_CNTROL_REC
PS_SET_CNTROL_TBL
PS_SET_CNTROL_TREE
PS_SOURCE_TBL
XLATTABLE
Various ChartField tables
Various VAT definition tables
These tables are updated during background journal edits:
PS_JRNL_EDIT_REQ
PS_JRNL_EDIT_LOG
PS_JRNL_HEADER
PS_JRNL_LN
PS_JRNL_CF_BAL_TBL
PS_TSE_JHDR_FLD
PS_TSE_JLNE_FLD
PS_JRNL_VAT
PS_JRNL_IU_ANCHOR
The Journal Edit process uses application locking instead of database locking to lock the journals being edited. When the Journal Edit process starts, it updates the journal header's JOURNAL_LOCKED field to Y to set the application locking. While the journals are locked, they cannot be used by other online or batch activities. After each journal is edited, its JOURNAL_LOCKED field is reset to blank and a commit is issued. Consequently, the journal is unlocked. The request record for journal edit processing enables you to specify a range of journals to edit, so that the commit point is a subset of the request level.
It is important to evaluate the size of the background run of the Journal Edit process for a specific request. The size determines whether or not concurrent activity is successful against the journal tables. Performance timings of the Journal Edit process indicate that a medium volume of journals should be an acceptable level for concurrent activity. Avoid large volumes when other journal processing activity needs to occur.
Volume estimates also depend on the database platform used. You can narrow the request level criteria to lower the volume of journals processed in a unit of work. Process large journals as separate requests.
Journal Generator Process (FS_JGEN)
The Journal Generator process uses information from record and field definitions, accounting entry definitions, journal generator template, General Ledger business unit, ledger definitions, calendar data, journal sources, tree definitions, and the journal generator request record. SELECT SQL access is used to retrieve this data.
The main activity of the Journal Generator process is creating journal entries from accounting entries. Journal entries are created in two steps. The first step inserts rows into the JGEN_WRK_TBLnnn work table from accounting entries. The second step inserts rows into the JRNL_HEADER and JRNL_LN tables by selecting from the JGEN_WRK_TBL nnn work table. The accounting entries are then updated with the journal information. A commit is issued after each journal is created.
Journal Post Process (GL_JP)
The Journal Post process references data from the record and field definitions, ledger definitions, and the journal request record. SELECT SQL access is used to retrieve this data.
Posting has the following functions:
To update or insert rows into the LEDGER table to which you are posting.
Rows in JRNL_HEADER are updated after they are successfully posted.
To create journal entries for the unpost, reversal creation, and when using ledger code for Multi-Gapp posting that may create adjustment journals for the different ledger codes.
This consists of Update, Insert, and Delete activity against the JRNL_HEADER, JRNL_LN and JRNL_VAT tables. The posting unit of work is the same as the request. If open item journals are involved, table OPEN_ITEM_GL is updated.
If Commitment Control is being used, posting calls the Commitment Control process (FS_BP) after creating journals.
If Average Daily Balance (ADB) setup is enabled, the Journal Post program also posts to the ADB ledgers.
Based on the request options or the configuration of the ledgers, additional tables may be updated during the posting process. OPEN_ITEM_GL is updated if the Open Item Reconciliation process is selected. SLEDGER_STG is updated if incremental summary ledger is enabled.
Success or failure of concurrent activity depends on whether the two processes attempt to update or insert the same ledger rows. The Posting process can run concurrently if the data sets are mutually exclusive (by business unit, ledger, year, period, or ChartField values).
Avoid large volumes when other journal and ledger process activity needs to take place.
Volume estimates also depend on the database platform used. You can narrow the request level criteria to lower the volume of journals processed in a unit of work. Process large journals as separate requests.
Ledger Load Process (GL_LED_LOAD)
The Ledger Load process updates the ledger table, a staging table for ledger load and the ledger load log tables. It also accesses various system definition tables and ChartField mapping tables.
The system table PSRECFIELD is used for checking whether the database is set up for separate debits and credits.
Other tables used to edit individual journal are:
PS_BUS_UNIT_TBL_GL
PS_CAL_DETP_TBL
PS_CF_MAPPING_SET
PS_CF_VALUE_MAP
PS_CFV_MAP_BU_SET
PS_CF_TARGET_TBL
PS_CF_SOURCE_TBL
PS_CF_MAPPING_CF
PS_LED_TMPLT_TBL
PS_BU_LED_GRP_TBL
PS_LED_GRP_LED_TBL
The Ledger Load process updates the ledger table. Evaluate the size of the run for a specific request. Because the process locks the rows in the ledger table for the specific run, avoid large volumes when other ledger activities need to occur.
Multicurrency Processing Process (FSPCCURR or FS_MC)
The Multicurrency Processing process references the following functional data: record and field definitions, account attributes, calendar data, translation and revaluation definitions, ledger information, tree definitions, TimeSpans, and ChartField table values. SELECT SQL access is used to retrieve this data.
The result of multicurrency processing is the updating of ledger rows and the creation of journal entries. Insert and Update activity required for these outputs occurs against the JRNL_HEADER JRNL_LN tables. The unit of work for multicurrency processing is a revaluation or translation step. Note that General Ledger also supports multiple journal and ledger tables for various ledger templates. The temporary table names are different across ledger templates.
Evaluate the time required to complete a multicurrency step. This is based on the functional requirements and the number of ChartFields that are restated as defined in the revaluation step or translation rules in a step. The estimated time to complete the unit of work determines the impact that journal entry creation and ledger update activity has on other concurrently running processes.
Open Item Reconciliation Process (GL_OI_RECON)
The only table that Open Item Reconciliation updates is the OPEN_ITEM_GL table. The unit of work is the same as the request. Work table GL_OI_TMP nnn is used for the Open Item Reconciliation process. Insert and Update functions are performed against this table within the unit of work interval.
Summary Ledger Application Engine Process (GL_SUML)
The Summary Ledger process uses information from tree definitions, calendar data, and ledger definitions for both summary and detail ledgers. SELECT SQL access is used to retrieve this data.
Multiple INSERTS, UPDATES, and DELETES are performed on the summary ledger tables, S_LEDGER_xxxxxx, and on the status table, SUMLED_STATUS. The incremental summary ledger update also updates and deletes rows from the staging table, SLEDGER_STG.
The main activity of the Summary Ledger process is inserting data into the summary ledger defined on the request. The Insert is accomplished with one SQL statement, comprising one unit of work. A commit is issued after each summary ledger is created. The request record for summary ledger processing enables you to specify a range of summary ledgers to create, so that the commit point is a subset of the request level. No concurrency problems have been identified within the Summary Ledger process.
Warning! The incremental Summary Ledger process should not be run concurrently for any single business unit and summary ledger combination. If multiple posting instances run concurrently and call the Summary Ledger process (for the same ledger and business unit combination), bad results or collisions can occur.
Spreadsheet Journal Batch Import Process (GL_EXCL_BATC)
This process inserts rows into the journal tables from data contained in a flat file that you create using the General Ledger Spreadsheet Journal Import utility. A commit is used after all data in the file has been loaded.
You can separate the journal data into smaller flat files and run several instances of this process concurrently.
Standard Journal Entry Application Engine Process (GL_SJE)
This Application Engine process creates standard journal entries. There should not be any concurrency issues with this process.