Quick Sizer Guide for SAP

Table of Content

SAP Business Suite

CRM

ERP

Financials

Human Capital Management

Logistics Execution

Product Development & Execution

Sales & Service

Corporate Services

Supply Chain Management

Demand Planning

Supply & Production Planning

Order Fulfillment

Inventory Collaboration Hub

Integration to ECC

Extended Warehouse Management

Extended Warehouse Management - Inbound

Extended Warehouse Management - Outbound

Supplier Relationship Management

Global Trade Services

Compliance and Customs Management

Risk Management Preference Processing

Industry Solutions

SAP for Banking

Analytical Banking

Core Banking

Page 1 of 76SAP Quick Sizer Help

10/30/2007https://websmp202.sap-ag.de/~sapidb/011000358700000519272005E

Insurance

Retail

Utilities

NetWeaver

Portal

Business Intelligence

Process Integration

Application Server

NetWeaver Standalone Engines

Expert Functions

The sizing elements from the questionnaires are written in italics.

Customer Relationship Management

CRM in the Quick Sizer

Note for IPC Handling The current Quick Sizer version is based on SAP CRM 5.0. SAP NetWeaver Application Server ABAP includes the software component Internet Pricing & Configurator (IPC), but the Quick Sizer result currently does not. Therefore, you have to size IPC with the sizing guideline Sizing the Internet Pricing & Configurator and add the result to the Quick Sizer result. In former CRM releases, the IPC was a separate component which was also installed separately.

Activity Management ACT-USER CRM-ACT

Definition Within Activity Management, your employees can:

Create business activities to document any interaction they have with customers Create tasks to manage their own workload Manage their work in the Application Workplace View appointments and activities in the calendar Access the Business Workplace for using workflow items

The two main elements in Activity Management are the application workplace and the calendar. Each provides a different view of your workload and you can switch between them.



The calendar displays all your appointments in a daily, weekly, or monthly overview. The inbox, on the other hand, provides you with a personal workplace or file manager, where all your activities, whether they have been given fixed appointments or not, are clearly sorted into different folders.

Activities often are some kind of follow-on actions, for example a follow-up call after an initial sales conversation with a customer.

Changes to an activity are regular. Make sure you include this information in the sizing.

Comments

Users are very rarely entered in this component because they are usually more involved in order processing or opportunity processing. Therefore, you should attribute users to these components rather than to Activity Management. Note that attached documents (typically PC type documents such as text files, presentations, or documents in print format) which are uploaded into CRM are not considered in this approach.

Opportunity Management OPP-USER CRM-OPP

Definition The Opportunity describes the sales prospects, their requested products and services, the sales prospect’s budget, the potential sales volume and an estimated sales probability. This information becomes concrete in the course of the sales cycle, and can be displayed and evaluated in the system.

Opportunity Management provides the framework for presenting sales projects from the very start, and tracking their progress. In this way, it provides the basis for an analysis and optimization of your Enterprise.

Users in Opportunity Management can use the following functions:

Presentation of the Sales Cycle Reason for Status Working With Products Management of Attachments Transferring Data for Sales Volume Forecast Classification of Opportunities Texts in Opportunities Opportunities - Fast Change

Comment

Make sure you (determine and) enter the number of times the opportunities are displayed or changed (in percent). This is important for the sizing because the typical lifecycle of an opportunity includes several changes (for example the status or phase) as well as several display actions (for example, to check the ongoing status or the final



success). Note that attached documents (typically PC type documents such as text files, presentations, or documents in print format) which are uploaded into CRM are not considered in this approach.

Internet Sales CRM-ISA Browsing the Catalog and Placing Orders

Definition Internet Sales: This component allows electronic business activities to take place between companies and consumers as well as only between companies. Using SAP Internet Sales, manufacturers, shippers, wholesalers, and retailers can sell their products directly via the World Wide Web. The following components are contained in CRM Internet Sales:

Business-to-Consumer (B2C) Internet Sales Business-to-Business (B2B) Internet Sales Business-to-Reseller (B2R) Internet Sales

Specifics for E-Selling in Internet Sales

Shop visits Number of visits to Internet shop (a visit normally consists of about 15 steps) % ord. Percentage of visits that lead to orders Items Average number of line items/sub objects per order/object CLP If checked, catalog list prices are used Months Number of months the data remains in the database (residence) Archiving Checks for existing archiving objects (no influence)

Comment Typically Internet Sales users will visit the internet shop and browse through the catalog to gather information about products. While most of the users will not fill the shopping basket or order products, there are of course a percentage of users who will put products into the shopping basket and place an order.

Enter the number of user visits to the shop and also specify how many percantage of the visits will lead to an order. This varies for the different Internet Sales scenarios (B2C, B2B, …). For B2C typically 10% of the visits lead to an order.

Service Transactions SRV-USER CRM-SRV

Definition You can use the component Service transaction to represent business processes in the service area in your company. Service transactions can be entered in the following ways.

By an employee in the CRM System



Service Order

By an employee in the Customer Interaction Center By your customer via the Internet

The service transaction can be either a service order or a service request.

Definition A short-term agreement between a service provider and a service recipient, in which the service recipient orders one-off services which are billed when completed using resource-related billing. The line for service orders includes the following:

Services Spare parts Products Prices Billing data

Customer Interaction Center IC-USER

Definition The Customer Interaction Center (CIC) is a key technology of Customer Relationship Management with the SAP Business Suite. It is designed as a multi-channel, blended business process interaction center to empower call centers to provide the highest level of customer service. It provides robust technology for contact center operations. It tightly integrates a highly customizable and full-featured front office with your back-office as well as your entire range of customer-centric processes. The Customer Interaction Center is the common state-of-the-art technology for any business transactions via phone, email, letter or face to face. It’s used in the following CRM Business Scenarios: Service Interaction Center, Telesales and Telemarketing. Highlights of CIC include:

Processing inbound and outbound telephone calls with customers and other business partners using Computer Telephony Integration (CTI) technology as middleware. An Email Office system for processing incoming and outgoing emails. Also included are Planned Activities for the agent to execute. A comprehensive Interaction History log to provide one view of a customer. This enables agents to view planned and historical activities along with sales and service orders.

Comment

For user-based sizing we assume that the CIC creates additional load. Basic load is created by the business transactions called through CIC, such as Opportunity Management, Activity Management, Customer Order, and Service Transaction. Therefore we recommend you enter a CIC user in the line for CIC as well as in the line of the respective business transaction.

To reflect CIC orders in the Quick Sizer use the line for customer orders and add the number of calls.

Example Altogether, 100,000 customer orders are being created, 50,000 of them through CIC. To reflect this, you enter 100,000 under customer orders and 50,000 under calls.



CIC Emails and Calls IC-CALL

Definition Enter the number of incoming and outgoing emails and calls. Note that business objects created during a call, such as a customer order or a service order must be entered separately. This equally applies to business objects that are displayed or changed during that call. Make sure you specify this in the columns for display and changes for the respective objects.

Note that only objects created or changed in CRM need to be considered. Because of the flexible design of the CIC and the SAP Workplace, other systems (such as non-SAP or legacy systems) can be incorporated in the process as well. But consecutive load in systems other than SAP CRM are not in the scope of this sizing. Therefore, activities may very well produce load in systems other than SAP CRM. For example, if a call center agent opens a customer order in a legacy system to display the delivery status, this has no influence on CRM sizing.

Mobile Sales and Service MSA-USER CRM-MSA

Definition In general, the Mobile Sales users will upload their data to the CRM system in a time frame of a few hours in the evening. Enter the highest number of users you expect to login within one hour.

Mobile Sales allows sales teams to work offline and to synchronize their data with the backend system. In this way, it supplies all the information required for optimal customer interaction. Such information can include real-time updates on:

Business partners Contact persons Products and services Opportunities Activities

This component contains functions allowing sales representatives to:

Coordinate their activities, including marketing and advertising campaigns Present product lines and compare them to competitive products Create quotations and orders immediately on site Ensure that orders are correct and confirmable, including configuration, pricing, and delivery data Coordinate the transmission, retrieval, and storage of inbound and outbound information

Mobile Service allows field service representatives to review daily service visit agendas, prepare service jobs, report on time spent and materials used as well as reporting on malfunctions encountered. It also enables field personnel to enter information on actions performed to fulfill service obligations.

Note Here you can also enter users who use Handheld Sales and Handheld Service.



Back to Top

Enterprise Resource Planning

Back to Top

Financials

Customer Orders SLS-USER CRM-SLS

Definition In CRM, customer orders can be created in different ways, for example by a telesales agent in the Call Center or by customers via the Internet. Directly created orders in CRM Online are included here as well.

It is important to enter the customer orders in the line/application/module where they are closest to because this may have a great influence on sizing.

Financials

Definition SAP ERP Financials comprises

Financial Supply Chain Management (FSCM) Financial Accounting (FA) Management Accounting (MA) Corporate Governance (CG)

Financial Supply Chain Management includes functions such as Treasury and Risk Management, Cash and Liquidity Management (CLM), Credit Management, and Dispute Management. The dominating functions of Financial Accounting are General Ledger, Accounts Receivable and Payable, Fixed Asset Accounting, and Financial Statements. Amongst others, Management Accounting includes Profit Center Accounting, Project Accounting, Revenue and Cost Planning, and Transfer Pricing. The Quick Sizer maps most of the sizings of FSCM and FA to FI, Management Accounting is predominatly reflected in CO. From a sizing perspective Corporate Governance plays a subordinate role.



FI User FI-USER

Definition In general, all users in the above transactions can be sized with 1 FI user (e.g. FI-AA, CLM).

To size Treasury and Risk Management (TRM) users, enter 2 FI users per TRM user.

Note Business Intelligence with its Strategic Enterprise Management comprises the functions that were formerly accounted for by Enterprise Controlling.(see Business Intelligence)

Controlling CO-USER CO

Definition of CO documents A proof of a cost accounting posting. This posting can be made both within (for example, distribution) and outside of (for example, primary cost posting in FI) CO.

Example

Documents to capture consumption of production factors Documents to capture the services of an enterprise

Line items: Because of double accounting, every document contains at least two line items. The number of line items in CO-OM and CO-OM-ABC (Activity-Based Costing) are posted to CO objects (such as orders, cost centers, and projects). Postings to statistical orders consist at least of three line items, because a statistical order contains booking, counter-booking and a separate display of the costs to enable descriptive reporting. Activity allocations add another line to the posting, because additionally the amount of services (non-monetary) are booked separately.

Example

Posting from Posting to Number of line itemsCost center Cost center 2

Cost center Statistical order 3

Posting activity calculation from

Posting activity calculation to Number of line items

Cost center Cost center 3

Cost center Statistical order 4

Comment If you use detailed planning, you should add line items created during planning.

Enter the number of line items that are created online (D = standard sizing for throughput) Enter the period closing activities (B = standard sizing for background)



Postings into CO, for example

(D) FI-postings into CO (D) Material movements into CO (D) Completion confirmations (PP,PM)

CO-internal allocations, for example

(D) Reposting (D) Activity allocation (B) Indirect activity allocation -> assessment (B) Overhead rates -> overhead rate (B) Settlement -> settlement (B) Assessment -> assessment (B) Distribution -> assessment (B) Periodic reposting -> assessment (B) Template allocation is currently not included. It mainly consists of a set of customer-defined functions, so measurements for CPU consumption cannot be done

Profitability Analysis CO-PA-BIL CO-PA-FI CO-PA-SLS

Comment In our experience, the number of documents that you transfer to CO-PA from Sales and Distribution (SD) or Financial Accounting (FI) serves as a good indicator of the disk space and system load that CO-PA represents. Using this indicator simplifies the sizing process because the Quick Sizer no longer needs to take into account the contributions from planning, cost center assessment, the information system, realignments, or settlement. If your requirements in one of these areas are high (for example, a large volume of data needs to be processed by a large number of users during peak system load times), you should contact your hardware partner or SAP. To gain a deeper understanding of the factors that can influence sizing and performance, see the information contained in at service.sap.com/co-pa.

Transferred Objects: If you use Profitability Analysis, SD billing documents (SD-BIL) and FI documents are transferred to CO-PA automatically. The transfer of orders (SD-SLS), on the other hand, is optional. For objects, enter the number of documents transferred per year from the respective components to CO-PA. For sub objects, enter the average number of document items in each case. You can also use the above methods to display how external data is transferred to CO-PA.

Profit Center Accounting Documents EC-PCA

Definition Number of documents that are posted to Profit Center Accounting (EC-PCA). For sizing we assume that the majority of postings are created in other components and then posted to EC-PCA. Enter the number of documents that are created in PCA with their respective lines items and the number of orders that have been posted by other components.



Business Accounting Documents FIN-BAC

Definition The proof of a business transaction. A distinction is made between original documents and data processing (DP) documents:

Original documents include incoming invoices, bank statements and carbon copies of outgoing invoices. DP documents include accounting documents, sample documents and recurring entry documents.

Whereas accounting documents are a representation of the original document in the SAP System, sample and recurring entry documents are simply templates to simplify entry of accounting transactions.

Assessment CO-OM

Definition Assessment is a method of internal cost allocation in which you transfer the costs of a sender cost center to receiver CO objects (orders, other cost centers, and so on) under an assessment cost element. The system supports both the hierarchical method (where the user determines the assessment sequence) and the iterative method (where the system determines the sequence via iteration).

Estimation of line items for assessment, distribution and periodic reposting:

The segments of all cycles have to be added. For each segment the line items (sender (S) - receiver (R) relationship) may be calculated:

assessment S-R = number of senders * number of receivers distribution S-R = number of senders * number of receivers * average number of cost elements used by the sender periodic reposting (equal to distribution) Indirect activity allocation S-R = number of senders * number of receivers * average number of activities used by the sender

Example You have defined a cycle which consists of the segments A and B. Each segment consists of 5 senders and two receivers. Each receiver(R) of segment A has received postings from each sender(S) with three different cost elements (CE). Each receiver(R) of segment B has received postings from each sender(S) with four different cost elements. Therefore the cycle has 30 + 40 = 70 S-R relations altogether. Segment A: 5 (S) * 3 (CE) * 2 (R) = 30 S-R relationships Segment B: 5 (S) * 4 (CE) * 2 (R) = 40 S-R relationships

Overhead Rates & Order Settlement CO-OM-RATE CO-OM-SETT

Definition Overhead rate refers to a rate at which overhead is allocated to direct costs to charge cost objects with the proportion of the overhead costs attributable to them. This can be a lump sum, percentage, or quantity-based rate.

An example of the use of overhead rates is to allocate overhead from material cost centers to orders by debiting the orders



Back to Top

Human Capital Management

in proportion to the material withdrawals and crediting the material cost centers with the same amounts. Also used to allocate sales and administration overhead.

Order settlement is the complete or partial crediting of an order. The costs which have accrued to an order are debited to one or several allocations.

Overhead rates: Enter the number of orders, cost centers and projects, that receive an overhead rate per period.

Order settlement: Enter the number of orders (from PP, PM, and CO) which are settled per period. We assume that your orders are settled without using the original cost element.

Personnel Administration & Payroll Accounting PA-USER

Definition Personnel Administration and Payroll Accounting from the Human Resource (HR) component includes the following areas: Personnel Administration, Benefits, Compensation Management, Recruitment, Personnel Time Management, Incentive Wages, Business Trip Management and Payroll Accounting.

Time Evaluation - Processed Time Pairs HCM-PT

Definition Time evaluation is a program which is generated daily to calculate attendance and absence times on the basis of attendance and absence data, time types (flextime balance, productive hours) and wage types (bonuses for night, Sunday and public holiday work). Assumption: Time Evaluation is processed every working day.

Personnel Planning & Development PD-USER

Definition Personnel Planning and Development includes the following areas: Organizational Management, Personnel Development, Workforce Planning, Training and Event Management and Room Reservations Planning.



Back to Top

Logistics Execution

Back to Top

Payroll HCM-PY

Definition For payroll you need to enter the number of employees and the number of retro calculations per payroll. A retro calculation is when a payroll run is repeated for a period for which payroll accounting has already been performed in the payroll past. Retroactive accounting is triggered during the payroll run for the current period if certain master and time data affecting the payroll past has been changed in the meantime.

Multiply the average number of retro calculations per employee per payroll times plus 1 times the number of employees: (number_employees)* (1 + number_retro_calculations). For example: You have 2 retro calculations per employee, this means a payroll run is executed for 3 periods in total. If have 100,000 employeed for whom the payroll is done, then you calculate (100,000) * (1 + 2) = 300,000. Please enter 300,000.

Comment Financial postings resulting from loan postings have to be treated separately. For the number of employees we assume that the payroll is executed once a month. Other periods should be scaled through the input data (Example: 50,000 employees should be calculated semi-monthly in 4 hours -> Input: 100,000 employees and 8 hours)

Logistics Execution LE-USER

Definition Logistics Execution contains Warehouse Management as well as Inbound and Outbound Logistics

Stock Movement LE-WM

Definition The business object transfer order is an instruction to move materials from a source storage bin to a destination storage bin within a warehouse complex at a specified point in time.

Line items: A transfer order consists of items that contain the quantity of the material to be moved and specifies the source and destination storage bins.

Delivery Notes & Goods Issue LE-SHP

Definition Number of delivery notes and goods issue.

Line items: Average number of line items for delivery notes and goods issue.



Product Development & Execution

PM Orders ALM-USER ALM-PM

Definition Orders in the sense of maintenance orders. Requirement to execute a maintenance task on a maintenance object for a specific deadline. In addition, the maintenance order is a means of documenting maintenance work. In particular, maintenance orders are used to

- plan maintenance tasks in a targeted manner - monitor the execution of maintenance tasks - enter and settle the costs incurred by maintenance tasks

The sub-object of a maintenance order is a component. A maintenance order contains operations that describe the individual work steps. If greater detail is required, operations can be subdivided into sub-operations. Enter the average number of components per operation.

Materials Management MM-USER

Definition Materials Management contains Inventory Management as well as Purchasing.

Materials Movement MM-IM

Definition Physical or logical movement of materials which leads to a change in material stock levels or results in direct consumption of the material. A goods movement can be a goods receipt, goods issue, or a transfer posting of materials. Please enter the number of all material movements that originate from any used component within the SAP system (e.g. LE - SHP Logistics Execution - Shipment)

Line items: A goods movement consists of items containing the quantity and value of the given material. The materials to be actually placed in or removed from storage can be specified in each item as single units.

Comment No postings in the previous month. When processing different IDOC-types (e.g. store order), enter any follow-on documents separately (such as SD order line-items in SD-SLS).

Purchase Order MM-PUR

Definition Request or instruction from a purchasing organization to a vendor (external supplier) or a plant to deliver a certain quantity of material or to perform certain services.

Line items: A purchase order consists of a number of items, each of which will have a procurement type defined.

Comment We assume a purchase order has two text lines on average. 30% of the purchase orders are assigned to an account.

10% of the line items have delivery costs. There is one goods receipt line item per purchase order line item. There is one



invoice line item per purchase order line item.

Production Planning and Control PP-USER

Definition Production Planning contains Sales & Operations Planning, Master Planning Capacity planning as well as Material Requirements Planning. Production Control deals with Production Orders, KANBAN and Repetitive Manufacturing.

Confirmations PP-CONF

Definition Documents the processing status of operations or sub-operations. A final confirmation is used to determine:

At which work center the operation was carried out Who performed the operation Quantities of yield and scrap produced Size of the standard values required for the operation

Comment

Enter the respective materials movements (goods receipt for the header material and goods movement for the used components) in the line for MM-IM. This is not counted automatically. Line items means the number of confirmed operations.This is not the number of material components as in the sizing element PP-SFC. The assumptions of the production order in the sizing element PP-SFC apply here, too.

Repetitive Manufacturing (Planned Orders) PP-REM

Definition A component in the SAP System for planning and controlling repetitive manufacturing and flow manufacturing.

It enables the period-dependent and quantity-dependent planning of production lines and reduces the work involved in production control and simplifies backflushing (confirmation, goods receipt posting).

Production Orders PP-SFC

Definition Manufacturing order used for discrete manufacturing. A production order contains operation sequences. An operation describes how to carry out a work step. By combining operations into operation sequences, you can create parallel or alternative processes.

The sub-object of a production order is a component: The following graph gives an example of how to determine the number of components by showing number of components of a multi-level BOM of a product F1.



The finished product F1 contains a semi-finished product F2, which is also an in-house-product. Therefore the production orders for both products F1 and F2 must be considered for sizing.

The size of the "number of components" is determined by the summation of all individual components on the first production layer (finished product and semi-finished product, respectively). The components used are either raw materials, for example F1Cx or F2Cx, or assemblies, such as F2 used in the production of F1. Phantom assemblies (P1 and P2) are only used to structure the bill of materials; they are not produced seperately. The components of the phantom assemblies (P1Cx or P2Cx) must therefore be added to the components of the next higher level.

Therefore, in this example we can determine the following number of components:

The production orders for the finished product F1 have seven components (F1C1, F1C2, F1C3, P1, P1C1, P1C2, and F2). The phantom assembly P1 should be counted as a real component. The production orders for the assembly F2 have six components (F2C1, F2C2, P2, P2C1, P2C2, and P2C3).

Note

The columns for the display of objects and the changes of objects should be filled, too. If, for example, you create a production order in one transaction and release it afterwards, please enter "100" for "object changes" because every order (i.e., 100% of the orders) is changed by being released. If you display the production order, then you must fill in the field for object display.



Confirmations to a production order must be entered at the sizing element PP-CONF. Order settlements are not considered and have to be considered by CO.

Comment We assume:

10 status items per production order 3 status items per component 1 sequence for every 10 componentsr 1 operation for every 5 components 3 status items per operation

Project System PS-USER PS

Definition Projects: A complex structure of tasks within a controlling area which is used to control and monitor the schedule, resources, capacities, cost, revenues, and funds availability.

Specifics for PS

WBS-Elements: An individual structural element in the work breakdown structure (WBS) representing the hierarchical organization of a project. It describes either a concrete task or a partial one that can be further subdivided. Networks: A network contains instructions on how to carry out activities in a specific way, in a specific order and in a specific time period. Activities: Average number of activities per network. An activity is a task in a network which has a defined start and finish. An activity can be broken down into activity elements. There are three categories of activities in the Project System: - internal activities - external activities - general costs activities

Due to the nature of project plans the procedure for entering data is slightly different from that in other components. Each year, usually only a few projects with many WBS elements are created. In contrast to other objects, such as FI documents projects are changed frequently, sometimes several times per day. This aspect of Project System is addressed in the Quick Sizer as follows

For average load

Enter the projects created per year, the average number of WBS elements per project and the residence period as usual Enter the average number of networks per project Enter the average number of activities per network Enter the average number of changes and average number of display per project (during its total lifetime)



For peak load

In the highload phase, for example at the end of the month when the projects statuses must be updated, enter the number of objects that are created, displayed, and changed on that particularly busy day. To determine peak CPU consumption, enter data that reflects the actions of a very busy day. Do not enter data that reflects a typical day - this is automatically considered. The way of entering data for peak load for projects is a little bit different from other sizing objects. The number of new projects, the number of changes and displays are just added and the sum is entered in the field "Objects". Average numbers of WBS, networks, and activities are entered as for the average load. The fields "Changes" and "Display" stay empty.

For example:

Every year, 150 projects are created with an average of 500 WBS elements. They remain in the database for about five years. On the average, each project consists of 20 networks and 100 activities per network. The estimation of the total number of changes and displays per project bases on the assumption that a project is changed three times and displayed once per working day over a period of 2 years. In a high load phase, 300 projects are changed five times and displayed once during a day. Additionally, on these very busy days, 10 projects are created. The sum of the number of new projects, changes, and displays is: 10 + 300*5 + 300*1 = 1.810

You enter the following data in the Quick Sizer:

Average load:

Number of objects per year: 150 Avg. no. of WBS elements: 500 Avg. no. of networks: 20 Avg. no. of activities/network: 100 Residence period in months: 60 Number of changes per project: 1.200 (3 changes / working day * 200 working days / year * 2 years) Number of displays per project: 400 (1 display / working day * 200 working days / year * 2 years)

Peak load:

Number of objects during peak load: 1.810 Avg. no. of WBS elements: 500 Avg. no. of networks: 20 Avg. no. of activities/network: 100 Number of changes (total): no input Number of displays (total): no input Time period: 08:00 - 16:00

Comment For calculation we assume:

Five status items per project Five distribution rules per project



Three status items per WBS element Three distribution items per WBS element Three allocations per WBS element

Inspections in Quality Management QM-USER QM-IM

Definition Tasks for determining the actual status of a technical system (for example, a machine) or a material.

Inspection Characteristics: The basis on which an inspection is performed.

Comment We assume that one inspection with several inspection characteristics is carried out per inspection lot. On average, there is one single value recording per inspection characteristic.

Material Requirements Planning MRP RUN

Definition Material Requirements Planning (MRP) Generic term for procedures in materials planning which take into account and plan every future requirement during the creation of order proposals (independent requirements, dependent requirements, and so on).

Net Change Planning Materials planning run where only those materials are planned which have undergone a change relevant to materials planning since the last planning run.

Specifics for MRP

Planned orders per day A planned order (PP-SOP) is a request created in the planning run for a plant to trigger the internal procurement of a plant material for a certain quantity for a specific date. Enter the number of planned orders that are added per day. The Quick Sizer automatically determines the total number of planned orders for the planning run (number of planned orders per day * planning horizon in days). Components/Bill of Material (BOM): Average number of components per BOM see PP-SFC Reorder items: Purchase requisitions for reorder-point driven materials Special procedure in materials planning. If the reorder point is greater than warehouse stock, an order proposal is created by materials planning. For this type of procurement multiple requests are summed up to build one procurement request. This is the lean version of external procurement. Non-reorder items: Purchase requisitions or schedule line items for non-reorder-point driven materials For this type of procurement each individual request leads to a purchase requisition or a schedule line item. This is the more demanding version of external procurement. Planning horizon in days: Length of planning horizon in days The planning horizon is the period which is used when the MRP planning mode "net change planning in the planning



Back to Top

Sales & Service

horizon" is used. For this type of net change planning only those materials are planned in the planning run which have a change related to materials planning within the period (in work days). The length of the planning horizon should at least include the following: Period in which customer orders are being created, delivery times and complete material processing time. % BOM changes per day: Number of BOM structure changes per day in % Each change of a BOM invalidates the planning data and requires a new calculation of all planned orders which are based on this BOM. Enter the average number of BOMs which are changed per day. % dependencies: % of BOM components with object dependencies (average) When variant configuration is used the explosion of the BOM is a more complex process. The Quick Sizer assumes a model of small or medium complexity of the underlying variant configuration and takes into account additional resource requirements. If the customer's model of variant configuration lies within this small to medium category, the average number of components (%) with object dependencies can be entered directly. If the customer's model of variant configuration is very complex, the input can be multiplied by an additional factor which takes into consideration extra resources. For example: If 10 % of the BOM components have object dependencies and the model is three times more complex enter 30 % in this field. % LTS: Number of orders with Lead Time Scheduling in % Lead Time Scheduling calculates the exact production dates and creates capacity requirements by using the routing information.

Comment We assume the following:

The MRP run is conducted every day with the processing key "Net change" and planning mode "Adapt planning data". The number of components implicitely determines the scope of the routing. With an increasing number of components, the number of operations in the routing rise. The runtime and CPU consumption directly depend on the number of reservations in the system. The MRP run can be parallized without end, dependencies on data constellation are not considered. The MRP sizing of the Quicksizer only gives CPU numbers. Diskspace is not calculated, because the MRP run works more or less on a steady state concerning the disk space. This means that the planning data created by the MRP run is deleted when the corresponding production orders and purchase orders are created.



Customer Service CS-USER CS-AG

Definition Application component that can be used to process services. Customer Service mainly comprises the following functions:

Structuring and management of technical objects for which services are to be performed (for example, technical systems, machines) Management of data regarding warranties and business partners Creation of service requests Planning and execution of the requested services Billing of the costs that arise as a result of the services Monitoring of call processing to ensure dates and agreed response times

Components: The sub-object of an order is a component. In an order, components are usually materials assigned to an operation. Enter the average number of components per order.

Comment We assume that one operation is valid for five components.

Incentive and Commission Management ICM

Definition Incentive and Commission Management delivers the capability to define various commission plans and render payment through the SAP payroll solution, thus rounding out the compensation solution. Please note that Sizing measurements are based on the standard table widths of ICM.

ICM Case Processing ICM-CASE

Specifics for ICM Case Processing

Number of commission cases This is the number of cases multiplied by the number of processing steps. A processing step is each change made to the case, such as create, change, reset, reactivate or mass postprocessing (for pending cases etc.) as well as additional commission cases (Bonuses and target agreements etc.). A common approach to improve the sizing result is to reduce the number of commission cases prior to posting. This is usually done by the operational system(s) by condensing according to the business restrictions. Remunerations per commission case These are the remunerations a document creates. In general this is the number of (direct and indirect) recipients per commission case. Number of months the data remains in the database How many months do the documents remain in the system on average before they are archived? Documents can only be completely archived if all due line items have been cleared. Reversed documents can always be archived. You can archive individual case versions for the commission case. "Old" case versions that are not valid can be archived immediately. There are further restrictions for all other versions.

ICM Document Posting

Specifics for ICM Document Posting



ICM-DOC

Number of documents Number of documents that are directly imported from the operational system(s) to ICM without using the commission case process. Remunerations per document These are the remunerations a document creates. In general this is the number of (direct and indirect) recipients per document. Number of months the data remains in the database How many months do the documents remain in the system on average before they are archived? Documents can only be completely archived if all due line items have been cleared. Reversed documents can always be archived. "Old" case versions that are not valid can be archived immediately. There are further restrictions for all other versions.

ICM Settlement ICM-SET

Specifics for ICM Settlement

Number of settlement items Every commission created directly by the commission case or via document posting as well as each settlement scheduling line item has to be summed up here. The settlement scheduling run uses compression based on certain criteria such as same due date, same business partner etc… This may reduce the number of due line items created by settlement scheduling. Each participant will receive at least one settlement item per case. Number of commission contracts Number of commission contracts which have to be settled. The contracts using settlement scheduling also have to be included here.

Sales & Distribution SD-USER

Definition Sales & Distribution contains Sales and Billing as well as Shipping.

Customer Inquiries SD-CUST

Definition A customer request to the company for a quotation or sales information that is not binding. The request can refer to materials or services, conditions and, if necessary, delivery deadlines. It is accepted by the sales area that is then responsible for any further processing. A customer request comprises one or several items containing the required quantity of a material/service.

Line items: Number of line items per customer inquiry

Invoices SD-BIL

Definition Sales and distribution document used to charge a customer for a delivery of goods or for services rendered.

Line items: Number of line items per invoice.



Sales Data and IDocs SD-POS

Definition Number of Sales Data and IDocs created per year. The Quick Sizer assumes that for every Idoc, one material document and one billing document are generated with subsequent postings to FI. The IDocs themselves are assumed to be archived immediately.

The column "number of objects created per year" refers to the number of documents created per year. The next column "number of subobjects....." refers to the number of line items per document.

The Quick Sizer considers aggregated upload (WPUUMS). In the case of WPUBON, you will have to consider the following:

1. Number of POS transactions. This corresponds to the number of customers per store. 2. Number of items per transaction. This corresponds to the number of articles purchased by each customer.

The total number of line items is the product of number of customers and the number of articles per customers.

Example: You have 500 stores with an average of 300 customers per day and an average of three articles per customers. Assuming one IDoc per store this will give you:

500 IDocs, each with 900 lines per day. Assuming 300 working days Number of objects created per year = 300 x 500 = 150000, Number of sub objects = 900 Residence period is actually that of the follow-on documents - material-, billing- and financial-documents.

Comment Number of Sales Data and Idocs created per year. The System creates one goods issue and one bill per document/IDOC including the respective number of line items. With each bill and material movement, one FI document with the respective number of line item is created. Additional postings are not considered.

When processing different IDOC-types (e.g. store order), enter any follow-on documents separately (such as SD order line-items in SD-SLS).

In the following graph you can see the factors that influence sizing.



Back to Top

Corporate Services

Sales Orders SD-SLS

Definition A customer request to the company for delivery of goods or services at a certain time.

Travel Receipts TV-RECEIPT

Definition Enter the number of receipts from business trips. These can be

Travel costs Lunch expenses Hotel costs



Back to Top

Supply Chain Management

Back to Top

Demand Planning

Line items are the average number of line items per receipt, for example travel costs, meals, or accommodations.

User in SCMIn SCM, load created by users is added to the throughput sizing. This is a different procedure from standard user sizing.

Demand Planning DP USER Sizing assumptions and principles

The hardware sizing for SAP APO estimates the following three hardware components:

1) Live Cache server

2) Database server

3) Application server

liveCache is a memory-based Database and therefore the appropriate estimation of the memory requirement is very important.

The SAP APO Demand planning application stores the historical data in NetWeaver BI InfoCubes. These are described as user designed relational databases, composed of one large table of input and output values, called a Fact Table, and several smaller tables that contain characteristics describing the data. These are called dimension tables. InfoCube data are stored in tables on the disk, not in the Live Cache.

For performance reason the historical data is copied from NetWeaver BI InfoCube to liveCache. Since Demand Planning uses Live Cache, the Live Cache size is increased due to the historic and planning result time series data in it. Instead of



storing the data in Star Scheme format (Fact and Dimension table combination) of the InfoCube, Live Cache stores the data in a time series for a particular key figure and characteristic combination.

Characteristics are attributes that describe what is planned. Examples include item code, UPC, brand name, market segment, location and customer name. Key figures hold the data input and output quantities that are stored in a single fact table for each InfoCube. Examples include sales history, demand forecast and percent promotion increase. Characteristics and key figures cannot be interchanged. In addition, characteristics can be bundled into groups, called dimensions. For example, item name, UPC, brand name, and market segment can be bundled into a single dimension called product. The number of info objects and dimensions and the number of unique values for each info object are used to determine the required data storage needed for the APO Demand Planning system.

The characteristic combinations, key figures, and time horizon are the variables, which influence the scalability of Demand Planning. The characteristic combination is the most dynamic variable, which has the range from a few hundred thousands to several millions. Tests showed that the runtime of the DP planning jobs is acted in a linear form with the increasing of the characteristic combination. In other words, the throughput (number of characteristic combinations be planned per hour) scales with the size of the hardware.

Compression of Timeseries

The Time Series data stored in liveCache may be compressed. This compression technique is very simple and it should be understood that a Time Series is either compressed or it is not. There is no partial compression. The only parts of the Time Series that is compressed are the empty time buckets. If less than 30% of the time buckets in a Time Series are loaded with data, then the empty time buckets are compressed. Nothing is done to the time buckets that have data in them. If more than 30% of the time buckets in a Time Series are loaded with data, the empty time buckets remain uncompressed and are loaded with zeros. As data is loaded, time buckets are filled for a specific characteristic combination key figure in a Time Series. Time Series compression is dynamic, i.e. when a Time Series is filled to greater than 30%, SAP software un-compresses the empty time buckets. Likewise, if data is deleted from the Time Series and usage falls below 30%, the Time Series is again compressed. For all practical purposes, there is no memory consumed by empty time buckets for a Time Series when compressed. However, memory is consumed when the Time Series is expanded even with the time buckets filled with zeros. For a characteristic combination key figure Time Series, data resides in real memory until LiveCache is cleared. When compressing a characteristic combination key figure Time Series, SAP software builds a structure representing the compressed data. This structure consists of the position of the time bucket data for a characteristic combination key figure in a Time Series, and the data for that time bucket. There are no entries in the structure for time buckets that have zero data. Currently, all characteristic combination key figures for a Time Series and for a Planning area have the same number of time buckets.

Sizing Elements Mainly we size the memory requirements of the timeseries stored in liveCache. The CPU sizing is determined by the batch planning run which calculates the forecast.



APO - Planning Area Sizing - SAP liveCache Memory TIMESERIES

Specifics for the Planning Area Sizing - SAP liveCache Memory

The total number of characteristic combinations is the number of values of each combination multiplied. For example, a company plans 800 products across 12 plants to serve 20 customer locations. Then the number of characteristic combinations would be 800*12*20 = 19,200. But usually not all products are available in all plants and all customer locations. Instead the average number of products in each location has to be estimated, e.g. in average 100 products are located in plants and in average 2 customer locations are delivered by one plant. Then the total number of characteristic combinations would be 100*12*2= 2,400.

Total number of key figures is the sum of the key figures used in planning.

Total number of periods is a count of time buckets used in planning. The more time buckets, the more memory space in liveCache are required to store data. For example, a DP planner may define an annual forecast in weekly time buckets. Hence, the number of time buckets is 52. Alternatively, the planner may define the annual forecast horizon as 12 weeks followed by 8 months. In that case, the number of time buckets would be 12+8*4 = 42, because all data is stored in the smallest time unit.

Compression index Either a 'Compression index' can be specified or the number of compressed time series (in percent) and the number of periods can be specified in the compressed time series. A compression index of 0 means that all time series are not stored in compressed form and the maximum main memory requirement is calculated. A compression index of 9 means that 90% of the time series are stored in a compressed way. A compression index of 5 is preset. This corresponds to a compression rate which we have observed with many customers.

Note Fill-in either values for the compression index or values for the following two fields.

Percentage of compressed timeseries: In a productive environment you can determine the percentage of compressed timeseries with help of the report /SAPAPO/OM_TS_FILLRATE (see note 537210). If you can’t determine this number than please use the compression index.

Number of time buckets in compressed timeseries: If the percentage of compressed time series and the number of periods in the compressed time series is known, these values can be entered in the fields provided (see note 537210).

Total number of planning versions stored in liveCache. The calculation for liveCache memory requirements assumes that each version contains the same amount of data per version.

APO - Planning Run Sizing - CPU DP RUN

Specifics for the Planning Run Sizing - CPU

Characteristic combinations relevant for planning run. A planning run can generate a forecast at any aggregation level in the hierarchy. If the forecast is generated at the lowest aggregation level (typically Item/Location) then all of the characteristic combinations are relevant for planning. Alternatively, if the planning run



is generated at higher level, then only a percentage of the characteristic combinations is used to generate a plan. So, the amount of CPU processing time is reduced in direct linear proportion to the percentage of characteristic combinations used to generate a forecast. The totals can be disaggregated to lower levels in the planning book, or summed up to a higher level in the hierarchy. For example, if a planner generates forecasted demand for a region, then the system does not plan forecasts for all of the different sales channels, product families, brands, products, and customers in that region. Those values are calculated in the planning book when displaying those characteristic combinations, and are based on the results of the forecast at the region.

Periods for planning run is a count of time buckets used in planning. CPU process time increases as the time bucket count grows.

The duration of planning run time frame is determined by a Company's planning and operating requirements. The shorter the required time frame, the more CPU processing power is required to complete the planning run. The impact required for CPU processing power versus process time is in reverse linear proportion.

Back to Top

Production Planning and Supply Network Planning

Production Planning and Supply Network Planing PP USER SNP USER

Sizing assumptions and principles The hardware sizing for SAP APO estimates the following three hardware components:

1. Live Cache server

2. Database server

3. Application server

The Task of Supply Network Planning is to identify sources for supply for finished products. It plans and considers safety stock levels in any location and distributes production over plants. Additionally it chooses production resources in plants and explodes bill of materials in plants. The outputs are purchase requisitions, stock transport purchase requisitions and planned production orders. We consider SNP heuristic to estimate the CPU requirements. The SNP heuristic usually runs in background.

Sizing Elements Mainly we size the memory requirements of the orders in liveCache. The CPU sizing is determined by the SNP heuristic planning run. If more than one version is used then we recommend to input the data for each version separately and add a comment which describes the version. You can easily add new input lines for each version.



APO - Master Data - SAP liveCache Memory MASTERDATA

Specifics for Master Data - SAP liveCache Memory

The number of product-location combinations can be determined by one of two ways. If all products can be stored in all locations, then multiply the number of products by the number of modeled locations. Alternatively, if selected products are stored at each facility, then sum up the number of products modeled at each location. For example, each customer location may store only finished goods, while each distribution center stores both finished goods, and components, and each plant produces and stores only a portion of the finished goods and components.

Total numbers of resources i.e. work center, production lines, and tools to be planned in APO. Resources used in APO can define work centers, or production lines and tools used in the manufacturing of products. Determine the number of resources used in APO planning for both Supply Network Planning and Detailed Scheduling.

APO - Warehouse Stocks - SAP liveCache Memory STOCK

Specifics for Warehouse Stocks - SAP liveCache Memory

The number of warehouse stocks is a count of the detailed stock locations used in planning. For each facility, you have to decide whether sub locations will be included in the planning process. These can be as detailed as shelf and bin locations in a warehouse. Also, batches can be separated in product planning. If either the sub location or the batch value is not used for planning then that category is set to 1. Multiply the number of sub locations by the number of batches for each facility. Sum up the totals for the facilities used in active model. If sub locations and batches are not used in planning, the total value is the number of facilities in the active model.

APO - Planned Orders - SAP liveCache Memory PLANNEDORD

Specifics for Planned Orders - SAP liveCache Memory

The average number of planning relevant planned orders / manufacturing orders refers to all production orders that are planned and scheduled. The larger the number, the greater the Live Cache memory requirements. Also, orders that are confirmed by the backend system are no longer in the APO system. So, the number of planned and released production orders in APO may be smaller than the number of production orders in R/3.

The average number of components per manufacturing order asks for a count of the bill of material components included in each production process model.

The average number of operation steps per manufacturing order asks for the average number of operations per Production Process Model.

The average number or operations steps per operation. Each operation is composed of operation steps (activities). Activities include setup, tear down, production, and queue. Determine the average number of activities per operation used in APO planning.



The average number of alternative resources per activity can be one or more, depending on the number of resources that can perform the same activity used to produce a product. (A resource can be a production line, a work center or any other manufacturing facility.)

Determine the average number of parallel capacity requirements per operation step (activity). This can be one or more constraining resource in an operation. For example, this can be a work center and a specific tool or person, all required performing a specific operation step.

APO - Sales and Purchase Orders - SAP liveCache Memory FORECAST PURCHORD SALES TRANSFER

Specifics for Sales and Purchase Orders - SAP liveCache Memory

The average number of forecast orders used for planning asks for the number of product-location combinations, with a forecast that is released from Demand Planning to Supply Network Planning. Each product-location combination is considered one forecast order.

The average number of schedule lines per forecast order refers to the number of partitions made for each time bucket in Demand Planning. So, if the forecasts from Demand Planning are in monthly time buckets, and SNP plans in daily time buckets, then the average number of scheduled lines per monthly forecast is 30.

The average number of planning relevant purchase orders or purchase requisitions. The number of planning relevant purchase orders include only those purchase orders that are not yet filled. Those that are will be deleted from liveCache. However, until payment is completed, they will still reside in R/3. For this reason, more purchase orders often reside in the backend system than in APO.

The average number of delivery schedules per purchase order or purchase requisition asks for the number of transports required for the average purchase order.

The average number of sales orders used for planning. Those orders that are satisfied are not relevant for planning, because they are deleted from liveCache. However, they still reside in R/3, until payment for the sale is fulfilled. So, there are typically more sales orders in the backend system than in APO.

The average number of delivery schedules per sales order. Determine how many transports, on average, are required for a sales order.

Average number of transfer orders used in planning. These are internal stock transfers generated by the APO SNP planning process. This number is typically a count of vehicles generated from a Transportation Load Builder (TLB) planning run.

Average number of products per transfer order asks for a count of products that are grouped into a transfer order from a TLB planning run.



APO - Planning Run Sizing - CPU SNP HEUR

Specifics for the Planning Run Sizing - CPU

SNP heuristic: Number of stock keeping units - for example location products - planned by one heuristic planning run asks for the number of location-products planned in one planning run.

Duration of a SNP heuristic planning run is the time needed to plan for the entire time horizon during nightly batch processing. The smaller this time (in hours), the more CPU processing capacity is required.

Back to Top

Order Fulfillment

Order Fulfillment Sizing assumptions and principles

Increasingly, companies operating worldwide are forced to globalize available information in order to conduct business efficiently. Specifically, this means that information has to be made available across system boundaries as quickly as possible to provide optimized decision support. Global ATP can be used in heterogeneous system landscapes to provide required information as quickly as possible. The ATP check – also known as the availability check – represents an online search that should ensure that your company can provide the requested product at the requested time in the quantity requested by the customer.

Sizing Elements We size the memory requirements of the ATP time series in liveCache. The CPU sizing is determined by the different ATP checks.

APO - Location Products ATP-MD

Specifics for the Location Products

Master Data: We ask for the number of locations for which an ATP check is possible.

APO - Available-to-Promise Checks - CPU

Specifics for the Available-to-Promise Checks - CPU

ATP simple The ATP check – also known as the availability check – represents an online search that should ensure that your



ATP-SIMPLE

ATP-RULE

ATP-CTP

company can provide the requested product at the requested time in the quantity requested by the customer. The simple ATP check is carried out based on the ATP quantity (Available-To-Promise). The ATP quantity is calculated from stock, planned receipts (production orders, purchase orders, planned orders and so on), and planned requirements (sales orders, deliveries, reservations and so on). Rule-based ATP-requests This check is an iterative process, every check defines the next check according to the rules in the system. Example Rule I Search for an alternative location. If none is found, search for an alternative requirements method. Rule II Search for an alternative product. If none is found, Search for an alternative product in an alternative location. If none is found, Search for an alternative requirements method.

CTP ATP requests Number of Capable-to-Promise (CTP) checks. If a required product is not available in the required quantities, in Production Planning and Detailed Scheduling, you can create planned orders or purchase requisitions for the missing products with the help of CTP

Back to Top



Sizing assumptions and principles

In the ICH sizing we cover the Supplier Managed Inventory (SMI) scenario which shifts the responsibility for inventory planning from the manufacturer to the suppliers. SMI enhances demand and inventory visibility for the suppliers by using the internet and helps to manage the replenishment process. Suppliers can see the status of their parts at all plants, receive automatic alerts when inventory levels get low, and respond quickly via the web. SAP SCM immediately integrates the latest inventory and replenishment information with back-end transaction and planning systems, so all parties remain up-to-date.

Sizing Elements We size the disk and the CPU requirements in order to process and to store the messages.



APO - Location Products ICH MD

Specifics for Location Products

Master Data: We ask for the number of locations used in ICH.

APO - Message Processing with Periods - CPU ICH DS ICH PROACT

Specifics for Message Processing with Periods - CPU

ICH DS (Delivery Schedule Notification): A message from the buyer to the supplier. The delivery schedule notification contains product net demand information (“forecast demand”) and/or product release information, either for short term and/or for medium to long term product scheduling ICH PROACT (Product Activity Notification): The "Product Activity Notification" may contain inventory and time series data, such as sales, sales forecasts, promotion sales forecasts or consumptions. Inventory and time series data refer to a given product and location.

APO - Message Processing - CPU ICH ASN ICH GR

Specifics for Message Processing - CPU

ICH ASN (Advanced Shipping Notification): A message from the supplier to the buyer. The purpose of the "Dispatched Delivery Notification", also called Advance Shipping Notification, is to notify the consignee that a delivery has been planned and assigned. The task includes to communicate at the detailed product level the contents of this delivery, when the delivery is expected to arrive, and other delivery information. ICH GR (Goods Receipt Notification): A message from the buyer to the supplier. The purpose of this message is to notify the shipper that a delivery has been received and to report the status on a delivery as well as on delivery content level, i.e. on a detailed product level.

Back to Top

Integration to ECC

Sizing Elements The CPU sizing is determined by the load generated by the integration. Only the SCM system is considered in the sizing result.



Back to Top

Extended Warehouse Management

APO - Orders replicated to/from ECC - CPU PI-PROD PI-SALES PI-PURCH PI-STOCK

Specifics for Orders replicated to/from ECC

Manufacturing orders: This refers to the number of production orders transferred from/to the ECC system. The number of line items refers to the average number of components in the production order. Sales orders: This refers to the number of sales orders transferred from/to the ECC system. The number of line items refers to the average number of schedule lines in the sales orders. Purchase orders: This refers to the number of purchase orders or purchase requisitions transferred from/to the ECC system. The number of line items refers to the average number of schedule lines in the purchase order. Stock movements: This refers to the number of stock movements transferred from/to the ECC system. The number of line items is always 1. Enter 1 in the column for line items.

Extended Warehouse Management (EWM)

Definition Extended Warehouse Management (EWM) offers you flexible, automated support for processing various goods movements and for managing stocks in your warehouse complex. The system supports planned and efficient processing of all logistics processes in your warehouse.

If you manage your warehouse stocks using the application component Inventory Management (MM-IM), then you manage the material stocks based on quantity and value in several storage locations.

In contrast, EWM gives you the option of mapping your entire warehouse complex in detail in the system, down to storage bin level. Not only do you gain an overview of the entire quantity of a material in the warehouse, you can also always determine exactly where a certain material currently is in your warehouse complex. With EWM, you can optimize the use of various storage bins and stock movements, and can store together material stocks from several plants in random storage areas. Using EWM, you can control and optimize various processes in the warehouse.

EWM is completely integrated into Inventory Management and Delivery Processing. Business processes, which you trigger in other application components, lead to physical goods movements in your warehouse. You organize, control, and monitor these goods movements using EWM.

Note



Back to Top

Extended Warehouse Management - Inbound

In the Quick Sizer we distinguish between inbound and outbound delivery processes.

EWM Inbound Delivery Process

The inbound delivery process consists of several steps:

Creation of inbound delivery (IEWM-DLV) Optional: Creation and confirmation of unloading warehouse tasks (IEWM-UNTSK, IEWM-CONF) Creation of putaway warehouse tasks (without preceding unloading task; IEWM-PATSK) Confirmation of putaway warehouse tasks (IEWM-PACON) Optional: Change of resource in putaway (IEWM-RESPA) Optional: Deconsolidation ((un)packing and creation of follow-up move warehouse task for putaway; IEWM-DECON) Optional: Move warehouse task (from deconsolidation station to final bin; IEWM-MOVE) Optional: Change of resource in movement from deconsolidation packing to final bin (IEWM-RESFI)

EWM - Mandatory Inbound Step - Creation of Inbound Delivery IEWM-DLV

Specifics

Objects: Number of delivery documents Items: Average number of items per delivery

EWM - Optional Inbound Steps - Creation and Confirmation of Unloading Warehouse Tasks IEWM-UNTSK, IEWM-CONF

Specifics

Wareh. Tasks: Number of unloading warehouse tasks Assumption: 100% RF

EWM - Mandatory Inbound Step - Creation of Putaway Warehouse Tasks (Without Preceding Unloading Task) IEWM-PATSK

Specifics

Wareh. Tasks: Number of putaway warehouse tasks without preceding unloading warehouse task



EWM - Mandatory Inbound Step - Confirmation of Putaway Warehouse Tasks IEWM-PACON

Specifics

Wareh. Tasks: Number of putaway warehouse tasks % RF: Percentage of radio frequency based putaway confirmation

EWM - Optional Inbound Step - Change of Resource in Putaway IEWM-RESPA

Specifics

Wareh. Tasks: Number of warehouse tasks with resource changes RsChg: Average number of resource changes per warehouse task Assumption: 100% RF

EWM - Optional Inbound Step - Deconsolidation ((Un)Packing and Creation of Follow-Up Move Warehouse Task for Putaway) IEWM-DECON

Specifics

HUs: Number of highest-level handling units (HUs) after deconsolidation Items: Average number of putaway items packed per highest-level HU Unpack. items: Number of unpacked items

EWM - Optional Inbound Step - Move Warehouse Task (From Deconsolidation Station to Final Bin) IEWM-MOVE

Specifics

Wareh. Tasks: Number of warehouse tasks Assumption: 100% RF

EWM - Optional Inbound Step - Change of Resource in Movement from Deconsolidation Packing to Final Bin IEWM-RESFI

Specifics


EWM - Inbound Delivery Process

Find this example to see how the fields could be filled-in.



Back to Top

Extended Warehouse Management - Outbound

Example During the peak hour the following process steps are executed in the system:

100 inbound deliveries with four items on average are created based on messages received from ERP. Each item is packed in two highest-level HUs. Enter for sizing element IEWM-DLV: objects = 100 deliveries , items = 4 items per delivery 50% make use of system based unloading with unloading warehouse tasks for the highest-level HUs. Enter for sizing elements IEWM-UNTSK and IEWM-CONF: wareh. tasks = 400 (50% * 100 * 4 * 2) For each received HU a (first) warehouse task is processed, either to deconsolidation station or for direct putaway (in case the reveived HUs are applicable for storage). Bundling of these warehouse tasks is always a single warehouse task per warehouse order. 30% of received HUs are applicable for storage and are not deconsolidated. Confirmation of these 30% warehouse tasks is done by GUI (not RF) and the putaway is done with a single resource. Enter for sizing element IEWM-PACON: wareh. tasks = 800 ( 100 deliveries * 8 highest-level HUs), % RF = 70% RF based confirmation Enter for sizing element IEWM-PATSK: wareh. tasks = 400 (800 – 400) The move warehouse tasks going to deconsolidation are processed with one resource change. Enter for sizing element IEWM-RESPA: wareh. tasks = 560 ( 70% * 800 highest-level HUs), rschg = 1 (one resource change) 560 received highest-level HUs are deconsolidated into 280 putaway HUs, each containing a single product. Enter for sizing element IEWM-DECON: HUs = 280 putaway HUs after deconsolidation, items = 1 putaway item per HU, unpack. items = 0 The 280 HUs created in deconsolidation are applicable for storage, so no split of those HUs into multiple putaway warehouse tasks per HU is done. Enter for sizing element IEWM-MOVE: wareh. tasks = 280 HU warehouse tasks Put-away of those 280 HUs needs two times a resource change (for example those HUs are going to high rack). Enter for sizing element IEWM-RESFI: wareh. tasks = 280 ( 280 HUs) , rschg = 2 (two resource changes)

EWM Outbound Delivery Process

Definition The outbound delivery process consists of several steps:

Creation of outbound delivery order (OEWM-DLV) Creation of picking warehouse tasks (OEWM-PICK) Confirmation of picking warehouse tasks (OEWM-CONF) Optional: Move warehouse task (from picking resource to picking destination bin, OEWM-DEST) Optional: Change of resource in picking (OEWM-RESPI) Optional: Packing and creation of follow-up move warehouse task (OEWM-PACK) Optional: Move warehouse task (from packing station to staging area (OEWM-STAGE)



Optional: Change of resource in staging (OEWM-RESST) Optional: Loading warehouse task (OEWM-LOAD) Delivery based Goods Issue (OEWM-GOODS)

EWM - Mandatory Outbound Step - Creation of Outbound Delivery Order OEWM-DLV

Specifics


EWM - Mandatory Outbound Step - Creation of Picking Warehouse Tasks OEWM-PICK

Specifics

Wareh. Tasks: Number of picking warehouse tasks

EWM - Mandatory Outbound Step - Confirmation of Picking Warehouse Tasks OEWM-CONF

Specifics

Wareh. Tasks: Number of picking warehouse tasks %RF: Percentage of radio frequency based picking confirmation

EWM - Optional Outbound Step - Move Warehouse Task (From Picking Resource to Picking Destination Bin) OEWM-DEST

Specifics

Wareh. Tasks: Number of warehouse tasks from resource to picking destination Assumption: 100% RF

EWM - Optional Outbound Step - Change of Resource in Picking OEWM-RESPI

Specifics


EWM - Optional Outbound Step - Packing and Creation of Follow-Up Move

Specifics

HUs: Number of highest-level HUs created in packing Items: Average number of pick items packed per ship highest-level HU



Warehouse Task OEWM-PACK

EWM - Optional Outbound Step - Move Warehouse Task (From Packing Station to Staging Area) OEWM-STAGE

Specifics

Wareh. Tasks: Number of staging original warehouse tasks Assumption: 100% RF

EWM - Optional Outbound Step - Change of Resource in Staging OEWM-RESST

Specifics


EWM - Optional Outbound Step - Loading Warehouse Task OEWM-LOAD

Specifics

Wareh. Tasks: Number of loading warehouse tasks Assumption: 100% RF

EWM - Mandatory Outbound Step - Delivery based Goods Issue OEWM-GOODS

Specifics


EWM - Simple Outbound Delivery Process Example


During the peak hour the following process steps are executed in the system:

500 outbound delivery orders with two items on average are created based on messages received from ERP. Enter for sizing elements OEWM-DLV and OEWM-GOODS: objects = 500 deliveries , items = 2 items per delivery Each delivery item is picked with a single picking warehouse task. Average size of a warehouse order is one picking warehouse task. A full pallet is picked, pallets play the role of picking and shipping HU: Enter for sizing element OEWM-PICK: wareh. tasks = 1000 pick warehouse tasks Enter for sizig element OEWM-CONF: wareh. tasks = 1000 pick warehouse tasks , % RF = 100% RF The full pallets are moved to staging area, including on average two resource changes (the pick resource plus two others take part). Enter for sizing element OEWM-DEST: wareh. tasks = 1000 HU movement warehouse tasks Enter for sizing element OEWM-RESPI: wareh. tasks = 1000 , rschg = 2 (two resource changes) Enter for sizing element OEWM-PACK: HUs = 0 (no repacking), items = 0 Enter for sizing element OEWM-STAGE: wareh. tasks = 0



Back to Top

Supplier Relationship Management

Enter for sizing element OEWM-RESST: wareh. tasks = 0, rschg = 0 100% make use of system based loading with loading warehouse tasks. Enter for sizing element OEWM-LOAD: wareh. tasks = 1000 HU loading warehouse tasks Goods issue is performed for the 500 deliveries.

EWM - Highly Complex Outbound Delivery Process Example


During the peak hour the following process steps are executed in the system:

100 outbound delivery orders with four items on average are created based on messages received from ERP. Enter for sizing elements OEWM-DLV and OEWM-GOODS: objects = 100 deliveries , items = 4 items per delivery On average, each delivery item is picked via two picking warehouse tasks (whole delivery quantity can not be managed with a single warehouse task). Average size of a warehouse order is five picking warehouse tasks. All five picking items are picked into a pick HU with RF (->160 pick HUs are created). Enter for sizing element OEWM-PICK: wareh. tasks = 800 pick warehouse tasks Enter for sizig element OEWM-CONF: wareh. tasks = 800 pick warehouse tasks , % RF = 100% RF Pick HUs are beeing moved by pick resource (small fork lift). 40% of them are dropt to be overtaken by one other resource which moves them to packing station, the 60% rest is directly moved to packing station. Enter for sizing element OEWM-DEST: wareh. tasks = 160 HU movement warehouse tasks Enter for sizing element OEWM-RESPI: wareh. tasks = 64 ( 40% * 160) , rschg = 1 (one resource change) During RF based packing, the pick HUs with five items each (cross delivery ! ) are repacked into shipping HUs with four items. Enter for sizing element OEWM-PACK: HUs = 100 HUs, items = 8 ( 4 delivery items * 2 picking warehouse tasks per delivery item) Shipping HUs are beeing moved to staging area by a single resource (without resource changes). Enter for sizing element OEWM-STAGE: wareh. tasks = 100 HU movement warehouse tasks Enter for sizing element OEWM-RESST: rschg = 0 (no resource change) 30% make use of system based loading with loading warehouse tasks. Enter for sizing element OEWM-LOAD: wareh. tasks = 30 HU loading warehouse tasks (30% of objects of sizing element OEWM-STAGE) Goods issue is performed for the 100 deliveries.

SAP Supplier Relationship Management (SAP

Definition SAP Supplier Relationship Management provides you with innovative methods to coordinate your business processes with your key suppliers and make them more effective. SAP SRM enables you to optimize your procurement strategy, to work



SRM) more effectively with your vendor pool, and thus to gain long-term benefits from all your vendor relationships.

With SAP SRM you can examine and forecast purchasing behavior, shorten procurement cycles, and work with your partners in real time. This allows you to develop long-term relationships with all those vendors that have proved themselves to be reliable partners.

The efficient processes in SAP SRM enable you to cut down your procurement expenses and to work more intensively with more vendors than ever before.

SAP Supplier Relationship Management Server

Definition The SAP Supplier Relationship Management Server (SAP SRM Server) includes both SAP Enterprise Buyer and SAP Bidding Engine.

SAP Enterprise Buyer is based on SAP NetWeaver Application Server (AS). It is an application and database instance installation released on several database and operating system platforms (see SAP Service Marketplace at service.sap.com/platforms -> Product Availability Matrix. It enables easy, full-cycle, inter-enterprise procurement. With it you can:

Create and process requirement requests, purchase orders, and reservations with or without electronic catalogs Approve and reject purchases Receive and enter service information at the desktop Use status, invoicing, and reporting functions

SAP Enterprise Buyer is the procurement and sourcing system that is the central part of any SAP SRM scenario. It empowers employees with self-service procurement, enables centralized direct procurement and provides the professional purchaser with tools to make the right sourcing decisions.

The SAP SRM solution requires the SAP Enterprise Buyer system for downloading materials data and (optionally)using the Business Intelligence capabilities offered by SAPNetWeaver.

Purchasers can use SAP Bidding Engine to create and process bid invitations, and bidders can use SAP Bidding Engine to submit bids in response to these bid invitations. Both purchasers and bidders can use reverse auction functions in a separate Live Auction application. Purchasers can define rules pertaining to bidding and bidders can submit bids in real time.

Note The sizing result for the SAP SRM Server includes sizing of SAP ITS.

Contract Management CTRCT-USER, SRM-CNTRCT

Description The Contract Management business scenario allows you to create, process, and monitor purchasing contracts and global outline agreements (GOA). It also provides a means to renegotiate existing contracts directly with the vendor or by creating a bid invitation. A contract can be automatically assigned as a source of supply or displayed as a possible



selection.

A strategic purchaser creates a contract or a GOA whenever a long-term relationship is anticipated and the vendor can be considered as a source of supply. Contract management enables purchasers from various parts of the company at different locations to take advantage of the terms of globally-negotiated contracts for specific product categories.

You can provide users with specific levels of authorization to contracts and GOAs, and also categorize these documents as confidential. You can distribute a GOA to the release-authorized purchasing organizations and these organizations can use the contracts and scheduling agreements created from the distributed GOA. You can use hierarchies to organize, structure, display, and search for your contracts.

If you use SAP Business Intelligence (SAP BI), you can view various consolidated reports of contract management. For example, you can view the aggregated value released against all the contracts in a contract hierarchy.

Typical tasks for the Contract Management business scenario include:

A strategic purchaser negotiates a long-term contract with a vendor to deliver goods of a specific commodity.

A strategic purchaser monitors contract compliance.

An operational purchaser searches for applicable contracts within a central contract database and puts contracts into effect.

The Quick Sizer scenario includes the business objects Purchaser Order and Contract.

Plan-Driven Procurement PLAN-USER, SRM-PLAN

Definition Plan-Driven Procurement automates and streamlines ordering processes for regularly needed core materials. You can use this business scenario to procure requirements for materials that have been generated in systems other than SAP Supplier Relationship Management (external systems). By integrating the SRM System with planning, design, and maintenance systems, you can accelerate your procurement and integrate the operational procurement with your Supply Chain Management solution. The business scenario supports third-party order processing, a special kind of procurement. Here the product goes directly from the vendor to the customer of the purchasing company. The purchase order to the vendor contains the necessary information for this.

You can set up the business scenario in such a way as to link one or more Materials Management systems (SAP-MM) with Materials Requirements Planning (SAP-PP-MRP) to one or more vendor systems (SAP Supplier Self-Services).

You can continue to plan requirements in SAP Advanced Planner and Optimizer (SAP APO).

Examples of tasks for Plan-Driven Procurement include:

A manufacturing company with many disparate planning systems consolidates all procurement (direct and indirect) in one e-procurement hub.

A company performing planned and unplanned maintenance centralizes procurement activities in a single application.

The Quick Sizer scenario includes the business objects Shopping Cart, Purchaser Order, Purchase Order Confirmation,



Confirmation and Invoice.

Self-Service

Classic Procurement CLASSIC-U, CLASSIC

Definition When using Self-Service (Indirect) Classic Procurement solution, employees use a self-service application to select items such as office material, for example, from a catalog and add them to a shopping cart in the EBP system. When the shopping process has finished, the shopping cart is transferred to an SAP R/3 Material Management (SAP MM) backend system where it is further processed in the form of a purchase order.

Note Note that you must account for the orders processed in MM and possible follow-on documents separately so that the backend system is sized properly. The backend systems being in these cases both MM and FI backend systems.

Self-Service

Extended Classic Procurement & Standalone Procurement EXT-USER, EXTENDED

Definition Both scenarios, Extended Classic Procurement and Standalone Procurement, can be sized with the same methodology.

Extended Classic Procurement

Whereas in the Classic Procurement scenario, all materials management takes place in the backend system, with this scenario the shopping cart and purchase order are created locally. If the data in the shopping cart is insufficient to generate a complete purchase order, the data is supplemented manually within Enterprise Buyer before being transferred to the backend system. The purchase order in Enterprise Buyer is the leading purchase order. The version that is transferred to the backend is not an exact copy, rather it is a much leaner version of the leading purchase order, a read-only copy. This copy supplies the reference needed for the creation of goods receipts, service entry sheets, and invoices in the backend system. Confirmations and invoices can also be pre-entered in Enterprise Buyer.

Standalone Procurement

This scenario handles the entire procurement process in Enterprise Buyer: The shopping cart and follow-on documents are created locally. You have no materials management in your ERP system and are using the Materials Management functions in the Enterprise Buyer system for all procurement. Accounting processes (incl. FI, CO and AM) must still be handled by a backend system. All validations and approvals are handled directly within Enterprise Buyer rather than in a backend system. Migration tools are provided to bring materials management data from SAP backend systems into the application product master.

Note

If you want to size both scenarios, just add the figures or, if they differ to a great extent, create a new sizing project Note that you must account for any follow-on documents or objects processed in the backend system separately. The backend systems being in these cases both MM and FI backend systems. The Standalone Scenario can be deployed using single or multiple FI backend systems. Or alternatively, in the case of a marketplace scenario no FI backend system is necessary.



Back to Top

Global Trade Services

Strategic Sourcing SOURCE-USER, SOURCING

Definition You can use this business scenario to process all your requirements and optimize your source of supply for each individual item. You can identify cost-saving opportunities and evaluate suppliers’ ability to provide materials and services at low cost, high quality, and on schedule. Once you have determined the best source of supply for your requirements, you can collaborate in project teams both internally and with your suppliers to establish on-going relationships based on contracts and global outline agreements.

Sample tasks for the Strategic Sourcing business scenario include:

A company locates different suppliers for upcoming new product development.

A financial institution maintains lists of suppliers for different maintenance, repairs, and operation (MRO) materials.

A consulting company reduces its supplier base by aggregating airline tickets to one airline.

The Quick Sizer scenario includes the business objects Bid Invitation/Auction, Bidders and Quotation.

Service Procurement SERVC-USER, SRM-SERVIC

Definition You can use this business scenario to cover the entire service procurement process. Before ordering external staff or services, you can send a request to one or more suppliers for detailed information on a specific service or the availability of individual service agents, for example. After receiving the suppliers’ responses and accepting one of these bids, the corresponding purchase order is automatically created. Next, time and expenses have to be entered into the system and, finally, the invoice is created.

You can integrate your suppliers into the procurement process by connecting a supplier system like Supplier Self-Services to your procurement system. In this way, the service agents can enter services performed and create invoices for these services. You have to approve all documents created by your suppliers and you always retain a complete overview of all business processes.

The Quick Sizer scenario includes the business objects Shopping Cart, Purchaser Order, Purchase Order Confirmation, Confirmation and Invoice.

Note: If you also want to size sub-items, simply add them to the number of items and insert this number in column "items".



Global Trade Services (SAP GTS) Compliance and Customs Management GTS-CUMA, GTS-SLS, GTS-FI, GTS-BP, GTS-MAT, GTS-SCREEN

Definition SAP Global Trade Services (SAP GTS) automates global trade processes and enables you to manage large numbers of business partners and material as well as high volumes of documents, while also helping you to comply with changing legal regulations. It facilitates foreign trade by providing you with the tools you require to respond to governments modernizing their systems and communicating electronically with businesses.

SAP GTS supports international trade compliance issues in three primary areas:

Sanctioned party list (SPL) screening Import/export control Embargo checking

SAP GTS also supports automated and standardized customs processes including, for example, electronic communication with the customs authorities. It speeds up the release of goods by the customs authorities in the following areas:

Import processing Export processing Transit procedure

The following are the technical elements used for SAP GTS sizing and their explanation:

GTS-CUMA – GTS Customs Documents (Import/Export Customs Declarations and Customs Shipments, Transit Documents) GTS-SLS – GTS Compliance Documents (Sales Orders, Deliveries, Purchase Orders) GTS-FI - Screening of payment (Sanctioned Party List Screening for Financial Accounting) Due to tighter control measures and legal regulations implemented by the European Union on foreign payment transactions, it is necessary for companies that operate on a global level to provide evidence of checks performed on incoming and outgoing payments. This involves checking business partners in accounting transactions against published sanctioned party lists. Your company can insure that sanctioned persons, groups and organizations are recognized in advance of payment transactions taking place, and, as a result, prevent transactions being performed. These sanctioned parties are published and updated on a regular basis in different countries and by different organizations, and may contain, in some cases, the same sanctioned parties. You should enter the number of FI payment documents and the average number of invoice line items you plan to screen during automatic transactions (F110 and F111) and during manual payments with printout (FBZ4). Technically, the number of entries in FI database table REGUH can give you a guideline for the number of payment documents whereas the number of entries in FI database table REGUP can help to derive the average number of invoice items. GTS-BP – Business Partners Master data (Vendors, Customers, Employees, etc) GTS-MAT – GTS materials GTS-SCREEN – Periodic GTS screenings (B1, B2, C1, C2)

All the above are to be used considering annual volumes by using the Average (rows with A -Y after the technical



description) or Peak (row with P-P after the technical description) sizing methods, excepting for GTS-SCREEN, which is explained in more detail below.

Note for GTS Business Partner & Documents Screening (GTS-SCREEN) The column "documents" refers to the B2 (Periodic) and C2 (SPL update) scenarios, which check document addresses.

B2 Scenario With the B2 scenario you can check periodically addresses in documents which have already been checked. Therefore, from a business perspective, this scenario is to be run only when GTS is first implemented to check on documents which have already been processed either manually or if you were using a different vendor software. To do this, you will have first to mass transfer the documents and then run the B2 scenario. Since it is recommended to transfer the documents and run the scenario BEFORE GTS is live and it is to be run only once, for sizing purposes, you should run a separate calculation with the quick sizer ONLY with the number of documents in GTS-SCREEN which you have mass transferred previously. This will give you a number of SAPS which should be required for this process, since there are no other processes consuming resources at the same time. Notice that since the documents have been already processed (and probably shipped), this B2 scenario is run for purely informative purposes, as you cannot take any logistic action on the documents. Also notice that there will be audit trail records available to be checked in case of an audit. C2 Scenario With the C2 scenario you can check addresses in documents which have already been checked when there has been a recent SPL data update. Therefore, from a business perspective, this scenario is to be run only when an SPL update has been implemented to check on documents which have already been processed. Have in mind that since there is new SPL data, you may get new SPL matches in documents that did not get any matches before, and that there will be an audit trail record which can be checked later in case of an audit. Therefore, you should consider running this scenario only if: 1) The documents being checked have not been shipped yet, OR 2) There is a clear understanding for the authorities that you have no logistic control over the documents being re-checked, since they are already shipped. Given that SPL updates are normally issued monthly (this is just a rough guideline which depends on your data provider), the recommended number of documents to be used for sizing purposes is one-twelfth (1 /12) of the yearly number of documents being considered for GTS Compliance Management (GTS-SLS at standard throughput sizing)

Global Trade Services (SAP GTS) Risk Management Preference Processing

Definition SAP Risk Management - Preference Processing supports exporters in indicating goods for preferential tariff treatment. SAP Risk Management – Preference Processing assists exporters in determining whether all the prerequisites for preferential customs duty rates have been fulfilled. Exporters can obtain a competitive advantage over competitors due to reduced or zero rates of customs duty on goods with preferential origin for the importing customer. For SAP Risk Management the Scenarios GTS-BP and GTS-MAT are to be included in the Sizing projects as common master data is used. For the purpose



Back to Top

SAP for Banking - Analytical Banking

GTS-RI-BOM, GTS-RI-MM, GTS-RI-SO, GTS-RI-INV, GTS-RI-SOL, GTS-RI-AGG, GTS-RI-PRD, GTS-RI-ISS

of Sizing it is assumed that one preference agreement is set up for preference processing.

SAP GTS supports preference processing issues in the following main areas:

Master data transferring - Bills of Material, Procurement Indicator and Price transfers. Transactional data from feeder system- Purchase Orders, Sales Orders, Invoices. BOM Preference Determination Long Term Vendor Declarations (LTVDs) processes - Solicitation, aggregation, issuing.

The following are the technical elements used for GTS Risk Management sizing and their short text explanation:

GTS-RI-BOM – Bill of material transfer For transferring Bills of Materials (BOMs). Here what you have to enter is the sum of the number of items (including the top material itself of all the BOMs to be transferred. That means that for a one level BOM with five subcomponents the number to be entered is six (five subcomponents + one top material). GTS-RI-MM – Worklist for requesting long-term vendor declarations based on MM Purchase Orders and MM Goods Receipts For MM Documents (Purchase Orders and Goods Receipts) being sent to GTS. In case the Purchase Orders are also to be screened with SAP GTS Compliance, you should make a separate entry in GTS-SLS. GTS-RI-SO – Preference status determination in sales process (SD SO) For Sales Orders Documents being sent to GTS. In case the Sales Orders are also to be screened with SAP GTS Compliance, you should make a separate entry in GTS-SLS. GTS-RI-INV – Worklist for issuing long-term vendor declarations based on SD Invoices For Invoice Documents being sent to GTS. In case the Invoice Documents are also to be processed within SAP GTS Customs, you should make a separate entry in GTS-CUMA. GTS-RI-SOL – Request of long-term vendor declaration For the solicitation of long-term vendor declarations. GTS-RI-AGG – Aggregation of long-term vendor declarations For the preference status aggregation into the GTS product master based on long-term vendor declarations. GTS-RI-PRD – Preference determination of bills of material For the preference determination of in house production according to Bills of Materials (BOMs). GTS-RI-ISS – Issuing long-term vendor declarations For issuing and revocation of long-term vendor declarations.

SAP Basel II Definition



Solution SAP Basel II provides a standard platform for accurate calculations of credit risk and capital adequacy involving all types of assets and calculation methods. The application's flexible structure and open reporting functions help banks improve internal risk management and meet external risk-reporting requirements. Part of the SAP for Banking analytical solutions, SAP Basel II gives banks broad, long-term support for regulatory compliance by integrating information for all finance and risk-related business processes.

The most prominent business processes of this solution handle mass data. The main process in the SAP Basel II solution is divided into the following steps:

1st step: Upload of the financial data from the front office systems to the source data layer (SDL; can be done daily) 2nd step: Execution of the pre-run or general method (optional; no sizing available) 3rd step: Execution of the credit risk exposure calculation (can be done on a daily basis) 4th step: Historization run (is normally not done daily; no sizing available) 5th step: Data extraction to NetWeaver BI (can be done daily) 6th step: Regulatory reporting interface (is normally not done every day)

Specifics for CPU Sizing For the CPU sizing only the peak values are taken into account. For each step you have to specify the start and end time. In addition for each step you have to specify the number of objects that have to be processed. Specifics for Disk Sizing The disk sizing is done by the average sizing elements only. We neglect the master data here due to the fact that usually the transactional data will dominate the disk sizing.

Note The sizing of the Bank Analyzer solution is quite complicated because of the complex business structure of the Basel II process, but also because of the very generic architecture of the Bank Analyzer. The structure of all mass data, business objects, result data, and so on strongly depends on the customizing in the customer system. Also the runtime of the methods working on these objects strongly depend on the way customers generate their particular modules. As a consequence, the measured resource consumptions in the various tests can only provide an indication of the hardware resources that may be required to fulfill the needed throughput.

Upload of Data (1st step) FT/FI, POSITION

Definition Upload of the financial data from the front office systems to the source data layer (SDL): For the calculation of the risk weighted assets (RWA) the customer needs to have the current data in the SDL. In the first step, the financial data (position data, business partner data, new transactions etc.) has to be uploaded from the front office systems etc. into the SDL. Specifics for Upload of Data

FT/FI Enter the number of new or changed business transactions or instruments



Position Enter the number of changed positions

Credit Exposure Run (3rd step) CE-RUN

Definition This business process calculates the risk weighted assets (RWA) in accordance with the Basel II paper and meets the requirements for regulatory reporting. The system selects the relevant data from the source data layer (SDL) and builds bundles for the transactions. Then the data for all the transactions and relevant partial objects in the bundle is read from the Operational Data Store (ODS) and enriched for the RWA calculation.

Note the following for the main run:

The system builds the basis for the calculation process during pre-processing. Here all necessary data is collected, enriched and provided for further processing. Netting is not relevant for the performance test; the Exposure at default (EAD) calculation base is derived based on the calculation approach for each financial transaction. The system determines the risk parameters necessary for the RWA calculation. The regulatory capital is calculated on the basis of optimized (capital saving) distribution of collaterals towards all claims.

The results of the calculation process are EAD, RWAs, expected losses and regulatory capital. These results are stored in the result layer (RDL).

For the performance of the calculation process it is important how many claims and collaterals are in the bundle as the number of claims and collaterals influences the time needed for the selection of the bundle, the collateral assignment and the number of results stored in the RDL (collaterized and uncollaterized part; external line, drawing, free line).

Specifics for Credit Exposure Run For each credit exposure run specify not only the total number of financial transactions or instruments to be processed, but also the number of objects that are relevant for effective maturity. These objects will strongly influence the runtimes, because the cash flow has to be constructed or loaded. Therefore we need to know the average number of payments on the cash flow that have to be constructed. If the customer uses the retail pre-run you should handle this just like an additional credit exposure run.

Objects Number of collaterals and claims: Enter number of collaterals and claims Lines: Enter number of free lines Months Effective maturity Cash flow



Back to Top

SAP for Banking - Core Banking

Disclosure and Reporting (5th step) DR-RUN

Definition In this step data from the source data layer (SDL), the results of the calculation process stored in the result data layer (RDL) and other SAP systems or non SAP systems could be extracted into the Business Information Warehouse. In the Business Information Warehouse there are more than 30 predefined Basel II reports covering the Pillar 3 requirements for Basel II.

Specifics for Disclosure and Reporting Run For disclosure and reporting (D&R) the sizing may strongly depend on the data that has to be read to enrich the RDL results of the credit exposure run. We assume that only the complex key figure of the contract has to be read, not the business partner. All information of the business partner was written into the RDL during the credit exposure run.

Objects Number of level 2 results: Enter the number of level 2 results

Regulatory Reporting Interface (6th step) REG-REPORT

Definition Regulatory reporting consists of two parts:

Writing enriched data to the cluster Creating of a file on a file system

Sizing considers only the first one.

Core Banking Definition Core banking is a key functional area of SAP for Banking that provides a customer-focused transaction processing environment. Core banking enables high-performance and cost-efficient processing for financial transactions and supports development and introduction of new products and services using a range of distribution channels.

Mass Posting, Single Posting,

Definition Processing of payment items embraces the validation of the payment items, its posting to the dedicated account, and



Posting FS-BK-MPST, FS-BK-SPST, FS-BK-PST

subsequently the update of balances for the account.

Specifics for Mass Posting, Single Posting, Posting Enter the number of payment items per peak period.

Statement FS-BK-STAT

Definition The on request bank statement process embraces the selection of all data (postings, balances, settlement details) that are necessary to provide a bank statement data of an account.

Specifics for Statement Enter the number of bank statements that are requested in a peak period.

Settlement FS-BK-SETT

Definition The settlement process embraces the calculation of interest and periodic charges for an account and the posting of the results to the settled or a deviate account.

Specifics for Settlement Enter ther number of accounts to be setlled per peak period.

Correspondence FS-BK-CORR

Definition The correspondence process embraces the creation of all types of customer correspondences (e.g. bank statements, correspondences for contract changes, correpondences for special posting events). This correspondence is started asynchronously e.g. once every day.

Specifics for Correspondence Enter the number of created documents that have to be processed within a peak period.

Accruals FS-BK-ACCR

Definition The accrual process embraces the calculation of interest and periodic charges for an account. Results are transferred to General Ledger in a subsequent process for the purpose of accrual.

Specifics for Accruals Enter the number of accounts to be accrued per peak period.



Back to Top

Insurance

CMS Monitor FS-BK-CMS

Definition Collateral management monitoring run Specifics for Credit Exposure Run

Collateral agreement An agreement on the institution's own entitlement and third-party entitlements to the asset, on the calculation of the collateral value and on the purpose of declaration. Enter the number of collateral agreements per peak period. Loans Enter the number of loans per peak period.

SAP Financial Services - Collection & Disbursement

Subledger Document & Payment Document SUBLEDGER

Definition A subledger document consists of one header with 1...n Business Partner items (e.g. receivables, payables) and 1..m General Ledger items. A payment document is a subledger document which represents a payment from/to the customer. In the most common case the payment documents are directly cleared against open items and point to the Business Partner item of the cleared item. Therefore payment documents normally don't create physical entries for their Business Partner items in the database.

Enter the total number of subledger documents to be created per year in the field "Postings", enter the total number of payment documents to be created per year in the field "Payments". Specify additionally the average number of Business Partner items per posting document and the average number of General Ledger items per posting and payment document.

Invoice and Definition



Account Statement ACC-STAT

Note: We assume that the invoices and account statements are printed.

Dunning DUNN

Definition The number of dunning notices that are produced. Note: We assume that the notices are printed. The calculation includes the dunning proposal run, the dunning activity run, and the print run for the dunning procedures.

Insurance Object INS-INV

Definition There are several different kinds of insurance objects. The principal objects used are contract accounts and claims. You can assign several insurance objects to a contract account.

Broker BROK-ITEM

Definition The intermediary (for example broker) between the insurer and the insured. The insurance settlement process can be carried out either directly with the customer or via the intermediary (hereafter called broker). In Financial Services - Collections & Disbursement there are two different scenarios:

Scenario 1: Communication and payment take place directly between the insurance company and the insured. In this scenario the typical master record model is set up as follows: 1 business partner has 1...n accounts, to which 1...n insurance objects are assigned. Payments and correspondences are based on the CD documents posted to the customer accounts. Scenario 2: In the scenarios that involve brokers, the master data does not only consist of the customer master data and the postings, but also of the "broker master data". For the broker additional master data is created: Business Partner (Intermediary, Broker) --> Contract Account (Broker Account) --> Insurance Object (Broker Contract). On the insurance contract level it is possible to specify and control for specific periods of time, whether the broker is also responsible for collections and disbursements. Broker collections offers an additional function called broker report. When a broker report is posted, the relevant items are transferred to the broker account, via a transfer posting. In addition, the broker may also have a commission account. The commissions are also posted to the broker account together with the broker report. In the end only the balance is settled with the broker, which, compared to Scenario 1, considerably reduces the number of payment transactions, because a broker is usually responsible for several customers at once.

Relevant is the number of broker report items which are reported by all brokers during the period. This includes all reported premiums, claims, commission and cost items.



Payment Lot Item CD-PL

Definition A function which enters the bank files of self-payers into the system and creates payment documents that are cleared against open items.

Payment Plan Transfer & Payment Plan Execution PAY-EXE PAY-TRANS

Definition During a payment plan transfer, the transaction data is transferred from the operational systems to the payment plan store of the FS-CD, and this is followed by the payment plan execution. The number of open items is relevant for sizing.

There can be different scenarios for this process:

In the simplest and most common scenario, a transferred Payment Plan line item corresponds to exactly one open item. In the more complex scenario, a payment plan item is divided into several partial receivables. One payment plan item can lead to the creation of several open items. For example, under a payment plan fixed payments have to be made for the next 12 months. The payment plan is stored at the insurance object level and controls the creation of open items from the payment plan line items.

Payment Run PAY-RUN

Definition The process during which for all open items which are selected by the payment run, payment documents are created and cleared against the due items. The data which is created with the payment run is also the bases for the creation of the payment media (e.g. bank files). Enter the number of open items.

Note: Objects in highload phase To account for payment runs during the highload phase do not simply enter the number of open posts to be balanced. Relevant is the number of all open items in the database, this includes also those open items which are not cleared by the payment run.

Example In the payment run those items are balanced that participate in the automatic debiting process. In addition, you have to include the number of open posts occasioned by individual debiting. This number can be considerably larger than the number of items to be balanced in general.

Account Balance Display ACC-BAL

Definition Enter the highest number of account balance displays that occur during the highest system load phase.



Back to Top

Retail

Retail Definition The Retail system is a variation of SAP Standard code which is tailored to fit the volumes and processes which are specific to a Retail functionality. Instead of dealing with materials and warehouses, this deals with locations/stores, articles and distribution centers and is engineered to handle the high potential volumes of input data representing the point-of-sale (POS) data collected at a register. There are six basic processes dealt with from a sizing viewpoint and these represent the key processes in the daily cycle of a retail operation.

Retail in the Quick Sizer

Note for the Retail Questionnaire within the Quick Sizer This questionnaire contains input fields which must be filled with the results you get with the help of the retail sizing questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecast and Replenishment, Sizing SAP POS Data Management) which reside on the Service Marketplace: http://service.sap.com/sizing -> Sizing Guidelines -> Solutions & Platform

Standard Background Sizing - Disk R-MRP, R-ALLOCAT, R-PHY-INV, R-PROMOT, R-VEND-INV

Specifics for Standard Background Sizing - Disk

MRP for retail (R-MRP) Basically for purchase requisitions created out of replenishment. (Table EBAN) Allocation for retail (R-ALLOCAT) Allocation tables are used in retail to determine how articles will be distributed to stores.(Tables AUKO, AUPO) Physical inventory for retail (R-PHY-INV) One major process in retail is the maintenance of accurate store and distribution center (DC) inventory. Physical counts are commonplace and frequent, hence increase in disk needs. (Tables IKPF, ISEG) Promotions for retail (R-PROMOT) hold the appropriate data for maintaining promotions in the system before processing through outbound to store level. (Tables WAKH, WAKP) Vendor invoice for retail (R-VEND-INV) Invoice data to complete cycle of DC activity in replenishment. (Tables WBRK, WBRP, WBPA, WBRF) In the simplest and most common scenario, a transferred Payment Plan line item corresponds to exactly one open item.



Please enter the number of objects and sub-items and the number of months that this data stay on the database.

Comments Retail environment puts heavy load on the tables listed above and they are considered separately for proper disk sizing.

Results from Sizings for Aggregation in Quick Sizer R-FR,

R-POS-DM, R-POS-DL, R-MASTER

Definition As mentioned above, this table contains input fields which must be filled with the results you get with the help of the retail sizing questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecast and Replenishment, Sizing SAP POS Data Management) which reside on the Service Marketplace: http://service.sap.com/sizing -> Sizing Guidelines -> Solutions & Platform

Specifics for this table

Forecast & Replenishment (R-FR) When sizing for a forecast and replenishment system, the results are expressed in SAPS required at the database and server levels for peak processing time, and the disk requirements anticipated with consideration for archiving plans. Those results should be entered in this section in the appropriate columns. Please ensure that peak timeframes are entered to ensure overall peak CPU considerations. Please enter the results you get if you follow the instructions within the sizing guideline "Sizing Forecast & Replenishment" in the corresponding columns SAPS (DB, ABAP, JAVA), memory (DB, ABAP, JAVA), and disk. Point Of Sale Data Management (R-POS-DM) POS DM is an add-on to BI. As such, the sizing of POS DM is considered as a delta-sizing of a BI-system. The sizing of POS DM considers three critical steps:

1. Non-aggregated sales data is sent to POS DM and stored in the TLOG tables. 2. Process non-aggregated data to create aggregated sales IDocs (message type WPUUMS), payment type IDocs

(message type WPUTAB), FI-IDocs (message type WPUFIB). 3. Send IDocs across to the ERP system via report RSEOUT00 for further processing.

Results are the peak SAPS-requirements. Here, use ratio 1:3 for the distribution of the SAPS between DB and AS. Please enter the results you get if you follow the instructions within the sizing guideline "Sizing SAP POS Data Management" in the corresponding columns SAPS (DB, ABAP, JAVA), memory (DB, ABAP, JAVA), and disk.

Point Of Sale Download (R-POS-DL) POS Download is the processing within ERP to prepare data (prices, new articles, promotions etc) to be sent down to the stores. Each price change, new article, article in a promotion is considered as a "change" that needs to be sent down to the stores. Enter the SAPS numbers provided by the Retail Sizing Questionnaire in the corresponding fields "DB SAPS" and "ABAP SAPS".



Back to Top

Utilities

Retail Masterdata (R-Master) This section estimates the disk capacity required to store the master data. Please fill in the fields as shown in the Retail Sizing Questionnaire.

Comment The actual processing cycle for POS Data Management (DM) is considered to be a once daily activity. If this is not the case, then the POS DM sizing will need modification to correctly consider the execution cycle proposed.

Master Data and Transactional Data for Disk Sizing - Part I UTIL-01

Specifics for Master Data and Transactional Data

Billing cycles per year (BillCycle) Corresponds to the number of bills sent to a customer each year. Some customers send their business partners a bill each month which would add to 12 invoices / year. An average value can be given here, if different groups of business partners have different invoicing frequencies. Note Typical values here are 1 (yearly billing), 2 (bi-yearly), 4 (quarterly), 6 (bi-monthly), 12 (monthly).

Budget billing amounts or partial bills per contract and year (Budget, Partial) Usually the meters are read only once a year, but companies would like to get money from the customer more frequently because of their own expenses. They have several choices to do it:

Real bills based on estimated consumption Budget billing amounts Real bills based on estimated consumption

The latter two ones are based on estimated amounts (not consumptions) and the difference between them is that budget billing amounts are not posting relevant. Legally they are not earnings of the company while partial bills are. Example When you read the meter once a year, you might have 11 partial bills between two bills. Note Due to the posting relevance, the treatment in IS-U is different and hence the significance for sizing. If there are neither budget billing amounts nor partial bills, the answer to this question is not relevant.

Posting relevant line items per budget billing amount or partial bill (P.items)



For explanation see ‘Posting relevant line items on consumption bill’. However, the same figure of a partial bill is asked for there. Usually, it is smaller then the one of the real, final bill. If no partial bills or budget billing amounts are made, the correct answer here is 0. Example Enter “2” to reflect basic fee deposits and deposits on utiltiy services. Posting relevant line items on consumption bill (C.item) On each bill many lines are printed. Basically three types of lines exist:

Generic lines with some general information which is the same for all business partners. These lines are part of the so-called print form and don’t play a role in sizing. Posting relevant line items which contain monetary information that has finally to be passed to the general ledger, like the total due amount. This is usual more then one line, as different services are posted on different accounts. To give an example, a company might deliver gas and water to a customer, so they might have four posting relevant line items for

Gas consumption Water consumption Waste water Metering services

Additional info lines which are all non-posting relevant lines. This can include:

Consumption Control readings

In any of these cases the average number of lines per single bill is requested in this sizing.

Additional info lines on consumption bill (Lines) For explanation see above (Posting relevant line items on consumption bill). The average number of info lines is asked for. Contracts (Contracts) A contract is an agreement between a business partner and the utility company that applies to a single division. Therefore, this entity is quite similar to the legal contract the business partner has with the utility company to get electricity, gas, water or some similar service. For example, if a company sells electricity to 500,000 customers and gas to 100,000 customers, it would have 600,000 contracts with their business partners. Taxes per contract (Taxes) The number of different taxes that have to be paid on a contract. This could be VAT (value added tax), sales tax or some kind of environment taxes. Example Enter “3” to reflect the jurisdiction code where the state, the county and the city each demand taxations. Contract accounts (ContAcc.) A contract account is an account in which posting data for contracts or contract items are processed for which the



same collection/payment agreements apply. Contract accounts are managed on an open item basis within contract accounts receivable/payable. In the case of utility companies, a contract is assigned to one contract account only. However, and depending on the contract account category, several contracts can be assigned to one contract account. The relation between business partners and contract accounts is 1:n but in most cases the relationship is almost 1:1. Nevertheless, this rule of thumb should only be used if there is no figures about “contract accounts” available. Meters (Meters) The number of meters to be read. Meters in the stock are not to be counted here. Here it is asked for meters as this device is quite familiar to everyone. A more correct input here would be the number of registers, but as usually the relationship is 1:1 for the majority meters work as well. However, if the customer has a lot meters with two registers, one e.g. for day- electricity and one for night-electricity, it would be better to enter the number of registers instead.

Master Data and Transactional Data for Disk Sizing - Part II UTIL-02

Specifics for Master Data and Transactional Data

Business partners (BusPartner) A business partner is a natural person, organization, group of natural persons, or group of organizations in which a company has a business interest. A business partner may be a person, organization, or group within a company, such as 'Mrs. Lisa Davies', 'Repro Electrical Products Inc.', or 'The tenants of 15 Charles St.'. Overdue notices per year (Overdues) The relative number of documents to be dunned per year is required. Experience from customers shows this figure is between 5 and 10%. Cash security deposits (Deposits) A cash security deposit is a payment which the business partner has to make before the utility service starts. It is usually requested when the company expects the business partner not to bill. This is different from pre-payment where the customer purchases the right to e.g. use electricity up to an amount of $40. The total number of cash securities is requested here. Customer contacts per year (Cust.contct) Usually when a business partner contacts the company by phone or mail a customer contact is created to keep track of the communications. The total number of customer contacts created during one year is requested here. As a rule of thumb from experience one contact per business partner and year can be assumed, but: In the past when IS-U/CCS was developed, no CRM systems did exist and therefore customer contacts had to be written in the IS-U/CCS system. Today however, most of the agents work with a CRM system and pass information from and to the IS-U/CCS system. In this case the customer contact is completely handled in the CRM system and the proper input here would be “0”.



CPU Sizing for Background Processes UTIL-BP

Specifics for Background Processes

Business partners (BusPartner) Find the definition above at Disk Sizing -Part II → Business partners. The entries in these two fields have to be identical. Days for batch (Days f. btch) Minimum number of days available for one full billing cycle. Example If all 100,000 customers have to be billed once a month and each day the same number of customers should be billed, the correct answer would be 28, because in February more customers have to be billed per day then in any other month. Minimal runtime per day (S.t. and E.t.) Minimal daily time permitted to process the main batch cycle. This includes the whole billing and collection process, starting from meter reading order preparation up to dunning activity run. The daily amount is calculated as the number of business partners divided by the number of days for batch. This has to be the lowest maximal runtime if the time window for this process is not the same every day.

Customer Overview (CPU Background Sizing) OVERVIEW

Comment Enter how often you use the transaction "Customer Overview".

Customer Contact (CPU Background Sizing) CONTACT

Find the definition above at Disk Sizing → Customer contacts per year.

Comment Enter how often you create customer contacts with the respective transaction. Attention: when using a CRM system together with the IS-U system, the customer contacts are recorded in the CRM system and therefore the question is irrelevant here.

Move-In and Move-Out (CPU Background

Definition Move-in is the registration for utility service by the customer. This is different from moving out of the residence, where the utility service is cancelled.



Back to Top

Portal

Sizing) MOVE IN MOVE OUT

Sizing NetWeaver Portal

Definition The questions for the NetWeaver Portal aim at determining the size of the Portal Server including the Portal database. The load driving factors consist of user interaction steps to the Portal Server, which are called navigation steps. Note that not all navigation steps create load on the Portal, but depending on the installation may create load on software components other than the Portal (such as TREX or back-end systems). For more information on sizing the NetWeaver Portal refer to Sizing SAP NetWeaver Portal. Note In a previous version of the NetWeaver Portal Sizing, the Quick Sizer assumed a distribution of 60% concurrent active users with a think time of roughly 600 seconds between two Portal navigation steps, 34% with about 180 seconds think time and 6% with a think time of 30 seconds. This results in an average think time of 211 seconds, which is quite realistic for an Intranet scenario (NW-EP-INT). This version's results were based on an exemplary business process from SAP CRM and the role of the Sales Representative, where each page contains three Java iViews.

Active Users - NetWeaver Portal NW-EP-URL, NW-EP-INT, NW-EP-PCC, NW-EP-PRT

Definition The Quick Sizer allows you to define Portal scenarios yourself. For easier handling, there are default values which you can modify at your discretion. If you only have user numbers and no other information, we recommend that you use sizing element NW-EP-INT (Intranet scenario). Make sure, however, that you document all assumptions for the scenario as detailed below. The list below contains an overview of the assumptions for each scenario.

NetWeaver Portal for launching back-end transactions using URL iViews Portal navigations are used to launch transactions in the back-end system. In these scenarios Portal pages typically contain one single URL iView (no Java iViews). To size the Portal Server, enter the number of users in this(these) scenario(s) and their think time. The NetWeaver Portal for launching back-end transactions is an example for a lightweight Portal application.

NetWeaver Portal for Intranet scenarios



In an Intranet scenario, the Portal is used as an Enterprise Information Portal. Users typically read news, access documents, and occasionally launch transactions in other business systems. Enter the number of users. You can modify the default suggestions at your discretion. The Intranet scenario is an example of a medium-weight Portal application.

NetWeaver Portal for People-Centric CRM (PCC) scenario This scenario is based on an example from SAP CRM with the end user role Sales Representative. An EP-PCC user typically navigates in the Portal to perform actions such as

Launching BSP-based CRM transactions (1 URL iView, 0 Java iView) Displaying overview information from CRM and NetWeaver BI backend system (Java iViews).

A NetWeaver BI (BEx) iView that does not use the Portal application cache is a URL iView. If it does use the Portal application cache, it creates a load similar to a Java iView. The PCC scenario is an example of a medium-weight Portal application.

NetWeaver Portal for custom-defined scenario You should use this scenario if you have more detailed information available on the Portal usage by specifying not only the users and the think time, but also the different numbers and types of iViews in different custom application scenarios. To reflect different scenarios, use the insert button to create any number of scenarios.

Specifics for Active Users - NetWeaver Portal

Number of concurrently active users To determine the high load phase, enter the highest possible number of users working simultaneously in the system.

Average think time in seconds This is the average elapsed time between two successive clicks of a user to the Portal Server, that is, between two navigation steps. Note that the think time is often higher than most customers assume, as end users type, read, use other applications, take a phone call and so on. As this field has a strong influence on the sizing result, you should consider the figures carefully.

Number of Java iViews on an average Portal page Specify the number of Java iViews of a typical Portal page of a specific scenario. A Java iView retrieves business content from back-end systems via JCo/RFC and renders the unformated business content in HTML.

Number of URL iViews on an average Portal page Specify the number of URL iViews of a typical Portal page of a specific scenario. For a URL iView, the Portal generates the URL and sends it to the browser. The browser then sends the URL to the back-end system and retrieves the HTML content from there.

Percentage of requests using Knowledge Management & Collaboration (% KMC) Enter how many clicks out of 100 access KMC content.

Maximal number of logons per hour



Back to Top

Business Intelligence

Active Users - NetWeaver Portal Logon NW-EP-LOG

Enter the highest number of users (2,000, for example) who log on to the Portal within one hour (e.g. 8 am - 9 am). If the users will log on to the Portal over a period of two hours (e.g. 8 am - 10 am), you then need to size only half of the users (e.g. 1,000 logons per hour).

SAP NetWeaver Business Intelligence

Find information about SAP NetWeaver Business Intelligence at the Service Marketplace -> Business Intelligence, for example information about Performance Tuning.

User Groups Business Planning Planning 1, Planning 2, Planning 3

Definition The general idea is to define user groups which are determined by the number and size of data records they work with and the types of planning functions they execute. If you are not sure exactly how many data are involved, you can take the proposed values, which are based on internal measurements and customer feedback.

Specifics for User Groups Business Planning

Users Estimate the highest number of active users per hour. Opposed to other sizing approaches in the Quick Sizer you can arbitrarily include users in a specific group. Normally the user groups reflect the fact that you have power, medium and occasional users (example at "Planning steps per user"). Planning steps per user Estimate the peak number of planning steps per user and hour. Example for "Users" and "Planning steps per user" A user carries out six planning functions, the first three work on the same set of data (5,000 records), the other ones each work on separate set of 600 records. If this sequence is carried out every 20 minutes, we were faced with 18 planning steps per hour and user. Average number of data records per planning step A planning step always contains exactly one planning function, for example a formula function. If that planning



sequences are used, these cannot be calculated as a planning step, instead the number of planning functions contained must be entered. The average number of data records manipulated by one single planning step has an impact on the CPU time consumed by a user. Example In our example we have an average of 2,800 ( = (3 * 5,000 + 3 * 600) / 6) records per planning step. Note

The term planning step is often understood from a business view, where it means a total run of a planning area. Here, we take a functional perspective. The memory requirement and CPU consumption is estimated on the basis of this data. To determine memory requirements, we assume that there is an average data record length of 1KB.

Maximum data per planning step Estimate the maximum number of data records manipulated by one single planning step. Example As mentioned above the planning functions work through different sets of data. The maximum number is 5,000 per hour and user. Maximum data per user Estimate the maximum number of data records a user holds in memory simultaneously. This is needed to estimate the memory consumption of a user. Example Take the example mentioned above. If the user doesn't leave the transaction, he holds 6,800 (5,000 + 600 + 600 + 600) records in memory. Please keep in mind, that the set of data is the sum of records read and records created

Comment

Editing/creating data records is achieved by planning functions or manual planning. We do not differentiate between these two types for sizing, as both of them are used to manipulate data records. We only size "User Groups Business Planning". NetWeaver BI server must be sized separately. However, the sizing result includes the part of NetWeaver BI that is used to deliver the transaction data to "User Groups Business Planning". For sizing the load generated on the NetWeaver BI system by "User Groups Business Planning" we assume that 30% of all executed planning steps access NetWeaver BI. For the remaining 70% of the planning steps we assume that they manipulate data records which have already been read by NetWeaver BI.

BI Users Definition



BI-INFO, BI-BUSIN., BI EXPERT

In NetWeaver BI, we distinguish roughly between user types according to their frequency of activity and the reporting they will normally do.

A navigation step includes drilling down in the reports and corresponds to nine dialog steps in the SD benchmark. If you don't know the user distribution, a typical ratio in the NetWeaver BI environment is 71% : 26% : 3% (Information Consumer : Business User : BI Expert).

Active User Type Navigation Steps per Hour This user will predominantly ...

Information Consumer 1 ... view predefined and static reports

Business User 11 ... navigate within reports, do slicing and dicing, but usually hit aggregates

BI Expert 33 and more ... run ad-hoc queries with a high probability of full table scans

Comment

The system automatically calculates the Java parts which are shown at the result level. If BI Java is not used, you should add 5 % to the SAPS of the application server.

User Groups Reporting & Analysis

Definition Collection of a selection of characteristics and key figures (InfoObjects) for the analysis of the data of an InfoProvider. A query always refers exactly to one InfoProvider, whereas you can define as many queries as you like for each InfoProvider.

For sizing purposes we distinguish between three query types which are defined by the load they create in the system.

Report Viewing: Predefined, static, reports using optimal aggregates OLAP Analysis: Slicing and dicing, navigating in reports, using various aggregates Data Exploration: Data mining, that is ad-hoc reports with unpredictable navigation paths, access of detail data, full table scans

Any user can do any type of query. However, experience shows a certain activity pattern, as you can see in the table below.

Query Type

Report Viewing OLAP Analysis Data Exploration Total Percent

Information Consumer

80% 20% 0% 100%

Business User

50% 50% 0% 100%

BI Expert 0% 0% 100% 100%



Data Upload UPLOAD

Definition In this section you can specify how many records you need to upload within your peak time interval.

InfoCube INFOCUBE IC-APO IC-CO IC-CRM IC-FI IC-HCM IC-MM IC-PP IC-PS IC-SD IC-SEM

Definition The central objects upon which reports and analyses in NetWeaver BI are based, are called InfoCubes. An InfoCube describes (from a reporting point of view) a self-contained dataset, for example, of a business-orientated area.

An InfoCube has a particular type:

BasicCube which is a collection of relational tables arranged according to the star schema: A large fact table in the center, surrounded by several dimension tables. MultiCube which is based on the basic cube. It combines data from several BasicCubes/RemoteCubes, and brings it together into one context. The MultiCube itself does not contain any data; its data comes exclusively from the BasicCubes it is based on. RemoteCube to carry out reporting using data in external systems without having to physically store transaction data in NetWeaver BI.

Only BasicCubes physically contain data on the database. MultiCubes and RemoteCubes simply display logical views of a dataset. The InfoCube type is not important, as far as reporting is concerned. A query definition always refers to one InfoCube. The difference between the InfoCube types becomes important at the point when you select data for the query.

InfoCube types: From the list below you can choose additional InfoCubes, just take the information and fill it in the questionnaire.

Long Text Short Name Cube name Dimensions Key Figures Length

Aerospace & Defense A&D 0AD_C01 6 2 94

Apparel and Footwear AFS 0AFMM_C01 8 48 896

Automotive 0AUPPC_3 12 11 307

Business Planning and Simulation 0SEM_C09 5 14 288

Category Management 0CM_C07 7 34 648

Consumer Products Industry CP 0CP_PURC1 8 52 964

Distribution Channel-Specific A 0CRM_CTI2 3 16 302

E-Analytics 0WEB_C01 12 5 205

External Market Data 0DB_MC01 9 5 175

Financials Management & Control 0FITV_C02 12 13 341

Healthcare 0HC_C01 9 16 362



Specifics for InfoCubes

Dimension A grouping of those evaluation groups (characteristics) that belong together, as regards contents, in one generic term. With the definition of an InfoCube, characteristics are summarized into dimensions in order to store them in a table of the star schema (dimension table). An InfoCube has no more than 16 dimensions, of which three are standard (package, time, unit) and included in the sizing by default. You can therefore enter only 13 dimensions at most. Key figures Values or quantities, such as sales revenue, fixed costs, sales quantity, or number of employees. In addition to the key figures saved on the database, you have the option of defining derived (calculated) key figures in the query definition in the Business Explorer. Such key figures are calculated using a formula from the key figures of the InfoCube. Examples of derived key figures are "sales revenue per employee" (sales revenue divided by number of employees), "variance as a percentage", or "contribution margin". Initial load & periodic load Initial load: Specify the estimated number of records which you plan to load into the cube initially. Periodical load: Specify the estimated number of records which are loaded in your periodical upload process. You should take into account that you upload data volume grows with time. Number of periods

Insurance 0IS_CS_C1 9 8 226

Inventory Management 0COPC_C04 7 6 172

Investment Management 0IMFA_C02 7 3 121

Marketing 0CRM_MC05 12 43 851

Marketplace 0MA_OP_C1 9 13 311

Media Enterprises 0MEMAMC04 11 16 382

Mobile Sales MSA 0MSA_C05 8 6 182

Oil & Gas Oil & Gas 0OI_SSC01 9 16 362

Personnel Management 0PACM_C01 10 17 389

Point of sale POS 0RT_C06 9 33 651

Retail - Logistics 0RT_C41 7 183 3181

Sales and Distribution Analyses 0CSAL_C09 12 29 613

Service 0CRM_PRI 14 47 939

Strategic Enterprise Management SEM 0SEMPA_C2 13 68 1286

Strategic Enterprise Management 0SEM_MC01 6 9 213

Traffic Analysis 0MA_C02 15 21 507

Treasury TR 0TRCM_MC1 6 2 94

Utility Company 0UCSA_C01 12 20 460



Back to Top

Process Integration

Specify the total number of uploads which will be kept in the InfoCube. Example: if you want to keep weekly data for 5 years, you should enter 260 (52*5) Short text If you have several different InfoCubes of the same type, use short text to attribute names in order to identify them more easily.

DataStore Object DS OBJECT

Definition A DataStore Object serves to store consolidated and debugged transaction data at a document level (atomic level). It describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or InfoSet Query.

A DataStore contains a key (for example, document number/item) as well as data fields that can also contain character fields (for example, order status, customer) as key figures. The data of a DataStore Object can be updated with a delta update into InfoCubes and/or other DataStore Objects in the same system or across systems.

In contrast to multi-dimensional data storage with InfoCubes, the data in DataStore Objects is stored in transparent, flat database tables.

Sizing Process Integration

Definition The current sizing procedure for SAP NetWeaver Process Integration (PI) determines the size of the Integration Server (including the central Adapter Engine) and/or additional non-central Adapter Engines. Resource requirements for proxy applications on sender or receiver side are not taken into account.

The minimal requirements for the installation of SAP PI depend on the respective requirements for SAP NetWeaver Application Server (AS) 7.0. Details are available on SAP Service Marketplace at http://service.sap.com/installnw70 .

Comment There are two different approaches:

Initial Sizing requires only basic knowledge about the PI architecture and the used scenarios.



Advanced Sizing requires advanced knowledge about the PI architecture and the used scenarios.

You can combine both approaches to obtain sizing figures for generic and detailed scenarios.

Note The results from all sizing tables (initial sizing, advanced Integration Server sizing, and advanced non-central Adapter Engine sizing) are added up. Therefore, the same scenario should not be entered in more than one sizing table.

Basic sizing information needed for PI:

Message size Average size for XML representation of messages of a scenario. If the size for XML representation is unknown, you can use the following guidelines to estimate the XML size: - For flat files, calculate a factor of 10 for conversion to XML (multiply flat file size by 10). - For IDocs, you can use the following approach: In a sender or receiver system, use the IDoc test tool (transaction WE19) to write a sample IDoc to a file using an XML File port (or a File port if an XML File port is not available); then use the file size as XML message size. Number of messages Peak number of outbound messages to be processed in a given timeframe for a scenario. For the Integration Server, only messages sent out from the Integration Server are counted; for a non-central Adapter Engine, all processed messages must be counted. For peak load calculation it might be helpful to distribute processing over time (e.g. by using batch functionality). Processing mode Synchronous or asynchronous processing mode determines how messages are handled in PI. - Synchronous messaging means that a sender application has to wait until a message is delivered to a receiver application, and that the receiver sends an immediate response like in a synchronous remote function call. This applies to Quality of Service BestEffort. - Asynchronous messaging means that a sender application sends a message to the Integration Server and receives a technical OK that the message has been received; the sender does not wait for immediate response by the receiver application. With this processing mode, the Integration Server needs to store data and deliver the message later (asynchronously) to the receiver application. Asynchronous processing is standard in PI and applies to Quality of Service ExactlyOnce and ExactlyOnceInOrder. If you use this mode in order processing (serialized), the Integration Server cannot make use of parallel processing. Business Process Management (optional) Business Process Management (BPM) provides stateful message processing capabilities with PI. An integration process is an executable cross-system process for the processing of messages, including process steps and parameters relevant for process control. The status of an integration process is persisted on the Integration Server. For sizing calculation, it is important to determine if messages of a scenario are handled by integration processes in the Business Process Engine (BPE), the runtime component for process execution. Within the sizing procedure, BPM usage is categorized in predefined BPM patterns (see process definitions in software component SAP_BASIS for namespace http://sap.com/xi/XI/System/Patterns in the Integration Repository).

Disk sizing: The Quick Sizer result includes an offset for the initial system setup (installation) and additional disk requirements per day (calculated by scenario timeframes) driven by temporary storage of messages. The needed database size then depends on the residence period for the data. In general, processed messages should be archived and/or deleted on a daily basis.



Asynchronous messages are calculated to use two persistence steps (message is persisted twice). If data is persisted more than twice by activating logging, additional disk space will be required.

Memory sizing: Memory sizing is based on the number of required CPU resources (SAPS value). Memory requirements raise as additional Application Server instances (ABAP or Java) need to be installed. Additionally, individual memory requirements by single messages due to their message size are considered. As result, the maximum for both memory requirements is calculated. The number of parallel messages to be processed is derived from the given throughput value. Depending on the type of adapter or mapping, at least six to eight times the message size is required as memory for processing. Therefore, available OS heap limits must be taken into consideration. Use of 64-bit environments is strongly recommended. For more information, see SAP Service Marketplace at http://service.sap.com/installnw70 → Operations → Process Integration → Tuning Guide.

Initial Sizing PI-INITIAL

Definition Initial sizing is based on an exemplary PI scenario that is very common at customer side. This basic scenario uses the IDoc adapter (asynchronous) or the proxy interface (synchronous) and a J2EE-based adapter provided by the Adapter Engine. Message mapping is also included in the scenario. As additional input, a percentage value for BPM processing can be added (meaning the percentage of messages that require BPM processing).

Comment The scenario for initial sizing includes the following:

IDoc adapter in/outbound processing (asynchronous) The IDoc adapter transforms IDoc binary data to IDoc-XML format. Proxy in/outbound processing (synchronous) Proxies are generated components (defined in the Integration Repository) used for message exchange with PI. J2EE-based adapter in/outbound processing J2EE-based adapters are, for example, the File, FTP, JDBC, and JMS adapter. Message mapping Mapping maps a source structure to a target structure. BPM percentage (percentage of messages handled by integration processes) Typically refers to asynchronous scenarios; for synchronous processing mode, BPM uses the SyncAsyncBridge pattern. TREX The Search and Classification engine (TREX) provides various software applications with intelligent search, retrieval, and classification functions. With PI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring on one component is included.

As IDoc processing is possible only in asynchronous processing mode, a proxy interface was used in the sample scenario for synchronous processing.



Advanced Sizing Definition Advanced sizing allows to create individual scenarios beyond the predefined initial sizing scenario. Therefore, advanced sizing requires additional knowledge about the PI architecture and processing capabilities. It is divided in two categories. One category refers to sizing the Integration Server including the central Adapter Engine. The second category refers to sizing a non-central Adapter Engine with an own database.

Comment Additional non-central Adapter Engines can be used for several reasons. For example, if you use independent network zones or for performance considerations in order to distribute and control the processing of specific interfaces.

Advanced Sizing (Integration Server) PI-INT-SRV

Definition The Integration Server includes the basic processing components Integration Engine and Business Process Engine. Inside the Integration Server, the Integration Engine enables processing of XML messages. Additional protocols like IDoc, RFC, HTTP (plain) are supported by adapters. Adapters for processing the standard XI protocol (proxies), for IDocs, and for the plain HTTP protocol are implemented directly within the Integration Server. Additional adapters are implemented in the central Adapter Engine as J2EE-based services.

Comment The sizing information needed for advanced sizing of the Integration Server is the following:

Message size, Number of messages, Processing mode Content-Based Routing (CBR) CBR requires access via XPATH expressions to the message payload or document. XPATH is a Web standard for navigating in XML documents. As input, the number of Routing conditions for a scenario needs to be entered. Mapping Type Mapping maps a source XML structure to a target XML structure. There are different mapping types available: - Mapping Tool: Graphical mapping tool which generates Java mapping classes. - XSLT Mapping: This type of mapping uses the J2EE Engine’s standard XSL Transformation processor. - Java Mapping: User defined java class for mapping transformation. - Value Mapping: Additional use of value mapping in the Mapping Tool. Mapping rules for different objects are stored in value mapping tables (requires DB access during mapping). Acknowledgements Acknowledgements enable the confirmation that an asynchronous message has been received. Acknowledgements must explicitly be requested by an application. Acknowledgements require that additional messages are transferred. BPM Pattern Specific usage types for ccBPM are defined as BPM patterns in the Integration Repository. In general, resource consumption of BPM processes depends on the complexity of the process design and the resulting number of process steps. Typically, process steps for receiving messages require more resources than process steps for sending messages due to correlation evaluation (correlations are used to assign messages that belong together to the same process instance). Most BPM scenarios are asynchronous scenarios (except the SyncAsync pattern). Available BPM patterns: - Collect: Collects messages and merges them into one message.



- Multicast: Sends one message to a receiver list and receives response messages. - Serialize: Serializes a number of messages. - Split: Splits one message into several messages. - SyncAsync: Synchronous to asynchronous bridge. - Other: Generic BPM scenario based on message forwarding (receive to send ratio 1:1, receive and send one message); includes additional process steps. BPM Ratio The BPM ratio is used to adapt or configure specific BPM patterns (if no value is entered, an internal default is used): - Collect: Defines the average collect factor; specify 10 for a 10:1 merge (merge 10 messages into 1 message). - Multicast: Defines the average number of receivers; specify 5 for an average of 5 receivers per process execution.- Serialize: Defines the average number of serialized messages; specify 3 for serialization of 3 messages per process execution. - Split: Defines the average split factor; specify 10 for a 1:10 split (split 1 message into 10 messages). - SyncAsync: Not relevant for this pattern. - Other: Defines the average number of additional process steps per process execution. Inbound Adapter Inbound adapters receive requests from a sender application and are therefore also called sender adapters. Available adapter types are: - IDoc: Standard IDoc adapter. - XI (Proxy): Standard XI message protocol (used within proxy communication) based on SOAP/HTTP. - HTTP (Plain): Adapter for message exchange using the plain HTTP protocol. - J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail). - J2EE w/conversion: J2EE-based adapters including content conversion (for example, conversion of flat files to XML). - Industry Speak: B2B adapters (RNIF, CIDX). - 3rdParty: Certified 3rd party adapters from partners. Outbound Adapter Outbound adapters send requests to a receiver application and are therefore also called receiver adapters. The available adapter types are the same as for the inbound adapters. TREX The Search and Classification engine (TREX) provides various software applications with intelligent search, retrieval, and classification functions. With XI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring on one component is included.

Adapters are divided into different categories referring to the adapter type. Several adapters are grouped together in subcategories as the sizing estimate is quite comparable (for example, J2EE-based adapters like File, FTP, JDBC).

Advanced Sizing (Non-Central Adapter Engine)

Definition A non-central Adapter Engine runs on the J2EE Engine. There may be any number of non-central Adapter Engines, each associated with exactly one Integration Server, with which the Adapter Engine communicates using the XI protocol. The



PI-ADAPTER Adapter Engine has an own database (based on AS Java). All J2EE-based adapters can be used with this type of Adapter Engine.

Comment The sizing information needed for advanced sizing of a non-central Adapter Engine is the following:

Message size, Number of messages, Processing mode Acknowledgements Acknowledgements enable the confirmation that an asynchronous message has been received. Acknowledgements must explicitly be requested by an application. Acknowledgements require that additional messages are transferred. Adapter Type - J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail). - J2EE w/conversion: J2EE-based adapters including content conversion (for example, conversion of flat files to XML). - Industry Speak: B2B adapters (RNIF, CIDX). - 3rdParty: Certified 3rd party adapters from partners. TREX The Search and Classification engine (TREX) provides various software applications with intelligent search, retrieval, and classification functions. With XI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring on one component is included.

Adapters are divided into different categories referring to the adapter type. Several adapters are grouped together in subcategories as the sizing estimate is quite comparable (for example, J2EE-based adapters like File, FTP, JDBC). Only adapters implemented in the J2EE Adapter Framework can be selected.

PI Sizing Examples

Example This section describes some sizing examples derived from customer projects. Split Process Scenario A backend system sends material master data IDocs to the Integration Server. Within the Integration Server, a BPM split process is defined to split the IDoc on record level. Single records are transferred using the JMS adapter with content conversion to a legacy system. Scenario Details:

Average message size of split messages is 1 kB Peak load during one hour is 10.000 split messages Asynchronous processing mode is used In a Quick Sizer project, enter: - 1 as XML message size - 10.000 as number of messages - Asynchronous as processing mode - BPM pattern Split - BPM factor 16



Back to Top

Application Server

- Inbound adapter type IDoc - Outbound adapter type J2EE w/conversion

Comment

Average customer message sizes are between 50-100 kB. A typical business process is as follows: - Backend system sends sales order IDocs via RFC - Use predefined mapping to transform IDoc-XML to other XML format - XML message is converted to flat file and transferred via FTP adapter to legacy system

Printed Documents BC-PRINT

Definition Data storage medium containing information of a specific type.

Enter the number of printed pages.

Comment We assume that a page is always completely filled in and that the document is always completely printed. This considers SAP script printing. Other print services such as Adobe print forms may require additional load. For more information please check for the respective sizing guidelines.

Business Workplace BWP

Definition The Business Workplace provides a standard working environment in which every SAP user can carry out their share of the business and communication processes in the enterprise. There, they receive all the work items that are assigned to them in the course of SAP Business Workflow and process the documents that were sent to them from people or from SAP applications. This can include the following actions:

Processing work items Receiving and sending mails Administrating documents and work processes Distributing and processing companywide and group internal information

Comment - In line BWP enter the number of lines per mail in the field for sub components.



Back to Top

NetWeaver Standalone Engines

Back to Top

Expert Functions

- In the lines for the emails enter the number of recipients for external and internal mails in the field for sub components.

Search function (using TREX) TREX-SRCH

Definition The information retrieval system Text Retrieval and Classification (TREX) provides various software applications with intelligent search, retrieval, and classification functions for documentation development. You can use TREX to search extensive electronic collections of text documents flexibly, and to structure document classification in a way that gives a clear overview of what is available. The TREX text-mining functions allow interesting and relevant information to be extracted from text documents for the user. In principle, TREX can process, search, and classify any file format that can be rendered as text. Filter software integrated into TREX converts all current standard document formats (HTML; XML; DOC; TXT; RTF, and so on) into text. Text documents in numerous European and non-European languages can also be processed by TREX. All central and western European languages are supported, as are Korean, Japanese, and Chinese.

Find more information for TREX at the SAP Help Portal -> TREX. Note Enter the number of searches per time period.

Comment For sizing TREX we currently consider only the search function.

Status "Final"Final projects cannot be modified anymore.



© Copyright 2007 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, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. 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. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, 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. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or

Status "Inactive" You can use this function for projects that are not required anymore. Inactive projects are not listed in your project list, if you search for all your projects (using your customer number and a wildcard for the project name). Also, you cannot change the project or use it as original for a create-with-reference procedure.



implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

