Describing the Data Warehouse Concept

In the implementation of more performant, integrated information systems, the newest Data Warehouse concepts are based on a three-tiered model.

The three levels subdivide the complete flow of data from capturing data in operational systems to displaying information.

Operational, integrated applications in OLTP systems form the basis for capturing information. Large amounts of master and process data are collected in these applications, which then need to be displayed in a more refined form using information systems.

The data from the applications is summarized to a subset of meaningful key figure values, and is managed separately in database tables in a Data Warehouse.

In the third level, the statistics data gathered in the Data Warehouse is available to various analysis tools for evaluation.

The analysis tools provide a large array of options for high-quality analysis and presentation of statistical data. Thus they provide modern management with a performant tool for making quick decisions.

The SAP Business Intelligence (BI) is the component that is used to extract and analyze data from operative business applications (OLTP systems). In addition to OLTP systems such as ECC and SRM (supplier Realtionship Management) other external data sources such as databases or online services can also be integrated. OLTP stands for online transaction processing.

The SAP Business Intelligence (BI) supports online analytical processing (OLAP) and is designed to process large volumes of operational and historical data.

SAP BI contains all of the meta data required for common business processes. This includes InfoSources, InfoObjects, InfoCubes and standard reports, transfer structures for all releases and communication structures and update rules for each InfoCube. These elements form part of a "ready- to-go"strategy that supports automatic data transfer with immediate analysis once the system has been installed and the source system defined.

SAP BI requests application data from the source systems that have been assigned at regular intervals (pull-mechanism). Back-end systems contain extractors that collect data and transfer it to the SAP Business Intelligence (BI).

Function model used to fill OLTP InfoObjects and InfoCubes for each infoSource.

Structure that defines the fields (infoObjects) to be loaded in to the Business Intelligence (BI). An InfoSource can include extractors from different OLTP systems or dataSources.

Fields to be loaded into the BI (for example, billed amount, date of bill, business partner, and so on). Can be either characteristics or key figures.

Central objects on which analyses are based.

They are closed datasets that are filled and aggregated according to their defined transformation rules.

Configurable view of InfoCube data.

A presentation layer of queries that can be stored as a self-contained dataset.

There are three basic types of information in an information structure:

• Characteristics are criteria that you define for collecting data on a particular subject. For example, in BW you require information about divisions, rate categories, rates, industries, and billing classes.

• The period unit is another criteria used in information structures. You can collect data for a specific day, week, month, or posting period.

• Key figures provide key business information with regard to a certain characteristic.

From a technical perspective, characteristics and periods are essential units for sorting data in databases.

The system determines the period using the source date.

You can select different periods If you use the from-date of the billing line items, the total consumption for that billing period is divided up among the individual months using the set weighting procedure. You can also use the posting date. In this case, all consumption quantities are set to the posting date.

The SAP S/4HANA Utilities data model is completed by the content available in BI.

Stock statistics map the history of the stocks. The number of contracts, for example, distributed in a region during the last 12 months lies at the center of the analysis not, for example, a list of all contracts within a region.

Transaction statistics show the number of monthly transactions and processes. Only the manual transactions are entered and registered here, as these statistics display the utilization of the employee.

The difference between manual and automatic transactions is highlighted by two examples:

• Move-in is performed automatically in migration and IDE scenarios. This is automatic processing and is, therefore, not included in the statistics

• Mass invoicing is also not relevant for the transaction statistics, whereas manual single invoicing represents an expense with regards to these statistics.

You can group rate categories and contracts according to the statistics update procedure using statistics groups.

You find the statistics groups for rate categories on the rate category screen. The statistics group for contracts is on a contract screen.

The following are examples of different updates:

• Rate categories: "Residential customers" and Commercial and industrial customers".

• Contracts: "Standard customers" and "Individual statistics". For certain contracts (such as standard customers), individual statistics are stored.

The update group controls the update on a general level. It is determined by a combination of the various statistics groups and the division.

When contracts are billed, the division and the statistics group are determined from the contract and rate category.

Using the combination of division and statistics groups, the system determines the relevant update group and saves it in the billing document for statistics-relevant line items.

Only line items with an update group in which an entry has been made can be updated to BI.

On the basis of the update group, further differentiations can be made within BI, for example, industrial and residential customers.

You enter the statistics group for quantities in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the quantities (for example, on- peak/off-peak rate active energy) in BI. This makes it easier to transfer data to CO-PA.

SAP ships the statistics groups 000000 to 000002 with the system as standard.

You should define the statistics groups in detail to ensure that the quantity in BI can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.

In the statistics group, you also define into which value fields of the operating concern the quantity in a billing line item is copied. This only applies to statistical postings in CO-PA (for example for unbilled revenue reporting).

You cannot assign any update rules to a statistics group for actual postings of the value flow in CO- PA. You control these updates using the PA transfer structure. Basically, all the billing line items in a billing document for which the field 'Billing line item relevant for posting' is set are processed for actual posting in CO-PA. The amounts from the billing line items are always transferred for actual posting. You can, however, prevent the amounts from being transferred by not setting the field Relevant for actual posting in CO-PAin the statistics group quantity.

You enter the statistics group for amounts in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the amounts (for example, energy and flat rate amount) in BI. This makes it easier to transfer data to CO-PA.

SAP ships the statistics groups 000000 and 000001 with the system as standard.

You should define the statistics groups in detail to ensure that the amount in BI can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.

For performance reasons, data modeling for unbilled revenue reporting has been moved to SAP BI. Instead of storing all URR data in a Cube, the extrapolation data 0UCSA_C06 and the actual data 0UCSA_C05 is evaluated using MultiCube 0UCS_MC01

The data is identified using the simulation ID (extrapolation data) and the creation date of the print document (actual data). Therefore, the CPU date of the print doucment must be included in the SalesCube. (if necessary, include in exit BWESTA01).

The variable exit for the print document creation date is then called and filled in the query as a result of the simulation ID selection. (see standard example queries).

Before carrying out unbilled revenue reporting, you should read the Unbilled Revenue Reporting cookbook in the Service Marketplace. BI also contains Queries for MultiProvider "Simulated/Actual Sales Statistics" 0UCS_MC01, which you can use templates in BI.

Unbilled revenue reporting takes places in steps:1. The actual data is stored in the sales statistics cube 0UCSA_C05 with the creation date for invoicing.

The simulted data is entered in the extrapolation cube 0UCSA_C06 with the simulation ID of the corresponding extrapolation run in SAP S/4HANA Utilities.

The simulation ID contains the date that the extrapolation was started in SAP S/4HANA Utilities.

All simulation data is analyzed in the MultiProvider using the simulation ID and the creation date <= start date.

The sales statistics are the most important SAP S/4HANA Utilities statistics for energy companies. For this reason we have gone to great lengths to improve performance during extraction, and the corresponding error handling. The following are the most important points:

Index Table DBESTA_BWPROT: All reconciliations that were created when invoicing contracts are saved here. During the extraction, the system checks whether the reconciliation key is closed, and then imports and extracts all documents for this reconciliation key.

Index Table DBESTA_BWPROTE: All invoicing documents that could not be extracted due to an incorrect status or error handling in the BEWSTA01 user exit are saved here. Correct the cause of the error.

During each extraction run the system attempts to reload documents from this index table. If this is not possible, then the entry remains in the table.

You must read the application log for the extraction. Either in BI monitor (a message is issued if an error has been detected in the extractor) or within the mass activity (transaction EBW_DQ_SS).

User Exit BWESTA01: If you need to make adjustments to the sales extractor (import additional tables, change values), then you should never use the RSAP0001 generic BI exit. Instead you should use this user exit. This exit is run for each billing document. As well as the billing document, it also has many other tables in the interface (note the interface for the exit). This avoids most performance-intensive and time-consuming saving procedures.

In addition, the exit also allows you to trigger an exception or error message of category 'E'. This means that the document is not extracted and written in the DBESTA_BWPROTE index table. Take advantage of the enhanced check in the exit. This has little effect on the performance, but significantly increases the time and effort required for subsequent corrections.

Some customers check address data here (for example, have the address codes been maintained?).

User Exit BWESTA02: Normally only those documents are extracted, whose reconciliation key have been closed. This restriction is not sufficient for some customers. In order to be able to make comparisons with the general ledger, you should only process the reconciliation keys that have actually been transferred to the general ledger.

For this reason you can check the reconciliation key in greater detail in this exit. However, you cannot extract an open reconciliation key.

For more information on the loading mechanism, see SAP note 438606.