Industries

During the day processing scenario, the benchmark program simulates typical daily volumes of a retail bank, including the quantity of payment transaction operations received from external payment transaction systems, single real-time payment transactions received from ATM machines, real-time account statements, as well as the quantity of account information read from the system. The scenario was constructed to mirror a distribution of typical banking tasks. Since the usual integration into the bank IT infrastructure takes place via real-time interfaces (BAPIs) rather than SAPGUI, the simulation consists of a sequence of BAPI calls.The following table shows in detail the sequence of all calls.

1. . Create 30 postings in one call
2. . Create 1 posting
3. . Create 1 bank statement for account
4. . Read postings for account
5. . Read details of a posting
6. . Create 1 posting
7. . Create 1 bank statement for account
8. . Create 1 posting
9. . Create 1 bank statement for account
10. . Create 1 payment order
11. . Read balances of account
12. . Create 1 posting
13. . Create 1 bank statement for account
14. . balances of account
15. . Read account master data

In one loop a total of 35 postings are created in steps 1, 2, 6, 8, 10 (in this step one posting for sender part only), and 12.The simulation works in such a way that a configurable amount of simulation agents simultaneously repeat the complete loop of all steps several times. During every loop, a set of 20 different accounts is accessed. This means that, as in real life, the system does not repeat operations on the same set of accounts.

In the night processing scenario, account balancing is performed at regular intervals to settle an account. The benchmark simulates account balancing by calculating interest and charges for each account across 20 value date days. While the system triggers account balancing periodically, it is also possible to set the time periods manually.

During account balancing, the system performs the following tasks:

• Determines balances

• Calculates balancing-dependent interest and charges in accordance with the conditions assigned to the account and updates on the respective account

• Increases the balancing date stored in the account master to the next date

• Forwards the interest to the component to calculate interest-based income tax for further processing

• Adjusts balancing of previous periods, when necessary, if there were value dates in the past or postings in the former account to already balanced periods

The throughput of the SAP for Utilities benchmark is measured in utilities reference customers (URC) per hour. A URC is the specific representation of a typical customer of a utility company in the ISU/CCS data model. In terms of this data model, a URC consists of one business partner with one contract account and one contract.

For each contract there is one installation with one device. Half the contracts are assigned to a different service provider to which usage information has to be sent.

The throughput unit URCs per hour describes how many URCs can be processed in one hour, assuming optimal usage of time. URC processing consists of:

• Creation of meter reading orders

• Download of meter reading orders

• Uploading meter reading results

• Billing, Invoicing and Bill Print

• Payment run

• Creation of dunning proposals

• Execution of dunning run

• Correspondence print

• Sending IDocs with consumption data and electronic bills

• Online simulation

The throughput of the ISU/CCS Benchmark is measured in Utilities Reference Customers (URC) per hour. A URC is the specific representation of a typical customer of a utility company in the ISU/CCS data model. In terms of this data model, a URC consists of one business partner with one contract account and two contracts.

For each contract there is one installation with one device.

The throughput unit URCs per hour describes how many URCs can be processed in one hour, assuming optimal usage of time. URC Processing consists of:

• Creating meter reading orders

• Outputting meter reading orders

• Uploading meter reading results

• Billing

• Invoicing

• Printing the bill
  

• 0. Logon
• 1. Main screen
• 2. Call /nWPUK (POS simulation: selection)
• 3. Choose Aggregated sales4. Choose Settings
• 4. Choose Repeats
• 5. Enter data and choose Continue
• 6. Choose Save
• 7. Choose IDOC status
• 8. Choose Continue
• 9. Call /nend
• 10. Confirm log off

User interaction steps 2 - 9 are repeated n times (eight user interaction steps).
Sales data line items per loop = 96; posted documents = inventory management, billing, financials

The Store Replenishment Benchmark consists of the following business scenario:

• POS Upload: The sales data from the stores is uploaded and posted into the central retail system. Note that this is only a pre-step of the POS upload in the POS Inbound Benchmark. In the Store Replenishment Benchmark, only the quantitative information of sold articles into specific database tables used for the replenishment run is updated.

• Requirement calculation: On the basis of sales data, forecast data, and stock data, a requirement calculation is conducted.

• Follow-on document creation: The results of the second step are taken to create follow-on documents such as purchase orders for external vendors and delivery and transfer orders for internal distribution centers.

The steps, above, are run for 1,000 stores. Every store contains 10,000 articles, distributed into 100 merchandise categories with 100 articles each. One half of the articles are received from 50 external vendors. The other half comes from internal distribution centers (DC). There are 10 DCs in total, and 100 stores are associated with each DC.

In the POS upload step, 100 IDOCs (WPUBON) with 1,000 line items have to be processed for each store. Every IDOC contains sales data for the 100 articles of a merchandise category. This means that 100,000 IDOCs with 100 million line items have to be processed in total. For each article, there are 10 line items in different receipts of an IDOC, so that aggregation reduces the data volume by a factor of 10. Due to the sales information in the IDOC, 2,000 articles must be replenished in every store.

During requirements calculation, the system checks the number of sold articles in every store (each with 10,000 articles) to determine whether a replenishment is required. As mentioned above, this will be the case for 20 percent of all articles (2,000) in every store.

In the final step, follow-on documents – purchase orders, deliveries, and transfer orders – are created for all articles determined in step 2. For the 1,000 articles that are delivered from an internal DC to a store, 10 deliveries with 100 items each are created. This triggers the creation of 10 corresponding transfer orders with 100 items. For the articles coming from external vendors, 50 purchase orders with 20 lines are created for each store. Consequently, 10,000 deliveries, 10,000 transfer orders, and 50,000 purchase orders are created in total.