Pomona PeopleSoft Development Standards by hij8Bw3

VIEWS: 14 PAGES: 24

									                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                  Action                                     Pages




Last Revised: 7/5/2012
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.2.1         Cloning CSU delivered reports/processes ............................................................... 1
              1.2.2         Cloning PeopleSoft delivered reports/processes ..................................................... 2
              1.2.3         Pomona reports/processes ....................................................................................... 2
     1.3      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

Section 2     Documentation Guidelines ....................................................................................................... 8
     2.1      Documenting New Files or Objects .......................................................................................... 8
              2.1.1         SQR/SQCs ............................................................................................................... 8
              2.1.2         PeopleSoft Objects ................................................................................................... 9
     2.2      Documenting Changes to Existing Files or Objects ............................................................... 11
              2.2.1         SQR/SQCs ............................................................................................................. 11
              2.2.2         PeopleSoft Objects ................................................................................................. 12
     2.3      Changing and/or Removing Previously Documented Changes ............................................. 13

Section 3     Development Standards ......................................................................................................... 13
     3.1      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
     3.2      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

Section 4     Appendix ................................................................................................................................ 17
     4.1      Appendix A – New SQR Documentation Example ................................................................ 17
     4.2      Appendix B – PeopleSoft Object Documentation Example ................................................... 19




Last Revised: 7/5/2012
Pomona PeopleSoft Development Standards                                                                            DRAFT



     4.3      Appendix C – PeopleCode Documentation Example ............................................................ 20




Last Revised: 7/5/2012
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: 7/5/2012                                                                        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: 7/5/2012                                                                            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: 7/5/2012                                                                            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: 7/5/2012                                                                           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: 7/5/2012                                                                          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: 7/5/2012                                                                          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: 7/5/2012                                                                          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: 7/5/2012                                                                               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’                 !Standard Cal Poly Pomona Log Header

2.1.2      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: 7/5/2012                                                                              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       Description




Last Revised: 7/5/2012                                                                              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: 7/5/2012                                                                         Page 11 of 20
   Run Control Parameters        List of all parameters on the run control for the given execution
  Process Instance Number        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: 7/5/2012                                                                          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: 7/5/2012                                                                         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: 7/5/2012                                                                         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: 7/5/2012                                                                             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: 7/5/2012                                                                       Page 16 of 20
Section 4           Appendix
4.1        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: 7/5/2012                                                                Page 17 of 20
!                              create date, and update date.
!
! Notes
! -----
!
! Date      Note#   Initials   Description
! -------- -----    --------   ----------------------------------------------------------
!
!
!----------------------------------------------------------------------------------------


#include   'setenv.sqc'       !Set environment
#define    PROCESS_NAME       'Password Aging Process'                      !20080512-01
#define    PROCESS_ID         'POMFN501.sqr'                                !20080512-01
#define    VERSION_NUMBER     '003'                                         !20080512-01
#define    LAST_UPDATE_DATE   '05/12/2008'                                  !20080512-01
#define    CREATE_DATE        '01/16/2008'                                  !20080512-01
#define    RECORD_LENGTH      200

!========================================================================================
Begin-Setup
!========================================================================================
  Declare-Variable
    date $sysdate
    date $lastdate
  End-Declare

End-Setup


!========================================================================================
Begin-Program
!========================================================================================

  do   Init-DateTime
  do   Init-Number
  do   Get-Current-DateTime
  do   Init-Report
  do   Select-Parameters                                                    !20080512-01
  do   Open-Input-File

  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: 7/5/2012                                                                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: 7/5/2012                                                                      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     Description
-------- -----   --------     -------------------------------------------------------------------
20090326-POM001 TJR           Added logic to test/set users language preference appropriately.

20090326-POM002      TJR      Added code to populate &wild variable

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 =:",      &OPRID, &OPRID, &EXISTS);
       If None(&EXISTS) Then
          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: 7/5/2012                                                                       Page 20 of 20

								
To top