The following illustration depicts a high level view of accounting entry creation and processing in PeopleSoft financial applications:
As you can observe, this illustration gives an overview of how different modules, such as Billing, Accounts Receivable, Accounts Payable, Asset Management, Expenses (also known as sub-modules or sub-systems) are integrated with General Ledger module. Each module creates accounting entries for business transactions that take place. For example, the Billing module creates accounting entries for sales invoices for customers; the Asset Management module creates accounting entries for fixed asset addition and depreciation activities, while the Expenses module creates accounting entries for each employee expense report that is processed. Note that these are just a few sample examples. We'll discuss the details of business transactions in respective chapters.
Once the accounting entries are created by a module, a batch process known as 'Journal Generator' performs subsequent activities. Note that Journal Generator process can create accounting journals from accounting entries generated by external non-PeopleSoft systems as well. It performs three critical tasks as part of the journal processing lifecycle:
Journal creation: Journal Generator process transforms these accounting entries into 'Journals'. A journal can be considered as a collection and summarized form of multiple accounting entries.
Journal edit: This process validates created journals based on the validation criteria to ensure that there are no accounting errors. If any errors are found, those journals are accordingly marked. They can be processed further only after their errors are manually resolved. Successfully validated journals are eligible for posting.
Journal posting: This process ensures that amounts in the journals are posted to appropriate General Ledger accounts. In other words, the Journal Post process updates the final account balances in General Ledger. These final account balances are then reported through financial statements such as Income statement and Balance sheet by the organization.
Let's consider a simple example to understand this process. Assume that an organization uses following accounts with hypothetical General Ledger balances:
|
Account |
Description |
Balance Type |
Balance Amount |
|---|---|---|---|
|
100000 |
Trade Receivables |
Debit |
$50000 |
|
200000 |
Customer sales |
Credit |
-$150000 |
Tip
'DR' denotes a 'Debit' transaction, while 'CR' denotes a 'Credit' transaction. PeopleSoft applications always denote credit amounts by a negative sign.
Now let's say that 4 new sales invoices – for $1000, $1500, $2000 and $2500 - are created in the Billing module on a particular day. As part of the invoice processing, the following accounting entries are created:
|
Invoice ID |
Type |
Account |
Amount |
|---|---|---|---|
|
|
DR |
100000 |
$1000 |
|
CR |
200000 |
- $1000 | |
|
|
DR |
100000 |
$1500 |
|
CR |
200000 |
- $1500 | |
|
|
DR |
100000 |
$2000 |
|
CR |
200000 |
- $2000 | |
|
|
DR |
100000 |
$2500 |
|
CR |
200000 |
- $2500 |
Each PeopleSoft module has a dedicated table to store these accounting entries. For Billing, above entries are stored in a table 'BI_ACCT_ENTRY'. Now these entries are ready to be processed by the Journal Generator process.
These entries are then consolidated into a journal as follows:
|
Journal ID |
Type |
Account |
Amount |
|---|---|---|---|
|
|
DR |
100000 |
$7000 |
|
CR |
200000 |
- $7000 |
Let's assume that the Journal edit process successfully validates this journal by ensuring that debit and credit totals in the journal are equal. If successfully validated, it marks the journal to be picked by the Journal Post process. Now the Journal Post process picks up this journal and posts these amounts to the appropriate accounts in General Ledger.
Thus, after this journal is posted, the final account balances will be updated as follows:
|
Account |
Description |
Balance type |
Balance amount |
|---|---|---|---|
|
100000 |
Trade Receivables |
Debit |
$57000 (50000+7000) |
|
200000 |
Customer sales |
Credit |
-$157000 (150000+7000) |
A typical PeopleSoft financials implementation requires the following configuration activities:
Set up a GL Business Units – We'll defer discussion of this activity to the chapter on General Ledger
Configure ledger templates
Configure Detail ledgers
Configure Detail ledger groups
Configure Ledgers for a unit
Configure Journal sources
Configure Accounting entry definitions
Configure Journal templates
As discussed earlier, PeopleSoft ledgers record posted net balances for a set of chartfield values (depending on how many chartfields are activated in the configuration) for each accounting period (such as month) and fiscal year.
A Ledger Template can be considered to be a framework of a ledger's attributes. Rather than using a ledger template for an individual ledger, it is linked to a Ledger Group. As a result, a ledger template applies to all the ledgers in a group. It essentially specifies various records and fields for a ledger that the system needs to report from.
Usually multiple ledgers are clubbed in a Ledger Group. We'll discuss the need for having multiple ledgers in a ledger group in the chapter for General Ledger. For the time being, let's just note that a ledger group can have one primary ledger and (if needed) up to nine secondary ledgers.
Follow this navigation to configure ledger templates:
General Ledger | Ledgers | Templates
The following screenshot shows a part of the Ledger Template page.
The following screenshot shows the remaining bottom portion of the Ledger Template page:
PeopleSoft delivers several default ledger templates (such as Commitment control ledgers, Standard ledgers, Average Daily Balance ledgers, and so on).
The preceding screenshot shows the ledger template used for standard detail ledgers. Each field in this screen refers to a table used for a specific purpose. Most of the fields in this definition here are used by background processes and do not affect the user transactions.
For a typical implementation, you need not change these default templates. However, we'll discuss a few important fields:
Record (Table) Name : This critical table stores the final chartfield combination balances for the posted transactions. For standard ledgers, this table is 'LEDGER'.
Account Chartfield : This table stores the values for the 'Account' chartfield. For standard PeopleSoft applications, it is
GL_ACCOUNT_TBL.Combo Data : This table stores the data used in determining whether a given combination of chartfield values is valid. In PeopleSoft terminology, this is known as 'Chartfield Combination Editing'. For standard ledgers, this table is
COMBO_DATA_TBL.Journal Line : This table stores the detailed journal line information for the journals. For standard ledgers, this table is
JRNL_LN.
Tip
Expert tip:
The given tables are extremely important in the sense that majority of General Ledger processing is based on them. These tables are used by various batch processes; hence such changes have a large impact requiring many code changes. To the extent possible, avoid making changes to delivered table values. Any changes to the delivered table values in ledger template need to be very carefully analyzed. In the rare event that these values are changed, all the journal processes need to be thoroughly tested to ensure that they are not impacted by these changes.
Closing Record Names : These fields specify the tables used in the closing process. The General Ledger chapter will discuss this process in detail.
Multicurrency Record Names : These fields specify the tables used in the multicurrency processing.
ADB Record Names : These fields specify the tables used in the Average Daily Balancing processing.
Ledger Loader Record Names : While ledgers can be configured from the online pages (as we will shortly see), they can also be loaded from external non-PeopleSoft systems. These fields specify the tables used during the external ledger load process.
Click the Field Definitions tab to see default field values populated by the system. These defaults are dependent upon the Default Ledger Type value in the previous tab.
The following screenshot shows the details of Field Definitions tab:
Account : Denotes the field name used for the 'Account' chartfield.
Monetary Amount : A journal line may contain amounts in two different currencies - Base currency of a Business Unit and Foreign currency (Transaction currency). This field stores the monetary amount in the base currency.
Posted Total Amount : This field stores the net balance amount for posted transactions of a chartfield combination.
Combination Edit Template : This field is mandatory for the Journal Edit process we discussed earlier. A value JOURNALS must be selected.
Corporate headquarters of Global Vehicles Inc. is located in the USA. Design a ledger structure to maintain its accounts and report the financial statements in USD. At the same time, it should be able to maintain all accounts in Euros and British Pounds (GBP) for internal reporting.
For the sake of simplification, we'll assume that COA for reporting in all currencies is the same. This can be achieved by maintaining three separate ledgers – one for USD balances, one for GBP balances and another for Euro balances. PeopleSoft General Ledger allows this flexibility to automatically post the journals simultaneously to multiple ledgers. We'll configure these three ledgers (named GLOBALUSD, GLOBALGBP, and GLOBALEUR respectively) and include them in a ledger group for the business unit. Let's see how to do it.
Follow this navigation to configure ledgers: General Ledger | Ledgers | Detail Ledgers
The following screenshot shows the Detail Ledgers page:
Note
Note that ledgers being master data elements (which can be shared by different Business Units) are defined by SetID. As we discussed earlier, a ledger needs to be linked to a ledger template. Thus, it inherits all the attributes that are defined for a ledger template.
Now our ledger is almost ready to start recording the accounting balances. The system knows which database tables and fields to refer to in order to update data from journals or retrieve data for reporting…all courtesy of the ledger template!
Follow this navigation to configure ledger groups:
General Ledger | Ledgers | Ledger groups
Ledger group configuration serves multiple objectives: Grouping multiple ledgers in a similar group (we'll see why we need to do this), specifying the edit tables for the relevant chartfields being used in the ledger, and specifying chartfield balancing options. Let's see each of these important functions in detail now.
We'll call our ledger group GLOBAL.
The Definition tab in the following screenshot , is where we can include multiple ledgers in a group:
We already saw why we need three different ledgers—to address different currency reporting requirements.
Having multiple currency requirements is just one of the possible reasons we need to define multiple ledgers in a group. Commitment control ledgers groups typically have multiple ledgers. We'll discuss them in detail in the Chapter 9, PeopleSoft Commitment Control.
When there are multiple ledgers in a ledger group, one ledger needs to be designated as the primary ledger, while the others are designated as secondary ledgers. PeopleSoft allows up to nine secondary ledgers in a ledger group. In other words, there can be a maximum of 10 ledgers in a group. Remember, it is not mandatory to always define secondary ledgers. If an organization has very straightforward reporting requirements, they can be addressed by a single primary ledger.
Now let's discuss the important fields that you see on the Definition tab:
Ledger Template : As discussed earlier, assign a ledger template to the ledger group so that all its ledgers inherit the template properties.
Keep Ledgers in Sync : This checkbox serves a very important function. If it is checked, the system ensures that journal transactions are posted automatically to all the ledgers in the ledger group. For example, for our ledger group, when a journal entry is created, the Journal Edit process posts it to all the ledgers (GLOBALUSD, GLOBALEUR and GLOBALGBP).
Ledger : Specify the ledger name that needs to be included in this ledger group.
Primary : Specify which ledger in this group is the primary ledger by checking this flag.
Translation : This checkbox determines if a ledger needs to be used by the currency translation process.
Base Currency : Specify the base currency for each ledger.
Inherit Base Currency : If we check this flag, the 'Base Currency' field is no longer available. This forces the base currency for each ledger to be the same as that of General Ledger BU.
The following screenshot shows the Chartfield tab. It is used to specify the edit tables for each chartfield being used by this ledger group:
View – No Effective Date: This field specifies the prompt table used for reporting prompts. Based on an organization's requirements, we can change it if needed. It'll determine which chartfield values are available for users.
The next tab on this page - Balancing - in the following screenshot, determines how the accounting entries are balanced:
Let's first understand the concept of balancing.
A sample journal entry looks something like this:
|
BU |
Account |
Dept |
Op Unit |
Product |
DR/CR |
Amount |
|---|---|---|---|---|---|---|
|
US001 |
123000 |
455 |
CPG |
INT40 |
DR |
$4500 |
|
US001 |
258000 |
155 |
TAX |
INT40 |
DR |
$1500 |
|
US001 |
215000 |
455 |
CPG |
INT40 |
CR |
-$6000 |
What is the most obvious thing about this accounting entry? Of course, the sum of debit and credit lines is equal. In other words, it is 'balanced'. Now can you say that debit and credit amounts are equal for each of the chartfields?
For BU US001 and Product value INT40, this is true. On the other hand, for Account, Department, and Operating Unit, accounting entries are not balanced.
Note that, no matter what happens, accounting entries have to be balanced for each Business Unit. However, if an organization maintains its balances for each Department or Operating Unit (or any other chartfield), then account balances have to be balanced for that chartfield as well.
The Balancing tab determines the chartfields by which the accounting entries must balance. Business Unit is always selected, while Account and Alternate Account are always excluded from balanced chartfields (in accounting terms, as an account can have only debit or credit balance, entries can never balance for an account). If an organization requires that, its entries should be balanced by additional chartfields, (Operating Unit, for example) the Balance checkbox should be selected for that chartfield. This is necessary when reporting needs to be performed by the Operating Unit.
The Journal Edit process ensures that for any journal, its accounting entries are balanced by the chartfields specified here. So, in the previous example (with entries balanced by BU and Operating Unit), our sample accounting entry would have been flagged as invalid since Operating Unit is not in balance.
Now that we have built the basic accounting structure in terms of ledgers, ledger groups, and templates, our PeopleSoft system is ready to record accounting balances. The last step is to link required ledgers to a General Ledger Business Unit.
Note that a GL BU can not only have multiple ledgers (or ledger groups) associated with it, but it can also have ledgers belonging to different types. It is possible that a BU may need to have a ledger group to maintain its budgets, another to record its accounting transactions. It also may have 2 different ledger groups to record transactions in different currencies. How many ledgers (and what types) are needed by a BU is entirely driven by the organization's processing and reporting requirements.
In addition to assigning ledgers/ledger groups to a GL BU, we also configure various processing options.
Follow the navigation to assign ledgers for a BU:
Set Up Financials/Supply Chain | Business Unit Related | General Ledger | Ledgers For a Unit
The following screenshot shows the Definition tab of the page. This is where we select ledgers/ledger groups for a BU:
There are three types of ledgers that can be selected here: Detail ledgers, Summary ledger, and Commitment control ledger. In a nutshell, detail ledgers are used to record actual accounting transactions. Summary ledgers on the other hand record only summarized versions of detailed accounting transactions. Commitment control ledgers record control budgets. We'll discuss the commitment control in greater details in Chapter 9, PeopleSoft Commitment Control.
Let's discuss some of the important fields in this tab:
Ledger Type : If Detail ledger is selected, only a Ledger Group field becomes available. If Summary ledger is selected, a Ledger field becomes available.
Balanced Ledger : Select this checkbox to force the ledger to be balanced. As we saw earlier, this means that the system will ensure that credit and debit balances posted to this ledger group are equal.
Journal Generator Default : Select this checkbox to make this ledger group the default for given BU. When Journal Generator creates journals from other sub-modules, it looks for the ledger group value on each accounting entry line. This value determines the ledger group where that entry will be posted. In case this value is missing on the accounting entry, Journal Generator will post it to the ledger group with this checkbox selected.
The following screenshot shows the next Journal Edit Options tab. This tab specifies how journal errors should be handled by the system:
Available error processing options are as follows:
Default to Higher Level Value : If this journal error is encountered, look at the processing option defined for the GL BU.
Suspend : Post the error amount or the amount needed to bring journals in balance to suspense account (specified using Suspense Chartfields hyperlink).
Recycle : If the error is encountered, mark the corresponding accounting entries as invalid and prevent them from posting until they are corrected and the journal is reprocessed by Journal Edit process.
Accept (only for Journal amount errors) : Ignore the error and continue processing.
The next tab on the page - Currency Options – is shown in the following screenshot:
This tab specifies the default currency options for the given GL BU and the given ledger.
The next tab on the Ledgers for a Unit page is Journal Post. The next screenshot shows details of this tab:
The configuration options on this tab control the posting and unposting of the journals for this ledger group:
D o not post Future-Dated Jrnls: If this checkbox is selected, the system prevents a journal from posting if the journal date is greater than the journal process date. Journal process date is set during the GL BU set up.
Automatic Post Reversals: Some transactions (known as accruals) generate reversing entries in the next accounting periods. If this checkbox is selected, the system automatically selects the future dated reversal entries to post when the original entries are posted.
The following screenshot shows the next Approval Options tab. The configuration options on this tab control the journal approval workflow process:
Based on organization's requirements, we can specify one of the following three options:
Default to Higher Level : Use the approval option specified during the GL BU definition:
Pre-Approved : If this value is selected, journal entries need not go through the approval workflow and the person entering them can post them from the journal entry page
Require Approval : If this value is selected, journal entries need to be approved through workflow before they can be posted
PeopleSoft offers two different workflow methods – Virtual Approver and Approval Framework. If Virtual approver method is selected, the following fields become visible:
Business Process Name : Specify the workflow business process that has been defined for journal approval
Approval Rule Set : Specify the workflow approval set for the selected business process that has been defined for journal approval
If Approval Framework method of workflow is used, the previous two fields are not available.
Tip
Building Virtual Framework workflow (including Business processes and Approval rule sets) requires strong technical skills. As a result, we will not discuss this area in our book.
In the example shown previously, the configuration will force regular journals to be approved, as per the business process rules defined. On the other hand, the budget journals are configured as Pre-approved, which means that they need not go through an approval process.
The last tab on the page is Commitment Control Options. It is shown in the following screenshot:
This tab enables the commitment control for the given ledger group. We'll discuss this in greater detail in Chapter 9, PeopleSoft Commitment Control.
Now that ledgers are ready to record Global Vehicles' accounting balances in multiple currencies, we'll turn our attention to the various sources that will generate the accounting entries and journals.
Perform necessary configurations, so that the PeopleSoft financial system can process journals created by the Billing module.
There are many possible sources which can create journal entries. PeopleSoft sub-modules such as Billing, Accounts Receivable, Accounts Payable, and more create their respective journals. In addition, we can create our own user defined journal sources to categorize manually entered journals. It is also possible that our PeopleSoft system receives journals created from external sources.
We can create as many journal sources as needed to tag the journal entries appropriately. For example, we can define a source 'EXT' for journals imported from an external system. There can be another source 'BI' for journals created by the Billing module.
A journal source is an important place where we can specify various processing options to handle journals from different sources differently. All the processing options we specified for a ledger are automatically inherited to journal sources. You'll see many of those options to be configured for a journal source as well. If an organization wishes to handle journals from a particular source in a different manner, we can do so by specifying that particular option at journal source level.
Note that configuration options specified at General Ledger business unit are overridden by those specified at the ledger. Options that we specify for a journal source override those specified for the ledger.
Follow this navigation to configure journal sources:
Set Up Financials/Supply Chain | Common Definitions | Journals | Source
The following screenshot shows the first tab Definition on the journal source page:
This tab is used to specify the name of the journal source and the effective date (the date from which it becomes active).
The next screenshot shows the next tab - Journal Options. Configuration options on this tab determine how various journal error options are handled for journals created from this source:
Can you recall where you have seen similar options? You are right if you answered Ledger Options For a Unit – Journal Edit Options!
If we select Default to Higher Level Value, the system looks at the configuration option specified for the ledger. If a particular error needs to be handled in a different way, specify the appropriate value here.
The following screenshot shows the next tab on the page - Currency Options:
The fields on this tab are again exactly similar to those we saw for a ledger. Specify a value depending on whether it needs to be different from the ledger value or select Default to Higher Level Value.
The last tab on the page - Approval Options – is shown in the following screenshot:
Specify how the journal approval workflow needs to be handled on this tab. If it need not be different from the configuration options for ledger, select Default to Higher Level Value.
We previously discussed that that Journal Generator process picks up the accounting entries created by a sub-module and transforms them into journals. We also learnt that each sub-module has a dedicated database table to store the accounting entries. It is the Accounting Entry Definition that provides these details of appropriate tables and fields for a sub-module to Journal Generator.
Follow this navigation to configure accounting entry definitions:
General Ledger | Journals | Subsystem Journals | Accounting Entry Definition
The following screenshot shows the accounting entry definition page:
Let's familiarize ourselves with some of the important fields on this page:
Tip
PeopleSoft delivers accounting entry definitions for various sub-modules, with all the details already populated. In most of the cases, we can use the delivered definitions without making any changes.
Record : This is the source table that stores the accounting entries for a particular sub-module. Journal Generator extracts the data from this table to create journals.
Record Update : After Journal Generator creates the journals, it updates this table with the journal details. Usually it is the same table from which accounting entries are extracted.
System Source : PeopleSoft has a pre-configured system source value for each sub-module. Ensure that the right source value corresponding to a module is selected.
Field Names : In the data fields in this section, specify the appropriate field value from the source table specified previously. For example, in the BI_ACCT_ENTRY table, the ACCOUNTING_DT field is used to store the accounting date.
Chartfield Mapping - Chartfield : These chartfields are used for summarizing accounting entries by the journal generator if Summarize to All Chartfield Level option is selected on the journal generator template page. If a chartfield is not listed here, it contains a blank value for the journals created from this accounting entry definition.
Chartfie ld Mapping - Summarize Chartfields: If the Summarize by Selected Chartfields option is selected on the journal Generator template page and this checkbox is selected for a chartfield, it is summarized during journal creation by the Journal Generator.
We'll discuss chartfield summarization shortly in the journal generator template section.
Now, in addition to the PeopleSoft sub-modules, sometimes journals need to be created from the accounting entries from external non-PeopleSoft systems. For such a scenario, PeopleSoft offers an accounting entry definition called GENERIC.
The following screenshot shows the details of GENERIC accounting entry definition:
As you can see, it uses a table JGEN_ACCT_ENTRY to read the accounting entries from. Thus, we need to ensure that these external accounting entries are stored into this table first. Also, the value for System Source field must be JGen-Other.
It's up to us to use any of the following three options to create journals from non-PeopleSoft systems:
Load accounting entries into
JGEN_ACCT_ENTRYtable and use the 'GENERIC'definition (if the mapping between the table fields and incoming data elements is simple).If needed, modify the '
GENERIC'definition by using a different table or view other thanJGEN_ACCT_ENTRY(if we need to use a different table to hold the incoming accounting entry details).Create a new definition and manually specify necessary fields (if organization requirements dictate that
GENERICdefinition cannot be used and a new dedicated definition must be used).
Now we come to the last important step in the configuration of ledgers and journals. In order to create the journals for the Billing module, we configured a Billing journal source and Billing accounting entry definition. Thus, now the system knows where to look for the Billing accounting entries.
Typically, accounting entries created by a sub-module belong to various types. For example, in case of Billing, they can be broadly categorized as regular billing entries (when customer invoices are created) and accrual billing entries (when revenue is recognized, but the customer invoice is not created).
In case of Accounts Receivable, accounting entries can be categorized as billing entries (based on customer invoices), payment entries (when customer payment is received), maintenance entries (when an outstanding invoice is written off, among other things) and so on.
We set Journal Templates for each of such various transaction types. This template determines how the Journal Generator summarizes the accounting entries to create journals. It also controls how the reversing journal entries are created.
Follow this navigation to configure journal generator templates:
General Ledger | Journals | Subsystem Journals | Journal generator Templates
The following screenshot shows the Defaults tab of journal generator template page:
The Defaults tab contains several options that need to be configured as follows:
Accounting Entry In Sync : Recall the Keep Ledgers in Sync checkbox on the Ledger Group configuration page. Checking this flag ensures that an accounting entry posted to the primary ledger in a ledger group is also simultaneously posted to other secondary ledgers as well. For example, when an accounting entry is posted to the GLOBALUSD ledger, PeopleSoft also posts this entry to GLOBALGBP and GLOBALEUR ledgers simultaneously.
Create One Journal For : This field controls how accounting entries are aggregated on the journals. Each line in the accounting entry in PeopleSoft has an application business unit as well as a General Ledger business unit. There may be multiple lines in an entry and it is possible that they may have different business units. Available options for the field are Application Business Unit (system creates a different journal for each subsystem business unit value present in accounting entry) and General Ledger Business Unit (system creates a different journal for each General Ledger business unit value present in accounting entry).
Reversal Code : In the case of some transactions (such as billing accrual), the accounting entries need to be reversed. This option controls if reversal entries should be created, and if so, when:
Do Not Generate Reversal : Journal Generator does not create the reversal entry, but it marks the journals with the reversal code
Beginning of Next Period : Creates a reversing entry dated the first business day of the next accounting period
End of Next Period : Creates a reversing entry dated the last business day of the next accounting period
Next Day : Creates a reversing entry dated the next business day
Journal ID Mask: A unique identifier is used to distinguish journals belonging to different transaction types we discussed previously. For example, we can denote all journals for regular billing to have journals IDs starting with BIR, while the journals for billing accruals journal IDs can start with BIA. System automatically uses this prefix for the journal IDs.
Thus a journal with ID BIA45276 can be identified as a billing accrual journal, while a journal with ID BIR27675 can be identified as a regular billing journal.
Note that it is not mandatory to have different journal ID masks for different transaction types.
The following screenshot displays the Summarization tab of the page. This tab controls how the accounting entries are summarized on the journals:
Again here we have the option to specify two different sets of summarization rules for two groups of accounts.
PeopleSoft offers the following summarization options:
Summarize t o Account, AltAcct: This means that accounting entries are summarized by the Account and Alternate Account (if used) in the journal, while all other chartfields are left blank
Summarize to All ChartFields: This option summarizes the accounting entries to unique combinations of all the chartfields on the Accounting Entry Definition page
Summarize by Selected CF's: This option summarizes the accounting entries to unique combinations of only those chartfields on the Accounting Entry Definition page that have the Summarize ChartField check box selected
You would be able to recall the part of the Accounting Entry Definition page in the following screenshot. This is where we specify which chartfield needs to be used for summarization:
Retain Detail: This option ensures that all accounting entries are distributed to the journal without any summarization and retain all chartfield value details.
If the organization needs to have a single summarization rule for all the accounts, select the option All Account Values and then select the appropriate Primary Summarization option.
If two different summarization rules are needed for two groups of accounts, carefully analyze how these account groups are organized. For the primary group of accounts, specify their values by either the Selected Account Values or Selected Tree Nodes options and then select the appropriate Primary Summarization Option. For all the remaining account values, specify the appropriate summarization option under Alternate Summarization Option.
Example: Accounting entries containing accounts 100001, 100002, and 100003 should be summarized to all chartfields, while all other entries should retain their entire chartfield details. In this case, configuration as shown in the following screenshot, will need to be done:
