Goods Transportation Reports in BW/BI

Report Name Description Comments
Lane Deficiency Report Report points out actual transit times per lane and compares it against transit tables in source system such as R3 where transportation details are stored
Deployment Scorecard Measures lane cost, mode cost, line haul costs, load factor, mode mix, short lead %, – Weekly, monthly &  yearly view. Data from the Freight Cost Detail & Accrual Tables in the source
Freight Scorecard monthly/yearly network resupply orders.  Measures linehaul, fuel, accessories and volume against AOP and then illustrates the cost variance & impact Data from the Freight Cost Detail & Accrual Tables in the source
Delivery Scorecard monthly/yearly network sales orders.  Measures linehaul, fuel, accessories and volume against AOP and then illustrates the cost variance & impact Data from the Freight Cost Detail & Accrual Tables in the source
On Time Delivery Summary Report / Carrier Scorecard Measures on time delivery at a weekly, monthly and yearly level.
Carrier Revenue Report Fiscal Month/Fiscal Year view of spend by carrier.  Measures spend on line haul, fuel, accessories.
TRACK Cost Per Mile Report Report Measures TRACK Cost Per Mile

Courtesy: Project related generic documents

SAP BI Business Content

This post describes generic standards and guidelines that apply to the use of standard BI objects delivered by SAP as part of the BI business content. Again, these may change as per your client’s BW system standards.

Activating Business Content

Anyone with access to the sandbox may activate business content there. If you activate content in sandbox, make sure that you do not activate the content in the background (batch mode.) Instead, activate the content in the foreground and always keep any existing customization for the objects you activate.

No one except the people allowed may activate business content in SAP BW development system.

 

If you need business content activated, contact one of those people and explain what you need activated. Continue reading “SAP BI Business Content”

SAP BW Back-End Usage Standards and Guidelines

Write ­Optimized DataStore Objects

Consider the following important facts in mind before you choose to use a Write Optimized DataStore Object:

  1. The primary unique key to a WODS Object consists of Request ID, Data Packet ID, and Record Number. The system does not use the semantic key as the primary, unique key to the data. This means that each time you load a particular semantic key into a WODS Object, you get a new, unique record.
  2. Write ­Optimized DataStore Objects do not aggregate data. If you extract and load two records with the same logical key (or extract and load the same record twice,) both records appear in the WODS Object.
  3. No delta detection or extraction function exists for WODS Objects. When forwarding data to subsequent data targets, the system will forward the requests (loads) that have not yet moved to those targets. Note, however, that this can result in duplicate rows going to the subsequent target.

Continue reading “SAP BW Back-End Usage Standards and Guidelines”

BW Data Retention / Archival and Space Management Guidelines

This post provides guidelines for managing space in the SAP BW Production environment in general. It describes these guidelines in the context of generic business intelligence goals, principles, and architecture.

 

Principles of Data Warehousing Data Retention:

Data warehouses exist to serve as the “information memory” of an enterprise. Data warehouses record all the critical business transactions conducted by an enterprise, so decision makers and business strategists can leverage the information to meet their goals and objectives.

 

The Value of Historical Information:

The business intelligence team must ensure that information captured in the data warehouse supports both the current, known requirements for analyses, but also supports the future, unknown requirements.

Low ­level, historical transaction data captures information about past behavior of the enterprise that no other source of information provides. When we delete this data, we eliminate forever the ability of the enterprise to leverage the knowledge contained in the raw data. If we summarize data and delete the original details, we eliminate forever the ability to produce alternate summaries of that data. Continue reading “BW Data Retention / Archival and Space Management Guidelines”

Designing and Building Secondary Indexes on DataStore Objects

This post describes best practices for building appropriate secondary indexes on DataStore Objects.

General guidelines for placing secondary indexes on DataStore Objects:

  1. The presence of secondary indexes on an DataStore Object can greatly improve query performance, but it may slow down load performance.
  2. If your application does not have routine, frequent reads or reports on a DataS­tore Object, do not build secondary indexes on it.

 

Designing Secondary Indexes:

Apply these general guidelines when determining the number and structure of secondary indexes on DataStore Objects: Continue reading “Designing and Building Secondary Indexes on DataStore Objects”

BW Development Standards Part 10: Flat File Management Guidelines

The standards and guidelines in this post apply to situations where you must move flat files into the BW environment and load them through the BW flat file interface. You may only load from flat files when you absolutely cannot use the BW Service API, the DB Connect interface, or the Universal Data Connect interface to extract data into BW.

File Locations on the BW System:

As part of your solution implementation, you need to ask the Basis team to create at least one file system directory for your application’s flat files. You should request a folder under the following path;

/usr/sap/interfaces/…..

NOTE: Refer your client’s SAP BW Naming Convention document for the details to follow naming convention.

 

Managing Flat Files in BW Process Chains

The BI Technology group has developed four custom process types to help you manage flat files in BW. You can find these process types under “General Services” in the Process Chain Maintenance tool. Their icons and descriptions appear below:

12

Each of these process types can perform its process on either the local BW system or on a remote system accessible from the BW server via ftp. In addition, each process type allows branching to one of two subsequent processes based on success or failure.

Standards Continue reading “BW Development Standards Part 10: Flat File Management Guidelines”

BW Development Standards Part 9: Process chain Standards and Guidelines

This post describes standards for building process chains in SAP BW at any generic development project. 

Process Chain Names & Attributes Standards:

Process chain technical names should begin with Z or as per your client naming conventions. 

Guidelines

Descriptions for meta chains (parent process chains that execute sub-­chains) should include “Meta” or “Parent.”

 Display Groupings:

 Standards

  1. Never leave a process chain under the default, “Not Assigned,” Display Grouping. Use the Display Components toolbar button ( ) to assign new process chains to the appropriate display grouping.
  2. Refer your client’s SAP BW Naming Convention document for Display Grouping technical names

 

Guidelines:

  1. If you have a large application composed of multiple logical subsystems, you may create multiple display groupings for your application. Doing so can help you organize your process chains by subsystem. Just make sure the name and description conform to the client standards.
  2. To ensure that you do not leave process chains abandoned under the “Not Assigned” display grouping, consider getting into the habit of assigning the display grouping immediately after you create the Start process for new process chains.

 

Process Chain Scheduling: Continue reading “BW Development Standards Part 9: Process chain Standards and Guidelines”

BW Development Standards Part 7: Reporting Guidelines

1.1.  Querying

1. All queries should be built on multi-providers – even if it is to be built on a single InfoProvider.

Multi-providers provide flexibility for the reporting layer.  Additional InfoCubes/DSO’s can be added in the future without much impact to the existing reports built. In cases where data needs to be combined using “joins,” InfoSets can be created. However, multiproviders should still be built on top of InfoSets for reporting. No end user reports should be built directly on InfoCubes, DSO’s or InfoSets.

Any reports built directly on InfoCubes/DSO’s should be utilized from an IT perspective for data quality or support inquiries.

2. For reporting, standards will be set as it relates to the information stored within each data warehousing layer. InfoCubes should be used to access summarized information and, DSO’s or additional detailed InfoCubes should be used to access detailed information.

Since the data warehousing architecture should include a DSO layer, this detail information should be the basis for providing Continue reading “BW Development Standards Part 7: Reporting Guidelines”

BW Development Standards Part 4: Master data Modeling

Master data modeling should be done is such a way that it is integrated across various modules. For example, there is only one customer for entire business regardless of module whether AR or Sales etc.

The master data info objects should be checked against business content and existing objects. If there are already existing objects which fulfill your requirement, then you should avoid creating new objects.

You can use the SAP metadata repository to search for the business content and existing objects.

Options for Modeling Dependent Attributes

Continue reading “BW Development Standards Part 4: Master data Modeling”

BW Development Standards Part 3: Data Modeling in Multiproviders and Infocubes

SAP BW Modeling:

Multiprovider:

Multiproviders must always be used as a base for the query.

Every MultiProvider includes a characteristic called InfoProvider (0INFOPROV) in the data package dimension.

Queries can filter on this characteristic to restrict access to one or more specific underlying InfoProviders.

If your MultiProvider definition includes a large number of underlying InfoProviders (such as one per year, one per division, etc.) you can improve query performance by dynamically filtering on the 0INFOPROV characteristic.

A customer exit variable provides a flexible way to Continue reading “BW Development Standards Part 3: Data Modeling in Multiproviders and Infocubes”