Working with Regulatory Regions

This chapter provides overviews of regulatory regions and regulatory region table relationships and discusses how to:

• Establish regulatory regions.

• Associate a regulatory region with a transaction.

Understanding Regulatory Regions

The Regulatory Region functionality in PeopleSoft Enterprise Human Resources is for use in performing regulatory and regional edits. You use Regulatory Region to drive PeopleCode edits, perform set processing, and control what codes and values the user sees.

A regulatory region can be any region where there are specific laws and regulations that are addressed by functionality in PeopleSoft Human Resources. Many country-specific transactions are driven by regulatory requirements where Regulatory Region is used for transaction processing. These requirements include areas such as ethnicity, disability, and health and safety. When driven by Regulatory Region, the regulatory codes, PeopleCode edits, and set processing in the system can vary by country and for each transaction .

When your system users enter data into PeopleSoft Human Resources, you want them to use the codes and data that are applicable to the regulatory region that they are working with. Using the Regulatory Region feature helps ensure that your users focus on the correct data sets, making their data entry faster and more accurate.

This functionality is especially helpful for organizations that have a multinational workforce. Consider the following examples where the Regulatory Region concept would be useful for organizing your business data:

• An employee officially works in the U.S., but has a health and safety-related incident occur during a business trip in Canada. Using Regulatory Region in the Incident Details component, your users work with incident data and codes (body parts, dangerous occurrences, diagnosis codes, and so forth), that are applicable to the country in which the incident occurred.

• Your organization has implemented PeopleSoft Enterprise Benefits Administration and would like to use its automatic eligibility processing capabilities to determine the benefits enrollment options for your U.S. and Canadian employees. Because benefits rules in Canada and the United States vary, you can use the Regulatory Region on the Eligibility Rules table to set up two sets of benefits eligibility rules: one set for your Canadian workers and another for your U.S. workers.

Understanding Regulatory Region Table Relationships

Use the following pages to review and set up Regulatory Region controls for your system:

• Regulatory Region (REG_REGION)

• Transaction (REG_TRX)

• Regions in Transaction (REG_TRX_REGION)

Use the Regulatory Region page to view or modify existing regulatory regions and to establish additional regulatory regions. The regulatory regions you create can be based on countries or regions within countries, such as states or provinces.

Use the Transaction page to view and modify existing transaction types or to establish and describe new regulatory transaction types.

Use the Regions In Transaction page to view and modify the regulatory regions that define existing regulatory transaction types and to establish the regions that define the new transaction types that you create.

The following table shows the relationships between the regulatory region pages that you use to define and administer regulatory regions in PeopleSoft Human Resources:

These pages do not have an Effective Date or an Effective Status. Both REG_REGION_TBL and REG_TRX have Related Language tables. You can hide data that you don't want by either making the REG_AVAIL = NOT or removing it from the transaction's region list.

Note. During configuration, you must create regulatory regions before you can create transactions and establish the relationship between them. A regulatory region can be used by many transactions.

Establishing Regulatory Regions

While the system is delivered with defined regulatory regions, you might want to add new regulatory regions if you have operations in additional countries. Or you might want to create additional regulatory regions that correspond to regions within countries, such as states or provinces, that impact the way your company does business. For example, you might want to set up regulatory regions for each state in the United States, if you thought that significant regulatory codes or data definitions would vary from state to state. Use the Regulatory Region page to establish these additional regulatory regions.

Note. You don't have to create new regulatory regions. You create new regulatory regions only if there is a special need, perhaps to accommodate specific local regulations. You do have to use the existing regulatory regions that are already in the system. If you have operations in only one country, and you want to limit the impact of Regulatory Region on your data entry users, then you can assign your one region as the default region in the Org Defaults by Permission Lst component (OPR_DEF_TBL_HR).

Note. Although the scope of a regulatory region can be smaller than a country, PeopleSoft recommends that the standard Regulatory Region be at the country level.

To simplify matters and provide consistency, we recommend that you use the following naming standard when creating new regulatory regions:

• For new country-level regulatory regions, use the 3-character, ISO-certified country code found in the Country Table component (COUNTRY_TABLE).

• For regions that are smaller than a country, use the 3-character country code and concatenate a 2-character unique regional identifier. For example, use CCCSS for state-level or province-level regions, where CCC is the country code and SS is the state or province code. Using this system, the regulatory region code for Canada - British Columbia is CANBC.

See Also

Establishing Regulatory Transaction Types

Associating a Regulatory Region with a Transaction

This section provides an overview of regulatory regions and transactions and discusses how to:

• Maintain regulatory regions.

• Use regulatory regions for transaction processing.

• Establish default regulatory regions.

• Assess the impact on PeopleCode transaction processing.

• Create prompt edit transaction views for REG_REGION.

• Add REG_REGION to human resources transactions.

Understanding Regulatory Regions and Transactions

Regulatory Region is used as a control field on pages throughout your PeopleSoft Human Resources system. It is almost always a required field.

PeopleCode is used to associate the desired Regulatory Transaction type or view with the specific transactions that are processed on a page. Regulatory Region fields have an edit prompt off the transaction specific view. The view displays to a user only those countries that are available for that Regulatory Transaction type and for which the user has security access.

A system of standard defaults assists the user in selecting the appropriate regulatory region and transaction.

Note. Usually you can override the defaults to ensure that the proper regulatory region is assigned to a transaction.

Maintaining Regulatory Regions

The size and definition of a regulatory region can be smaller or larger than a country, varying by the transaction or application. However, the standard region is a Country Code.

You can create additional transaction or application views that display only the applicable regions for that transaction. Place the Regulatory Region field on that transaction record and define an edit prompt in the transaction-specific view. The view should display only those countries that are available to the user (either Available to All or With Global Security Only, joined with user Global Security). For example, the following table shows some regulatory regions that are already in the system:

You can add regulatory regions for your own configuration. For example, you can add the 50 U.S. states and differentiate at that level for most transactions.

Using Regulatory Regions for Transaction Processing

The system identifies the general regulatory region for a person by looking at the current effective Job Data record for each EmplID and employee record number combination.

For PeopleSoft Human Resources business process functions that need a different regulatory region for a transaction than is generally associated with a person, add Regulatory Region to that transaction. Use a Transaction view (normally STANDARD) from the Regulatory Region table to provide the appropriate prompt of Regulatory Regions for that transaction.

Once REG_REGION is in a page buffer, you can perform regional edits and set processing.

Note. Be sure to use the Country field (related display) of the region for all country specific edits to ensure that the user can go to a finer level of detail for other edits.

Establishing Default Regulatory Regions

Regulatory Region is almost always a required field. The system establishes the default Regulatory Region in different ways, depending on the PeopleSoft Human Resources business process. You can always override these defaults. The following table lists the components that default a Regulatory Region value and the pages the value defaults from.

See Also

Creating and Tracking Incidents

Setting Up Primary Permission List Preferences

Tracking Disabilities

Defining Establishments

Creating Positions

Assessing the Impact on PeopleCode Transaction Processing

Most transactions involve the Regulatory Transaction type STANDARD. The system performs PeopleCode edits against the person's Regulatory Region in the Job Data component and establishes the appropriate transaction PeopleCode that the system should apply to page processes, based on the regulatory region that you enter.

Note. The Regulatory Region field is required on the Job Data pages. On the Job Data pages, you see only the STANDARD list of regulatory regions to which you have security access.

For Health and Safety transactions or incidents, the Regulatory Transaction type HANDS is used because it includes the Canadian provinces as regulatory regions. The Regulatory Region value on the Org Defaults by Permission Lst component appears by default on the Incident Data and Incident Reporting pages.

Creating Prompt Edit Transaction Views for REG_REGION

Because there are two types of transactions in PeopleSoft Human Resources (STANDARD for employee transactions and HANDS for Health and Safety transactions), there are two different prompt views for those transactions. When you add a transaction to your system, you include a new prompt view that can be built from the views that are included in the system.

REG_STANDARD_VW
                
SELECT   
                
S.OPRID,  
                
R.REG_REGION,  
                
R.DESCR50, 
                
R.COUNTRY  
                
FROM PS_REG_REGION_TBL R,             
                
      PS_REG_TRX_REGION  T,            
                
      PSOPRDEFN S  
                
WHERE T.REG_TRX = 'STANDARD'      
                
AND T.REG_REGION =   R.REG_REGION
                
      AND (R.REG_AVAIL = 'ALL' 
                
          OR (R.REG_AVAIL = 'GBL' 
                
              AND S.OPRID = (SELECT OPRID FROM PS_SCRTY_TBL_GBL G
                
              WHERE S.OPRID = G.OPRID  
                
              AND G.COUNTRY = R.COUNTRY)))
                
REG_HANDS_VW
                
SELECT   
                
S.OPRID,  
                
R.REG_REGION,  
                
R.DESCR50, 
                
R.COUNTRY  
                
FROM PS_REG_REGION_TBL R,             
                
      PS_REG_TRX_REGION  T,            
                
      PSOPRDEFN S  
                
WHERE T.REG_TRX = 'HANDS'      
                
AND T.REG_REGION =   R.REG_REGION
                
      AND (R.REG_AVAIL = 'ALL' 
                
          OR (R.REG_AVAIL = 'GBL' 
                
              AND S.OPRID = (SELECT OPRID FROM PS_SCRTY_TBL_GBL G
                
              WHERE S.OPRID = G.OPRID  
                
              AND G.COUNTRY = R.COUNTRY)))

Note. You can create new transaction views by doing a Save As and changing the hard-coded transaction name.

Adding REG_REGION to Human Resources Transactions

The following two examples show how to associate regulatory regions with human resources transactions:

Example - Job Data

To associate REG_REGION to a person on the Job Data pages:

1. Add the REG_REGION field to the record JOB.

2. Make the REG_REGION field a required field.

3. After adding the field to the record, define a prompt edit from the standard view (REG_STANDARD_VW).

4. Add this field to the page JOB_DATA1.

Now, when you prompt on the Regulatory Region, you see only those Regulatory Regions to which you have security access.

Example - Health and Safety

We associated Regulatory Region with incidents in Health and Safety. Regulatory Region is a required field that controls the values that are returned by all the Health and Safety setup pages that have SetID as their primary key. For example, if the Regulatory Region for an incident is specified as GBR (United Kingdom), then only GBR codes for Dangerous Occurrences appear on the Incident Details - Description page (HS_INC_DESCRIPTION). Health and Safety incidents have REG_HANDS_VW as the prompt edit.

Warning! All linked setup values for an incident must belong to the same regulatory region. If the Regulatory Region is altered (such as when you are operating in update/display mode), and the SetID for the new Regulatory Region is different from the original, all linked setup fields and values are deleted to prevent inconsistent data. For example, the SetID for the Regulatory Region USA is USA, and for GBR it is GBR.. If the Regulatory Region for an already established USA incident is changed to GBR, then all of the linked details on the Incident Details pages are lost. The system prompts you that the Regulatory Region is about to be changed, and you can choose whether to proceed before the values are deleted or not.

In Health and Safety, the following SetIDs are mapped for each regulatory region, as shown:

These regulatory regions were mapped to these SetIDs on the TableSet Control − Record Group page (SET_CNTRL_TABLE1).

All regulatory regions that have region-specific sets of codes or values in the Health and Safety system are mapped to a SetID of the same name. This group includes CANBC, DEU, FRA, GBR, and USA.

The other regulatory regions that aren't mapped to a SetID of the same name fall into two additional categories. Except for British Columbia, the Canadian provinces have no specific provincial codes or values in the system and are mapped to the SetID CAN.

All the other countries that are supported directly in PeopleSoft Human Resources and that don't have any region specific codes or values in the system are mapped to a generic SetID value of STD. This group includes JPN, BEL, and NLD.

Additional Transaction Modifications for Regulatory Region

We've added Regulatory Region to the following PeopleSoft Human Resources components:

• Position Data, with REG_STANDARD_VW as the prompt edit.

• Job Openings, with REG_STANDARD_VW as the prompt edit.

• Establishment, with REG_STANDARD_VW as the prompt edit.

• Org Defaults by Permission Lst, with REG_STANDARD_VW as the prompt edit.

• Disability/Accommodation Request, with REG_STANDARD_VW as the prompt edit.

See Creating Positions.

See Creating Job Openings.

See Defining Establishments.

See Setting Up Primary Permission List Preferences.

See Tracking Disabilities.