Introducing Business Units and Data Sharing

This chapter provides overviews of PeopleSoft business units and data sharing among business units and discusses how to:

• Select a business unit structure.

• Implement tableset sharing.

Understanding PeopleSoft Business Units

Before you implement the Campus Solutions applications for an institution, take a close look at how the institution functions operationally. To make the most of PeopleSoft’s flexible design, you have to first decide how you want to map the operational structures into PeopleSoft applications.

In a PeopleSoft system, a business unit is an operational subset of an organization. Business units can be independent legal entities, or organizations that need to segregate their financial data for accounting purposes, or operational centers that segregate their operations for management purposes.

Business unit names can vary among the different applications within the PeopleSoft system. For example, PeopleSoft Enterprise Student Financials and PeopleSoft Enterprise General Ledger business units typically consist of different entities for financial and tax reporting purposes. You can share business units across any combination of applications in Campus Solutions, or you define them within a single application. If the entire institution keeps only one set of books, then you can have a single business unit. You must have one business unit defined for each PeopleSoft application installed, but all applications can share the same business unit. A minimum of one business unit is required for the entire suite of applications in the Campus Solutions system.

How you define a business unit depends on the institutional structure, requirements, or reporting demands, as well as how you’ve organized operating responsibilities. For example, an institution might separate technical or graduate school operations from its main campus operations. Transactions are stored by business unit. Reports and processes are requested by business unit and security can be enforced by business unit.

Although each business unit keeps its own set of books, the institution can still maintain a single, centralized database, reducing the effort of maintaining redundant information for each business unit and ensuring consistent and accurate consolidated results. In addition, you can produce reports across business units, enabling you to obtain a broad overview or to compare detailed information.

This diagram illustrates how centralized data enables analysis and reporting across business units:

Benefits of centralized data

Understanding Data Sharing Among Business Units

The PeopleSoft system uses business units to separate organizations within the institution. Although each business unit represents a separate organization, there is data that is shared throughout the institution. Business units can share data by using tableset sharing, which is a way to share control table information among business units to minimize redundant data and system maintenance tasks.

This section discusses:

• Tableset sharing.

• Control tables keyed by tableset ID.

• Record groups in tableset sharing.

• Business units, tablesets, and record groups.

• Set control values.

• Data sharing.

Tableset Sharing

Tableset sharing is the sharing of common control tables among business units. There are two types of tables in the PeopleSoft system that are used to store data.

Control tables enable you to use tableset IDs, which make tableset sharing possible. The tableset ID indicates which of the rows in the control table a particular business unit can access. Each row in the control table has a tableset ID associated with it and business units are associated with tableset IDs through record groups:

Business units and tableset IDs associated through record groups

Note. The tableset ID is also referred to as the setID. These terms are interchangeable.

If much of the control table data is the same from business unit to business unit, tableset sharing enables you to share that information among business units instead of having to enter the same data multiple times. For example, suppose that an institution has 10 business units and they all use the same accounts. Instead of having to enter all of the accounts 10 times, you could enter them once and set up tableset sharing to enable all of the business units to access them.

Tableset sharing also enables you to manage exceptions within the organization. For example, suppose that 9 of the 10 business units use the same accounts, but the tenth business unit uses entirely different accounts. This is easily accommodated through tableset sharing.

The two following tables show how different business units access a centralized control table based on tableset ID. In the example, there are three tableset IDs—MAINC, EASTC, and WESTC—representing three campuses. The account number information for all campuses is contained in a single control table. Allowing access to certain tableset IDs can restrict access to the account number information. For example, East Campus (EASTC) can view only its two account numbers when it accesses the control table.

Here are the accounts for all three campuses:

This view shows only the accounts for East Campus:

See Also

Enterprise PeopleTools PeopleBook: Data Management, “PeopleTools Utilities”

Control Tables Keyed by Tableset ID

Here are some examples of the control tables keyed by tableset ID for each application in Campus Solutions. This information can help you decide how the data can be segmented, so that you make the correct decisions when setting up the tableset IDs and assign the correct tableset IDs to record groups.

Note. This list is not exhaustive.

This table lists some examples of control tables keyed by tableset ID:

Record Groups in Tableset Sharing

A record group is a set of functionally or logically related records or views based on how the records are used in the system. A record group can contain a single record or view, or it can contain many records and views. Record groups are delivered as part of the PeopleSoft system and should not be altered.

When you create a business unit, that business unit is automatically linked to each record group in the system that you are using.

Record groups exist for two purposes:

• To save time in data entry.

  With record groups, tableset sharing can be accomplished quickly and easily instead of requiring redundant data entry.

• To provide consistency in the data.

  Record groups ensure that tableset sharing is applied consistently across all related tables and views in the system.

Business Units, Tablesets, and Record Groups

When you create and then save a business unit, a new tableset ID with the same name as the business unit is created. The system automatically assigns that tableset ID to each record group for the new business unit.

Note. PeopleSoft suggests that you create tableset IDs and business unit names that are five characters long. A performance degradation occurs if the tableset IDs or business units have fewer than five characters.

This diagram illustrates the relationship between business unit, record group, and tableset ID:

Relationship between business unit, record group, and tableset ID

Tableset IDs are the labels that the system uses to identify tablesets. You can have as many tableset IDs as you like, but the more you have, the more complex tableset sharing becomes. You always have the same number of tableset IDs as tablesets.

Warning! You must define at least one complete set of these tables—a tableset—for the Campus Solutions system to function.

Note. You must create at least one tableset ID, even if you are not taking advantage of tableset sharing. Some institutions need only one tableset ID and one business unit.

When you set up the control tables in the system, you’ll notice that the tableset ID, or additional primary key, enables the sharing of control table information across business units. If you prefer, you can create a unique set of tables for each new business unit. Either way, tablesets form the building blocks of the system. You populate the individual tables in the tableset according to your particular business rules.

You can also rearrange tablesets by updating tableset assignments for a business unit in the Utilities - TableSet Controls component. A tableset is a group of control table rows identified by the same tableset ID.

You are not required to share all tables in a tableset. With Campus Solutions, you can share any combination of tables with any number of business units, according to your needs. Use the pages in the component to identify, for each business unit, which data is shared and how it is shared.

Tableset sharing can be extremely easy for an organization to design. In fact, it is almost entirely set up by the time you have finished creating the business units.

When defining tableset IDs for Contributor Relations, you must manually create a setID in the tableset ID record, if one does not already exist that matches the Contributor Relations business unit.

Set Control Values

Tablesets are identified by a set control value. The set control value is also a tableset ID. The set control value used to identify a tableset is not the same as the tableset ID that PeopleTools uses to retrieve the data from the tables in the database. Sometimes the set control value is the same as the tableset ID, but other times it is not.

Here is an example of how this works. Suppose that a community college district has three campuses and a main office:

Two of the campuses share location and facility information, and all three share the grading scheme and level or load rules. Here are the shared record groups:

This table shows how set control values and tableset IDs are used to identify which rows appear in prompt boxes:

Data Sharing

With tableset sharing, you can specify the control table data that the system uses for each business unit. If much of the control table data is the same from business unit to business unit, tableset sharing enables you to share that information, instead of having to enter the same data multiple times.

To understand how this works in the PeopleSoft system, consider what happens when a user makes a selection from the available options. The list that appears contains all of the valid entries that can be entered in the field based on the relevant business unit.

This series of questions outlines the online process that occurs:

Tableset sharing process

Note. Record groups and setIDs for a set control value have a one-to-one relationship.

Selecting a Business Unit Structure

Business units offer a flexible structuring device that you can use to implement each PeopleSoft application based on how the institution is organized. In some institutions, the correspondence between existing structures and the organizational model is obvious. In other cases, it can require careful analysis to determine how to set up the business units so that they reflect the institution and enable you to use the system effectively.

In deciding on the business unit structure for a PeopleSoft application, look closely at the structure in the current system as a starting point. What sort of organizing concepts or categories do you use? Do you still want to use these structures in the PeopleSoft system? To decide where to draw the lines between business units in the institution, you may have to weigh a number of different variables. First, you might consider the question from one perspective, saying, “If I use these criteria, my institution divides into these logical units.” Then you might use different criteria and see if the institution divides into different logical units. As you determine at the optimal business unit structure for the institution, keep in mind that in some circumstances you must set up multiple business units and in some cases setting up multiple business units is optional.

Note. Multiple business units are not required for Contributor Relations.

Examine the existing codes and IDs and determine how they might relate to PeopleSoft business units. Consider whether you can make a simple mapping of the existing structures onto business units, or whether you should modify the structures based on the flexibility afforded by the PeopleSoft system.

Note. Work closely with your PeopleSoft implementation partner early in the design to determine how best to define business units for the Campus Solutions system.

Implementing Tableset Sharing

This section provides an overview of tableset sharing implementation and discusses how to:

• Create tableset IDs.

• Review record groups.

• Create business units.

• Assign cross-references for business units.

• Adjust tableset sharing for record groups.

• Adjust tableset sharing by using trees.

Understanding Tableset Sharing Implementation

After you have determined how many business units you need and how you want to organize them, you can create them for the Campus Solutions system, and then implement tableset sharing.

You define tableset IDs for the purpose of administering certain control tables, such as the Department table, in a decentralized way. When you define a tableset ID, consider how to categorize a subset of the control table data. If you want to use multiple tableset IDs to set up tableset sharing for the first business unit that you create—before you have created any additional business units—create tableset IDs on the TableSetID page before defining the business unit.

You can create tableset IDs as you set up the business units. If the default setID that you enter creates a new business unit that does not exist, the system automatically creates it; however, you can also create tableset IDs independent of business unit creation by using the TableSetID page.

To define tableset sharing for the organization, you complete the steps for each of these tasks.

To establish tableset sharing, you:

1. Set up business units.

2. Define record groups.

   You can add new record groups.

3. Define tableset IDs for the organization, to reflect the organization’s structure.

   This step is sometimes optional. It is required, however, for Contributor Relations if a setID matching the Contributor Relations business unit does not exist.

4. Update all of the tableset record group controls.

To link tableset sharing and system defaults to permission lists or business units, you:

1. Set up Primary Permission List Preference Defaulting options.

2. (Optional) Set up all Business Unit HR Defaulting (business unit human resources defaulting) options.

Pages Used to Implement Tableset Sharing

Creating Tableset IDs

Access the TableSet ID - TableSet Control page.

Note. SetIDs should be five characters in length for optimal system performance.

You can create tableset IDs independently or as part of the business unit creation process by using the TableSet ID page. When you add a new business unit to the system, the system automatically specifies a default tableset ID on the Business Unit page that matches the name of the new business unit. If this default tableset ID (with a name matching that of the new business unit) does not already exist, the system automatically creates a new tableset ID with a name that corresponds to the new business unit.

Note. The system creates a tableset ID with the same name as the business unit when you add a new business unit to the system, regardless of whether you choose to use the business unit name as the default setID. Contributor Relations business unit setup does not automatically create a related setID. If you are creating a Contributor Relations business unit that does not already have a matching setID in the tableset ID record, you must create one manually.

To use multiple tableset IDs to set up tableset sharing for the first business unit that you create (before you create any additional business units), create tableset IDs on the TableSet ID page before defining the business unit.

This example illustrates tableset sharing:

Tableset sharing matrix

See Also

Understanding Data Sharing Among Business Units

Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer, “Planning Records, Control Tables and TableSets”

Reviewing Record Groups

Access the Record Group page.

In the record group table, group the record definitions for the tables that you want to share, as well as any dependent record definitions. If you're adding a table to a PeopleSoft application, an appropriate record group may already be defined. But if you are adding new functionality, you may need to add a new record group for the tables that you define.

Warning! Record group definitions and the assignment of the individual tables and views to specific groups are provided to ensure complete and accurate tableset sharing within each functional area. You should not change these record group assignments.

Note. When you add a new record group ID, the system automatically adds the new record group ID to all current set control values (business units). The default setID for the new record group ID is based on the default setID for each set control value, as defined for that set control value on the TableSet Control - Record Group page.

Creating Business Units

Access the Business Unit page.

Warning! For optimal system performance, business units must be five characters. Significant performance degradation occurs if the business units have fewer than five characters.

When you define a business unit, you can specify that the system establish default tableset IDs for the business unit by using the Default Record Group SetIDs group box. This indicates to the system which tableset ID is associated with the business unit. The tableset ID determines the preliminary tableset sharing for the business unit by associating the business unit with a record group.

Default Record Group SetIDs

Note. When you save a new business unit for the first time, the system makes the default setID or clone unit unavailable for entry. You cannot change the default record group setID information for this business unit again. This rule prevents you from accidentally overwriting the tableset record group controls for the defined business units.

When you add a new business unit and save the page, the system creates all of the appropriate table values provided by PeopleTools that connect the business unit ID, record group ID, and setID.

See Setting Up Business Units.

Example of Business Unit and Tableset ID Association

This diagram shows how the business unit, record groups, and tableset ID are associated. The business unit and tableset ID can have the same value:

Tableset sharing

Assigning Cross-References for Business Units

Access the Business Unit Reference page.

Indicate the business unit cross-reference, if applicable, for any of the PeopleSoft applications listed on the page. You can identify business units in other PeopleSoft applications that relate to the business unit.

Adjusting Tableset Sharing for Record Groups

Access the TableSet Control - Record Group page.

Default SetID

Select the default setID to use for the set control value. The default setID is the tableset ID that the system uses when you add additional record definition groups to be shared within this tableset. If you have the system require a default setID (by using the Record Group page), then you cannot change the setID for the record group with a setID that is different from the default setID that you indicate here. The setID for that record group ID becomes unavailable for entry. Remember, most record groups contain a number of tables and views. The tableset ID that you assign to that record group must represent the information that you want to use from each of the control tables contained in that record group.

SetID

For each record group ID, enter the setID to use.

Adjusting Tableset Sharing by Using Trees

Access the TableSet Control - Tree page.

Default SetID	Displays the default setID assigned to the field value. If you created another tableset for sharing trees, you can change this value.
Tree Name	Select the tree definitions that are defined with the same set control field.
SetID	Select the appropriate setID.