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.