Actions and Employee Self Service Munis: Human Resources

Transcription

1 [MU-HR-5-A] Actions and Employee Self Service Munis: Human Resources CLASS DESCRIPTION This session will explore the Personnel Actions entry module, how to create personnel actions, managing personnel actions, and different setup options. The different posting options and numerous reporting tools will also be discussed. The session will explore how to set up Employee Self Service to allow employees to initiate their own personnel actions to accomplish common tasks: (i.e. name change, address change, dependent changes, etc.). The session will also explore the 3 main use cases for personnel actions: (New Hires, Terminations/Reinstatements, and Personnel File Changes) OVERVIEW The Personnel Actions Entry module is designed to aid in the data entry process by making changes in a timelier manner, allowing for a greater level of security, providing customizable workflow processes unique to the changes being entered, as well as provide a means of historical tracking and report functionality. All of these features combined should make Personnel Actions Entry the preferred method for most, if not all, employee related changes made within the Payroll / Human Resources module. Security Personnel Actions Entry provides added layers of security. Changes made in Employee Master, Employee Job/Salary, etc. affect LIVE payroll data directly and will immediately effect the payroll. Changes made directly in these programs are not subject to oversight or review nor are these changes subject to approval by authorized users prior to impacting the payroll. By utilizing Personnel Actions Entry as the method for making employee related changes a much higher level of control and oversight is gained, which will ultimately lead to fewer data entry errors and more accurate payroll processing. Timing If changes are made directly into the Employee data records (Employee Master, Job/Salary, etc.) those changes impact the payroll process immediately. Often, however, changes to employee data can be known in advance and do not take effect for weeks (employee promotions, pay increases, changes to benefits, etc.). The Payroll Generation process looks at the information that exists in the employee profile at the moment the process is run. If a change to an employee pay rate or deduction amount shouldn t take effect until some future payroll period these changes would need to wait until the Payroll department has completed processing on the last payroll that should use the OLD information. With Personnel Actions Entry, actions are entered with an effective date, thus allowing the opportunity get the information entered into the system the day the request is received or determined and have the changes posted to live once the effective date arrives. From a workload standpoint this allows for data entry tasks

2 to be dispersed more evenly rather than attempting to enter data within the payroll period in which it becomes effective. Efficiency (Decentralized Entry) With the addition of Employee Self Service initiated actions, the Personnel Actions Entry process offers several means by which data can be entered. Employees can initiate Personnel File changes directly from Employee Self Service which provides a much higher degree of accuracy since the changes being requested are being entered directly by the employee. Changes can also be entered into the Munis system by decentralized HR departments and routed and reviewed (using workflow) to ensure the changes are accurate and are appropriately entered based on the desired business practices. Workflow With multiple workflow rules that can be defined, different types of personnel actions can be routed based on the type of changes contained within the personnel action change package. Some personnel actions may require multiple reviewers and complicated workflow paths, while other simple changes (Address / Phone Number / Emergency Contact changes) may require far less oversight. Workflow can be used as a tool to notify users when pending changes have been entered and released for approval. Reporting Built in reports will provide quick access to pending changes being made within each personnel action. These reports can be run any number of times before the changes are finally posted updating LIVE payroll information. In addition to run-time reporting of changes currently pending, after a change is posted to the LIVE payroll information, the changes can be archived to the actions history program which can log a record for every personnel action that is created, approved, and posted. These historical records can be used as a reporting tool to help answer many various high level questions about historical changes made to a single employee, or on a broader scale to answer questions about hiring practices, termination practices, benefit changes, budgeting changes, etc. High Level overview of PA To fully understand the process of how the data is manipulated and maintained and how the pending changes can avoid impacting current payroll processing it is important to understand the process by which a Personnel Action is created. When a new Personnel Action is created, Munis makes a copy of all the data that can potentially be manipulated as part of the personnel actions data entry process and stores it separate from the data that is examined when running payroll processing. NOTE: Not all employee data is copied to the pending personnel actions, only data that is heavily maintained and would potentially impact payroll processing is copied to the separate set of data. This separate copy of data is typically referred to as the actions sandbox or the actions data set. This copy is what is being maintained during the data entry process within personnel actions entry. The live data set from which the data is copied will remain unchanged until the actions data set is posted and updates the live data that ultimately affects the payroll. 2

3 Below is a diagram that will hopefully make the process easier to understand from a visual perspective: 1.) Personnel Action is Started: This process can be initialized from several places within Munis. (Personnel Actions Entry, Salary Change programs, Employee Self Service, etc.). Creating a personnel action creates a copy of all employee related data that will potentially be modified during the employee data entry process. 2.) Personnel Actions Data (Copy of Live): At the very beginning of the personnel action processing, the data that exists in the actions data set (sandbox) and the data that exists in the live data set (data affecting payroll) will be identical. Changes made in the live data after the creation of the personnel action will not be reflected in the personnel actions data. Changes made to the personnel actions data set will not be reflected in the live data set, until posted this is intentional to provide a data entry process that is independent of the live payroll data. NOTE: Since changes made to live are potentially occurring at the same time that data is being entered into the personnel action, it is vital to ensure that changes that are being made in live do not adversely affect changes being made in the personnel action. Personnel Actions has processes to avoid data conflicts and resolve them in the most appropriate ways possible, however when a conflict arises and a choice is necessary to be made, the personnel actions data will always overwrite live data with data found in personnel actions data set. (See the Posting section for more details about conflict avoidance and resolution). 3.) Employee Data Entry: This is where the data changes to the employee profile can be made. Most of the data entry will occur using screens identical to the screens designed to maintain the live data set. (Please use caution to make sure changes are being made to the correct data set.) 4.) Employee Changes are Reviewed / Approved: This step in the process is where workflow rules are applied and notifications and approvals are entered to ensure data entry and business practices are adhered to properly. 5.) Output-Post: This is the final stage in the process where data changes are aggregated and conflict avoidance and conflict resolution occurs. Assuming changes are approved and posted to the live data set, actions history records can be created and changes will update live in a timely manner based on the effective date of the personnel action. 3

4 SETUP The Personnel Actions Entry module has several different setup processes that should all be carefully analyzed before implementing a naming / setup scheme. As with any implementation process making poor decisions during the initial design / setup process can cause future processing to become much more difficult and require significant effort to work around rising challenges and changes to the Personnel Actions module over time. Security and Permissions Security can be setup at the role level to control access to personnel actions. All of the same permissions that can be applied in the live data set, can be applied to the personnel actions data set. This allows existing permissions to be copied and applied directly to the personnel actions data set. This separation of permissions allows a user to be granted view only access (inquiry only) to the live data set, and update/delete access to the personnel actions data set. This would require that all changes that need to be entered would have to be entered through a personnel action where security and workflow rules are the strongest. LIVE DATASET ACTIONS DATASET The Role Maintenance program provides 5 distinct permissions that can restrict access to varying degrees of security. No Access: User will not be allowed to view any data in the program. In most cases the program directly associated with the category will cease to open. Update/Delete: User will have full access to add/update/delete records in the program directly associated with the category. 4

5 Hide SSN (Upd/Del): This permission behaves identically to the Update/Delete option, with the limitation that the SSN would be restricted from view. (See SSN Security Note below) Inquiry Only: This permission will allow the data to be viewed but not modified. This should be used for the Employee Master data set (Live) when all changes should be made through personnel actions entry. Hide SSN (Inquiry): This permission is the same as the inquiry only permission, but with the addition restriction that the SSN should also not be seen. NOTE: SSN Permissions should only be given to users who require access to maintain the SSN. Only users responsible for adding new employees are required to have access to the SSN in order to complete the new hire process. All other users are not required (from an application standpoint) to see or edit the SSN. In addition to role category permissions, data access permissions will also be adhered to when in the Personnel Actions Entry module. These restrictions can be defined to further decentralized access to specific employee data based on: Location, Deduction, Org code, and Pay Types. Applicant data restrictions are not applied within the Personnel Actions Entry module. Personnel Settings The Personnel Settings program has several parameters that can be set to control functionality within the Personnel Actions Entry module. While some of these settings uses may seem unclear at this point in the document, their purposes will hopefully make more sense as you review the remaining parts of this document. 5

6 Print Single PAF: This option is used when posting more than one action at a time. If multiple Employee Personnel Actions are being posted for multiple employees this will combine all the PAF (Personnel Action Forms) data into one single PAF file, rather than having one file per employee. Use Primary Job for Action History: When posting personnel actions and creating actions history, the job class and pay information that is stored on the actions history record can either be based on the job class of the pay records that are actually modified or always pulled from the employee s primary job class employee job / salary base pay. If more than one base pay is modified the primary job class will always be used, otherwise non-primary job classes can be reported if no other base pays are modified. This option once set, should not be modified to ensure consistent reporting methodology. Allow Actions Post to Projections: (New in 11.1): Traditional posting from a personnel action will post to the live data set. This is the primary purpose of a personnel action, to queue changes to later be posted to live. However, with recent modification requests we ve extended this capability to allow personnel actions to be posted to other data sets that exist within the Munis Payroll/HR system. This option enables the ability to post to salary and benefit projections that are currently assigned to the user running the personnel actions output post. The implications of this process are complex and would require a significantly long explanation far beyond what will be discussed in this document. Additional information can be found in the Munis Knowledgebase regarding this new process. Action Code Setup There are three distinct code files that are used in the identification of a personnel action and ultimately determine what workflow process the action uses, additional optional behaviors specific to the code 6

7 being used, how personnel actions are categorized for reporting, etc. As mentioned above, the setup of these codes should be carefully planned before implementing a code scheme. ACTION CODES The action codes program is the primary code based program that is used in the personnel actions entry module. This program controls the behavior of the primary action processing codes. The codes should remain as generic as possible. These codes are the only required code setup, though the additional codes discussed later will help to further elaborate on the meaning of codes setup in this program. Action Code: As mentioned above the code naming scheme should be carefully considered. This 4 character code will control the behavior of the action. Category: This category controls the behavior of the action, as well as the workflow process that is utilized. N New Hire actions will force the input of an employee that does not currently exist in the live data set. R Reinstatement will force the input of an employee that exists in the terminated data set being moved back to live. See below for more details regarding each category and any special behavior it provides. Short Description: This is a 10 character field that briefly describes the code. Long Description: This is a 30 character field that describes the code in more detail. NOTE: This description will appear on ESS for actions that can be submitted from ESS. Caution should be used when describing the action code since it will be visible by employees on ESS. Default Program: When a personnel action is created using personnel actions entry, a default program can be launched saving the user the trouble of having to navigate to that program to 7

8 perform data entry. This is especially useful when the only changes that are necessary for a given action code are found exclusively in one program. For example, address change, or direct deposit changes. Default On/Off Board: This code specifies the on-boarding/off-boarding code that will be associated and pre-populated when using the entered action code. Survey Code: This is the survey that will be generated as a result of posting the action. User will still have the option of whether the survey should be generated or sent. ESS Template: This option controls which ESS Template will be used when submitting action entry requests from Employee Self Service. (This will be discussed in detail further in this document). Attachment Type (11.2): As of 11.2, when attachments are added via Employee Self Service, the attachments will now be coded with a specific Attachment Type. These Types can be translated into TCM attachment types if TCM is being utilized. Civil Service Action: This checkbox will mark an actions as a Civil Service Action, which will provide a restricted data entry mode specific to Civil Service Employee tracking functionality. Print Personnel Form: This checkbox will control whether the action, when posted, will generate / be included in the Personnel Action Form (PAF). Action History Default: This checkbox will control whether the Creates Actions History checkbox will be checked on the Personnel Action. This can be overwritten during entry, this option simply defaults the checkbox on the Personnel Action when this code is used. Allow Job Change: This checkbox enables the Job Change menu option. This option does not prevent modifications to Employee Job/Salary or Employee Master in regards to the Employee s Job Class. Show Interviews: This checkbox controls whether the Interviews tab on Personnel Actions Entry is hidden or enabled. Show Replacement: This checkbox controls whether the Replacement tab on Personnel Actions Entry is hidden of enabled. Reset Workflow: This checkbox controls whether changes made within the personnel action, after the action is released to workflow, causes the workflow to be restarted. (NOTE: The workflow restart is initiated whenever the record is displayed or proof-posted.) Action Categories: Other than the code value and the description values, the category code is the only other required field. This field controls the main behavior of a code and each category has its own workflow business rule. The chart below will outline each of the categories as well as discuss the functional differences for each category. Category Description Business Rule Unique Functionality Typical Use Case A Attendance PMD None Used for years of service adjustments or accrual modifications. 8

9 B Benefit Change PMB None Used for changes to benefits. E Evaluation PMW - Generates Evaluation specific PAF Used for changes to evaluations. I Injury/Incident PMI None Used for changes made as a result of an injury, accident, or illness. L Leave PML N New Hire PMN - Evaluation Score, Leave Length, Return Date, and Impact Seniority fields are enabled on action header. - Return Date is a required field. - Generates New hire specific PAF. - Launches Condensed Employee Master as its default program. - Potentially generates a probationary evaluation. - Requires SSN and DOB permissions to complete. - New Hire must specify a new employee number. (Employees who exist in the Terminated data set will require R category). Used to record when an employee will be out of work for extended leave. (FMLA, Military, Injury, etc.) Used when hiring / adding new employees. O Other PMO None Typically used when making demographic changes. (Name, address, phones, etc.) Namely when changes need to be made that don t fall under any other category. R Reinstatement PME - (For Employees already Terminated) Data is initially copied from the terminated data set. Used to re-hire or reinstate an employee 9

10 - (For Employees already Terminated) Data is updated in the terminated data set before being move back to the live data set during posting. - Launches Condensed Employee Master as its default program. - Potentially generates a probationary evaluation. - Can also be used for employees who have been Inactivated in Live. from the Terminated Employee file. S Salary Change PMS None Used when modifications are made to Employee Job/Salary. (Job Change, Transfer, COLA, stipends, etc.) T Terminate PMT - Causes accrual data to be printed on the PAF. Used for employee termination or separation. V Civil Service Validation PMV None Used for all actions relating to Civil Service Employee tracking. Action codes that use this category should also be marked as a civil service action. REASON / AUTHORIZATION CODES The Reason/Authorization codes are optional so far as Munis is concerned. They can certainly help to expand your Personnel Action Code schema to provide sufficient detail so that the action code itself describes fully the What and Why for each of the actions you perform. The biggest advantage to using Reason/Authorization codes in your coding schema is to allow you to define a more detailed workflow notification and approval chain. The Reason/Authorization can be specified as part of the workflow business rule which allows the personnel action to be routed to the appropriate user that needs to review and approve the data that is being changed in the personnel action. 10

11 These codes are 4 character alpha/numeric and should further explain the action code. Any Action Code and Action Reason/Authorization combination can be specified in personnel actions, based on this combination the action can be further defined to better explain what is being modified and why it s being modified. As shown above, the reason code can be specified as part of the workflow setup to help better route who should be notified and who is responsible for approving the changes being completed in the Personnel Actions module. 11

12 SUPPORTING ACTION CODES The Supporting Action field is optional. If it is used, it is used primarily to add an additional layer of description to a particular personal action. Unlike Personnel Action Codes or Reason/Authorization codes described above, there is no impact on Munis functionality or Workflow by using or not using these codes. Not all actions have to specify a support action code, some may specify a supporting action code, some may not. To set up these codes use the folder icon found to the right of the field or access Miscellaneous codes and select the code category ACT2 Personnel Supporting Action Code option from the list provided. Workflow Setup Once the action codes and supporting action code scheme has been defined, workflow business rules can be defined to further refine the approval process of personnel actions. 12

13 - If no workflow business rules are defined for a particular process, releasing the personnel action for approval will automatically set the personnel action to the approved state. This type of setup should only be used for processes that require little to no oversight. (Emergency Contact, or Phone number changes are common examples.) - If a workflow business rule exists for the specified category linked to the personnel action code being used, the workflow process will be initialized once the action has been released for approval. There are numerous factors that are taken into consideration and can be used to route personnel actions more efficiently to the appropriate users. Action Code / Action Category: The action code is linked to an action category. As specified in the table above, each action category has it s own workflow business rule. Group/BU: The Employee Master Group/BU code can be used to route workflow approvals. Authorization / Reason: The authorization / reason code can be specified on an action and specified on a workflow business rule to increase the routing capabilities of the approval process. Location (Ranges): The Employee Master location can be used to route approval. Ranges of Locations can also be specified. Job Class (Ranges): The Employee Master job class can be used to route approval. Ranges of job classes can also be specified. 13

14 G/L Org Code (Ranges): The Employee Master G/L Org Code can be used to route approval. Ranges of G/L Org Codes can also be specified. G/L Segment (Ranges): The Employee Master G/L Segement data can be used to route approval. Ranges of G/L Segment data can also be specified. The details on how to setup workflow business rules to meet specific needs for routing will not be discussed in detail here. There are numerous documents available on the Munis Knowledgebase to help guide the setup of these rules. PERSONNEL ACTIONS ENTRY After setting up the necessary codes and workflow options and examining and choosing which personnel settings to utilize, the Personnel Actions Entry module can be utilized to perform its basic functionality, providing an interface to make employee data changes without effecting live and while preserving history and providing adequate approval chains and oversight. All of the fields on the Personnel Action Entry record serve a purpose, some are more important than others. In this document the focus will be on the fields that have the most functionality and/or impact on 14

15 the processing of the personnel action. For a detailed explanation or use case of every field, please review documents found in the Munis Knowledgebase. Employee Number: This is the employee number of the existing employee, new employee, or old employee for which the action exists. New employee numbers can be assigned from the Control File, existing employee numbers can be specified, or terminated employee numbers can be specified. Effective Date: This is the date that the personnel action will be effective and potentially the date the action will be posted. While this date can be updated, it is strongly encouraged to remain unchanged. Changing the effective date of the action can have additional impact other than when the action is scheduled to be posted. Action Code: This is the code that drives the behavior of the action. It not only determines the action category, but the behavior of the action itself. (See above for further details about how this code drives the behavior of the personnel action.) Reason/Authorization: This code can also drive the behavior of the personnel action in regards to workflow. This code can also be used when leveraging the Personnel Actions Rapid Entry functionality that is not discussed explicitly in this document. (Again, documentation about this functionality can be found in the Munis Knowledgebase.) Supporting Action: This field has no functional use other than to further specify the nature of the changes being made as part of the action. Creates Actions History: This checkbox controls whether the action will generate a personnel actions history record when the action is posted. Employee Initiated: This checkbox controls whether the action was initiated by an employee from Employee Self Service. Action Category: This is a display only field that is specified in the Action Code setup program. Status: This field shows the workflow status of the personnel action. The field contains the valid workflow status options that exist for all other workflow enabled functionality. (Not Released, In Progress, Approved, On Hold, Rejected.) 15

16 Some action types may require entry on the Other tab though not generally required. As a rule, Munis will automatically populate the fields found in the Employee Info block using information currently defined for the employee this data is display only. Evaluation Score and Pay Off amount and Payoff Type may be filled but these fields are used for information purposes only and are completely optional. For Category L Leave actions, however, you will be required to provide information on Leave Length and Estimated Return. NOTE: If using the Seniority Calculator feature in Munis the Seniority Impact flag is vital to this functionality working properly. When running the calculator employee seniority can be impacted and the number of days between Effective Date and Estimated Return will be subtracted from an employee s seniority total when any leave actions exist for that employee within the dates you specify when running the Seniority Calculator program. Even if the feature is not being used, the field will still require input of an Estimated Return date but it will be used for informational purposes only. In most HR departments this is usually pretty important piece of information so being prompted to fill it is generally regarded as a good idea. 16

17 Menu Options Detail: This option will provide access to the Employee Detail menu from which programs that store information within the Personnel Actions module can be accessed. Output Post: This option starts the posting process for the selected personnel actions. This will be discussed in further detail later in this document. Projections Post: This option similar to output post, starts the posting process except posting to a salary and benefit projection data set for the selected personnel actions. This will not be discussed in further detail later in this document, for more information please refer to the Munis Knowledgebase. Dates: This option launches the employee dates maintenance program. This program is useful for viewing important dates as well as a quick interface for maintaining important dates in the employees profile without the need to navigate to the program that contains these dates. 17

18 Scheduled Post: This option provides an interface for scheduling the posting of personnel actions that have been workflow approved. This will be discussed in further detail later in this document. Create PAF: This option allows the PAF (Personnel Actions File) to be generated without the need to post the changes. This is a useful tool that can be used to generate custom reports. Release: This is the standard workflow release option and will initiate the workflow process for the current personnel actions entry record that is displayed. Rapid Entry: This option displays the personnel actions rapid entry screen where data edits can occur more seamlessly and occur in one central screen without the need to go to several Munis screens to maintain the data. This functionality however provides a far less robust data entry process and does not provide all the menu options that can be found in the various data entry programs within personnel actions entry module. Job Change: This function allows for a quick interface for moving an employee from one job to another job (or one position to another position). The interface requires very little information and can perform the necessary modifications to the Employee Job/Salary records as well as Employee Master. Pos/Bud Request: This option will launch the Position Budget request application and will attempt to find an associated position budget request based on the current personnel actions record being displayed. 18

19 EMPLOYEE SELF SERVICE ACTIONS ENTRY As of 11.1 Employee Self Service Actions Entry functionality was added to allow Employees to submit requests to change their own personnel file. Certain modules on Employee Self Service already supported the logic to generate a personnel action, this new functionality enhances that capability and provides a more direct process for creating personnel actions. The functionality requires that ESS templates be designed and assigned to personnel action codes. Action codes that have an ESS template defined will be visible from the ESS Actions Entry screen. Personnel Actions ESS Templates Templates can be added and maintained from the new ESS Action Entry Template program. This program allows for basic header text (which supports HTML encoding) and a set of data fields that will be exposed and allow the employee to make any necessary changes. Template Code: The code to identify the template. This code will be used in the action code program to link an action code to a template. 19

20 Description: This 30 character description will describe the template. This description does not appear on ESS it will only appear in the actions code program. Documentation: This field specifies and controls the behavior of attachments in Employee Self Service. Three options exist: None, Optional, Required. ESS Header Text: This text field is displayed at the top of the ESS template once the type of change is selected. Its purpose is to provide the employee with information about what can be changed, as well as any instructions on how to populate the data. Template Fields: This section defines the fields that are accessible as part of the template. Field Code: The Munis field that will be exposed. This will also be the name of the field on ESS if the ESS Display column is not defined. Required: This determines whether the field requires an entered value. ESS Display: This will be the field label used on ESS (if specified). ESS Default: If the field should have a specific defaulted value this value will be entered into the field if the employee leaves the field blank. ESS Interface The ESS interface for entering Personnel Actions must be enabled in the ESS Administration settings. By default this functionality is not enabled. Once enabled, the ESS Interface for entering personnel actions can be accessed by employees after logging into Employee Self Service and going to the Personal Information > Add/View Changes section of ESS. 20

21 Clicking on the Add a change option in the upper right hand corner will begin the process. Based on the action codes that have been associated with ESS Action Entry Templates, the list of action types on ESS may be short or long. In the case shown above, only five options are available. Once the requested action type is selected the fields for the selected template will be rendered on the screen. 21

22 The fields that are required are marked with an (*). If fields that are required are left blank and the form is attempted to be submitted a warning will be generated and prevent the submission of the change. In this particular instance an attachment was also required and caused a warning to be generated in addition to the First Name field being a required data entry field. Once the warnings have been corrected the form can be submitted and a personnel action is created. 22

23 The created personnel action is created, released for approval, and marked as employee initiated. The action code matches the selected action type in ESS. The effective date is entered as the date the request was made. This can be posted after the effective date if it is not approved in the same day, but a record of the day it was submitted is preserved. Once this action is approved by the necessary Munis user, it can be posted just like any other personnel actions record. An output post will show the changes that were requested from ESS. Once the action is posted the action will be visible by the employee in ESS as a historical profile change. 23

24 POSTING Regardless of how the actions is created or maintained the data will be required to be posted or deleted. Deleting the action simply removes the duplicate employee data and cleans up the actions entry record removes any record of the changes requested or entered. If the action is to be posted, the posting process can be run manually or can be run automatically from the Munis Scheduler. Both processes will review the actions for errors and build a change package to be applied to the live data set. The posting process does its best to avoid conflicts and resolve data conflicts in the most logical manner possible. While there are clear rules about how certain scenarios will be processed, it is important to understand how certain scenarios process its change package to better avoid potential data loss. Output Post As discussed through this process, no changes made through the use of Personnel Actions entry will impact LIVE data until the Output/Post process is completed on the pending action record. This process can be run manually on a single record or on a Find Set of multiple records. If any record within the find set has not yet been approved (Status not equal to Y-Approved) then none of the pending change records in the find set will post. The proof report showing data elements that will be changed if/when the approval to post is still generated but an error message indicating that one or more actions have not been approved will be displayed and none of the pending personnel actions will post. 24

25 Even if workflow approval errors are generated, the proof will still be generated and output. This will allow users to view the report to get a cleared picture about what fields have been modified, which records have been added, and which records have been removed. If multiple actions are being posted for multiple employees, the proof report is broken down by employee and then are grouped by the program in which changes were made (Employee Master, Employee Job/Salary, etc.). Scheduled Post The scheduled post process provides the ability to setup a scheduled output-post process for all approved actions up to a specific date (other setup options also exist, though this is the most common use case). 25

26 After clicking Accept on the screen above, Munis will launch the schedule settings page where you can define the timing and frequency of the process, the individuals to be notified and the printer or spool directory to receive the reports produced by the process. Refer to documentation available on the Knowledgebase for further details on use of the Munis scheduler, including maintenance and administrative tasks. Once this process is defined, Munis will automatically, in the background, at the specified time, using the defined parameters: 1. Look for any actions with an effective date less than or equal to (<=) today s date (or the date / date range specified). 2. Produce the standard proof reports indicating all actions to be posted and the individual data field changes (showing changed record specifics on what was changed, both Old and New) as well as showing any records added or deleted. 26

27 3. Post all actions that have been fully approved and, if checklists are included, have any required steps flagged as completed. Additional data checks are also performed before posting, any errors that are generated will halt the process and produce an error report / log. Current error checking and data validation checks that performed include: (Some of these checks are conditional based on control file settings or other setup parameters): a. Workflow Approval b. Checklist Completion c. Position Max FTE limits d. Credential Validation 4. Hold back all records that are not fully approved or have incomplete checklists and provide you a listing of those actions along with the reason they were not posted. The system will continue to try and post those actions on subsequent runs and if these situations are resolved, will post them as normal. Otherwise they ll be held back and included on the error listings until such time as those situations are resolved or those actions are deleted from the Pending Action file. ACTIONS HISTORY After actions are posted they potentially create history records (depending on the Creates Actions History checkbox). If the action creates history the data is stored and is accessible from the Actions History program. This history program will allow for searching and basic reporting. Advanced reporting options are available from the Actions History Reporting program. Actions History Records Actions History records are conditionally created and store basic information about the nature of the action, basic pay information about the employee at the time of the action, and some detailed history that allows access to the specific audited changes that took place during the posting of the action. In this sense all the data relating to the changes made to live are tracked in actions history. 27

28 Information from the personnel action record is joined with information from the Employee Master record to populate the main screen. The Employee Master data reflects all of the updated data values that would have been modified during the action. The Change History section of the screen will show all change packages that were applied to the Live data set. In this particular example only two changes were applied, but the change packages can contain numerous entries from numerous tables. Clicking on these rows will launch the Audit Inquiry program to help better understand the exact nature of the changes. The Pay tab contains information about the employee s primary base pay. (This can contain information from the base pay that is not the employee s primary job depending on personnel settings and the changes that were made within the personnel action.) The Civil Service and Other tabs contain information from the Civil Service tab of Employee Master, as well as the Other data tab from personnel actions entry. 28

29 Actions History Reporting Actions history reporting can be used to perform detailed reporting in a more robust manner. The options that exist in this program make finding specific trends or generating employee history tracking much simpler than attempting to find the data records in the actions history program. For a more detailed explanation of the capabilities of this program the Munis Knowledgebase should provide ample information. 29