Understanding General Ledger Background Processes

This chapter discusses:

• The background process model.

• Initiation of processes from application pages.

• Restart and recovery of processes.

• Concurrent processing.

The Background Process Model

Many functions in Oracle's PeopleSoft Enterprise General Ledger, such as journal editing and posting, allocations processing, financial consolidations, year-end closing, and creation of summary ledgers are run as background processes using a process request page. A common processing model is incorporated into all PeopleSoft background processes to initiate processes, monitor their progress, and track their history. In addition, through commits, this model frees shared resources as quickly as possible to facilitate concurrent activity.

The model includes the following elements:

• Unit of work.

• Process instance (run ID).

• Request records.

• Message log.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler, “Understanding PeopleSoft Process Scheduler”

Unit of Work

The unit of work is the interval of processing that takes place between commit points. All PeopleSoft Enterprise General Ledger background processes use a functional approach to defining the unit of work. This guideline is the basis for the restart and recovery process. If a program encounters an error during the unit of work interval, the system rolls back all processing to the previous completed unit of work. If a rollback occurs as a subset of the request criteria, this point is indicated on the request record for that background process.

For the Allocations and Year End Close background processes, the unit of work is defined as a subset (a process step) within the request level. The program can successfully complete an allocation step or close a ledger for a fiscal year without completing all the steps or business units specified in the request record. The Year End Close process commits the work for each unique ledger and business unit combination. This enables you to continue an interrupted job by starting from the failed business unit. In these cases, several commits could be issued before the request record is updated. For the Consolidations and Equitization process, the unit of work is the same as the request level.

The amount of time required to complete a unit of work is critical when determining which processes can run concurrently. Because this is a function of the data, the nature of the requests, and the database environment, you should run tests of typical units of work to see how long they take in the absence of conflicting processes.

Process Instance (Run ID)

The system assigns a unique process instance number to each background run. The number uniquely identifies data within shared work and log tables. The process instance field counter resides in PS_PRCSSEQUENCE.SEQUENCENO. At the start of a background process, a program updates the counter (incrementing it by 1), selects the value, and then commits the work.

Request Records

The request record stores information about the status of a background process. A request record defines the input data that a background process uses to complete a unit of work, and it contains these fields:

When a background process starts, it reads the first request record that is flagged for processing. After the record is read, it is immediately updated as In Process and committed by the background process. This prevents other instances of the process from reading and processing the request, and provides information about the current status.

If the PROCESS_FREQUENCY field value is Process Once, the process changes the value to Don’t Process when the request is complete. The process updates the PROCESS_STATUS field to reflect the success or failure of the run, and it issues a commit immediately after the update.

Message Log

Each background process generates informational and error messages related to the process run. Because all processes share the tables where the system logs these messages, a commit occurs after an insert into the Message Log table to prevent locking by one process.

Initiation of Processes from Application Pages

Some processes, such as the Journal Edit process and the Journal Post process, can be initiated from application data-entry pages. For example, to initiate the Journal Edit process from the Create Journal Entries - Lines page, select Edit Journal in the Process field. The system initiates the edit background process immediately. You use this same method to post and copy a journal on the Lines page.

See Also

Specifying Journal Search Criteria

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler, “Submitting and Scheduling a Process Request”

Restart and Recovery of Processes

If the system encounters an error while processing a request, it performs a rollback and sets the PROCESS_STATUS in the request record to Error. The program then continues to process the next request. To rerun the canceled request, you must return to the online request page and reinitiate the request.

Identify any requests marked in error using the message log information. When you correct the condition that caused the error, mark the request for processing and run the job again.

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.

See Also

Using Non-Shared Tables

Concurrent Processes

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:

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 report is normally less than five minutes.

Background Process Concurrency

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. The Allocations process, the Combination Edit process, the Journal Ledger process, and the Summary Ledger process are all Application Engine processes. 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 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)

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; interim close always creates 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.

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 (GLPPPOST) 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 (GLPPPOST) 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. There should not be any 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_TBLnnn work table. The accounting entries are then updated with the journal information. A commit is issued after each journal is created.

Journal Post Process (GLPPPOST)

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 two primary functions:

1. 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.

2. To create journal entries for the unpost and reversal creation process.

   This consists of Update, Insert, and Delete activity against the JRNL_HEADER and JRNL_LN tables. The posting unit of work is the same as the request. If open item journals are involved, table OPEN_ITEM_GL is updated.

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. LEDGER_ADB_HLD is updated if an average daily balance is maintained for this ledger. 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)

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 ChartKeys 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 (GLPPOITM)

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_TMPnnn is used for the Open Item Reconciliation process. Insert and Update functions are performed against this table within the unit of work interval.

Post Daily Balance Process (GL_ADB_POST)

The Post Daily Balance process uses the following information to post the journal transactions to the ADB ledger: business unit and ledger data, calendar data, ledger template, and the posted activity from the Journal Post process (contained in a holding table). SELECT SQL access is used to retrieve this data.

The main function of the Post Daily Balance process is to post the daily balances to the ADB ledger from the ADB ledger holding table. The ADB ledger holding table contains posted journal activity from the Journal Post process. To ensure the accuracy of the balances, the Post Daily Balance process deletes the posted activity from ADB ledger holding table after it is posted to the ADB ledger. The Post Daily Balance process also inserts data into the ADB adjustment holding tables for posted activity that is required to adjust average daily balances.

A commit is done after the balances are posted and the data is cleared from the adjustment holding table. The time to complete this step is determined by the number of transactions that are posted.

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 table, 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_JRNL)

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.

See Also

Integrating and Transferring Information Among Applications

Making General Ledger Journal Entries