Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation

Design an accounting system for Global Vehicles, so that it can answer questions like the following:

Did you say, "Just make sure that you record all required pieces of information when each vehicle sale takes place"? You are absolutely right if you did!

One way of recording the sale transactions can be recording the Continent, Country, Product line, Vehicle model, and Sale Price. Thus, its sales data for January 2011 may look something like this:

As you can see, one can certainly answer the above questions if your accounting system can record all these attributes for each transaction.

Now let's go one step further. Say Global Vehicles has about 100 dealerships in the USA and wants to know the sales performance for each dealership. How can we address this additional requirement? Simple, by recording the dealership as an additional attribute for all the sales transactions.

You probably realize now that designing the structure of accounting information to be recorded is driven by how you wish to use the data. This structure (collection of all required attributes) is known as the Chart of Accounts (COA). All the attributes in COA are termed Chartfields in PeopleSoft parlance.

You would also be able to appreciate that the number of chartfields that an organization needs, depends on its business requirements. Having few chartfields will make the recording process simpler, but will not offer much insight into the recorded accounting data. On the other hand, having more chartfields will give a more meaningful picture of the accounting transactions, but at the cost of system performance. A PeopleSoft practitioner needs to balance an organization's reporting requirements and ease of use before recommending appropriate Chart of Accounts.

PeopleSoft Financial applications offer the following 25 chartfields:

Note that some chartfields (such as Account, Alternate Account, Project Costing Business Unit, Affiliate chartfields) are reserved for specific purposes and cannot be used to record any value other than its intended purpose. For example, the Account chartfield has to be used only to record corporate accounts used in accounting. However, there are no limitations on the use of other chartfields. Thus, it is not necessary that the Product chartfield has to be used to record a product. You can very well use it to record any attribute such as 'Country' or 'Continent' in the COA example discussed earlier.

As you can see, the given set of PeopleSoft chartfields may not really satisfy the organization's implementation requirements. This can be due to following factors:

To achieve this, you need to perform chartfield configuration activities.

Standard chartfield configuration

The following operations can be performed on PeopleSoft delivered chartfields using standard configuration:

• Changing the display order of chartfields on pages and reports.

• Relabeling long and short names (descriptions) of chartfields.

• Deactivating or activating chartfields.

• Changing the display length of chartfields on pages and reports.

• Changing Related chartfields for IntraUnit Affiliate chartfields.

Follow this navigation to perform standard chartfield configuration:

Setup Financials/Supply Chain | Common definitions | Design chartfields | Configure | Standard configuration

The following screenshot shows the partial Standard Chartfield Configuration page:

The next screenshot shows a part of the bottom half of the page:

In the COA example for Global Vehicles discussed earlier, we need to record the following attributes: Continent, Country, Product Line, and Model. Also, we anticipate that a new chartfield may be required in future to record 'Dealership'. Thus we need five chartfields for the COA (in addition to the Account chartfield). As you can see, PeopleSoft doesn't offer any chartfield by these names.

Therefore, we need to perform the following configuration activities:

• Ensure that necessary chartfields are activated

• Deactivate those chartfields that are not required

• Relabel the active chartfields to reflect actual intended usage

Let's say that we decide to use following chartfields for our example (based on the available chartfield lengths):

Required Chartfield	PeopleSoft Chartfield
Continent	Operating Unit
Country	Fund Code
Product Line	Department
Model	Budget Reference
Dealership	Product
Account	Account

To activate any chartfield that is inactive, select the checkbox next to it and click the Activate button:

• To inactivate any redundant chartfield that is currently active, select the checkbox and click Inactivate button.

• To change the display label of a chartfield, click the Relabel hyperlink. In the secondary page that opens, provide the new name to be used. For example, we need to relabel the Operating Unit chartfield as Continent as shown in the following screenshot:

  

• Change display length of any chartfield in the Display Length column as required (provided it is not greater than original chartfield length).

• Once configuration activities are complete, click Preview button to see what the new COA looks like.

• Final step in the chartfield configuration process is to run the Full Configuration batch process. Click the Configure button to trigger this process.

Advanced chartfield configuration

The following operations can be performed on chartfields using advanced chartfield configuration:

• Add new chartfields

• Delete chartfields

• Resize chartfields

• Rename chartfields

Note that these changes have quite a wide impact on the PeopleSoft system, compared to standard configuration.

Follow this navigation to perform advanced chartfield configuration:

Setup Financials/Supply Chain | Common definitions | Design chartfields | Configure | Advanced configuration

The following screenshot shows the Advanced Chartfield Configuration page:

Tip

Expert tip:

Advanced chartfield configuration is not advised by PeopleSoft. Always try to achieve the desired result by its corresponding action in standard configuration.

Activate an inactive ChartField instead of adding a new ChartField.

Inactivate a ChartField instead of deleting it.

Change the display length rather than the actual field length when reducing the size of a ChartField.

Relabel a ChartField instead of renaming it.

In PeopleSoft parlance, Business Unit is the organizational unit. It can be any entity that needs to maintain its account balances separately from each other for reporting. In the previous examples, we can say that Europe, North America, and Asia will be the business units of the organization.

However, if Global Vehicles wants to be structured by its line of business, we can create the following Business Units: Passenger car, Commercial vehicles, and Two wheelers. Note that transaction data tables will always have Business Unit as their primary key (to identify where they belong to). In other words, sales invoices, purchase orders, accounting journals, and so on are segregated by the Business Unit.

Business Unit configuration needs to be done for each module that is to be implemented. For example, to implement Accounts Payable and General Ledger modules, the Passenger Car BU needs to be configured for both the modules.

Ta bleset ID (or SetID, as it is commonly known) is used to segregate the master data. Depending on how we want to group the master data, an appropriate number of SetIDs are created. It is the SetID that determines which Business Unit can access which master data elements. This is a two step process:

Follow this navigation to configure SetID:

PeopleTools | Utilities | Administration | TableSet IDs

The next screenshot shows the TableSet ID page, where we need to configure the new value:

TableSet Control determines which master data rows can be accessed by a BU. We saw how to do this in the previous illustration. In reality, due to the very high number of data tables, this access is given for a group of tables, rather than a single data table. Let's take a look at how this is configured.

Follow this navigation to configure Tableset Control:

PeopleTools | Utilities | Administration | TableSet Control

The next screenshot shows the TableSet Control page for a Business Unit US001:

As you can see, the BU US001 can access all master data rows defined under SetID GLOVH in the group of records AM_19. Note that this record group contains the Vendor table among others. For other record groups, US001 will be to access master data values defined under a different SetID called SHARE.

A typical PeopleSoft financials implementation requires the following configuration activities:

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.

Configuring ledger templates

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.

Implementation challenge

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.

Solution

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.

Configuring ledgers

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!

Configuring ledger groups

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.

Configuring ledgers for a Business Unit

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.

Implementation challenge

Perform necessary configurations, so that the PeopleSoft financial system can process journals created by the Billing module.

Solution

We'll need to configure (or review the PeopleSoft delivered configurations) for a journal source, accounting entry definition and journal generator templates for the Billing module.

Configuring journal sources

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.

Configuring accounting entry definitions

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:

1. Load accounting entries into JGEN_ACCT_ENTRY table and use the 'GENERIC' definition (if the mapping between the table fields and incoming data elements is simple).

2. If needed, modify the 'GENERIC' definition by using a different table or view other than JGEN_ACCT_ENTRY (if we need to use a different table to hold the incoming accounting entry details).

3. Create a new definition and manually specify necessary fields (if organization requirements dictate that GENERIC definition cannot be used and a new dedicated definition must be used).

Configuring journal templates

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:

Bank ID qualifiers are country pre-defined specific numerical values. This value drives the bank information that needs to be defined for a bank depending on the country it belongs to.

Follow this navigation to configure bank ID qualifiers:

Banking | Banks and Branches | Bank ID Qualifiers

The following screenshot shows the Bank ID Qualifiers page:

As banks can be shared by multiple business units, they are set up by SetIDs.

Follow this navigation to configure a bank:

Banking | Banks and Branches | Bank Information

The next screenshot shows the Bank Information page:

Let's understand some of the important fields on this page:

We can define as many branches for a bank as required. Let's define the New York branch for our bank.

Follow this navigation to set up a bank branch:

Banking | Banks and Branches | Bank Branch Information

The following screenshot shows the Bank Branch Information page:

To enter the address details for this branch, click the Address Information hyperlink. The system opens the Address Information secondary page. The next screenshot shows this page:

To enter the contact person details for this branch, click the Contact Information hyperlink on the Bank Branch Information page. This opens the Contact Information secondary page as shown in the next screenshot:

Add or remove any bank contact person details as needed by clicking + or – button.

To define the contact information, follow this navigation:

Banking | Banks and Branches | Contact Information

The following screenshot shows the Contact Information page, where relevant details of the contact person can be entered:

As we saw earlier, an external bank means a physical bank with which the organization carries out its business. For example, if the organization has banking relationships with HSBC or Citibank, these qualify to be called as external banks. Bank accounts that an organization holds in these banks are in turn called external accounts.

Follow this navigation to configure external bank accounts:

Banking | Banks and Branches | External Accounts

The next screenshot shows the first tab on the External Accounts page:

Let's familiarize ourselves with the important fields on this page:

For example, when a check payment is issued to a vendor, the system creates an accounting entry as follows:

While the payables account is extracted from the voucher being paid, the cash account is retrieved from Cash-AP chartfields specified in this tab.

The following screenshot shows the next tab on this page—Signatories:

The Signatories tab stores the signatory person and the maximum monetary amount that he/she can approve. Note that this information is only for informational purposes and does not affect any processing.

Now let's consider the next important tab on the External Accounts page—Reconciliation. The following screenshot shows the details of Reconciliation tab:

This tab is used to set up the rules for reconciling the bank statement against the cash account positions in Treasury applications. As these are not in the scope of this book, we'll not get into the details. Suffice it to say that PeopleSoft offers three reconciliation methods: Manual, Semi manual, and Automatic.

The following screenshot shows Account Information tab on the page. This tab contains various configuration options used by Receivable and Payable modules:

We'll concentrate on some of the important fields on this page:

The following screenshot shows Collection Methods tab on the page. This tab specifies various options used to receive customer payments in this bank account. Thus, these options are more relevant for the Accounts Receivable module:

The following screenshot shows the Payment Methods tab on the page. This tab specifies various options used to disburse (pay) payments to external entities such as vendors or organization's employees through this bank account. Thus, this tab is more relevant for Accounts Payable module:

Click the Overall Preferences hyperlink to set up cross-module preferences. The following screenshot shows the Overall Preferences tab. This tab specifies the default Business Unit, SetID, and the Localization Country for the given user ID:

As you can see from the screenshot, for the user Anton James, the system will always use US001 as the Business Unit and SHARE as the SetID whenever he accesses a PeopleSoft page to enter a new transaction or retrieve data from the database. Of course, the user can always change this value, but defaulting simplifies the job to a large extent.

Click the Process Group hyperlink on the main User Preferences page.

The following screenshot shows the Process Group tab. This tab contains important configuration options for Accounts Payable and Receivable module features that can be selectively enabled for specific users:

Source Transaction indicates a specific system feature from the Receivable or Payable module. PeopleSoft allows us to select from a group of 25 such system features. The screenshot shows two sample source transactions: VOUCHER (Voucher entry) and ARPAYWS (AR Payment Worksheet).

VOUCHER controls the processing options for the voucher entry function in Payable, while ARPAYWS controls the actions that a user can perform for Payment worksheets in the Receivable module.

In other words, we have just allowed Anton to use these two system features, while preventing him from using the remaining 23.

The Process Group indicates what level of privileges is granted to a user for a selected source transaction.

For example, PeopleSoft offers us the following options (Process Groups) as far as payment worksheets are concerned: ARACTIONA (Do not post), ARACTIONL (Batch standard), ARACTIONN (Batch priority), ARPOST (Post now), ARPOSTGL (Post now through to GL). To perform his job, Anton needs to be able to post the payment worksheets to GL. Thus, we will select the value ARPOSTGL in the Process Group field.

Allow Processing flag controls if on-demand processing is enabled for this user. PeopleSoft allows system users to run certain batch processes from the transaction screens. For example, a user can execute batch processes such as Voucher Post, Journal Generator, and so on. from the voucher entry page itself. He/She need not navigate to a different page just to run that particular process. This is known as on-demand processing.

Click the Billing hyperlink on the main User Preferences page.

The following screenshot shows the Billing tab.

Billing user preferences primarily control which batch processes are executed (or skipped) when they are triggered from a button on the Billing pages. Note that this doesn't apply if the batch processes are executed from their dedicated run control pages.

Server Name specifies the default server where the Billing processes will be executed.

Job Run Opt specifies if certain Billing processes are excluded from being executed. Selecting the 'Print/Load' option means the system runs all the processes in the multi-process job. Selecting the 'No Load' option skips the following processes: Currency Conversion, Load AR, Pre-load, Load GL, Commitment Control, and Standard Form 1080 and 1081 processes. We'll discuss these processes in Chapter 3, PeopleSoft Billing Module.

Click the General Ledger hyperlink on the main User Preferences page.

The next screenshot shows the General Ledger tab:

Use Next Journal ID field controls if this user can manually enter a journal ID when he/she enters a new journal. If this checkbox is selected, while creating a new journal, the system automatically disables the journal ID field and assigns the next number to the new journal. This is an important option to enforce the system generated numbering for GL users.

If the Change Journals from Journal Generator checkbox is selected, the user can modify the chartfields and amounts for the journals created by Journal Generator process. In PeopleSoft GL, journals can be either manually entered or created automatically by Journal Generator process. Manual journals can always be modified by system users. However limiting the capability to modify Journal Generator journals to only a select few users greatly improves the controls.

Click the Procurement | Payables hyperlink on the main User Preferences page.

The following screenshot shows the Payable Online Vouchering secondary page:

Click the Receivab les Data Entry 1 hyperlink on the main User Preferences page.

The following screenshot shows the Receivables Data Entry 1 tab:

The business unit value used in these fields is used as the default value by the system whenever the user accesses the Receivable pages. The user can of course override these default values. However this greatly reduces the data entry efforts.

Click the Receivables Data Entry 2 hyperlink on the main User Preferences page.

The following screenshot shows the Receivables Data Entry 2 tab. This tab contains user preference options for the user to perform two important functions: Payment worksheets and Maintenance worksheets:

Payment worksheets are used to apply customer payment to its outstanding invoices. Maintenance worksheets are used to write off customer invoice amounts (partially or completely) and issue refunds to customers. For example, there may be an outstanding invoice for USD 1000. However it turns out that this customer may not (or will not) pay this amount (due to a variety of reasons). If he/she can pay only a part (say USD 700), we need to write off the remaining USD 300 (30% of the invoice amount). On the other hand, if the customer cannot pay anything, we will need to write off the entire amount of USD 1000.

Options under the Payment Worksheet section:

Options under the Maintenance Worksheet section:

Configure the PeopleSoft Billing module using Setup Manager.

Follow this navigation to access Setup Manager:

PeopleTools | Setup Manager | Manage Implementation Projects

The following screenshot shows the Manage Implementation Projects page:

As you can see, we can create the implementation project either by a product (such as Billing, Accounts Receivable, and so on) or a Business Process (such as Process customer payments, Receive goods, and so on).

For our business requirement, as we need to configure the Billing module, we'll create the implementation project by Product.

Click the Products button. As shown in the following screenshot, the system opens a page listing all the PeopleSoft modules for which the organization holds a license:

Check the Select checkbox next to the required module and click the View Summary button at the bottom of the page.

The system opens a new page with two tabs. The following screenshot shows the Product Summary tab:

The page shows all the features offered by PeopleSoft in selected product. As part of the implementation, one of the critical tasks is to determine which of these features are really needed for the implementing organization.

Let's assume that for our hypothetical Billing module implementation, we do not need the Balance Accumulation and Billing Summarization features. Remove these features from the list by clicking the '-' button next to them.

Click Save at the bottom of the page. The system opens a new page, which is shown in the following screenshot:

Enter the Project Name and Description and click OK. As shown in the next screenshot, the system opens a page showing the implementation project with given name:

Click the Generate Setup Tasks button in this page to automatically create the list of configuration tasks. The following screenshot shows the process status page:

This triggers a batch process in the background with its Run Status as Queued. When the process is completed, the run status automatically changes to Success.

Click the View Setup Tasks button to see the configuration activities. The following screenshot shows the Manage Setup Tasks page that opens:

This page lists out all the necessary configuration activities in the appropriate sequence.

The Status field shows the current status for the setup task. Place the cursor over the icon to see the status: Not started, In progress, or Complete.

Setup Task: Clicking the hyperlink transfers the control to the appropriate page in order to perform the required setup activity.

Click the Tracking tab to record progress of setup activities. The following screenshot shows the details of Tracking tab:

Click the Task Details tab. The following screenshot shows the details of Task Details tab:

Let's look at a different set of tasks. The following screenshot shows a few setup tasks for the Billing module:

As you can see, configuring Adjustment Type and Book Code can be done by Online method alone. On the other hand, configuration for other tasks can be done either by Component Interface or Online method.

Let's understand these different configuration methods:

So, this is what we'll need to do as we go along the configuration of a PeopleSoft module: