BP080OSSFutureProcessModelv3 0
BP080OSSFutureProcessModelv3 0
BP080OSSFutureProcessModelv3 0
Document Control
Change Record
4
Author Oracle Consulting Mark Price Mark Price Mark Price Glyn East Mark Price
Version
Change Reference No Previous Document Baseline version Added Payroll Information Issued Updated Payroll information - Issued Included AR, updated after Build Stage 1 - Issued
Reviewers
Position Oracle Solution Architect Business Processes Lead, HR and Payroll Business Processes Lead, Finance
Distribution
Copy No. 1 2 3 4
Location Project Library Oracle Project Manager OSS Business Solution Project Managers
Note To Holders: If you receive an electronic copy of this document and print it out, please write your name on the equivalent of the cover page, for document control purposes. If you receive a hard copy of this document, please write your name on the front cover, for document control purposes.
File Ref: BP080 OSS Future Process Model v3.0.doc (v. 3.0) Company Confidential - For internal use only
Page ii
Contents
Document Control ................................................................................................................ ii Introduction........................................................................................................................... 5 Chart of Accounts ................................................................................................................. 6 Multiple Organisations ........................................................................................................ 7 Sets of Books .......................................................................................................................... 8 Accounting to Financial Reports ........................................................................................ 9 Subledger Journals to Post ........................................................................................... 9 Budgets to Approval ................................................................................................... 10 Taxation......................................................................................................................... 18 Period End Close to Financial Reports ..................................................................... 19 Receipt to Assets .......................................................................................................... 20 Assets to Depreciation ................................................................................................ 24 Bank Statement to Reconciliation .............................................................................. 28 Credit to Cash............................................................................................................... 29 Statement to Collections ............................................................................................. 31 Project Costing .................................................................................................................... 33 Plan to Project Budget................................................................................................. 33 Execution to Asset ....................................................................................................... 37 Analysis to Closure ..................................................................................................... 45 Human Resources............................................................................................................... 47 HRMS Foundation....................................................................................................... 47 Recruitment .................................................................................................................. 52 Learning Management................................................................................................ 58 Performance Management ......................................................................................... 64 Occupational Health & Safety.................................................................................... 68 Workers Compensation .............................................................................................. 77 Workplace Equity and Dispute Resolution ............................................................. 82 Procure to Pay ..................................................................................................................... 85 Requisition to Receipt Direct for Procurement..................................................... 85 Catalog Setup to Management................................................................................... 87 Click to Requisition ..................................................................................................... 88 Requisition to Receipt Indirect for Procurement.................................................. 89 Requisition to Receipt Indirect for Accounting .................................................... 91 Supplier Invoice to Payment...................................................................................... 94 Supplier Return to Debit............................................................................................. 96 Supplier Return to Replacement ............................................................................... 97 Payroll .................................................................................................................................. 98 Time Collection to Payroll.......................................................................................... 98
File Ref: BP080 OSS Future Process Model v3.0.doc (v. 3.0) Company Confidential - For internal use only Page iii
Payroll to Payment ...................................................................................................... 99 Payroll Awards Structure......................................................................................... 100 Grade Step Progression ............................................................................................ 103 Manage Employee Payroll Data .............................................................................. 104 Overpayments............................................................................................................ 105 Salary Packaging........................................................................................................ 106 Multiple Assignments............................................................................................... 109 Year End Processing.................................................................................................. 112 Termination to Payroll .............................................................................................. 113 Absence to Payroll ..................................................................................................... 114 Open and Closed Issues for this Deliverable ................................................................ 117 Open Issues................................................................................................................. 117 Closed Issues .............................................................................................................. 117
File Ref: BP080 OSS Future Process Model v3.0.doc (v. 3.0) Company Confidential - For internal use only
Page iv
Introduction
The document serves as a summary of the results of the Conference Room Pilot (CRP 2.2) and details all business flow diagrams developed during this process. Conference Room Pilots workshops were conducted for the following business flows Accounting to Financial Reports Procure to Pay Human Resources Credit to Collections Project Costing
Conference Room Pilot 2.2 focused more on the underlying details below the standard Oracle Business Flows to draw out detailed requirements and to give the teams a consistent methodology for capturing this data. As such, teams were asked to consider the following topics during the Conference Room Pilot workshops for each of the detailed flows: Interfaces Data Migration Security Integration Touchpoints Documents attributable to the process Reports Portal Requirements Additional Setup requirements Workflows Templates Other Requirements This document summarises the detailed business process flows developed during this period, as well as a overview of each process.
Page 5 of 117
Chart of Accounts
The Chart of Account (Accounting Key Flexfield) structure forms the foundation for all Oracle Applications with an accounting impact. It is used to record accounting transactions, balances and to perform financial reporting. The chart of account structure may contain up to a maximum of 30 segments however, such a large number of segments is not recommended. Typically, a chart of account structure containing approx 4-8 segments is generally sufficient for financial reporting purposes. Design Council has signed off the Chart of Account Framework. The following Accounting Flexfield structure will be configured within the applications moving forward.
No. 1 2 3 4 5 6 Segment Name Entity Cost Centre Account Fund Project Agency Defined Example Length 3 7 6 3 8 6
Page 6 of 117
Multiple Organisations
The diagram below depicts the CRP 2.2 multi-org structure based on the Design Statement of Works document. This forms the foundation for the proposed structure within the Oracle Applications but does not represent the final solution.
Page 7 of 117
Sets of Books
Within the Oracle Applications, the set of books is considered to be the highest level for financial reporting. It partitions and secures GL accounting information such as journal entries and account balances and is defined by:1. 2. 3. Calendar Currency Chart of Accounts
To determine the need for a multicompany organisation structure, and therefore multiple sets of books, it is necessary to understand the financial information for each agency. You need multiple sets of books if one of the following is true: You have agencies that require different Chart of Account structures to record information about transactions and balances. At this stage, the proposed solution will have a single chart of account structure to be used for all entities. You have agencies that use different accounting calendars. The proposed solution will have a single calendar (1 July 30 June) with 12 monthly periods and one adjusting period for year-end finalisation of accounts. You have agencies that require different functional/base currencies and report in another base currency
Page 8 of 117
Page 9 of 117
Budgets to Approval
Process Summary For the Whole of Government (WoG), agencies are responsible for the development of their budgets, complying with all Department of Treasury and Finance (DTF) budgeting requirements and deadlines. The Office of Shared Service (OSS) is responsible for managing the Oracle Financial Analyser (OFA) as the WoG Budget tool, developing and maintaining common templates within the system. As the discipline of budgeting and forecasting is agency-specific, budget data prepared in OFA with be developed using differing types of budgetary techniques, including Top Down, Bottom Up, Zero-Based and Marginal. In addition, agencies may have their own budgeting criteria, or budgeting perspectives for modeling their budget. External data or non-financial
BP080 OSS Future Process Model v3.0.doc Company Confidential Page 10 of 117
data may need to be loaded into budgeting system for such purpose. For example, FTE rate for each agency is needed from HR system for FTE costs budgeting. During the budgeting cycle, there is a budget approval processes within each agency to review and approve the budget submitted from subordinated budget users. This process may be repeated several times until the budget data is approved and finalized. Once this process is completed the Agency is responsible for: Submitting the approved budget data to the shared data set, held by the Office of Shared Service (OSS), for uploading into the General Ledger; Producing operating and capital budget submissions for DTF and uploading adjustments in the Adjustment Tracking Module (ATM) of Treasury Information Management System (TIMS).
Timely budget data submission and uploads are essential for up-to-dated information required to support financial reporting and analysis. Descriptive Overview of Budgeting & Forecasting Oracle Financial Analyzer (OFA) allows all people with budget responsibilities within an agency to have direct access to the system. Line Managers will be able to prepare budgets and submit their budget information directly into the OFA budgeting system for consolidation, analysis, review and approval. Within each agency, there is an internal review and approval process during the budgeting cycle. Management at differing levels will review the budget data submitted by subordinates, then approve or reject the budget data. Once the budget is finalized the agency will submit the data to the shared data set, maintained by OSS, for upload into the general ledger. Additional data files will also be generated by the Agency for upload into the ATM of TIMS, satisfying DTF budgetary requirements.
Process Flow
Page 11 of 117
The diagram above depicts the processes of extracting information from the General ledger to OFA and the development and maintenance of budget templates in OFA. The Oracle Applications General Ledger Super User and OFA Super Administrator in OSS are responsible for these processes. This process starts with extraction of CoA structures and financial data from the GL to OFA. The standardised GL Link for integration between Oracle General Ledger (OGL) and OFA, allows for Chart of Account (CoA) information and financial data balances to be extracted and loaded into OFA, as required for purpose of budget development and forecasting. Once the extraction from GL is complete, using the OFA loading processes the data is loaded into the shared database by the OFA super administrator. From the GL update, OSS budget team members are able to revise existing templates or develop new budgeting templates within OFA. These budgeting templates are then distributed within OFA for Agency use.
Page 12 of 117
The process of budget development is agency specific. Budget data prepared in OFA can be developed using differing types of budgetary techniques, including Top Down, Bottom Up, Zero-Based and Marginal. A majority of Agencies develop their budgets using a bottom up approach. Data is developed at a lower level, such as individual cost centre, program or activity. Analysis of the budget can be performed a number of ways, from the traditional organisational structure to business oriented budgeting. As an agency budget data will be consolidated within OFA, reports can be generated from the system to effectively analysis this data. For example, analysing the comparison between the developed budget to budget targets. To facilitate budget development by Agencies, external data can be loaded into OFA. For example the Public Service Award rates for Travel. This external data can be loaded at the OFA Super Administrator level and then shared across Agencies.
The diagram above depicts the internal budget approval process within each agency. Within the OFA system architecture, data for each agency is stored and managed in a centralised shared database.
Page 13 of 117
When Line Managers have finalised entering their budget data into Budget templates, they will need to update an approval log in OFA. This is to provide information on budget status and budgets that require review and approval. An OFA report on this approval log can be generated and published to the portal page for review by the Agencys Budgeting Officers and Approvers of the submitted budgets. The Approvers of submitted budgets will be required to log into the OFA system to review the budgets. After the budget data is reviewed, the budget will either be approved or rejected. The budget status will then have to be updated in the approval log. If the budget is rejected and requires additional work this will also have to be indicated in the log with a reason.
For budget data to be upload into the General Ledger module for reporting and analysis, an Agencys approved budget needs to be submitted to OSS shared data set. The diagram above depicts the process for submitting a budget from an Agency to the OSS shared data set. Agencies are required to freeze the budget data to ensure that no further updates occur to the approved budget. The Agency Administrator submits the approved budget into the shared dataset at the agency level. This process is required to align the budget to the CoA structure within the General Ledger. The Agency Administrator submits the shared dataset controlled by the Agency to the shared dataset controlled by the OSS.
Page 14 of 117
The process flow diagram above depicts the main tasks involved in importing the approved budget data from OFA into the GL system. This write back process will commerce after agencies have submitted their finalized approved budget to the OSS shared data set. Using the standard OFA-GL Link set up, the OFA super administrator in OSS will submit the data write back to the GL. This data will be written back to specific budgets defined in the GL. During the write back process, CoA account combinations for the budget data will be created in GL. As part of this process it is necessary to maintain the budget organisations, after the budget write back to the GL, to ensure that the new combination are assigned to a budget organisation. After this write back process is competed, standard reports can be generated or a FSG reports can be created by Agencies as a means of validating the loaded budget.
Page 15 of 117
OFA standard functionality allows for the process of developing and planning budgets data to be Agency specific. For examples differing budgetary approaches with can be taken are: Target budgeting using a top-down approach. In this technique budget data is entered at a high level and driven down to cost centres. Cost centre Managers then provide the relevant detailed budget information and align their programs to the allocated budget target. Bottom up approach. For this technique Line Managers develop their budgets based on the Agency objectives at a detailed Project or Cost Center. To assist with the formulation of an Agencys budget, WoG and Agency specific budget models can be developed within OFA. This modeling can includes the use of budgeting rate tables for budget planning and where necessary the upload external data via flat files to assist with this process.
Agencies are required to load their approved budget into the Adjustment Tracking Module (ATM) of Treasury Information Management System (TIMS). This is a Department of Treasury and Finance (DTF) budgetary requirement. The diagram above depicts this process. To allow for budget data to be uploaded into the ATM of TIMS in the correct format, several mapping tables will be defined within OFA. The first mapping sequence will map the GL CoA accounts to the TIMS accounts. This mapping table will allow several GL accounts to be mapped into a single TIMS account. This table is populated during data loading. The second mapping sequence will map the TIMS accounts to the Counter Party Identifier (CPID). Most Accounts can be mapped to a single CPID. However for accounts that have to be mapped to several CPID, the amount for these accounts can be split based on a ratio defined by each agency. The Agency Administrator will be required to review and adjust the mapping prior to exporting the budget data. The Agency Administrator will submit a task to export budget data from OFA after reviewing all of the mapped information in their shared database. The text files generated will be used for uploading into the ATM of the TIMS system.
Page 16 of 117
For Agencies using the Oracle Project Costing Module, project budgets developed within OFA will need to be interfaced back to the Project Costing for reporting purposes. The diagram above depicts this process. In order to facilitate the process, the budget within OFA has to be consolidated at an Agency level. A mapping table will be used to correlate the projects defined within Project costing against the projects defined within OFA. Agencies will be responsible for reviewing and updating the mapping table prior to generating the data files from within OFA. Once completed, Agencies will need to submit a task to export the budget data from OFA into a text file format for uploading into the Project Costing module.
All variance analysis reporting will be performed out of the General Ledger module. Users will be provided access to run reports from either the core application or by running reports using Oracle Report Manager. The later has functionality for publishing reports to the portal page.
BP080 OSS Future Process Model v3.0.doc Company Confidential Page 17 of 117
Variations can occur by: Incorrect coding of expenditure Unplanned expenditure Delays in posting expenditure Delays in Agency programs Incorrect budget amounts established. Variations to expenditure if proven can be corrected by completing a journal using the Web ADI functionality. amendments to budget are performed within OFA and an updated Budget will be uploaded to the GL. All
Taxation
Process Summary The Taxation (GST Reporting) business flow consists of three stages. 1. 2. 3. GST Governance: Ad Hoc compliance checks during the processing period. BAS Reconciliation: Reconciliation of BAS as per ASG/ASSIST GST Toolkit recommended methodology. BAS Lodgement: OSS and Agencies review of BAS and subsequent OSS lodgement of BAS returns.
Process Flow
Page 18 of 117
Process Flow
Page 19 of 117
Receipt to Assets
Process Summary
Receipt to Assets business flow demonstrates the business processes for recording fixed assets. This flow enables users to manually enter assets, transfer invoice lines marked as assets in accounts payable as Mass Additions to Oracle Assets, transfer capitalizations from Oracle projects, and use ADI and/or WebADI to upload Asset lines from other sources thru Excel worksheet. This also allows exporting of Asset information into a file than can be sent to 3rd party systems.
Process Flow
Page 20 of 117
Page 21 of 117
Page 22 of 117
Page 23 of 117
Assets to Depreciation
Process Summary
The Assets to Depreciation business flow demonstrates the business processes for maintaining fixed assets and calculating depreciation. This flow enables users to perform maintenance for individual assets or a range of assets. The business flow also covers recording of physical inventory, transfer, reclassification, adjustment, revaluation, retirement and calculation of future depreciation expense. Agencies use iAssets to raise and accept requests for transfer. Again this flow shows the usefulness of webADI in entering transactions as manifested in processing stocktake and dataloader in Asset Revaluation.
Process Flow
Page 24 of 117
Page 25 of 117
Page 26 of 117
Page 27 of 117
Process Flow
Page 28 of 117
Credit to Cash
Process Summary Credit Approval to Customer
As part of the Credit Management process, there is a need to ensure that customers credit limits are set up. The end user can set up credit limits while creating the customer information, or update it at a later stage. Based on an analysis of the history of the customer, statements, collections, past due and aging, the credit limits may be changed. The fields act only as reference data fields unless Order Management is used to raise sales orders and invoices there from. Order Management is not in scope for the detailed design and build/test stages of this implementation.
Process Flow
Page 29 of 117
Process Flow
Page 30 of 117
Process Flow
Statement to Collections
Process Summary
As per the business requirements of the agencies and OSS, reminders need to be sent to the customer when the invoices remain unpaid beyond the due date. In case of delay in payment, collecting officers would initiate collection activities, that need to be recorded. In a few cases, customers are assigned to debt collection agencies and debt recovery charges are incurred. Also, disputes may be raised by the customers, which need to go through a process of approvals, if they are to be converted into credit memos. OSS would like to have the capability of creating and sending statements if and when required.
Page 31 of 117
Process Flow
Page 32 of 117
Project Costing
Plan to Project Budget
Process Summary
Plan to Project Budget demonstrates the business process flow covering the creation and maintenance of a project, as well as, the addition and maintenance of a budget of a project. This sub-flow supports the manual entry of projects into the Oracle Application and the interaction with OFA for the creation of an initial budget. In addition the sub-flow also supports the maintenance of both the project details and the supporting project budget. Processes identified as being conducted within the Agency environment, on occasion, may in fact be conducted within the Shared Service Centre. This event arises when the Agency concerned is deemed a light project user, and has a SLA agreement with the OSS. This occurs when the Agency may not have all of the required knowledge or access to support the entry and maintenance of both the project and budget.
Process Flow
OSS Draft Future Business Flow : Plan to Project Budget External Project Management
Enterprise Roles OSS Project Manager Agency Approver
PM5801 PM5801
Extract & Extract & Maintain Maintain Project Plan Project Plan
Project manager maintains the work plan for the project.
Yes
PM5802 PM5802
Select Project Select Project Template & Work Template & Work Breakdown Structure Breakdown Structure
PM selects appropriate project template which defines work breakdown structure
PM5819 PM5819
Projects, Financials
Project Budgeting
PM5840 PM5840 PM5827 PM5827 PM5841 PM5841 PM5828 PM5828
Projects
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Page 33 of 117
PM5815.1 PM5815.1
PM5815.2 PM5815.2
Yes
No
No
Yes
PM5815.3 PM5815.3
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Select project template and work breakdown structure demonstrates the business flow covering the initiation of the project creation cycle. This process identifies the project template required to be used for the creation of a project. It also highlights if a suitable template is available, to satisfy the Agencies requirement for creation of a project.
OSS Draft Future Business Flow : Define Project Details PM5818
PM5818.1 PM5818.1
No
No
Yes
Yes
PM5818.2 PM5818.2
Yes
No
PM5818.3 PM5818.3
Yes
No
PM5818.4 PM5818.4
Yes
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
The define project details flow demonstrates the business process flow covering the population of project related details, for newly created projects. This flow also takes into account that under certain circumstances the details required for a newly created project may not exist within the template structures.
BP080 OSS Future Process Model v3.0.doc Company Confidential Page 34 of 117
In addition, this flow identifies if the existing templates are suitable for the project, or if changes are required to project template(s), to support a shift in the Agency business requirements.
OSS Draft Future Business Flow : Define Project Details PM5819
PM5819.1 PM5819.1
Identified Identified Need to Need to Amend Amend Project Details Project Details
PM5819.2 PM5819.2
No
No
Yes
PM5819.3 PM5819.3
Yes
No
PM5819.2 PM5819.2
Yes
Yes
No
PM5819.3 PM5819.3
No
Yes
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
The Maintain Project Details flow demonstrates the business process flow covering the maintenance of project related details, for created projects. In addition, this flow identifies if the existing templates are suitable for the project, or if changes are required to project template(s), to support a shift in the Agency business requirements.
OSS Draft Future Business Flow : Approve Project PM5824
PM5824.1 PM5824.1
No
Yes
No
PM5824.2 PM5824.2
PM5824.4 PM5824.4
PM5824.5 PM5824.5
Approved ?
Yes
PM5824.3 PM5824.3
Execution to Asset
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Project Approval demonstrates the business process flow covering the approval of a created project, enabling the project to incur expenditure.
Page 35 of 117
This sub flow supports the use of a project approval workflow, in the event that the Agency has created and approved the project. Under certain circumstances the Agency may have a SLA with the OSS, which requires the OSS to act as an agent and create the project, on behalf of the agency. In this case where the project is deemed to be pre-approved a workflow is not invoked.
OSS Draft Future Business Flow : Import Project Budget PM5827
Execution to Asset
PM5827.1 PM5827.1
Load Successful
Yes
No
PM5827.3 PM5827.3
PM5827.2 PM5827.2
Yes
No
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Import Project Budget demonstrates the business process flow covering the adoption of an initial project budget. OFA is deemed to be OSS budgeting tool and as such is the source of approved project budgets in the first instance.
OSS Draft Future Business Flow : Maintain Project Budget PM5827
PM5828.1 PM5828.1 PM5828.2 PM5828.2 PM5828.3 PM5828.3 PM5828.4 PM5828.4
Identified Identified Need to Need to Amend Amend Project Budget Project Budget
No
Yes
PM5828.8 PM5828.8 PM5828.7 PM5828.7
Yes
PM5828.5 PM5828.5
No
No
Approved
No
PM5828.9 PM5828.9 PM5828.6 PM5828.6
Advise Advise Agency of Agency of Budget Change Budget Change Completed Completed
Identify Required Identify Required Correction for Correction for Rejection Rejection Reason Reason
Yes
Maintain Project Details
PM5828.10 PM5828.10
No Correct
OFA Budget Tool Execution To Asset
Yes
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Page 36 of 117
Maintain Project Budget demonstrates the business process flow covering the amendment and alteration of a project budget. Initial budgets are loaded from OFA, using the PM5827 Import Project Budget process, however changes to project budgets are identified and processed using this business flow. Where project budgets have been amended within the PA application the process includes a workflow process to approve any budget changes. The budgets held against projects provide a reporting aspect only and are not used for any encumbrance or expenditure checking. Where budgets are altered within PA, the change is uploaded to the OFA tool to enable the change to be effected within the GL.
Execution to Asset
Process Summary
Project Execution to Asset process flow demonstrates the business process flow covering the creation and maintenance of expenditure transactions, as well as the passing of costed expenditures to the Oracle Fixed Assets application. The sub flow supports the manual entry of expenditure batches, processing of integrated transactions and the interface of asset and financial data to Oracle Fixed Assets. The OSS operates in an agent capacity and is responsible solely for the processing of data in a timely manner, on behalf of the Agency. The high level flow below is identified in more specific details below.
Process Flow
OSS D raft Future Business Flow : Project Execution to Asset
Project Expenditures
PM 5857 PM5857 PM5848 PM 5848 PM 5851 P M5851
Ma nage Ma nage Project Project Com m itm ents Com m itm ents
Create project r elated purch as e requisition an d purch as e orders.
PM5862 PM 5862
Process Project Process Project Supp lier Supp lier Invo ice Invo ice E xpe nd itures E xpe nd itures
Su pplier invoic es m atch ed an d proc ess ed in O S S..
PM5863 PM5863
PM5858 PM 5858
Ma nage Ma nage Project Project E xpe nd iture E xpe nd iture Adjustm ents` Adjustm ents`
Project m an ager reviews project ch arges an d advis es of nec ess ary adjustm ents.
Process Process Project Project E xpe nd iture E xpe nd iture Adjustm ents Adjustm ents
Project expen diture adjustm ents proc ess in O SS as r equired
Project Expenditures
PM 5860 PM5860 PM5864 P M5864 PM5865 PM 5865
Generate G enerate Fina ncia l l Fina ncia Tra nsactio ns Tra nsactio ns
Th e proc ess es required to gen er ate financial trans action to G en eral ledger are su bm itted.
P rojects, F inancials
Copyright 2005, Oracle C orporation. A ll rig hts reserved. A ugust 25, 2005 R elease 11i.10 Slide 1
Page 37 of 117
P M 5857.1 P M 5857.1
P M 5 857 .2 P M 5 857.2
P M 5857.3 P M 5857.3
Project Expe nd iture Project E xpe nd iture Source :: Source Labor Labor H ours H ours
Project Expe nd iture Project Expe nd iture Source :: Source Labor Labor C ost $ C ost $
Project E xpe nd iture P roject E xpe nd iture Source :: S ource Burde n C osts Burde n C osts
P M 5 857 .4 P M 5 857 .4
Project Expe nd iture Project Expe nd iture Source :: Source M isc. M isc. E xpe nd itures E xpe nd itures
Enterprise Roles O SS Agenc y M em ber Pr oject M anager PM 5857 Pr ocess Project Expen ditures
P M 5857.5 P M 5857.5
P M 58 57 .6 P M 5 857 .6
P M 58 57.7 P M 5 857 .7
Project E xpe nd iture Project E xpe nd iture Source :: Source Project Project Allocatio ns Allocatio ns
P roject Expe nd iture Project Expe nd iture S ource :: Source GL GL A llocatio ns A llocatio ns
P roject Expe nd iture Project Expe nd iture S ource :: Source U sage U sage Tra nsactio ns Tra nsactio ns
P M 58 57.8 P M 58 57.8
P roject Expe nd iture P roject Expe nd iture S ource :: S ource R eve nue S o urces R eve nue S o urces
C opyr ig ht 2005, O racle C orporation. A ll rig hts rese rved. A ug ust 25, 2005 R elease 11i.10 S lide 1
Process Project Expenditures demonstrates the business process flow covering the creation and maintenance of project related expenditures. The details provided show the numerous sources and transactions that may be incurred against a project. Each of these processes is described in detail and illustrated below, within a high level process identification. Specific reference should be made to each detailed flow.
No
P M 5857.1.1 P M 5857.1.1 P M 5857.1.2 P M 5857.1.2 P M 5857.1.3 P M 5857.1.3 P M 5857.1.4 P M 5857.1.4
Prepare Prepare Project Project R elated R elated Labor H ours Labor H ours
U pload U pload Project Project R elated R elated Labor H ours Labor H ours
R ejected R ecords
Yes
Ide ntify Ide ntify R eason R eason For For R ejection R ejection
P M 5857.1.8 P M 5857.1.8
P M 5857.1.7 P M 5857.1.7
P M 5857.1.5 P M 5857.1.5
Yes
No
P M 5857.1.6 P M 5857.1.6
C opyrig ht 2005, O racle C orporation. A ll rights rese rved. S eptem ber 2, 2005 R elease 11i.10 S lide 1
Page 38 of 117
Process Labor costs demonstrates the business process covering the creation and entry of labor cost transactions. This process is used, where the Project costing module, is not responsible for the calculation of labor costs against a project, using costing rates for specific individuals, but relates to the processing of whole dollars against a project. The calculation of the charge is done outside of the Oracle application and entered as a charge against the project, as a pre costed transaction. It is perceived that Agencies will either use this process to attribute labor costs to projects or alternatively us the PM5857.1 Process Labor Hours process. Each of the processes are exclusive and do not operate in conjunction with each other.
PM5857 Process Labor Hours PM5857 Process Labor Costs PM5857 Process Usage Costs PM5857 Process Miscellaneous Expenditures PM5857 Process GL Balance Project Allocations PM5857 Process Project Allocations PM5860 Generate Financial Transactions
No
PM5857.3.1 PM5857.3.1 PM5857.3.2 PM5857.3.2
Rejected Records
Yes
PM5857.3.3 PM5857.3.3
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Process Burden Costs demonstrates the business process flow covering the calculation of burden amounts to be attributed against costed transactions already known to the Project. This process relies upon maintenance and availability of Burden Cost Schedules being available for the data combinations entered and costed within the application. Upon transition to the Shared Service center, these Burden Cost schedules will be entered as part of the Agencies original configuration.
Page 39 of 117
No
PM5857.4.1 PM5857.4.1 PM5857.4.2 PM5857.4.2 PM5857.4.3 PM5857.4.3 PM5857.4.4 PM5857.4.4
Prepare Prepare Misc Costs Misc Costs Expenditure Expenditure Batches Batches
Upload Upload Misc Costs Misc Costs Expenditure Expenditure Batches Batches
Rejected Records
Yes
PM5857.4.8 PM5857.4.8
PM5857.4.7 PM5857.4.7
PM5857.4.5 PM5857.4.5
Yes
No
PM5857.4.6 PM5857.4.6
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Process Miscellaneous Expenditures demonstrates the business process covering the processing of Expenditures against a project from external to Oracle sources. These transactions are processed as pre costed, in other words the Oracle application is not required to apply any cost rates to these transactions and processes the values passed from the data source.
OSS Draft Future Business Flow : Process Project Allocations PM5857
No
PM5857.5.1 PM5857.5.1 PM5857.5.2 PM5857.5.2
Rejected Records
Yes
PM5857.5.3 PM5857.5.3
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Page 40 of 117
Process Project Allocations demonstrates the business process flow covering the calculation of allocation amounts to be attributed against projects from a source of an existing project. This process relies upon maintenance and availability of Project Allocation Schedules being available for the data combinations entered within the application. Upon transition to the Shared Service centre, these Project Allocation schedules will be entered as part of the Agencies original configuration. Project Allocation schedules can be quite detailed and specific attention should be paid to the results of each allocation run.
OSS Draft Future Business Flow : Process GL Balance Project Allocations PM5857
No
PM5857.6.1 PM5857.6.1 PM5857.6.2 PM5857.6.2
Rejected Records
Yes
PM5860.6.3 PM5860.6.3
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Process GL Allocations demonstrates the business process flow covering the calculation of allocation amounts to be attributed against projects from a source of a balance in a General Ledger account. This process relies upon maintenance and availability of GL Allocation Schedules being available for the data combinations entered within the application. Upon transition to the Shared Service centre, these GL Allocation schedules will be entered as part of the Agencies original configuration. GL Allocation schedules can be quite detailed and specific attention should be paid to the results of each allocation run.
Page 41 of 117
No
PM5857.7.1 PM5857.7.1 PM5857.7.2 PM5857.7.2 PM5857.7.3 PM5857.7.3 PM5857.7.4 PM5857.7.4
Rejected Records
Yes
PM5857.7.8 PM5857.7.8
PM5857.7.7 PM5857.7.7
PM5857.7.5 PM5857.7.5
Yes
No
PM5857.7.6 PM5857.7.6
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Process Usage Costs demonstrates the business process covering the creation and entry of volume related transactions that require costing. This process is used, where the Project costing module, is responsible for the calculation of Usage costs against a project, using costing rates for specific resources.
OSS Draft Future Business Flow : Manage Project Commitments PM5848
No
PM5848.1 PM5848.1
Action Required
Yes
Enterprise Roles OSS Agency Member Project Manager Requisition and Purchase Order Process Accounts Payable Invoice Process
PM5848.2 PM5848.2
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Page 42 of 117
Manage Project commitments demonstrates the business process flow covering the identification and analysis of committed expenditure against a project. The flow does not highlight any specific application related activities, as the processing and approval of project commitments is addressed within the Purchasing and Payables modules. Specific details can be found in each of these areas process documentation.
OSS Draft Future Business Flow : Process Supplier Invoice Expenditures PM5857
End
No
PM5857.1 PM5857.1 PM5857.2 PM5857.2
Rejected Records
Yes
PM5857.3 PM5857.3
Copyright 2005, Oracle Corporation. All rights reserved. September 2, 2005 Release 11i.10 Slide 1
Process Supplier Invoice Expenditures demonstrates the business process flow covering the transfer of Supplier Invoices from the Accounts Payable module, where the invoice is processed against a project. The flow does not highlight any specific application related activities within the Accounts Payable area, as the processing is addressed within the Payables module. Specific details can be found in the Accounts Payable process documentation.
Page 43 of 117
Process Burden Costs Sub ledger Journals to Post Process Misc. Expenditures
No
PM5860.1 PM5860.1
PM5860.2 PM5860.2
Rejected Records
Yes
Revenue Transaction
PM5860.4 PM5860.4 PM5860.3 PM5860.3
Correct Correct Transactions Transactions source or amend source or amend Auto Accounting Auto Accounting
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Generate Financial Transactions demonstrates the business process flow for the transfer of financial amounts from the Project module to the General Ledger. Each of the various processes identified within this document, have cause for generating financial transactions with the General Ledger, in particular those transactions that have originated within the Project costing module. Each of these transaction sources require auto accounting rules to be configured to enable the PA module to generate the appropriate General Ledger account to effect a financial posting.
OSS Draft Future Business Flow : Manage Project Assets PM5864
Plan to Project Budget PM5851 Process Supplier Invoice Expenditures PM5857 Process Project Expenditures PM5862 Process Expenditure Adjustments PM5858 Process Project Allocations PM5865 Process Project Assets
PM5860.1 PM5860.1
PM5860.2 PM5860.2
Define & Define & Maintain Maintain Project Project Assets Assets
Copyright 2005, Oracle Corporation. All rights reserved. August 25, 2005 Release 11i.10 Slide 1
Page 44 of 117
Manage Project Assets demonstrates the business flow for the identification and collation of Asset related information, where the Project Costing module is responsible for the transfer of assets to Oracle Fixed Assets.
OSS Draft Future Business Flow : Process Project Assets PM5865
PM 5851 Process S upplier Invoice Expe nditures PM 5857 Process Project Expenditures PM 5862 Process Ex penditure Adjustments PM 5858 Process Project Allocations PM 5864 M ana ge Project Assets
PM5865.1 PM5865.1 P M5865.2 PM5865.2 PM5865.2 PM5865.2
PM5865.1 PM5865.1
PM5865.2 PM5865.2
No
Rejected Lines
Yes
Confirm Confirm W ith OSS W ith OSS Capitalisation Capitalisation Readiness Readiness
Yes
PM5865.1 P M5865.1
No
PM5865.1 PM5865.1
PM5865.1 PM5865.1
No
Prior Period Prior Period Asset Lines Asset Lines Interfaced Interfaced to FA to FA
Copyright 2005, Oracle C orporation. A ll rights reserved. Septem ber 2, 2005 Release 11i.10 Slide 1
Process Project Assets demonstrates the business process covering the generation of amounts to be capitalised, for capital projects. These amounts are then transferred to the Fixed Assets module, for capitalisation.
Analysis to Closure
OSS Draft Future Business Flow : Analysis to Project Closure
Project Execution to Asset Project Execution to Asset Period End Close to Financial Reports
Project Execution
PM5833 PM5833 PM5863 PM5863 PM5839 PM5839
Project manager analyzes budget to actual variances by project, task or resource. Review Capital Projects
Copyright 2005, Oracle Corporation. All rights reserved. August 26, 2005 Release 11i.10 Slide 1
Page 45 of 117
Analysis to Project Closure demonstrates the business process covering the analysis of project expenditure and budgets, as well as the maintenance of a project through the project lifecycle. This sub flow supports the changing of project statuses and review and adjustment of expenditures and budgets contained within a project. This process is solely managed through the agency and is supported by the expenditure, budget and Project maintenance processes contained within the Plan to Budget and Execution to Asset flows.
Page 46 of 117
Human Resources
HRMS Foundation
Process Summary
The HRMS Definition Phase is the summary of a range of initiatives designed to align the requirements of the Government of Western Australia and the functionality of Oracle Human Resources Management (HRMS). These initiatives have involved representatives of the Office of Shared Services (OSS) and Oracle Consulting. Initiatives have included: Daily interactions between OSS staff and Oracle consultants, An initial conference room pilot (CRP 2.1) based on the Request for Tender and initial understandings, Workshops following the CRP2.1 to clarify requirements, demonstrate functionality and prepare the subsequent CRP, CRP 2.2 to refine OSS business flows and functional needs
The Oracle modules covered were Human Resource Management (Core), Human Resources Self-Service, Oracle iRecruitment, Oracle Learning Management and Performance Management. This phase sought to confirm the suitability of Oracle HRMS to the OSS business requirements and to determine the degree of fit for functionality and identify gaps and alternative solutions.
Process Flow
Depicted below is the Whole of Government Office of Shared Services Human Resources High Level Organisational Data Management Process. This is the process that is followed when a new organisation or position requires creating, or an existing organisation or position requires change or reclassified. The High Level Organisational Data Management process is broken down into more detail in the following processes: Organisational Structure New / Update Position / TSA Review / New
Page 47 of 117 Company Confidential
Position Data / JDF Update Position Update / Abolish (vacant) Position Update / Abolish (Surplus Employees) Position Update Specified Callings & Criteria Progression positions Position Update Specified Callings & Criteria Progression positions (review when vacant)
. Depicted below is the Whole of Government Office of Shared Services Human Resources Organisational Structure New/Update Process. This process is followed when a new organisation is required or an existing organisation requires updating
Page 48 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Position / TSA Review / New Process. This process is followed when a new position is required or an existing position is to be reviewed.
Depicted below is the Whole of Government Office of Shared Services Human Resources Position Data / JDF Update Process. This process is followed when an existing positions data needs to be updated or the position JDF requires updating.
Page 49 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Position Update / Abolish (Vacant) Process. This process is followed when a position is updated or abolished and the position becomes vacant.
Depicted below is the Whole of Government Office of Shared Services Human Resources Position Update / Abolish (Surplus Employees) Process. This process is followed when a position is updated or abolished and the result of the abolishment is the creation of a surplus employee.
Page 50 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Position Update Specified Callings and Criteria Progression Positions Process. This process is followed when a position is to be reclassified.
Depicted below is the Whole of Government Office of Shared Services Human Resources Position Update Specified Callings and Criteria Progression Positions (review when vacant) Process.
Page 51 of 117
Recruitment
Depicted below is the Whole of Government Office of Shared Services Human Resources High Level Recruitment Process. This is the process that is followed when a position becomes vacant and is required to be filled. The High Level Recruitment process is broken down into more detail in the following processes: Create a Vacancy Posting a Vacancy - Open Posting a Vacancy Closed Entry Level Recruitment (Level 1 clerical and admin) Applicant Process Unsolicited Applicant Process Selection Process Hire Process Contract for Service
Page 52 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Create a Vacancy Process. This is the process that is followed when a position becomes vacant and a manager requests that the position be filled. All vacancies have to be interfaced to RAMS to gain clearance for posting. RAMS check all the records for a suitable redeployee before granting approval for any posting.
Depicted below is the Whole of Government Office of Shared Services Human Resources Posting a Vacancy Open Process. This is the process that is followed when RAMS has granted posting clearance and the Agency has decided to continue with the recruitment process. This process defines the posting of a vacancy that is posted to all Agency websites.
Page 53 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Posting a Vacancy Closed Process. This is the process that is followed when RAMS has granted posting clearance and the Agency has decided to continue with the recruitment process. This process defines the posting of a vacancy that is posted only on the website of the Agency that raised the vacancy. Posting of this type of vacancy is only used where the opportunity is of a finite periodnot to be used for permanent appointments.
Depicted below is the Whole of Government Office of Shared Services Human Resources Entry Level Recruitment Process. This is the process that is followed when a level 1 position becomes vacant and a manager requests that the position be filled. All vacancies have to be interfaced to RAMS to gain clearance. RAMS refers suitable level 1 candidates from the pool database.
Page 54 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Applicant Process. This is the process that is followed when an employee or external applicant applies for a vacancy or a redeployee is identified as a potential match for a vacancy. Please note that the lightly shaded process blocks depicted below are part of the vacancy process and are only defined in this process to give an indication of how the applicant process is started.
Depicted below is the Whole of Government Office of Shared Services Human Resources Unsolicited Applicant Process. This is the process that is followed when an applicant shows interest in a position at a government agency but there are no vacancies currently open.
Page 55 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Recruitment Selection Process. This is the process that the applicant goes through once they have applied for a vacancy.
Depicted below is the Whole of Government Office of Shared Services Human Resources Recruitment Hire Process. This is the process that the applicant goes through once they have successfully completed the selection process.
Page 56 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Contract for Service/Volunteer Process. This is the process that the manager goes through to employ a contingent worker. That is, Contract for Service person, Volunteer or Work Experience person. These workers are not paid through the payroll system but require access to the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources Pool Recruitment Process. This is the process that is followed when a manager requests that a position is to be filled and a previous pool recruitment process is identified. All vacancies have to be interfaced to RAMS to gain clearance.
Page 57 of 117
Learning Management
The high level business flow depicted below is the Whole of Government Office of Shared Services Human Resources High Level Learning Management Process. This is the process that is followed when a Manager or employee initiate a development program for the employee. The High Level Learning Management process is broken down into more detail in the following processes: Identify and Prioritise skill gaps Collect and analyse Learning requirements Define Learning Strategy Define Learning Content Create Learning Delivery Framework Manage Learning Delivery Evaluate Learning Strategy
Page 58 of 117
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Set up a Class Process. This is the process that is followed when a Learning Administrator establishes Courses, Offerings and Classes within the Whole of Government Catalog. The Set up a Class process is broken down into more detail in the following processes, Build the Course Create the Offering Create the Classes
Page 59 of 117
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Enroll in a Class Process. This is the process that is followed when an Employee or Manager logs into the Learning Management Homepage and searches for and books a course. The process shows approvals and notifications.
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Administer and Evaluate a Class Process. This is the process that is followed when a Learning Manager undertakes the administration of enrolments, evaluation and financial arrangements associated with completing course.
Page 60 of 117
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Organisational Learning Paths Process. This is the process that is followed when there is a requirement to undertake bulk enrollment within Learning Management. Bulk enrollments may be by Org Unit, Job Type, Level or other criteria.
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Individual Learning Path Process. This is the process that is followed when a Manager and Employee agree to establish a series of training initiatives (Learning Path) for an employee. It involves creating a Learning Path from options within the catalog and completing enrolment and approvals.
Page 61 of 117
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Enroll in an External Class Process. This is the process that is followed when a Manager and Employee search for an appropriate Class within Learning Management and cannot find one. After approval an external course can be booked. The Learning Management system is then updated through self-service.
The high-level business flow depicts the Whole of Government Office of Shared Services Human Resources enrolling external learner in a class Process. This is the process that is followed to ensure that all external learners are entered into the Learning Management system after theyve identified a learning activity in the OSS System, contacted the learning administrator and enrolled in a class. The learners organization will enter in the system as a customer via procurement.
Page 62 of 117
The high level business flow depicts the Whole of Government Office of Shared Services Human Resources Administer Training Resources Process. This is the process that is followed to ensure that all new resources are entered into the Learning Management system and where required established as Suppliers within Oracle Financial system.
Page 63 of 117
Performance Management
The high level business flow depicted below is the Whole of Government, the Office of Shared Services, Human Resources High Level Performance Management (PM) Process. This is the process that is followed when a new or existing employee undertakes the process of setting work objectives and subsequent reviews against those objectives. The High Level performance Management process is broken down into more detail in the following processes: Employee Performance Planning Employee Performance Progress Employee Performance Achievement, and if required
Substandard Performance.
Page 64 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Employee Performance Management Planning Process. This is the process that is followed when a Manager and a person who is a new assignment set and complete Planning Meeting.
Government of WA
Employee Performance Management Internal HAD (Temporary) of Person Promotion of Person Planning
Manager & Employee Manager Prepare for meeting: Check JDF Check Agency Policy and Guidelines
HRPMPP06
New Assignment
HRPMPP02
Set up meeting
HRPMPP05
Secondary Assignment
HRPMPP03
Planning Meeting Agree on: Objectives Competencies Performance Indicators Learning Paths Career Development Other employee interests
HRPMPP07
Learning Management
HRPMPP08
Manager & Employee Agree on meeting outcomes and set next meeting date
HRPMPP09 Yes
No
Process Key: Oracle Performance Mgt External system Office of Shared Services Agency
Depicted below is the Whole of Government Office of Shared Services Human Resources Performance Management Employee Performance Planning Process. This is the process that is followed when a Manager and an existing employee set and completes a Planning Meeting.
Page 65 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Employee Performance Management Progress Process. This is the process that is followed when a Manager and an employee meet to review the outcomes of the Planning Meeting and amend if necessary. It is the time that the Planning Meeting outcomes are reviewed and amended if necessary. Any Learning Management/Career Management issues or Substandard Performance issues may also be considered.
Depicted below is the Whole of Government Office of Shared Services Human Resources Performance Management Manage Performance Achievement Meeting Process. This is the process that completes the Performance Management cycle. The employee and manager meet to review and assess progress made towards achieving Planning/Progress Meeting outcomes. Any Learning Management/Career Development issues or Substandard Performance issues may also be considered.
Page 66 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Performance Management Substandard Performance Process. This is the process that allows a Manager and Employee to work together to resolve performance issues and develop plans and actions to resolve them.
Depicted below is the Whole of Government Office of Shared Services Human Resources Performance Management Separation survey Process. This is the process that is followed when an employee leaves State Government employment or permanently moves to a Employees who are leaving the agency are invited to complete a survey in regard to their employment experiences.
Page 67 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Employee Logging an incident Process. This process is followed when an incident needs to be logged in the system.
Page 68 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Manager Logging an incident Process. This process is followed when a manager is notified an incident has been logged in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Representatives action in the incident logging Process. This process is followed when an OSH Representative is notified an incident has been logged in the system
Page 69 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Coordinators action in the incident logging Process. This process is followed when an OSH Coordinator is notified an incident has been logged in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Incident Report Data Process. This process is followed to meet legislative requirements in making incident data available to employees.
Page 70 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Hazard Logging Process. This is the process that is followed when an employee logs a hazard, which has occurred. The High Level Hazard Logging process is broken down into more detail in the following processes Employee Manager OSH Representative OSH Coordinator
Page 71 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Employee Logging a Hazard Process. This process is followed when a Hazard needs to be logged in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources Manager Logging a Hazard Process. This process is followed when a manager is notified a Hazard has been logged in the system.
Page 72 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Representatives action in the Hazard logging Process. This process is followed when an OSH Representative is notified a Hazard has been logged in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Coordinators action in the hazard logging Process. This process is followed when an OSH Coordinator is notified a hazard has been logged in the system.
Page 73 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Hazard Report Data Process. This process is followed to meet legislative requirements in making Hazard data available to employees
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Non Employee Occurrence Process. This process is followed when a non-employee needs to report an incident or hazard to an agency where they are working or visiting so the data is captured in the system.
Page 74 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Representative Elections Process. This process is followed when elections for OSH Representatives need to be held.
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Assessments Process. This process is followed when an OSH Representative undertakes an assessment.
Page 75 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Workplace Inspections Process. This process is followed when an OSH Representative or OSH Coordinator carries out legislative workplace inspections.
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Health Surveillance Process. This process is followed when an OSH Coordinator undertakes health surveillance.
Page 76 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources OSH Provisional Improvement Notices Process. This process is followed when an OSH Representative in an Agency raises a provisional improvement notice (PINS).
Workers Compensation
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Process. This is the process that is followed when an employee logs a Workers Compensation Claim through to the recommendation, payment and recovery of the money. The High Level Workers Compensation process is broken down into more detail in the following processes undertaken by the: Workers Compensation New Claim Workers Compensation Recurrence of Injury Managers Recommendation on a Claim (new or a recurrence) Workers Compensation Administrator Injury Management Claims Meetings Interfaces
Page 77 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation new claim Process. This process is followed when an employee enters a new claim in the system.
Page 78 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Recurrence of Injury Process. This process is followed when an employee enters a Workers Compensation Recurrence of Injury for an old claim already recorded in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Managers Recommendation Process. This process is followed when an employee has lodged a new claim or recurrence claim in the system.
Page 79 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Administrator Process. This process is followed when an employee has entered a new claim or a recurrence of injury in the system.
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Injury Management Process. This process is followed after a workers compensation claim or recurrence of injury claim has been entered into the system and the employee requires the injury management process to start.
Page 80 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Claims Meetings Process. This process is followed when an employee has entered a new claim or recurrence of an injury in the system. The Workers Compensation administrator enters details of any claim meetings that have occurred between RiskCover, OSS, Rehabilitation providers and Agencies.
Depicted below is the Whole of Government Office of Shared Services Human Resources Workers Compensation Interfaces. The interfaces are part of the process following an employee lodging a new workers compensation claim or a recurrence of injury claim for an old claim already recorded in the system.
Page 81 of 117
Page 82 of 117
Depicted below is the Whole of Government Office of Shared Services Human Resources Lodging a Breach of Standards Process. This process is followed when an employee or External applicant lodges a Breach of Standards.
Depicted below is the Whole of Government Office of Shared Services Human Resources Lodging a Formal Grievance Process. This process is followed when an employee lodges a Formal Grievance.
Page 83 of 117
Page 84 of 117
Procure to Pay
Requisition to Receipt Direct for Procurement
Process Summary
This flow follows the replenishment process for inventory-planned items where requisitions are created in Purchasing. An Agency that supports Inventory Management will have the replenishment of inventory performed by Purchase orders or Blanket Release that can be automatically created and managed through to receipt. Requisitions can be either generated from the Min/Max planning program and are submitted for review and approval by HR Position Hierarchy or created manually following the similar approval process. Purchase Orders and Blanket Releases can be auto-created from requisitions and also created as Standard Purchase orders. This process also covers the copying of previous PO documents to a newly created one and purchase order cancellation. PO documents are approved depending on HR Position Hierarchy and distributed to Supplier by the Suppliers preferred method of transmission. Inventory item is received from Suppliers and entered into receiving and located within the controlled sub inventory. NOTE# 1. 2. 3. 4. On day 1 of going live, there will be no Inventory Agencies involved. All requisitions that required approval intervention will be authorized via Internet Procurement where the Approval Hierarchy is invoked. No Purchase Orders will be issued in core Procurement without a Requisition either manual or on-line. All Gaps identified in the Requisition to Receipt - Indirect for Procurement as listed below apply to this process.
PR0128.01 Additional Requisition Information for Approver in email notification PR0128.02 Approval Group listing. PR0128.03 Approval Assignment Listing. PR0128.04 HR Position Hierarchy PR1182.01 Configure PO Create Document WF to auto create PO based on WoG criteria. PR0153.01 Modification to the PO print layout. Include Government of WA Logo. PR0153.02 Provide functionality to print attachments. PR0153.03 Configure Fax utility. PR0153.04 Configure SMTP Email Server PR0153.05 Restrict PO Print to Agency specific orders. Secure Print PO to agency buyer. PR0153.06 Restrict to print only Agency specific PO information PR1935.01 Customise Receipt Traveler.
Page 85 of 117
PR1935.02 Notify buyer and receiving location when items are not received on time, supported by workflow.
Process Flows
Approving employee approves Internet Procurement requisition or planning requisition. Approvals are based on WoG Position Hierarchy and Agency specific Hierarchy. Approvals will be controlled, based on the Approval Groups and Approval Assignments, defining the employees approval limits determined by amount, category or account code. Vacation rules are established to determine variation in approval process when Approving Officer is unavailable. Requisition Pool: Approved Requisitions then await Purchasing action or depending on criteria is automatically created into an approved or un-approved purchase order.
The Buyer (QA) approves the purchase order. Purchase Order approvals are based on WoG Position Hierarchy and specific Agency Hierarchy. Approvals will be controlled based on the Approval Groups and Approval Assignments defining the Buyers approval limits determined by amount, category or account code.
BP080 OSS Future Process Model v3.0.doc Company Confidential Page 86 of 117
In the case of Inventory the Inventory Controller or Inventory Buyer will have the appropriate access levels to determine replenishment values. The Agency Lead Buyer will manage Buyer works loads, including where a Buyer is on leave or unavailable.
Page 87 of 117
Process Flow
Click to Requisition
Process Summary
This flow facilitates the requisitioning process. It covers managing of user profiles, searching catalogs, shopping lists, selecting payment methods and managing requisitions. The process commences with the Requisitioner managing their individual profiles. It then provides the Requisitioner with the ability to search I-Procurement shopping lists and establish their own personal shopping lists. Requisitioner - can obtain quotations themselves or refer request to Buyer (Sourcing) to obtain quotes on their behalf. Requisition Approver Approval (generally financial or separation of duties based) for Requisition. (Note Requisition may be auto approved depending on Financial and Procurement delegation of Requisitioner To be determine through Agency specific Approval Groups and Approval Assignment.) Buyer (Sourcing) obtains quotes and undertakes sourcing either in their own right or on behalf of others initiated either from a non-ERP direct approach (e.g. phone call, email, etc), in which case they obtain quotes and then prepare the Requisition; or via an incomplete Requisition forwarded by a Requisitioner via Internet Procurement. Buyer (QA) Quality assurance of procurement process prior to issue of Purchase Order. May be involved in the sourcing process.
Page 88 of 117
Process Flow
Page 89 of 117
Process Flows
Approving employee approves Internet Procurement requisition or planning requisition. Approvals are based on WoG Position Hierarchy and Agency specific Hierarchy. Approvals will be controlled, based on the Approval Groups and Approval Assignments, defining the employees approval limits determined by amount, category or account code. Vacation rules are established to determine variation in approval process when Approving Officer is unavailable. Requisition Pool: Approved Requisitions then await Purchasing action or depending on criteria is automatically created into an approved or un-approved purchase order.
Page 90 of 117
The Buyer (QA) approves the purchase order. Purchase Order approvals are based on WoG Position Hierarchy and specific Agency Hierarchy. Approvals will be controlled based on the Approval Groups and Approval Assignments defining the Buyers approval limits determined by amount, category or account code. The Agency Lead Buyer will manage Buyer works loads, including where a Buyer is on leave or unavailable The Buyer (QA) approves the purchase order.
Page 91 of 117
No accounting entry is created in the general ledger for non-received purchase orders. That is, purchase orders that have been approved and no receiving transaction or invoices have been applied. At Period End the Uninvoiced Receipts Report is used to analyze the uninvoiced expense receipts before accrual of these receipts. The Receipt Accruals PeriodEnd process creates periodend accruals for the uninvoiced receipts for the expense distributions. Purchasing creates an accrual journal entry in General Ledger for each uninvoiced receipt. When opening the next period, Purchasing automatically reverses the accrual entries. In this flow, Requisitions are submitted for review and approval by HR Position Hierarchy. Purchase orders are auto-created from requisitions and also created manually. This process also covers the copying of previous PO documents to a newly created one and purchase order cancellation. PO documents are reviewed and/or approved by HR Position Hierarchy and distributed to Supplier by the Suppliers preferred method of transmission. Goods/Services are received from Suppliers and are either entered into receiving (Core Applications) or Internet Procurement. Where a number of Agencies are sharing an Operating Unit, document security is required. It is proposed to secure documents such as Purchase Order, Contract Purchase Agreements (CPAs), Blankets, Requisitions and RFQ/Quotations to specific Agencies. Currently standard functionality is unable to secure the above documents by Agency where multi agencies share the same Operating Unit. The method proposed for this is based around each Agency being associated to an Inventory Organisation. Security would be based on the Agencys Inventory Organisation, the users Menu Responsibility and HR Location (Deliver To Location). Note#: There are to be no Purchase Orders issued in core Procurement without a Requisition either manual requisition or on-line.
Process Flows
Approving employee approves Internet Procurement requisition or planning requisition. Approvals are based on WoG Position Hierarchy and Agency specific Hierarchy.
Page 92 of 117
Approvals will be controlled, based on the Approval Groups and Approval Assignments, defining the employees approval limits determined by amount, category or account code. Vacation rules are established to determine variation in approval process when Approving Officer is unavailable. Approved Requisitions then await Purchasing action in the requisition Pool or depending on criteria is automatically created into an approved or un-approved purchase order.
The Buyer (QA) approves the purchase order. Purchase Order approvals are based on WoG Position Hierarchy and specific Agency Hierarchy. Approvals will be controlled based on the Approval Groups and Approval Assignments defining the Buyers approval limits determined by amount, category or account code. The Agency Lead Buyer will manage Buyer works loads, including where a Buyer is on leave or unavailable The Buyer (QA) approves the purchase order.
Page 93 of 117
Page 94 of 117
Process Flow
Page 95 of 117
Process Flow
Page 96 of 117
Process Flow
Page 97 of 117
Payroll
Time Collection to Payroll
Process Flow
HR2103 Define and Maintain Schedules & Shifts
OTL Administrator
Payroll to Payment
Legend:
Event Temporal Event Process Step Manual Process Step Automated Process Step Roles Copyright 1999 Oracle Corporation, All rights reserved Expandable Sub-process Decision Data Store External Rostering System
Process Summary
Refer to the BF140 Time Collection to Payroll v3 for further details of this business process.
Page 98 of 117
Payroll to Payment
Process Flow
Compensate to Compete (continued) Payroll to Payment Business Flow
Termination to Payroll Benefits to Payroll Employee Incident to Workers Compensation Personal Assessment to Promotion Time Collection to Payroll Processing Planning Compensation to Commission
HR1216 HR1216
HR1224 HR1224
HR1319 HR1319
HR1242 HR1242
HR1243 HR1243
HR3235 HR3235
HR1244 HR1244
Report and Report and Transfer Transfer Financial Data Financial Data
HR3233 HR3233
HR3234 HR3234
Assurance Team Leader Senior PPR Quality Assurance Officer PPR Quality Assurance Officer
Process Summary
Refer to the BF140 Payroll to Payment Processing v1.4 for further details of this business process.
Page 99 of 117
Process Summary
A summary of each agreement is listed below.
The relationships between these agreement types can vary depending on the ruling of each condition within these types. Some examples of the relationships are as follows;
BP080 OSS Future Process Model v3.0.doc Company Confidential Page 100 of 117
General Order conditions may override conditions in an employees Award or Agreement, Where a condition does not exist in any of the Awards, Agreements, General Orders, etc. then the condition values in the Minimum Conditions policy document are to be used, Custom & Practice Conditions may override conditions in an employees Award or Agreement,
Due to the many variations in the way these agreement types are dealt with a manageable solution is required. This solution is a combination of Payroll configuration with associated Fast Formula and manual intervention by Payroll staff to ensure that the correct payment or absence calculation occurs. Award, Agreement & Agency Specific Agreements Award, Agreement & Agency Specific Agreements is a hierarchical-based structure where the Agency Specific Agreements are subordinate to Agreements and Agreements are subordinate to Awards. This hierarchy is consistent with the majority of the Awards & Agreements but there are a select few where the hierarchy is different. For the select few that the hierarchy is different (i.e.) CALM, Department of Fisheries and Zoo. Custom & Practice Conditions Custom & Practice Conditions is a statement that defines selective conditions that an employee or range of employees may be entitled to. This condition may be as a result of an employee receiving an entitlement condition for a period of time for example, but was not entitled to the condition based on the Award. The employee/s negotiate an agreement to continue the condition or a modification of it. Workplace Agreements A Workplace Agreement is a specific agreement that relates to an employee. This agreement can contain various conditions based on the employment contract agreed to by both the employee and government agency. Minimum Conditions Minimum conditions are a policy document that defines the minimum working conditions that an employee in the government service is entitled to. Note, in most cases the Awards, Agreements, etc. will at least be equal to or better than the minimum conditions. General Order A General Order is a policy statement that defines a condition or range of conditions that can affect any number of employees based on rulings within the Order. The Order can either override conditions within Awards/Agreements, Minimum Conditions, etc. or substitute these conditions if the value is better than in the Awards/Agreements, etc. Other Considerations The Award Detail Reckoner spreadsheet that specifies the Award/Agreement conditions will be used as the basis for determining the Award/Agreement configuration. There may be a requirement to store additional conditions based on the existing conditions; for example, a Condition of Standard Hours per Day may be used to store Standard Hours per Week. Award, Agreement & Agency Specific Agreements The following business flow defines the steps involved in the change of Award, Agreement or Agency Specific Agreements.
The Federal & State Government based Award; Agreement or Agency Specific Agreement particulars are required for payroll and absence payment. These particulars are used to derive the following; Eligibility for payment Payment amounts Deduction amounts Absence eligibility
Page 101 of 117 Company Confidential
Absence amounts
Within Oracle Payroll an Award, Agreement or Agency Specific Agreement will be recorded as a Collective Agreement. A Workplace agreement could be contained in the Collective Agreement structure but would not be linked to a base award or agreement. The Collective Agreement structure is made up of the following components;
User Defined Table - Award, Agreement & Agency Specific Agreements The following business flow defines the steps involved in the change of Award, Agreement or Agency Specific Agreements.
The Federal & State Government based Award, Agreement or Agency Specific Agreement particulars are required for payroll and absence payment. These particulars are used to derive the following; Eligibility for payment Payment amounts Deduction amounts Absence eligibility Absence amounts
Within Oracle Payroll a configuration tool called a User Defined Table (UDT) will be used to store the configuration of an Award, Agreement or Agency Specific Agreement. The UDT is Date Tracked to enable retrospective changes in Award or Agreement modifications. Therefore, when a Retro pay process is performed, retrospective payments can occur. In addition, retrospective changes can dynamically change leave accruals when respective absence conditions change. The People Group flex field will contain an either the Award, Agreement or Agency Specific Agreement name in the 1st Segment. The users will enter short name Award or Agreement names into the People Group flex fields. For example;
Process Summary
Refer to BF140 Payroll to Payment Administration Grade Progression v1.08 for details of this flow.
Process Summary
Voluntary deductions will be managed from three perspectives. An employee thru Employee Self Service will enter specific voluntary deductions. There are also voluntary deductions that will be entered into the system by OSS staff. A list of these voluntary deductions will be provided in the BF162 Payroll Deduction Element Configuration document. Employees may also manage payment to other entities, which are not included in ESS Voluntary Deductions, and OSS requires manage the Voluntary Deductions within the core application. This Process Step will describe all three ways of managing payments to the different deduction houses. With regard to allowances, there are specific allowances that will be managed through Employee Self Service. Manager Self Service will be used if the employee does not have access to the system and his supervisor has agreed to enter the allowance claim for his subordinate.
Overpayments
Process Flow
Process Summary An overpayment is a monetary gain for which there is no entitlement, legislative or other, be it as direct cash or paid time. An overpaid salary is any payment paid to an employee through the payroll to which the employee is not entitled. Overpayments will in most cases be identified through the retro pay process and other quality assurance processes identified for payroll reporting. Other overpayments identified outside this process will require transactions to be entered. Some examples of overpaid salaries include: Leave without pay where there is no opportunity to make adjustments out of the following pay period. An employee may be placed on the incorrect salary step, which is adjusted to the correct salary step. An employee may be paid leave or allowances to which they are not entitled.
An overpaid salary can only be recovered from an employees salary once the employee acknowledges they have been overpaid and permits the OSS to recover the outstanding debt via their pay.
Refer to BF140 Payroll to Payment Administration Overpayments v1.05 for further details of this process flow.
Salary Packaging
Process Flow
Process Summary
Salary packaging arrangements are entered into by the agreement between the employee and employer. Once agreed, the employee arranges with the Salary Packaging provider to administer the package on the employees behalf. The information updated for the employees salary packaging element is updated by the appropriate salary packaging providers either via an interface or report. It is envisaged that all ongoing maintenance of salary packaging element is updated through the interface between the provider and the Office of Shared Services (OSS). Salary Packaging Elements Salary Packaging elements are to be created for both pre-tax and post-tax deductions for each of the salary packaging service providers. These elements require a pay value within the input values as the dollar value is uploaded or downloaded via the interface. The values are shown separately on the employees payslip and reported as salary packaging. Employees can only employ the salary packaging provider appointed by the agency or employer agency to administer their package. The eligibility criteria for the element are used to validate the provider against the agency and allow the employees to be eligible to the element if the criteria are met. The Salary packaging provider calculates and maintains the employees package. Therefore the Pre-tax and Post-tax element will be sent to OSS. An employee has the choice to salary package superannuation deductions directly to GESB/FESA super, rather than choosing the Salary Packaging Provider. If this occurs the Pre tax superannuation element will be updated by GESB via the GESB interface into the superannuation elements.
Employees must request salary packaging changes for superannuation funds such as Pension scheme and Gold state schemes via GESB only. These funds are not available for employees to update and maintain information via ESS due to the fixed criteria for managing these funds. Pre-Tax Weststate contributions can be altered and maintained by the employee through ESS and the updated value is processed to GESB via the interface file. Eligible employees may salary package deductions for GEHA housing. Agencies who allow employees to salary package these deductions will require specific details to be forwarded to OSS for updating into the system. GEHA elements will not be available for employees to update via ESS. Eligible employees may salary package deductions for rental arrangements for Main Road housing. Main Roads who allow employees to salary package these deductions will require to be forwarded to OSS for updating into the system. The MR elements will not be available for employees to update via ESS.
The following elements have been identified and are reflected in the BF 162 Deductions. Elements and Interface (Statement of Works)
Element Name
PTD McMillan Shakespeare pre tax PT McMillan Shakespeare post tax Superannuation Elements
Interface
McMillian and Shakespeare (MD 050 supplied) McMillian and Shakespeare (MD 050 supplied) Superannuation is covered in the MD 050 Superannuation document
Element Name
GEHA pre-tax MR pre-tax Salary Packaging Refund FBT Shortfall Recovery Input Tax Credits
Description
Rental Rental Tax by marginal rate (PAYG) Pre-tax deduction Tax by PAYG
Element Name
Paradigm pre tax Paradigm post tax PKF pre-tax PKF post-tax Salary Packaging Services pre-tax Salary Packaging Services post-tax Salpac pre-tax Salpac post-tax SmartSalary pre-tax SmartSalary post-tax Refunds
Reports
Interface for Paradigm Interface for Paradigm Report Identified Report Identified Report Identified Report Identified Report Identified Report Identified Interface for SmartSalary Interface for SmartSalary
Where a refund is sent through to OSS through the Salary Packaging Provider via the interface, this amount is paid by Salary Packaging Refund element to the employees regular salary and PAYG tax is charged according to marginal rate. Input Tax Credits (ITC) that are paid to employees will be sent back to the salary package provider by Finance. Finance is responsible for the calculation for terminated employees and a report will be provided to OSS every 3 months for entry. Email provided by M. Stagg23/8/05 Salary Packaging ITC Reporting Requirements The following reports have been identified for Salary Packaging: New Report Identified:
Page 107 of 117 Company Confidential
Report to identify employees salary packaging amounts that have exceeded 50% of the employees base salary. This report is used for quality assurance purposes (Payroll Report). When an employee has been identified that their package has exceeded the OSS will contact the employee and the agency to advise.
Fringe Benefits Tax Recovery Finance advises the OSS when an employee needs to be pursued for payment of Fringe Benefits Tax Liability. Payroll will receive the details of outstanding FBT shortfall from Finance via a report and this information requires negotiation between OSS and the employee. Once the value is determined the element is updated by OSS via the FBT shortfall recovery element, to process the pursuing repayment back to the appropriate account. The report is produced by Finance in June of each year, once the FBT processing is completed for the ATO.
Multiple Assignments
Process Flow
1 OSS checks current assignment details of employee who is going to be "Hired" into another position
Manual Process
HRR16
No
Post to Payroll
9 OSS Enters and Maintains Competence Profile, Education and Qualifications, Awards
Core HR
Go to Process Step 45
Assignment-specific information
20 18 Person-specific information 17 Employee updates Person and Assignment specific information through ESS
Employee Self Service
Assignment-specific information ID
Go to Process Step 31
Post to Payroll
Yes
Go to Process Step 32
End of Process
Supervisor updates both Person and Assignm ent specific inform ation through MSS
Custom Manager Self Service
Go to Process Step 34
These will include the following : Competence Profiles Education and Qualifications Other Professional Qualifications (Awards) Resum e W ork Preferences Appraisals Em ployee Perm anent Transfer Em ployee Review Em ployee Secondm ent In/Out Em ployee Temporary Transfer Higher Duties Assignm ent Extending Higher Duties Assignm ent Leave of Absence Release Inform ation
Process Summary In Oracle HRMS, a job or post held by an employee is referred to as an Assignment. It is the central concept that relates employees to the structures in which they work and the compensation and benefits for which they are eligible. It is made up of many attributes: organisation (e.g. department, division, region), GRE (government reporting entity) job title, position, location, grade, payroll frequency (i.e. weekly, fortnightly or monthly), salary basis (monthly or hourly), pay amount, and user-definable attributes to differentiate one assignment from another. See Figure 1.
Each assignment may have its own rate of pay and other unique compensation and benefits eligibility requirements. Additionally, each assignment may report into a different part of an organisation, be funded differently, accrue different leave accruals and may require costing to be different. Each assignment may require using Employee Self Service (ESS) and having the appropriate manager approve the transaction by Manager Self Service (MSS). Managers may also require having access to view and updating their subordinate employees personal and assignment records Whenever an employee holds more than one assignment in Oracle HRMS at any given point in time, this is referred to as an employee holding multiple assignments. An employee can have multiple assignments, but only one is the primary assignment. All others are secondary assignments. Managers will be able to view the personal and assignment information of their subordinates. However, in Employee Self Service, some functions may not be available to secondary assignments For further details of this process flow please refer to the BF140 Multiple Assignments
Process Summary
The end of year processing for Australia is focused on the reconciliation and production of the plain paper Payment Summaries and the electronic lodgement with the Australian Taxation Office (ATO). Employers have a legislative requirement to report to the ATO, details of payment summaries issued to employees during the taxation financial year. Payment Summaries must be processed in compliance with the Australian Taxation Office Guidelines and legislation.
Termination to Payroll
Process Flow
Process Summary Refer to BF140 Payroll to Payment Termination to Payroll v1.05.doc for further details of this process.
Absence to Payroll
Leave Entry Process Diagram
Manager / Delegate Leave Entry Bulk Entry (WebADI)
No
Valid Entry?
Yes
Yes
Approved Absence
Leave Payment
Yes
Yes
Valid Entry?
Valid Entry?
2.
In addition to this criteria an additional value will be defined against the absence type in Oracle to determine if the absence type should be visible in the self service applications. This is to allow leave types such as Workers Compensation to be entered by OSS only via the professional user interface.
Refer to the BF140 Absence to Payroll v1.7 for further details of the business process flow for Leave.
ID
Issue
Resolution
Responsibility
Target Date
Impact Date
Closed Issues
Details contained within the BF140 deliverables.
ID
Issue
Resolution
Responsibility
Target Date
Impact Date