SAP Public Budget Formulation PDF Free Download

Sizing Guide Document Version: 1.0 2013-09-30 CUSTOMER

Typographic Conventions Type Style Example Example EXAMPLE Example Example <Example> EXAMPLE Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Textual cross-references to other documents. Emphasized words or expressions. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER. 2 2013 SAP AG. All rights reserved. Typographic Conventions

Table of Contents 1 Introduction... 7 1.1 Functions of SAP Public Budget Formulation... 7 1.1.1 Budget Forms... 7 1.1.2 Budget Forms Re-Allocations... 8 1.1.3 Personnel Expenditure Planning... 8 1.1.4 What-If Projection... 8 1.1.5 Pay Period Personnel expenditure Planning... 9 1.1.6 Attrition and Backfill Projection... 9 1.1.7 Ranking... 9 1.2 Architecture of SAP Public Budget Formulation... 10 1.3 Factors that Influence Performance... 10 2 Sizing Fundamentals and Terminology... 11 3 Initial Sizing for Public Budget Formulation... 13 3.1 Sizing the Budget Forms Scenario... 14 3.1.1 CPU Sizing... 14 3.1.2 Memory Sizing... 15 3.1.3 Disk Space Sizing... 16 3.1.4 Network Sizing... 17 3.2 Sizing the Budget Forms - Reallocations Scenario... 17 3.2.1 CPU Sizing... 17 3.2.2 Memory Sizing... 18 3.2.3 Disk Space Sizing... 19 3.2.4 Network Sizing... 19 3.3 Sizing Personnel expenditure Planning scenario... 19 3.3.1 CPU Sizing... 19 3.3.2 Memory Sizing...20 3.3.3 Disk Space Sizing...20 3.3.4 Network Sizing... 21 3.4 Sizing the What-If Scenario... 21 3.4.1 CPU Sizing... 21 3.4.2 Memory Sizing... 22 3.4.3 Disk Space Sizing... 22 3.4.4 Network Sizing... 22 3.5 Sizing Pay Period Personnel Expenditure Planning Scenario... 22 3.5.1 CPU and Memory Sizing... 23 3.5.2 Disk Space Sizing... 23 3.5.3 Network sizing... 23 3.6 Sizing the Attrition and Backfill Scenario... 23 3.6.1 CPU and Memory Sizing... 24 3.6.2 Disk Space Sizing... 24 3.6.3 Network Sizing... 24 3.7 Sizing the Ranking Forms Scenario... 24 4 2013 SAP AG. All rights reserved. Table of Contents

3.7.1 CPU Sizing... 25 3.7.2 Memory Sizing... 25 3.7.3 Disk Space Sizing... 26 3.7.4 Network Sizing... 26 4 Miscellaneous... 28 5 Comments and Feedback...29 6 Appendix... 30 6.1 Technical Details... 30 6.1.1 Budget Forms... 30 6.1.2 Budget Forms Re-Allocations... 31 6.1.3 Personnel Expenditure Planning... 32 6.1.4 What-If Projections... 33 6.1.5 Ranking... 35 6.1.6 Pay Period Projection... 35 6.1.7 Attrition and Backfill Projection...37 Table of Contents 2013 SAP AG. All rights reserved. 5

1 Introduction SAP Public Budget Formulation (SAP PBF) supports the Public Sector budgeting process and the associated reporting requirements. The application uses SAP NetWeaver Business Warehouse as the backend and Visual Composer as the frontend. The application consists of a list of BW objects, RFC-enabled function modules, BW-IP queries and planning functions, and Java-based text handling black boxes that are seamlessly integrated to a visual composer model to address business process. 1.1 Functions of SAP Public Budget Formulation The application has four modules Budget Formulation, Ranking, Personnel expenditure Planning, and Budget Form Re-allocations. 1.1.1 Budget Forms The Budget Form uses the BW-Integrated Planning Framework and comprises of three queries. The Form Layout contains two main sections: the header section and the line-item section. The input values in the header are used as a filter for the BW queries. First, the user creates a Form Instance ID. The technical behavior of a Form instance ID can be equated to a variant creation process in standard SAP applications. After successful completion of the Form Instance creation process, the user moves to the line-item section that displays the query result or an empty template for the user to enter values. The standard Budget Forms contain seven filters in the header, including one for currency selection, and at least two other selections in the line-item level. Each of these selections would include two browser navigations. In the case of the Budget Form position tab, the number of manually maintained values is significantly higher than the expense and the revenue tabs. The number of browser navigations in this case would be as high as 29. On Save, the PBF currency conversion planning function is executed, which translates the form currency amounts (selected on the header) into the FM area currency. The characteristic selections in the header and line-item sections are checked for authorizations and are filtered by the PBF combo-edit functionality. The PBF combo edit functionality uses SAP BW analysis authorizations and is checked at the time of filter selections. With PBF 8.1, Budget Forms is extended with new features to export, download, copy, and upload data. Please refer section 6.1 for technical details. Introduction 2013 SAP AG. All rights reserved. 7

1.1.2 Budget Forms Re-Allocations This is a new functionality added as part of PBF 8.0. The functionality allows users to allocate expenses, revenues, or position costs from one form instance to one or many receivers. The allocation can be based on absolute value or percentages. The functionality is based on BW-Integrated planning framework and comprises of two queries and two planning functions. The UI offers a wizard-based screen with three steps: Select Sender Form ID, Select Receiver Form IDs, and Enter Receiver Form details. Please refer section 6.1 for technical details 1.1.3 Personnel Expenditure Planning The projections scenario describes the functionality required to project the cost for a given set of personnel master data (employees, positions) for a predefined period. Upon entering the parameters (projection period, projected increases of various benefits/salaries), the system calculates the cost for the included personnel and stores the cost under the projection ID in the projection cube. Every projection ID describes a what-if scenario. Please refer section 6.1 for details 1.1.4 What-If Projection Functional Overview The what-if projection is an enhancement to the PEP Framework to provide What-if PEP result analysis. What-If scenario is used to create a new projection based on a reference projection. The dimension parameters used in the reference projection are defaulted and can be changed to reflect a smaller selection or subset of the values inherited from referenced projection ID. This allows the users to restrict what-if results by FM dimensions, employee group/subgroups, personnel area/subarea, job, pay scale group, etc. It also provides supplementary salary and benefits rate/amount to increment or decrease the computed amounts. Users can add/change Pay scale parameters like step months and next pay scale level information and enter any additional benefits. Users can also add cost allocations to cause results to be allocated differently than the reference projection. A variety of options are available to allow the changes to affect all employees and positions or limited to specific employees or positions. It uses the position and employee data of reference projection ID and not the master data. Projections are executed and analyzed as per need, and saved in the PBF database There is no limit on the number of what-if projections that can be generated on a reference projection. The what-if projection is a two-step process. The first step is to create a reference projection. A reference projection is a PEP projection scenario executed with the Save Master Data option selected. The second step is to create the what-if projection using the master data from the referenced projection completed in first step. The what-if projection allows users to further filter the FM dimensions, date ranges and other selection parameters as 8 2013 SAP AG. All rights reserved. Introduction

well as change Next Pay Scale levels, add benefits and add or change allocations to employees and positions thus allowing What-if analysis without affecting master data or other projections. Please refer section 6.1 for more details 1.1.5 Pay Period Personnel expenditure Planning The functionality provides greater flexibility in calculating projection results. The functionality allows users to set up calendar which is flexible enough to support different pay type like weekly, by-weekly, semi-monthly, monthly, quarterly etc. PEP calculation engine will support any type of Pay Period that is configured. The PEP Results will be posted in Pay Periods and FISCAL Periods. A new framework is implemented to support high volume data more effectively. The functionality also allows users to select master data sources. Example: If the user has two versions of master data, say from ECC and a locally modified version in BW, during the execution of projection, the user would now be able to select the master data source. Please refer section 6.1 for more details 1.1.6 Attrition and Backfill Projection A framework supports the attrition and backfill scenario, very similar to what was built to support what-if projections in PBF 8.0. The attrition and backfill scenarios will require a pay-period-based reference projection, just as what-if scenarios require a PEP reference projection. Attrition would reduce the costs and backfill would increase costs. Please refer section 6.1 for more details 1.1.7 Ranking Functional Overview The Ranking template is a Visual Composer (VC) model that allows users of Public Budget Formulation (PBF) to prioritize budget requests by assigning ranking values. Ranking is available for all requests within a form definition. Ranking is used to assign priority ranks to budget requests, compare request amounts by FM dimension combination and then determine which requests could be funded by defining funding levels. Budget requests can be ranked and re-ranked as many times as needed. The screen will display the previous and current rank for each budget request as the request progresses up the selected dimensional hierarchy. The ranking form will re-sequence the budget requests based on the assigned rank. Please refer section 6.1 for technical details. Introduction 2013 SAP AG. All rights reserved. 9

1.2 Architecture of SAP Public Budget Formulation Figure 1 - Architecture of SAP Public Budget Formulation There are three main connections between the CE system and the BW system. All queries and planning functions use the JCo connections PBF_BI and PBF_R3. An additional two connection types are used: WebDynpro logical connection for WebDynpro screens and a Web Service connection hosted in BW JAVA and called by the CE system Sizing of the NWDI system is provided in OSS Note 737368. 1.3 Factors that Influence Performance Resource consumption strongly depends on the user activity profile and the number of unique master data combinations that are used in the forms. For personnel expenditure planning, the amount of master data such as employees, position, associated benefits, projection duration, and benefit rules configuration is loaded or saved to the system. For the same amount of master data, the resource requirements with multiple concurrent users is linear to the amount of concurrent users. The user activity profile takes into consideration the pauses between the different interactions of the user with the system. Users who navigate more intensively with the user interface of the PBF application are more productive in terms of number of executed scenarios per time interval. If the concurrent users are more productive, the resource requirements are higher. 10 2013 SAP AG. All rights reserved. Introduction

2 Sizing Fundamentals and Terminology SAP provides general sizing information on the SAP Service Marketplace. For the purpose of this guide, we assume that you are familiar with sizing fundamentals. You can find more information at http://service.sap.com/sizing Sizing Guidelines General Sizing Procedures. This section explains the most important sizing terms, as these terms are used extensively in this document. Sizing Sizing means determining the hardware requirements of an SAP application, such as the network bandwidth, physical memory, CPU processing power, and I/O capacity. The size of the hardware and database is influenced by both business aspects and technological aspects. This means that the number of users using the various application components and the data load they put on the server must be taken into account. Benchmarking Sizing information can be determined using SAP Standard Application Benchmarks and scalability tests (www.sap.com/benchmark). Released for technology partners, benchmarks provide basic sizing recommendations to customers by placing a substantial load upon a system during the testing of new hardware, system software components, and relational database management systems (RDBMS). All performance data relevant to the system, user, and business applications are monitored during a benchmark run and can be used to compare platforms. SAPS The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) Benchmark, where 100 SAPS is defined as the computing power to handle 2,000 fully business processed order line items per hour. (For more information about SAPS, see http://www.sap.com/benchmark Measuring in SAPS). Initial Sizing Initial sizing refers to the sizing approach that provides statements about platform-independent requirements of the hardware resources necessary for representative, standard delivery SAP applications. The initial sizing guidelines assume optimal system parameter settings, standard business scenarios, and so on. Sizing Fundamentals and Terminology 2013 SAP AG. All rights reserved. 11

Expert Sizing This term refers to a sizing exercise where customer-specific data is being analyzed and used to put more detail on the sizing result. The main objective is to determine the resource consumption of customized content and applications (not SAP standard delivery) by comprehensive measurements. For more information, see http://service.sap.com/sizing Sizing Guidelines General Sizing Procedures Expert Sizing. Configuration and System Landscaping Hardware resource and optimal system configuration greatly depend on the requirements of the customerspecific project. This includes the implementation of distribution, security, and high availability solutions by different approaches using various third-party tools. In the case of high availability through redundant resources, for example, the final resource requirements must be adjusted accordingly. There are some "best practices" which may be valid for a specific combination of operating system and database. To provide guidance, SAP created the NetWeaver configuration guides (http://service.sap.com/instguides SAP NetWeaver). 12 2013 SAP AG. All rights reserved. Sizing Fundamentals and Terminology

3 Initial Sizing for Public Budget Formulation The hardware requirements are derived from resource consumption measurements in internal SAP systems using an SAP-specific configuration and data set, such as: Ranking Forms Number of Form instances ranked: 30. The user executes Load, Rank, and Fund Forms in each scenario. A query reads the Budget Form Cube and writes data into the Ranking Cube. The Budget Form Cube had 541,000 entries and Ranking Cube had 1100 entries. Data volume in the /PBFBI/BF_CUBE is 541,743 and in the /PBFBI/RANKING Info Cubes is 1100. Personnel Expenditure Planning (PEP) 10000 Employees, 10000 Positions, average number of 9 benefits and 2 years of projection duration are considered for this scenario. Data volume in the /PBFBI/PROJ_1 is 1,300,550 and in the /PBFBI/PROJ_2 is 17,800,221. The user executes Load Projection, Calculate, and Save in each scenario. The following facts and comments are valid with all sizing recommendations: The number of concurrent users can be calculated back from the scenario executions per hour (throughput) by taking into consideration the average response time (in seconds) of the business process steps, the average think time of the users when executing the scenario. Respectively, the throughput can be calculated back from concurrent users. The relation is defined as: 3600 = ( + ) The ABAP server initialization memory for buffers, caches, and so on is not considered - please check the latest recommendations for minimum ABAP server memory, usually above 4 GB. The ABAP Memory [MB] in this sizing guideline is the net memory, required to run the specified amount of concurrent users or parallel processes (in case of background jobs). The memory requirement for SAP Java Composition Environment depends on the throughput. The Java Memory [MB] includes the total requirement for initialization of one or multiple Java server nodes. Requirements below 4 GB can be handled with one java server node in default configuration. With higher throughput might be required either more server nodes or different memory configuration with one server node. The memory requirements of the database are vendor specific. Please, check with database vendor for an appropriate recommendation, which is usually provided on the basis of sharing the SAPS requirement information with the database vendor. Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 13

The CPU requirements are determined by the number of executed business scenarios (throughput) per hour. For similar amount of master data the increase of resources is linear to the increase of the number of concurrent users, and to the increase of throughput. For scenarios which are executed by concurrent users, the SAPS for Java server, ABAP server, and database are calculated with guarantee factor of 65%, which means that there is 35% extra capacity planned to handle peaks and to try to ensure no degradation of response time due to CPU queuing effects. For background jobs, the SAPS are calculated without buffer. 3.1 Sizing the Budget Forms Scenario With Budget Forms scenario the mapping between concurrent users and throughput for the Budget Forms scenario looks like this: Throughput (scenario executions per hour) Average think time [s] Number of concurrent users 1000 5 ~50 1000 10 ~100 1000 30 ~250 A typical user executes the scenario for about six minutes, which would mean average think time about ten seconds and an experienced user executes the scenario for about minutes, which would correspond to about five seconds average think time. 3.1.1 CPU Sizing The CPU requirements are defined for execution of 1000 scenario executions per hour with different number of unique master data values. In brackets are provided additional PBF 8.1 feature SAPS required for processing of a mixture of total 1000 export, download, copy or upload operations per hour, in any combination, for example x1 uploads, x2 copies, x3 downloads, and x4 exports with the specified volume of master data values. To calculate the total required SAPS, calculate the SAPS for the expected usage of PBF 8.0 features and add to it the calculated SAPS for the expected usage of PBF 8.1 features. Unique master data values refer to the number of unique value of the different characteristics like funds center, fund, commitment item, etc. used in the query. Assume the query has four characteristics fund, fund center, commitment item, and funded program. There can be 1000 rows in the query but only 50 unique values are used for the above four characteristic hence the unique master data values in this scenario is 200 (that is, 50 x 4). 14 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

Category Up to unique master data values SAP NetWeaver Composition Environment Java [SAPS] (additional PBF 8.1 feature SAPS) SAP NetWeaver Business Warehouse ABAP [SAPS] (additional PBF 8.1 feature SAPS) DB [SAPS] (additional PBF 8.1 feature SAPS) S 50 450 (300) M 100 500 (550) L 200 550 (650) XL 500 700 (800) More contact SAP or hardware vendor 2650 (900) 3100 (1600) 4000 (2500) 6650 (5000) 800 (600) 900 (1000) 1050 (1500) 1550 (3000) For higher throughput apply ratio, like Java [SAPS] for 5000 scenarios per hour with up to 50 master data values will be 5 * 450 SAPS = 2250 SAPS. If at this same hour 2000 export, upload, copy or download operations has happened, then add 2*300 SAPS = 600 SAPS and get a total result of 2250 SAPS + 600 SAPS = 2850 SAPS. ABAP [SAP] for 5000 scenarios per hour with up to 50 master data values will be 5 * 2650 SAPS = 13250 SAPS. Add 2 * 900 SAPS = 1800 SAPS for the new features and get final result of 13250 SAPS + 1800 SAPS = 15050 SAPS. The calculation for the DB [SAPS] is similar. 3.1.2 Memory Sizing The net memory requirements for SAP NetWeaver BW depend on the number of concurrent user and the size of master data, With the new features export, copy, download and upload the memory requirements per user are increased. In brackets are provided additional PBF 8.1 feature memory values. In contrast to the SAPS, when new PBF 8.1 features are used, only the values in brackets should be considered and not the sum of old functionality and new functionality. Category Up to Unique Master data Values Memory requirement per user [MB] (additional PBF 8.1 features MB) Net ABAP Memory [GB] (additional PBF 8.1 features GB) 50 concurrent users 100 concurrent users 250 concurrent users S 50 24 1.2 2.3 5.9 (40) (1.9) (3.8) (9.5) Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 15

Category Up to Unique Master M 100 26 Memory requirement per user [MB] (60) Net ABAP Memory [GB] (additional PBF 8.1 features GB) 1.3 2.5 (2.9) (5.8) 6.3 (14.5) L 200 28 1.4 2.7 6.8 (80) (3.9) (7.8) (19.5) XL 500 32 1.6 3.1 7.8 (100) (4.9) (9.8) (24.5) More contact SAP or hardware vendor The net memory requirement for SAP Java Composition Environment depends on the number of scenarios per hour and the size of the master data. In brackets is provided the memory requirement when new features are used. For 1000 scenarios per hour the sufficient Java memory is Category Up to Unique Master data Values SAP NetWeaver Composition Environment Java Memory [GB] (additional PBF 8.1 features GB) S 50 0.27 (1.2) M 100 0.28 (1.5) L 200 0.3 (1.8) XL 500 0.38 (2.1) More contact SAP or hardware vendor For higher throughput apply ratio, like Java Memory for 5000 orders per hour with up to 50 received forms will be 5 * 0.27 GB = 1.35 GB and with few features it would be 5 * 1.2 GB = 6 GB 3.1.3 Disk Space Sizing 6 KB will be added to the database disk space per scenario execution. For example, if per year will be executed 1.000.000 scenarios required disk space will be 1.000.000 * 6 KB = 6.000.000 KB = 5.7 GB. 16 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

3.1.4 Network Sizing Network traffic to front-end is on average 17 KB per business step, which is 28*17 KB = 476 KB per scenario. Up to 10.000 scenarios per hour would fit into network capacity 10 Mbit. Up to scenarios per hour Network capacity [Mbit/s] 1000 1 5000 5 10000 10 20000 20 3.2 Sizing the Budget Forms - Reallocations Scenario With Budget Forms Reallocations scenario the mapping between concurrent users with different think times and throughput looks like following: Throughput (scenario executions per hour) Average think time [s] Number of concurrent users 1000 5 ~25 1000 10 ~40 1000 30 ~100 A typical normal user executes the scenario with average think time ~10 seconds and an experienced user with ~ 5 seconds average think time. 3.2.1 CPU Sizing The resource requirements for throughput of 1000 scenarios per hour are as follow Category Up to forms for reallocation s SAP NetWeaver Composition Environment SAP NetWeaver Business Warehouse Java [SAPS] ABAP [SAPS] DB [SAPS] S 10 600 2100 1000 M 25 650 2350 1050 L 50 750 2750 1150 Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 17

Category Up to forms for re- SAP NetWeaver Composition Environment SAP NetWeaver Business Warehouse XL 100 950 3550 1400 More contact SAP or hardware vendor The resource requirements for higher throughput can be calculated applying a linear extrapolation. For example, the Java [SAPS] for 5000 scenarios per hour with 50 reallocation forms will be 5 * 750 = 3750 SAPS. Same calculation is valid for the SAPS on the ABAP and DB. 3.2.2 Memory Sizing The net memory requirements for SAP NetWeaver BW depend on the number of concurrent user and the size of master data, for example Category Up to Forms for Reallocations Memory requirement per user [MB] Net ABAP Memory [GB] 25 concurrent users 40 concurrent users 100 concurrent users S 10 15 0.4 0.6 1.5 M 25 20 0.5 0.8 2.0 L 50 28 0.7 1.1 2.7 XL 100 44 1.1 1.7 4.3 More contact SAP or hardware vendor The net memory requirement for SAP Java Composition Environment depends on the number of scenarios per hour and on the size of master data. For 1000 scenarios per hour the sufficient Java memory is Category Up to Forms for Reallocations SAP NetWeaver Composition Environment Java Memory [GB] S 10 0.4 M 25 0.45 L 50 0.5 XL 100 0.7 More contact SAP or hardware vendor For higher throughput apply ratio, for example with 5000 scenarios per hour and 10 re-allocation forms the Java Memory [MB] will be 5 * 0,4 GB = ~ 2 GB. 18 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

3.2.3 Disk Space Sizing 3.7 KB will be added to the database disk space per scenario execution. For example, if per year will be executed 1.000.000 scenarios required disk space will be 1.000.000 * 3.7 KB = 3.700.000 KB = 3.6 GB 3.2.4 Network Sizing Network traffic to front-end is on average 12 KB per business step. Up to 20.000 scenarios per hour would fit into network capacity 6 Mbit. Up to scenarios per hour Network capacity [Mbit/s] 1000 0.3 5000 1.5 10000 3 20000 6 3.3 Sizing Personnel expenditure Planning scenario The resource consumption of the Personnel expenditure Planning executed as background process depends on the number of employees/position, the average number of associated benefits and allocations, the projection duration in fiscal period and required duration of execution (P). = ( + ) 3.3.1 CPU Sizing The execution time depends on the level of parallelization of the batch job. For example the number of employees can be split into packages of 100 and can be assigned for execution in parallel processes. The execution time (period) would be achieved only if enough parallel processes are configured to allocate fully the amount of calculated SAPS. Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 19

Up to total number of calculated records Period (minutes) SAP NetWeaver Business Warehouse ABAP [SAPS] DB [SAPS] 5.000.000 30 1000 7000 5.000.000 60 500 3500 10.000.000 30 2000 14000 10.000.000 60 1000 7000 To estimate the resource requirements for different data volumes and periods follow the approach to reduce the SAPS by the factor of increase of the time period and to increase the SAPS by the factor of increased data volume for same period. For example: If 10.000.000 calculated records should be processed in 120 minutes (2 hours) then ABAP requires 500 SAPS and database requires 3.500 SAPS. If 20.000.000 calculated records should be processed in 30 minutes then ABAP requires 4.000 SAPS and database requires 28.000 SAPS. Note For same amount of data, if the customer can afford a longer period to complete the processing, a machine will less capacity can handle the requirement and save some hardware cost. 3.3.2 Memory Sizing The net memory requirements for SAP NetWeaver BW depend on the number of parallel processes. Plan 300 MB for each parallel process. Number of parallel processes SAP NetWeaver Business Warehouse Memory [GB] 4 1.2 8 2.4 16 4.8 3.3.3 Disk Space Sizing The disk space required by the database data files is 235 bytes per calculated record. 20 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

3.3.4 Network Sizing No network frontend requirements with this scenario. 3.4 Sizing the What-If Scenario Similar to the Personnel expenditure Planning scenario, the resource consumption of the What-if scenario executed as background process depends on the number of employees/position, the average number of associated benefits and allocations, the projection duration in fiscal period and required duration of execution (P). = ( + ) 3.4.1 CPU Sizing The execution time depends on the level of parallelization of the batch job. For example, the number of employees can be split into packages of 100 and can be assigned for execution in parallel processes. The execution time (period) would be achieved only if enough parallel processes are configured to allocate fully the amount of calculated SAPS. Up to total number of calculated records Period (minutes) SAP NetWeaver Business Warehouse ABAP [SAPS] DB [SAPS] 5.000.000 30 900 5400 5.000.000 60 450 2700 10.000.000 30 1800 10800 10.000.000 60 900 5400 To estimate the resource requirements for different data volumes and periods follow the approach to reduce the SAPS by the factor of increase of the time period and to increase the SAPS by the factor of increased data volume for same period. For example: If 10.000.000 calculated records should be processed in 120 minutes (2 hours) then ABAP requires 450 SAPS and database requires 2.700 SAPS. If 20.000.000 calculated records should be processed in 30 minutes then ABAP requires 3.800 SAPS and database requires 21.600 SAPS. Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 21

3.4.2 Memory Sizing The net memory requirements for SAP NetWeaver BW depend on the number of parallel processes. Plan 300 MB for each parallel process. Number of parallel processes SAP NetWeaver Business Warehouse Memory [GB] 4 1.2 8 2.4 16 4.8 3.4.3 Disk Space Sizing The disk space, required by the database data files is 350 bytes per calculated record. 3.4.4 Network Sizing No network frontend requirements with this scenario. 3.5 Sizing Pay Period Personnel Expenditure Planning Scenario The resource consumption of the pay period personnel expenditure planning scenario executed as background process depends on the number of employees/position, the average number of associated benefits, allocations, the projection duration in pay periods and required duration of execution. If the number of fiscal periods are more than pay periods = ( + ) ( + ) If the number of pay periods are more than fiscal periods = ( + ) ( + ) 22 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

3.5.1 CPU and Memory Sizing The execution time depends on the level of parallelization of the batch job. For example the number of employees can be split into packages of 100 and can be assigned for execution in parallel processes. The execution time (period) would be achieved only if enough parallel processes are configured to allocate fully the amount of calculated SAPS. The duration of pay period personnel expenditure planning is heavily influenced by the database cache size configuration. Even small miss rates in the cache have quite negative impacts on the required database SAPS and duration of processing. The SAPS and memory requirements and usual execution time for PEP batch job with six ABAP work processes and package size of 100 - for volumes of data up to 10.000.000 records, this batch job configuration is considered optimal. Up to total number of calculated records Expected duration (minutes) ABAP [SAPS] DB [SAPS] Memory [MB} 1.000.000 9 740 1400 2500 2.000.000 16 760 1500 2500 10.000.000 80 780 2050 2500 Note For same amount of data, if the customer can afford a longer period to complete the processing, a machine will less capacity can handle the requirement and save some hardware cost. 3.5.2 Disk Space Sizing The disk space, required by the database data files is 249 bytes per calculated record. 3.5.3 Network sizing No network frontend requirements with this scenario. 3.6 Sizing the Attrition and Backfill Scenario The resource consumption of the attrition and backfill executed as background process depends on the number of employees/position, the average number of associated benefits, allocations, number of attrition rules, the projection duration in pay periods and required duration of execution. Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 23

= (Numberofemployeesattritestartingfromtheattriteperioduntilendofprojection + ) ( + ) 3.6.1 CPU and Memory Sizing The execution time depends on the level of parallelization of the batch job. For example the number of attrition and backfill rules can be assigned for execution in parallel processes. The execution time (period) would be achieved only if enough parallel processes are configured to allocate fully the amount of calculated SAPS. The duration of the attrition and backfill scenario is heavily influenced by the database cache size configuration. Even small miss rate in the cache has quite negative impact on the required database SAPS and duration of processing. The SAPS and memory requirements and usual execution time for execution of A&B batch job with 6 ABAP Work processes and package size of 100. - for volumes of data up to 10.000.000 records this batch job configuration is considered optimal. Up to total number of calculated records Expected duration (minutes) ABAP [SAPS] DB [SAPS] Memory [MB] 1.000.000 3 400 600 1200 2.000.000 6 500 700 1200 10.000.000 18 600 1800 1200 3.6.2 Disk Space Sizing The disk space, required by the database data files is 364 bytes per calculated record. 3.6.3 Network Sizing No network frontend requirements with this scenario. 3.7 Sizing the Ranking Forms Scenario The ranking forms scenario consists of six business steps and the average response time is about three seconds. The mapping between concurrent users and throughput with Ranking Forms scenario looks like 24 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

Throughput (scenario executions per hour) Average think time [s] Number of concurrent users 1000 5 ~20 1000 10 ~45 1000 30 ~75 A typical user executes the scenario with average think time of about ten seconds and an experienced user with about five seconds average think time. 3.7.1 CPU Sizing CPU and memory requirements for execution of 1000 business scenarios per hour with different number of forms ranked. Category Up to number of forms ranked SAP NetWeaver Composition Environment SAP NetWeaver Business Warehouse Java [SAPS] ABAP [SAPS] DB [SAPS] S 10 500 3200 750 M 25 550 3700 900 L 50 650 4500 1150 XL 100 800 6150 1650 More contact SAP or hardware vendor The resource requirements for higher throughput can be calculated applying a linear extrapolation. For example, the ABAP [SAPS] for 5000 scenarios per hour with 25 ranking forms will be 5 * 3700 = 18350 SAPS. The JAVA [SAPS] and DB [SAPS] for higher throughput are calculated in similar way. 3.7.2 Memory Sizing The net memory requirements for SAP NetWeaver BW depend on the number of concurrent user and the size of master data, for example Category Up to number of forms ranked Memory requirement Net ABAP Memory [GB] 20 concurrent users 45 concurrent users 75 concurrent users Initial Sizing for Public Budget Formulation 2013 SAP AG. All rights reserved. 25

Category Up to number of per user [MB] Net ABAP Memory [GB] S 10 18 0.3 0.8 1.3 M 25 20 0.4 0.9 1.5 L 50 24 0.5 1.1 1.8 XL 100 33 0.6 1.4 2.4 More contact SAP or hardware vendor The net memory requirement for SAP Java Composition Environment depends on the number of scenarios per hour and on the size of master data. For 1000 scenarios per hour the sufficient Java memory is Category Up to number of forms ranked SAP NetWeaver Composition Environment Java Memory [GB] S 10 0.3 M 25 0.35 L 50 0.4 XL 100 0.5 More contact SAP or hardware vendor For higher throughput apply ratio, for example with 5000 scenarios per hour and 10 re-allocation forms the Java Memory [MB] will be 5 * 0,3 GB = ~ 1,5 GB. 3.7.3 Disk Space Sizing 3.9 KB will be added to the database disk space per scenario execution. For example, if per year will be executed 1.000.000 scenarios required disk space will be 1.000.000 * 3.9 KB = 3.900.000 KB = 3.7 GB 3.7.4 Network Sizing Network traffic to front-end is on average 13 KB per business step, which is 6*13 KB = ~80 KB per scenario. Up to 20.000 scenarios per hour would fit into network capacity 5 Mbit/s. 26 2013 SAP AG. All rights reserved. Initial Sizing for Public Budget Formulation

4 Miscellaneous For performance optimizations and tuning with PBF please check OSS Note 1415800 FAQs PBF Performance Tuning at https://service.sap.com/~sapidb/012006153200000678492009e/sap_public_budget_formulation_701.pdf. 28 2013 SAP AG. All rights reserved. Miscellaneous

5 Comments and Feedback Please open an OSS message in component IS-PS-PBF or mail Rajesh Vijaywargi at rajesh.vijaywargi@sap.com or Natan Teren at natan.teren@sap.com. Comments and Feedback 2013 SAP AG. All rights reserved. 29

6 Appendix 6.1 Technical Details 6.1.1 Budget Forms Currency Conversion: Planning Function /PBFBI/BF_CURR_TRAN This function is used to convert the amount between the input currencies to the FM area currency. Expense: /PBFBI/A_BF_CU1_QI001 This is an input-ready query which displays the expenses data for the selected filter criteria and on Save commits the data to the budget forms info cube. Position: /PBFBI/A_BFCU_QI000 Planning Functions:/PBFBI/PF_DELETE01,/PBFBI/PF_DELETE01,/PBFBI/PF_BFHRM1 The input-ready query /PBFBI/A_BFCU_QI000 is used to read and save the positions entry. The planning functions are used to calculate the positions cost for the entered row. Revenue: /PBFBI/A_BF_CU1_QI003 This is an input-ready query which displays the revenues data for the selected filter criteria and on Save commits the data to the budget forms info cube. The three input-ready queries allow users to enter expenses/revenue and calculate the annual and month-wise cost of a position. The yearly records are stored in /PBFBI/BF_CUBE, and the monthly records are stored in Info Provider /PBFBI/HRPJ_R01. These stored records also contain the currency translated into the FM area currency. This translation is carried out using the /PBFBI/BF_CURR_TRAN planning function. 6.1.1.1 Expense and Revenue Using the presented layout, users are able to select Funds Center and Commitment items from a list of drop-down values, enter an amount (expense or revenue), and save the value to the budget from cube. The budget form header uses two functional modules: /PBFBI/NEW_FORM_INSTANCE to create form instances and /PBFBI/GET_HEADER_TEXT_NODES to display hierarchies in the header. Authorization checks are integrated in this same function. All PBF queries use standard BW analysis authorizations. 6.1.1.2 Position Tab The query in position tab allows users to request new positions. The costs for the new positions are driven from the Pay Levels (User Input Values or Job Defaults) and Benefits assigned to the selected Job. 30 2013 SAP AG. All rights reserved. Appendix

After saving, the calculation results for monthly salary and benefit records are posted to position Cube/PBFBI/HRPJ_R01 and annual salary and benefit records to/pbfbi/bf_cube. The Planning Function uses Info provider/pbfbi/bfhr_m01, aggregation level/pbfbi/a_bfhrm1, and filter/pbfbi/f_bfhrm1. 6.1.1.3 6.1.1.3 Copy Form Feature Transaction data from /PBFBI/BF_CUBE, Form Elements, Comments, Line Item Text will be copied from existing Form Instance to a newly created Form Instance. All the contents of the existing Form Instance will be copied into the new Form Instance with the exception of Attachments. The initial stage defined for the Form Definition will be set to the budget stage /PBFBI/STAGE copied to transactional data. The budget year /PBFBI/BDGT_YR of the copied to data will be set to the budget year maintained in configuration settings of PBF Global settings using Transaction code: SPRO. The Fiscal year 0FISCYEAR and Fiscal year/period 0FISCPER of the copied to transaction data will be added by a offset value that is calculated by the difference between the Budget year of the existing Form Instance and the Budget year of the new Form Instance. 6.1.1.4 File Upload Feature The functionality allows users to selectively upload data into specific tabs 6.1.1.5 Form Download PBF Form Download is a feature that allows user to download all the budget items and supporting text data with just one click from the budget form. The data is downloaded in XML file format that can be easily viewed in Microsoft Excel. 6.1.2 Budget Forms Re-Allocations 1. The user selects the following details: o Form ID: Sender Form ID is entered here. o Type of Entry: This is to decide whether an expense, revenue or position entry has to be allocated. o Fiscal Year: The year from which the amount has to be deducted. The query/pbfbi/a_alloc_qi001 is fired on the form ID, fiscal year, and type of entry to determine the total amount available for allocation in the form id. 2. The user selects the FM dimensions to retrieve a list of authorized receiver form IDs. 3. The user selects the line-item details for each of the receiver form IDs and the amount that will be allocated against each form. Appendix 2013 SAP AG. All rights reserved. 31

The /PBFBI/A_ALLOC_QI002 query is fired on the receiver form IDs selected in Step 2 to retrieve the total amounts. There is option of allocating based on percentages instead of entering full amounts. On Save and Re-Allocate, the RFC/PBFBI/SAVE_SEND_RECV_DATA and the planning function/pbfbi/pf_alloc are executed to create the entered allocations. 6.1.3 Personnel Expenditure Planning Functional Overview: The Personnel Expenditure Projection (PEP) is the calculation of the cost of each individual employee or vacant position: Most of the position and employee data is maintained within the HR system. HR Data is transferred to the PBF database at specific points in the budget formulation process. Projections are executed and analyzed as needed, and saved in the PBF database. The Projection Screen Parameters: FM Dimensions, Employee Group, Employee Sub-Group, Personnel Area, Personnel Sub-Area, Job, ES- Grouping CAP, Pay Scale Group. Non-Filter Parameters: Projection ID is a system-assigned number. Start Date The start date of the projection period. End Date The end date of the projection period. Vacant filter that tells the projection to calculate Filled only, Vacant only, or both. If Vacant, the projection calculates for only vacant positions; if Filled, the projection calculates only Filled; if both, no filter is applied. Vacant Lag Months: The number of lag months for filling a vacant position. For the projection, the system will not calculate any costs for the number of lag months entered. Lag months begin from the Projection Start Date. Valid values are (0, 1, 2, 11); default is 0. A Projection Start Date of 7/1/2010 with Lag Months = 2 will result in calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of a projection for vacant positions by the number of lag months. Ideally, Lag Months will also be a system parameter; the system will default the system parameter for lag months for all projections. Stage and Projection Type: Additional information is required in the Cube to indicate where a Projection Scenario s results should be used in the budget formulation process. Currency: The currency on which the month wise costs will be calculated. Post results to only cube: If this check box is set on, the month wise records will be saved only in cubes and deleted from month-wise DSO upon loading to cubes. 32 2013 SAP AG. All rights reserved. Appendix

Technical Overview: Object Type Object Short text DSO /PBFBI/HRPAO07 &/PBFBI/HRPAO09 Employee Month-wise DSO /PBFBI/HRPAO08 &/PBFBI/HRPAO10 Position Month-wise Info Cube /PBFBI/PROJ_1 Projection Cube 1 Info Cube /PBFBI/PROJ_2 Projection Cube 2 Multi Provider /PBFBI/HR_M04 Multi-Provider for Projection Cubes 6.1.4 What-If Projections The what-if projection screen has four sections as described below. Selection Screen Section In this section users will either display an existing What-if projection or create a new What-if projection based on a reference projection. What-if Projection Filter Section This section will allow users to change the selection filter for the what-if projection. The dimension parameters used in the reference projection are defaulted and can be changed to reflect a smaller selection or subset of the values inherited from referenced projection ID. This section will allow the users to restrict what-if results by FM dimensions, employee group/subgroups, personnel area/subarea, job, pay scale group, and so on. What-if Supplemental Data Section This section is similar to the existing Projection Scenario screen. Functionality in this section is to provide supplementary salary and benefit rate/amount to increment or decrease the computed amounts. Step Date, Allocation, and Benefit Supplemental Section This section allows users to enter/change Pay scale parameters like step months and next pay scale level information and enter any additional benefits. Users can also add cost allocations to cause results to be allocated Appendix 2013 SAP AG. All rights reserved. 33

differently than the reference projection. A variety of options are available to allow the changes to affect all employees and positions or limited to specific employees or positions. The What-If Projection Screen Parameters: FM Dimensions, Employee Group, Employee Sub-Group, Personnel Area, Personnel Sub-Area, Job, ES- Grouping CAP, Pay Scale Group. Non-Filter Parameters What-if Projection ID is a system-assigned number. Start Date - The start date of the projection period. End Date - The end date of the projection period. Vacant filter that tells the projection to calculate filled only, vacant only, or both. If Vacant, projection calculates for only vacant positions, if Filled, the projection calculates only Filled, if both, no filter is applied. Vacant Lag Months: The number of lag months for filling a vacant position. For the projection, the system will not calculate any costs for the number of lag months entered. Lag months begin from the Projection Start Date. Valid values are (0, 1, 2 11). Default is 0. A Projection Start Date of 7/1/2010, Lag Months = 2 will result in calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of a projection for vacant positions by the number of lag months. Ideally, Lag Months will also be a system parameter; the system will default the system parameter for lag months for all projections. Stage and Projection Type: Additional information is required in the Cube to indicate where a Projection Scenario s results should be used in the budget formulation process. Currency: The currency on which the month wise costs will be calculated. Post results to only cube: If this check box is set on, the month wise records will be saved only in cubes and deleted from monthwise DSOs upon loading to cubes. Technical Overview Object Type Object Short text DSO /PBFBI/RBPSE01 Employee Month wise DSO /PBFBI/RBPSP01 Position Month wise DSO /PBFBI/RBPSO01 Employee - PEP Analysis Data & Master Data Version DSO /PBFBI/RBPSO02 Position - PEP Analysis Data & Master Data Version DSO /PBFBI/RBPSO03 Position's Employee Count 34 2013 SAP AG. All rights reserved. Appendix

Object Type Object Short text DSO /PBFBI/RBPSO04 Projection Specific Pay Scale Level DSO /PBFBI/RBPSO05 Employee Projection Allocations DSO /PBFBI/RBPSO06 Position Projection Allocations DSO /PBFBI/RBPSO07 Employee Projection Benefits DSO /PBFBI/RBPSO08 Position Projection Benefits DSO /PBFBI/RBPSO09 Job Benefits Inherited Info Cube /PBFBI/RFPRJ_1 Reference Based Projection Cube 1 6.1.5 Ranking Technical Overview The Ranking data is stored in the Ranking cube /PBFBI/RANKING. The multi provider used is /PBFBI/BF_RANK. Aggregation Level: /PBFBI/A_RANK03 Planning Functions: /PBFBI/UNASSIGN_FORM: Change the funding status of the forms for a given version /PBFBI/RANK03_PFC02: Copy Prior Ranks /PBFBI/RANK03_PFC01: Copy Version with or without history /PBFBI/RANK03_PFX01: Used to Fund or Un-Fund form instances /PBFBI/RANK03_PFX02: Sequence Form ids /PBFBI/STORE_AMOUNTS: Stores yearly funding amount which are used for funding. The database table/pbfbi/rform contains the list of all the ranking ids created. 6.1.6 Pay Period Projection Pay period projections were added to address the requirement to produce results by pay period. These projections produce results at the fiscal period and pay period levels. For pay period PEP the lowest level of results are at the pay period level. Pay period PEP utilizes the same configuration and master data as Fiscal period PEP (with some exceptions) and also requires some additional configuration. The same employee and position master data can be used for either fiscal period PEP or pay period PEP with one exception. Benefit rule maintenance requires additional information for pay period month, year and accumulators to calculate benefits for pay period PEP. Appendix 2013 SAP AG. All rights reserved. 35

Functional Overview: The Pay Period PEP is the calculation of the cost of each individual employee or vacant osition: Most of the position and employee data is maintained within the HR system. HR Data is transferred to the PBF database at specific points in the budget formulation process. Projections are executed and analyzed as needed, and saved in the PBF database. The Projection Screen Parameters: FM Dimensions, Employee Group, Employee Sub-Group, Personnel Area, Personnel Sub-Area, Job, ES- Grouping CAP, Pay Scale Group. Non-Filter Parameters: Projection ID is a system-assigned number. Start Date The start date of the projection period. End Date The end date of the projection period. Vacant filter that tells the projection to calculate Filled only, Vacant only, or both. If Vacant, the projection calculates for only vacant positions; if Filled, the projection calculates only Filled; if both, no filter is applied. Vacant Lag Months: The number of lag months for filling a vacant position. For the projection, the system will not calculate any costs for the number of lag months entered. Lag months begin from the Projection Start Date. Valid values are (0, 1, 2, 11); default is 0. A Projection Start Date of 7/1/2010 with Lag Months = 2 will result in calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of a projection for vacant positions by the number of lag months. Ideally, Lag Months will also be a system parameter; the system will default the system parameter for lag months for all projections. Stage and Projection Type: Additional information is required in the Cube to indicate where a Projection Scenario s results should be used in the budget formulation process. Currency: The currency on which the month wise costs will be calculated. Post results to only cube: If this check box is set on, the month wise records will be saved only in cubes and deleted from month-wise DSO upon loading to cubes. Technical Overview: Object Type Object Short text DSO /PBFBI/PPRDOE1 Employee Pay Periodwise Records-1 DSO /PBFBI/PPRDOE2 Employee Pay Periodwise Records-2 DSO /PBFBI/PPRDOE3 Employee Pay Periodwise Records-3 DSO /PBFBI/PPRDOP1 Position Pay Periodwise Records-1 36 2013 SAP AG. All rights reserved. Appendix

Object Type Object Short text DSO /PBFBI/PPRDOP2 Position Pay Periodwise Records-2 DSO /PBFBI/PPRDOP3 Position Pay Periodwise Records-3 DSO /PBFBI/PPRDEMP Employee Master Data Template DSO /PBFBI/PPRDPOS Position Maste Data Template DSO /PBFBI/PPRDO11 Projection Pay Parameters for Pay Period DSO /PBFBI/PPRDO12 Projection Benefit Parameters for Pay Period DSO /PBFBI/PPRD_EC Stores pay periodwise position s employee count Info Cube /PBFBI/PPRD_C1 Pay Period Projection Cube1 Info Cube /PBFBI/PPRD_C2 Pay Period Projection Cube2 Info Cube /PBFBI/PPRD_C3 Pay Period Projection Cube3 Multi-Provider /PBFBI/PPRD_M1 Multi-Provider for Pay Period Projection Cube 6.1.7 Attrition and Backfill Projection An attrition and backfill projection takes a previously executed pay period PEP projection and applies an attrition and backfill group rule to create new results. It is a two-step process: The first step is to create a pay period projection with save maser data option is selected. This saves the master data, also known as a the reference pay projection, that is a pre-requisite for the attrition and backfill projection The second step is to create the attrition and backfill projection. This step requires the reference pay projection created in the first step and a pre-configured attrition and backfill group. The attrition and backfill group contains individual attrition rules to reduce costs (attritions) and any associated backfill criteria to increase future costs (backfill positions). The attrition and backfill projection writes the results into a separate InfoCube. Queries can then be used to combine the original reference pay period projection and the attrition and backfill projection results into a single report. The attrition and backfill framework includes the attrition and backfill scenario screen, an analysis layer to store data from the pay period reference projection and configuration DSOs for attrition and backfill rules. Attrition and backfill scenarios will use the analysis layer from the reference pay period projection for the calculations as well as attrition and backfill rules. Any PEP master data changes will need to be included in a pay period reference projection before they can be considered by attrition and backfill projections. For any configuration changes, such as benefit or pay level changes, a new reference pay period projection needs to be executed before any subsequent attrition and backfill projections are executed against it. Appendix 2013 SAP AG. All rights reserved. 37

Technical Overview Object Type Object Short text DSO /PBFBI/PPRDOE4 Attrition and Backfill Employee DSO DSO /PBFBI/PPRDOP4 Attrition and Backfill Position DSO DSO /PBFBI/PPRD_AH Attrition Rule Header DSO /PBFBI/PPRD_AB Attrition and Backfill Rule DSO /PBFBI/PPRD_AD Attrition Rule Detail Info Cube /PBFBI/PPRD_C4 Attrition and Backfill Projection Cube 38 2013 SAP AG. All rights reserved. Appendix

www.sap.com/contactsap 2013 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System ads, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iseries, pseries, xseries, zseries, eserver, z/vm, z/os, i5/os, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xapps, xapp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP Public Budget Formulation 8.1