SAP Public Budget Formulation 8

Sizing GuideDocument Version: 1.0 – 2013-09-30

CUSTOMER

SAP Public Budget Formulation 8.1

2Customer© 2013 SAP AG. All rights reserved.

SAP Public Budget Formulation 8.1Typographic Conventions

Typographic Conventions

Type Style Description

Example 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.

Example Emphasized words or expressions.

EXAMPLE Technical names of system objects. These include report names, program names,transaction codes, table names, and key concepts of a programming language when theyare surrounded by body text, for example, SELECT and INCLUDE.

Example 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 anddatabase tools.

Example Exact user entry. These are words or characters that you enter in the system exactly as theyappear in the documentation.

<Example> Variable user entry. Angle brackets indicate that you replace these words and characterswith appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F2 or ENTER .

SAP Public Budget Formulation 8.1Document History

Customer© 2013 SAP AG. All rights reserved. 3

Document History

Version Date Change

1.0 2013-09-30 Initial release


SAP Public Budget Formulation 8.1Table of Contents

Table of Contents

1 Introduction .............................................................................................................................................. 71.1 Functions of SAP Public Budget Formulation ....................................................................................................... 7

1.1.1 Budget Forms .......................................................................................................................................... 71.1.2 Budget Forms Re-Allocations ................................................................................................................ 81.1.3 Personnel Expenditure Planning ............................................................................................................ 81.1.4 What-If Projection ................................................................................................................................... 81.1.5 Pay Period Personnel expenditure Planning ........................................................................................ 91.1.6 Attrition and Backfill Projection ............................................................................................................. 91.1.7 Ranking .................................................................................................................................................... 9

1.2 Architecture of SAP Public Budget Formulation ................................................................................................ 101.3 Factors that Influence Performance .................................................................................................................... 10

2 Sizing Fundamentals and Terminology ................................................................................................. 11

3 Initial Sizing for Public Budget Formulation ........................................................................................ 133.1 Sizing the Budget Forms Scenario ....................................................................................................................... 14

3.1.1 CPU Sizing ............................................................................................................................................. 143.1.2 Memory Sizing ....................................................................................................................................... 153.1.3 Disk Space Sizing .................................................................................................................................. 163.1.4 Network Sizing ...................................................................................................................................... 17

3.2 Sizing the Budget Forms - Reallocations Scenario ............................................................................................ 173.2.1 CPU Sizing ............................................................................................................................................. 173.2.2 Memory Sizing ....................................................................................................................................... 183.2.3 Disk Space Sizing .................................................................................................................................. 193.2.4 Network Sizing ...................................................................................................................................... 19

3.3 Sizing “Personnel expenditure Planning” scenario ............................................................................................ 193.3.1 CPU Sizing ............................................................................................................................................. 193.3.2 Memory Sizing .......................................................................................................................................203.3.3 Disk Space Sizing ..................................................................................................................................203.3.4 Network Sizing ...................................................................................................................................... 21

3.4 Sizing the What-If Scenario .................................................................................................................................. 213.4.1 CPU Sizing ............................................................................................................................................. 213.4.2 Memory Sizing ....................................................................................................................................... 223.4.3 Disk Space Sizing .................................................................................................................................. 223.4.4 Network Sizing ...................................................................................................................................... 22

3.5 Sizing Pay Period Personnel Expenditure Planning Scenario ........................................................................... 223.5.1 CPU and Memory Sizing ....................................................................................................................... 233.5.2 Disk Space Sizing .................................................................................................................................. 233.5.3 Network sizing ....................................................................................................................................... 23

3.6 Sizing the Attrition and Backfill Scenario ............................................................................................................ 233.6.1 CPU and Memory Sizing ....................................................................................................................... 243.6.2 Disk Space Sizing .................................................................................................................................. 243.6.3 Network Sizing ...................................................................................................................................... 24

3.7 Sizing the Ranking Forms Scenario ..................................................................................................................... 24

SAP Public Budget Formulation 8.1Table of Contents


3.7.1 CPU Sizing ............................................................................................................................................. 253.7.2 Memory Sizing ...................................................................................................................................... 253.7.3 Disk Space Sizing ................................................................................................................................. 263.7.4 Network Sizing ...................................................................................................................................... 26

4 Miscellaneous ......................................................................................................................................... 28

5 Comments and Feedback ......................................................................................................................29

6 Appendix ................................................................................................................................................ 306.1 Technical Details ................................................................................................................................................... 30

6.1.1 Budget Forms ....................................................................................................................................... 306.1.2 Budget Forms Re-Allocations .............................................................................................................. 316.1.3 Personnel Expenditure Planning ......................................................................................................... 326.1.4 What-If Projections ............................................................................................................................... 336.1.5 Ranking .................................................................................................................................................. 356.1.6 Pay Period Projection ........................................................................................................................... 356.1.7 Attrition and Backfill Projection ...........................................................................................................37


SAP Public Budget Formulation 8.1Introduction



1 Introduction

SAP Public Budget Formulation (SAP PBF) supports the Public Sector budgeting process and the associatedreporting requirements. The application uses SAP NetWeaver Business Warehouse as the backend and VisualComposer as the frontend.

The application consists of a list of BW objects, RFC-enabled function modules, BW-IP queries and planningfunctions, and Java-based text handling black boxes that are seamlessly integrated to a visual composer model toaddress business process.

1.1 Functions of SAP Public Budget Formulation

The application has four modules – Budget Formulation, Ranking, Personnel expenditure Planning, and BudgetForm Re-allocations.

1.1.1 Budget Forms

The Budget Form uses the BW-Integrated Planning Framework and comprises of three queries. The Form Layoutcontains 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 SAPapplications. After successful completion of the Form Instance creation process, the user moves to the line-itemsection 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 leasttwo other selections in the line-item level. Each of these selections would include two browser navigations. In thecase of the Budget Form position tab, the number of manually maintained values is significantly higher than theexpense 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 filteredby the PBF combo-edit functionality. The PBF combo edit functionality uses SAP BW analysis authorizations andis 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.



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 valueor percentages.

The functionality is based on BW-Integrated planning framework and comprises of two queries and two planningfunctions. 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 personnelmaster 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 andstores 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-Ifscenario is used to create a new projection based on a reference projection. The dimension parameters used inthe reference projection are defaulted and can be changed to reflect a smaller selection or subset of the valuesinherited 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 supplementarysalary and benefits rate/amount to increment or decrease the computed amounts. Users can add/change Payscale parameters like step months and next pay scale level information and enter any additional benefits. Userscan also add cost allocations to cause results to be allocated differently than the reference projection. A variety ofoptions are available to allow the changes to affect all employees and positions or limited to specific employees orpositions.

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 referenceprojection is a PEP projection scenario executed with the Save Master Data option selected. The second step is tocreate the what-if projection using the master data from the referenced projection completed in first step. Thewhat-if projection allows users to further filter the FM dimensions, date ranges and other selection parameters as



well as change Next Pay Scale levels, add benefits and add or change allocations to employees and positions thusallowing 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 setup 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 beposted in Pay Periods and FISCAL Periods. A new framework is implemented to support high volume data moreeffectively. The functionality also allows users to select master data sources. Example: If the user has twoversions of master data, say from ECC and a locally modified version in BW, during the execution of projection, theuser would now be able to select the master data source.


1.1.6 Attrition and Backfill Projection

A framework supports the attrition and backfill scenario, very similar to what was built to support what-ifprojections 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 wouldincrease costs.


1.1.7 Ranking

Functional Overview

The Ranking template is a Visual Composer (VC) model that allows users of Public Budget Formulation (PBF) toprioritize budget requests by assigning ranking values.

Ranking is available for all requests within a form definition. Ranking is used to assign priority ranks to budgetrequests, compare request amounts by FM dimension combination and then determine which requests could befunded 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 theselected dimensional hierarchy. The ranking form will re-sequence the budget requests based on the assignedrank.

Please refer section 6.1 for technical details.



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 functionsuse the JCo connections PBF_BI and PBF_R3. An additional two connection types are used: WebDynpro logicalconnection for WebDynpro screens and a Web Service connection hosted in BW JAVA and called by the CEsystem

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 datacombinations 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 theamount of concurrent users.

The user activity profile takes into consideration the pauses between the different interactions of the user with thesystem. Users who navigate more intensively with the user interface of the PBF application are more productive interms of number of executed scenarios per time interval. If the concurrent users are more productive, theresource requirements are higher.

SAP Public Budget Formulation 8.1Sizing Fundamentals and Terminology


2 Sizing Fundamentals and Terminology

SAP provides general sizing information on the SAP Service Marketplace. For the purpose of this guide, weassume that you are familiar with sizing fundamentals. You can find more information athttp://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 influencedby both business aspects and technological aspects. This means that the number of users using the variousapplication 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 sizingrecommendations 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 datarelevant to the system, user, and business applications are monitored during a benchmark run and can be used tocompare platforms.

SAPS

The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes theperformance 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 orderline items per hour. (For more information about SAPS, see http://www.sap.com/benchmark Measuring inSAPS).

Initial Sizing

Initial sizing refers to the sizing approach that provides statements about platform-independent requirements ofthe hardware resources necessary for representative, standard delivery SAP applications. The initial sizingguidelines assume optimal system parameter settings, standard business scenarios, and so on.

http://service.sap.com/sizing


SAP Public Budget Formulation 8.1Sizing Fundamentals and Terminology

Expert Sizing

This term refers to a sizing exercise where customer-specific data is being analyzed and used to put more detailon the sizing result. The main objective is to determine the resource consumption of customized content andapplications (not SAP standard delivery) by comprehensive measurements. For more information, seehttp://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 customer-specific project. This includes the implementation of distribution, security, and high availability solutions bydifferent 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/instguidesSAP NetWeaver).

http://service.sap.com/sizing

http://service.sap.com/instguides

SAP Public Budget Formulation 8.1Initial Sizing for Public Budget Formulation


3 Initial Sizing for Public BudgetFormulation

The hardware requirements are derived from resource consumption measurements in internal SAP systemsusing 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 had541,000 entries and Ranking Cube had 1100 entries. Data volume in the /PBFBI/BF_CUBE is 541,743 and inthe /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 areconsidered 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, theaverage think time of the users when executing the scenario. Respectively, the throughput can be calculatedback 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 thelatest recommendations for minimum ABAP server memory, usually above 4 GB. The ABAP Memory [MB] inthis sizing guideline is the net memory, required to run the specified amount of concurrent users or parallelprocesses (in case of background jobs).

The memory requirement for SAP Java Composition Environment depends on the throughput. The JavaMemory [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 higherthroughput might be required either more server nodes or different memory configuration with one servernode.

The memory requirements of the database are vendor specific. Please, check with database vendor for anappropriate recommendation, which is usually provided on the basis of sharing the SAPS requirementinformation with the database vendor.



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 ofconcurrent users, and to the increase of throughput.

For scenarios which are executed by concurrent users, the SAPS for Java server, ABAP server, and databaseare calculated with guarantee factor of 65%, which means that there is 35% extra capacity planned to handlepeaks 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 Formsscenario looks like this:

Throughput (scenario executionsper hour)

Average think time [s] Number of concurrentusers

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 tenseconds and an experienced user executes the scenario for about minutes, which would correspond to about fiveseconds average think time.

3.1.1 CPU Sizing

The CPU requirements are defined for execution of 1000 scenario executions per hour with different number ofunique master data values.

In brackets are provided additional PBF 8.1 feature SAPS required for processing of a mixture of total 1000export, download, copy or upload operations per hour, in any combination, for example x1 uploads, x2 copies, x3downloads, 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 expectedusage 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 usedfor the above four characteristic hence the unique master data values in this scenario is 200 (that is, 50 x 4).



Category Up to …uniquemasterdatavalues

SAP NetWeaverComposition Environment

SAP NetWeaver Business Warehouse

Java [SAPS]

(additional PBF 8.1 featureSAPS)

ABAP [SAPS]

(additional PBF 8.1feature SAPS)

DB [SAPS]

(additional PBF 8.1feature SAPS)

S 50 450

(300)

2650

(900)

800

(600)

M 100 500

(550)

3100

(1600)

900

(1000)

L 200 550

(650)

4000

(2500)

1050

(1500)

XL 500 700

(800)

6650

(5000)

1550

(3000)

More – contact SAP or hardware vendor

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 = 13250SAPS. 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 ofmaster data, With the new features – export, copy, download and upload the memory requirements per user areincreased. In brackets are provided additional PBF 8.1 feature memory values. In contrast to the SAPS, whennew PBF 8.1 features are used, only the values in brackets should be considered and not the sum of oldfunctionality and new functionality.

Category Up to …UniqueMasterdataValues

Memoryrequirementper user [MB]

(additionalPBF 8.1features MB)

Net ABAP Memory [GB]

(additional PBF 8.1 features GB)

50 concurrentusers

100 concurrentusers

250 concurrentusers

S 50 24

(40)

1.2

(1.9)

2.3

(3.8)

5.9

(9.5)



Category Up to …UniqueMaster

Memoryrequirementper user [MB]



M 100 26

(60)

1.3

(2.9)

2.5

(5.8)

6.3

(14.5)

L 200 28

(80)

1.4

(3.9)

2.7

(7.8)

6.8

(19.5)

XL 500 32

(100)

1.6

(4.9)

3.1

(9.8)

7.8

(24.5)


The net memory requirement for SAP Java Composition Environment depends on the number of scenarios perhour and the size of the master data. In brackets is provided the memory requirement when new features areused. For 1000 scenarios per hour the sufficient Java memory is

Category Up to … Unique Master dataValues

SAP NetWeaver CompositionEnvironment Java Memory [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)


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 withfew 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.



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 to10.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 andthroughput looks like following:



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” userwith ~ 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 forre-allocations

SAP NetWeaver CompositionEnvironment


Java [SAPS] ABAP [SAPS] DB [SAPS]

S 10 600 2100 1000

M 25 650 2350 1050

L 50 750 2750 1150



Category Up to …forms forre-

SAP NetWeaver CompositionEnvironment


XL 100 950 3550 1400


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 ofmaster data, for example

Category Up to …Forms forRe-allocations

Memoryrequirement peruser [MB]


25 concurrentusers

40 concurrentusers

100 concurrentusers

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


The net memory requirement for SAP Java Composition Environment depends on the number of scenarios perhour and on the size of master data. For 1000 scenarios per hour the sufficient Java memory is

Category Up to … Forms for Re-allocations


S 10 0.4

M 25 0.45

L 50 0.5

XL 100 0.7


For higher throughput apply ratio, for example with 5000 scenarios per hour and 10 re-allocation forms the JavaMemory [MB] will be 5 * 0,4 GB = ~ 2 GB .




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


Network traffic to front-end is on average 12 KB per business step. Up to 20.000 scenarios per hour would fit intonetwork 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 onthe number of employees/position, the average number of associated benefits and allocations, the projectionduration 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 employeescan 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 ofcalculated SAPS.



Up to … total numberof calculated records

Period

(minutes)


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 theSAPS by the factor of increase of the time period and to increase the SAPS by the factor of increased data volumefor same period.

For example:

If 10.000.000 calculated records should be processed in 120 minutes (2 hours) then ABAP requires 500 SAPSand database requires 3.500 SAPS.

If 20.000.000 calculated records should be processed in 30 minutes then ABAP requires 4.000 SAPS anddatabase requires 28.000 SAPS.

NoteFor same amount of data, if the customer can afford a longer period to complete the processing, amachine 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 MBfor each parallel process.

Number of parallel processes SAP NetWeaver BusinessWarehouse Memory [GB]

4 1.2

8 2.4

16 4.8


The disk space required by the database data files is 235 bytes per calculated record.




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” scenarioexecuted as background process depends on the number of employees/position, the average number ofassociated 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 employeescan 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 ofcalculated SAPS.

Up to … total numberof calculated records

Period

(minutes)


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 theSAPS by the factor of increase of the time period and to increase the SAPS by the factor of increased data volumefor same period.

For example:

If 10.000.000 calculated records should be processed in 120 minutes (2 hours) then ABAP requires 450 SAPSand database requires 2.700 SAPS.

If 20.000.000 calculated records should be processed in 30 minutes then ABAP requires 3.800 SAPS anddatabase requires 21.600 SAPS.



3.4.2 Memory Sizing

The net memory requirements for SAP NetWeaver BW depend on the number of parallel processes. Plan 300 MBfor each parallel process.

Number of parallel processes SAP NetWeaver BusinessWarehouse Memory [GB]

4 1.2

8 2.4

16 4.8


The disk space, required by the database data files is 350 bytes per calculated record.



3.5 Sizing Pay Period Personnel Expenditure Planning Scenario

The resource consumption of the pay period personnel expenditure planning scenario executed as backgroundprocess 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

= ( + )

( + )



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 employeescan 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 ofcalculated SAPS.

The duration of pay period personnel expenditure planning is heavily influenced by the database cache sizeconfiguration. Even small miss rates in the cache have quite negative impacts on the required database SAPS andduration of processing.

The SAPS and memory requirements and usual execution time for PEP batch job with six ABAP work processesand package size of 100 - for volumes of data up to 10.000.000 records, this batch job configuration is consideredoptimal.

Up to … totalnumber ofcalculated 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

NoteFor same amount of data, if the customer can afford a longer period to complete the processing, amachine will less capacity can handle the requirement and save some hardware cost.



3.5.3 Network sizing


3.6 Sizing the Attrition and Backfill Scenario

The resource consumption of the attrition and backfill executed as background process depends on the numberof employees/position, the average number of associated benefits, allocations, number of attrition rules, theprojection duration in pay periods and required duration of execution.



= (Number of employees attrite starting from the attrite period until end of projection+ )

( + )

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 attritionand backfill rules can be assigned for execution in parallel processes. The execution time (period) would beachieved 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 ofprocessing.

The SAPS and memory requirements and usual execution time for execution of A&B batch job with 6 ABAP Workprocesses and package size of 100. - for volumes of data up to 10.000.000 records this batch job configuration isconsidered optimal.

Up to … totalnumber ofcalculated 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.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





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 withabout 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 formsranked.

Category Up to …number offorms ranked

SAP NetWeaverCompositionEnvironment


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


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 ofmaster data, for example

Category Up to …number offormsranked


Memoryrequirement

20 concurrentusers

45 concurrent users 75 concurrent users



Category Up to …number of


per user [MB]

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


The net memory requirement for SAP Java Composition Environment depends on the number of scenarios perhour and on the size of master data. For 1000 scenarios per hour the sufficient Java memory is

Category Up to … number of formsranked


S 10 0.3

M 25 0.35

L 50 0.4

XL 100 0.5


For higher throughput apply ratio, for example with 5000 scenarios per hour and 10 re-allocation forms the JavaMemory [MB] will be 5 * 0,3 GB = ~ 1,5 GB.


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


Network traffic to front-end is on average 13 KB per business step, which is 6*13 KB = ~80 KB per scenario. Up to20.000 scenarios per hour would fit into network capacity 5 Mbit/s.



Up to … scenarios perhour

Network capacity [Mbit/s]

1000 0.3

5000 1.2

10000 2.5

20000 5


SAP Public Budget Formulation 8.1Miscellaneous

4 Miscellaneous

For performance optimizations and tuning with PBF please check OSS Note 1415800 “FAQs PBF PerformanceTuning“ athttps://service.sap.com/~sapidb/012006153200000678492009E/SAP_Public_Budget_Formulation_701.pdf.

https://css.wdf.sap.corp/sap/bc/bsp/spn/sapnotes/index2.htm?numm=0001415800

https://service.sap.com/~sapidb/012006153200000678492009E/SAP_Public_Budget_Formulation_701.pdf

SAP Public Budget Formulation 8.1Comments and Feedback


5 Comments and Feedback

Please open an OSS message in component IS-PS-PBF or mail Rajesh Vijaywargi at [email protected] orNatan Teren at [email protected].

mailto:[email protected]

mailto:[email protected]


SAP Public Budget Formulation 8.1Appendix

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 commitsthe 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 planningfunctions 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 commitsthe data to the budget forms info cube.

The three input-ready queries allow users to enter expenses/revenue and calculate the annual and month-wisecost of a position. The yearly records are stored in /PBFBI/BF_CUBE, and the monthly records are stored in InfoProvider /PBFBI/HRPJ_R01. These stored records also contain the currency translated into the FM areacurrency. 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-downvalues, 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 instancesand /PBFBI/GET_HEADER_TEXT_NODES to display hierarchies in the header. Authorization checks areintegrated 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 fromthe Pay Levels (User Input Values or Job Defaults) and Benefits assigned to the selected Job.



After saving, the calculation results for monthly salary and benefit records are posted to positionCube/PBFBI/HRPJ_R01 and annual salary and benefit records to/PBFBI/BF_CUBE. The Planning Function usesInfo 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 existingForm Instance to a newly created Form Instance. All the contents of the existing Form Instance will be copied intothe 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 totransactional data. The budget year /PBFBI/BDGT_YR of the copied to data will be set to the budget yearmaintained in configuration settings of ‘PBF Global settings’ using Transaction code: SPRO. The Fiscal year0FISCYEAR and Fiscal year/period 0FISCPER of the copied to transaction data will be added by a offset value thatis calculated by the difference between the Budget year of the existing Form Instance and the Budget year of thenew 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 withjust one click from the budget form. The data is downloaded in XML file format that can be easily viewed inMicrosoft 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 totalamount 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 allocatedagainst each form.



The /PBFBI/A_ALLOC_QI002 query is fired on the receiver form IDs selected in Step 2 to retrieve the totalamounts. 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 planningfunction/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 vacantposition:

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 projectioncalculates 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 willnot calculate any costs for the number of lag months entered. Lag months begin from the Projection StartDate. Valid values are (0, 1, 2, …11); default is 0. A Projection Start Date of 7/1/2010 with Lag Months = 2 willresult in calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of aprojection for vacant positions by the number of lag months. Ideally, Lag Months will also be a systemparameter; 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 ProjectionScenario’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 anddeleted from month-wise DSO upon loading to cubes.



Technical Overview:

ObjectType

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

MultiProvider

/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 areference projection.

What-if Projection Filter Section

This section will allow users to change the selection filter for the “what-if” projection. The dimension parametersused in the reference projection are defaulted and can be changed to reflect a smaller selection or subset of thevalues inherited from referenced projection ID. This section will allow the users to restrict what-if results by FMdimensions, 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 providesupplementary 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 levelinformation 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 allemployees and positions or limited to specific employees or positions.

The What-If Projection Screen Parameters:


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 willnot calculate any costs for the number of lag months entered. Lag months begin from the Projection StartDate. Valid values are (0, 1, 2…11). Default is 0. A Projection Start Date of 7/1/2010, Lag Months = 2 will resultin calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of aprojection for vacant positions by the number of lag months. Ideally, Lag Months will also be a systemparameter; the system will default the system parameter for lag months for all projections.



Post results to only cube: If this check box is set on, the month wise records will be saved only in cubes anddeleted 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 DataVersion

DSO /PBFBI/RBPSO02 Position - PEP Analysis Data & Master DataVersion

DSO /PBFBI/RBPSO03 Position's Employee Count




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. Theseprojections produce results at the fiscal period and pay period levels. For pay period PEP the lowest level of resultsare 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 masterdata can be used for either fiscal period PEP or pay period PEP with one exception. Benefit rule maintenancerequires additional information for pay period month, year and accumulators to calculate benefits for pay periodPEP.



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:


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 projectioncalculates 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 willnot calculate any costs for the number of lag months entered. Lag months begin from the Projection StartDate. Valid values are (0, 1, 2, …11); default is 0. A Projection Start Date of 7/1/2010 with Lag Months = 2 willresult in calculations of 0 for 7/2010, 8/2010 for vacant positions. This effectively changes the start date of aprojection for vacant positions by the number of lag months. Ideally, Lag Months will also be a systemparameter; the system will default the system parameter for lag months for all projections.



Post results to only cube: If this check box is set on, the month wise records will be saved only in cubes anddeleted from month-wise DSO upon loading to cubes.

Technical Overview:


DSO /PBFBI/PPRDOE1 Employee Pay Periodwise Records-1



DSO /PBFBI/PPRDOP1 Position Pay Periodwise Records-1






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 employeecount

Info Cube /PBFBI/PPRD_C1 Pay Period Projection Cube1



Multi-Provider /PBFBI/PPRD_M1 Multi-Provider for Pay Period ProjectionCube

6.1.7 Attrition and Backfill Projection

An attrition and backfill projection takes a previously executed pay period PEP projection and applies an attritionand 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 masterdata, 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 projectioncreated in the first step and a pre-configured attrition and backfill group. The attrition and backfill group containsindividual 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 canthen be used to combine the original reference pay period projection and the attrition and backfill projectionresults into a single report.

The attrition and backfill framework includes the attrition and backfill scenario screen, an analysis layer to storedata from the pay period reference projection and configuration DSOs for attrition and backfill rules. Attrition andbackfill scenarios will use the analysis layer from the reference pay period projection for the calculations as well asattrition and backfill rules. Any PEP master data changes will need to be included in a pay period referenceprojection before they can be considered by attrition and backfill projections. For any configuration changes, suchas benefit or pay level changes, a new reference pay period projection needs to be executed before anysubsequent attrition and backfill projections are executed against it.



Technical Overview


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

www.sap.com/contactsap

© 2013 SAP AG. All rights reserved.No part of this publication may be reproduced or transmitted in anyform or for any purpose without the express permission of SAP AG.The information contained herein may be changed without priornotice.Some software products marketed by SAP AG and its distributorscontain proprietary software components of other softwarevendors.Microsoft, Windows, Excel, Outlook, and PowerPoint are registeredtrademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, System ads, System i5, Systemp, 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 EnterpriseServer, PowerVM, Power Architecture, POWER6+, POWER6,POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix aretrademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the U.S. andother countries.Adobe, the Adobe logo, Acrobat, PostScript, and Reader are eithertrademarks or registered trademarks of Adobe SystemsIncorporated 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 theOpen Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,VideoFrame, and MultiWin are trademarks or registered trademarksof Citrix Systems, Inc.HTML, XML, XHTML and W3C are trademarks or registeredtrademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute 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 byNetscape.SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge,ByDesign, SAP Business ByDesign, and other SAP products andservices mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG in Germany and inseveral other countries all over the world. All other product andservice names mentioned are the trademarks of their respectivecompanies. Data contained in this document serves informationalpurposes only. National product specifications may vary.These materials are subject to change without notice. Thesematerials are provided by SAP AG and its affiliated companies ("SAPGroup") for informational purposes only, without representation orwarranty of any kind, and SAP Group shall not be liable for errors oromissions with respect to the materials. The only warranties for SAPGroup products and services are those that are set forth in theexpress warranty statements accompanying such products andservices, if any. Nothing herein should be construed as constitutingan additional warranty.

Date post:	25-Jan-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

SAP Public Budget Formulation 8

Documents