Before we delve into studying the PeopleSoft Financials applications, we need to understand that it is primarily an ERP application, meant to be used as a transaction processing system. Its core philosophy is driven by the need to record, process, and report accounting transactions of an organization.
In this chapter, we'll establish the understanding of core concepts of PeopleSoft applications—such as Chart of Accounts, Business units, SetIDs, Banks, User preferences, and related configurations. We'll also learn how to use an important tool known as Setup Manager, which is used in implementing PeopleSoft applications.
Note that these concepts are not related to a specific module and serve as the foundation for all subsequent modules in this book. A PeopleSoft Financials practitioner must understand these aspects to be able to successfully maintain and implement the applications.
This book relates to the version 9.1 of PeopleSoft applications. As a result, the concepts and screenshots in this book refer to the version 9.1. Some of the screens and basic concepts may be similar to previous PeopleSoft versions.
Any accounting system (be it manual or automated) is built on a structure that determines how the accounting information is recorded (and ultimately reported). Each organization determines the best possible way to capture and classify the vast number of accounting transactions that take place every day. This decision is a combination of two distinct factors:
The need to report the accounting data by various important parameters
Feasibility and ease of recording the accounting transactions
Let's take a very simple example to better understand this.
Global Vehicles Inc. is an automobile manufacturer, selling vehicles such as passenger cars, commercial vehicles as well as scooters. Its operations are spread across multiple countries. Let's say that its annual sales from all its vehicles are $100 million. The key challenge is to know where exactly these dollars are coming from.
Design an accounting system for Global Vehicles, so that it can answer questions like the following:
Which country is contributing the most to Global Vehicle's sales?
Which product family is lagging in terms of revenues?
What were the sales of passenger cars in USA?
Which is the best selling scooter model in terms of revenue?
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:
Continent |
Country |
Product Line |
Model |
Sale Price |
---|---|---|---|---|
North America |
USA |
Passenger Car |
Alpha |
USD 10,000 |
Europe |
France |
Scooter |
Gamma |
FRF 3000 |
North America |
USA |
Passenger Car |
Theta |
USD 30,000 |
North America |
Canada |
Passenger Car |
Theta |
CAD 33,000 |
North America |
USA |
Scooter |
Gamma |
USD 2,000 |
Europe |
UK |
Commercial |
Zeta |
GBP 40,000 |
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:
Chartfield |
Length |
Comments |
---|---|---|
10 |
This is a mandatory chartfield used to record corporate accounts and cannot be used for any other attribute. For example, an organization may use account # 100000 to record fuel expenses, while account # 200000 is used to record salary expenses for employees. | |
10 |
This chartfield is used only for statutory reporting to further classify accounting transactions. | |
8 | ||
5 |
Used primarily in education and government accounting systems. | |
10 | ||
5 | ||
5 | ||
8 | ||
6 | ||
5 |
Used if Project Costing module is implemented to track projects related details. | |
15 |
Used to track projects related details in Project Costing module. | |
15 |
Used to track projects related details in Project Costing module. | |
5 |
Used to track projects related details in Project Costing module. | |
5 |
Used to track projects related details in Project Costing module. | |
5 |
Used to track projects related details in Project Costing module. | |
10 |
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use. | |
10 |
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use. | |
10 |
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use. | |
5 |
Used for inter-unit transactions (transactions between 2 different business units) if only a single inter-unit account is used. This chartfield cannot be used for any other purpose. | |
10 |
Used for intra unit transactions (transactions between two separate Funds belonging to the same business unit) if only a single intra unit account is used. This chartfield cannot be used for any other purpose. | |
10 |
Used for intra unit transactions (transactions between two separate Operating Units belonging to the same business unit) if only a single intra unit account is used. This chartfield cannot be used for any other purpose. | |
10 | ||
4 | ||
4 | ||
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:
Delivered chartfield names cannot be used
You may not need all of the given 25 chartfields
Given chartfields are not sufficient and you need to add additional chartfields (although this is highly unlikely)
To achieve this, you need to perform chartfield configuration activities.
Tip
Expert tip:
As far as the number of required chartfields is concerned, always think of your system's future requirements. Remember, it is extremely complicated to add a new chartfield to the COA if the system already has data using the old COA. If you think there is a possibility of new chartfield requirements down the line, include them in your COA even if you may not use them. You can simply keep it blank until the time it is needed.
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):
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.
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.
An ERP system like PeopleSoft financial applications needs to record and store enormous amounts of data. We need to understand the types of data that the system generates before getting into how it is done. Business Units and SetID form the basic structure of how the system records and accesses this data.
In PeopleSoft architecture, the data are categorized into the following two types:
Transaction data: These are the data elements that are generated due to regular business transactions. For example, an organization like Global Vehicles may create a purchase order for one of its suppliers to buy tires for its vehicles, create a vendor invoice (also known as voucher) to acknowledge that it needs to pay its supplier for received goods or issue a sales invoice when a vehicle is sold.
As you can see, amount of transaction data in a table that stores them, will keep on changing frequently as new transactions take place.
Master (Setup) data: These are the data elements that are needed to enable the system to perform its business transactions. For example, Global Vehicles may have a group of vendors from whom it buys components for its vehicles. It also may have a group of banks where it holds its bank accounts for its financial transactions.
What key differences do you see between such master data and the transaction data elements?
The first (and somewhat obvious) is the dynamic nature of transaction data. As we saw earlier, the number of sales invoices will always keep changing from day to day. On the other hand, how frequently can we expect changes in the number of vendors? True, there will be additions or deletions of vendors, but these changes will be far less compared to transaction data.
The second difference relates to the purpose of these types of data. Master data is needed to perform regular business transactions. For example, a vendor needs to be set up in the system before we can create a purchase order (a business transaction) to buy something from it. Similarly, we need to set up rules to calculate discount before we can create a sales invoice and decide how much discount can be given to a customer.
The third key difference lies in the way these data elements can be shared or need to be separated from each other. Let's assume that Global Vehicles' business has been structured by geography. Thus, it has following operating divisions: North America, Europe, and Asia.
Now let's consider the master data first. Is it possible that all these divisions can have a common vendor or bank? The answer is yes—a single vendor can sell car seats or tires to all the divisions. Similarly, a bank with a global presence can offer banking services to all these divisions. Thus, theoretically, master data can be shared by various groups within the organizations. Note that the master data doesn't always have to be shared, but can be if needed.
Let's consider the transaction data now. When the European division sells a car, can this transaction (sales invoice) be claimed (in other words, shared) by other divisions? The answer is no—the system must segregate sales invoices of Europe from those of North America and Asia divisions, in order to keep a track of them and ultimately report on the sales performance of each.
Thus, while master data can be shared, transaction data belonging to organizational units must be segregated by the system.
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:
Create SetIDs and group master data elements.
Associate a Business Unit with an appropriate SetID to control which master data elements it can access.
Assume that there are five suppliers (or vendors in PeopleSoft terms) for Global Vehicles. All these vendors need to be used by all its Business Units.
As all the master data elements (vendors) are going to be used by everybody, there is a need for only a single group (SetID) of vendors. Let's call this SetID 'GLOVH'. The Vendor table will contain the data as follows:
SetID (Primary Key) |
Vendor ID |
---|---|
GLOVH |
VENDOR1 |
GLOVH |
VENDOR2 |
GLOVH |
VENDOR3 |
GLOVH |
VENDOR4 |
GLOVH |
VENDOR5 |
Now, we need to specify which rows of master data can be accessed by each Business Unit.
Business Unit |
Master data table |
SetID to be accessed |
---|---|---|
Passanger Car |
|
|
Commercial Vehicles |
|
|
Two wheelers |
|
|
Thus, each BU can now access master data defined under 'GLOVH' SetID from the Vendor table.
Vendors 1 and 2 should be accessible only by Passenger Car BU, Vendors 3 and 4 should be accessible only by the Commercial Vehicles BU, while Two wheelers BU should have access only to Vendor 5.
Now we need three distinct groups of vendors. In other words, we need three SetIDs. Let's see how the data will be grouped in the Vendor table:
SetID (Primary Key) |
Vendor ID |
---|---|
|
|
|
|
|
|
|
|
|
|
And finally, let's specify which BU can access which data rows under Vendor table:
Business Unit |
Master data table |
SetID to be accessed |
---|---|---|
Passanger car |
|
|
Commercial vehicles |
|
|
Two wheelers |
|
|
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.