Pomona Peoplesoft Development Standardsdraft

Pomona PeopleSoft Development StandardsDRAFT

/ Cal Poly Pomona
PeopleSoft Development Standards
Last Revised: / 11/04/2010

REVISION CONTROL

Document Title: / Pomona PeopleSoft Development Standards
Author: / Tim Raymond
File Reference: / Pomona PeopleSoft Development Standards.doc
Date / By / Action / Pages
2/20/2008 / Tim Raymond / New Document / All
11/10/2010 / Tim Raymond / Removed “Draft” status.

Review/Approval History

Date / By / Action / Pages

Table of Contents

Page

Section 1Naming Conventions

1.1Module Names

1.2Report/Process Naming

1.2.1Cloning CSU delivered reports/processes

1.2.2Cloning PeopleSoft delivered reports/processes

1.2.3Pomona reports/processes

1.3PeopleSoft Object Naming

1.3.1Records

1.3.2Pages

1.3.3Components

1.3.4Menu Items

1.3.5Portal Registry

Section 2Documentation Guidelines

2.1Documenting New Files or Objects

2.1.1SQR/SQCs

2.1.2PeopleSoft Objects

2.2Documenting Changes to Existing Files or Objects

2.2.1SQR/SQCs

2.2.2PeopleSoft Objects

2.3Changing and/or Removing Previously Documented Changes

Section 3Development Standards

3.1SQR/SQC

3.1.1Program Text File Width - Guideline

3.1.2Procedures - Standard

3.1.3Defined Variables – Standard

3.1.4Using Input/Output Files

3.2PeopleSoft Objects

3.2.1Standards Common to all PeopleSoft Objects

3.2.2Records

3.2.3Pages

3.2.4Message Catalog Entries

Section 4Appendix

4.1Appendix A – New SQR Documentation Example

4.2Appendix B – PeopleSoft Object Documentation Example

4.3Appendix C – PeopleCode Documentation Example

Last Revised: 10/28/2018

Section 1Naming Conventions

The standard Pomona naming conventionbegins with POM. Additionally the name should also contain the abbreviated module namewhen applicable (see below). How the abbreviated module name is included in the name is dependent on the type of item. This document will provide guidelines as to how to name various items/objects that you develop.

1.1Module Names

The following is a list of the module abbreviations for HCM:

HR - Human Resources (general HR reports)

BD – Budgets (in the HR system)

BN – Benefits

PY – Payroll

RR – Regulatory Reports

RS – Recruiting Solutions

TL – Time & Labor

WA –Workforce Administration

SSH – Self-Service Human Resources

SA – Student Administration (general SA reports that DO NOT fall into a module)

AD – Admissions

AA – Academic Advisement

EU – Extended University

FA – Financial Aid

FC – Faculty Affairs

SF – Student Financials

SR – Student Records

CC – Campus Community

SSS – Self-Service Student

The following is a list of the module abbreviations for Finance:

FN – General Finance Application

AM – Asset Management

AP – Accounts Payable

AR – Accounts Receivable

BG – Budgets

GL – General Ledger

PO – Purchasing

1.2Report/Process Naming

1.2.1Cloning CSU delivered reports/processes

If the report/process is CSU delivered and is being cloned by Pomona, the Pomona version should retain (if not already taken) the same module designation and number (if it is not already used), and replace ‘CSU’ with ‘POM’.

For example CSUSR104.sqr becomes POMSR104.sqr.

1.2.2Cloning PeopleSoft delivered reports/processes

If the report/process is PeopleSoft delivered and is being cloned by Pomona, the Pomona version should attempt to preserve as much of the original name as possible, while pre-pending ‘POM’ to the beginning of the name.When possible the module name should be preserved, however in these cases it is realized that space is an issue.

For example CCLTRGEN.sqr becomes POMLTRGN.sqr.

1.2.3Pomonareports/processes

Pomona reports/processes will be named using the following convention:

POMXXNNN

Where XX is the module abbreviation (SR, FA, AD, CC, etc.) and NNN is the report/process number. Report numbers shall be between 101 and 499, incremented sequentially. Process number shall be a number greater than 499 incremented sequentially. Numbers below 101 are reserved for CSU use. The next sequential number for the given module can be found on the I&IT Applications website at:

The tracking spreadsheet should be immediately updated (incremented) after the number is determined. This will avoid the possibility that multiple developers may develop a report/process using the same number.

1.3PeopleSoft Object Naming

1.3.1Fields

In order to create the most flexibility and reusability of Pomona fields, field names should not contain the module name and should be named using the following naming convention:

POM_...

The ellipses (…) should be replaced by text that makes sense. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

1.3.2Records

Run Control Records

Pomona has defined common run control records for each module. In HCM these records are:

POM_HR_RNCTL – Human Resources

POM_PY_RNCTL – Payroll

POM_RS_RNCTL – Recruiting Solutions

POM_TL_RNCTL – Time & Labor

POM_SA_RNCTL – Student Administration

POM_AD_RNCTL – Admissions

POM_CC_RNCTL – Campus Community

POM_FC_RNCTL – Faculty Affairs

POM_SF_RNCTL – Student Financials

POM_SR_RNCTL – Student Records

POM_EU_RNCTL – Extended University

In Finance these records are:

POM_FN_RNCTL – General Finance

POM_AM_RNCTL – Asset Management

POM_AP_RNCTL – Accounts Payable

POM_GL_RNCTL – General Ledger

POM_PO_RNCTL – Purchasing

When developing for any of these modules, the common run control record should be used. If the fields needed by the process do not exist they should be added (non-destructively) to the common run control record. The only occasion when a new run control record should be created is when the run control page will have a scroll level that the common run control record does not support. In that case the record should be named using the following naming convention:

POM_XXNNNN_RNCTL

Where XX is the module abbreviation and NNN is the report/process number.

Set-Up Records

If a record is created as a set-up record for a report or process, the record should be named using the following naming convention:

POM_XXNNN_SETUP

or if the record is effective dated:

POM_XXNNN_EFFDT

If child tables are utilized they should be named using the standard report/process prefix of:

POM_XXNNNN_

Where XX is the module abbreviation and NNN is the report/process number.

The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining five characters.

Data Records

Data records are rarely associated with a report or process and as such have more leeway in their naming. Data records should be named using the following naming prefix:

POM_XX_

Where XX is the abbreviated module name. The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters. In rare circumstances an additional character many be needed when naming the record. If that is the case, then the trailing underscore shown in the convention above may be dropped.

Derived Records (Work Records)

Derived records should be named using the following naming conventions:

POM_..._WRK

POM_DERIVED_…

The ellipses (…) should be replaced by a module name if the record is being created specific to a module, or other text that makes sense. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters

Temporary Records

Temporary records are often associated with a report/process. The type of process (SQR or Application Engine) will determine the naming convention. The records should be named using the following naming convention:

Application Engine:POM_XXNNN_TAO

Non Application Engine: POM_XXNNN_TMP

Where XX is the module name and NNN is the report/process number. If multiple temporary tables are needed for a single report/process, the tables should be named using the following naming convention:

Application Engine:POM_XXNNNA_TAO

POM_XXNNNB_TAO

Non Application Engine: POM_XXNNNA_TMP

POM_XXNNNB_TMP

Where XX is the module name and NNN is the report/process number.

If a temporary table is needed for a purpose other than a report/process, it should be named using the following naming convention:

POM_..._TMP

The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

Application Engine State Records

Application Engine state records hold the value of variables while an Application Engine program is running. The records should be named using the following naming convention:

POM_XXNNN_AET

Where XX is the module name and NNN is the report/process number.

Views

Views that are created as a search view should be named using the following naming convention:

POM_..._SRCH

Views that are created in support of a report/processshould be named using the following naming convention:

POM_XXNNN_VW

Where XX is the module name and NNN is the report/process number.

If the view is not created in support of a process/process, it should be named using the following naming convention:

POM_XX…_VW

Where XX is the module name. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

1.3.3Pages

Run Control Pages

Run control pages should be named using the following naming convention:

POM_XXNNNN_RNCTL

Where XX is the module abbreviation and NNN is the report/process number. Note this would be identical to the record name if a record were created specifically for the process.

Run Control Set-Up Pages

If a set-up page is created as part of a process, the page should be named using the following naming convention:

POM_XXNNN_SETUP

or if the page is effective dated:

POM_XXNNN_EFFDT

Where XX is the module abbreviation and NNN is the report/process number. If additional pages including secondary and/or subpages are utilized they should be named using the standard report/process prefix of:

POM_XXNNNN_

However the remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining five characters. Note that this will cause the pages and their associated records have the same name. This is intended.

Other Set-Up Pages

Set-up pages not associated with a report/process should be named using the following naming prefix:

POM_XX_

Where XX is the module abbreviation. The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining nine characters.

Inquire/Use Pages

Inquire/Use pages should be named using the following naming prefix:

POM_XX_

Subpages

Subpages should be named using the following naming convention:

POM_XX…_SBP

Where XX is the module abbreviation, however this may be omitted if the subpage has the ability to be used by various modules. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

Secondary Pages

Secondary pages should be named using the following naming convention:

POM_XX…_SEC

Where XX is the module abbreviation. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

1.3.4Components

Run Control Components

Run control components should be named the same as the run control page that it contains. If the component contains multiple pages, it should be named the same as the main run control page:

POM_XXNNN_RNCTL

Where XX is the module abbreviation and NNN is the report/process number.

Run Control Set-Up Components

If a set-up component is created as part of a process, the component should be named using the following naming convention:

POM_XXNNN_SETUP

Where XX is the module abbreviation. This name should match the name of the main page in the component.

Other Set-Up Components

Components that contain set-up pages not associated with a report/process should be named using the following naming prefix:

POM_XX_

Where XX is the module abbreviation. This name should match the name of the main page in the component.

Inquire/Use Components

Components that contain Inquire/Use pages should be named using the following naming prefix:

POM_XX_

Where XX is the module abbreviation.This name should match the name of the main page in the component.

1.3.5Menu Items

Pomona Custom Menu

The Pomona Custom menu is the menu that is updated regularly. Menu items contain two entries, Name and Label. All names added to this menu should be named using the following naming convention:

Name: The name of the component the menu item is for

The label may vary depending on the type of component the menu item refers to. In all cases the label should begin with the two letter module abbreviation that the menu item is for. Menu labels should be named using one of the following naming prefixes:

Label: XXNNN-…

Label: XX-…

Where XX is the module abbreviation. If the item being added is a report/process, the module abbreviation should be followed by the 3 digit report/process number and a dash. If the item being added is not a report/process then the module abbreviation and dash is sufficient. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

Delivered Menu

On occasion we will seek an exemption and modify a delivered menu. All names and labels added to delivered menus should be named using the following naming convention:

Name: The name of the component the menu item is for

Label: POM-…

The use of the prefix POM is to assist in easily identifying Pomona changes to delivered menus. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.

1.3.6Portal Registry

Portal Registry Entries

Portal Registry Entries contain Name, Label, and Long Description fields to be entered. Portal Registry entry names should be named using the following naming convention:

Name: COMPONENT_NAME_MARKET

Where COMPONENT_NAME is the name of the component the Portal Registry is being created for, and _MARKET is the market that the component was saved as. E.G.:POM_AA101_RNCTL_USA.

The label and long description of a portal registry entry should be named using one of the following naming prefixes:

Label & Long Description: XXNNN-…

Label & Long Description: XX-…

Section 2Documentation Guidelines

All development should be appropriately documented. How that is accomplished varies depending on the object type being developed. This section will provide guidance on how to appropriately document development at Cal Poly Pomona.

2.1Documenting New Files or Objects

Currently SQRsand PeopleSoft objects reflect a variety of documentation standards as they have changed over time. This section will provide guidance as to what the current standard is, as well as when documentation should be removed from files or objects that are being modified.

2.1.1SQR/SQCs

A sample document displaying the following standards can be found in Appendix A.

All SQR/SQCs should have a standard header consisting of multiple sections that contain the following information:

Campus, Report Name (File Name), Developer Name, Creation Date, and Program Name
Program Description (and for SQCs “Used By”)
The program description should be a concise and relatively non-technical description of the program
Used By should reference SQRs that include the SQC
Table Usage
This should contain afull list of all tables utilized by the process.The list should include the full table name, a brief description of the table, and the actions performed on the table by the program. Options may contain one, two, or all of the following actions separated by a / character:
SELECT
UPDATE
INSERT
Debugging Levels
This section should note the various types of debug statements in use throughout the program and a description of what each type do when enabled in the process definition.
Maintenance History and Programming Notes
This section may or may not contain any information when the program is initially written.
For standards to follow when populating this section, please see Section 2.2.1.

The standard delimiter between the header documentation sections is an exclamation point followed by hyphens equal to the file width -1 (i.e.: !------…). Using the standard delimiter is important as it used by a script that pulls the first two sections from each SQR/SQC and stores it in a text file.

All SQRs should also contain the following four constants:

PROCESS_NAME
VERSION_NUMBER
LAST_UPDATE_DATE
CREATE_DATE

All SQRs should contain the following line in the Init-Report procedure to produce the standard Cal Poly Pomona log file header:

Do Display-Pomona-Report-Header

All SQRs should contain the following include statement to allow for the printing of the standard Cal Poly Pomona report header:

#include ‘pomloghdr.sqc’ !Standard Cal Poly Pomona Log Header

2.1.2PeopleSoft Objects

Pomona Custom Menus

The Pomona custom menus’ object properties should be updated each time an item is added. The update should include:

Date, User, Menu, Action

Where User is the person performing the update, Menu is the portion of the menu being updated (i.e.: SetUp, Process, etc.), and Action is what was added.

Example:

**********************************************************************************

DATE USER MENU ACTION

------

11/25/03 Mauricio Calderon CreatedMenu for SA Custom Reports

11/25/03 Mauricio Calderon Process Added CC500.sqr

Other Objects Including but not limited to: Application Engine, Component, Menu, Page, and Record, Delivered PS/CSU Objects (including Menus)

The object definition properties of all PeopleSoft objects should contain a description. The comments section should also contain the campus name, the name of the developer who created the object, the date the object was created, and a description of the object or its use. If there is additional information of value (such as the name of the modification or process that the object is associated with) that should be documented in the comments section as well. A sample displaying the following standards can be found below as well as in Appendix B: