COTS CBMS POC

Proof of Concept
For the provision of
Commercial-Off-The-Shelf (COTS) Software
for the
Central Budget Management System
Table of Contents
1
Section A - Introduction..................................................................................................... 7
Functional & Non-Functional Requirements Model ................................................... 7
1.2
Reference Data Set (RDS)........................................................................................... 8
1.1
Proof of Concept ................................................................................................................ 9

2.1
Approach to Proof of Concept .................................................................................... 9
System Rules to be applied in the Proof of Concept ....................................................... 10
Technical environment / hardware................................................................................... 11

4.1
Key POC design aspects and Finance technical expectations................................... 12
4.2
Approach to evaluating non-functional requirements in the POC ............................ 14
Section B - Introduction ................................................................................................... 17
Expected Outcome of POC .............................................................................................. 17

Demonstrate CBMS Solution .................................................................................... 17
6.2
Scenarios ................................................................................................................... 17
6.3
Data and Expected Outputs ....................................................................................... 17
6.1
POC Process..................................................................................................................... 17
7.1
Timeline .................................................................................................................... 19
Responsibilities / Expectations of Shortlisted Tenderers................................................. 20

Read POC Document ................................................................................................ 20
8.2
Communications via email ........................................................................................ 20
8.3
Installation, de-install, provide technical support ..................................................... 21
8.4
Notification of Changes/Variations ........................................................................... 21
8.5
Funding for the POC ................................................................................................. 21
8.1
Guide to Scenarios ........................................................................................................... 23

Background ............................................................................................................... 23
9.2
Outline/Structure of Scenarios .................................................................................. 23
9.3
Summary Table ......................................................................................................... 25
10
9.1
Scenario 1 Set up .......................................................................................................... 30

Activity 1.1 Establish Reference Data Set .................................................................... 31
Activity 1.2 Security and Application Administration Application / Information
access control ................................................................................................................... 39
Activity 1.3 Application Administration Business Rules .......................................... 46
Activity 1.4 Application Administration User Interface Modification ...................... 48
Activity 1.5 Application Administration Report definition ....................................... 49
Activity 1.6 Application Administration Budget process and system related guidance
.......................................................................................................................................... 51
11
Scenario 2: Decision Making and Budget Estimates Data Entry .................................... 52
Activity 2.1 Assign Measures Code (Process 1.2 Functional Requirement Map 1)..... 53
Activity 2.2 Enter High Level Budgetary Impacts (process 1.3 Functional Requirement
Map 1) .............................................................................................................................. 55
Activity 2.3 Draft Measures Text (process 1.4 Functional Requirement Map 1)......... 56
Activity 2.4 Enter Budget Estimates (process 2.1.2.1 2.1.2.6 Functional Requirement
Map 2.1.2) ........................................................................................................................ 58
Activity 2.5 Reconcile High Level Measures Data (process 2.1.2.7 Functional
Requirement Map 2.1.2) .................................................................................................. 62
Activity 2.6 Run Measures Tables (process 4.1.3.1 4.1.3.4 Functional Requirement
Map 4.1.3) ........................................................................................................................ 64
12
Scenario 3: Financial Consolidation & Reporting of Budget Estimates.......................... 66

Activity 3.1 Post Manual Consolidation Journals (Process 2.4.1 Functional
Requirement Map 2.4) ..................................................................................................... 67
Activity 3.2 Consolidate Financial Statements (Process 2.4.2 Functional Requirement
Map 2.4) ........................................................................................................................... 69
Activity 3.3 Produce Consolidated Financial Statements (Process 4.1.1 Functional
Requirement Map 4.1) ..................................................................................................... 72
Activity 3.4 Produce Portfolio Budget Statements (Process 4.1.4 Functional
Requirement Map 4.1) ..................................................................................................... 74
Activity 3.5 Produce Appropriation Bills (Process 4.1.5 Functional Requirement Map
4.1) ................................................................................................................................... 76
13
Scenario 4: Appropriation Management .......................................................................... 79

Activity 4.1 Set-up of Appropriation Limits (Process 3.1.1 Functional Requirement
Map 3.1) ........................................................................................................................... 80
14
Scenario 5: Cash Management......................................................................................... 82

Activity 5.1 Enter Daily Cash Transactions (Process 3.1.3 Functional Requirement
Map 3.1) ........................................................................................................................... 83
Activity 5.2 Daily Cash Management (Process 3.1.4 Functional Requirement Map 3.1)
.......................................................................................................................................... 93
Activity 5.3 Monthly Cash Management (Process 3.1.5 Functional Requirement Map
3.1) ................................................................................................................................. 101
Activity 5.4 Manage Appropriation Limits (Process 3.1.2 Functional Requirement
Map 3.1) ......................................................................................................................... 103
15
Scenario 6: Annual Actuals ........................................................................................... 106

Activity 6.1 Enter annual actuals (Process 2.3.1 2.3.3, Functional Map 2.3) .......... 107
Activity 6.2 Consolidate Annual Actuals ................................................................... 110
Activity 6.3 Finance Rolls Over Actuals into Estimates (Process 2.1.1, Functional Map
2.3) ................................................................................................................................. 113
16
Scenario 7: Monthly Reporting...................................................................................... 115

Activity 7.1 Enter monthly actuals (process 2.3.1.1 to 2.3.1.2 Functional map 2.3.1)
........................................................................................................................................ 116
Activity 7.2 Compile variance explanations (process 2.3.1.3 -2.3.1.4 Functional Map
2.3.1) .............................................................................................................................. 118
Activity 7.3 Reconcile to Official Public Account (OPA) (process 2.3.1.5 Functional
map 2.3.1) ...................................................................................................................... 120
17
Scenario 8: Application Administration ........................................................................ 123

Activity 8.1 RDS Change: Moving a Program between Agencies ............................. 124
Activity 8.2 Transfer of Functions (Section 32 FMA) (Process 3.1.2.1 Functional
Requirement Map 3.1.2) ................................................................................................ 126
Activity 8.3 RDS Change: Change of an Agency Name ............................................ 128
Activity 8.4 RDS Change: Change to user profile ...................................................... 130
Activity 8.5 RDS Change: Change to Chart of Accounts ........................................... 131
Activity 8.6 Implementation of a new business rule................................................... 134
18
Scenario 9: Mid Year Update and Monthly Profile ....................................................... 136

Activity 9.1 Enter Budget Estimates (Process 2.1.2.1 2.1.2.6 Functional Requirement
Map 2.1.2) ...................................................................................................................... 137
Activity 9.2 Consolidate Financial Statements (process 2.4.2.1 Functional
Requirement Map 2.4.2) ................................................................................................ 139
Activity 9.3 Derive Cash Flows and Aggregates (process 2.4.1 Functional
Requirement Map 2.4) ................................................................................................... 141
Activity 9.4 Produce Financial Statements and Reconciliation Tables (process 4.1.1
and 4.1.2 Functional Requirement Map 4.1) ................................................................. 143
Activity 9.5 Finance Loads Year-End Estimates and YTD Actuals into Profile (process
2.2.1.2 Functional Requirement Map 2.2.1) .................................................................. 145
Activity 9.6 Enter Monthly Profile (process 2.2.2.1 2.2.2.2 Functional Requirement
Map 2.2.2) ...................................................................................................................... 147
Non-functional requirements ......................................................................................... 153
Introduction .................................................................................................................... 166
Assumptions................................................................................................................... 166
Data Overview ............................................................................................................... 166
Data Sets ........................................................................................................................ 166
Data Files ....................................................................................................................... 167
Introduction .................................................................................................................... 170
Templates and Data........................................................................................................ 170
Templates used in the POC ............................................................................................ 170
Template Files................................................................................................................ 171
Introduction .................................................................................................................... 174
Guide to Report Definitions ........................................................................................... 174
Report Files .................................................................................................................... 174
Preface
The Proof of Concept (POC) for Commercial of the Shelf (COTS) Software for the Central Budget
Management System (CBMS) is part of the evaluation of each shortlisted Tenderers solution for RFT
FIN10/FMG020. This document provides a business overview together with information for shortlisted
Tenderers on the expected outcomes, process and timeline of the POC. The POC also contains the
scenarios and activities that will be covered in the POC and the related data, templates, reports and
business rules. The content of each section is as follows:
Section A - Business Overview provides a general overview of the business environment

such as the Australian Government Budget Process, Stakeholders, Publications and Reports.
It also describes the functional and non-functional requirements that the Department of
Finance and Deregulation (Finance) is seeking from the COTS Software. In addition, the
section discusses the Reference Data Set.
Section B - Information for shortlisted Tenderers guides shortlisted Tenderers on what

outcome Finance is expecting from the POC, shortlisted Tenderers responsibilities and
support that can be expected from Finance.
Section C - Scenarios - sets out guidance to the scenarios that will assist shortlisted
Tenderers with their understanding and preparation for the POC. It also lists the components
that affect each scenario, such as inputs, outputs, deliverables and business rules.
Section D - Appendices provides supplementary information for the POC, being, NonFunctional Requirements, Templates, and Reports.
Section A: Business Overview
Section A - Introduction
Tenderers that have been shortlisted during the evaluation process for the Request for
Tender for the provision of COTS Software for CBMS RFT FIN 10/FMG 020 are required to
participate in the POC process during Stage 3 of the Tender evaluation process. This
process offers shortlisted Tenderers the opportunity to exhibit the capability of their
proposed COTS Software to meet the requirements set out in the COTS Software RFT.
Finance has prepared this document to provide guidance to shortlisted Tenderers in
understanding and undertaking the POC. The document outlines the business environment
and requirements surrounding the COTS Software RFT. In addition, it lists Finances
expectations from shortlisted Tenderers during the POC process and the support that
Finance will provide.
A range of scenarios will be used in the POC process, depicting different stages and
processes in the Australian Government Budget Process. Scenarios will be discussed
further in Section C.
The CBMS is the core whole-of-government ICT system underpinning the budget process
and financial management of the Australian Government. All scenarios used in the POC
process will involve a phase or process in the Budget Cycle, which will cover at least one of
the major functions.
The CBMS supports the Government in the management of the following:
Recording of Government decisions;
Budget Estimates updates;
Monthly Estimates Profiles;
Appropriation and Cash Management; and
Monthly and Annual Reporting.
1.1
Functional & Non-Functional Requirements Model

All five major business processes of the functional requirements will be covered in the POC
process. A range of requirements across functional and non-functional will be selected for
the POC process. Shortlisted Tenderers are expected to demonstrate the ability of their
COTS Software to meet these requirements.
Figure 1 Australian Government Budget and Financial Management Requirements
1.2
Reference Data Set (RDS)

The RDS is a collective term used for the underlying data that is used to facilitate entry of
transactions in the CBMS Solution. It will drive a number of business rules to check that
data is valid before allowing the data to be submitted.
It is intended that system benefits will be realised with an effective implementation of the
CBMS Solution, which will be supported by an RDS.
By establishing an RDS the CBMS Solution will provide a number of streamlined and
simplified methods for data entry. It will be the single, authoritative source of financial and
budgetary information and it will reduce the number of manual reconciliations and quality
assurance checks currently in place to ensure data quality and integrity. As a result, all
relevant financial data published in the Australian Government Budget Papers will be
sourced from the CBMS Solution.
Minimum Data Set

Establishment of a minimum data set (i.e. the minimum amount of information to be
entered for every data update in order to satisfy the range of reporting and management
requirements) will offer significant advantages at the point of collection of data. By ensuring
that only the minimum amount of data required is collected thereby reducing the number of
dimensions against which Agencies are asked to partition data, the overall workload will
decrease and the quality and relevance of data entered will improve.
Reference Data Set

Conceptual Data Structure Diagram
WoG *
Portfolio
Sector
Governance
Function
Agency
Bank
Account
Aggregates
Update
Year
Version
Period
Outcome
Month/
Day
Approp
Type
Reason #
Measure
Code
SPP *
(NB: Jurisdiction in
account)
Comment
Measure
text
Approp
Item
Approp
Year
Reason
Groups
Subfunction
Program
Account
Related
Agency
Control
type
Key:
Blue = Minimum Data Set
Green = Derived / consolidated reporting
Grey = Additional information required for selected instances of the MDS
Indicates a many-to-one relationship
Figure 2 Reference Data Set including Minimum Data Set
Proof of Concept
The objective of the POC phase of the evaluation is, via a hands-on assessment, to confirm
whether or not the proposed solution can deliver the required capability in a way that meets
Finances business and technical environment.
2.1
Approach to Proof of Concept

Finance has developed the specifications to be used in the POC process. The
specifications will address areas where a component is considered critical to the ultimate
delivery of the CBMS Solution, or where Finance is less confident in its assessment of the
capabilities of the proposed COTS Software.
The POC specifications will enable Finance to understand technical risks associated with a
given COTS Software candidate, such as compatibility issues with current infrastructure,
interoperability between functional areas, workflow processes, security and access
management.
While the large majority of the POC specifications will be the same among shortlisted
Tenderers, Finance may customise some of the POC specifications for each shortlisted
Tenderer.
System Rules to be applied in the Proof of Concept

The following system rules will apply to the POC process. These system rules supplement
the requirements in Part Two of the COTS Software RFT and will form part of the design
and operations of the CBMS Solution.
Rule 1 Finance does not view or access Agencies Financial Management
Information System (FMIS)
Finance does not view or access Agencies data since there is no link between CBMS and
an Agencys FMIS. Agencies maintain their own separate FMIS to support its day to day
financial operations. Finance will view those data that Agencies enter in the CBMS.
Rule 2 Estimates are built on an incremental basis
Budget estimates are built on an incremental basis and not from a zero base. This means
that the estimates accumulate over budget cycles.
Rule 3 Actuals data is submitted at the financial statement level and on a year-todate (YTD) basis
The Actuals data is updated directly by Agencies through the entry of financial statements
and supporting schedules for the reporting period. Data is submitted to Finance on a
financial YTD basis.
Rule 4 The Reference Data Set (RDS) as a single authoritative source of data and is
consistent across all functions
The RDS is a single authoritative source of financial data in the CBMS Solution, and any
change to data is made through the single authoritative source. In addition, all data
collected within the CBMS Solution will use the same data set across the various functions
(eg. Estimates, Actuals, cash) to allow for a high degree of comparability.
Rule 5 - All mandatory fields will be completed prior to submission
All mandatory fields will need to be completed prior to submission; otherwise the process/
transaction cannot progress to the next step. A message will appear if there is any
incomplete field.
Rule 6 All processes will meet pre-defined validation rules
All CBMS processes will be subject to pre-defined system validation rules. For example,
the rules will include a check on enforcement of cut-off time, valid combination of
parameters, available balance, valid appropriation, and balanced journal entries, etc.
Rule 7 System access depends on the users profile
A users profile dictates what type of system access is available. For example: User As
profile is to be able to read, write, authorise for the Department of Finance and
Deregulation Portfolio for Budget Estimates, and Reporting. In effect, User A will be able to
read, write, authorise for all agencies under Finances portfolio, for processes under the
Budget Estimates and Reporting functions.
Rule 8 All processes will be subject to a multi step approval process and a Finance
review step
All CBMS Solution processes will be subject to a multi step approval process. For any
process entered in the CBMS Solution, an approval step is required before completing the
process. With the exception of some transactions, data submitted by Agencies are subject
to Finance review.
Rule 9 Data to flow automatically between functions
In line with Rule 4, the data should flow automatically between the following functions:
Budget Management to Cash Management;
Cash Management to Actuals Reporting; and
Actuals Reporting to Budget Management.
10
For example, the data entered and approved as estimate adjustments in the Budget
Management function should automatically flow to Cash Management function, reflecting
the estimates data as Appropriation Limits.
Rule 10 Data is submitted using templates to ensure consistent data entry
To ensure completeness, uniformity and accuracy of data, templates will be used when
entering most data in the CBMS Solution (or to view data uploaded via a flat file). The
templates will consist of fields that will be populated prior to submission. This is in line with
Rule 5.
Technical environment / hardware

The non-functional part of the POC process will be focused on the following aspects:
Prevention of unauthorised access or tampering:

Consistency of the Authentication Model;
Use of role / function based access; and
Security of information at rest and in transit.
Solution is accessible to end users when required:
Meets performance expectations;
Resilience to component failures; and
Resilience to site failures.
Ease of use by End-Users:
Application is responsive;
User Interface and application menus are intuitive;
User interface and application behaviour is consistent; and
Provides easy access to context sensitive help.
Maintainability, Supportability and ease of Deployment:
End-point agnostic;
Solution is viable for 10 years in service;
Provides effective monitoring and instrumentation;
Leverages existing Finance technology and technical expertise; and
Minimises requirement for frequent and extended maintenance outages.
Capability to cope with unplanned additional workload(s):
Additional processing load; and
Additional data and data management load.
Cost effectiveness:
Efficiently allocate resources.
Ensure confidence in Budget information:
Validate input; and
Maintain data integrity.
The diagram provided in Figure 3, below, illustrates a number of logical aspects that will
need to be configured in order to form an appropriate technical representation of the
system and its interaction with users.
11
Figure 3 POC Environment - Logical View of the Technical Configuration Required
4.1
Key POC design aspects and Finance technical expectations

POC Hardware
The POC is to include each component of the proposed final solution (e.g. database server,
application server, firewalls, switches, routers etc) configured as per the solution proposed
in the shortlisted Tenderers COTS Software RFT response. Where there is anticipated to
be multiple devices performing the same role not all devices have to be included in the
POC. Finance does not restrict the make, model or configuration of infrastructure employed
12
by the shortlisted Tenderer for the POC, to demonstrate the COTS Software. Shortlisted
Tenderers should employ those configurations deemed optimal for effective COTS
Software operation, as proposed in their COTS Software RFT response.
Separation of CBMS Network, Finance Network, and Agency Networks

The CBMS Solution is required to be certified to process and store information up to and
including the PROTECTED classification. Although the Finance network is similarly
certified, a suitable degree of separation is required to enforce the need to know principle,
as only a subset of Finance staff are CBMS users. The full spectrum of different
classifications may apply to Agency networks, ranging from UNCLASSIFIED (ie. not
certified to handle classified materials) through to PROTECTED.
The level of interconnection between the networks is to reflect the proposed security model
of the COTS Software. It is accepted that at the time of the POC, the nature of the CBMS
hosting model to be employed is unknown. Shortlisted Tenderers should note however the
COTS Software RFT requirements to adhere to Finance security policies, including ISM
compliance.
Separation of the CBMS Internal Networks

It is anticipated that the CBMS will need to be separated into a number of zones, in order
for the COTS Software to meet DSD security requirements. As such, Finance expects a
representative POC environment would illustrate the relationships and COTS Software
functionality within a demilitarised zone, application / database zone, management zone
and any presentation layer that interacts with user sessions.
Configuration of Finance Functionality

The POC emulation of the broader Finance Network that the CBMS Solution will interact
with, should contain Microsoft Active Directory, five Microsoft Windows workstations that
are capable of running the COTS Software full functionality client (and potentially the Webbased client), printers, and emulations of file storage systems.
The POC should illustrate how single sign-on functionality will be delivered by the COTS
Software for Finance users, while maintaining appropriate security of each environment.
A range of service management accounts (at least two with differing access rights and no
access to the application) should be configured, in addition to user functional accounts (as
detailed in Scenario 1), to illustrate the delegation of authority model supported by the
COTS Software, and how least privilege access is supported. Finance also requires at
least two total environment system administrator accounts.
Configuration of Agency Functionality

The POC emulation of a typical Agency environment should contain three Microsoft
Windows workstations that are capable of running the COTS Software full functionality
client (and potentially the Web-based client), printers, and emulations of file storage
systems. Additionally, three non-Windows devices (eg. a locked down kiosk style system)
should be configured to illustrate the independence and zero footprint of the Web-based
client.
Agencies connect to the CBMS via the Internet, and via Fedlink. Unless otherwise
proposed by the shortlisted Tenderer, Finance will assume the COTS Software functionality
for Agency users is the same for both connection methods.
An emulation of the Internet should be configured. The POC should then illustrate how
functionality will be delivered by the COTS Software for Agency users, using two factor
13
authentications across the Internet, while maintaining appropriate security of each

environment.
A number of Agency user functional accounts (as per Scenario 1) should be configured, to
further illustrate the delegation of authority model supported by the COTS Software, and
how least privilege access is supported.
4.2
Approach to evaluating non-functional requirements in the POC

The non-functional POC process will be focused on the following key aspects. Emphasis
will be placed on those areas of the COTS Software RFT response that cannot be
otherwise verified through publicly available information, reference checks, and feedback
from the Implementer Expression of Capability.
1
Architecture Qualities
Solution is accessible to end users when required:

Meets performance expectations;
Efficiently allocate resources as and when required;
Resilience to component failures; and
Resilience to site failures.
Capability to cope with unplanned additional workload(s):
Additional processing load; and
Additional data and data management load.
Access Channel
Ease of use by End-Users:

Application is responsive;
User Interface and application menus are intuitive;
User interface and application behaviour is consistent; and
Provides easy access to context sensitive help.
Application Services
Data Management

Validate input; and
Integration
Security
Prevention of unauthorised access or tampering:

Consistency of the Authentication Model;
Use of role / function based access; and
Security of information at rest and in transit.
Infrastructure
Maintainability, Supportability and ease of Deployment:

End-point agnostic;
Solution is viable for 10 years in service;
Provides effective monitoring and instrumentation;
Leverages existing Finance technology and technical expertise; and
Minimises requirement for frequent and extended maintenance
outages.
14
Development

Validate input; and
The relevant subsets of non-functional requirements that will be assessed during the POC
evaluation are listed in Appendix 1. These requirements will be tested throughout all
scenarios within the POC.
15
Section B: Information for Shortlisted

Tenderers
16
Section B - Introduction
The POC will be conducted in accordance with clause 23 of Part One of the COTS
Software RFT and the POC Deed at Attachment A of Part One of the COTS Software RFT.
Section B of this document provides more detailed information for shortlisted Tenderers
involved in the POC process, covering such areas as the expected outcomes of the POC,
the timeline and process of conducting the POC, responsibilities and expectations of
shortlisted Tenderers and support from Finance.
Expected Outcome of POC

Through the POC, Finance seeks a greater understanding of the COTS Software and to
gain evidence that the proposed COTS Software addresses the requirements set out in the
COTS Software RFT.
A greater understanding of the capabilities of the proposed COTS Software will be used in
the evaluation of Tenders against the Evaluation Criteria to:
6.1
refine the assessment of business suitability;

refine the assessment technical suitability;
more accurately estimate financial implications for deployment of a full CBMS
Solution; and
identify any additional risks emerging from the POC process that may need to be
mitigated (which may include conditions in the Contract) through the project with
these being identified in the assessment against the relevant evaluation criteria.
Demonstrate CBMS Solution

Each shortlisted Tenderer will be required to participate in a POC that represents the
solution as proposed in the shortlisted Tenderers response to the COTS Software RFT.
The purpose of a POC demonstration is to address the functional and non-functional
requirements of the scenarios outlined in Section C of this document. The POC
demonstration is to be tailored to the scenarios outlined in Section C of this document and
is not a generic product demonstration of the COTS Software.
6.2
Scenarios
The scenarios for the POC provided at Section C of this document include a step by step
guide to the business processes and functionality to be evaluated. The scenarios are a
representation of a number of the functional requirements detailed in Part Two of the COTS
Software RFT.
6.3
Data and Expected Outputs

Finance will provide the input and output data related to the POC, together with the
expected content and format of reports generated in the scenarios. While Finance has
provided the expected outputs of each scenario, Finance may conduct additional testing,
for example, via additional data entry, during the POC demonstrations to assess the
functionality being tested.
POC Process
POC specifications provided Finance will provide all Tenderers with the specifications
for the POC prior to the commencement of the POC (the anticipated timetable is detailed
below). At this time, Tenderers will also be provided with the set-up data for the POC (as
per Scenario 1), including the POC Reference Data Set. The specifications are provided for
information only as not all Tenderers will be asked to participate in the POC. Tenderers
may choose to begin their preparations for the POC at this stage but this will be at each
17
Tenderers own risk. Furthermore, Finance reserves the right to amend the POC
specifications up until the date that Tenderers are shortlisted.
Tenderers are to advise the location of the POC should they be shortlisted In order
for Finance to plan for the conduct of the POC, all Tenderers are requested to advise
Finance the city in which they would provide their POC demonstrations in the event that the
Tenderer is shortlisted. Tenderers are requested to provide this information in writing to
CBMSredev@finance.gov.au. It is Finances preference that the POC demonstrations be
located in Canberra.
POC shortlist finalised Shortlisted Tenderers, each of which will be required to
participate in the POC, will be notified. Any reserve shortlisted Tenderers requested to
participate in the POC will also be notified. At this time, the shortlisted Tenderers will also
be provided with the input data to be used in the POC Scenarios and the expected outputs.
If a reserve Tenderer is required to participate in the POC, it will do so on the same terms
as a shortlisted Tenderer, including the reimbursement of costs.
Briefing for shortlisted Tenderers A briefing will be held in Canberra for all shortlisted
Tenderers, to discuss the content and process of the POC. Attendance at the briefing is
strongly encouraged but is not mandatory. The Probity Advisers will also provide a probity
briefing at this time. Shortlisted Tenderers will be provided with the details on the time and
location of the briefing in advance.
Preparation for POC Each shortlisted Tenderer prepares for the POC.
POC Preliminary Demonstrations Each shortlisted Tenderer will have an opportunity to
provide a preliminary demonstration of the POC to Finance with the purpose of seeking
clarification on the POC and receiving feedback on their demonstration. Shortlisted
Tenderers will have up to two Business Days (9am to 5pm) to demonstrate their COTS
Software. Days may be taken individually, or in a block.
Shortlisted Tenderers should apply in writing to CBMSredev@finance.gov.au with their
desired dates for the preliminary demonstration. Those dates must be within the
demonstration period which is 3 November to 25 November 2010. Applications for
preliminary demonstration dates and any proposed changes to the date of a scheduled
preliminary demonstration must be received at least three Business Days prior to the
proposed date. Dates for preliminary demonstrations will be allocated on a first come, first
served basis. The POC preliminary demonstration will provide shortlisted Tenderers the
ability to clarify functional or non-functional requirements. The POC preliminary
demonstration does not form part of the POC evaluation.
Feedback on preliminary demonstration Finance provides feedback to each shortlisted
Tenderer on the preliminary demonstration. Finance may, in its absolute discretion, refuse
to answer one or more questions during the preliminary demonstration and/or may take
questions on notice.
Finance will endeavour to provide verbal answers to simple questions of fact asked by a
shortlisted Tenderer during the preliminary demonstration. However, shortlisted Tenderers
cannot rely on any verbal or other representations made by Finance during the preliminary
demonstration. All material questions posed during the preliminary demonstrations, and
answers to those questions, will be provided to shortlisted Tenderers in written form after
the preliminary demonstration.
Finance will endeavour to provide the written Question and Answer document no later than
3 Business Days after the conclusion of the shortlisted Tenderer's preliminary
demonstration. Shortlisted Tenderers are entitled to rely on the answers provided by
Finance in the written Question and Answer document. If a shortlisted Tenderer considers
18
that a material representation made by Finance during the preliminary demonstration is not
reflected in the Question and Answer document, the shortlisted Tenderer should inform
Finance as soon as possible. Finance will then decide, in its absolute discretion, whether
the Question and Answer document should be amended.
Finance reserves the right to provide answers to any questions raised by shortlisted
Tenderers at the preliminary demonstration to other shortlisted Tenderers in an anonymous
fashion, where Finance considers that the answer is relevant to all shortlisted Tenderers.
This will be determined by Finance on a case by case basis.
Final POC demonstration Each shortlisted Tenderer provides a final POC
demonstration to Finance, where Finance will spend up to three days (9am to 5pm) actively
assessing shortlisted Tenderers COTS Software through hands on testing. The purpose
of the final POC demonstration will be for each shortlisted Tenderer to demonstrate the
scenarios in Section C of this document. Finance may also provide shortlisted Tenderers
with new transactions to confirm the results of the POC demonstration. Finance may ask
questions of the shortlisted Tenderers during the POC demonstrations, and may (in its
absolute discretion) obtain independent expert advice on the POC demonstrations.
Each shortlisted Tenderer should be available for the entire period between 7 December
and 23 December 2010. That is, all shortlisted Tenderers must be prepared to provide their
POC demonstration on and from 7 December 2010. Finance proposes to conduct the final
POC demonstrations in two stages. Stage 1 will involve Finance spending one day (9am to
5pm) with each shortlisted Tenderer at the beginning of the final POC demonstration
period. Once all shortlisted Tenderers have completed Stage 1, Finance will commence
Stage 2 with each shortlisted Tenderer. Stage 2 will involve Finance spending up to two
further days (9am to 5pm) with each shortlisted Tenderer over the remaining final POC
demonstration period.
Finance reserves the right to revisit POC demonstrations at any time within the final POC
demonstration period. These visits may be in addition to the three day evaluation period.
Actual dates for Finance visits of each shortlisted Tenderers final POC demonstration will
be determined via a ballot on 6 December 2010.
Update COTS Software RFT evaluation following the POC, Finance will update
evaluation of each of the shortlisted Tenderers responses to reflect the greater
understanding of the operation of the COTS Software and any associated risks or issues
regarding its use for the CBMS Solution.
7.1
Timeline
The POC process will be conducted between the short listing of Tenderers and the
commencement of the negotiation stage. It is anticipated that the POC will start on
1 November 2010 and conclude on 23 December 2010. The planned sequence of activities
is as follows:
Proof-of-Concept Timeline
Activity
Date
POC Specifications and Set-Up data

provided to all Tenderers
11 October 2010
All Tenderers to have advised Finance of

the location of their POC demonstration
20 October 2010
19
(should they be shortlisted)
POC Shortlist finalised. Shortlisted

Tenderers are provided with any changes to
the POC Specifications and are provided
with input data and expected results once
the signed POC deed is returned to Finance
29 October 2010
Commence preparation for POC
1 November 2010
Briefing for shortlisted Tenderers
From 3 November 2010
POC Preliminary Demonstration Period
3 November
25 November 2010
Feedback on POC Preliminary

Demonstrations finalised
26 November 2010
Shortlisted Tenderers to submit as-built

documentation of POC to Finance
3 December 2010
Shortlisted Tenderers advised of dates for

Final POC Demonstration
6 December 2010
Final POC Demonstration Period
7 December
23 December 2010
Update COTS Software RFT evaluation
January 2011
Responsibilities / Expectations of Shortlisted Tenderers

The following points outline the responsibilities and expectations of each shortlisted
Tenderer in relation to this document and during the POC process.
8.1
Read POC Document

It is the responsibility of each shortlisted Tenderer to read in full and understand this
document before attempting to address the scenarios contained within.
Each shortlisted Tenderer will be given the opportunity to seek clarifications regarding the
document to assist in their understanding of the requirements of the POC. This opportunity
will be in the form of a briefing conducted with all shortlisted Tenderers before the POC.
Finance reserves the right to provide answers to any clarification questions raised by
shortlisted Tenderers at the briefing to all shortlisted Tenderers in an anonymous fashion.
8.2
Communications via email

Questions compiled by the shortlisted Tenderers in relation to any part of the POC
document or process, including the scenarios (other than those questions addressed at the
briefing), must be addressed in writing to the CBMS Redevelopment Branch via the
following email address:
CBMSredev@finance.gov.au.
Responses to shortlisted Tenderers questions may be published on the CBMS
redevelopment website, http://www.finance.gov.au/cbms/CBMS_redevelopement.html in an
anonymous fashion.
20
8.3
Installation, de-install, provide technical support

Each shortlisted Tenderer will provide the hardware and technical environment necessary
to host its POC.
Each shortlisted Tenderer will be responsible for the installation and de-installation of its
POC system. Installation of the POC system should be on an environment consistent with
the configurations proposed in their COTS Software RFT response.
Each shortlisted Tenderer will need to provide the necessary technical support required to
install, de-install and support its POC system.
Each shortlisted Tenderer will also need to provide Finance with access to two shortlisted
Tenderer representatives who are familiar with the set-up, performance and functionality of
the system. These people will be required to explain the design of the system and brief
Finance on access etc. These people should then be available to answer any questions
from Finance.
Finance requires as-built documentation that explains the POC system. This
documentation should be of sufficient detail for Finance to understand the hardware,
technical environment and configuration employed in the POC, to allow a competent
engineer to replicate the solution. This must be provided to Finance by 3 December 2010.
8.4
Notification of Changes/Variations
It is the responsibility of the shortlisted Tenderer to notify Finance of any changes and/or
variations to the COTS Software as proposed in the COTS Software RFT response. These
changes / variations must be agreed by Finance in writing prior to the installation and
testing of the POC scenarios. Finance reserves the right not to agree to any changes
and/or variations at its absolute discretion.
8.5
Funding for the POC

In accordance with Part One of the COTS Software RFT, Finance will reimburse each
shortlisted Tenderer for reasonable effort expenses incurred in preparing and participating
in the POC. Reimbursement will occur at the conclusion of the POC process and subject to
the terms of the POC Deed.
21
Section C: Scenarios
22
Guide to Scenarios
9.1
Background
Finance has created nine scenarios to test the capabilities of the proposed COTS Software.
The scenarios contain a number of activities that provide a step-by-step guide to the
business processes and functionality being tested and which should be undertaken in
order.
A strong focus in the structuring of the scenarios is assessing the integration of the COTS
Software and the ability for data to automatically flow from one business process to the
next.
The scenarios and associated activities are fictitious and are designed to provide an
illustrative example of how the CBMS Solution will be used. Detail in each scenario is for
illustrative purposes only, and does not indicate a preference on what the final solution will
involve.
Shortlisted Tenderers are encouraged to demonstrate all nine scenarios.
9.2
Outline/Structure of Scenarios
The structure used to present the nine scenarios is outlined below.
Overall Scenario Description
A short description of the scenario, including the activities tested and the primary
functionality that will be demonstrated.
Activity Description
A short description of the activity, including the business processes a user would undertake
in completing the activity.
Process Diagram Activity
The relevant business process diagrams that the activity is demonstrating, as represented
in the COTS Software RFT. Within each process diagram, the processes relevant to the
activity are shown in green while the processes not relevant to that activity have been
greyed out.
Functional Requirements
The functional requirements listed in the COTS Software RFT that shortlisted Tenderers
will demonstrate in completing the activity.
Key inputs and linkages from other functions
The inputs a user would require to complete the activity, including data, template and
security inputs. Each input is provided in the Appendices to this document.
Inputs are shown in incremental format, where each change is displayed in a new version.
An indication of the information contained in each version is outlined below:
Set-up - data to be used in the configuration or setting up of the CBMS Solution

(Scenario 1)
Base - historical transaction data, to be preloaded into the CBMS Solution prior to the
commencement of a scenario;
Data transactional data to be entered or uploaded into the CBMS Solution in the
conduct of the scenario. Data Version 1.0 comprises the original transactional data
which is being entered into the CBMS Solution for the first time or which is unchanged
from the original version. Data Version 1.1, 1.2, etc comprises updated versions of the
data reflecting the incremental impact of changes made to the data in previous
scenarios or activities. The POC data sets are listed in Appendix 2;
23
Templates to ensure the collection of accurate and complete data sets, standard
templates are used for the collection of all data entering the system. The POC
templates are listed in Appendix 3 and detail the fields necessary for entering the
various types of data into the CBMS Solution;
Rule business rules for data validation, eliminations and reconciliations to be applied
for various activities within the POC; and
Security user roles to be applied in the conduct of an activity which will determine the
extent and type of access given to the user in completing the activity.
Where an input to a Scenario and/or Activity is dependent upon the completion of an earlier
Scenario/Activity, the Input table will include a cross reference to the earlier
Scenario/Activity.
Key outputs and linkages to other functions
The outputs expected at the completion of the activity, including updated or processed
data, and any system, statutory or ad hoc reports.
Each expected output, including the reports and expected data with those reports is
provided in the Appendices to this document.
Outputs are also shown in incremental form and primarily consist of:
Data data which has been updated by the CBMS Solution during a scenario activity.
This is generally the point at which the data version changes (e.g. from 1.0 to 1.1)
reflecting that the data has been amended in some way;
Report - an onscreen and/or printed output showing the results of a particular activity or
group of activities. Some reports have specific formats and structures while other
reports are ad-hoc and free-form. Report formats are listed in Appendix 4.
24
9.3
Summary Table
Scenario
Designed to demonstrate
POC Activities
RFT Part Two

Reference
Scenario 1: Setup
usability;
Activity 1.1 Establish Reference Data Set
Clause 10.7.2
Clause 12.3.3
a single, consistent view of data that applies

across all the information that is collected
through the reference data set;
Activity 1.2- Application Administration

Application/Information access control
Clause 10.7.3
Clause 12.7
data integrity;
Activity 1.3 Application Administration Business Rules
Clause 10.7.1
Clause 10.7.4
security;
Activity 1.4 Application Administration User Interface

Modification
product integration; and
Activity 1.5 Application Administration Report definition
robustness of design
Clause 10.6
Clause 10.7.5
Activity 1.6 Application Administration Budget process and

system related guidance
Clause 10.7.5
the capture and reporting of Government

decisions, including narrative;
Activity 2.1 Assign Measures Code
Clause 10.3
Activity 2.2 Enter High Level Budgetary Impacts
Clause 10.3
entering or uploading multi-year budgeted

financial data against a predefined reference
data set; and
Activity 2.3 Draft Measures Text
Clause 10.3
Activity 2.4 Enter Budget Estimates
Clause 10.4.1
Activity 2.5 Reconcile High Level Measures Data
Clause 10.3
Activity 2.6 Run Measures Tables
Clause 10.6.1
the posting of consolidation at various levels

within the consolidation hierarchy; and
Activity 3.1 Post Manual Consolidation Journals
Clause 10.4.4 (a)
Activity 3.2 Consolidate Financial Statements
Clause 10.4.4 (b)
the consolidation of financial information
Activity 3.3 Produce Consolidated Financial Statements
Clause 10.6.1 (a)
Scenario 2:
Decision Making
and Budget
Estimates Data
Entry
Scenario 3:
Financial
Consolidation &
data integrity through system-based

validations, reconciliations and approval
controls for the budget estimates function.
25
Scenario
Reporting of
Budget Estimates
Scenario 4:
Appropriation
Management
POC Activities
RFT Part Two

Reference
according to different consolidation hierarchies;
Activity 3.4 Produce portfolio budget statements
Clause 10.6.1 (d)
the automatic matching and elimination of

related-entity transactions, including the
identification and automatic adjustment of
mismatched related entity transactions; and
Activity 3.5 Produce appropriation bills and resourcing tables
Clause 10.6.1 (e)
the production of consolidated statutory

reports for various elements and combinations
within the RDS, including consolidated reports
by Sector and Function;
the automatic sourcing of Appropriation Limits

in the Cash Management function from
Appropriation data entered during the
Estimates update process;
Activity 4.1 Set-up of Appropriation Limits
Clause 10.5.1 (a)

controls for the Cash Management function;
the capture of Appropriation Limits information

against various aspects of the RDS;
the ability to manage and classify adjustments

to Appropriation Limits (e.g. Advance to the
Finance Minister (AFM), section 32, Reduction,
etc);
the ability to view Appropriation balances onscreen while performing a process; and
the generation, execution and printing of

reports relating to the set-up of, and
management of modifications of Appropriation
Limits.
Clause 10.6.2 (b)
26
Scenario
POC Activities
RFT Part Two

Reference
Scenario 5: Cash
Management
ability to process drawdowns, receipts and

journals by manual entry and using upload files;
Activity 5.1 Enter Daily Cash Transactions
Clause 10.5.1 (c)
ability to change the status of transactions as

data flows from one process to another;
Activity 5.2 Daily Cash Management

controls;
Activity 5.3 Monthly Cash Management
Scenario 6:
Annual Actuals
producing an error message when a process

fails a business rule;
access control limiting users access to specific

roles and functions;
allocation of unique reference numbers to

transactions in the CBMS Solution;
ability to report data across functions and

conduct comparative analysis;
Reserve Bank of Australia (RBA) reports can be

successfully uploaded into CBMS; and
CBMS file to be successfully uploaded to

ReserveLink WE.
the submission of actual financial statement

data information and supporting notes;

controls over the submission of actual financial
results and supporting information;
Clause 10.6.2 (a)

Clause 10.5.1 (d)
Clause 10.6.2 (b)
Clause 10.5.1 (e)
Clause 10.6.2 (a)
Clause 10.6.2 (b)
Activity 5.4 Manage Appropriation Limits
Clause 10.5.1 (b)

Clause 10.6.1 (a)
Activity 6.1 Enter annual actuals
Clause 10.4.3
Activity 6.2 Consolidate Annual Actuals
Clause 10.4.4
Activity 6.3 Finance Rolls Over Actuals into Estimates
Clause 10.4.1
27
Scenario
Scenario 7:
Monthly
Reporting
Scenario 8:
Administration
POC Activities
RFT Part Two

Reference
the consolidation of actual financial statement

information and supporting notes at various
levels within the consolidation hierarchies;
the production of Statutory reports and audit

reports; and
Integration between the annual actual process

and the budget estimates process.
the submission of actual YTD financial

statement information;
Activity 7.1 Enter monthly actuals
Clause 10.4.3
Activity 7.2 Compile variance explanations
Clause 10.4.3

controls for the submission of monthly reports;
Activity 7.3 Reconcile to Official Public Account
Clause 10.4.3
integration between the monthly reporting

function and the budget estimates function,
including the capture of textual explanations for
budget variances; and
integration between the monthly reporting

function and the cash management function,
including the ability to reconcile appropriations
and transfers to the official public account.
a central facility to manage changes to the

Reference Data Set that are applied consistently
across all functions;
Activity 8.1 RDS Change: Moving a Program between Agencies
Clause 10.7.2
Activity 8.2 Transfer of Functions (Section 32 FMA)
Clause 10.5.1 (b)
Activity 8.3 RDS Change: Change of an Agency Name
Clause 10.7.2
the capture of audit information for any

reference data changes;
28
Scenario
Scenario 9: Mid
Year Update and
Monthly Profile
POC Activities
RFT Part Two

Reference
The ability to maintain data integrity following

changes to the Reference Data Set; and
Activity 8.4 Change to user profile
Clause 10.7.3
the ability to manage and classify adjustments

to Appropriation Limits to reflect a MoG change
(e.g. section 32 transfer of function);
Activity 8.5 RDS Change: Change to Chart of Accounts
Clause 10.7.2
Activity 8.6 Implementation of a new business rule
Clause 10.7.1
application access controls that allow the

modification of user access across multiple
dimensions.
the capture and reporting of Government

decisions;
Clause 10.4.1
Clause 10.4.4
entering or uploading multi-year budgeted

financial data against a predefined reference
data set;
Activity 9.3 Derive Cash Flows and Aggregates
Clause 10.4.4
Activity 9.4 Produce Financial Statements and Reconciliation

Tables
Clause 10.6.1
Data integrity through system-based

controls;
Activity 9.5 Finance Loads Year-End Estimates and YTD Actuals

into Profile
Clause 10.4.2
Activity 9.6 Enter Monthly Profile
Clause 10.4.2
Entry of consolidation adjustments and the

consolidation of estimates data to produce a
derived cash flow statement and reconciliation
tables;
Activity 9.7 User-defined reporting
Clause 10.6.2
Entering or uploading budgeted financial data

profiled against the remaining months of the
financial year against a predefined reference
data set; and
Ability to define reporting across multiple

dimensions.
29
10
Scenario 1 Set up
This scenario provides details for shortlisted Tenderers to enable them to set up their
CBMS Solution and undertake the specific administration tasks required to support the
business functions to be tested in the following scenarios. The scenario details the
functionality evaluated, the inputs required for each element of the set up and the expected
outputs.
The scenario follows a selected subset of the business processes, functional and nonfunctional requirements presented in Part 2 of the CBMS COTS Software Request for
Tender.
In this scenario, the shortlisted Tenderers POC will be evaluated to assess the shortlisted
Tenderers ability to provide a solution which ensures:
useability;
a single, consistent view of data that applies across all the information that is collected
through the reference data set;
data integrity;
security;
product integration; and
robustness of design;
while meeting the operational activities.

Detail in the scenario is for illustrative purposes only, and do not indicate a preference on
what the final solution will involve.
As the set-up of the POC must take place prior to the instigation of Scenarios 2 to 9 and
may require some time, shortlisted Tenderers may choose to implement Scenario 1 prior to
the the final POC demonstration.
The key activities and associated functionality to be covered in this POC scenario include:
Activity
Primary Functionality Tested
RFT Reference
Activity 1.1 Establish Reference Data

Set
Data Administration
Access Channels
Clause 10.7.2
Clause 12.3.3
Activity 1.2- Application Administration

Application/Information access
control
Data Administration
Security
Clause 10.7.3
Clause 12.7
Activity 1.3 Application

Administration Business Rules
Data Administration
Clause 10.7.1

Administration User Interface
Modification
Data Administration
Clause 10.7.4

Administration Report definition
Reporting and Analysis
Clause 10.6
Data Administration
Clause 10.7.5

Administration Budget process and
system related guidance
Data Administration
Clause 10.7.5
30
Activity 1.1 Establish Reference Data Set

An overarching principle for the Reference Data Set (RDS) is a single authorative source of
financial data providing a single, consistent view of data that applies across all the
information that is collected by the CBMS Solution.
A POC RDS and base data will need to be loaded into each shortlisted Tenderers POC
prior to the execution of scenarios.
Shortlisted Tenderers should note that the RDS has been derived for the purposes of the
POC. It is not intended to reflect the full reference data set required in the CBMS Solution.
The key tables and fields to be included in the POC are illustrated below.
31
Proof of concept data group relationships
32
Proof of concept data group relationships
The diagram on page 32 labelled Proof of concept data group relationships provides
additional detail for each item of the Reference Data Set (RDS) that are introduced in Figure
2 on page 9. It lists the names of each field within each RDS item that are required to enable
the RDS to facilitate both the capture of transaction data and the associated derivations
required for the POC. It also details the interaction of data-entry templates, user profiles and
business rules with the RDS.
The data groups used in the POC are described below:
A. Update
The Update element of the RDS distinguishes between estimates and actuals and to
distinguish between different budget rounds (e.g. Budget, MYEFO, etc). The CBMS
Solution also requires the functionality to distinguish between different versions within a
Budget Round.
In the Budget Estimates function, an update would comprise the period between two
centrally defined dates. For example, if the previous Budget Update was completed on the
28 February 2011 and the current Budget Update was completed on 10 May 2011, then the
Current Budget Update would comprise all adjustments up until the 10 May 2011 and the
Budget Reconciliation Tables (refer RFT Part Two Clause 10.6.1, Process 4.1.2) would be
based on all adjustments entered between the 28 February 2011 and the 10 May 2011.
The POC base data will include opening budget balances as at 28 February 2011. The
opening budget balances provide a point in time snapshot of all adjustments journals
entered before this date against the various elements of the Reference Data Set.
Shortlisted Tenderers will have the discretion as to how the base-level data is entered into
the POC. During the remaining POC scenarios, a number of new adjustments will be
entered in addition to the base-level data.
B. Period
The POC scenarios will span two financial years in elapsed time commencing in April 2011
and completing in December 2011.
To support the completion of all POC scenarios the following time periods will be required:
Year Data
Year
Required for
Budget
Estimates
Monthly
Profile
Actuals
Cash
Management Management
2009-10
2010-11
2011-12
2012-13
33
2013-14
2014-15
34
Month Data
Year
Required for
Budget
Estimates
Monthly
Profile
Actuals
Cash
July YTD
August YTD
September YTD
October YTD
November YTD
December YTD
January YTD
February YTD
March YTD
April YTD
May YTD
June YTD
Day Data
Year
Required for
Budget
Estimates
Monthly
Profile
Per Calendar
Actuals
Cash
Y
C. Account
The POC set-up data will include a representative multi-level subset of the current CBMS
chart of accounts. The POC chart of accounts will enable shortlisted Tenderers to
demonstrate:
The entry or submission of double entry journals for estimates (that is, applying debits
and credits to modify financial estimates) and the submission of financial statement
information for actual;
The submission of supplementary note information (e.g commitments);
The calculation of key fiscal aggregates; and
35
The derivation of cash flow statements.
Shortlisted Tenderers will have the flexibility to determine how the chart of accounts is
structured in order to meet the functional requirements for the CBMS Solution.
D. Program Structures
Under the current framework, Programs represent the central entity around which
government activities are organised. All transactions submitted to the CBMS Solution will
be entered against individual Programs.
Programs are either administered or departmental as designated in the Control Type
element.
Each Program roll-ups into one Outcome and one Sub-function. An example program
structure drawn from the POC set-up data is illustrated below:
Function
Sector
General
Government
Sector
Governance
Health
Portfolio
FMA
Health Portfolio
Agency
Department of
Health
Subfunction
Pharmaceutical
Benefits and
Services
Outcome
Outcome
Health Outcome 1
Health Outcome 2
Control Type
Control Type
Departmental
Administered
Program
Health Program
Support
Program
Program
Program
Medical Services
Pharmaceuticals
Community
Pharmacy
Subfunction
Medical Services
and Benefits
Subfunction
General
Administration Health
The POC set-up data includes an illustrative sample of Programs and related derived /
consolidated elements (e.g Outcome, Agency, etc) which will enable shortlisted Tenderers
to demonstrate consolidation and reporting at various levels during the relevant scenarios.
E. Reason Code
Within the Budget Estimates function, each estimate adjustment journal must be assigned
a Reason Code selected from a list of available Reason Codes. Reason Code information
is currently used for three main purposes:
to provide a consistent classification framework for each journal adjustment;
36
to distinguish government decisions from other adjustments. Adjustments with a

government decision Reason Code must also include a Measure code and description;
and
in the reporting of several consolidated reconciliation tables which show how certain
totals and derived aggregates have changed since the last published Budget Update.
The POC set-up data will include a representative subset of the current CBMS list of
Reason Codes.
Functional requirements
This activity will enable shortlisted Tenderers to demonstrate the following requirements:
Requirement
Importance
Description
FR-BM-006
Core
Support administrator definition of adjustment date range to be

included in a given budget update (i.e., the baseline financial
statements should be as at a given date (including all approved
estimate adjustments up to this date) while the reporting of budget
movements should be based on all adjustments entered for a given
date range).
FR-BM-023
Core
Storage of historical estimates for comparative purposes and analysis

in accordance with the Reference Data Set (RDS) at the time of
publication and on the current RDS to enable consistent time series.
FR-BM-049
Core
Allow for actuals by RDS to be prepared offline for bulk entry (e.g. via
manual creation of a file for upload).
FR-BM-050
Core
Allow for data to be entered via on-line direct entry by RDS.
FR-AA-017
Core
Enable the classification of accounts to enable the automatic

generation of defined reports including Agency financial statements
represented by Balance Sheet, Operating Statement, Cash Flow
Statement.
FR-AA-018
Core
Enable differences in account types, for example income and

expenditure accounts as distinct from balance sheet accounts as
distinct from notes information (balances supplied to assist in
production of notes to the financial statements), and the various subcategories within each category (e.g. revenue, expense, asset, liability,
cash flow, equity).
FR-AA-021
Core
Enable the configuration of relationships using dependent hierarchies

for RDS structures (e.g. Outcome-program hierarchy).
FR-AA-023
Core
Provide a tool and user interface to allow on-line, real-time viewing and
visualisation of RDS elements (i.e. code table style data, account
structure and hierarchy) including their interrelationships. The solution
is to include a user interface to maintain the RDS.
37

This activity will receive the following inputs:
Type
Inputs
Version
Reference
Set-Up
Set-up_Period_data
1.0
Appendix 2
Set-Up
Set-up_Account_data
1.0
Appendix 2
Set-Up
Set-up_Appropriation_data
1.0
Appendix 2
Set-Up
Set-up_Related-Entity_data
1.0
Appendix 2
Set-Up
Set-up_Program_data
1.0
Appendix 2
Set-Up
Set-up_Reason_code_data
1.0
Appendix 2
Set-Up
Set-up_Bank_accounts_data
1.0
Appendix 2
Data
Base_budget_estimates_data (to be
loaded before Scenario 2 - Opening
balance at 28/02/2011).
1.0
Appendix 2
Data
Base_Monthly Estimates_data (to be

loaded after Scenario 3 -2011-12
Profile at May 2011.).
1.0
Appendix 2
Data
Base_Annual_Actuals_data (To be
loaded after Scenario 3 2009-10
Annual Actuals).
1.0
Appendix 2
Data
Base_Available_Appropriation_data
(To be loaded prior to Scenario 4 2009-10 Available Appropriations).
1.0
Appendix 2
Data
Base_Monthly_Actuals (To be loaded

prior to Scenario 6 - July 2011).
1.0
Appendix 2

This activity will produce the RDS and base data which will be utilised in the subsequent
scenarios to the POC.
This activity will produce the following outputs:
Function
Outputs
Version
Reference
Report
Admin_COA_report
1.0
Appendix 4
Report
Admin_Program_hierarchy_report
1.0
Appendix 4
38
Non-Functional Requirements
Requirement
Importance
COTS Software
CBMS Solution
NFR-ARCH-004
Core
Provides the ability to make

Allows changes to the RDS and
changes to the RDS and business business rules without requiring a
rules without requiring a change to change to the source code.
the source code.
NFR-ARCH-005
Core
The standard architecture offers

the ability to change CBMS
Solution functionality and data
structures in an efficient and
effective way without
compromising the CBMS Solution
architecture and whilst maintaining
data integrity.
The ability to change functionality and

data structures in an efficient and
effective way without compromising the
CBMS Solution architecture and whilst
maintaining data integrity.
NFR-GINT-005
Core
The interface accommodates

changes to the RDS and CoA to
be applied without requiring
interface modification or recoding.
The interface accommodates changes

to the RDS and CoA to be applied
without requiring interface modification
or recoding.
NFR-SDM-002
Core
Provides for a customisable data

dictionary that defines the names
and definitions of business data
elements in the data model; using
the entities and definitions defined
in clause 11 (RDS), as a starting
point.
A data dictionary is to be developed

and maintained that defines the names
and definitions of business data
elements in the data model; using the
entities and definitions defined in clause
11 (RDS) as a starting point.
NFR-SDM-003
Core
The ability to create and maintain

a DTD that is consistent with
arbitrary elements of the business
data model.
The ability to create and maintain a

DTD that is consistent with arbitrary
elements of the business data model.
NFR-SDM-009 Highly Desirable The COTS Software allows entry

and preservation of text with rich
formatting (eg. bold, italics, dot
points).
The ability to enter and preserve text

with rich formatting (eg. bold, italics, dot
points).
Activity 1.2 Security and Application Administration Application /

Information access control
Finance requires the CBMS Solution to be accessed both internally and via the Internet.
Therefore the CBMS environment must be protected from unauthorised access and
malicious attack, while providing valid users access to undertake their authorised activities.
39
The shortlisted Tenderers architectural environment will be assessed by inspection after

the set-up of the POC and access will be granted and modified during the POC in
accordance with business requirements.
The application / information access control sub-function relates to the functionality
involved in ensuring that the CBMS Solution is capable of enforcing controls on information
and access to functionality, at a sufficient level of detail to support the security model.
A number of users will be accessing the CBMS solution over the following scenarios.
These users will have a number of different roles, requiring access to different aspects of
the solution to allow them to complete their tasks.
The following roles for each user type will be employed in the POC:
40
POC User Profiles

Budget Estimates
User Type
User Name
Single Agency
Portfolio
Cash Management
All Agencies
Agencies
Single
Portfolio
Agency
Agencies
All Agencies
Actuals
Single Agency
Portfolio
All Agencies
Agencies
Portfolio Department User
Agency_Usr
Create/Update Read
(e.g Health_Usr) Read
None
Create/Update Create/Update None

Read
Read
Create/Update Read
Read
None
Portfolio Department
Approver
Agency_Mgr
Read,
(e.g Health_Mgr) Authorise
Read
None
Read,
Authorise
None
Read,
Authorise
Read
None
Portfolio Agency (excl

Portfolio Department)
Agency_Usr
Create/Update None
(e.g Sports_Usr) Read
None
Create/Update Read
Read
None
Create/Update None
Read
None
Agency Approver (excl

Portfolio Department)
Agency_Mgr
Read,
(e.g Sports_Mgr) Authorise
None
Read,
Authorise
None
None
Read,
Authorise
None
Finance divisional officer (e.g

Finance Budget Officer)
FDO_Portfolio
(e.g FDO_Law)

Read
Read
Authorise
Authorise
Read
Read
None

Read
Read
Authorise
Authorise
Finance divisional manager
FDM_Portfolio
(e.g FDM_Law)
Read,
Authorise
Read, ,
Authorise
None
Read
Read
None
Read,
Authorise
Finance analyst
Finance_Anyt
Read
Read
Read
Read
Read
Read
Read
Finance central processing

officer
Finance_Cpo
Create/Update Create/Update Create/Update Create/Update Create/Update Create/Update Create/Update Create/Update Create/Update

Read
Read
Read
Read
Read
Read
Read
Read
Read
None
Read,
Authorise
Read
Read, ,
Authorise
Read
None
Read
41
Budget Estimates
User Type
User Name
Single Agency
Portfolio
Cash Management
All Agencies
Agencies
Finance central processing

approver
Finance_Cpa
Data administration
Finance_Admin
Read,
Authorise
Admin
Single
Portfolio
Agency
Agencies
All Agencies
Actuals
Single Agency
Portfolio
All Agencies
Agencies
Read,
Authorise
Read,
Authorise
Read,
Authorise
Read,
Authorise
Read,
Authorise
Read,
Authorise
Read,
Authorise
Read,
Authorise
Admin
Admin
Admin
Admin
Admin
Admin
Admin
Admin
Key:
Create/Update User can create or update a measure, budget adjustment, cash draw down request, etc in the CBMS Solution;
Read User can view a measure, budget adjustment, cash draw down request, etc in the CBMS Solution;
Authorise User can approve a measure, budget adjustment, cash draw down request, etc to the next stage in the approval process (i.e from draft to
agency authorised and from agency authorised to finance validated);
Admin - User has access to change structures through the data administration function (e.g. changes to the RDS).
42
Requirement
Importance
Description
FR-AA-037
Core
Security access controls are to ensure that users only have access to the
CBMS Solution functions and data for which they have authorisation.
FR-AA-038
Core
Application access controls are to allow the modification of access across

multiple dimensions (eg. deny all users access to specific functions, or
grant access to an entire portfolio).
FR-AA-039
Core
Application access controls are to allow for a combination of role based

security that also takes into Account organisational structures (eg,
Agencies and Portfolios) and allows for roles that have access across
organisational boundaries.
FR-AA-040
Highly
Desirable
FR-AA-041
Core
The access management UI is to include the ability to create and define

user roles that:
grant and deny access to specific CBMS Solution functions;
grant and deny access to specific subsets of data within a
function (at the Agency level, and also at a more granular level
such as control types and Measures within an Agency); and
define different types of access to data within a function, such as
create, read, update, and authorise (see example 1 following).
FR-AA-044
Core
The access management UI is to support the following functionality;

create a user profile;
create a user profile from a copy of an existing profile;
amend a user profile;
delete a user;
activate a user; and
deactivate a user.
FR-AA-045
Core
The access management UI is to include the ability to grant or deny an

authorised user access to one or more roles.
FR-AA-052
Core
Users, roles and access rights are to be defined in one place and applied
consistently across all components of the CBMS Solution including
reporting; i.e. the administrator should not have to create separate users
for separate functions.
FR-AA-053
Core
Ability to be able to enforce separation of duties so that incompatible roles

are not given to the same user.
A simple and efficient UI is required that supports the existing CBMS

access management processes and forms.
43

Type
Inputs
Version
Set-Up
Set-up_User_roles_data
1.0
Reference
Appendix 2

This activity will produce the security user profiles which will be utilised in the subsequent
This activity will also produce the following outputs:
Type
Outputs
Version
Report
Admin_user_roles_report
1.0
Reference
Appendix 4
Non-Functional Requirements
Requirement
Importance
COTS Software
CBMS Solution
NFR-REP-012
Core
Access controls to reports is to

be based on the same security
access model implemented for
the transactional data.
Access controls to reports is to be

based on the same security access
model implemented for the
transactional data.
NFR-AAC-001
Core
Provides a single sign-on to CBMS

which integrates with the existing
Finance Windows AD-based
internal authentication solution.
A single sign-on solution which

integrates with the existing Finance
internal authentication solution is
required for Finance users.
Note that multi factor

authentication is not required for
CBMS access from within the
Finance network.
Note that multi factor authentication is

not required within the Finance
network.
NFR-AAC-002
Core
Provides identification,
authentication and authorisation
for logical access controls
compliant with the ISM (in
particular, sections related to
logical access controls).
Identification, authentication and

authorisation for logical access controls
are to comply with the ISM (in
particular, sections related to logical
access controls).
NFR-AAC-004
Core
Capable of enforcing the Finance

password policy specified in the
Finance Information Security
The access control and authentication

solution is to be capable of enforcing
the Finance password policy specified
in the Finance Information Security
44
Requirement
Importance
COTS Software
Policy.
NFR-AAC-007
Core
CBMS Solution
Policy.
Employs and enforces the

The following principles are to be
following principles with respect to enforced by the CBMS Solution with
the implementation of user roles: respect to the implementation of user
roles:
1. users are to be uniquely
identified within the CBMS
1. users are to be uniquely identified
Solution;
within the CBMS Solution;
2. users will be identified and
2. users will be identified and
authenticated before access to
authenticated before access to the
the CBMS Solution is granted:
CBMS Solution is granted:
a. for users on the Finance
a. for users on the Finance LAN,
LAN, single factor
single factor authentication is
authentication is required (ie.
required (ie. UserID and
UserID and password pair);
password pair);
b. for users connecting from an
environment certified to
environment certified to handle
handle data up to and
data up to and including
including PROTECTED;
PROTECTED; single factor
single factor authentication is
authentication is required (ie.
required (ie. UserID and
UserID and password pair); and
password pair);
c. for users connecting from any
c. for users connecting from
other environment that has a
any other environment that
classification lower than
has a classification lower
PROTECTED; multi-factor
than PROTECTED; multiauthentication is required (eg. via
factor authentication is
a token-based certificate plus a
required (eg. via a tokenUserID and password pair).
based certificate plus a
3. CBMS Solution users are to be
granted the least amount of
3. Users are to be granted the
privileges required to undertake
least amount of privileges
their specific duties; and
required to undertake their
4. Role / Group access is to be
specific duties; and
sufficiently granular as to enforce
4. Role / Group access is to be
need-to-know.
sufficiently granular as to
Note that for users on the Finance LAN,
enforce need-to-know.
a single sign-on solution which
Note that for users on the
internal authentication solution is Highly
Finance LAN, a single sign-on
solution which integrates with the Desirable (refer NFR-AAC-001).
existing Finance internal
authentication solution is Highly
45
Requirement
Importance
COTS Software
CBMS Solution
Desirable (refer NFR-AAC-001).

NFR-AAC-011
Core
Limits users access to the

services that they have been
specifically authorised to use.
Users will only have direct access to

the services that they have been
NFR-AAC-016
Core
User access will be granular

enough to provide access to a
combination of portfolios,
Agencies, control types, roles,
and modules.
User access will be granular enough to

provide access to a combination of
portfolios, Agencies, control types,
roles, and modules.
NFR-AAC-011
Core
Limits users access to the services Users will only have direct access to
the services that they have been
that they have been specifically
authorised to use.
NFR-AAC-016
Core
User access will be granular

enough to provide access to a
combination of portfolios,
Agencies, control types, roles, and
modules.

portfolios, Agencies, control types,
roles, and modules.
Activity 1.3 Application Administration Business Rules

This sub-function describes the facility to support the management of business rules used
to control processes within the CBMS Solution. The CBMS Solution administrator will
ensure that business rules have been centrally stored and managed so that they are
applied consistently across all functions of the CBMS Solution.
Shortlisted Tenderers will load business rules during the set up scenario that will be applied
to data entered and processed over the following scenarios.
Another set of business rules is required for consolidation purposes. This set of business
rules identifies which accounts are to be matched when agencies identify related-entity
transactions. It also identifies which account is to be adjusted when the two agencies to a
related-entity transaction differ in the amount they report as related-entity.
This activity will enable shortlisted Tenderers to demonstrate the following:
Requirement
FR-AA-001
Importance
Core
Description
Enable the creation and recording of accounting and validation rules
including the user defined rules, a unique identifier and a user-friendly
description of what the rule does.
46
Requirement
Importance
Description
FR-AA-002
Core
Enable the creation of business rules to apply to different combinations of

the RDS (eg. restrict Accounts to certain Agencies) and across functions
(eg. Budget and Actual)
FR-AA-004
Core
Enable the recording of audit information upon entry or change to

accounting or validation rules including date / time, version, user and
session details.
FR-AA-008
Core
Has a centralised business rules management capability, such that a

single business rule can be created once and reused consistently
throughout the various CBMS Solution functions and interfaces.
FR-AA-009
Core
Business rules are to be able to be changed via a UI without requiring

program coding changes.
FR-AA-010
Core
The ability to promote business rule changes into production independent

of a standard code change release.
FR-AA-011
Core
The ability to promote business rule changes into production within a

defined time-frame consistent with business continuity requirements (eg.
two hours for changes to the RDS in a Budget update).
FR-AA-012
Core
The ability to toggle business rules on and off, and to set the level of
impact for breaking individual rules (pass/fail/warning).
FR-AA-013
Core
Support the maintenance of a library of business rules.

Type
Inputs
Version
Reference
Set-Up
Set-up_Business_rules
1.0
Appendix 2
Set-Up
Set-up_elimination_matching_rules
1.0
Appendix 2
Set-Up
Set-up_derivation_rules
1.0
Appendix 2

This activity will produce the business rules which will be utilised in the subsequent
47
Activity 1.4 Application Administration User Interface Modification

During the POC, shortlisted Tenderers will be required to create data entry templates to
reflect data entry requirements that are presented in the subsequent scenarios to the POC.
following scenarios.
Requirement
Importance
Description
FR-AA-056
Core
Ability to define and manage data entry and reporting templates.
FR-AA-057
Core
Ability to have version control and an audit trail for modifications to data
entry templates.
FR-AA-058
Highly
Desirable
Ability for authorised users to create / maintain user-defined templates for

data entry with associated data validation rules attached to each field.
FR-AA-059
Highly
Desirable
Ability for authorised users to edit / modify data entry templates.
FR-AA-061
Desirable
Ability to create a new data entry template from copy of an existing one.
FR-AA-062
Desirable
Ability to store and retrieve data entry templates centrally in a template

library and assign access to different group of users.

Type
Inputs
Version
Reference
Template (fields)
Budget_estimates Data entry template
1.0
Appendix 3
Template (fields)
High_level_budget_impact_template
1.0
Appendix 3
Template (fields)
Monthly_Profile_Data_entry_template
1.0
Appendix 3
Template (fields)
Monthly_Actuals_Data_entry_template
1.0
Appendix 3
Template (fields)
Annual_Actuals_Data_entry_template
1.0
Appendix 3
Template (fields)
Cash_Drawdown_template
1.0
Appendix 3
Template (fields)
Measures_template
1.0
Appendix 3
Template (fields)
Cash_receipts_template
1.0
Appendix 3
Template (fields)
Cash_journal_template
1.0
Appendix 3
Template (fields)
RBA_Upload_template
1.0
Appendix 3
Template (fields)
Approp_adjustments_template
1.0
Appendix 3
48

This activity will produce the data entry templates which will be utilised in the following
scenarios.
Activity 1.5 Application Administration Report definition

During the POC, shortlisted Tenderers will be required to define certain reporting templates
which will be used to show outputs in the subsequent scenarios to the POC.
Requirement
Importance
Description
FR-RA-001
Core
Enable production of print-ready statements for Appropriation Bills,

selected tables within the Budget Papers (eg. Budget Papers No. 1 through
to No. 4, and PBS), Actuals reporting, and associated documentation to
defined template guidelines.
FR-RA-003
Core
Ability to retrieve formatted textual information to facilitate production of the

Budget documentation (eg. Appropriation Bills).
FR-RA-005
Core
Enable both time and version comparisons of financial data across

functions (eg. month-over-month, Budget vs. Actual, consolidation 1 vs.
consolidation 2).
FR-RA-006
Core
Enable pre-defined variables-driven report specification across multiple

dimensions (eg. Programs, functions, etc).
FR-RA-007
Core
Enable the production of consolidated financial statement reports to stated

external reporting standards (eg. Government Financial Statistics (GFS)
standards, Generally Accepted Accounting Principles (GAAP)).
FR-RA-010
Core
Ability to change statutory report templates and maintain version control of

templates without need for program coding changes.
FR-RA-013
Core
Ability to produce QA reports, including exception reporting and audit trails.
FR-RA-043
Core
Provide the capability to save reports generated for reuse via library style
functionality.
FR-RA-044
Core
Ability to change user-defined report templates and maintain version control

of templates without the need for program coding changes.
FR-AA-056
Core
Ability to define and manage data entry and reporting templates.
49

Type
Inputs
Report (definition)
Estimates_Consolidated_income_statement
Actuals_Consolidated_income_statement
Estimates_Consolidated_balance_sheet
Actuals _Consolidated_balance_sheet
Estimates_Consolidated_cash_flow_statement
Actuals _Consolidated_balance_sheet
Expenses_by_sub-function_report
Monthly_budget_variance_report
Monthly_estimates_report
Monthly_OPA_reconciliation_report
PBS_departmental_income_statement
PBS_admin_balance_sheet
PBS_budgeted_expenses_by_program
Actuals_income_statement
Actuals_balance_sheet
Elimination_matching_report
Measure_code_report
2011-12_budget_approp_bill_one
High_level_budget_impact_report
Measures_table_report
Budget_estimates_adjustment_report
System_validation_report
Measures_data_reconciliation_report
Admin_COA_report
Admin_program_hierarchy
Actuals_journal_trail
2011-12_available_approp
Cash_transaction_detail_report
RBA_payment_file_report
AOFM_payment_register_report
Daily_RBA_reconciliation
Approp_limit_detail_report
CBMS_OPA_reconciliation_report
Data_submission_report
Estimates_UC_reconciliation_report
Estimates_FB_reconciliation_report
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Report (definition)
Version
Reference
1.0
Appendix 4
1.0
Appendix 4
1.0
Appendix 4
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4
Appendix 4

This activity will produce the reporting templates which will be utilised in the subsequent
50
Activity 1.6 Application Administration Budget process and system

related guidance
Shortlisted Tenderers will need to provide documentation to assist users as they progress
through the subsequent scenarios to the POC.
Requirement
FR-AA-063
Importance
Core
Description
Ability to create, update, publish and remove on-line contextual help and
other user documentation relating to the CBMS Solutions operation. Eg,
training material or policy memoranda.
51
11
Scenario 2: Decision Making and Budget Estimates Data Entry

This scenario covers the business processes associated with Government decisions on
new policy proposals, the associated measures information that is captured within the
CBMS Solution, and entry of the detailed financial impacts of those decisions. It also
covers the entry of Budget Estimates adjustments that are driven by reasons other than a
Government decision.
In this Scenario, the shortlisted Tenderers POC will be evaluated to assess the shortlisted
Tenderers ability to provide a solution which supports:
the capture and reporting of Government decisions, including narrative;
entering or uploading multi-year budgeted financial data against a predefined RDS; and
data integrity through system-based validations, reconciliations and approval controls.
Activity
RFT Part Two

Reference
Activity 2.1 Assign Measures Code
Decision Making
Clause 10.3
Activity 2.2 Enter High Level

Budgetary Impacts
Decision Making
Clause 10.3
Activity 2.3 Draft Measures Text
Decision Making
Clause 10.3
Management of Budget
Estimates
Clause 10.4.1
Activity 2.5 Reconcile High Level

Measures Data
Decision Making
Clause 10.3
Activity 2.6 Run Measures Tables
Statutory Reporting
Clause 10.6.1
52
Activity 2.1 Assign Measures Code (Process 1.2 Functional Requirement

Map 1)
Decision Making (Functional Requirement map 1)
Finance/Treasury
CBMS
1.1
Provide coordination
comments and
agree costings
NPP approved by
Government?
Yes
1.2
Assign measure
code
1.3
Enter high-level
budgetary impacts
New Policy Proposal
No
1.4
Draft measures
description text
1.5
Consult with
agencies
2.1
Budget
Estimates
Agencies
4
Reporting and
Analysis
The scenario starts with the Government making two decisions for inclusion in the
2011-12 Budget. These are:
following a large number of cases of people catching colds in 2010-11, the

Government has agreed to fund a new cold and flu drug called no sneeze. This
drug will be administered by the Department of Health (Health).
following incidents at several overseas events, the Government has decided to

prevent the importation and use of plastic trumpets at sporting events throughout
the country. This is a cross-portfolio measure lead by the Department of Law and
Order (DLO), with funding also provided for Health and Sports Australia.
This activity involves the following steps:

1. Once the Government has made the decisions above, the Finance central processing
officer (Finance_Cpo) creates a unique identifier for each decision, known as a
Measures Code. The Measure Codes for these decisions have a unique identifier that:
distinguishes the type of decision (an expense, capital or revenue decision); and
the decisions were made as part of the 2011-12 Budget.
2. When creating the Measure Codes, the Finance_Cpo will also enter details related to
the Measure, such as the lead agency and whether it the decision is ongoing,
terminating or lapsing, etc.
53
3. Once the Measure Codes have been created, the Finance_Cpo progresses the
measure codes to the Finance central processing approver (Finance_Cpa) for approval.
Requirement
Importance
Description
FR-DM-001
Core
Capture information on Measures via reference to a Measure code.
FR-DM-002
Core
Assign a unique reference code (Measure code) for Government decisions

(Measures).
FR-DM-005
Core
Support a multi-step approval process for Measures.
FR-DM-004
Core
Support the classification of Measures (eg. type, lead portfolio, package of

Measures).
FR-DM-011
Core
Capture non-financial information on Measures such as date decided,

authority, reference to proposal, lapsing/terminating period, indexation
status and parameter.

Type
Inputs
Version
Reference
Data
2011-12_Budget_Decisions
1.0
Appendix 2
Template
Measures_template
1.0
Appendix 3
Security
User profile for:

Finance_Cpo
Finance_Cpa
1.0
Per Scenario 1, Activity 1.2

Output

Type
Outputs
Version
Data
2011-12_Budget_Decisions (including
Measure codes)
1.1
Report
Measure_Code_report
1.0
Reference
Appendix 2
Appendix 4
54
Activity 2.2 Enter High Level Budgetary Impacts (process 1.3 Functional
Requirement Map 1)
Finance/Treasury
CBMS
1.1
comments and
agree costings
NPP approved by
Government?
Yes
1.2
Assign measure
code
1.3
Enter high-level
budgetary impacts
New Policy Proposal
No
1.4
Draft measures
description text
2.1
Budget
Estimates
1.5
Consult with
agencies
Agencies
Reporting and
Analysis

1. Following creation of the Measure Codes, Finance_Cpo enters the high level budgetary
impacts (the underlying cash and fiscal balance impact) of the Governments decisions.
2. Once entered, the respective high level budgetary impacts are approved by
Finance_Cpa.
Requirement
FR-DM-010
Importance
Desirable
Description
Reflect the high-level budgetary impact of Measures on Budget Estimates.

Type
Inputs
Version
Reference
Data
1.1
Per Activity 2.1 output.

Appendix 2.
Template
High_level_budget_impact_template
1.0
Appendix 3
55
Type
Inputs
Security
User profile for:

Finance_Cpo
Finance_Cpa
Version
1.0
Reference
Output

Type
Outputs
Version
Data
2011-12_Budget_Decisions (including
high level impacts)
1.2
Report
High_level_budget_impact_report
1.0
Reference
Appendix 2
Appendix 4
Activity 2.3 Draft Measures Text (process 1.4 Functional Requirement

Map 1)
Finance/Treasury
CBMS
1.1
comments and
agree costings
NPP approved by
Government?
Yes
1.2
Assign measure
code
1.3
Enter high-level
budgetary impacts
New Policy Proposal
No
1.4
Draft measures
description text
1.5
Consult with
agencies
2.1
Budget
Estimates
Agencies
4
Reporting and
Analysis
Following the creation of the Measure Codes, the relevant Finance divisional officers
(FDO_Health and FDO_DLO) commence the drafting of text to explain the decisions made
by Government. This text describes the intended overall effect of the Measure, identifies
who the Measure will affect and relates how these parties will be affected. The Measure
description also identifies and explains the estimated financial effects of the Measure.
56

1. FDO_Health and FDO_DLO drafts measures text for each decision. Once each user
has drafted their respective Measures text, it is sent to their managers for clearance.
2. The draft Measures text has had an initial review and clearance by FDM_Health and
FDM_DLO. However, in light of a slight change in approach to presenting measures
descriptions, FDM_Health considers that the text for the no sneeze decision should be
revised slightly prior to being sent to Treasury for comment.
3. Rather than sending the Measures text back to the initial drafter, this revision is made
by the FDM_Health prior to approval. An audit trail captures that the text has been
amended at the approval stage.
Requirement
Importance
FR-DM-005
Core
FR-DM-012
Desirable
Description
Support a multi-step approval process for Measures.
Capture descriptive text (including punctuation and formatting) for a
Measure description for publication in Budget Paper No. 2 and associated
Budget documents.

Type
Data
Inputs
Template
Measures_template
Security
User profile for:

FDO_Health
FDO_DLO
FDM_Health
FDM_DLO
Version
1.2
Reference
As per Activity 2.2 output.
Appendix 2
1.0
1.0
Appendix 3
Output

Type
Outputs
Version
Reference
Data
1.3
Appendix 2
Report
Measures_table_Report
1.0
Appendix 3
57
Activity 2.4 Enter Budget Estimates (process 2.1.2.1 2.1.2.6 Functional

Requirement Map 2.1.2)
Agency Submits Estimates (Functional Requirement Map 2.1.2)
Agency
Pass system
validations?
No
CBMS
System validation
report
Yes
Finance AAUs
2.1.2.3
Agency authorises
measure adjustment
2.1.2.2
Agency submits
Estimate Variations
into CBMS
2.1.2.1
Agency prepares
adjustment for
Government decision
Check if consistent
with Finance high
level measure
details
Decision
Making
2.1.3
Finance QAs
estimates
Decision
Making
2.1.2.4
Agency prepares
parameter and other
adjustment
Consult Finance
Estimates
Agency
Finance
Variations
Authorised
Validated
Unauthorised
2.1.3
Finance QAs
estimates
2.1.2.5
Agency submits
parameter and other
adjustment journal into
CBMS
Agency/Finance
No
Pass system
validations?
System validation
report
Yes
2.1.2.6
Agency authorises
parameter and other
adjustment
As the decisions made by Government on the cold and flu drug and plastic trumpets have
financial impacts, the relevant agencies are required to enter the detailed financial impacts
of these decisions into CBMS. Further, all Agencies are required to enter adjustments to
reflect changes to their budget estimates that come from changes in parameters and other
movements.
1. The Health has chosen to enter their measures with a series of other decisions and
parameter adjustments. For efficiency, they have chosen to enter their data via a flatfile
upload via a rich GUI that facilitates working in off-line mode.
2. As Sports and DLO only have a small number of adjustments, they have chosen to
enter information via direct entry. The DLO submits their information via a rich GUI.
Sports submits their information via a web browser UI.
3. While the Department of Public Services (DPS) and the Public Court do not have any
new decisions, they are uploading a flatfile to reflect parameter and other movements in
their Budget Estimates via the web browser UI.
4. Although not within the General Government Sector, Utilities must also submit
estimates, which they do through a flatfile upload via the web browser UI.
5. Once adjustments have been entered by Agency users and cleared by Agency
approvers within each of the Agencies, they are then sent through to Finance for quality
assurance and approval.
58
6. Once the FDO_Health, FDO_DLO and FDO_Services are satisfied that their respective
Portfolios adjustments have been:
a.
b.
c.
allocated to the appropriate elements of the RDS (for example, the correct
Program is used);
have the correct financial impacts; and
have the appropriate authority.
The data is approved for inclusion in the consolidation and production of the statutory
reports.
Requirement
Importance
Description
FR-BM-004
Core
Capture Budget Estimates for the current year, the budget year, and a predefined number of forward years (currently up to 15 years).
FR-BM-005
Core
Support adjustments that cover one or more financial periods (eg. where
funding for a Program spans across a number of years).
FR-BM-006
Core
Support administrator definition of adjustment date range to be included in

a given Budget update (i.e., the Budget Estimates will be as at a given
date (including all approved Estimate adjustments up to this date) while
the reporting of budget movements will be based on all adjustments
entered for a given date range).
FR-BM-007
Core
Automatically populate Estimates for subsequent years where an

adjustment results in changes to the balance sheet and associated notes
(eg. asset movement tables).
FR-BM-008
Core
Support adjustments that modify Estimates using a double entry journal

(that is, applying debits and credits to modify financial Estimates).
FR-BM-009
Core
Capture information against various aspects of the RDS (eg. Accounts,

Program, Appropriation type, SPPs, Administered/Departmental control,
etc) for each adjustment to enable production of Appropriation Bills and
selected tables within the Budget Papers (eg. Budget Papers No. 1
through to No. 4 and PBS).
FR-BM-011
Core
Allow for adjustments to be prepared offline for bulk entry (eg. via manual
creation of a file for upload).
FR-BM-012
Core
Allow for adjustments to be entered via on-line direct entry.
FR-BM-014
Core
Record adjustment information that spans beyond the forward Estimates

period, such as Program commencement and expiry date, date of review
of Government decisions, and long-term financial Estimates.
FR-BM-019
Core
Categorise adjustments by various types (eg. Agency, cash flow

adjustments, consolidation adjustments, etc).
FR-BM-021
Core
Ability to enter adjustments which only impact on the Cash Flow Statement
and/or other derived Measures (eg. to override a derived impact or
reclassify amounts between cash flow classifications).
59
Requirement
Importance
Description
FR-BM-022
Core
Ability for each adjustment to be uniquely identified (eg. allocation of a

reference number)
Ensure individual adjustments conform to pre-defined validation rules and
controls (eg. accounting rules, business process rules).
FR-BM-024
Core
FR-BM-025
Core
Capture audit information for each individual adjustment, including

classification codes (eg. Reason, Measure code) and a textual description
for the reason why an adjustment is being applied, the user entering the
adjustment, and the time of the adjustment.
FR-BM-026
Core
Enforce a multi-step approval (eg. draft, authorised, validated) and deletion

processes for adjustments that are consistent with pre-defined business
rules (eg. approved adjustments cannot be changed or deleted, previous
periods cannot be changed).
FR-BM-027
Core
Provide the ability for Finance and Agencies to progress adjustments

through the approval process consistent with business logic, and to
capture the reasons for doing so.
FR-BM-028
Core
Support the reporting, extraction and printing of adjustments (eg. for offline
processing, records management).
FR-BM-029
Core
Automatically calculate the impact of adjustments on key aggregates as

adjustments are created (eg. the underlying cash balance and fiscal
balance).
FR-BM-030
Core
Automatically derive the effect of adjustments on internal models (eg.

system-derived cash flow modelling).
FR-BM-031
Core
Ability to report status against the approval stages (eg. number of

adjustments that are Finance validated).
FR-BM-032
Core
Ability to view the impact of adjustments on financial statements for

different approval steps (eg. draft, authorised and validated).
FR-BM-033
Core
Ability to report (list) adjustments by various elements of the RDS (eg.

Program, Reason code, Measures code) and/or by an element of RDS (eg.
Function, Program, Account, etc).
FR-BM-037
Core
Maintain and report an audit trail of all adjustments for a given period/date
range, including the ability to filter/sort the trail by Agency categorisation
(eg. consolidation, etc).
60

Type
Inputs
Data
2011_12_Budget_Estimates_Data
Version
Reference
1.0
Appendix 2
Health_2011 Budget Estimates data

(upload)
DLO_2011 Budget Estimates data
(Data entry)
Sports_2011 Budget Estimates data
(Data entry)
DPS_2011 Budget Estimates data
(upload)
Court_2011 Budget Estimates data
(upload)
Utilities_2011 Budget Estimates data
(upload)
Data
2011_12 Budget Decisions (including

Measure Codes)
1.1

Output
Template
Budget Estimates Data entry template
1.0
Appendix 1
Rule
Budget Estimates Business Rules
1.0

Output
Security
User profile for:

Health_Usr
Health_Mgr
DLO _Usr
DLO _ Mgr
Sports _Usr
Sports _ Mgr
DPS _Usr
DPS _ Mgr
Court _Usr
Court _ Mgr
Utilities _Usr
Utilities _ Mgr
FDO_Health
FDO_DLO
FDO_Services
1.0

Output
61

Type
Outputs
Version
Reference
2011-12_Budget_Estimates_data (all
agencies) (with Measure codes)
1.1
Refer to input for Activity 2.4

(unchanged)
Report
Budget_Estimates_adjustment_report
1.0
Appendix 3
Report
1.0
Appendix 3
Data
Appendix 2
Activity 2.5 Reconcile High Level Measures Data (process 2.1.2.7

Functional Requirement Map 2.1.2)
Agency
Pass system
validations?
No
Yes
2.1.2.2
Agency submits
Estimate Variations
into CBMS
2.1.2.1
Agency prepares
adjustment for
Government decision
Decision
Making
2.1.3
Finance QAs
estimates
Decision
Making
2.1.2.4
Agency prepares
parameter and other
adjustment
Finance AAUs
CBMS
System validation
report
2.1.2.3
Agency authorises
measure adjustment
2.1.2.7
Check if consistent
with Finance high
level measure
details
Consult Finance
Estimates
Agency
Variations
Authorised
Unauthorised
2.1.3
Finance
Validated
Finance QAs
estimates
2.1.2.5
Agency submits
parameter and other
CBMS
Agency/Finance
No
Pass system
validations?
System validation
report
Yes
2.1.2.6
Agency authorises
parameter and other
adjustment

1. The high level Measures information (entered in Activity 2.2) is reconciled within CBMS
against the detailed information entered by Agencies (entered in Activity 2.4).
2. Once data has been entered at both the high level and detailed agency level, the
Finance_Cpo runs a report in CBMS to highlight all measures that do not have
matching financial information.
3. For measures that do match, the Finance_Cpo restricts access to that Measure Code
to ensure no further data is entered against it.
62
Requirement
Importance
Description
FR-DM-009
Core
Ability to restrict access to a Measure Code after it has been created.
FR-RA-013
Core

Type
Inputs
Data
Version
1.3
Reference
Output.
Appendix 2.
Data
2011-12_Budget_Estimates_data
1.1

Output.
Appendix 2.
Security
User profile for:

Finance_Cpo
1.0

Output

Type
Outputs
Report
Measures_data_reconciliation_report
Version
1.0
Reference
Appendix 3
63
Activity 2.6 Run Measures Tables (process 4.1.3.1 4.1.3.4 Functional

Produce Measures Tables (Functional Requirement Map 4.1.3)
Finance/Treasury
CBMS
Decision
Making
UEFO
PEFO
Budget
Estimates
MYEFO
4.1.3.1
Run measure tables
4.1.3.2
QA measure data and
text
Budget Paper 2
2.1
Passes QA?
Yes
4.1.3.3
Group and/or
rearrange measures
No
Change numbers
2.1
Budget
Estimates
4.1.3.4
Prepare draft budget
papers
4.1.3.5
Review and sign-off
budget measures
Passes review?
Yes
No
Change text
1
Decision
Making

1. Measures tables are run from CBMS by the Finance_Cpo, displaying the title, financial
impacts and description text of each Measure.
2. The key financial aggregates derived from Agencies entry of detailed financial
information for each measure (entered in Activity 2.4) is combined with the associated
Measures text (entered in Activity 2.3) to produce the Measures tables.
3. It has been decided that cross portfolio Measures will be presented first, with other
Measures following. As a result, Finance_Cpo sets the order in the report so that the
banning of plastic trumpets will be the first Measure in the Measures tables, followed by
the no sneeze drug. Further, the funding provided to Sports Australia has been
determined as not for publication as is reflected accordingly in the financial impacts of
the measures table.
64
Requirement
Importance
Description
FR-RA-017
Core
Allow users to report on Measures.
FR-RA-018
Core
Ability to group and order Measures and associated narrative prior to

producing Measures tables, incorporating the ability for ASCII text and
formatting and copying and pasting Measures text from Microsoft Word.
FR-RA-019
Core
Ability to produce Measures tables in print-ready formats including text.
FR-RA-020
Core
Ability to suppress financial impacts where sensitivities such as

commercial-in-confidence require that numbers are not disclosed.

Type
Inputs
Version
Reference
Data
1.3

Output. Appendix 2.
Data
1.1

output. Appendix 2.
Security
User profile for:

Finance_Cpo
1.0

Output

Type
Outputs
Report
Measures_table_report
Version
1.1
Reference
Appendix 3
65
12
Scenario 3: Financial Consolidation & Reporting of Budget Estimates

Consolidation involves the aggregation of data submitted by agencies for both Estimates
and Actuals by Finance. The financial statements are combined on a line-by-line basis by
adding together like items of assets, liabilities, equity, income and expenses. The CBMS
Solution will automatically match and eliminate related-entity transactions. Consolidation
journals are posted to eliminate related entity amounts and to adjust for inconsistent
accounting policies to form a consolidated set of financial statements.
The financial consolidation process occurs during the Budget Estimates, monthly profile and
actual (monthly and annual) processes. While the data and period to be consolidated
differs between each of the above functions, the process by which the consolidation is
performed is largely the same for each function. This scenario is concerned with the
consolidated of the budget estimates entered in Scenario 2.
In this scenario, the shortlisted Tenderer will be evaluated to assess the ability to provide a
solution which supports:
the posting of consolidation at various levels within the consolidation hierarchy;
the consolidation of financial information according to different consolidation

hierarchies;
the automatic matching and elimination of related-entity transactions, including the

identification and automatic adjustment of mismatched related entity transactions;
the production of consolidated statutory reports for various elements and combinations
within the RDS, including consolidated reports by Sector and Function; and
the ability to define, generate and save ad-hoc reports in real-time, including reports
drawn from different sources (i.e. budget estimates, cash management, actuals, etc).
Activity
RFT Part Two

Reference
Activity 3.1 Post Manual Consolidation

Journals
Financial Consolidation
Clause 10.4.4 (a)
Clause 10.4.4 (b)
Activity 3.3 Produce Consolidated Financial

Statements
Clause 10.6.1 (a)
Activity 3.4 Produce portfolio budget

statements
Clause 10.6.1 (d)
Activity 3.5 Produce appropriation bills
Clause 10.6.1 (e)
66
Activity 3.1 Post Manual Consolidation Journals (Process 2.4.1 Functional

Requirement Map 2.4)
Activity 3.1 Post Manual Consolidation Journals (Process 2.4.1 Functional Requirement Map 2.4)
CBMS
Finance
Consolidate Financial
Statements
2.1
Finance
QA Consolidated Financial
Statements
2.4.3
2.4.2
Budget Estimates
2.2
2.4.1.1
Prepare agency
adjustment journals
2.4.1.2
Prepare standing
consolidation
journals
2.4.1.3
Post journals to
CBMS
2.4.2
Consolidate Financial
Statements
Monthly Profile
Agency data
2.3
Consolidation
journals
Adjusted
Actuals Management
In commencing the consolidation Finance may post consolidation journals at the Program,
Agency or sectoral level. These journals adjust agency submitted data but do not overwrite
the agency submitted data (that is, data can be viewed pre and post adjustment).
This scenario starts with an initial set of 2011-2012 Budget Estimates data. A consolidated
adjustment journal is required to reclassify funding to the Department of Law and Orders
Departmental Outcome 1, sub function Other Public Order and Safety.
Law and Order has advised that the set of 2011-2012 Budget Estimates data is complete,
however Department of Finance are required to reclassify funding for costal patrol boats
from capital spending to supplier expenses.
1. The creation of a consolidated adjustment journal for the Department of Law and Order
for the Budget Estimate year 2011/12 (i.e. as at 30 June 2012) via direct entry (using
the consolidation adjustment for Budget Estimates data entry template and 2011-12
Budget consolidation adjustments data). The journal must cover Outcome 1, sub
function Other Public Order and Safety.
2. The Finance central processing officer (Finance_Cpo) enters the consolidation journal
which must pass the pre-defined business and validation rules. The status of the
journal would now be Agency Authorised.
3. The Consolidation Scenario will prepare budget estimates for the crown entity. The
Crown entity shows the balance of the Governments central bank account (the Official
Public Account) as well as transfers to and from agencies through the estimate years.
The Crown entity will be entered via a consolidation adjustment.
67
4. Once submitted the journals must be approved by the Finance central processing
approver (Finance_Cpa). Once approved the status of the journal would now be
Finance Validated.
5. The outputs from this activity will be the 2011/12 Budget Estimates containing the
budget consolidation adjustment and a Budget Estimates Adjustment report.
Requirement
FR-BM-072
Importance
Core
Description
Ability to upload consolidation adjustments with application of pre-defined
business and validation rules during upload. The posting of manual
consolidation adjustments for Estimates, monthly profile and Actuals would
be subject to the same business requirements as per Agency Estimate
adjustment submission and QA.
Key Inputs and linkages from other functions

To complete this activity the following inputs will be required:
Function
Inputs
Data
2011-12_Budget_estimates_data (All
agencies)
Data
201112_Budget_consolidation_adjustments
Security
User profile for:

Finance_Cpo
Finance_Cpa
Budget_estimates_data_entry_template
Template
Version
1.1
Reference
Appendix 2
Per scenario 2, Activity 2.4
Output
Refer to 201112_Budget_Estimates_data
(All agencies including
consolidation adjustments)
v1.2
N/A

Output
1.0
Appendix 3
Per scenario 1, Activity
1.4Output
Rule
Setup_business_rules
1.0

Output
68
Key Outputs and linkages to other functions

Function
Outputs
Version
Data
2011-12_Budget_Estimates_data (All
agencies including consolidation
adjustments)
1.2
Report
1.1
Reference
Appendix 2
Appendix 4
Activity 3.2 Consolidate Financial Statements (Process 2.4.2 Functional

Activity 3.2 Consolidate Financial Statements (Process 2.4.2 Functional Requirement Map 2.4)
CBMS
Finance
Finance
Agency
Yes
2.4.2.3
Liaise with agencies
Agency agrees to
amend?
No
No
2.4.1
Post manual
consolidation journals
2.4.1
2.4.2.1
Run consolidation
and eliminations
2.4.2.2
Review elimination
matching
Post manual
consolidation
Elimination
variances
immaterial?
Yes
2.4.3
Statements
Elimination matching
report
Unauthorised
Agency
Authorised
Finance
validated
With the consolidated adjustment journal entered, validated and approved to reclassify the
Department of Law and Orders Departmental Outcome 1, sub function Other Public Order
and Safety, the Budget Estimates are now required to be consolidated in order to produce
sector and Whole-of-Government financial statements.
1. The consolidation adjustment journal has now been created, submitted, validated and
approved, with Budget Estimates data now including the consolidation adjustment
journal. Finance_Cpo is required to consolidate the Budget Estimates data.
69
2. As part of the consolidation process, the Finance_Cpo is to Identify related entity

transactions to be eliminated during the consolidation. Where amounts do not match
and are below the tolerance threshold, elimination journals are balanced according to
business rules.
3. The Finance_Cpo will extract and print an elimination related entities and balances
mismatch report for the General Government Sector to identify outstanding elimination
related entities and balances.
4. The outputs from this activity will be the consolidated 2011-12 Budget Estimates and
an Elimination Matching report.
Requirement
Importance
Description
FR-BM-073
Core
Ability to consolidate without the need to lock Agencies access. Agencies

will be able to continue entering Estimates adjustments arising from
Government decisions whilst Finance consolidates data from earlier
decisions.
FR-BM-074
Core
Identify related entity transactions, balances, and Agencies involved in the

transactions to be eliminated at each level during the consolidation.
FR-BM-075
Core
Provide automated elimination of related entity transactions for monthly and

Budget Estimates and Actuals against standard parameters and business
rules for each element of the RDS (eg. Account, function, Program, reason
code etc.). The automated eliminations will provide for reporting of various
levels within the consolidation hierarchy (eg. sector, TNFPS, Whole-ofGovernment).
FR-BM-076
Core
Ability to consolidate the data by the RDS (eg. Account, function, Program,
reason code etc.) for monthly and Budget Estimates and Actuals. Includes
the ability to produce portfolio, sector and Whole-of-Government view of
Accounts.
FR-BM-077
Core
Ability to automatically post correcting journals for unmatched elimination

balances below a pre-defined threshold (by individual related entity
combinations).
FR-BM-078
Core
Ability to generate, extract and print mismatch reports to identify outstanding

elimination related entities and balances.
FR-BM-081
Core
Ability to consolidate multiple periods (eg. comparative financial statements).
70

Function
Inputs
Version
Reference
Data
agencies including consolidation
adjustments)
1.2
Security
User profile for:

Finance_Cpo
N/A

Output
Rule
Setup_business_rules
1.0

Output
Rule
Setup_elimination_matching_rules
1.0

Output
Appendix 2
Output

Function
Outputs
Version
Reference
Data
agencies consolidated)
1.3
Appendix 2
Report
Elimination_matching_report.
1.0
Appendix 4
71
Activity 3.3 Produce Consolidated Financial Statements (Process 4.1.1

Functional Requirement Map 4.1)
Activity 3.3 Produce Consolidated Financial Statements
(Process 4.1.1 Functional Requirement Map 4.1)
Finance/Treasury
Budget
Estimates
Budget
Estimates
Monthly Profile
Actuals
Management
2.1
2.2
2.3
CBMS
2.1
No
Monthly Profile
Finance
Consolidation
2.2
2.4
4.1.1.1
Produce
consolidated
financial statements
and agency tables
4.1.1.2
Treasury and
Finance review of
statements
Passes QA?
Yes
4.1.1.3
Inclusion in draft
budget papers and
text
4.1.1.4
Sign-off budget
papers
Actuals
Management
Budgeted GG
Statements and
notes
2.3
CFS
FBO
UEFO
PEFO
MYEFO
Functional tables
Budget Paper 1
Budgeted PNFC and

TNFPS statements
ASL by agency
NCI by agency
Expenses by agency

1. Other reports to be extracted and printed by the Finance_Cpo for the General
Government Sector include:
a. Consolidated Income Statement;
b. Consolidated Balance Sheet; and
c. Expenses Report by sub-function.
This includes the production of print ready financial tables and charts for the Budget
Papers.
Requirement
Importance
Description
FR-RA-001
Core
Enable production of print-ready statements for Appropriation Bills,

selected tables within The Budget Papers (e.g. Budget Papers 1 through 4,
and PBS), Actuals reporting, and associated documentation to defined
template guidelines.
FR-RA-002
Core
Enable production of notes to the financial statements.
72
Requirement
Importance
Description
FR-RA-003
Core
Ability to retrieve formatted textual information to facilitate production of

The Budget documentation (e.g. Appropriation Bills).
FR-RA-004
Core
Enable the scheduling of the production of multiple statutory reports on an

ad-hoc and cyclical basis.
FR-RA-005
Core
Enable both time and version comparisons of financial data across

functions (e.g. month-over-month, Budget vs. Actual, consolidation 1 vs.
consolidation 2).
FR-RA-006
Core
Enable pre-defined variables-driven report specification across multiple

dimensions (e.g. Programs, functions, etc).
FR-RA-007
Core

external reporting standards (e.g. Government Financial Statistics (GFS)
FR-RA-008
Core
Ability to view reports prior to printing in WYSIWYG (What You See Is

What You Get), e.g. Appropriation Bills.
FR-RA-009
Core
Ability to export tables, graphs and reports to various file formats including
Word CSV, XML, HTML, JPEG (for images such as charts), Excel and PDF
in suitable format for analysis.
FR-RA-010
Core
Ability to change Statutory report templates and maintain version control of

templates without need for program coding changes.
FR-RA-012
Core
Ability to always be able to reproduce published data (e.g. Budget) at any

time.
FR-RA-013
Core

Function
Inputs
Data
1.3
User profile for:

Finance_Cpo
N/A
Security
Version
Reference
Appendix 2
Output
Output
73

Function
Outputs
Version
Report
Estimates_Consolidated_Income_Statement
(General Government Sector)
1.0
Report
Estimates_Consolidated_Balance_Sheet
1.0
Report
Esimates_Expenses_by_subfunction_report (General Government

Sector)
1.0
Reference
Appendix 4
Appendix 4
Appendix 4
Activity 3.4 Produce Portfolio Budget Statements (Process 4.1.4 Functional

Activity 3.4 Produce Portfolio Budget Statements (Process 4.1.4 Functional Requirement Map 4.1)
Agency
Finance
Budget
Estimates
2.1
4.1.4.1
Advise agency system
is PBS ready
4.1.4.2
Produce agency
statements
4.1.4.3
QA agency statements
Budget financial
statements
Passes QA?
Yes
Budget outcome and

program statements
4.1.4.5
Prepare PBS/PAES
and text
No
4.1.4.6
Sign-off PBS/PAES
PAES
PBS
4.1.4.4
Liaise with Finance
Agencies are required to publish Portfolio Budget Statements (PBS). Prior to commencing
a Budget update, Finance will make any necessary changes to the PBS tables in the
CBMS Solution.
1. The Department of Health (Health_Usr) runs the following statutory reports from the
CBMS Solution in a format suitable for exporting directly into Microsoft Word:
a. PBS_income_statement (Health)
b. PBS_budgeted_expenses_by_program (Health, Outcome 1)
c. PBS_balance_sheet
For this activity the Health_Usr will run the statutory reports.
74
The table of data to run these reports only uses agency entered data. Therefore PBS data
provided by agencies should not include consolidation adjustments made by Finance.
Requirement
Importance
Description
FR-RA-001
Core
Enable production of print-ready statements for Appropriation Bills, selected

tables within the Budget Papers (eg. Budget Papers No. 1 through to No. 4,
and PBS), Actuals reporting, and associated documentation to defined
template guidelines.
FR-RA-007
Core

external reporting standards (eg. Government Financial Statistics (GFS)
FR-RA-009
Core
Word CSV, XML, HTML, JPEG (for images such as charts), Excel and PDF
in suitable format for analysis.
FR-RA-012
Core
Ability to always be able to reproduce published data (eg. Budget) at any

time.
FR-RA-022
Core
Ability for Agencies to add additional information to report templates subject

to validation rules.

Function
Inputs
Data
1.3
User profile for:

Health_Usr
N/A
Security
Version
Reference
Appendix 2
Output
Output

Function
Outputs
Report
PBS_income_statement (Health)
Version
Reference
1.0
Appendix 4
75
Function
Outputs
Version
Report
PBS_budgeted_expenses_by_program
(Health, Outcome 1)
1.0
Report
PBS_Balance_Sheet
1.0
Reference
Appendix 4
Appendix 4
Activity 3.5 Produce Appropriation Bills (Process 4.1.5 Functional

Activity 3.5 Produce Appropriation Bills
(Process 4.1.5 Functional Requirement Map 4.1)
Agency
CBMS
Finance
Finance
Budget
Management
2.1
4.1.5.2
Initial QA of
appropriation bills
4.1.5.1
Run draft appropriation
bills
CBMS
4.1.5.3
Liaise with agencies to
amend estimates
No
Passes QA?
4.1.5.5
Agency amends
estimates
4.1.5.4
Agency runs and QAs
bills tables
Yes
No
Passes agency
QA?
Yes
4.1.5.6
CFO signs-off bills
tables
4.1.5.7
Produce bills and
resourcing tables
Finance prepares the Annual Appropriation Bills and Budget Paper 4- Agency Resourcing
at Budget, which are introduced into Parliament on Budget night.
This activity will look at the ability of the proposed solution to produce Appropriation Bill 1
and perform formatting change without requiring program coding change. The format of
the Appropriation Bills is predefined, while the content depends on the logic and business
rules defined against each type of Appropriation Bill.
1. The Finance_Cpo will run Appropriation Bill 1 for 2011-12 for All Portfolio (i.e containing
Health, Law and Services portfolios).
2. The outputs from this activity will be the 2011-12_Budget_Approp_Bill_One Report.
The 2011-12_Budget_Approp_Bill_One will contain the Schedule 1 of the 2011-12
Appropriation Bill (No.1) 2011-2012, with the following information:
the name of the agency and portfolio;

a narrative description of each Outcome the agency contributes to;
76
for each Outcome, Appropriation for the Budget year 2011-12 is split between the
Control Type administered and the Control Type departmental. This information is
sourced from the Budget Estimates function (Activity 2.4):
o
o
o
o
Administered Appropriation amounts are defined by POC Account

4100001.7593 (see POC Base Data);
Departmental Appropriation amounts are defined by POC Account
1280004;
Appropriations for CAC Agencies is defined by POC Account 1270018;
Actual Available Appropriation for the year 2010-11 is split between the
Control Type administered and the Control Type departmental. This
information is sourced from the Cash Management function and is based
on the current Appropriation Limits; and
Agency totals.
3. Upon review of the 2011-12_Budget_Approp_Bill_One Report, the following formatting

changes are required:
4.
Appropriation font size to be changed from 8 to 8.5;

Actual Available Appropriation font size to be changed from 7.5 to 8; and
Outcome text font theme changed from Arial to Times New Roman.
Then Finance_Cpo makes this change and the Bills are then re-run.
Requirement
Importance
Description
FR-RA-023
Core
Production of Appropriation Bills consistent with technical requirements set by

the Office of Parliamentary Counsel, through extraction of information from
multiple data sources within defined template guidelines (both financial and
text).
FR-RA-024
Core
CSV, XML, HTML, JPEG (for images such as charts), Excel and PDF in
suitable format for analysis.
FR-RA-025
Core
Ability to change Appropriation Bills and resourcing templates (including text,

format and structure) without need for program coding changes.

Function
Inputs
Version
Reference
77
Function
Inputs
Version
Reference
Data
1.3
Data
Base_2010-11_available_approp
1.0
Appendix 2
Security
User profile for:

Finance_Cpo
N/A

Output
Appendix 2
Output

Function
Outputs
Report
2011-12_Budget_Approp_Bill_One
Version
Reference
1.0
Appendix 4
78
13
Scenario 4: Appropriation Management

This scenario will cover the process of setting up Agencies Appropriation Limits in the
CBMS Solution. It specifically looks into the automatic flow of Budget Estimates data to
Appropriation Limits. Similar to the other process this scenario requires an approval step.
The Appropriation Limits captured from Budget Estimates is limited by the POC Setup_Account_Data as set up in Activity 1.1. For example Administered Appropriation is
defined by Account 4100001.7593 while Departmental Appropriation is defined by Account
1280004.
The Finance approved annual Appropriation Estimates that are reported in the
Appropriation Bills become the Appropriation Limits for Cash Management purposes. The
Appropriations do not become available until the Appropriation Bills (Scenario 3, Activity
3.5) receive Royal Assent. Upon Royal Assent the Appropriation Bills become
Appropriation Acts.
the automatic sourcing of Appropriation Limits in the Cash Management function from
Appropriation data entered during the Estimates update process;
data integrity through system-based validations, reconciliations and approval controls

for the Cash Management function;
the capture of Appropriation Limits information against various aspects of the RDS;
the ability to manage and classify adjustments to Appropriation Limits (via an Advance
to the Finance Minister (AFM));
the ability to view Appropriation balances on-screen while performing a process; and
the generation, execution and printing of reports relating to the set-up of, and
management of modifications of Appropriation Limits.
Activity
Activity 4.1 Set-up of Appropriation Limits
RFT Part Two

Reference
Cash Management
Clause 10.5.1 (a)
Clause 10.6.2 (b)
79
Activity 4.1 Set-up of Appropriation Limits (Process 3.1.1 Functional

Activity 4.1 Set-up of Appropriation Limits (Process 3.1.1 Functional Requirement Map 3.1)
Finance
2.1
3.1.1.1
Set-up of
Appropriation Limits
3.1.3
Enter Daily Cash
Transactions
Management of
Budget Estimates
Acts 1 6
Parl Dept Acts
Special Appropriation
Emergency Act
GST (s30A FMA)

1. The scenario starts with Finance_Cpa being informed through the CBMS Solution that
the 2011-12_Budget_Estimates v1.3 data is available to be set-up as Appropriation
Limits for Financial Year 2011/2012. The data remains in the queue pending
Finance_Cpas approval.
2. Given that Royal Assent was granted at the end of June 2011, on 01 July 2011
Finance_Cpa reviews and approves the process. This activity results to Agencys
Appropriation Limits being set-up in the CBMS Solution, allowing Agencies to process
their drawdowns. The 2011-12_Budget_Estimates data will now be
2011-12_Approp_Limits.
3. Note that Appropriation Limits are driven by Agency Estimates data and does not get
impacted by consolidation or elimination processes.
4. Upon Finance_Cpas approval of the process, Finace_Cpo runs the 201112_Available_Approp report which reflects the Appropriation Limits amounts being setup according to Agency, Financial Year, Control Type, Appropriation Type,
Appropriation Item, Outcome, and Program.
80
Requirement
FR-CM-001
FR-CM-002
FR-CM-004
FR-CM-006
FR-RA-033
Importance
Description
Core
Record Agency Appropriation limits and allows tracking of modifications.
Core
Enable Appropriation data to be automatically sourced from official

Estimates information with the capability for manual changes, consistent
with business rules (i.e. hard limit set at legislated limits).
Core
Ensure that setting Appropriation limits requires multiple step approval.
Core
Capture information for Appropriation limits against various aspects of the

RDS (e.g. selected AEIFRS Accounts, Program, Appropriation type,
Appropriation year, SPPs, Administered/Departmental control, etc).
Core
Support the ability for users to generate, execute and print ad-hoc queries
and reports.

Function
Inputs
Version
Data
2011-12_Budget_Estimates_Data
1.1
Security
User profile for:

Finance_Cpo
Finance_Cpa
1.0
Reference
Output
Output

Function
Outputs
Version
Reference
Data
2011-12_Approp_Limits
1.0
Appendix 2
Report
2011-12_Available_Approp
1.0
Appendix 4
81
14
Scenario 5: Cash Management

The Cash Management Scenario is divided into three main activities, namely:
Activity 5.1 Enter Daily Cash Transactions;

Activity 5.2 Daily Cash Management; and
Activity 5.3 Monthly Cash Management.
Activity 5.4 Manage Appropriation Limits has been included in this scenario to demonstrate
an appropriation adjustment after the initial set-up of Appropriation Limits and processing of
relative drawdown and receipt transactions. This activity should also demonstrate the ability
to manage and classify adjustments to Appropriation Limits (via an Advance to the Finance
Minister (AFM)).
The three main activities are cyclical in nature which means the output of one activity
contributes to the input of the next activity. This scenario should be able to demonstrate
Finances ability to manage the OPA group of accounts, including daily and monthly
reconciliation processes, using the CBMS Solution.
ability to process drawdowns, receipts and journals by manual entry and using upload
files;
ability to change the status of transactions as data flows from one process to another;
data integrity through system-based validations, reconciliations and approval controls;
producing an error message when a process fails a business rule;
access control limiting users access to specific roles and functions;
allocation of unique reference numbers to transactions in the CBMS Solution;
ability to report data across functions and conduct comparative analysis;
Reserve Bank of Australia (RBA) reports can be successfully uploaded into CBMS; and
CBMS file to be successfully uploaded to ReserveLink WE.
Activity
Activity 5.1 Enter Daily Cash Transactions

Activity 5.2 Daily Cash Management
Activity 5.3 Monthly Cash Management
RFT Part Two

Reference
Cash Management
Clause 10.5.1 (c)
Clause 10.6.2 (a)
Cash Management
Clause 10.5.1 (d)
Clause 10.6.2 (b)
Cash Management
Clause 10.5.1 (e)
Clause 10.6.2 (a)

Clause 10.6.2 (b)
Activity 5.4 Manage Appropriation Limits
Cash Management
Clause 10.5.1 (b)
Clause 10.6.1 (a)
82
Activity 5.1 Enter Daily Cash Transactions (Process 3.1.3 Functional

Daily cash transactions are generally performed by Agencies; however they can also be
performed by selected Finance staff such as Finance_Cpo and Finance_Cpa. These daily
cash transactions include processing drawdowns, receipts and journals. These processes
allow Agencies to record their cash transactions in the CBMS Solution mirroring their
Agencies Financial Management Information System (FMIS), as much as possible.
This activity is broken down into three main processes, namely:
Process Drawdowns (Process 3.1.3.1);

Process Receipts (Process 3.1.3.2); and
Process Journals (Process 3.1.3.3).
Process Drawdowns (Process 3.1.3.1 Functional Requirement Map 3.1.3)

Activity 5.1 Enter Daily Cash Transactions (Process 3.1.3.1 Process Drawdowns)
Finance
Agency
3.1.1
Setting up of
3.1.2
3.1.3.1
Process
Drawdowns
Management of
Appropriation
Limits
Agencys Funding
Requirement
3.1.4
3.1.3.3
Process Journals
3.1.3.2
Process Receipts
Daily Cash
Management
4
Reporting &
Analysis
Agency Returning
Cash to the OPA
Prior to an Agency processing a drawdown, Finance is required to maintain Agencies

official head office Bank Accounts in the CBMS Solution. This type of maintenance requires
a multiple step approval. Finance maintains the Agencys head office Bank Account details
such as BSB (Bank State Branch) and account number, together with the relative Control
Type (Administered or Departmental) in the CBMS Solution. This information has been setup in Scenario 1, Activity 1.1.
1. This scenario starts with the Department of Health user (Health_Usr) processing the
following Government Direct Entry System Real Time Gross Settlement (GDESRTGS) drawdowns and the Department of Health approver (Health_Mgr) approving the
83
transactions. In this process the 2011-12_Daily_Cash_Transactions data is used,

particularly the drawdown transactions. These are:
a. Department of Healths fortnightly payroll, entered using an upload file;
b. Department of Healths invoice payment relating to the Plastic Trumpets Ad
Campaign, entered manually; and
c.
Sports Australias payroll drawdown entered using an upload file.
2. When processing a drawdown, the CBMS Solution automatically assigns a unique

reference number to each transaction. Also, upon approval of a drawdown transaction,
it is recorded in the CBMS Solution with a status of unpaid. This means that it has
been deducted from the relative appropriation, but the drawdown request (Payment
File) has not been sent to the Reserve Bank of Australia (RBA). In addition, a
drawdown will mean a decrease to the Available Balance.
3. Additional GDES-RTGS drawdowns are also processed which will be an input to
Activity 5.2 Daily Cash Management, Process 3.1.4.1 Daily Payment Run. These are
for the following Agencies:
a.
b.
c.
d.
Department of Law and Order (DLO);

Public Court (Court)
Department of Public Services (DPS); and
Crown Entity (Crown)
4. Finance_Cpo performs a drawdown in the CBMS Solution and selects the Crown Entity
as the Agency. The process is discontinued as the CBMS Solution produces a
message due to a validation error. This is due to Crown Entity not having bank account
details maintained in the CBMS Solution.
5. Agency users (DLO_Usr and DPS_Usr) then process their respective drawdowns. The
first batch of drawdown does not pass the business rules, hence are unsuccessful. Both
drawdowns exceeded the Available Balance of their respective Appropriations.
Available Balance = Appropriation Limit Total Drawdowns + Total Receipts
Where: Total Receipts = Total of Approp Return (s30) Receipts
DLO_Usr and DPS_Usr then revised their data and processed another drawdown,
which their respective Agency approvers (DLO_Mgr and DPS_Mgr), successfully
approved.
6. Before the 2pm cut-off, Health_Usr was advised that the drawdown to pay the Plastic
Trumpets Ad Campaign is no longer required and needed to be reversed. As it is before
the 2pm cut-off, the drawdown will not have been paid yet to the RBA, and will still be in
status unpaid. Therefore, the drawdown can still be reversed.
7. Finance is contacted to reverse the unpaid drawdown. The reversal process is
performed by Finance_Cpo by selecting the specific drawdown identified by its unique
reference number. Once the reversal is approved by Finance_Cpa, the drawdown
transaction will: be excluded from the input to Activity 5.2; entry against the relative
Appropriation will be reversed; will not appear in the Cash_Transaction_Detail_Report;
84
and will have a status of deleted in the CBMS Solution. This function is only available to
Finance.
8. At 2.30pm Department of Health is advised that they need to process an urgent
drawdown to pay a sudden surge in PBS claims for No Sneeze, otherwise supply of
the drug will be discontinued. Hence, an Emergency Real Time Gross Settlement
(ERTGS) drawdown is necessary.
9. Health_Usr attempts to process an ERTGS, but is denied access. As it is past the cutoff time for Agency access, Department of Health contacts Finance for temporary
access. Finance_Cpa adjusts the set cut-off time for drawdowns.
10. Health_Usr then processes the ERTGS and Health_Mgr approves the drawdown. Upon
completion of the ERTGS, Finance is notified and Finance_Cpa changes the cut-off
time back to 2pm.
11. Additional ERTGS drawdowns are also processed which will be an input to Activity 5.2
Daily Cash Management, Process 3.1.4.1 Daily Payment Run. These are for the
following Agencies:
a.
b.
c.
Department of Law and Order (DLO);

Public Court (Court); and
Department of Public Services.
12. Lastly, Finance_Cpo runs the 2011-12_Available_Approp and Cash_Transaction_Detail

Report to check the drawdowns just processed.
Requirement
Importance
Description
FR-CM-020
Core
Provide a facility for Agencies to request cash funds to be drawn down into
their bank accounts on a daily basis due on the following day. These
facilities are known as either Government Direct Entry System (GDES) or
for amounts over $100m Real Time Gross Settlement (RTGS).
FR-CM-021
Core
Provide for a scheduling facility to enable future dated Agency drawdown

requests.
FR-CM-022
Core
Enable same-day Agency drawdown for emergency situations. This type of

drawdown is known as Emergency Real Time Gross Settlement (ERTGS).
FR-CM-023
Core
Ability to set a cut-off time for processing drawdowns.
FR-CM-024
Core
Enable efficient drawdown file transfer (upload) from Agencies.
FR-CM-026
Core
Capture cash transactions against various aspects of the RDS (eg.

selected AEIFRS Accounts, Program, Appropriation type, Appropriation
85
Requirement
Importance
Description
year, SPPs, Administered Departmental control, etc).
FR-CM-027
Core
Ability to reverse unreconciled receipts and unpaid drawdowns.
FR-CM-029
Core
Ensure Appropriation drawdown request is validated against Appropriation

limit before funds transfer verified.
FR-CM-032
Core
Enable on-screen account balance details by Appropriation.
FR-CM-034
Core
Ability to accommodate changes in departmental banking and accounting

arrangements. This may include changes stemming from Machinery of
Government changes or the creation or deletion of bank accounts.
FR-CM-036
Core
Ability to earmark approved future-date drawdown transactions from the

available Appropriation limits even if still unpaid.
FR-CM-037
Core
Ability to allocate a unique reference number for each Cash Management

transaction (drawdown, receipt, journal, budget adjustment, system
maintenance, etc).
FR-RA-033
Core
and reports.

Function
Inputs
Version
Data
1.0
Data
2011-12_Daily_Cash_Transactions
(Drawdowns)
1.0
Data
(Reversal)
1.1
Data
(Updated Drawdowns)
1.2
Template
Cash_Drawdown_Template
1.0
Reference
Output
Appendix 2
Appendix 2
Appendix 2
Appendix 3
86
Function
Inputs
Security
User profile for:

Finance_Cpo
Finance_Cpa
Health_Usr
Health_Mgr
DLO_Usr
DLO_Mgr
Court_Usr
Court_Mgr
DPS_Usr
DPS_Mgr
Daily_Cash_Transactions_
Business_Rules
Rule
Version
Reference
1.0

Output
1.0

Output
Key outputs and linkages from other functions

Function
Outputs
Version
Reference
Data
(Drawdowns)
1.3
Per Scenario 5, Activity 5.1,

Process 3.1.3.1 Input
Report
1.1
Appendix 4
Report
Cash_Transaction_Detail_Report
1.0
Appendix 4
87
Process Receipts (Process 3.1.3.2 Functional Requirement Map 3.1.3)

Activity 5.1 Enter Daily Cash Transactions (Process 3.1.3.2 Process Receipts)
Finance
Agency
3.1.1
Setting up of
3.1.2
3.1.3.1
Process
Drawdowns
Management of
Appropriation
Limits
Agencys Funding
Requirement
3.1.4
3.1.3.3
Process Journals
Daily Cash
Management
3.1.3.2
Process Receipts
Reporting &
Analysis
Agency Returning
Cash to the OPA
In this process the 2011-12_Daily_Cash_Transactions data is used, particularly the

receipts transactions.
1. This scenario starts on 16 August 2011 when Health_Usr performs daily bank
statement reconciliation for 15 August 2011. Health_Usr notice that they made two
transfers to the Official Public Account (OPA) the previous day. This means that relative
receipts need to be recorded in the CBMS Solution.
2. Health_Usr processes the receipts, takes note of the unique identifier number of each
transaction and prints out the reports. Similar to drawdowns when processing a receipt,
the CBMS Solution automatically assigns a unique reference number to each
transaction.
3. This activity will result to the recording of receipts in the CBMS Solution which will be an
input to Activity 5.2 Daily Cash Management to perform Process 3.1.4.3 Daily Bank
Reconciliation. Also, upon processing of receipts, it becomes recorded in the CBMS
Solution with a status of not reconciled. This means that the receipt has not been
reconciled with the RBA_transactions, and will not yet be reflected against relative
Appropriations and will not affect the Available Balance.
4. The scenario continues with a few other agencies entering receipts in the CBMS
Solution. Health_Usr successfully enters a receipt for Sports. Then DLO_Usr enters a
receipt in the CBMS Solution but fails a business rule. The amount of receipt entered is
greater than the allowable amount of receipts. DLO_Usr discontinues processing the
receipt.
Receipt Amount Total Drawdowns Total Receipts
88
Where: Total Receipts = Total of Approp Return (s30) Receipts

5. The next Agency is Public Court. Court_Usr processes two batches of receipts. One is
entered manually and the second using an upload file. The manual entry is successfully
completed. The upload file initially failed to be processed due to failing a business rule.
The receipt date of the file is 1 July 2011. Receipt date can only be between the first
day of the current period (Month/Day) and current days date (in this scenario is 16
August 2011). A revised upload file is entered in the CBMS Solution and passes the
business rule.
6. Then Court realises that the manually entered receipt was also part of the upload file
just processed. The duplicate receipt needs to be reversed. Court_Usr contacts
Finance to reverse the receipt. The reversal process is performed by Finance_Cpo by
selecting the specific receipt identified by its unique reference number. Once the
reversal is approved by Finance_Cpa, the receipt transaction will: be excluded from the
input to Activity 5.2; entry against the relative Appropriation will be reversed (if status is
reconciled); will not appear in the Cash_Transaction_Detail_Report; and will have a
status of deleted in the CBMS Solution. This function is only available to Finance
Reports to check the receipts just processed.
Requirement
Importance
Description
FR-CM-026
Core

FR-CM-027
Core
Ability to reverse unreconciled receipts and unpaid drawdowns.
FR-CM-032
Core
FR-CM-033
Core
Ability to automatically increase relevant Appropriation limits based on

approved receipts from independent sources.
FR-CM-037
Core

maintenance, etc).
FR-RA-033
Core
and reports.
89

Function
Inputs
Data
(Receipts)
1.4
Data
(Reversal)
1.5
Data
(Updated Receipts)
1.6
Data
1.0
Template
Cash_Receipts_Template
1.0
Security
User profile for:

Finance_Cpo
Finance_Cpa
Health_Usr
Health_Mgr
DLO_Usr
DLO_Mgr
Court_Usr
Court_Mgr
Business_Rules
Rule
Version
Reference
Appendix 2
Appendix 2
Appendix 2
Output
Appendix 3
1.0

Output
1.0

Output
Key outputs and linkages from other functions

Function
Outputs
Version
Reference
Data
(Receipts)
1.6

Report
1.2
Appendix 4
Report
1.1
Appendix 4
90
Process Journals (Process 3.1.3.3 Functional Requirement Map 3.1.3)

Activity 5.1 Enter Daily Cash Transactions (Process 3.1.3.3 Process Journals)
Finance
Agency
3.1.1
Setting up of
3.1.2
3.1.3.1
Process
Drawdowns
Management of
Appropriation
Limits
Agencys Funding
Requirement
3.1.4
3.1.3.3
Process Journals
3.1.3.2
Process Receipts
Daily Cash
Management
4
Reporting &
Analysis
Agency Returning
Cash to the OPA

1. While reviewing the daily reports, DLO_Mgr realises that their drawdown was
processed against the wrong Program. It should have been drawn down from the
Public Order instead of the Legal Services. DLO_Usr enters a journal in the CBMS
Solution to correct the drawdown. DLO_Mgr approves the transaction. The journal then
goes to Finances queue for Finance approval.
2. Only upon Finances approval will the change be reflected in the reports. The journal
will in effect increase the Available Balance against Legal Services Policy and
decrease against Public Order Policy. Similar to drawdowns and receipts when
processing a journal, the CBMS Solution automatically assigns a unique reference
number to each transaction.
3. Health_Usr was advised that their drawdown should have been split between
Appropriation Act 1, program Medical Services and Act 1, program Community
Pharmacy, instead of the full amount being drawn solely from Administered
Appropriation Act 1, Medical Services. Health_Usr enters a correcting drawdown
journal in the CBMS Solution. Upon submitting the journal, an error message appears
suggesting that the journal does not meet a validation rule. The debits and credits did
not balance (total debits should be equal to total credits).
4. The journal is corrected and Health_Usr re-submits the journal, which is then approved
by Health_Mgr. Then the journal goes to Finances queue for Finance approval.
5. Court_Usr performs the daily reconciliation and realises that the receipt they recorded
as Administered Receipt should have been a section 31 receipt (s31 FMA) against
2011-2012 Departmental Appropriation Act 2.
91
6. Court_Usr processes the correcting receipt journal. While processing the journal
Court_Usr used the on-screen balance to check that there is sufficient balance to debit
(reduce) from the total of Administered Receipts. Court_Mgr approves the journal
followed by a Finance approval. This journal will have an effect on Public Courts
Appropriation Limit for 2011/2012 Departmental Appropriation Act 1. Section 31
receipts increases the Appropriation Limit instead of increasing the Total Receipts.
Reports to check the journals just processed.
Requirement
Importance
Description
FR-CM-025
Core
Ability to capture journal entries (eg. to reclassify a transaction

classification) which can be categorised by multiple type (eg. general and
budget) subject to approval processes and with appropriate audit
information (eg. comment, time stamp, user etc).
FR-CM-026
Core

FR-CM-032
Core
FR-CM-033
Core
Ability to automatically increase relevant Appropriation limits based on

approved receipts from independent sources.
FR-CM-037
Core

maintenance, etc).
FR-RA-033
Core
and reports.

Function
Data
Data
Inputs
Version
1.0
(Journals)
1.7
Reference
Output
Appendix 2
92
Function
Inputs
Data
(Updated Journal)
1.8
Template
Cash_Journals_Template
1.0
Appendix 3
Security
User profile for:

Finance_Cpa
DLO_Usr
DLO_Mgr
DPS_Usr
DPS_Mgr
Court_Usr
Court_Mgr
Business_Rules
1.0

Output
1.0

Output
Rule
Version
Reference
Appendix 2

Function
Outputs
Version
Reference
Data
1.1
Appendix 2
Data
1.8
Report
1.3

Appendix 4
Report
1.2
Appendix 4
Activity 5.2 Daily Cash Management (Process 3.1.4 Functional Requirement

Map 3.1)
The following activities are what Finance performs daily to manage the day to day
operation of the OPA group of accounts held at the Reserve Bank of Australia (RBA).
This activity is broken down into three main processes, namely:
Process Daily Payment Run (Process 3.1.4.1);

Process Daily Reporting (Process 3.1.4.2); and
Process Daily Bank Reconciliation (Process 3.1.4.3).
The Payment Run is performed at 2pm daily. The Daily Reporting starts at 9am, or as soon
as the RBA Reports are available, and the Daily Bank Reconciliation is conducted
immediately after completion of the Daily Reporting.
93
Process Daily Payment Run (Process 3.1.4.1 Functional Requirement Map 3.1.4)
Activity 5.2 Daily Cash Management (Process 3.1.4.1 - Process Daily Payment Run)
Finance
CBMS
3.1.4.3
Process Daily
Bank Rec
3.1.4.2
Process Daily
Reporting
3.1.4.1
Process Daily
Payment Run
3.1.3
Payment File
3.1.5
Monthly Cash
Management
Enter Daily Cash

Transactions
Payment Register
Report
Commonwealth
Cash Balances
Report
OPA Bank
Statement
Account
Maintenance
Information (AMI)
File
Devolution of
Government
Services
Daily Bank
Reconciliation
Although Finance normally performs the Payment Run at 2pm, there should be no
restriction to the number of Payment Runs Finance can do and at what time of the day they
are processed.
1. The scenario begins with Finance performing the Payment Run process after 2pm.
Finance_Cpo starts the process in the CBMS Solution, first by selecting the ERTGS
drawdowns then submits the transaction. The CBMS Solution assigns a unique
reference number to the transaction (which is in sync with RBAs reference numbers).
The ERTGS Payment Run stays in the queue, pending approval.
2. Finance_Cpa selects the transaction, reviews the Payment Run (ensuring that the
transaction contains Agencies ERTGS drawdowns only), then approves the Payment
Run. The same process is done with processing the GDES-RTGS Payment Run.
3. The data used for the Payment Run comes from the drawdown data
2011-12_Daily_Cash_Transactions data (Scenario 5, Activity 5.1 Process 3.1.3.1
Output). Upon completion of the Payment Run, the status of a drawdown transaction in
the CBMS Solution changes from unpaid to paid. This confirms that the Payment
File has been sent to the RBA.
4. Resulting from the Payment Run process the CBMS Solution produces the Payment
File which contains the GDES-RTGS and ERTGS data. This Payment File is in DAT_U
file type and is sent to the RBA via the ReserveLink WE.
94
5. After sending the Payment File to the RBA, Finance_Cpo runs the
AOFM_Payment_Register_Report and sends it to the Australian Office of Financial
Management (AOFM).
6. Lastly, Finance_Cpo runs the Cash_Transaction_Detail Report to check if the status of
the drawdowns has changed to paid.
Requirement
Importance
Description
FR-CM-039
Core
Ability to pool multiple or single drawdowns by payment type and funds

release date.
FR-CM-044
Core
Provide a dedicated link to RBA to enable automatic transfers (Agency

payment files, and account balances).
FR-CM-045
Core
Ability to generate payment files for the RBA banking system with appropriate
validation and/or authorisation, including a unique reference number (in
sequence) and to be in sync with RBAs reference number.
FR-CM-046
Core
Ability to create multiple payment runs, edit or delete a payment run, including
adding or removing selected drawdowns.
FR-CM-048
Core
Ability to control access for cash drawdowns by periods by using effective

date (eg. 1 Aug closes the July period). Also, ability to control access to
lapsing Appropriations by defining a completion period.
FR-RA-033
Core
Support the ability for users to generate, execute and print ad-hoc queries and
reports.

Function
Inputs
Version
Reference
Data
(Drawdowns)
1.8

Process 3.1.3.3 Output
Security
User profile for:

Finance_Cpo
Finance_Cpa
1.0

Output
95

Function
Outputs
Version
Reference
Report
RBA_Payment_File
1.0
Appendix 4
Report
AOFM_Payment_Register_Report
1.0
Appendix 4
Report
1.3
Appendix 4
Process Daily Reporting (Process 3.1.4.2 Functional Requirement Map 3.1.4)

Activity 5.2 Daily Cash Management (Process 3.1.4.2 - Process Daily Reporting)
Finance
CBMS
3.1.4.3
Process Daily
Bank Rec
3.1.4.2
Process Daily
Reporting
3.1.4.1
Process Daily
Payment Run
3.1.3
Enter Daily Cash
Transactions
Payment File
3.1.5
Monthly Cash
Management
Payment Register
Report
Commonwealth
Cash Balances
Report
OPA Bank
Statement
Account
Maintenance
Information (AMI)
File
Devolution of
Government
Services
Daily Bank
Reconciliation

1. The Daily Reporting process is performed by Finance. It starts when Finance_Cpo
downloads the RBA Reports from ReserveLink WE. These reports are dated the
previous business day and are all in DAT_U file type.
2. The RBA Reports are then uploaded in the CBMS Solution, for reformatting, processing
and reconciliation. Finance_Cpo should be able to run the Daily_RBA_Reconciliation_
Report if the data balances. Refer to Appendix 4 for further explanation on the RBA
Reports.
3. If Finance_Cpo is unsuccessful in uploading the RBA_AMI_File due to failing a
business rule, the CBMS Solution will not allow the process to continue, which stops
the RBA_AMI_File data being used for Daily Bank Reconciliation process (Process
3.1.4.3).
96
4. In this scenario, Finance_Cpo uploads the RBA_AMI_File, which successfully

reconciles with the other RBA Reports. The RBA_Transactions_Data is now available
as an input to the Daily Bank Reconciliation process 3.1.4.3.
5. Finance_Cpo runs the Daily_RBA_Reconciliation Report.
Requirement
Importance
Description
FR-CM-038
Core
Ability to upload Agency working cash limits into the system for monitoring
and reporting purposes.
FR-CM-040
Core
Ability to manage multiple central bank accounts.
FR-CM-041
Core
Record audit trails for all OPA funds movement transactions including audit
reporting capability.
FR-CM-042
Core
Enable automated daily reconciliation of the OPA (including automatic

matching of Agency and RBA data).
FR-CM-043
Core
Ability to collect and store Agency bank balance information on a daily basis.
FR-CM-044
Core
Provide a dedicated link to RBA to enable automatic transfers (Agency

payment files, and account balances).
FR-CM-047
Core
Ability of system to accept and validate external data sources (eg. RBA
reports).
FR-CM-050
Core
Generate daily cash transaction reports by RDS.
FR-RA-033
Core
reports.

Function
Inputs
Version
Reference
Data
RBA_DOGS_File
1.0
Appendix 2
Data
RBA_CAC_File
1.0
Appendix 2
Data
RBA_Commonwealth_Cash_Balances
1.0
Appendix 2
Data
RBA_AMI_File
1.0
Appendix 2
Template
RBA_Upload_Template
1.0
Appendix 3
97
Function
Inputs
Security
User profile for:

Finance_Cpo
Finance_Cpa
1.0

Output
RBA_Reconciliation_Business_Rules
1.0

Output
Rule
Version
Reference

Function
Outputs
Version
Reference
Data
RBA_Transactions_Data
1.0
Appendix 2
Report
Daily_RBA_Reconciliation_Report
1.0
Appendix 4
Process Daily Bank Reconciliation (Process 3.1.4.3 Functional Requirement Map

3.1.4)
Activity 5.2 Daily Cash Management (Process 3.1.4.3 Process Daily Bank Reconciliation)
Finance
CBMS
3.1.4.3
Process Daily
Bank Rec
3.1.4.2
Process Daily
Reporting
3.1.4.1
Process Daily
Payment Run
3.1.3
Enter Daily Cash
Transactions
Payment File
3.1.5
Monthly Cash
Management
Payment Register
Report
Commonwealth
Cash Balances
Report
OPA Bank
Statement
Account
Maintenance
Information (AMI)
File
Devolution of
Government
Services
Daily Bank
Reconciliation
This process is a continuation of the Daily Reporting process (Process 3.1.4.2). It is

essential that the Daily Reporting is completed before data is used for the Daily Bank
Reconciliation. At this stage the CBMS Solution should have the capacity to automatically
reconcile the RBA_Transactions_Data with the 2011-12_Daily_Cash_Transactions data, in
particular the receipt and drawdown transactions.
98
1. The scenario begins with Finance_Cpo performing the Daily Bank Reconciliation.
Finance_Cpo looks up at a screen where the Agency recorded receipts and drawdowns
(2011-12_Daily_Cash_Transactions) are reconciled with the receipts and drawdowns in
the RBA_Transactions_Data.
2. The CBMS Solution initially automatically reconciles each receipt and drawdown
between the two reports in step 1. Finance_Cpo views items that cannot be
automatically matched, for example, if an Agency has not recorded the corresponding
receipt to match with a receipt recorded in the RBA_Transactions_Data, or an Agency
incorrectly records the receipt amount which cannot be reconciled with the
RBA_Transactions_Data. These will appear as outstanding, unreconciled items in the
CBMS Solution.
3. Finance_Cpo continues with the process by investigating the outstanding items in the
CBMS Solution and manually reconciles items that were not automatically processed.
4. Upon investigation Finance_Cpo advises Agencies to process receipts in the CBMS
Solution to match with RBA Report items. After Agencies have entered their receipts,
either the CBMS Solution automatically reconciles the receipts with the
RBA_Transactions_Data or Finance_Cpo manually matches the items.
5. To complete the process Finance_Cpo runs the CBMS_OPA_Reconciliation Report to
reflect the outstanding unreconciled items (both under RBA_Transactions_Data and
2011-12_Daily_Cash_Transactions data), OPA opening and closing balances,
summary of OPAs debit and credit transactions. These reports are checked and signed
off by Finance_Cpa.
6. In addition, Finance_Cpo runs the 2011-12_Available_Approp and
Cash_Transactions_Daily_Report to confirm that the receipt status has changed from
unreconciled to reconciled.
Requirement
Importance
Description
FR-CM-040
Core
Ability to manage multiple central bank accounts.
FR-CM-041
Core
Record audit trails for all OPA funds movement transactions including audit
reporting capability.
FR-CM-042
Core
Enable automated daily reconciliation of the OPA (including automatic

matching of Agency and RBA data).
FR-CM-047
Core
Ability of system to accept and validate external data sources (eg. RBA
reports).
99
Requirement
Importance
Description
FR-CM-049
Core
Enable the production of daily cash activity and cash transaction reports by
RDS, including the reporting of Appropriation limits, limit adjustments and
drawdowns against limits.
FR-CM-050
Core
Generate daily cash transaction reports by RDS.
FR-RA-033
Core
reports.

Function
Data
Data
Security
Rule
Inputs
Version
Reference
1.0

1.8

1.0

Output
1.0

Output
User profile for:

Finance_Cpo
Finance_Cpa
Daily_Bank_Reconciliation_
Business_Rules

Function
Outputs
Version
Reference
Report
CBMS_OPA_Reconciliation (Daily)
1.0
Appendix 4
Report
1.4
Appendix 4
Report
1.4
Appendix 4
100
Activity 5.3 Monthly Cash Management (Process 3.1.5 Functional

Activity 5.3 Monthly Cash Management (Process 3.1.5.1 Monthly Cash Management)
Finance
Daily Cash
Management
3.1.5.1
Monthly Cash
Management
3.1.4
1.3
Actuals Management
3.2
Cash Monitoring
& Forecasting
AOFM Term
Deposits
OPA Monthly
Interest
CBMS to OPA
End of Month
Reconciliation
Reporting &
Analysis
Agreed Working
Cash Limit Report
At the end of the month Finance_Cpo and Finance_Cpa performs various month-end
reporting. Most of the reports are based on data collected daily which already forms part of
Activity 5.2 Daily Cash Management Process 3.1.4.1 Daily Payment Run, Process 3.1.4.2
Daily Reporting, and Process 3.1.4.3 Daily Bank Reconciliation. It is expected that the
CBMS Solution is able to use the same data from the Daily Cash Management and
translate it to Monthly Cash Management data and reports.
CBMS to OPA End of Month Reconciliation - this is similar to the Daily Bank
Reconciliation process (Process 3.1.4.3) in Activity 5.2, where receipts and drawdown
transactions recorded in the CBMS Solution (2011-12_Daily_Cash_Transactions) are
reconciled with the actual cash transactions in the OPA bank account
(RBA_Transactions_Data). The CBMS Solution is expected to automatically reconcile the
whole months data and year to date data.
Prior to starting this scenario, Finance_Cpo should have completed the Daily Bank
Reconciliation (Process 3.1.4.3) for the last business day of the month, and Finance_Cpa
has signed off on the reports.
1. Finance_Cpa initiates the CBMS to OPA End of Month Reconciliation by calling up the
related screen.
2. By doing so the CBMS Solution reconciles the 2011-12_Daily_Cash_Transactions with
the RBA_Transactions_Data. The reconciliation is performed by month and year to
date.
101
3. Upon reconciliation the CBMS Solution checks for discrepancies and display a warning
message if any has been identified. In this scenario Finance_Cpa receives an error
message advising of discrepancies. The CBMS Solution should allow Finance_Cpa to
make appropriate adjustments and perform manual reconciliation, before finalising the
reports.
4. Once reconciliation is completed, CBMS Solution produces the
CBMS_OPA_Reconciliation Report. Finance_Cpa prints out the report, signs-off and
provides it to management.
Requirement Importance Description
FR-CM-051
Core
Enable automated monthly reconciliation of the OPA.
FR-CM-052
Core
Support monthly cash activity reporting for all Agencies by RDS.
FR-RA-029
Core
Ability to report data across functions and from different sources for reporting
and analysis (eg. Budget and Actual).
FR-RA-033
Core
reports.
FR-RA-045
Core
Provide users with multi-dimensional analytical and reporting capability.
FR-RA-061
Core
Provide the ability to conduct comparative analysis (eg. present year vs. last
year, Budget vs. annual) across functions and periods.

Function
Data
Inputs
Version
Reference
1.0

Data
(drawdowns and receipts)
1.8

Security
User profile for:

Finance_Cpo
Finance_Cpa
Monthly_Bank_Reconciliation_
Business_Rules
1.0

Output
1.0

Output
Rule

102
Function
Outputs
Version
Report
CBMS_OPA_Reconciliation (Monthly)
Reference
1.1
Appendix 4
Activity 5.4 Manage Appropriation Limits (Process 3.1.2 Functional

Formal adjustments to Annual Appropriations can be made after the initial set-up of
Appropriation Limits. Reasons for the adjustments could vary, for example, due to a
Government decision or a Machinery of Government (MOG) change. Any adjustment made
in the CBMS Solution should be supported by the related legal authority such as a Finance
Ministers Determination.
Activity 4.2 Manage Appropriation Limits (Process 3.1.2.3 Advance to the Finance Minister)
Finance
Cabinet / PM /
Ministerial
Decision, AAO
Change
Ministerial
Request
3.1.2.1
Transfer of
Functions
(s32 FMA)
3.1.2.2
Appropriation
Reduction
(section 9)
AFM/APO
Application
3.1.2.3
Advance to the
Finance Minister
(AFM / APO)
Request for
Movement of Funds
Savings
identified
Reallocation
identified
Requirement to
Refund
Amount of
Admin Operating
Approp Required
3.1.2.4
Movement of
Funds Process
(Re-phasings)
3.1.2.5
Identified
Savings
3.1.2.6
Reallocation
between Prog &
Outcomes
3.1.2.7
Refund of
Administered
Receipts (s28)
3.1.2.8
Section 11
Administered
Optng Process
2.1
AAU Decision
3.1.2.9
Ad-hoc
Quarantine
3.1.3
Management of
Budget Estimates
Enter Daily Cash

Transactions (adjusted
drawdown limit)
CBMS
Note These processes, except Section 11 and Quarantines will result in changes to data in Annual Estimates (2.1)
The Advance to the Finance Minister (AFM) is a provision in the annual appropriation Acts
that enables the Finance Minister by determination to provide urgently required
appropriation when no other is available 1.
For the purpose of the POC the automatic production of Determinations will not be tested.
1. This scenario starts when Department of Health is advised of an immediate need for
additional funding for No Sneeze. According to a Health Report due to the extreme
cold temperature during this winter season, there is a prediction of a high prevalence of
outbreaks of flu. Health needs to triple their order of No Sneeze.
http://www.finance.gov.au/budget/budget-process/advance-to-finance-minister.html
103
2. Health consults Finance and applies for an AFM in the CBMS Solution. Health_Usr
processes the AFM and Health_Mgr approves the transaction.
3. The process continues with a Finance review and approval step. Finance_Cpa then
reviews the application, performs a quality assurance, part of which is checking the
Appropriation balance, and then prepares the Determination.
4. Upon completion of the relative legislative process and documentation Finance_Cpa
approves the AFM in the CBMS Solution. In effect Healths Appropriation will be
increased and is made available for drawdown.
5. Finance_Cpa runs the reports from the CBMS Solution to check Healths Appropriation
Limits per the AFM process. The details of the appropriation adjustment will reflect in
the Approp_Limit_Detail_Report while the set up of the Appropriation will be seen in the
2011-12_Available_Approp Report.
Requirement
FR-CM-007
Importance
Core
Description
Ability to automatically update Appropriation limits for legislative
determinations and other approval changes subject to a multi-step
approval process.
FR-CM-008
Core
Ability to categorise Appropriation limit adjustments by reason code (eg.

Advance to the Finance Minister (AFM), movement of funds, section 32,
additional categories, etc).
FR-CM-009
Core
Record audit trail for any change to Appropriation (eg. limit, amount, type,
reason).
FR-CM-010
Core
Ensure that any change to an Appropriation requires multiple step approval.
FR-CM-012
Core
Provide for manual changes of Appropriation limits by authorised users and

maintain an audit trail of manual changes.
FR-CM-013
Core
Enable on-screen Account balance details by Appropriation.
FR-CM-014
Core
Support capture of financial data for the production of Appropriation Bills

and selected tables within annual Budget Papers (eg. Budget Papers 1
through 4, and PBS).
FR-CM-016
Desirable
Ability to automatically produce applications and determinations resulting

from certain legal Appropriation adjustments (eg. AFM s 32 determination).
FR-CM-019
Highly
Desirable
Ability to automatically update both sides for Appropriation limit transfers

between Appropriation types following a multi-step approval process in
accordance with the Governments Appropriation framework.
104
Requirement
Importance
Description
FR-RA-013
Core
FR-RA-033
Core
and reports.

Function
Data
Inputs
Version
Reference
1.1

Data
AFM_Appropriations_Adjustment_Data
1.0
Appendix 2
Template
Approp_Adjustment_Template
1.0
Appendix 3
Security
User profile for:

Finance_Cpa
Health_Usr
Health_Mgr
1.0

Output
Approp_Adjustment_Business_Rule
1.0
Rule

Output

Function
Outputs
Version
Reference
Data
1.2
Appendix 2
Report
1.5
Appendix 4
Report
Approp_Limit_Detail_Report
1.0
Appendix 4
105
15
Scenario 6: Annual Actuals

This scenario covers the business processes associated with the submission and
consolidation of agency financial information at year-end and the subsequent updating of
the budget estimates to reflect actual results.
At year-end, all General Government Sector (GGS) agencies have to submit preliminary
statements (currently by around the end of July). All GGS agencies, as well as all Public
Non-Financial Corporations (PNFCs) and Public Financial Corporations (PFCs), have to
submit actual statements based on audit cleared data for inclusion in the Final Budget
Outcome and Consolidated Financial Statements. This includes financial information
pertaining to supplementary notes such as commitments, contingencies and maturity
tables.
This information is consolidated to produce the statutory reports. Consolidation involves the
aggregation of data submitted by agencies. The financial statements are combined on a
line-by-line basis by adding together like items of assets, liabilities, equity, income and
expenses. The CBMS Solution will automatically match and eliminate related-entity
transactions. Consolidation journals may also be posted manually to eliminate certain
related entity amounts and to adjust for inconsistent accounting policies.
the submission of actual financial statement information and supporting notes;

over the submission of actual financial results and supporting information;
the consolidation of actual financial statement information and supporting notes at

various levels within the consolidation hierarchies;
the production of Statutory reports and audit reports; and
integration between the annual actual process and the budget estimates process.
Activity
RFT Part Two

Reference
Activity 6.1 Enter annual actuals
Actuals management
Clause 10.4.3
Activity 6.2 Consolidate Annual

Actuals
Financial consolidation
Clause 10.4.4
Activity 6.3 Finance Rolls Over

Actuals into Estimates
Budget Estimates
Clause 10.4.1
106
Activity 6.1 Enter annual actuals (Process 2.3.1 2.3.3, Functional Map 2.3)
Activity 6.1 Enter annual actuals (Process 2.3.1 2.3.3)

Finance
Agency
2.4
Cash
Management
Monthly Profile
Budget
Estimates
2.2
2.1
Finance
Consolidation
Monthly Profile
2.2
No, load estimate
Reporting and
Analysis
2.3.1
Agency submits
actual statements
CBMS
Pass system
validations?
Yes
2.3.2
Finance QA and
analysis
Passes QA?
Yes
2.3.3
Review agency
submission status
and load profiles
All agencies
submitted?
2.1
Yes
Annual Estimates
Agency
No
No
2.3
No, contact agency
Monthly Profile
3
Cash Management

1. Sports Australia and the Department of Law and Order have chosen to enter 2010/11
(i.e. as at 30 June 2011) annual actual information via direct entry (using the
Annual_Actuals_data_entry_template). The remaining POC agencies submit their
annual actuals via a flat file upload using the same user interfaces as per Scenario 2,
Activity 2.4. In submitting their annual financial statements, the Department of Law and
Order needs to restate a comparative amount reported for 2009-10.
The annual actuals are submitted at the Program level applying the POC RDS. The
submitted information includes supplementary note information on commitments,
contingencies and maturity tables. The annual actual process is the only time agencies
currently have to submit this additional supplementary information.
The status of the annual actual information is Draft, meaning that Finance cannot
amend the financial information.
2. Once the statements and supplementary notes have been entered by each agency
user (e.g. Health_Usr) the users checks through the user interface that the financial
information passes the POC business rules. The annual actuals cannot be approved
by the agencies approvers (e.g. Health_Mgr) unless the validations are passed.
Once the Public Court has upload their annual actual, they find that the financial
information does not pass the business rule which requires that:
assets liabilities = equity
107
The Public Court corrects this in their own system and uploads a revised file which
passes the business rules.
3. The annual actual are then approved by each agencies approver (e.g. Health_Mgr)
and are available to Finance to undertake quality assurance.
The status of the annual actual information is now Agency Authorised, meaning that
the Agency can no longer adjust the financial information and it is now available to
Finance.
4. Prior to starting the QA process, the Finance_Cpo runs a data submission report to
identify whether agencies have entered annual actuals information and the status of
this information (i.e. Draft, Agency authorised or Finance Validated).
5. The Finance_Cpo then quality assures the annual actual information submitted by the
Department of Health by running two reports:
a.
b.
income statement report for the pharmaceutical benefits Program which compares
the actual income statement for this Program to the corresponding year (2010-11)
in the 2011-12 Budget Update completed in Scenario 2, Activity 2.4); and
An administered agency level balance sheet compared to last year (i.e. comprising
the aggregation of all programs under the Department of Health agency with a
control type of Administered).
6. Satisfied, the Finance_Cpo clears the annual actuals for the Department of Health.
The status of the annual actual information is now Finance Validated, meaning that
the information has been quality assured.
Requirement
Importance
Description
FR-BM-048
Core
Report monthly and annual Actuals information (financial statement and

supporting schedules) against various aspects of the RDS (eg. Account,
Program, function, SPPs, control type, etc) via direct entry or batch
upload. The Actuals data will be at a level consistent with the relevant
Estimates.
FR-BM-051
Core
Allow for Actuals by RDS to be prepared offline for bulk entry (eg. via
FR-BM-052
Core
FR-BM-057
Core
Ability to adjust comparative periods (operating balances) when submitting

current period results.
FR-BM-058
Core
Ensure Actuals data pass pre-defined validation rules (eg. accounting

rules, business process rules) before submission is accepted.
FR-BM-061
Core
Enforce multi-step approval (eg. unauthorised, authorised and Finance

validated) and deletion processes for financial statements that are
consistent with pre-defined business rules.
108
Requirement
Importance
Description
FR-BM-062
Core
Provide the ability for Finance and Agencies to progress Actuals data
FR-BM-069
Core
Ability to QA and accept/reject Agency adjustments to comparative

statements.

Function
Inputs
Version
Reference
Data
2010-11_Annual_Actuals_Data
1.0
Appendix 2
Data
1.1
Appendix 2
Template
(Updated Public Court)
Annual_actuals_data_entry_template
1.0

Output. Appendix 3
Rule
1.0

Output
Security
User profile for:

Finance_Cpo
Finance_Cpa
Health_Usr
Health_Mgr
DLO _Usr
DLO _ Mgr
Sports _Usr
Sports _ Mgr
DPCS _Usr
DPCS _ Mgr
Court _Usr
Court _ Mgr
Utilities _Usr
Utilities _ Mgr
1.0

Output

Function
Outputs
Version
Reference
Data
(Finance validated)
1.1
Scenario 6, Activity 6.1.

Appendix 2
Report
1.0
Appendix 4
109
Function
Outputs
Version
Report
Actuals_Income_Statement_report
(Program level)
1.0
Report
Actuals_Balance_sheet_report (Agency
level)
1.0
Reference
Appendix 4
Appendix 4
Activity 6.2 Consolidate Annual Actuals

The consolidation process for annual actuals is consistent with the consolidation process
details in Scenario 3.
1. The Finance_Cpo reviews the financial statements for the crown entity. The Crown
entity shows the balance of the Governments central bank account (the Official Public
Account (OPA)) as well as all transfers to and from agencies over the course of the
preceding year. It is this account from which agencies draw down their appropriations
into their own bank account and return administered receipts (e.g. taxes) to the OPA.
The crown entity is created through the Cash Management function. For the POC, the
crown entity for 2010/11 will be based on the base file base_cash_management_data
(refer Appendix 2).
2. The Finance_Cpo runs the consolidation process (as per Scenario 3, Activity 3.2). All
transactions between agencies are eliminated. This will include:
a. A grant from the Department of Health to Sports Australia;
b. Appropriation drawdown from the Crown Entity to the Department of Health,
Department of Law and Order, Department of Public Services and Public Court
c. Supplier expenses from the Department of Law and Order, Department of Health,
Sports Australia and Department of Public Services to Utilities Australia and a
supplier payable from the Department of Health to Utilities Australia;
d. A supplier expense and supplier payable from the Public Court to the Department of
Law and Order; and
e. A dividend from Utilities Australia to the Crown Entity.
3. With the exception of the grant (item a), all related entity transactions match and are
eliminated at the appropriate levels in the consolidation hierarchy for sectors and
functions (for example, Utilities Australia is the only entity not in the General
Government Sector as such, the supplier payment from the Department of Law and
Order and the dividend to the Crown entity would only be eliminated at the Whole of
Government level). The grant between the Department of Health and Sports Australia
does not agree and the difference is automatically adjusted against Healths external
grant expense applying the Set-up_elimination_matching_rules.
4. The Finance central processing officer (Finance_Cpo) runs the following statutory
reports:
a. a consolidated Income Statement and Balance Sheet for the General Government
Sector;
b. a consolidated Income Statement and Balance Sheet at Whole of Government; and
110
c.
expenses by Subfunction for the General Government Sector.
Shortlisted Tenderers are not required to show a consolidated balance sheet for the
comparative year (2009-10) in the POC but would be expected to demonstrate that this
is possible (as per Scenario 3, Activity 3.3).
5. The Finance_Cpo runs an elimination matching report for the General Government
Sector which supports the elimination process (as per Scenario 3, Activity 3.3).
As per Scenario 3, Activities 3.1 to 3.3.

Function
Inputs
Version
Reference
Data
1.1

Output. Appendix 2
Data
Base_Cash_Management_data
1.0
Appendix 2
Template
Annual_Actuals_Data_entry_template
1.0

Output
Rule
1.0

Output
Rule
Set-up_elimination_matching_rules.
1.0

Output
Security
Finance_Cpo
Finance_Cpa
1.0

Output

Function
Outputs
Data
2010-11_Annual_Actuals_Data (including
crown entity and then consolidated)
Actuals_Consolidated_Balance_Sheet
(for the General Government Sector and
at Whole of Government).
Report
Version
1.2
1.0
Report
Actuals_Consolidated_Income_Statement
(for the General Government Sector and
at Whole of Government).
1.0
Report
Actuals_expenses_by_subfunction
1.0
Reference
Appendix 2
Appendix 4
Appendix 4
Appendix 4
111
Function
Outputs
Report
Version
1.1
Reference
Appendix 4
112
Activity 6.3 Finance Rolls Over Actuals into Estimates (Process 2.1.1,
Functional Map 2.3)
Activity 6.3 - Finance Rolls Over Actuals into Estimates (Process 2.1.1)
Finance
Agency
Actuals
Management
2.3
2.2
2.1.1
Finance rolls over
actuals into
estimates
Monthly Profile
CBMS Baseline update
2.4
1
Decision
1.6.1.2
Making
2.1.2
Agency submits
estimates
CBMS
Pass system
validation?
Yes
2.1.3
Finance QAs
estimates
Passes QA?
Yes
Finance
Consolidation
Reporting and
Analysis
No
Agency
No
3
Cash
Management
At the end of the annual actuals process, the Budget Estimates for each Program are
updated to reflect differences between the most recent Budget update and the annual
actuals. The Estimates are also rolled forward one year to reflect entering a new financial
year (eg. Forward Estimate 3 becomes Forward Estimate 2 etc).
In the illustrative example below, the revised budget amount of $200 is rolled back to into
the prior year actual column. However, the prior year actual figure then needs to be
adjusted by $10 to reflect that the annual actual amount was $190, rather than $200.
113
To the extent the rollover adjustment impacts the balance sheet, this change would flow
through to all forward estimate years. For example, if the actual balance of a receivable
account for 2010-11 was $10 higher than the receivables balance for 2010-11 reported at
the most recent budget update, then the budgeted receivables would also increase by $10
in all forward years included in the budget estimates (2011-12, 2012-13, etc).
In this activity, the shortlisted Tenderer will demonstrate how the COTS Software can
compare the annual actuals to the budget estimates for 2010-11 by Program and prepare
an adjustment journal which updates the budget estimates for the difference (an adjustment
journal to update Program estimates being the output of this activity). The shortlisted
Tenderer will also demonstrate how the multi-year budget period rolls forward one year.
Requirement
Importance
Description
FR-BM-002
Core
Ability to automatically calculate the difference between actual results and

Estimates and reflect the Actuals result in the previous Actuals in
Estimates.
FR-BM-003
Core
Ability to automatically update the budget year and to reflect the rollover
into a new financial year.

Function
Inputs
Version
Reference
Data
(consolidated)
1.2

Output
Data
1.3

Output. Appendix 2
Rule
1.0
Per Scenario 1, Activity

1.3Output
Security
Finance_Cpo
Finance_Cpa
1.0

Output

Function
Outputs
Data
2011-12_Budget_Estimates_data (after
rollover)
Version
1.4
Reference
Appendix 2
114
16
Scenario 7: Monthly Reporting

This scenario covers the business processes associated with the submission and analysis
of agency actual financial information each month, including the identification of variances
to the monthly profile and submission of variance explanations.
General Government Sector agencies submit information to Finance each month on a
financial YTD basis along with explanations of variances between actual results and the
relevant monthly profile.
The POC will cover the submission of YTD financial information for August 2011 (Financial
information for July 2011 will be pre-loaded during the Scenario 1: Set-up)
the submission of actual YTD financial statement information;

for the submission of monthly reports;
integration between the monthly reporting function and the budget estimates function,
including the capture of textual explanations for budget variances; and
integration between the monthly reporting function and the cash management function,
including the ability to reconcile appropriations and transfers to the official public
account.
Activity
RFT Part Two

Reference
Activity 6.1 Enter monthly actuals
Actuals management
Clause 10.4.3
Activity 6.2 Compile variance

explanations
Actuals management
Clause 10.4.3
Activity 6.3 Reconcile to Official

Public Account
Actuals management
Clause 10.4.3
115
Activity 7.1 Enter monthly actuals (process 2.3.1.1 to 2.3.1.2 Functional

map 2.3.1)
Activity 7.1 Enter monthly actuals (process 2.3.1.1 2.3.1.2)

Agency
Agency
CBMS
Finance QA
2.3.1.2
Agency submits
actuals to CBMS
2.2
Finance
2.3.2
2.3.1.1
Agency prepares
actual statements
Actuals
Actuals
Actuals to estimates
2.3.1.3
Agency compares to
budget profile
Unauthorised
Agency
authorised
2.3.2
Finance
validated
Estimates
Monthly
Profile
2.3.1.4
Agency enters
variance
explanations
Yes
Variance
explanations
required?
being Agency
2.3.1.5
Agency reconciles to
OPA
No
3
Finance QA and
analysis
Cash
Actuals to cash
Cash
Management
No
OPA
reconciled?
Yes
2.3.1.6
Agency approves
actual statements
No
Passes
system
validations?
Yes
2.3.1.7
Agency submits
other notes
(Annual only)
Passes
system
validations?
Yes
No
As per previous scenarios, in this activity Sports Australia and the Department of Law and
Order have chosen to enter YTD August 2011 financial statements via direct entry (using
the monthly_actual_data_entry_template). With the exception of Utilities Australia, the
remaining POC agencies submit their annual actuals via a flat file upload using the same
user interfaces as per Scenario 2, Activity 2.4. As a PNFC, Utilities Australia does not
submit monthly financial information to Finance.
In submitting their monthly actuals, agency users will be able to see online the
corresponding amounts for the most recent monthly profile.
The status of the monthly actuals is Draft, meaning that Finance cannot amend the
financial information.
Requirement
Importance
Description
FR-BM-048
Core
Report monthly and annual Actuals information (financial statement and

supporting schedules) against various aspects of the RDS (eg. Account,
Program, function, SPPs, control type, etc) via direct entry or batch
upload. The Actuals data will be at a level consistent with the relevant
Estimates.
FR-BM-051
Core
Allow for Actuals by RDS to be prepared offline for bulk entry (eg. via
116
Requirement
Importance
Description
FR-BM-052
Core
FR-BM-061
Core

FR-BM-062
Core
Provide the ability for Finance and Agencies to progress Actuals data

Function
Inputs
Version
Reference
Data
2011-12_August_YTD_Actuals_Data
1.0
Appendix 2
Base
Base_Monthly Estimates_Data
1.0

Output
Appendix 2
Template
Monthly_actual_data_entry_template
1.0

Output
Appendix 3
Rule
Set-Up_Business_Rules
1.0

Output
Security
User profile for:

Health_Usr
DLO_Usr
Sports_Usr
DPCS_Usr
Court_Usr
1.0

Output

Function
Outputs
Data
2011-12_August_YTD_Data (Draft)
Version
1.1
Reference
Appendix 2
117
Activity 7.2 Compile variance explanations (process 2.3.1.3 -2.3.1.4

Functional Map 2.3.1)
Activity 7.2 Compile variance explanations (process 2.3.1.3 2.3.1.4)

Agency
Agency
CBMS
Finance QA
2.3.1.2
Agency submits
actuals to CBMS
2.2
Finance
2.3.2
2.3.1.1
Agency prepares
actual statements
Actuals
Actuals
2.3.1.3
Agency compares to
budget profile
Unauthorised
Agency
authorised
2.3.2
Finance
validated
Estimates
Monthly
Profile
2.3.1.4
Agency enters
variance
explanations
Yes
Variance
explanations
required?
No
3
Finance QA and
analysis
Cash
being Agency
2.3.1.5
OPA
Actuals to cash
Cash
Management
No
OPA
reconciled?
Yes
2.3.1.6
Agency approves
actual statements
No
Passes
system
validations?
Yes
2.3.1.7
Agency submits
other notes
(Annual only)
Passes
system
validations?
Yes
No
Once each agency has entered their monthly financial statements, the CBMS Solution will
calculate, by account, the difference between the monthly actual and the corresponding
monthly profile. Where this difference exceeds either a dollar variance or a percentage
variance, the user will be required to enter a textual explanation for the budget variance. In
the POC, the CBMS Solution will apply a threshold of $50 million or 10%. The user will be
required to submit an explanation for each variance above the threshold prior to submitting
their financial statements to Finance. An example variance explanation would be The
actual number of people getting sick was 20% higher than budgeted combined with higher
per unit prices of the no sneeze drug
The agency user (e.g Health_Usr) or approver (e.g Health_Mgr) can run a report which lists
the variances and associated explanations.
Functional
Requirement
Importance
Description
FR-BM-059
Core
Ability to report actual monthly financial results compared to multiple

sources including monthly profiles and prior year data and report variance
explanations.
FR-BM-050
Core
Ability to capture explanatory text for variance reporting.
118
Requirement
Importance
Description
FR-BM-060
Core
Enable the setting of thresholds for automatic variance reporting.
FR-BM-069
Core
Ability to QA and accept/reject Agency adjustments to comparative

statements.

Function
Inputs
Version
Reference
Data
2011-12_August_YTD_Actuals_Data
1.1

Output
Base
Base_Monthly_Estimates_data (201011 Budget data)
1.0
Appendix 2
Template
Monthly_actual_data_entry_template
1.0

Output
Rule
1.0

Output
Security
User profile for:

Health_Usr
DLO_Usr
Sports_Usr
DPCS_Usr
Court_Usr
1.0

Output

Function
Outputs
Data
2011_12_August_YTD_Actuals_Data
(with variance explanation)
Note: variance explanations have not
been provided at this stage in the
appendix. However, some variance
text will be entered during evaluation.
Monthly_Budget_variance_report
Report
Version
Reference
1.1
1.0
Appendix 4
119
Activity 7.3 Reconcile to Official Public Account (OPA) (process 2.3.1.5

Functional map 2.3.1)
Activity 7.3 Reconcile to OPA (process 2.3.1.5)

Agency
Agency
CBMS
Finance QA
2.3.1.2
Agency submits
actuals to CBMS
2.2
Finance
2.3.2
2.3.1.1
Agency prepares
actual statements
Actuals
Actuals
2.3.1.3
Agency compares to
budget profile
Unauthorised
Agency
authorised
2.3.2
Finance
validated
Finance QA and
analysis
Estimates
Monthly
Profile
Yes
Variance
explanations
required?
No
3
2.3.1.4
Agency enters
variance
explanations
Cash
being Agency
2.3.1.5
OPA
Actuals to cash
Cash
Management
No
OPA
reconciled?
Yes
2.3.1.6
Agency approves
actual statements
No
Passes
system
validations?
Yes
2.3.1.7
Agency submits
other notes
(Annual only)
Passes
system
validations?
Yes
No

1. The Health agency user checks that their appropriations from and transfers to the
Official Public Account (i.e. the Crown entity) reconciles to the appropriation draw
downs and cash transfers entered over the course of the year-to-date through the cash
management function (refer Scenario 5).
The POC will adopt a simplified form of this reconciliation as follows:
Reconciliation to the Official Public Account
Per Agency Monthly Actuals
$,000
Ref
plus
Appropriations: Price of Outputs Revenues

Appropriations: Administered Revenues
(a)
(b)
plus Opening
less Closing
Appropriations Receivable as at beginning of year

Appropriations Receivable - Other
(c)
(d)
less
Cash transfers to the OPA
(e)
equals
Net Cash Transfers from / (to) the Official Public Account
Per Official Public Account (Cash management function)

equals
less
Appropriation drawdowns to Agency

Cash transfers from agency
equals
Net Drawdowns to / (transfers from) agency
Variance
(f)
(g)
0
0
Parts (a) to (e) of the above reconciliation are sourced from the following accounts
entered by the agency during the monthly reporting update:
120
(a) Account 1280004 - Price of Outputs Appropriation for August 2011 YTD
(b) Movement Account 7593 - Administered Appropriations from the OPA for August
2011 YTD
(c) Account 5233029 - Appropriations Receivable as at 30 June 2011
(d) Account 5233029 - Appropriations Receivable as at 31 August 2011
(e) Movement Account 7592 - Cash transfers to the OPA for August 2011 YTD
Parts (f) to (g) are sourced from the cash management function and represent the sum
of the cash appropriation draw downs (f) and the administered receipts (g) entered by
each agency for the year-to-date.
If the reconciliation does not reconcile, the user will check and restate their monthly
actuals.
2. Once the statements and variance explanations have been entered by each agency
user (e.g Health_Usr) and the OPA reconciliation reviewed the user checks that the
monthly actuals passes the POC business rules. The monthly actuals cannot be
approved by the agencies approvers (e.g Health_Mgr) unless the validations are
passed.
3. The monthly actuals are then approved by each agencies approver (e.g Health_Mgr)
and are available to Finance to undertake quality assurance checking.
The status of the monthly actual information is now Agency Authorised, meaning that
the Agency can no longer adjust the financial information and it is now available to
Finance.
Requirement
Importance
Description
FR-BM-056
Core
Automatically link to OPA transaction data as part of the cash reconciliation

process for monthly Actuals.
FR-BM-058
Core
Ensure Actuals data pass pre-defined validation rules (eg. accounting rules,
business process rules) before submission is accepted.
FR-BM-061
Core


Function
Inputs
Data
2011-12_ August_YTD_Actuals_Data
Version
1.1
Reference
Output, Appendix 2
121
Function
Inputs
Version
Reference
Data
1.8

Output, Appendix 2
Rule
1.0

Output
Security
User profile for:

Health_Usr
DLO_Usr
Sports_Usr
DPCS_Usr
Court_Usr
1.0

Output

Function
Outputs
Data
2011-12_ Monthly_Actuals_Data
(Finance validated)
Monthly_OPA_Reconciliation_Report
(Health)
Report
Version
1.1
1.0
Reference
Appendix 2
Appendix 4
122
17
Scenario 8: Application Administration

This scenario covers the business processes associated with changes occurring to the
underlying Government structures. The underlying structure of Government can be affected
by MOG changes that assign responsibility to Agencies for the management of
administrative arrangements and delivery of Programs or through Government-requested
changes to Programs and Outcomes.
In this Scenario, the shortlisted Tenderers POC will be evaluated to assess the shortlisted
a central facility to manage changes to the RDS that are applied consistently across all
functions;
the capture of audit information for any reference data changes;
the ability to maintain data integrity following changes to the RDS;
the ability to manage and classify adjustments to Appropriation Limits to reflect a MoG
change (e.g. section 32 transfer of function); and
application access controls that allow the modification of user access across multiple
dimensions.
Activity
RFT Part Two

Reference
Activity 8.1 RDS Change: Moving a

Program between Agencies
Budget Estimates
Activity 8.2 Transfer of Functions

(Section 32 FMA)
Cash Management
Clause 10.5.1(b)
Activity 8.3 RDS Change: Change of

an Agency Name
Budget Estimates
Clause 10.7.2
Activity 8.4 Change to user profile
Budget Estimates
Clause 10.7.3
Activity 8.5 RDS Change: Change to

Chart of Accounts
Budget Estimates
Clause 10.7.2
Activity 8.6 Implementation of a new

business rule
Budget Estimates
Clause 10.7.2
Cash Management
Actuals
Clause 10.7.1
Actuals
123
Activity 8.1 RDS Change: Moving a Program between Agencies

1. The Finance_Admin user will move the Program Community Pharmacy from the
Department of Health Agency to the Department of Public Services Agency by
changing the Outcome to which the Program aggregates to within the RDS. The
effective date of the new structure will be 1 September 2011.
2. Once the amendment has been applied to the system (step 1), Budget Estimates data
existing against the Program Community Pharmacy will now aggregate to the
Department of Public Services Agency.
3. Actuals and Cash Management historical data (data entered before the effective date of
1 September 2011) that relates to the Community Pharmacy Program will be reported
under the Department of Health Agency.
Requirement
Importance
Description
FR-AA-019
Core
FR-AA-020
Highly
Desirable
The ability to show changes between RDS versions with date, time and
user ID stamping for identification.
FR-AA-022
Core
Allow the automatic adding and updating of dependent reference data

elements (i.e. look up lists).
FR-AA-024
Core
Provide a tool and UI to assist in editing the RDS, and the relationships
between elements in online, real-time manner to support dynamic changes,
(eg. to RDS structures and their elements). The CBMS Solution is to
include a UI to maintain the RDS.
FR-AA-025
Core
Ability to enforce a multi-step approval process for changes to the RDS

including the ability to monitor the status of the proposed change.
FR-AA-026
Core
Provide the flexibility to redefine RDS structures, in particular the

relationships between elements.
FR-AA-027
Highly
Desirable
FR-AA-028
Core
The ability to maintain multiple effective date RDS hierarchies at the same
time and maintain snapshots of historical versions.
Provide the facility to view the RDS structures in their entirety, and select
individual elements to view their details and where the individual element
has moved in the RDS over time (eg. a Program moving between
Agencies).
Record audit information for any reference data changes including
date/time, user and session.
124
Requirement
Importance
Description
FR-AA-029
Core
Provide a facility so that the reference data managers can run an audit
report that lists the changes made, the date/time that they were made, and
who made the changes. The user will have the ability to select a version
number or a date range.
FR-AA-030
Core
Allow multiple RDSs to be maintained and used simultaneously.
FR-AA-033
Core
Changes to the RDS will be available to users within strict deadlines ( eg.
within 2 hours for critical changes).
FR-AA-034
Core
To ensure that the integrity of data is maintained when changes are made
to the RDS ( eg. an element cannot be deleted from the RDS if it has data
already entered against it).

Function
Inputs
Version
Reference
Set-Up
Program_Data
1.0
Appendix 2
Set-Up
Admin_Program_Change
1.0
Appendix 2
Security
User profile for:

Finance_Admin
1.0
Appendix 2

Type
Outputs
Version
Set-Up
Program_Data
1.1
Report
PBS_Balance_Sheet (Both Health and

DPCS)
1.5
Reference
Appendix 2
Appendix 3
125
Activity 8.2 Transfer of Functions (Section 32 FMA) (Process 3.1.2.1

Functional Requirement Map 3.1.2)
Activity 4.2 Manage Appropriation Limits (Process 3.1.2.1 Transfer of Functions s32 FMA)
Finance
Cabinet / PM /
Ministerial
Decision, AAO
Change
Ministerial
Request
3.1.2.1
Transfer of
Functions
(s32 FMA)
3.1.2.2
Appropriation
Reduction
(section 9)
AFM/APO
Application
3.1.2.3
Advance to the
Finance Minister
(AFM / APO)
Request for
Movement of Funds
Savings
identified
Reallocation
identified
Requirement to
Refund
Amount of
Admin Operating
Approp Required
3.1.2.4
Movement of
Funds Process
(Re-phasings)
3.1.2.5
Identified
Savings
3.1.2.6
Reallocation
between Prog &
Outcomes
3.1.2.7
Refund of
Administered
Receipts (s28)
3.1.2.8
Section 11
Administered
Optng Process
2.1
AAU Decision
3.1.2.9
Ad-hoc
Quarantine
3.1.3
Management of
Budget Estimates
Enter Daily Cash

Transactions (adjusted
drawdown limit)
CBMS
Note These processes, except Section 11 and Quarantines will result in changes to data in Annual Estimates (2.1)
Section 32 of the FMA Act enables the transfer of an amount of appropriation where a
function is transferred between agencies, either because an agency is abolished or for any
other reason. The section 32 is required due to the MOG change where Department of
Healths Community Pharmacy program is to be transferred to Department of Public
Services.
1. The scenario starts with Health processing a section 32 transfer application in the
system, following a MOG change. Health_Usr processed the application in the CBMS
Solution and Health_Mgr approved the process. At this stage, the process temporarily
quarantines (holds the relative amount with an effect of temporarily reducing the
Appropriation Limit) the Appropriation of Health to prevent the Department of Health
from performing a drawdown. This will be recorded in the CBMS Solution as a
Quarantine appropriation adjustment.
2. Following Agency approval in the CBMS Solution, the application for section 32 transfer
is transferred to Finances for review and approval. Finance_Cpa receives a notification
in the system of a pending section 32 transfer application. While performing the review,
Finance_Cpa verifies the amount entered by viewing the on-screen account balance.
The section 32 transfer will be held in the system, pending completion of relative
legislative process. The Appropriation will continue to be in Quarantine status.
3. Once the relative process and documentation has been completed Finance_Cpa
approves the section 32 in the CBMS Solution. In effect, the quarantine on Department
of Healths Appropriation will be lifted; the status will change from Quarantine to section
32 which permanently reduces the balance of the Appropriation. On the other hand,
126
Department of Public Services Appropriation increases by the amount reduced from

Department of Healths Appropriation.
4. Finance_Cpa runs the reports to check the section 32 transfer. The details of the
transfer should reflect in the Approp_Limit_Detail_Report.
For the purpose of the POC the automatic production of Determinations is not being tested.
Requirement
Importance
Description
Core
Ability to automatically update Appropriation limits for legislative

determinations and other approval changes subject to a multi-step
approval process.
Core
Ability to categorise Appropriation limit adjustments by reason code (e.g.

Advance to the Finance Minister (AFM), movement of funds, section 32,
additional categories, etc).
FR-CM-009
Core
Record audit trail for any change to Appropriation (e.g. limit, amount, type,
reason).
FR-CM-010
Core
Ensure that any change to an Appropriation requires multiple step

approval.
FR-CM-011
Core
The ability to track Appropriations and transactions over multiple years

(e.g. non-lapsing Appropriations).
FR-CM-013
Core
Enable on-screen Account balance details by Appropriation.
Core
Support capture of financial data for the production of Appropriation Bills

and selected tables within annual Budget Papers (e.g. Budget Papers 1
through 4, and PBS).
Desirable
Ability to automatically produce applications and determinations resulting

from certain legal Appropriation adjustments (e.g. AFM s 32
determination).
FR-CM-007
FR-CM-008
FR-CM-014
FR-CM-016
FR-CM-018
Core
Ability to add and remove quarantine Appropriations (or amounts of

Appropriations) to prevent (and potentially reinstate) Agency ability to
drawdown quarantined amount.
Ability to automatically update both sides for Appropriation limit transfers
between Appropriation types following a multi-step approval process in
accordance with the Governments Appropriation framework.
FR-CM-019
Highly
Desirable
FR-RA-013
Core
FR-RA-033
Core
and reports.
127

Function
Inputs
Data
S32_Appropriations_Adjustment_Data
1.0
Data
S32_Appropriations_Adjustment Data
(Quarantined)
1.1
1.2

Output
Template
Approp_Adjustment_Template
1.0
Appendix 3
Security
User profile for:

Health_User
Health_Mgr
Finance_Cpa
1.0
Approp_Adjustment_Business_Rule
1.0

Output
Version
Reference
Data
Rule
Version
Reference
Appendix 2
Appendix 2

Output

Function
Outputs
Data
1.3
Report
Approp_Limit_Detail_Report
(Quarantine)
1.1
Report
Approp_Limit_Detail_Report (s32)
1.2
Appendix 4
Report
1.6
Appendix 4
Appendix 2
Appendix 4
Activity 8.3 RDS Change: Change of an Agency Name

1. User Finance_Admin renames Agency Department of Public Services to Department
of Public and Community Services within the RDS.
2. Once the amendment has been applied to the system (step 1), data existing against the
Department of Public Services will now be reported under the Department of Public
and Community Services. The reports will also update with the new name.
3. Historical data for Actuals and Cash Management (data entered before the effective
date) relating the Department of Public and Community Services will be reported
under the Department of Public Services name.
128
Requirement
Importance
Description
FR-AA-019
Core
FR-AA-020
Highly
Desirable
The ability to show changes between RDS versions with date, time and
user ID stamping for identification.
FR-AA-022
Core
Allow the automatic adding and updating of dependent reference data

elements (i.e. look up lists).
FR-AA-024
Core
between elements in online, real-time manner to support dynamic
changes, (eg. to RDS structures and their elements). The CBMS
Solution is to include a UI to maintain the RDS.
FR-AA-025
Core
Ability to enforce a multi-step approval process for changes to the RDS

including the ability to monitor the status of the proposed change.
FR-AA-026
Core
Provide the flexibility to redefine RDS structures, in particular the

relationships between elements.
FR-AA-027
Highly
Desirable
FR-AA-028
Core
Record audit information for any reference data changes including

date/time, user and session.
FR-AA-029
Core
Provide a facility so that the reference data managers can run an audit
report that lists the changes made, the date/time that they were made,
and who made the changes. The user will have the ability to select a
version number or a date range.
FR-AA-030
Core
FR-AA-033
Core
Changes to the RDS will be available to users within strict deadlines (

eg. within 2 hours for critical changes).
FR-AA-034
Core
To ensure that the integrity of data is maintained when changes are

made to the RDS ( eg. an element cannot be deleted from the RDS if it
has data already entered against it).
The ability to maintain multiple effective date RDS hierarchies at the

same time and maintain snapshots of historical versions.
Provide the facility to view the RDS structures in their entirety, and
select individual elements to view their details and where the individual
element has moved in the RDS over time (eg. a Program moving
between Agencies).
129

Function
Inputs
Version
Reference
Data
2011 Updated Budget Estimates data
1.0
Appendix 2
Set-Up
Program_Data
1.1
Appendix 2
Set-Up
User profile for:

FDO_DPS
FDM_DPS
1.0

Type
Outputs
Version
Reference
Set-Up
Program Data
1.2
Appendix 2
Report
PBS_Balance_Sheet
1.2
Appendix 3
Activity 8.4 RDS Change: Change to user profile

This scenario covers the business processes associated with proving the ability to modify
user access roles across multiple dimensions. The activity relates to the functionality
involved in ensuring that the CBMS Solution is capable of enforcing controls on information
and access to functionality, at a sufficient level of detail to support the security model.
1. The user Finance_Admin provide additional access to user profile Fdo_Health
enabling them access to a second agency Department of Public and Community
Services.
2. The change applied to the system (step 1) will be displayed within the user access log.
3. The user Fdo_Health will be able to read/write to the added agency.
Requirement
Importance
Description
FR-AA-038
Core
Application access controls are to allow the modification of access across

multiple dimensions (eg. deny all users access to specific functions, or
grant access to an entire portfolio).
FR-AA-042
Core
The ability to report on the user access patterns, for example:
130
Requirement
Importance
Description
active and de-activated users;

what access (roles) a current user has;
history of what roles a user has had in the past;
time periods during which the user was active;
who created or updated the user;
the time periods when users where locked out;
who created or updated a role and the access rights; and
date of last logon for a user and a report of users who have not
accessed in the last x number of days.
FR-AA-043
Core
User roles and relevant access rights are to be automatically updated to

retain relationships with elements of the RDS as it changes.
FR-AA-045
Core
The access management UI is to include the ability to grant or deny an

authorised user access to one or more roles.

Function
Inputs
Version
Set-Up
User profile for:

Finance_Admin
1.0
Set-Up
User_Access_Roles
1.0
Reference

Type
Outputs
Security
User_Access_Roles
Report
Admin_user_access_report
Version
Reference
1.1
1.0
Activity 8.5 RDS Change: Change to Chart of Accounts

This scenario covers the business processes associated with proving the ability to modify
the RDS structure in relation to the Chart of Accounts structure.
131
1. The Finance_Admin user will create the new account 2330009: Grants - Current by
modifying the Chart of Accounts structure within the RDS. The effective date of the new
account will be 1 September 2011.
2. The Admin_COA_Report will show the RDS change as per step 1.
Requirement
Importance
Description
FR-AA-015
Core
Enable the application of business rules to the RDS that define the relationships
between Accounts, and the level at which data elements are required.
FR-AA-016
Core
Enable the mapping of central CoA to other required standards (eg. derived
cash flow).
FR-AA-017
Core
Enable the classification of Accounts to enable the automatic generation of

defined reports including Agency financial statements represented by Balance
Sheet, Operating Statement, and Cash Flow Statement.
FR-AA-018
Core
Enable differences in Account types, (eg. income and expenditure), Accounts

as distinct from Balance Sheet, Accounts as distinct from notes information
(balances supplied to assist in production of notes to the financial statements),
and the various sub-categories within each category (eg. revenue, expense,
asset, liability, cash flow, equity).
FR-AA-019
Core
The ability to maintain multiple effective date RDS hierarchies at the same time
and maintain snapshots of historical versions.
FR-AA-020
Highly
Desirable
The ability to show changes between RDS versions with date, time and user ID
stamping for identification.
FR-AA-021
Core
Enable the configuration of relationships using dependent hierarchies for RDS

structures (eg. Outcome-Program hierarchy).
FR-AA-022
Core
Allow the automatic adding and updating of dependent reference data elements
(i.e. look up lists).
FR-AA-023
Core
Provide a tool and UI to allow on-line, real-time viewing and visualisation of

RDS elements (i.e. code table style data, account structure and hierarchy)
including their interrelationships. The CBMS Solution is to include a UI to
maintain the RDS.
FR-AA-024
Core
between elements in online, real-time manner to support dynamic changes, (eg.
to RDS structures and their elements). The CBMS Solution is to include a UI to
maintain the RDS.
132
Requirement
Importance
Description
FR-AA-026
Core
Provide the flexibility to redefine RDS structures, in particular the relationships

between elements.
FR-AA-027
Highly
Desirable
Provide the facility to view the RDS structures in their entirety, and select
individual elements to view their details and where the individual element has
moved in the RDS over time (eg. a Program moving between Agencies).
FR-AA-028
Core
Record audit information for any reference data changes including date/time,
user and session.
FR-AA-029
Core
Provide a facility so that the reference data managers can run an audit report
that lists the changes made, the date/time that they were made, and who made
the changes. The user will have the ability to select a version number or a date
range.
FR-AA-030
Core
FR-AA-031
Core
Provide flexibility to report on the content of any defined level in the RDS
hierarchy.
FR-AA-033
Core
Changes to the RDS will be available to users within strict deadlines (eg. within
2 hours for critical changes).

Function
Inputs
Set-Up
Set-up_Account_Data
Version
1.0
Reference
Appendix 2

Type
Outputs
Version
Reference
Set-Up
Set-up_Account_data
1.1
Appendix 2
Report
Admin_COA_Report
1.1
Appendix 2
133
Activity 8.6 Implementation of a new business rule

This scenario covers the business processes associated with proving the ability to
implement a new business rule in the CBMS Solution.
This activity involves the ability to implement a new new business rule into the CBMS
Solution. The validation rule will force a validation error when the sum of the account
balance for account 2330009: Grants - Current does not equal the balance of account
2330000: Grants.
Requirement
Importance
Description
FR-AA-001
Core
Enable the creation and recording of accounting and validation rules

including the user defined rules, a unique identifier and a user-friendly
description of what the rule does.
FR-AA-002
Core
Enable the creation of business rules to apply to different combinations of

the RDS (eg. restrict Accounts to certain Agencies) and across functions
(eg. Budget and Actual)
FR-AA-004
Core
Enable the recording of audit information upon entry or change to

accounting or validation rules including date / time, version, user and
session details.
FR-AA-008
Core
Has a centralised business rules management capability, such that a

single business rule can be created once and reused consistently
throughout the various CBMS Solution functions and interfaces.
FR-AA-009
Core
Business rules are to be able to be changed via a UI without requiring

program coding changes.
FR-AA-010
Core
The ability to promote business rule changes into production independent

of a standard code change release.
FR-AA-011
Core
The ability to promote business rule changes into production within a

defined time-frame consistent with business continuity requirements (eg.
two hours for changes to the RDS in a Budget update).
FR-AA-012
Core
The ability to toggle business rules on and off, and to set the level of
impact for breaking individual rules (pass/fail/warning).
FR-AA-013
Core
Support the maintenance of a library of business rules.
134

Type
Inputs
Set-Up
Version
1.0
Reference
Appendix 2

This activity will produce the business rules which will be utilised in the subsequent
Type
Outputs
Set-Up
Version
1.1
Reference
Appendix 2
135
18
Scenario 9: Mid Year Update and Monthly Profile

This scenario covers the business processes associated with a Mid Year Update of the
Budget Estimates. It covers the entry of Budget Estimates and the financial consolidation
process. It also covers the update of the Monthly Estimates Profile to reflect changes in the
Budget Estimates for 2011-12.
the capture and reporting of Government decisions;
entering or uploading multi-year budgeted financial data against a predefined RDS;
data integrity through system-based validations, reconciliations and approval controls;
entry of consolidation adjustments and the consolidation of estimates data to produce a

derived cash flow statement and reconciliation tables;
entering or uploading budgeted financial data profiled against the remaining months of
the financial year against a predefined RDS; and
ability to define reporting across multiple dimensions.
Activity
RFT Part Two

Reference
Management of Budget
Estimates
Clause 10.4.1
Activity 9.2 Consolidate Financial

Statements
Clause 10.4.4
Activity 9.3 Derive Cash Flows and

Aggregates
Clause 10.4.4
Activity 9.4 Produce Financial

Statements and Reconciliation Tables
Statutory Reporting
Clause 10.6.1
Activity 9.5 - Finance Loads Year-End

Estimates and YTD Actuals into Profile
Monthly Profiling of
Estimates
Clause 10.4.2
Activity 9.6 Enter Monthly Profile
Monthly Profiling of
Estimates
Clause 10.4.2
Activity 9.7 User-defined reporting
Clause 10.6.2
136
Activity 9.1 Enter Budget Estimates (Process 2.1.2.1 2.1.2.6 Functional

Agency
Pass system
validations?
No
CBMS
System validation
report
Yes
Finance AAUs
2.1.2.3
Agency authorises
measure adjustment
2.1.2.2
Agency submits
Estimate Variations
into CBMS
2.1.2.1
Agency prepares
adjustment for
Government decision
Check if consistent
with Finance high
level measure
details
Decision
Making
2.1.3
Finance QAs
estimates
Decision
Making
2.1.2.4
Agency prepares
parameter and other
adjustment
Consult Finance
Estimates
Agency
Finance
Variations
Authorised
Validated
Unauthorised
2.1.3
Finance QAs
estimates
2.1.2.5
Agency submits
parameter and other
CBMS
Agency/Finance
No
Pass system
validations?
System validation
report
Yes
2.1.2.6
Agency authorises
parameter and other
adjustment
At the Mid Year update of the Budget Estimates, the Government has decided to extend its
decision from the 2011-12 Budget and is now also banning the use of bagpipes at sporting
events. As with the decision in the 2011-12 Budget, this is a cross-portfolio measure led by
the Department of Law and Order (DLO), with funding also provided for Health and Sports
Australia.
The Government has also decided that:
Sports Australia will sell official merchandise for the national sporting team; and
The Public Court will build a new Court house.
Each measure code will need to distinguish the type of decision (Capital, Expense or
Revenue), and that it is a MYEFO decision.
While this scenario is not testing the entry of measures text or high level budgetary
impacts, a measure code is created consistent with the process in activity 2.1 of scenario 2.
Consistent with the Budget Update (activity 2.4 of scenario 2), DLO, Health, Sports and the
Public Court enter the detailed impact of their Measures into CBMS. At the Mid Year
update, all Agencies also adjust their Budget Estimates for parameter and other
movements.
Upon entry, the adjustments derive the impact on key financial aggregates, such as
Underlying Cash and Fiscal Balance.
The activity involves the following steps:
1. Agency_User roles updates Budget Estimates as per the template
Budget_Estimates_Data_entry_template.
137
2. The adjustment entered in step 1 is approved by the agency approver role

Agency_Mgr.
3. The adjustment is then approved by the Finance_Cpo user.
Each Agency has chosen to use the same method of data entry as used in the Budget
Update. Once approved within the Agency, data is sent through to Finance for quality
assurance and approval.
This activity will enable shortlisted Tenderers to demonstrate the requirements as outlined
in Activities 2.1 and 2.4 of Scenario 2.

Type
Inputs
Version
Reference
Data
1.4
Scenario 3, Activity 3.2

Appendix 2
Template
Budget_Estimates_Data_entry_template
1.0
Appendix 3
Rule
Setup_Business_Rules
1.0

Output
Security
User profile for:

Finance_Cpo
Finance_Cpm
Health_Usr
Health_Mgr
DLO _Usr
DLO _ Mgr
Sports _Usr
Sports _ Mgr
DPCS _Usr
DPCS _ Mgr
Court _Usr
Court _ Mgr
Utilities _Usr
Utilities _ Mgr
FDO_Health
FDO_DLO
FDO_Services
1.0

Output and Scenario 8,
Activity 8.3
138

Type
Outputs
Version
Reference
Data
1.5
Appendix 2
Report
Measure_Code_report
1.1
Appendix 4
Report
1.2
Appendix 4
Report
1.1
Appendix 4
Activity 9.2 Consolidate Financial Statements (process 2.4.2.1 Functional

Consolidate Financial Statements (Process 2.4.2.1 Functional Requirement Map 2.4.2)
CBMS
Finance
Finance
Agency
Yes
2.4.2.3
Liaise with agencies
Agency agrees to
amend?
No
No
2.4.1
Post manual
consolidation journals
2.4.1
2.4.2.1
Run consolidation
and eliminations
2.4.2.2
Review elimination
matching
Post manual
consolidation
Elimination
variances
immaterial?
Yes
2.4.3
Statements
Elimination matching
report
Unauthorised
Agency
Authorised
Finance
validated
Once all Agency adjustments have been entered, quality assured by Finance and
approved, the Budget Estimates are consolidated in order to produce a General
Government Sector Balance Sheet and Operating Statement.
The processes followed in this activity replicate those followed in activity 3.2 of scenario 3.
However, unlike activity 3.2, a consolidation journal has not been entered for this activity
and all related entity balances match on consolidation.
in activity 3.2 of scenario 3.
139

Type
Inputs
Version
Reference
Data
1.5

Output. Appendix 2.
Rule
Setup_elimination_Matching_rules
1.0

Output
Security
User profile for:

Finance_Cpo
1.0

Output

Type
Outputs
Version
Reference
Data
1.6
Appendix 2
Report
Estimates_Consolidated_Income_Statement
1.1
Appendix 4
Report
Estimates_Consolidated_Balance_Sheet
1.1
Appendix 4
140
Activity 9.3 Derive Cash Flows and Aggregates (process 2.4.1 Functional
Financial Consolidation (Functional Requirement Map 2.4)
Finance
Agency
2.1
No
Agency amends?
Budget Estimates
2.2
No
2.4.1
Post manual
consolidation
journals
2.4.2
Consolidate financial
statements
Eliminations
materially match?
Yes
2.4.3
QA consolidated
statements
Passes QA?
Yes
2.4.4
Derive cashflows
and aggregates
4
Reporting
and
Analysis
Monthly Profile
No
2.3
Actuals Management
The Cash Flow Statement is calculated by taking the Operating Statement and adjusting it
for movements in the Balance Sheet. A number of key fiscal aggregates (Net Operating
Balance, Fiscal Balance and Underlying Cash) are also derived. Finance conducts quality
assurance checks over the consolidated Cash Flow Statement and key fiscal aggregates
and attributes consolidation adjustments out by Agency.
In this scenario, the Finance_Cpo has run a derived cash flow report to interrogate and
analyse movements to ensure the derivation model accurately reflects cash movements.
As a result of this analysis, the Finance_Cpo has identified the need to submit a
consolidation adjustment to adjust the derived cash flow. These consolidation adjustments
are distinguished as cash flow adjustments and impact only on the Cash Flow Statement.
As with other consolidation adjustments entered in Scenario 3, Actvity 3.2, these journals
adjust Agency submitted data but do not overwrite the Agency submitted data. The
process for entering cash flow adjustments is consistent with other consolidation
adjustments
The cash flow adjustment is a reclassification of a cash flow for Sports. While Sports has
entered its Budget Estimates for the Sports Assistance Program as an impact on grant
payments, an amount will be reclassified to personal benefit payments.
141
1. The Finance_Cpo enters a consolidation adjustment to move the data from personal
benefit payments to supplier payments.
2. Once cash flow adjustments are entered, they are reviewed and approved by
Finance_Cpa.
in activity 3.1 of scenario 3. It will also allow shortlisted Tenderers to demonstrate the
following functional requirements:
Requirement
Importance Description
FR-BM-021
Core
Ability to enter adjustments which only impact on the Cash Flow Statement
and/or other derived Measures (eg. to override a derived impact or reclassify
amounts between cash flow classifications).
FR-BM-084
Core
Ability to produce a system derived cash flow on both the Budget Estimate
financial statements and individual adjustments, using a pre-determined
methodology.

Type
Data
Inputs
Version
Reference
1.6

Output. Appendix 2.
Template
Budget_Estimates_Data_entry_
template
1.0
Appendix 1
Rule
Setup_Business_rules
1.1

Output
Rule
Setup_Derivation_rules
1.0

Output
User
User profile for:

Finance_Cpo
Finance_Cpa
1.0

Output

Type
Outputs
Data
(Consolidated MYEFO, including
Cash-flow)
Version
1.7
Reference
Appendix 2
142
Type
Outputs
Version
Report
Estimates_Consolidated_Cashflow_Statement
1.0
Reference
Appendix 4
Activity 9.4 Produce Financial Statements and Reconciliation Tables

(process 4.1.1 and 4.1.2 Functional Requirement Map 4.1)
4.1 Statutory Reporting

Finance/Treasury
Actuals
Management
2.3
Monthly
Profile
2.2
Budget
Estimates
2.1
4.1.1
Produce financial
statements
4.1.2
Produce
reconciliation tables
Decision
Making
4.1.3
Produce measures
tables
Budget
Estimates
2.1
4.1.4
Produce portfolio
budget statements
Cash
Management
4.1.5
Produce
appropriation bills
and resourcing
tables
Actuals
Management
2.3
Budget
Estimates
2.1
5
Data administration
(Archive estimates)
Print and release

budget papers
4.1.6
Produce federal
financial relations
tables
Following the consolidation of the Budget Estimates and entry of cash flow adjustments,
Statutory Reports are produced. In this scenario Reconciliation Tables are produced.
The Reconciliation Tables distinguish movements in Underlying Cash and Fiscal Balance
since the 2011-12 Budget, between those caused by Government decisions and those
caused by parameter and other movements.
The movements in Underlying Cash and Fiscal Balance are a summation of all the
Estimate adjustment journals (both Agency and consolidation adjustments) that have been
entered and approved since the Budget tables produced in scenario 3.
The Reconciliation Tables are run by Finance_Cpo.
Together with the requirements as outlined in activity 3.5 of scenario 3, this activity will
enable shortlisted Tenderers to demonstrate the following functionality:
143
Requirement
Importance
FR-RA-017
Core
Allow users to report on Measures.
Core
Ability to group and order Measures and associated narrative prior to producing
Measures tables, incorporating the ability for ASCII text and formatting and
copying and pasting Measures text from Microsoft Word.
Core
Ability to produce Measures tables in print-ready formats including text.
Core
Ability to suppress financial impacts where sensitivities such as commercial-inconfidence require that numbers are not disclosed.
FR-RA-018
FR-RA-019
FR-RA-020
Description

Type
Data
Inputs
Version
Reference
1.7

Output. Appendix 2.
Security
User profile for:

Finance_Cpo
1.0

Output
Rule
Setup_Derivation_rules
1.0

Output

Type
Outputs
Version
Reference
Report
Estimates_UC_Reconciliation_report
1.0
Appendix 3
Report
Estimates_FB_Reconciliation_report
1.0
Appendix 3
144
Activity 9.5 Finance Loads Year-End Estimates and YTD Actuals into Profile
(process 2.2.1.2 Functional Requirement Map 2.2.1)
2.2.1 Finance Loads Year-End and YTD Profile
CBMS
Finance
Finance
Budget
Estimate
2.1
2.2.1.1
Finance loads yearend estimates
Annual
Estimates
Monthly
Profile
Actuals
Actuals
Management
2.2.1.2
Finance updates
profile with YTD
actual results
2.3
2.2.1.3
Finance opens
CBMS for agency
input
2.2.2
Agency submits
profile
After completion of the Mid Year Estimates Update, all General Government Sector
Agencies are required to update their monthly profile to phase their estimates over the
remaining months of the year on a year-to-date (YTD) basis.
As the Mid Year Estimates Update was completed in 2 September, the first two months of
2011-12 financial year are populated with monthly actuals data. Agencies are then required
to phase each remaining month of the financial year except for June, which is locked within
CBMS to equal the Budget Estimate entered for 2011-12 in the Mid Year Update.
Prior to allowing Agency access to complete the monthly profile, the Finance_Cpo ensures
that the year-end estimates and YTD actual results have been populated.
Requirement
Importance
Description
FR-BM-038
Core
Ability to populate for past months with monthly Actuals when completing
phasings midway through a year.
FR-BM-039
Core
Ability of the CBMS Solution to populate June YTD monthly profile from the
Budget Estimates.
145

Type
Data
Inputs
Version
Reference
1.7

Output. Appendix 2.
Data
July_2011_Monthly_Actuals_data
1.0
Appendix 2
Data
August_2011_Monthly_Actuals_data
1.0
Appendix 2
Rule
1.0

Output
Security
User profile for:

Finance_Cpo
1.0

Output

Type
Outputs
Version
Reference
Data
2011-12_Monthly_Estimates data
1.0
Appendix 2
Report
Monthly_Estimates_report
1.0
Appendix 3
146
Activity 9.6 Enter Monthly Profile (process 2.2.2.1 2.2.2.2 Functional

2.2.2 Agency Submits Profile

Agency
Agency
CBMS
No
2.2.1
Finance loads
year-end and
YTD profile
2.2.2.1
Agency prepares
and submits monthly
profiles
Pass system
validation?
Yes
2.2.2.2
Agency authorises
profile
2.2.3
Finance QAs
profile
Agency
System validation
report
Unauthorised
Agency
Authorised
Finance
validated
After completion of the Mid Year Estimates Update, all General Government Sector
Agencies are required to update their monthly profile to phase their Budget Estimates over
the remaining months of the year on a year-to-date (YTD) basis.
As the Mid Year Estimates Update was completed in 2 September, the first two months of
2011-12 financial year are populated with monthly actuals data. Agencies are then required
to phase each remaining month of the financial year except for June, which is locked within
CBMS to equal the Budget Estimate entered for 2011-12 in the Mid Year Update.
Each Agency chooses to enter their monthly profile in the same method that they use to
enter their Budget Estimates, so Health use a flatfile upload via a rich GUI, Sports Australia
directly enter via a web browser UI, the Department of Law and Order direct enter via a rich
GUI and the Department of Public Services and the Public Court use a flatfile upload via the
web browser UI.
1. The 2011-12 Monthly Estimate is created and submitted by the Agency_User role.
2. The 2011-12 Monthly Estimate is then agency approved by the Agency_Mgr role.
3. The Finance_Cpo user then approves the 2011-12 Monthly Estimate.
Each Agency has submitted data that has passed all of the validation rules. As a result, it is
approved and sent through to Finance, where it is put through a quality assurance process.
147
Requirement
Importance
Description
FR-BM-040
Core
Ability to capture monthly phasings of nominated annual financial estimate

years.
FR-BM-041
Core
Ability for Agencies to enter monthly phasing multiple times per year, keeping a
record of past phasing as history.
FR-BM-042
Core
Ability to report on the status of phasings entry and approval, showing those
Agencies that have submitted profiles (and the status of the profiles) and those
Agencies that have not.
FR-BM-045
Core
Enforce a multi-step approval (eg. draft, unauthorised and authorised) and

deletion processes for profiles that are consistent with pre-defined business
rules.
FR-BM-047
Core
Ability to view monthly profiles at different approval steps.

Type
Inputs
Version
Reference
Data
2011-12_Monthly_Estimates_data
1.0
Scenario 9, Activity 9.5.

Appendix 2
Template
Monthly_Estimates_data_entry_template
1.0
Appendix 3
Rule
1.1

Output
Security
User profile for:

Health_User
Health_Mgr
DLO _User
DLO _ Mgr
Sports _User
Sports _ Mgr
DPCS _User
DPCS _ Mgr
Court _User
Court _ Mgr
Finance_Cpo
1.0

Output
148

Type
Outputs
Version
Data
2011-12_Monthly_Estimates_data
(completed)
1.1
Report
Monthly_Estimates_report
1.1
Reference
Appendix 2
Appendix 3
Activity 9.7 User-defined reporting (Process 4.2 Functional Requirement

Map 4)
Activity 9.7 User-defined Reporting (Process 4.2 Functional Requirement Map 4)
Finance/Treasury
2.1
Budget
Estimates
2.2
4.2.1
Define reports
4.2.2
Generate report
To be reused?
Yes
4.2.3
Save report definition
Monthly Profile
No
2.3
Actuals
Management
Ad-hoc report
End
User defined reporting refers to the ability of CBMS Solution users to create, maintain and
manage reports that can extract data against all elements of the RDS without the need for
expert technical knowledge. Users include both Finance and other Agency Staff. Users
should be able to request or interrogate up-to-the-minute (real-time) data for reporting.
In this activity, the shortlisted Tenderer will be able to demonstrate their systems reporting
capability, with particular emphasis on the users ability to:
define and generate ad-hoc reports in real-time;
drill-down into and across the RDS;
compare information drawn from different sources (i.e budget estimates, actuals,
cash management);
extract information into various formats and other applications (for example
Microsoft Office Applications) for further analysis;
149
amend report formats in real-time; and
save reports for future reference.
For this activity, the user-defined reports will be run by a Finance Analyst (Finance_Anyt).
Requirement
Importance
Description
FR-RA-027
Core
Provide ability to develop user defined reports and analytics such that users
are able to define the content and presentation style of reports.
FR-RA-028
Core
Support the ability to define and include calculated fields or columns.
FR-RA-029
Core
Ability to report data across functions and from different sources for reporting
and analysis (e.g. Budget and Actual).
FR-RA-030
Core
Provides the ability to customise reports (e.g. add titles, add data caveat
notes, add pictures, change CBMS Solution generated labels, etc).
FR-RA-033
Core
and reports.
FR-RA-034
Core
Provide the ability to interact with user-defined analytics.
FR-RA-035
Core
Support simple and complex searches of the content of a report.
FR-RA-036
Core
Ability for users to apply formatting to individual columns and fields (eg.
applying font selections, rounding and truncation etc).
FR-RA-037
Core
Ability for users to sort by any valid data field including number, text or date
fields and exclude or include data set as per selection criteria.
FR-RA-038
Core
Provide the ability to schedule the execution of multiple queries or reports,

online or in batch mode.
FR-RA-039
Core
Enable the graphical representation of data (Numerical and Text) via charts
and graphs.
FR-RA-040
Core
Ability to view reports prior to printing in WYSIWYG (What You See Is What
You Get).
FR-RA-041
Core
CSV, XML, HTML, JPEG (for images such as charts), Excel and PDF.
FR-RA-043
Core
Provide the capability to save reports generated for reuse via library style
functionality.
150
Requirement
FR-RA-044
Importance
Core
Description
Ability to change user-defined report templates and maintain version control
of templates without the need for program coding changes.

To complete this activity the following inputs will be required
Function
Inputs
Version
Reference
Data
1.7
Data
2010-11_Annual_actuals_data
1.0
Appendix 2
Security
User profile for:

Finance_Anyt
1.0

Output
Appendix 2
Output

This activity will produce the following outputs
Function
Outputs
Data
Various ad-hoc reports at tenderers

discretion
Version
Reference
151
Appendix 1
Non-functional Requirements
152
Non-functional requirements
Subsets of Non-Functional Requirements from the COTS Software RFT that will be examined
in the POC are included in the following table:
Requirement Importance
NFR-AAC-001
Core
COTS Software
CBMS Solution
Provides a single sign-on to CBMS which

Windows AD-based internal authentication
solution.
A single sign-on solution which integrates

with the existing Finance internal
authentication solution is required for
Finance users.
Note that multi factor authentication is not

required for CBMS access from within the
Finance network.
Note that multi factor authentication is not

required within the Finance network.
NFR-AAC-002
Core
Provides identification, authentication and

authorisation for logical access controls
compliant with the ISM (in particular,
sections related to logical access controls).
Identification, authentication and

authorisation for logical access controls are
to comply with the ISM (in particular,
sections related to logical access controls).
NFR-AAC-004
Core
Capable of enforcing the Finance password

policy specified in the Finance Information
Security Policy.
The access control and authentication

solution is to be capable of enforcing the
Finance password policy specified in the
Finance Information Security Policy.
153
NFR-AAC-007
Core
COTS Software
Employs and enforces the following
principles with respect to the
implementation of user roles:
CBMS Solution
The following principles are to be enforced
by the CBMS Solution with respect to the
implementation of user roles:
1.
users are to be uniquely identified within 1. users are to be uniquely identified within
the CBMS Solution;
the CBMS Solution;
2. users will be identified and authenticated 2. users will be identified and authenticated
before access to the CBMS Solution is
before access to the CBMS Solution is
granted:
granted:
a. for users on the Finance LAN, single
a. for users on the Finance LAN, single
factor authentication is required (ie.
environment certified to handle data up
environment certified to handle data up
to and including PROTECTED; single
to and including PROTECTED; single
UserID and password pair); and
c. for users connecting from any other
c. for users connecting from any other
environment that has a classification
environment that has a classification
lower than PROTECTED; multi-factor
lower than PROTECTED; multi-factor
authentication is required (eg. via a
authentication is required (eg. via a
token-based certificate plus a UserID
token-based certificate plus a UserID
and password pair);
and password pair).
3. Users are to be granted the least amount 3. CBMS Solution users are to be granted
of privileges required to undertake their
the least amount of privileges required to
specific duties; and
undertake their specific duties; and
4. Role / Group access is to be sufficiently 4. Role / Group access is to be sufficiently
granular as to enforce need-to-know.
granular as to enforce need-to-know.
Note that for users on the Finance LAN, a
single sign-on solution which integrates with
the existing Finance internal authentication
solution is Highly Desirable (refer NFRAAC-001).
Note that for users on the Finance LAN, a

single sign-on solution which integrates with
the existing Finance internal authentication
solution is Highly Desirable (refer NFRAAC-001).
NFR-AAC-011
Core
Limits users access to the services that

they have been specifically authorised to
use.
Users will only have direct access to the

services that they have been specifically
authorised to use.
NFR-AAC-016
Core

portfolios, Agencies, control types, roles,
and modules.

portfolios, Agencies, control types, roles,
and modules.
154
COTS Software
CBMS Solution
Provides an end-to-end audit trail of

transactions. That is, traceability of a single
transaction through each tier of the CBMS
Solution.
Provides an end-to-end audit trail of

transactions. That is, traceability of a single
transaction through each tier of the CBMS
Solution.
NFR-AAUD002
Core
NFR-AAUD003
Highly
Desirable
Ad-hoc reports against application audit

data using standard database query tools.
Will have the ability to run ad-hoc reports

against application audit data using
standard database query tools.
NFR-ARCH002
Core
To use Finance's Infrastructure standard

products and services.
To use Finance's Infrastructure standard

products and services.
NFR-ARCH004
Core
Provides the ability to make changes to the

RDS and business rules without requiring a
change to the source code.
Allows changes to the RDS and business

rules without requiring a change to the
source code.
NFR-ARCH005
Core
The standard architecture offers the ability

to change CBMS Solution functionality and
data structures in an efficient and effective
way without compromising the CBMS
Solution architecture and whilst maintaining
data integrity.
The ability to change functionality and data

structures in an efficient and effective way
without compromising the CBMS Solution
architecture and whilst maintaining data
integrity.
NFR-ARCH007
Core
The architecture does not employ

proprietary technologies.
The Tenderer is to identify where

proprietary technologies are proposed, and
to provide evidence of the cost, benefits
and risk to Finance of the proposed
proprietary technologies.
NFR-ARCH009
Core
No customisation of the product necessary

to achieve the functional and non-functional
requirements.
Where customisation of COTS Software is

proposed, the Tenderer is to prove that the
risk and cost of product Upgrades can be
minimised. Identify Upgrade paths, and
certify compatibility between COTS
Software elements. Details of scope, and
the likely costs of all customisations are to
be specified and product support life cycles
are to be identified.
155
NFR-ARCH010
Core
NFR-AS-001
COTS Software
CBMS Solution
Use technologies, products, and software

languages that conform to Finance
standards.
For solutions owned, hosted, operated and

managed by Finance Personnel in Finance
premises, the CBMS Solution is to be
implemented using technologies, products,
and software languages that can be
maintained by Finance staff. Finance staff
will be able to readily acquire the skills
necessary to maintain the CBMS Solution.
High
Desirable
Application and web server COTS Software

that are proposed are supportable on the
Finance Infrastructure standard products
and services.
Owned, hosted, operated and managed by

Finance personnel in Finance premises,
application and web server products are to
be supportable on the Finance
Infrastructure standard products and
services.
NFR-AS-008
Highly
Desirable
The web and application server software

optimises stability and performance, and
provides high availability (e.g. through the
use of clustered servers).
The web and application server software is

to optimise stability and performance. If not
cluster aware then the Tenderer will identify
how the CBMS Solution will provide similar
or equivalent functionality.
NFR-AS-011
Highly
Desirable

to be capable of failing over to another
server in case of failure with minimal
disruption to users.

to be capable of failing over to another
server in case of failure with minimal
disruption to users.
NFR-AVAIL004
Core
The combined application and

Infrastructure architecture and configuration
allows the CBMS Solution to exhibit no
single point of failure.
Has no single point of failure.
Individual component level protection is not

necessarily required CBMS functional
service and services continuity is the aim.
NFR-AVAIL007
Core
Provides logging, and facilitates user

generated and automated reports on actual
CBMS Solution availability at defined
periods (daily, weekly, monthly).
Individual component level protection is not

necessarily required CBMS Solution
functional service and services continuity is
the aim.
The ability to provide reports on actual

availability at defined periods (daily, weekly,
monthly) is required.
156
COTS Software
CBMS Solution
NFR-DC-001
Core
Subject to necessary Infrastructure, is

suitable and effective for processing and
storing data up to and including
PROTECTED classification, in accordance
with the ISM.
Is capable of processing and storing data

up to and including PROTECTED
classification, in accordance with the ISM.
NFR-DS-001
Core
No constraints on the capability of storing

the volume of data generated and
accommodate anticipated growth rates.
Capable of storing the volume of data

generated and accommodate anticipated
growth rates.
NFR-DS-003
Core
Subject to necessary Infrastructure, allows

the CBMS Solution to accommodate
storage capacity required to undertake
backups and restoration of data maintained
by the new CBMS Solution, over and above
the data storage requirements to service
production operations.
Has the storage capacity required to

undertake backups and restoration of data
maintained by the new CBMS Solution.
NFR-DS-008
Core
The database management system

employed is query-able using industry
standard languages such as Structured
Query Language (SQL) and Extensible
Markup Language for Analysis (XMLA).
The database management system

proposed as part of the CBMS Solution is to
be query-able using industry standard
languages such as Structured Query
Language (SQL) and Extensible Markup
Language for Analysis (XMLA).
NFR-EXINT001
Highly
Desirable
Include a standards-based external

systems interface that supports plug-in to
commercially available products.
Include a standards-based external

systems interface that supports plug-in to
commercially available products.
NFR-EXINT004
Core
Provides a programmatic interface for

exchanging information.
Include a programmatic interface with the

Reserve Bank of Australia for exchanging
information on draw-downs and receipts.
NFR-GDM-003
Core
Will maintain the integrity of the data

irrespective of any changes to CBMS
Solution functionality or data structures.
Will maintain the integrity of the data

irrespective of any changes to functionality
or data structures.
NFR-GINT005
Core
The interface accommodates changes to

the RDS and CoA to be applied without
requiring interface modification or recoding.
The interface accommodates changes to

the RDS and CoA to be applied without
requiring interface modification or recoding.
157
COTS Software
CBMS Solution
NFR-INT-001
Core
Capable of integrating custom software and

off-the-shelf software components using
non-proprietary protocols such as web
services.
Capable of integrating custom software and

off-the-shelf software components using
non-proprietary protocols such as web
services.
NFR-INT-002
Highly
Desirable
Employs non-proprietary middle technology

for inter-process communications.
Use non-proprietary middle technology for

inter-process communications.
NFR-INT-003
Core
Recovers from inter-process message

failures without compromising stability or
user experience.
Will recover from inter-process message

failures without compromising stability or
user experience.
NFR-NET-001
Core
Compatible with appropriately secured

network communications required to
support user interaction with the CBMS
Solution, from:
The Infrastructure is to enable authorised

users to securely connect via any of the
following networks:
1.
2.
3.
the Finance network;

Fedlink; and
public infrastructure (The Internet).
1.
2.
3.
the Finance network;

Fedlink; and
public infrastructure (The Internet).
NFR-NET-004
Core
Application level protocols work over

TCP/IP.
Application level protocols are to work over

TCP/IP.
NFR-NET-006
Core
Compatible with redundant equipment /

multimode processing to allow for high
availability.
LAN / WAN Infrastructure within the scope

of the CBMS Solution is free of functional
single points of failure (ie. individual
component level redundancy is not
necessarily required; the intention is to
ensure the CBMS Solution has an
uninterrupted ability to provide services,
irrespective of the nature of the failure).
NFR-PERF005
Core
The architecture demonstrates features that

allow it to accommodate the processing of
simple predefined reports to be completed
within three (3) seconds, measured from
the edge server in the presentation layer,
through any application, transaction or
databases servers and back to the edge
server.
Processing of simple predefined reports is

to be completed within three (3) seconds,
measured from the edge server in the
presentation layer, through any application,
transaction or databases servers and back
to the edge server.
158
COTS Software
CBMS Solution
NFR-REP-012
Core
Access controls to reports is to be based on

the same security access model
implemented for the transactional data.
Access controls to reports is to be based on

the same security access model
implemented for the transactional data.
NFR-SDM-001
Core
The database management system is to be

capable of supporting conceptual and
logical data models.
The database management system is to be

capable of supporting conceptual and
logical data models.
NFR-SDM-002
Core
Provides for a customisable data dictionary

that defines the names and definitions of
business data elements in the data model;
using the entities and definitions defined in
clause 11 (RDS), as a starting point.
A data dictionary is to be developed and

maintained that defines the names and
definitions of business data elements in the
data model; using the entities and
definitions defined in clause 11 (RDS) as a
starting point.
NFR-SDM-003
Core
The ability to create and maintain a DTD

that is consistent with arbitrary elements of
the business data model.
The ability to create and maintain a DTD

that is consistent with arbitrary elements of
the business data model.
NFR-SDM-006
Core
Will maintain the integrity of data regardless

of the number of users concurrently
updating the database.
Will to maintain the integrity of data

regardless of the number of users
concurrently updating the database.
NFR-SDM-007
Core
Subject to necessary Infrastructure, is to be

able to recover from transaction failures
with the data remaining in a consistent state
and no loss of committed data.
Table to recover from transaction failures

with the data remaining in a consistent state
and no loss of committed data.
NFR-SDM-008
Core
The ability to prevent update or deletion of

certain records based on business rules or
status flags.
The ability to prevent update or deletion of

certain records based on business rules or
status flags.
NFR-SDM-009
Highly
Desirable
The COTS Software allows entry and

preservation of text with rich formatting (e.g.
bold, italics, dot points).
The ability to enter and preserve text with

rich formatting (e.g. bold, italics, dot points).
NFR-UDM-001
Desirable
The ability to store unstructured data (e.g.

MS Office and PDF documents) and link
them to an instance of a process.
The ability to store unstructured data (e.g.

MS Office and PDF documents) and link
them to an instance of a process.
NFR-UDM-003
Desirable
The ability to index unstructured text.
The ability to index unstructured text.
159
COTS Software
CBMS Solution
NFR-UI-002
Core
A file export/upload capability that can be

accessed via both of the users interfaces
identified in NFR-UI-001 is required.
A file export/upload capability that can be

accessed via both of the users interfaces
identified in NFR-UI-001 is required.
NFR-UI-011
Core
All error messages generated by the CBMS

Solution and presented to an end-user will
be meaningful, actionable and in "plain
English."
All error messages generated and

presented to an end-user will be
meaningful, actionable and in "plain
English."
NFR-USE-001
Core
Exhibits the flexibility to allow

documentation and adherence to a UI style
guide, compliant with relevant sections of
the Government guidelines for usability,
and w3.org accessibility recommendations.
A UI style guide is to be developed that

addresses the requirements specified in
this section and is informed by the
Government guidelines for:
Style guide content will be agreed and

approved by Finance.
For each of the guidelines and
recommendations from the four cited
reference sources, indicate how the UI
conforms, or otherwise, and provide
rationale for the decision:
Usability
http://www.finance.gov.au/publications/u
ser-profiling-and-testing-toolkit/usabilitychecklist.html
Usability
http://www.finance.gov.au/publications/u
ser-profiling-and-testing-toolkit/usabilitychecklist.html
Accessibility
http://www.w3.org/TR/WAIWEBCONTENT/#def-checkpoint and
http://www.w3.org/TR/WCAG20/
Web Publishing
http://webpublishing.agimo.gov.au/
Accessibility http://www.w3.org/TR/WAIWEBCONTENT/#def-checkpoint and

http://www.w3.org/TR/WCAG20/
Web Publishing
http://webpublishing.agimo.gov.au/
NFR-USE-002
Core
Conformance to the four cited reference

sources in NFR-USE-001.
All UIs are to conform to the style guide

developed to meet requirement NFR-USE001.
NFR-USE-003
Core
Provides intuitive UIs, that are easy to use,

and responsive.
The UIs are to be intuitive, easy to use, and

responsive.
160
COTS Software
CBMS Solution
NFR-USE-004
Highly
Desirable
Exhibits the controls to ensure all UIs have

a consistent look and feel, menu layout,
functional behaviour and navigation styles,
whilst flexible to conform to the agreed style
guide.
All UIs are to have a consistent look and

feel, menu layout, functional behaviour and
navigation styles.
NFR-USE-005
Core
The UI is flexible to facilitate display,

navigation and update of very large grid like
data sets, including the ability to freeze
panes so that headings and data groupings
remain visible when moving around the
screen.
UIs are to facilitate display, navigation and

update of very large grid like data sets,
including the ability to freeze panes so that
headings and data groupings remain visible
when moving around the screen.
NFR-USE-006
Core
The UI is flexible to all fields on input

screens including user enabled context
sensitive help to display the definition of the
field in accordance with the data dictionary
developed as per requirement NFR-SDM002.
All fields on input screens are to include

context sensitive help that can be enabled
by the user to display the definition of the
field in accordance with the data dictionary
developed as per requirement NFR-SDM002.
NFR-USE-007
Core
Tools for Finance staff to develop on-line

end-user documentation.
The Tenderer is to provide tools for Finance

staff to develop on-line end-user
documentation.
NFR-USE-008
Core
End-user documentation available on-line

using a common UI.
End-user documentation is to be available

on-line using a common UI.
NFR-USE-009
Core
The ability to print end-user documentation

from the same UI as the CBMS Solution.
The ability to print end-user documentation

from the same UI as the CBMS Solution.
NFR-USE-010
Core
The ability to limit access to user

documentation to the level matching a
user's access to CBMS Solution modules
and functionality.
The ability to restrict access to certain

components of the user documentation. Eg.
users should not be able to access
documentation related to application
functionality or modules to which they do
not have access.
161
NFR-USE-011
Core
COTS Software
Menu-based on-line end-user
documentation.
Exhibits controls to ensure displayed
documentation content always reflects the
current CBMS Solution design and
processes.
CBMS Solution
On-line end-user documentation will be
menu based. The documentation will
always reflect the current CBMS Solution
design and processes.
NFR-USE-013
Core
The UI exhibits common Windows

behaviour as defined in IEEE1295
specifications.
The UI is to exhibit common Windows

behaviour as defined in the IEEE1295
industry standard graphical UI specification.
Eg. cut and paste, drag and drop and
concurrent display of multiple windows.
NFR-USE-014
Core
The UI has the ability to provide an easy

and user friendly mechanism for finding and
selecting values in large look-up lists and
RDSs.
The UI is to provide an easy and user

friendly mechanism for finding and selecting
values in large look-up lists and RDSs.
NFR-USE-016
Core
Has the ability to progressively save data in

a temporary location within the central
storage, up until the data set is committed.
Has the ability to progressively save data in

a temporary location within the central
storage, up until the data set is committed.
This feature is to run in the background and
be transparent to the user. The aim is to
avoid the situation where a user has to rekey large amounts of data after an
unexpected client error, network error or
system outage. No unencrypted information
is to be stored on the client systems, or
retained within client caches.
This feature runs in the background and is

transparent to the user.
The aim is to avoid the situation where a
user has to re-key large amounts of data
after an unexpected client error, network
error or system outage.
No unencrypted information is to be stored
on the client, or retained within client
caches.
NFR-PERF003
Core

allow it to accommodate 90% of user
inquiry and update Transactions being
completed within one (1) second; measured
from the edge server in the presentation
layer, through any application, Transaction
or databases servers and back to the edge
server.
90% of user inquiry and update

Transactions are to be completed within
one (1) second; measured from the edge
server in the presentation layer, through
any application, Transaction or databases
servers and back to the edge server.
162
COTS Software
CBMS Solution
NFR-PERF005
Core

allow it to accommodate the processing of
simple predefined reports to be completed
within three (3) seconds, measured from
the edge server in the presentation layer,
through any application, transaction or
databases servers and back to the edge
server.
Processing of simple predefined reports is

to be completed within three (3) seconds,
measured from the edge server in the
presentation layer, through any application,
transaction or databases servers and back
to the edge server.
NFR-PERF012
Core
Will provide a performance reporting

mechanism that addresses agreed key
parameters including, but not limited to online monitoring, display of real-time
performance and key thresholds, and
automated exception reporting and fault
logging.
Will provide a performance reporting

mechanism that addresses agreed key
parameters including, but not limited to online monitoring, display of real-time
performance and key thresholds, and
automated exception reporting and fault
logging.
163
Appendix 2
Data
164
Contents
1
Introduction .................................................................................................................... 166
Assumptions................................................................................................................... 166
Data Overview ............................................................................................................... 166
Data Sets ........................................................................................................................ 166
165
Introduction
The purpose of this Appendix is to provide shortlisted Tenderers an understanding of the
data that is supplied as part of the POC. The data provided for the POC will form part of the
solution that will be provided to the Central Budget Management System (CBMS)
Evaluation Team for testing.
The following information outlined in this Appendix is in relation to:
a data overview explaining the data types;
a guide to data definitions and data files;
explanations of Set-up, Base, scenario and attachments data used in the POC
Assumptions
The data overview described in this section represents a subset of the data that is similar to
what is currently used in Finances business however it is fictional for POC purposes.
The data overview is a logical example of how the data files provided are related. The
relationships between the set-up data files are not intended to represent a real agency
relationship diagram and therefore should not be relied upon in this way.
Data Overview
There are three main types of data represented in the POC data files. These are Set-up
data, Base data and Scenario data.
Set-up data represents data to be used in the configuration or setting up of the system.
This includes data that represents the RDS elements, business rules and user details.
Base data represents the historical transaction data that is to be pre-loaded into the
proof-of concept solution.
Scenario data represents the transactional data that supports the scenarios for the
proof-of concept, including changes driven by the scenarios. The data incorporates
financial and non-financial data. This data provides the shortlisted Tenderers with a step by
step view of how data is intended to move through the different stages of each scenario.
Data Sets
Data set names represent all the different data sets that are to be used in the CBMS POC
system. Data sets are made up mainly of textual and non-textual data.
Data files
Data sets are set-up and stored in Excel files called data files. Each data file provides the
shortlisted Tenderer with a logically organised format in a header at the top of each file
representing the columns of data (or fields). These column headers are colour-coded to
represent the data group that the data file mainly represents (see data set relationships
diagram in previous section).
Structure of data files
The data files contain either one or many worksheets dependent on whether the data is
Set-up Base or Scenario data. Attachments do not have certain file structure.
166
Set-up and Base data - files only contain one worksheet. The worksheet name is named
as Set-up or Base.
Scenario data consist of a number of worksheets showing the data in its various states.
An example of this is shown as follows:
Version 1.0 The version as first used in the system, ready to be updated according to the
relevant steps of the Scenario.
Version 1.1,1.2,1.3 etc. Updated versions, reflecting incremental changes to the underlying
information. Incremental changes to the data are highlighted in yellow.
Attachments a file structure does not apply for attachments. Attachments are supporting
information to the scenario data and as stored as a Word, Excel or PDF file.
Data Files
Excel files containing the data for the POC Scenarios is in the attached folder Data files
167
Appendix 3
Templates
168
Contents
1
Introduction .................................................................................................................... 170
Templates and Data........................................................................................................ 170
Templates used in the POC ............................................................................................ 170
169
Introduction
To ensure the collection of accurate and complete data sets, standard templates are used
for the collection of all data entering the system. Templates may include a combination of
optional and mandatory fields.
This Appendix describes the templates required for the POC in detail, providing shortlisted
tenderers with the information necessary to build the templates required to support the
identified scenarios.
Templates and Data

Each template consists of a number of fields that allow a user to enter data into the system
in the desired format and in line with the data model outlined in Appendix 2.
The relationship between templates and data is pictorially represented in the example
below:
Templates used in the POC

There are multiple templates that support the scenarios within the POC, with each differing
in its composition both in terms of fields and the number of statuses applicable. It should be
noted that statuses are sequential in nature, such that all templates must begin at Draft
status before moving to the next status.
170
As part of their POC solution shortlisted Tenderers are expected to provide a simple and
intuitive interface to support the system administration scenarios outlined in the main
document. How this is provided is at the shortlisted Tenderers discretion.
Template Files
An excel file containing the data entry templates for the POC Scenarios is in the attached
folder Templates.
171
Appendix 4
Reports
172
Contents
1
Introduction .................................................................................................................... 174
Guide to Reports ............................................................................................................ 174
173
Introduction
Shortlisted Tenderers should note that there are a number of reports that require
development for the POC. Some of the reports will be considered standard reports
requiring little or no configuration, while others will require development.
This Appendix seeks to provide shortlisted Tenderers with the information necessary to
develop the reports identified in the scenarios contained in the main document.
Guide to Reports
To assist shortlisted Tenderers in understanding individual reports, example reports have
been included as attachments to this document.
The following list provides an overview of the information contained in each report
File Name: Name of Excel spreadsheet containing the report. These names correlate back
to the report name as referenced throughout this POC document.
Version: Contained in the worksheet tab within each file. Version 1.0 refers to the first time
the report is run in the POC. Version 1.1, 1.2, etc comprises updated versions of the report
reflecting the incremental impact of changes made to the data in previous scenarios or
activities.
(NB: The consolidated balance sheet (Report_Estimates_Consolidated_Balance_Sheet)
and income statement (Report_Estimates_Consolidated_Income_Statement) also include
opening balance versions. These are intended to assist tenderers in reviewing expected
outputs after the loading of the base estimate data (Base_budget_estimates_data).
Report Title: The title as displayed on the final published report.
Content: The content contained in each report is relevant to each Scenario Activity. To
assist in understanding, linkages to the underlying data tables have been maintained in the
example reports. The example reports also show the expected output from the POC
activities.
Report Files
Excel files containing the expected reports for the POC Scenarios is in the attached folder
Report Files
Report formats not prescribed

Several reports listed through the POC do not have required formats and will vary in
appearance depending on the solution used. As a result, these reports have not been
included in the Report Files, however a report that provides the information required as per
the relevant activity should be produced. A list of such reports is below.
Report
Version
Scenario Reference
Admin_COA_Report
v1.0
v1.1
v1.0
v1.0
v1.0
v1.0
v1.1
v1.0
v1.0

Admin_Program_hierarchy_report
Admin_user_access_report
174
Report
Budget_Estimates_adjustments_report
Monthly_Budget_variance_report
(This report design has not been prescribed
as Tenderers solutions may have predefined reports. For guidance, it would be
expected that this report would show the
actual monthly amount, relevant monthly
profile amount, difference between the two
and textual explanation for all accounts that
exceed the threshold amount detailed in the
relevant POC Scenario)
Actuals_journal_trail
(This report is not prescribed for any
particular scenario but should provide a trail
for journal adjustments (e.g consolidation
adjustments) made in all relevant activities)
Version
Scenario Reference
v1.1
v1.0
v1.1
v1.2
v1.0

v1.0
175

COTS CBMS POC

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

COTS CBMS POC

Загружено:

Авторское право:

Доступные форматы

Proof of Concept

For the provision of

Commercial-Off-The-Shelf (COTS) Software

Central Budget Management System

Reference Data Set (RDS)........................................................................................... 8

Proof of Concept ................................................................................................................ 9

Approach to Proof of Concept .................................................................................... 9

System Rules to be applied in the Proof of Concept ....................................................... 10

Technical environment / hardware................................................................................... 11

Key POC design aspects and Finance technical expectations................................... 12

Approach to evaluating non-functional requirements in the POC ............................ 14

Section B - Introduction ................................................................................................... 17

Expected Outcome of POC .............................................................................................. 17

Data and Expected Outputs ....................................................................................... 17

Responsibilities / Expectations of Shortlisted Tenderers................................................. 20

Communications via email ........................................................................................ 20

Installation, de-install, provide technical support ..................................................... 21

Notification of Changes/Variations ........................................................................... 21

Funding for the POC ................................................................................................. 21

Guide to Scenarios ........................................................................................................... 23

Outline/Structure of Scenarios .................................................................................. 23

Summary Table ......................................................................................................... 25

Scenario 1 Set up .......................................................................................................... 30

Scenario 2: Decision Making and Budget Estimates Data Entry .................................... 52

Scenario 3: Financial Consolidation & Reporting of Budget Estimates.......................... 66

Scenario 4: Appropriation Management .......................................................................... 79

Scenario 5: Cash Management......................................................................................... 82

Scenario 6: Annual Actuals ........................................................................................... 106

Scenario 7: Monthly Reporting...................................................................................... 115

Scenario 8: Application Administration ........................................................................ 123

Scenario 9: Mid Year Update and Monthly Profile ....................................................... 136

Non-functional requirements ......................................................................................... 153

Introduction .................................................................................................................... 166

Data Overview ............................................................................................................... 166

Data Sets ........................................................................................................................ 166

Data Files ....................................................................................................................... 167

Introduction .................................................................................................................... 170

Templates and Data........................................................................................................ 170

Templates used in the POC ............................................................................................ 170

Template Files................................................................................................................ 171

Introduction .................................................................................................................... 174

Guide to Report Definitions ........................................................................................... 174

Report Files .................................................................................................................... 174

Section A - Business Overview provides a general overview of the business environment

Section B - Information for shortlisted Tenderers guides shortlisted Tenderers on what

Section A: Business Overview

Functional & Non-Functional Requirements Model

Figure 1 Australian Government Budget and Financial Management Requirements

Reference Data Set (RDS)

Minimum Data Set

Reference Data Set

Figure 2 Reference Data Set including Minimum Data Set

Approach to Proof of Concept

System Rules to be applied in the Proof of Concept

Budget Management to Cash Management;

Cash Management to Actuals Reporting; and

Actuals Reporting to Budget Management.

Technical environment / hardware

Prevention of unauthorised access or tampering:

Figure 3 POC Environment - Logical View of the Technical Configuration Required

Key POC design aspects and Finance technical expectations

Separation of CBMS Network, Finance Network, and Agency Networks