CIVPRO SOP
MODERN DEFENSE CIVILIAN PERSONNEL DATA SYSTEM (MDCPDS)
14 DECEMBER 2000
STANDARD OPERATING PROCEDURES
DEPARTMENT OF THE ARMY
CIVILIAN PRODUCTIVITY REPORTING SYSTEM (CIVPRO)
MODERN DCPDS
TABLE OF CONTENTS
SECTION PAGE(S)
I. Introduction 3
ll. Processes and Responsibilities 3
A. Managers 3
B. CPACs 4
C. CPOCs
1. Inbox Mapping 5
2. Identification of Fill Actions 5
3. Event Codes 5
4. Exclusion Event Codes 5
5. Local Event Codes 6
6. Closure Edits 6
7. Pipeline Actions Special Event Codes 6
D. Office of DASA-CPP 6
III. Hold and Suspense Inboxes 7
IV. Adding/Viewing RPA Event Codes 7
V. CivPro Data Capture and Measurements 8
A. Fill Actions 8
B. Time-to-Fill Definition 8
C. Open Actions 8
D. Closed Actions 8
E. Exclusion Event Codes 8
F. Job Offer/Commit Dates - Noncompetitive Actions 9
G. Job Offer/Commit Dates - CivPro Default 9
VI. Appendices
A. Event Codes and Definitions
A-1 RPA Event Code Quick Reference Guide
A-2 RPA Event Code Definitions
A-3 RPA Pipeline Actions Special Event Codes
B. Modern System Appointment Family Codes
C. Nature of Action/Legal Authority Code (NOA/LAC) Definition
D. LAC Exceptions to Fill Action Count
E. Modern System Closure Edits
F. Maintaining RPA Event History
G. Obsolete Event Codes
H. Inbox Routing Identifier & Inbox Type Codes
I. Glossary of ACRONYMS
An on-line version of this plan is maintained on the Army's CPOL web site y.mil. This same site also has the downloadable version of this guide (MS Word).
NOTICE: This plan is updated continuously as needed.
I. INTRODUCTION
A. The Civilian Productivity Reporting System (CivPro) is the Department of the Army's official productivity reporting system for civilian personnel administration. The CivPro database captures workload data on core personnel functions such as classification, position management and staffing and recruiting. The CivPro also captures workload data on other personnel actions such as separations, performance appraisals and awards. The CivPro provides statistics that measure the efficiency, performance and workload of each Army regional Civilian Personnel Operations Center (CPOC) and Civilian Personnel Advisory Center (CPAC) in accomplishing designated functions and tasks to support civilian personnel management.
B. The CivPro database is derived from the Modern Defense Civilian Personnel Data System
(Modern DCPDS) Human Resources (HR) database on CPOC regional servers and the
Headquarters ACPERS (HQ ACPERS). The Requested Personnel Action (RPA)
application will be utilized to determine the reconciled quantity and timeliness for
recruitment and placement, classification, and other routine personnel actions submitted
and processed through Modern DCPDS. The HQ ACPERS will be utilized to provide data
on civilian personnel transactions, number of personnelist and serviced strength.
C. The CivPro provides pre-packaged reports displaying key performance indicators, and
other output from analytic applications delivered to the user's desktop from Web browsers
and Intranet or Internet connectivity. The CivPro data are used to monitor workload,
evaluate production capability, reengineer personnel administration processes and respond
to customer-oriented production questions.
II. PROCESSES AND RESPONSIBILITIES
A. Managers. Managers will initiate personnel action requests using the RPA
application process in the Modern DCPDS. From the RPA application Navigator
Window, managers will select the "Request for Personnel Action" process, then
select "Recruit/Fill, Establish Position, Review Position, Reassignment, Salary Change"
(or any of the other types of actions listed). Modern DCPDS does not include an “other”
category. For actions not covered in the RPA Navigator Menu, refer to the Modern DCPDS
Desk Guide or consult the servicing CPAC for assistance. The "Action Requested" data
field is automatically populated based on the action selected from the RPA Navigator Menu.
Managers will use the RPA "Notepad" function to provide position information.
B. CPACs. The CPACs will review RPAs for all relevant information necessary to
process the action (e.g., proposed duties or a classified job description, crediting
plan or career program request forms and other documents to explain and clarify
the requested action). CPACs will further review the RPA for the specific
information as described in CPOC criteria for submission of RPAs
(e.g., position title, pay plan, occupational series, grade, unit identification code
organization, geographical location of the position, TDA paragraph and
line number, and appropriation code). As necessary, CPACs will coordinate any
changes with management or the appropriate office before routing the
RPA to CPOC.
If a manager desires to make multiple selections from a referral list and has not
previously submitted the appropriate number of personnel action requests, additional RPAs
are required for each vacancy and selection. The CPAC will not extend job offers for
multiple selections made by managers until additional RPAs are received from the manager
and routed to the CPOC.
For fill action RPAs, the CPAC is responsible for providing CPOCs the following information
to support accurate and timely event code data capture:
(1) Date Career Program referral list requested.
(2) Date Career Program referral list received.
(3) Date referral list returned from manager.
NOTE: Date referral list returned is the date the CPAC received a signed or otherwise validated referral list through manual or electronic means.
(4) Date job offer made.
(5) Date job offer accepted.
(6) Date job offer declined.
(7) Date applicable clearance (security, credentialling, 180-day waiver, etc) process/ procedure/request initiated.
(8) Date applicable clearance (security, credentialling, 180-day waiver, etc) process/ procedure/request completed.
NOTE: CPACS will normally notify the CPOC within one working day after
receiving or establishing the applicable information.
C. CPOCs.
1. Inbox Mapping. CPOCs are responsible for ensuring that all user inbox names and
Group inbox names include approved mapping codes. See Appendix H for a description of the usage of mapping codes and a list of approved codes.
2. Identification of fill actions. Upon receipt, the CPOC will review the requested action to
determine if the action is in the “Appointment Family” (Appendix B) or meets the Nature of
Action Legal/Legal Authority Code (NOA/LAC) definition for a fill action (Appendix C).
If at any time during its life cycle, the CPOC determines that the request meets the
NOA/LAC or "Appointment Family" definition for fill actions, the CPOCs must enter Event
Code G07000 (“Fill Action”) from the Event History Window in the RPA.
3. Event Codes. CPOCs are responsible for maintaining accurate event code entries and
will review and regularly update the RPA Event Codes to reflect the status of the action (Appendix F). All mandatory Event Code entries (Appendix A-1, A-2) will normally be changed within one working day of an event occurrence or change in status of an event.
.
For fill action RPAs, the CPOC will receive the following event code data from the CPAC:
(1) Date Career Program referral list requested.
(2) Date Career Program referral list received.
(3) Date referral list returned from manager.
NOTE: Date referral list returned is the date the CPAC received a signed or otherwise validated referral list through manual or electronic means.
(4) Date job offer made.
(5) Date job offer accepted.
(6) Date job offer declined.
(7) Date applicable clearance (security, credentialling, 180-day waiver, etc) process/ procedure/request initiated.
(8) Date applicable clearance (security, credentialling, 180-day waiver, etc) process/ procedure/request completed
4. Exclusion Event Codes. CPOCs will be required to provide an explanation for each use of the bypass edit/RPA counted for productivity event code. (See Para V.E.)
5. Local Event Codes. CPOCs may develop local event codes. CAUTION: Local event codes are fully subject to closure edits (Appendix E). The guidelines for establishing local event codes are as follows:
(1) All local event codes must begin with the letter "L".
(2) The local event code can be associated with the General (G), Classification (C) or
Staffing (S) categories.
(3) Recommend the second letter of the local event code correspond with the associated
General, Classification or Staffing category (e.g., LS2500 - OPF requested)
(4) No local event code can supercede the use of or conflict with a mandatory event
code (i.e., CPOCs cannot establish an LS1600015 - Job Offer PPP or an LS14000 -
Fourth Referral List).
6. Closure Edits. The Modern DCPDS productivity functionality is programmed with
productivity edits to ensure that event tracking data are accurate. Productivity
edits are invoked whenever the “Update HR” function is performed and
(1) the RPA’s action requested is in the “appointment family” (Appendix B) or
(2) the RPA’s data includes event code G07000 (“Fill Action”).
There are two types of edits, Mandatory and Warning (Appendix E.) Failing an edit means
the event tracking data (i.e., the event records) associated with the RPA are incomplete or
incorrect. Mandatory edits must be corrected before the database can be updated (i.e.,
before the RPA can be consummated). Warning edits are provided as a user notification
but will not prevent the action from updating the database. If no edits fail, the action should
update the HR database normally.
7. Pipeline Actions Special Event Codes. Pipeline action special event codes have
been developed to capture productivity data on personnel actions during initial Modern
DCPDS deployment procedures (See Appendix A-3).
D. Office of the Deputy Assistant Secretary of the Army (Civilian Personnel Policy) (ODASA-CPP). The ODASA(CPP) will develop, modify, program and maintain
CivPro, with the exception of local event codes. The ODASA-CPP will retrieve productivity data from automated systems, post data on CivPro and monitor data quality. The Program Support Division will execute a monthly production data pull on the first weekend following the end of the month.
III HOLD AND SUSPENSE INBOXES
A. Hold Group Inboxes. Hold group inboxes will be used to hold RPAs that
cannot be worked on because they are out of the control of the CPOC [e.g.,
Reduction In Force (RIF), PPP qualification issue, referral list issued to
managers(waiting for selection)]. Normally actions will not be held in a hold group
inbox for more than 30 days, except when being held for RIF. Use of the hold group
inbox is optional. Hold Group Inbox time will be reported in CivPro calculations.
NOTE: HOLD BOX TIME CONTINUES TO COUNT UNTIL ACTION IS CLOSED.
Actions routed to a hold inbox for RIF purposes must have a "Hold for RIF" event code
entry. While use of the hold inbox is optional, use of the event code “Hold for RIF” is
mandatory.
B. Suspense Group Inbox. Suspense group inboxes will be used to hold RPAs with
name social security number, and effective dates confirmed. The suspense group
inbox will be used for the following, but not all inclusive, actions: pending
resignations, termination of LWOP, career promotion received in advance of
effective date. Use of the suspense group inbox is optional.
IV ADDING/VIEWING EVENT CODES
A. MANAGERS – Managers can view event codes for an RPA if the RPA has ever
been in their inbox. Managers may not add or change event codes.
B. CPACS – CPACs can view event codes for an RPA if the RPA has ever been in
their inbox. CPAC users may not add or change event codes.
C. CPOCS – CPOC staff (usually classification or staffing) are responsible for adding and
maintaining event codes. The only user who can update (add or modify) event tracking
information is the CPOC user who currently has the RPA as an “open” action (i.e., the
action is in that user's inbox). CPOC users are identified as any user with a user
name that includes a routing identifier code that begins with "CO" (ex: John. Smith/COF)
(See Appendix H for a complete listing of Inbox Routing Identifier & Inbox Type Codes).
The data is "read only" for all others.
V CIVPRO DATA CAPTURE AND MEASUREMENTS
A. Fill Actions. Fill actions are defined by Natures of Action and Legal Authority Codes as shown at Appendix C.
B. Time-to-Fill Definition. Average number of calendar days to fill positions from the date the action enters the personnel community (CPAC, CPOC or CPO) until the date offer is accepted (committed). This definition is used in CivPro. Time-to-fill data is based on closed actions.
C. Open actions. CivPro also measures productivity on open actions including counts of the number of actions received, number of actions on hand and average age of open actions.
IMPORTANT: Open actions are identified exclusively by the G07000 (“Fill Action”) event code in the RPA's data, not by the presence or absence of NOA/LAC.
D. Closed actions. The NOA/LAC definition will be used to capture and measure productivity for all closed actions time-to-fill data.
IMPORTANT: Closed fill actions are identified exclusively by specific NOAs/LACs, as listed in Appendix C, not by the presence (or absence) of a G07000 ("Fill Action") event code.
E. Exclusion Event Codes: The exclusion event codes X01000 and X02000 (Appendix A-1, A-2) will only be used in cases of productivity anomalies caused by Modern DCPDS HR requirements or by mandated personnel actions that adversely impact our productivity data capture.
X01000 - bypass edits/RPA not counted for productivity.
The closure edits will not trigger and the RPA will not be counted for productivity purposes. Examples for appropriate use of this event code include (1) higher headquarters directed use of a NOA/LAC combination (See App C) but the action processed is not truly filling a vacant position (i.e., the use of 570/UAM to convert CIPMS employees from GS to GG), (2) certain 911 DoD Reconstruct actions and (3) corrections of effective dates when the RPA was created because modern system correction protocol prohibits correction of an effective date to a date earlier than the original effective date.
X02000 - bypass edits/RPA counted for productivity.
The closure edits will not trigger, but the RPA will be counted for productivity purposes. Use of this event code must be documented. Use of this event code should be very limited. Appropriate uses for this event code include (1) those processing an RPA created to replace a RPA when the Update HR function did not consummate the original action and the original RPA was cancelled or (2) RPAs created as a result of a decision or order or settlement agreement reached under third party procedures outlined in Chapter 32, The Guide to Processing Personnel Actions. A monthly quality control report will capture data on use of this event code. CPOCs will be required to provide an explanation for each use of the bypass edit/count for productivity event code.