Cal Poly Pomona
PeopleSoft Development Standards
Last Revised:
11/04/2010
Pomona PeopleSoft Development Standards
DRAFT
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
Last Revised: 2/12/2016
Action
Pages
Pomona PeopleSoft Development Standards
DRAFT
Table of Contents
Page
Section 1
Naming Conventions ................................................................................................................ 1
1.1
Module Names ......................................................................................................................... 1
1.2
Report/Process Naming ........................................................................................................... 1
1.3
Section 2
2.1
2.2
2.3
Section 3
3.1
3.2
Section 4
1.2.1
Cloning CSU delivered reports/processes ............................................................... 1
1.2.2
Cloning PeopleSoft delivered reports/processes ..................................................... 2
1.2.3
Pomona reports/processes ....................................................................................... 2
PeopleSoft Object Naming ....................................................................................................... 2
1.3.1
Records .................................................................................................................... 2
1.3.2
Pages ........................................................................................................................ 5
1.3.3
Components ............................................................................................................. 6
1.3.4
Menu Items ............................................................................................................... 7
1.3.5
Portal Registry .......................................................................................................... 7
Documentation Guidelines ....................................................................................................... 8
Documenting New Files or Objects .......................................................................................... 8
2.1.1
SQR/SQCs ............................................................................................................... 8
2.1.2
PeopleSoft Objects ................................................................................................... 9
Documenting Changes to Existing Files or Objects ............................................................... 11
2.2.1
SQR/SQCs ............................................................................................................. 11
2.2.2
PeopleSoft Objects ................................................................................................. 12
Changing and/or Removing Previously Documented Changes ............................................. 13
Development Standards ......................................................................................................... 13
SQR/SQC ............................................................................................................................... 13
3.1.1
Program Text File Width - Guideline ...................................................................... 13
3.1.2
Procedures - Standard ........................................................................................... 13
3.1.3
Defined Variables – Standard................................................................................. 14
3.1.4
Using Input/Output Files ......................................................................................... 14
PeopleSoft Objects................................................................................................................. 14
3.2.1
Standards Common to all PeopleSoft Objects ....................................................... 14
3.2.2
Records .................................................................................................................. 14
3.2.3
Pages ...................................................................................................................... 15
3.2.4
Message Catalog Entries ....................................................................................... 15
Appendix ................................................................................................................................ 17
4.1
Appendix A – New SQR Documentation Example ................................................................ 17
4.2
Appendix B – PeopleSoft Object Documentation Example ................................................... 19
Last Revised: 2/12/2016
Pomona PeopleSoft Development Standards
4.3
DRAFT
Appendix C – PeopleCode Documentation Example ............................................................ 20
Last Revised: 2/12/2016
Section 1
Naming Conventions
The standard Pomona naming convention begins with POM. Additionally the name should also contain
the abbreviated module name when 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.1
Module 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.2
Report/Process Naming
1.2.1
Cloning 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.
Last Revised: 2/12/2016
Page 1 of 20
1.2.2
Cloning 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.3
Pomona reports/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:
http://www.csupomona.edu/~iit/applications/process_reports.shtml
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.3
PeopleSoft Object Naming
1.3.1
Fields
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.2
Records
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
Last Revised: 2/12/2016
Page 2 of 20
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:
Last Revised: 2/12/2016
Page 3 of 20
POM_..._WRK
or
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
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.
Last Revised: 2/12/2016
Page 4 of 20
Views that are created in support of a report/process should 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.3
Pages
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.
Last Revised: 2/12/2016
Page 5 of 20
Inquire/Use Pages
Inquire/Use pages 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.
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.4
Components
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:
Last Revised: 2/12/2016
Page 6 of 20
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.5
Menu 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.6
Portal 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
Last Revised: 2/12/2016
Page 7 of 20
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-…
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.
Section 2
Documentation 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.1
Documenting New Files or Objects
Currently SQRs and 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.1
SQR/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”)

o
The program description should be a concise and relatively non-technical description of
the program
o
Used By should reference SQRs that include the SQC
Table Usage
o

This should contain a full 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
Last Revised: 2/12/2016
Page 8 of 20
o

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
o
This section may or may not contain any information when the program is initially
written.
o
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’
2.1.2
!Standard Cal Poly Pomona Log Header
PeopleSoft 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
Created Menu 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:
Last Revised: 2/12/2016
Page 9 of 20
California State Polytechnic University, Pomona
Developer: Tim Raymond
Date: 04/01/2009
Purpose:
This run control component is to run POMCC505 Flatten Acad Org.
------------------------------------------------------------------------------------------------History
------------------------------------------------------------------------------------------------04/02/2009 - Tim Raymond
Object Created
04/24/2009 - Tim Raymond
Object was modified to add the following four fields: INSTITUTION, ACAD_CAREER, ACAD_PLAN,
ACAD_PROG
05/31/2009 - Tim Raymond
Object was modified by adding record POM_CC_EFFDT to allow the run control to hold multiple
parameters so that it can have multiple runs under the same run control ID.
PeopleCode
All newly developed PeopleCode should have a standard header consisting of two sections that contain
the following information, followed by an example:

Campus, Developer Name, Creation Date, and Description

Maintenance History and Programming Notes
o
This section may or may not contain any information when the program is initially
written.
o
For standards to follow when populating this section, please see Section 2.2.2.
/***********************************************************************************************
California State Polytechnic University, Pomona
Programmer: Tim Raymond
Create Date: 01/16/2008
Description: This code was developed to support the Pomona Credentials Mod.
Maintenance History
------------------Date
Mod.#
Initials
Last Revised: 2/12/2016
Description
Page 10 of 20
-------- -----20080110-POM001
-------TJR
------------------------------------------------------------------Modified code to carry all current values forward on RowInsert.
Notes
----Date
Note#
Initials
Description
-------- -----------------------------------------------------------------------------***********************************************************************************************/
The Maintenance history section will be added, if necessary, when the PeopleCode is updated.
A sample of PeopleCode including the documentation of changes can be found in Appendix C.
2.2
Documenting Changes to Existing Files or Objects
2.2.1
SQR/SQCs
Changes to an existing file should be documented in the Modification History section of the file. Each
documented modification should be referenced by the date and modification number for that date in the
format YYYYMMDD-##. The initials of the developer making the change should follow the
modification date-number. Finally a clear description of the change should follow the developer’s initials.
Each modification number should pertain to a single change. That change may cause updates to different
lines throughout the file all referencing the same modification number. Other changes that are either
significantly different than or unrelated to the other changes should receive their own modification
number.
Adding, Deleting, or Changing Lines of Code
Comments relating to each change should be reflected on the line that the change is made, right justified
as follows:
!20080531-01
If the change involves deleting a line of code, then the comment relating to the change should appear
alone on the line that was deleted.
Old code should never be commented and left in a file. It should always be deleted.
Adding Procedures
When a procedure is added it is not necessary to add the modification date-number to each line added.
The addition of a procedure will be referenced with the modification date-number right justified on the
same line as the “Begin-Procedure …” code block as follows:
!============================================================================
Begin-Procedure Lookup-ID
!20080531-02
!============================================================================
Defined Variables
Every time an SQR is modified both the VERSION_NUMBER and LAST_UPDATE_DATE variables
should be updated to remain current.
Log Output
All SQRs should at a minimum contain the following info in addition to the info the standard log header
provides:
Last Revised: 2/12/2016
Page 11 of 20
Run Control Parameters
Process Instance Number
List of all parameters on the run control for the given execution
Process Instance number of the given execution
Begin Time
Date-Time Stamp when the process started
End Time
Date-Time Stamp when the process ended
In addition the following information should be provided in the log/trace file when it makes sense. This is
left to the developer’s discretion:
Records Processed
A count of the records processed
May include separate counts for reads, inserts, updates, deletes
Step or Procedure
What is currently being executed.
This should include some identifying info like EMPLID for reference.
2.2.2
PeopleSoft Objects
PeopleCode
When making changes to PeopleCode, the Modification date-number should appear above the line that is
added/changed when the change involves a single line of code. If the addition/change involves more than
a single line of code the modification date-number should be appended with “Begin” and “End” to denote
the beginning and end of the lines of changed code, as follows:
Single line code change:
/* 20090402-POM001 */
&PRCSSTATUS = &RQST.Status;
Multiple line code change:
/* 20090402-POM002 Begin */
If %Component = Component.TSCRPT_RQST Or
%Component = Component.AA_RPT Then
&REQUEST_REASON_CD = SA_REQUEST_HDR.REQUEST_REASON_CD;
SA_REQUEST_HDR.REQUEST_REASON_CD = "X";
SA_REQUEST_HDR.REQUEST_REASON_CD = &REQUEST_REASON_CD;
End-If;
/* 20090402-POM002 End */
A sample of PeopleCode including the documentation of changes can be found in Appendix C.
Other Objects Including but not limited to: Application Engine, Component, Menu, Page, and
Record, Delivered PS/CSU Objects (including Menus)
Last Revised: 2/12/2016
Page 12 of 20
2.3
Changing and/or Removing Previously Documented Changes
When changing or removing a previous change, the previous change number should be captured in the
change documentation, and the previous change line comment removed. This ensures that references to a
given change never completely disappear from a file, even if the change itself does.
Section 3
Development Standards
There are some basic development standards to adhere to when developing at Cal Poly Pomona. This
section will outline what standards are to be followed.
3.1
SQR/SQC
SQRs and SQCs developed at Cal Poly Pomona should conform to some standards and may conform to
some development guidelines. This section will discuss standards and guidelines associated with
SQR/SQC development.
3.1.1
Program Text File Width - Guideline
When coding a new SQR/SQC, there is not a standard file width that must be followed. As a guideline,
the file width should be no more than 90 characters if it is desirable to allow for printing the file in
portrait mode. Files that are 90 characters wide are printable without line wraps using a fixed width font
(i.e. Courier New) at 10 point with ½ inch page margins. As a guideline, the file width should be no more
than 100 characters if it is desirable to print in landscape mode. Regardless of the width of the file (90
characters, 100 characters, or a width of your own choosing) the file should have a standard width
throughout, and comments denoting changes should be justified against the right margin. Code lines
longer than the standard width may be continued onto additional lines using the SQR command
continuation symbol – (hyphen).
3.1.2
Procedures - Standard
A line containing an exclamation point followed by the file width -1 equal signs (i.e.: !======…) should
appear one line above and below the line containing the Begin-Procedure syntax as follows:
Last Revised: 2/12/2016
Page 13 of 20
!============================================================================
Begin-Procedure Lookup-ID
!============================================================================
3.1.3
Defined Variables – Standard
The Pomona standard log/trace file and report header sqcs contain standard data elements and use
standard variable names to display them. In order for these to function properly the following defined
variables should appear at the beginning of every Pomona SQR:
#define
PROCESS_ID
'POMFN501.sqr'
#define
PROCESS_NAME
'Password Aging Process'
#define
VERSION_NUMBER
'001'
#define
LAST_UPDATE_DATE
'01/16/2008’
#define
CREATE_DATE
'01/16/2008'
3.1.4
Using Input/Output Files
When using any files within an SQR, all references to the file(s) should be clear and meaningful, for
instance:
show 'Open of output file failed - program exiting'
At no time should a reference to the ambiguous file handle be used:
show 'Open of file 10 failed - program exiting'
3.2
PeopleSoft Objects
3.2.1
Standards Common to all PeopleSoft Objects
3.2.2
Records
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:
Last Revised: 2/12/2016
Page 14 of 20
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. When creating new run
control records please be sure to adhere to the naming standards detailed in Section 1 of this document.
Derived Records (Work Records)
Derived records are typically generic in nature so that they may be utilized by a wide variety of pages and
reports/processes. When a derived record is needed, first a search of existing derived records (both
delivered and custom) should be performed to see any existing records can be utilized without changes. If
none exists, the existing derived records should be assessed to determine if one could be altered with
additional fields to serve the need. A new derived record can be created only if it has been determined that
there are no existing derived records that can be utilized. When creating new derived records please
adhere to the naming standards detailed in Section 1 of this document.
Temporary Records
Temporary records should be created as Record Type: Temporary Table. Temporary records are usually
associated with a report/process. When creating new temporary records please adhere to the naming
standards detailed in Section 1 of this document.
3.2.3
Pages
In order to remain consistent with the rest of the user experience in PeoplSoft, pages should be created
using the following size in the object properties “Use” tab:
800X600 page without portal
In addition please observe the following guidelines when developing a new page:

Labels and fields on pages should appear consistent and orderly.

Field tab order should follow a logical order of fields on a page from left to right, top to bottom.

All fields that display or accept a code of some sort should have immediately nest to them a
related display showing a description of the code (i.e.:Term, Career, Test ID, etc.)

Fields that contain an allowable set of values should always be prompt fields.
When creating new pages please adhere to the naming standards detailed in Section 1 of this document.
3.2.4
Message Catalog Entries
Message Catalog Entries
Last Revised: 2/12/2016
Page 15 of 20
The Pomona Message Catalog entries exist in the message Set number range of 32,000. In HCM they are
split up between modules as follows:
32,000 – 32,009
Campus Community
32,010 – 32,019
Admissions
32,020 – 32,029
Financial Aid
32,030 – 32,039
Student Records
32,040 – 32,049
Student Financials
32,050 – 32,059
Academic Advising
32,060 – 32,099
Human Recourses (they may further divide this range by HR Module)
Last Revised: 2/12/2016
Page 16 of 20
Section 4
4.1
Appendix
Appendix A – New SQR Documentation Example
The following example demonstrates the standard Cal Poly Pomona SQR/SQC documentation standard.
The Maintenance History and Notes sections should be created when new SQR/SQCs are created and
may or may not be initially populated.
!---------------------------------------------------------------------------------------! California State Polytechnic University, Pomona
! Report Name: POMFN501.sqr
!
Programmer: Tim Raymond
! Create Date: 01/16/2008
! Program Name: Password Security
!---------------------------------------------------------------------------------------!
! Program Description
! ------------------! This process reads a flat file containing user's last password change date. A date
! comparison is performed and based on the parameters on the run control a user may
! receive an email notification that their account may soon be locked. Accounts with
! passwords that are too old based on the run control parameters may be locked.
!
!---------------------------------------------------------------------------------------!
! Table Usage
! ----------!
! Table Referenced
Description
Usage
! -----------------------------! PS_POM_RUN_FN
Procedure Run Control Record
SELECT
! PSOPRDEFN
PS Operator Definition Record
SELECT/UPDATE
!
!---------------------------------------------------------------------------------------!
! Debugging Levels
! ---------------!
! Level
Description
! --------------!
P
Display Procedure Names
!
S
Miscellaneous additional info regarding individuals being processed
!
!---------------------------------------------------------------------------------------!
! Maintenance History
! ------------------!
! Date
Mod.#
Initials
Description
! -------- --------------------------------------------------------------------! 20080110-01
TJR
Cloned POMCC501.SQR from HCM for Finance.
!
! 20080303-01
TJR
Added replace line to allow $days_til_locked to be in the
!
notification text. Moved line to before call to
!
Process-Notification.
!
! 20080303-02
TJR
Added replace line to allow $oprid to be in the
!
notification text.
!
! 20080425-01
TJR
Cleaned up show statements by removing a blank one and
!
adding #debugp to others.
!
! 20080512-01
TJR
Performed file clean-up. Changes include standardizing
!
case and debug statements, rearranging program flow,
!
creating standard #define variables, creating standard
!
program header including sqr file name, version number,
Last Revised: 2/12/2016
Page 17 of 20
!
create date, and update date.
!
! Notes
! ----!
! Date
Note#
Initials
Description
! -------- --------------------------------------------------------------------!
!
!----------------------------------------------------------------------------------------
#include
#define
#define
#define
#define
#define
#define
'setenv.sqc'
PROCESS_NAME
PROCESS_ID
VERSION_NUMBER
LAST_UPDATE_DATE
CREATE_DATE
RECORD_LENGTH
!Set environment
'Password Aging Process'
'POMFN501.sqr'
'003'
'05/12/2008'
'01/16/2008'
200
!20080512-01
!20080512-01
!20080512-01
!20080512-01
!20080512-01
!========================================================================================
Begin-Setup
!========================================================================================
Declare-Variable
date $sysdate
date $lastdate
End-Declare
End-Setup
!========================================================================================
Begin-Program
!========================================================================================
do
do
do
do
do
do
Init-DateTime
Init-Number
Get-Current-DateTime
Init-Report
Select-Parameters
Open-Input-File
!20080512-01
do Process-Main
do Close-Input-File
do Reset
do Stdapi-Term
do Successful-EOJ
End-Program
!========================================================================================
Begin-Procedure Init-Report
!========================================================================================
#include 'pomloghdr.sqc'
!Print Pomona standard log/trace header
Last Revised: 2/12/2016
Page 18 of 20
4.2
Appendix B – PeopleSoft Object Documentation Example
The following should be in the Comments section of the Definition Properties for all newly developed
PeopleSoft objects. The Maintenance History section should be created when the object is created and
may or may not be initially populated.
California State Polytechnic University, Pomona
Developer: Tim Raymond
Date: 04/01/2009
Purpose:
This run control component is to run POMCC505 Flatten Acad Org.
------------------------------------------------------------------------------------------------Maintenance History
------------------------------------------------------------------------------------------------04/02/2009 - Tim Raymond
Object Created
04/24/2009 - Tim Raymond
Object was modified to add the following four fields: INSTITUTION, ACAD_CAREER, ACAD_PLAN,
ACAD_PROG
05/31/2009 - Tim Raymond
Object was modified by adding record POM_CC_EFFDT to allow the run control to hold multiple
parameters so that it can have multiple runs under the same run control ID.
Last Revised: 2/12/2016
Page 19 of 20
4.3
Appendix C – PeopleCode Documentation Example
The following header should appear at the top of all newly developed PeopleCode. The Maintenance
History and Notes sections should be created when the code is created, and may or may not be initially
populated.
/***********************************************************************************************
California State Polytechnic University, Pomona
Programmer: Tim Raymond
Create Date: 01/16/2008
Description: This code was developed to support the Pomona Credentials Mod.
Maintenance History
------------------Date
Mod.#
Initials
-------- -----------20090326-POM001 TJR
Description
------------------------------------------------------------------Added logic to test/set users language preference appropriately.
20090326-POM002
Added code to populate &wild variable
TJR
Notes
----Date
Note#
Initials
Description
-------- -----------------------------------------------------------------------------***********************************************************************************************/
If %Component = Component.TSCRPT_RQST Or
%Component = Component.AA_RPT Then
&OPRID = %OperatorId;
If None(PRCSRUNCNTL.LANGUAGE_CD) Then
/* 20090326-POM001 Begin */
If Not SQLExec("SELECT LANGUAGE_CD FROM PSOPRDEFN WHERE OPRID = :1", &OPRID, &LANG_CD) Then
&LANG_CD = PSOPTIONS.LANGUAGE_CD;
End-If;
/* 20090326-POM001 End */
&LANG_OPTION = "O";
SQLExec("SELECT LANGUAGE_CD FROM PS_PRCSRUNCNTL WHERE OPRID =:",
If None(&EXISTS) Then
&OPRID, &OPRID, &EXISTS);
SQLExec("INSERT INTO PS_PRCSRUNCNTL (OPRID) VALUES (:1)", &OPRID);
End-If;
End-If;
/* 20090326-POM002 */
&wild = 1;
SQLExec("SELECT RUNCNTLID FROM PSPRCSRUNCNTL WHERE OPRID =:1", &OPRID, &RUNCNTLID);
If None(&RUNCNTLID) Then
SQLExec("INSERT INTO PSPRCSRUNCNTL (OPRID) VALUES (:1)", &OPRID);
End-If;
End-If;
Last Revised: 2/12/2016
Page 20 of 20