Peoplesoft SETID and Business Unit

Business Units
Business Units are logical units created within any organization for reporting purposes and don’t have any predetermined restrictions or requirements. This flexible structuring device enables you to actually define a higher level of reporting for your employees and group them according to functional or administrative tasks or for your business purposes.

One can define Business Units that reflect the specific functional needs of your internal human resources departments, or reflect the actual business structure of your enterprise. Your Business Units may be, for example, companies, agencies, subsidiaries, divisions, departments, or branch offices within your organization. Or, you may choose to have a single Business Unit represent your entire organization. It’s up to you and your unique business needs.

TableSets and SetIDs
Once you’ve established Business Units, you can define TableSets, or groups of tables, for your system-wide control tables, so that you can share the same code values among multiple Business Units within your enterprise. Conversely, the TableSet feature also enables you to limit access to specific data to only those users who need it, while maintaining all of your data on the same tables. The flexibility to share TableSets among Business Units enables you to centralize redundant information while you keep other information, such as Department and Job Codes, decentralized. You can use Business Units and TableSets to associate a Business Unit with employees in your enterprise and to specify how default values for currencies and country codes will behave throughout the HRMS system, based on either the user’s Permission List or the Business Unit that the system is referencing during a particular business process or activity.

Where a Business Unit organizes your company or your organization, SetIDs help you organize your data within the system. The HRMS system uses tables (Control Tables or Prompt Tables) that use a high-level key that enables you to identify and retrieve data from the system. A secondary high-level key, referred to as a SetID, has also been added on various tables. SetIDs are simply the labels used to identify a TableSet. Business Unit and SetID functionality in PeopleSoft also provides you with a higher business level for reporting purposes and other business data roll-up.

Peoplecode setting value to Null

Peoplecode setting value to Null


Always use space to assign a null value to a string.
e.g. &Test_Str = ” “;


Use 0 (zero) to assign a null value to a number.
e.g. &Test_Num = 0;


Always Use blank value to assign a null value to a date otherwise it will give you invalid date error if it is equated to null or space as string.
e.g. &Test_Date = “”;

Other Data Types

For other data types like record, rowset we can assign them to null so as to get accurate results from all() and none() functions by paasing them as parameter.
e.g. &Test_Rec = null;

Application Class Properties

We can not use all() or none() functions to check if any property of application class is set. For this we will need to check by equating it to null or blank or space or zero based on its type in a conditional statement.

Peoplesoft Template Based Hire extension

From this:


Extending SmartHire (Template Based Hire) with custom Field Change & Field Prompt Events


‘Hiring new employees or adding contingent workers into the system is one of the most time-consuming tasks for Human Resources departments. Template-Based Hire reduces the current labor-intensive data entry process through the Personal Data and Job Data pages by providing a configurable, template-driven approach. Template Administrators can define default data for various sections or fields in the hiring process and they can determine what sections should be displayed, hidden and made  equired to the end-user. This allows organizations to deploy policy control and flexibility in multiple template configurations for the end-users. This flexibility provides Human Resources departments the ability to decentralize the hiring process out to line managers or HR representatives in the field, rather than only allowing centralized hiring.’

Source: Red Paper Template Based Hire Red Paper for Human Resources 9.0.

With the SmartHire you can configure templates with common fields that are required for hiring an employee/contingent worker. On these templates you configure (predelivered) sections with fields, corresponding the PERSON, JOB etc record fields. These fields contain hardcoded validation, where available. Fortunately Oracle has also created a user exit, which you can use to build and configure your own business process validations and prompts. Unfortunately this not been documented. When you look at the screenshot below, you have two sections, where you can configure your own FieldChange event and Field Prompt event.

But what are the prerequisites for the Event class? Which methods need to be used? Which parameters need to be used? Does it need to have return values?

First thing you start to do, is start looking for documentation. There is a red paper available on Oracle Support  document 747744.1, Template Based Hire Red Paper for Human Resources 9.0. This states:

The Field Change App Class provides a user exit for field change code to be added. Some delivered section fields include field change code. For example, the Company field on the delivered Work Location – Job Fields section has field change code that builds prompt lists for other fields in the section, such as Location and Establishment ID. It is recommended that any validation methods added at implementation be stored in customer-created application classes.
The Field Prompt App Class section provides a field prompt user exit. Normally the prompt values come from a prompt table, but a program can be written instead to supply these values. We did not ship any field prompt code, but customers can add their own, if needed. We may actually deliver some field prompt code as system data in future as part of fixes for performance issues.

When you look at PeopleBooks for this subject, it states:

The Field Change App Class provides a user exit for field change code to be added. Some delivered section fields include field change code. For example, the Company field on the Work Location – Job Fields section has field change code that builds prompt lists for other fields in the section, such as Location and Establishment ID.

Note. Oracle recommends that any validation methods added to the PeopleSoft application at implementation be stored in a customer-created application class.

So I had to dig into the code, to see what was needed to build a custom Event class. After a couple of hours, I stumbled upon the Package HRTMPL. This package contains all classes to build the UI of SmartHire and set all FieldChange and Field Prompt Events. These (hardcoded) FieldChange and Field Prompt events get set by the class FieldChangeFactory and FieldPromptFactory.  Let’s take a closer look at the FieldChangeFactory class, here is a portion of the class.

import HRTMPL:TMPL:hrTmplEvent;
import HRTMPL:FC:*;

class FieldChangeFactory extends HRTMPL:TMPL:hrTmplEvent
   method FieldChangeFactory();
   method execute();

method FieldChangeFactory
   %Super = create HRTMPL:TMPL:hrTmplEvent();

method execute
   /+ Extends/implements HRTMPL:TMPL:hrTmplEvent.execute +/

   Local string &FieldName, &RecordName;
   Local object &lObjEvent;
   Local HRTMPL:FC:FieldChange &objFieldChange;

   If %This.getSectionField().isFieldEvent() Then
      &lObjEvent = CreateObject(%This.getSectionField()
      .getEventClassPath() | ":" | %This.getSectionField()
      ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
      ObjectDoMethod(&lObjEvent, "setSectionField", %This.getSectionField());
      ObjectDoMethod(&lObjEvent, %This.getSectionField().getEventMethod());


      &FieldName = %This.getSectionField().getName();
      &RecordName = %This.getSectionField().getParentRecord().getName();

      Evaluate &RecordName
      When Record.JOB

         Evaluate &FieldName
         When Field.BUSINESS_UNIT
            &objFieldChange = create HRTMPL:FC:JobBusinessUnit();
         When Field.REG_REGION
            &objFieldChange = create HRTMPL:FC:JobRegRegion();
         Evaluate [OTHERFIELDS, ETC, ETC]


      If All(&objFieldChange) Then

When you look at this code, you’ll see that if a custom FieldChange is set on a field, the code runs the following lines

1 &lObjEvent = CreateObject(%This.getSectionField().getEventClassPath() |
  ":" | %This.getSectionField().getEventClassID());
2 ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
3 ObjectDoMethod(&lObjEvent, "setSectionField", %This.getSectionField());
4 ObjectDoMethod(&lObjEvent, %This.getSectionField().getEventMethod());

On the first line the Object is created that you defined in the FieldChange section of the field configuration. After this, the method setTmplRowSet is executed and after this the method setSectionField is executed. After this your custom method is called,  you defined in the FieldChange section of the field configuration. You might think you need a custom class with three methods.

When you look at the predelivered  FieldChange classes, you can create the following class hierarchy diagram.

You can see the predelivered  FieldChange classes (PersonBirthCountry, PersonNIDCountry, etc) get extended from FieldChange class, which in it’s turn get extended from the hrTmplEvent class. The hrTmplEvent class already contains the setTmplRowSet  and setSectionField methods.

So, if you were to create your custom class, you should extend the HRTMPL:FC:FieldChange class. You would have to create only one custom method, since the other two methods are inherited from the superclass.

Now that we know what the class needs to look like and where it should reside, let’s create a custom package and class for the field Position Number. Whenever you change the Position Number, I would like to default the Salary Admin Plan, Grade and Step from the PositionData table. The following example will execute this.


import HRTMPL:FC:FieldChange;
class hrTbhFieldChangePosition extends HRTMPL:FC:FieldChange
   method hrTbhFieldChangePosition();
   method execute();
/* Constructor */
method hrTbhFieldChangePosition
   %Super = create HRTMPL:FC:FieldChange();

method execute
   /+ Extends/implements HRTMPL:FC:FieldChange.execute +/
   Local string &PosNbr;
   Local Record &rPositionData;
   Local string &SalAdminPlan, &Grade, &Step;

   /* Get selected position number */
   &PosNbr = %This.getTmplRowSet().getField(Record.JOB, 1, Field.POSITION_NBR)

   /* Check if position has a value, onload this in empty */
   If All(&PosNbr) Then

      /* Get Position defaults from POSITION_DATA record */
      &rPositionData = CreateRecord(Record.POSITION_DATA);
      &rPositionData.POSITION_NBR.Value = &PosNbr;

      /* Get default values from Position Data */
      &SalAdminPlan = &rPositionData.SAL_ADMIN_PLAN.Value;
      &Grade = &rPositionData.GRADE.Value;
      &Step = &rPositionData.STEP.Value;

      MessageBox(0, "", 0, 0, "Choosen position: " | &PosNbr |
      "; Set SalAdminPlan/Grade/Step to: " | String(&SalAdminPlan) |
      " / " | String(&Grade) | " / " | String(&Step));

      /* Set Field Values from Position Data */
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.SAL_ADMIN_PLAN)
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.GRADE)
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.STEP)

The same way the Field Prompt event is constructed.

When you look at the FieldPromptFactory class, you will see the following lines:

If %This.getField().isPromptEvent() Then
   &lObjEvent = CreateObject(%This.getField().getPromptClassPath() |
   ":" | %This.getField().getPromptClassID());
   ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
   ObjectDoMethod(&lObjEvent, "setField", %This.getField());
   ObjectDoMethod(&lObjEvent, %This.getField().getPromptMethod());

This class creates your custom FieldPrompt class, executes method setTmplRowSet and setField and then executes your custom method.

The following class diagram illustrates the hierarchy.

So, if you were to create your custom class, you should extend the HRTMPL:FP:FieldPrompt class. You would have to create only one custom method, since the other two methods (setField, setTmplRowSet) are inherited from the superclass. Let’s say we want the Position Number to have only three positions eg 19000017, 19000018, 19000019. The custom class would look like this:

import HRTMPL:FP:FieldPrompt;
import HRTMPL:TMPL:hrTmplField;
import HRTMPL:TMPL:hrTmplCodeList;
import HRTMPL:TMPL:hrTmplCode;
class hrTbhPromptPosition extends HRTMPL:FP:FieldPrompt
   method hrTbhPromptPosition();
   method execute();

   property HRTMPL:TMPL:hrTmplField objTmplField;
/* Contructor */
method hrTbhPromptPosition
   %Super = create HRTMPL:FP:FieldPrompt();

method execute
   /+ Extends/implements HRTMPL:FP:FieldPrompt.execute +/
   Local integer &i;
   Local HRTMPL:TMPL:hrTmplCodeList &lobjCodeList;
   Local HRTMPL:TMPL:hrTmplCode &lobjCode;
   Local Rowset &rsPositionData;
   Local string &PositionNbr, &PositionDescr;

   /* Get current field executing this method */
   &objTmplField = %This.getField();

   /* Create custom rowset for dropdown values */
   &rsPositionData = CreateRowset(Record.POSITION_DATA);
   &rsPositionData.Fill("WHERE POSITION_NBR IN

   /* Create runtime list of values object */
   &lobjCodeList = create HRTMPL:TMPL:hrTmplCodeList();

   /* Loop through custom rowset positions */
   For &i = 1 To &rsPositionData.ActiveRowCount
      /* Get Position Number & Description */
      &PositionNbr = &rsPositionData(&i).GetRecord(1)
      &PositionDescr = &rsPositionData(&i).GetRecord(1)

      /* Create runtime value object */
      &lobjCode = create HRTMPL:TMPL:hrTmplCode(&PositionNbr,

      /* Add runtime value object to list of values object */


   /* Set runtime list of values object to current Field */


I have created these two classes in a custom package CUSTOM_HRTMPL.

These classes are configured on the Position Number field, as seen in the second screenshot of this post.

Now let’s see it in action on a PeopleSoft Vanilla Demo environment using Template KUEMP_MGR_POSITION, with custom events on section WORK_LOC_POS_NBR on field Position Number.

FieldPrompt with only the position numbers 19000017, 19000018, 19000019

Finally the FieldChange event when selecting a position number