Improve performance - by designing InfoCube dimensions correctly in #SAP #BW

By Martin Grob

Introduction

In reality dimensions in an InfoCube are often designed by business terms (like material, customer etc.) This often leads to the impression that InfoCube dimensions should be designed based on business constraints. This although should not be the leading criteria and shouldn't drive the decision. 

Aside from the datavolume which depends on the granularity of the data in the InfoCube, performance is very much depending on how the InfoObject are arranged in the dimensions. Although this has no impact on the size of the fact table it certainly has one on the size of the dimensions.

How is a dimension then designed?

The main goal distributing the InfoObjects in their dimensions must be to keep the dimensions as small as possible. The decision on how many dimension and what InfoObjects go where is purely technical driven. In some cases this matches the organisational view but this would only be a conicidence and not the goal.

There is a few guidelines that should be considered assigning InfoObjects to dimensions:

• Use as many dimensions as necessary but it's more important to minimize dimension size rather than the number of dimensions.
• Within the dimension only characteristics that have a 1:n relation should be added (e.g. material and product hierarchy)
• Within a dimension there shouldn't be n:m relations. (e.g. product hierarchy and customer)
• Document level InfoObjects or big characteristics should be designed as Line-Item dimensions. Line item dimensions are not a true dimensions they have a direct link between the fact table and the SID table. 
• The most selective characteristics should be at the top of the dimension table
• Don't mix characteristics with values that change frequently causing large dimension tables. (e.g. material and promotions)
• Consider also to combine unrelated characteristics it can improve performance by reducing the number of table joins. (you only have 13 dimensions so combine the small ones)

As a help the report (SE38) SAP_INFOCUBE_DESIGNS can be used.

This yellow marked dimension should be converted into a line item dimension if it contains a document level characteristic or it is simply bad design.

The maximum number of entries  a dimension potentially can have is calculated through the cartesian product of all SID's. (e.g. 10'000 customer and 1'000 product hierarchies lead to 10'000'000 possible combinations in the dimension table. It's unlikely that this is going to happen and while designing the dimension this should also be considered - analyzing the possibilities of all customers buying all products in this case.

In cases where there is an m:m relationship it usually means there is a missing entity between those two and therefore they should be stored in different dimensions.

Once data is loaded into the InfoCube a check on the actual number of records loaded into the dimension table vs. the number of record in the fact table should be done. As a rule of thumb the ratio should be between 1:10 and 1:20.

Degenerated Dimensions

If a large dimension table reaches almost the size of the fact table when measured the number of rows in the tables it's a degenerated dimension. The OLAP processer has to join two big tables which is bad for the query perfromance. Such dimensions can be marked as Line Item Dimensions causing the database not to create an actual dimension table. Checking the table /BIC/F<INFOCUBE> will then show that instead of the DMID dimension key the SID of the degenerated dimension table is placed in the fact table. (Field name RSSID). With this a join of the two tables is eliminated. Those dimensions can only hold one InfoObject as a 1:1 relationship must exist between the SID value and the DIMID.

Dimensions with a lot of unique values can be set to High Cardinality which changes the method of indexing dimensions. (ORA DB only) This results in a switch from a bitmap index to a B-Tree index.

Defining a dimension as Line Item Dimension / High Cardinality

Conclusion

Finding the optimal model and balancing the size and the number of dimensions is a delicate excercise.

Dimensions in MultiProvider do not have to follow the underlying InfoCubes definitions. Those can be focused on the end users need and be structrured by the organizations meaning. This does not affect the performance as the MultiProvider does not have a physically existing datamodel on the database.    

Designing the dimension in an InfoCube correctly can have a significant improvement on performance!

All about....Activatation Programs used while Production support....

By: CSM Reddy from SCN

Run Program RSBKDTPREPAIR

RSDG_TRFN_ACTIVATE

RSDG_CUBE_ACTIVATE             Activation of InfoCubes

RSDG_ODSO_ACTIVATE             Activation of all ODS Objects

RSDG_IOBJ_ACTIVATE             Activation of all InfoObjects

RSDG_MPRO_ACTIVATE             Activating Multiproviders

RS_COMSTRU_ACTIVATE_ALL         Activate all inactive Communication Structures

RS_TRANSTRU_ACTIVATE_ALL         Activate Transfer Structure

RSAU_UPDR_REACTIVATE_ALL         Activate Update Rules
  
RRHI_HIERARCHY_ACTIVATE         Activate Hierarchies

SAP_AGGREGATES_ACTIVATE_FILL     Activating and Filling the Aggregates of an InfoCube

RS_PERS_ACTIVATE             Activating Personalization in Bex(Inactive are highlighted)

RSDDS_AGGREGATES_MAINTAIN —     attribute change run

RSSM_SET_REPAIR_FULL_REQUEST — changes full update to repair fulll request

RSTRSNSTRU_ACTIVATE_ALL–     activating transfer structure

RSPC_PROCESS_FINISH —         process chain details

RSDG_IOBJ_REORG         Repair InfoObjects

RSDG_IOBJ_REORG_TEXTS         Reorganization of Texts for InfoObjects

RSDG_MPRO_ACTIVATE         Activating Multiproviders

RSDG_MPRO_COPY             Make Multiprovider Copies

RSDG_MPRO_DELETE         Deleting Multiproviders

RS_COMSTRU_ACTIVATE_ALL     Activate all inactive Communication Structures

RS_TRANSTRU_ACTIVATE_ALL     Activate Transfer Structure

RSAU_UPDR_REACTIVATE_ALL     Activate Update Rules

RRHI_HIERARCHY_ACTIVATE     Activate Hierarchies

SAP_AGGREGATES_ACTIVATE_FILL    Activating and Filling the Aggregates of an InfoCube

SAP_AGGREGATES_DEACTIVATE     Deactivating the Aggregates of an InfoCube

RS_PERS_ACTIVATE         Activating Personalization in Bex(Inactive are highlighted)

RSSM_SET_REPAIR_FULL_FLAG     Convert Full Requests to Repair Full Requests

SAP_INFOCUBE_DESIGNS         Print a List of Cubes in The System and Their Layouts

SAP_ANALYZE_ALL_INFOCUBES     Create DB Statstics for all InfoCubes

SAP_CREATE_E_FACTTABLES     Create Missing E-Fact Tables for InfoCubes and Aggregates

SAP_DROP_EMPTY_FPARTITIONS     Locate/Remove Unused or Empty partitions of F-Fact Table

SAP_DROP_TMPTABLES         Remove Temperory Database Objects



Function Modules within BW.

Function Module Description (Function Group RRMX)

RRMX_WORKBOOK_DELETE         Delete BW Workbooks permanently from Roles & Favourites

RRMX_WORKBOOK_LIST_GET         Get list of all Workbooks

RRMX_WORKBOOK_QUERIES_GET     Get list of queries in a workbook

RRMX_QUERY_WHERE_USED_GET     Lists where a query has been used

RRMX_JUMP_TARGET_GET         Get list of all Jump Targets

RRMX_JUMP_TARGET_DELETE     Delete Jump Targets



Function Module Description

MONI_TIME_CONVERT         Used for Time Conversions.

CONVERT_TO_LOCAL_CURRENCY    Convert Foreign Currency to Local Currecny.

CONVERT_TO_FOREIGN_CURRENCY     Convert Local Currency to Foreign Currency.

TERM_TRANSLATE_TO_UPPER_CASE     Used to convert all texts to UPPERCASE

UNIT_CONVERSION_SIMPLE         Used to convert any unit to another unit. (Ref. table : T006)

TZ_GLOBAL_TO_LOCAL         Used to convert timestamp to local time

FISCPER_FROM_CALMONTH_CALC     Convert 0CALMONTH or 0CALDAY to Financial Year or Period

RSAX_BIW_GET_DATA_SIMPLE     Generic Extraction via Function Module

RSAU_READ_MASTER_DATA         Used in Data Transformations to read master data InfoObjects

All about BW Table Types (MD tbl, SID tbl, DIM tbl, etc)

Attribute tables:

·         Attribute tbl for Time Independent attributes:

·         /BI*/P<characteristic_name>

·         stored with characteristic values

Attribute tbl for Time Dependent attributes:

·         /BI*/Q<characteristic_name>

·         Fields DATETO & DATEFROM are included in time dependent attribute tbl.

·         stored with characteristic values

Dimension tables:

·         Dimension tbls (i.e. DIM tables): /BI*/D<Cube_name><dim.no.>

·         stores the DIMID, the pointer between fact tbl & master data tbl

·         data is inserted during upload of transact.data (data is never changed, only inserted)

·         Examples:

o    /bic/D(cube name)P is the package dimension of a content cube

o    /bic/D(cube name)U is the unit dimension of a content cube

o    /bic/D(cube name)T is the time dimension of a content cube

o    /bic/D(cube name)I is the user defined dimension of a content cube

External Hierarchy tables:

·         /BI*/I*, /BI*/J*, /BI*/H*, /BI*/K*

·         /BI0/0P...

·         are tables that occur in the course of an optimized preprocessing that contains many tables.

·         bic/H(object name) hierarchy data of object

·         For more information see Note 514907.

Fact tables:

·         In SAP BW, there are two fact tables for including transaction data for Basis InfoCubes: the F and the E fact tables.

o    /bic/F(cube name) is the F-fact table of a content cube

o    /bic/E(cube name) is the E-fact table of a content cube

·         The Fact tbl is the central tbl of the InfoCube. Here key figures (e.g. sales volume) & pointers to the dimension tbls are stored (dim tbls, in turn, point to the SID tbls).

·         If you upload data into an InfoCube, it is always written into the F-fact table.

·         If you compress the data, the data is shifted from the F-fact table to the E-fact table.

·         The F-fact tables for aggregates are always empty, since aggregates are compressed automatically

·         After a changerun, the F-fact table can have entries as well as when you use the functionality 'do not compress requests‘ for Aggregates.

·         E-fact tbl is optimized for Reading => good for Queries

·         F-fact tbl is optimized for Writing => good for Loads

·         see Note 631668 

Master Data tables

·         /BI0/P<char_name>

·         /bic/M(object name) master data of object

·         Master data tables are independent of any InfoCube

·         Master data & master data details (attributes, texts & hierarchies) are stored.

·         Master data table stores all time independent attributes (display & navigational attribues)

Navigational attributes tables:

·         SID Attribute table for time independent navigational attributes: /BI*/X<characteristic_name>

·         SID Attribute tbl for time dependent navigational attributes: /BI*/Y<characteristic_name>

·         Nav.attribs can be used for naviagtion purposes (filtering, drill down).

·         The attribs are not stored as char values but as SIDs (master data IDs).

P table:

·         P-table only gets filled if you load master data explicitly.

·         As soon as the SID table is populated, the P tbl is populated as well

SID table:

·         SID tbl: /BI*/S<characteristic>

·         stores the char value (eg customer number C95) & the SID. The SID is the pointer that is used to link the master data tbls & the dimension tbls. The SID is generated during the upload (uniqueness is guaranteed by a number range obj).

·         Data is inserted during the upload of master data or of transactional data

S table gets filled whenever transaction gets loaded. That means if any new data is there for that object in the transactions then SID table gets fillled.

Text table:

·         Text tbl: /BI*/T<characteristic>

·         stores the text for the chars

·         data is inserted & changed during the upload of text data attribs for the InfoObject

·         stored either language dependent or independent

All about Infocube….

· Added by Krish, last edited by Arun Varadarajan on Mar 16, 2009
InfoCube:
Definition
An object that can function as both a data target and an InfoProvider.
From a reporting point of view, an InfoCube describes a self-contained dataset, for example, of a business-orientated area. This dataset can be evaluated in a BEx query.        
An InfoCube is a quantity of relational tables arranged according to the star schema: A large fact table in the middle surrounded by several dimension tables.
Use
InfoCubes are supplied with data from one or more InfoSources or ODS objects (Basic InfoCube) or with data from a different system (RemoteCube, SAP RemoteCube, virtual InfoCube with Services, transactional InfoCube).
Structure There are various types of InfoCube:
1.      Physical data stores:
Basic InfoCubes
Transactional InfoCubes
2.      Virtual data stores:
RemoteCube
SAP RemoteCube
Virtual InfoCube with Services
Only Basic InfoCubes and transactional InfoCubes physically contain data in the database. Virtual InfoCubes are only logical views of a dataset. By definition, they are not data targets. However, the InfoCube type is of no importance from the reporting perspective, since an InfoCube is accessed as an InfoProvider.
Integration You can access the characteristics and key figures defined for an InfoCube in the Query Definition in the BEx Web or in the BEx Analyzer.

Basic InfoCube
Definition
A Basic InfoCube is a type of InfoCube that physically stores data. It is filled with data using BW Staging. Afterwards, it can be used as an InfoProvider in BEx Reporting.
Structure
As with other InfoCube types, the structure of a Basic InfoCube corresponds to the Star Schema.
For more information, see InfoCube
Integration
The Basic InfoCube is filled using the Scheduler, providing that Update Rules have been maintained.
It is then made available to Reporting as an InfoProvider. It can also be updated into additional data targets or build a MultiProvider together with other data targets.
Transactional InfoCubes
Definition
Transactional InfoCubes differ from Basic InfoCubes in their ability to support parallel write accesses. Basic InfoCubes are technically optimized for read accesses to the detriment of write accesses.
Use
Transactional InfoCubes are used in connection with the entry of planning data. See also Overview of Planning with BW-BPS. The data from this kind of InfoCube is accessed transactionally, meaning data is written to the InfoCube (possibly by several users at the same time). Basic InfoCubes are not suitable for this. You should use Basic InfoCubes for read-only access (for example, when reading reference data).
Structure
Transactional InfoCubes can be filled with data using two different methods: Using the transaction of BW-BPS to enter planning data and using BW staging, whereas planning data then cannot be loaded simultaneously. You have the option to convert a transactional Info Cube Select Convert Transactional InfoCube using the context menu in your transactional InfoCube in the InfoProvider tree. By default, Transaction Cube Can Be Planned, Data Loading Not Permitted is selected. Switch this setting to Transactional Cube Can Be Loaded With Data; Planning Not Permitted  if you want to fill the cube with data via BW Staging.
During entry of planning data, the data is written to a transactional InfoCube data request. As soon as the number of records in a data request exceeds a threshold value, the request is closed and a rollup is carried out for this request in defined aggregates (asynchronously).  You can still rollup and define aggregates, collapse, and so on, as before.
According to the database on which they are based, transactional InfoCubes differ from Basic InfoCubes in the way they are indexed and partitioned.  For an Oracle DBMS this means, for example, no bitmap index for the fact table and no partitioning (initiated by SAP BW) of the fact table according to the package dimensions.
Reduced read-only performance is accepted as a drawback of transactional InfoCubes, in the face of the parallel (transactional) writing option and improved write performance.
Creating a transactional InfoCube Select the Transactional indicator when creating a new (Basis) InfoCube in the Administrator Workbench.
Converting a basic InfoCube into a transactional InfoCube
InfoCube conversion: Removing transaction data
If the Basic InfoCube already contains transaction data that you no longer need (for example, test data from the implementation phase of the system), proceed as follows:
1.      In the InfoCube maintenance in the Administrator Workbench choose, from the main menu, InfoCube ® Delete Data Content. The transaction data is deleted and the InfoCube is set to "inactive".
2.      Continue with the same procedure as with creating a transactional InfoCube.
InfoCube conversion: retaining transaction data
If the Basic InfoCube already contains transaction data from the production operation you still need, proceed as follows:
Execute the SAP_CONVERT_TO_TRANSACTIONAL ABAP report under the name of the corresponding InfoCube. You should schedule this report as a background job for InfoCubes with more than 10,000 data records. This is to avoid a potentially long run-time.
Integration
The following typical scenarios arise for the use of transactional InfoCubes in BW-BPS.
1st Scenario:
Actual data (read-only access) and planned data (read-only and write access) have to be held in different InfoCubes. Therefore, use a Basic InfoCube for actual data and a transactional InfoCube for planned data. Data integration is achieved using a multi-planning area that contains the areas that are assigned to the InfoCubes. Access to the two different InfoCubes is controlled here by the characteristic "Planning area", which is added automatically.
2nd Scenario: In this scenario, the planned and actual data have to be together in one InfoCube. This is the case, for example, with special rolling forecast variants. Here you have to use a transactional InfoCube, since both read-only and write accesses take place. You can no longer load data directly that has already arrived in the InfoCube by means of an upload or import source. To be able to load data nevertheless, you have to make a copy of the transactional InfoCube that is identified as a Basic InfoCube and not as transactional. Data is loaded as usual here and subsequently updated to the transactional InfoCube.

RemoteCube
Definition
A RemoteCube is an InfoCube whose transaction data is not managed in the Business Information Warehouse but externally. Only the structure of the RemoteCube is defined in BW. The data is read for reporting using a BAPI from another system.
Use
Using a RemoteCube, you can carry out reporting using data in external systems without having to physically store transaction data in BW. You can, for example, include an external system from market data providers using a RemoteCube.
By doing this, you can reduce the administrative work on the BW side and also save memory space.
Structure
When reporting using a RemoteCube, the Data Manager, instead of using a BasicCube filled with data, calls the RemoteCube BAPI and transfers the parameters.
Selection
Characteristics
Key figures
As a result, the external system transfers the requested data to the OLAP Processor.
Integration
To report using a RemoteCube you have to carry out the following steps:
1.      In BW, create a source system for the external system that you want to use.
2.      Define the required InfoObjects.
3.      Load the master data:
Create a master data InfoSource for each characteristic Load texts and attributes
4.      Define the RemoteCube
5.      Define the queries based on the RemoteCube

SAP RemoteCube
Definition
An SAP RemoteCube is a RemoteCube that allows the definition of queries with direct access to transaction data in other SAP systems.
Use
Use SAP RemoteCubes if:
You need very up-to-date data from an SAP source system
You only access a small amount of data from time to time
Only a few users execute queries simultaneously on the database.
Do not use SAP RemoteCubes if:
You request a large amount of data in the first query navigation step, and no appropriate aggregates are available in the source system
A lot of users execute queries simultaneously
You frequently access the same data
Structure SAP RemoteCubes are defined based on an InfoSource with flexible updating. They copy the characteristics and key figures of the InfoSource. Master data and hierarchies are not read directly in the source system. They are already replicated in BW when you execute a query.
The transaction data is called during execution of a query in the source system. During this process, the selections are provided to the InfoObjects if the transformation is only simple mapping of the InfoObject. If you have specified a constant in the transfer rules, the data is transferred only if this constant can be fulfilled. With more complex transformations such as routines or formulas, the selections cannot be transferred. It takes longer to read the data in the source system because the amount of data is not limited. To prevent this you can create an inversion routine for every transfer routine. Inversion is not possible with formulas, which is why SAP recommends that you use formulas instead of routines.
Integration
To be assigned to an SAP RemoteCube, a source system must meet the following requirements:
BW Service API functions (contained in the SAP R/3 plug-in) are installed.
The Release status of the source system is at least 4.0B
In BW, a source system ID has been created for the source system
DataSources from the source system that are released for direct access are assigned to the InfoSource of the SAP RemoteCube. There are active transfer rules for these combinations.
Virtual InfoCubes with Services
Definition
A virtual InfoCube with services is an InfoCube that does not physically store its own data in BW. The data source is a user-defined function module. You have a number of options for defining the properties of the data source more precisely. Depending on these properties, the data manager provides services to convert the parameters and data.
Use
You use a virtual InfoCube with services if you want to display data from non-BW data sources in BW without having to copy the data set into the BW structures. The data can be local or remote. You can also use your own calculations to change the data before it is passed to the OLAP processor.
This function is used primarily in the SAP Strategic Enterprise Management (SEM) application.
In comparison to the RemoteCube, the virtual InfoCube with services is more generic. It offers more flexibility, but also requires more implementation effort.
Structure When you create an InfoCube you can specify the type. If you choose Virtual InfoCube with Services as the type for your InfoCube, an extra Detail pushbutton appears on the interface. This pushbutton opens an additional dialog box, in which you define the services.
1.      Enter the name of the function module that you want to use as the data source for the virtual InfoCube. There are different default variants for the interface of this function module. One method for defining the correct variant, together with the description of the interfaces, is given at the end of this documentation.
2.      The next step is to select options for converting/simplifying the selection conditions. You do this by selecting the Convert Restrictions option. These conversions only change the transfer table in the user-defined function module. The result of the query is not changed because the restrictions that are not processed by the function module are checked later in the OLAP processor.
Options:
No restrictions: If this option is selected, no restrictions are passed to the InfoCube.
Only global restrictions: If this option is selected, only global restrictions (FEMS = 0) are passed to the function module. Other restrictions (FEMS > 0) that are created, for example, by setting restrictions on columns in queries, are deleted.
Simplify selections: Currently this option is not yet implemented.
Expand hierarchy restrictions: If this option is selected, restrictions on hierarchy nodes are converted into the corresponding restrictions on the characteristic value.
3.      Pack RFC: This option packs the parameter tables in BAPI format before the function module is called and unpacks the data table that is returned by the function module after the call is performed. Since this option is only useful in conjunction with a remote function call, you have to define a logical system that is used to determine the target system for the remote function call, if you select this option.
4.      SID support: If the data source of the function module can process SIDs, you should select this option.
If this is not possible, the characteristic values are read from the data source and the data manager determines the SIDs dynamically. In this case, wherever possible, restrictions that are applied to SID values are converted automatically into the corresponding restrictions for the characteristic values.
5.      With navigation attributes: If this option is selected, navigation attributes and restrictions applied to navigation attributes are passed to the function module.
If this option is not selected, the navigation attributes are read in the data manager once the user-defined function module has been executed. In this case, in the query, you need to have selected the characteristics that correspond to these attributes. Restrictions applied to the navigation attributes are not passed to the function module in this case.
6.      Internal format (key figures): In SAP systems a separate format is often used to display currency key figures. The value in this internal format is different from the correct value in that the decimal places are shifted. You use the currency tables to determine the correct value for this internal representation.
If this option is selected, the OLAP processor incorporates this conversion during the calculation.
Dependencies
If you use a remote function call, SID support must be switched off and the hierarchy restrictions must be expanded.
Description of the interfaces for user-defined function modules
Variant 1: Variant 2:
Additional parameters for variant 2 for transferring hierarchy restrictions, if they are not expanded:
With hierarchy restrictions, an entry for the 'COMPOP' = 'HI' (for hierarchy) field is created at the appropriate place in table I_T_RANGE (for FEMS 0) or I_TX_RANGETAB (for FEMS > 0), and the 'LOW' field contains a number that can be used to read the corresponding hierarchy restriction from table I_TSX_HIER, using field 'POSIT' .  Table i_tsx_hier has the following type:
Variant 3:
SAP advises against using this interface.
The interface is intended for internal use only and only half of it is given here.
Note that SAP may change the structures used in the interface.
Method for determining the correct variant for the interface
The following list describes the procedure for determining the correct interface for the user-defined function module. Go through the list from top to the bottom. The first appropriate case is the variant that you should use:
If Pack RFC is activated: Variant 1
If SID Support is deactivated: Variant 2

Technorati Tags: Infocube,Dimensions,Types of Infocubes,SAP BI INTERVIEW QUESTIONS

What are the Business content Cubes, ODS and some other objects in SD,MM, FI-Co modules we use regularly in implementation.

here is the process fllow of different modules!

SD Flow
You create a sales document to enter information about different sales transactions. R/3 provides a number of predefined sales document types. However , these can be customized to suit your company's needs when R/3 is installed.
Some examples of sales documents include:
• sales queries
• sales orders
• outline agreements
• complaints
You use sales queries to enter information about potential sales into R/3.Types of sales query documents include:
• inquiries
• quotations
• free-of-charge deliveries
An inquiry is used to record any general queries a customer may have about goods or services they
are thinking of buying from your company. An inquiry is one of the first possible documents you can
create in the customer order management cycle. An example of the type of information contained in an inquiry is whether your company stocks a certain product line. Along with entering general customer queries, you can use inquiries to record the goods or services that a customer is interested in. And you can enter descriptions of goods or services that your company should research in order to answer customer queries. You can carry out automatic pricing for any goods or services you enter in an inquiry. This will enter the price of goods or services into the inquiry for you. You can also check whether any goods you entered in the inquiry are available in your company's warehouse. The order probability function enables you to determine the likelihood that a customer will buy from you. To increase the probability of a sale, you can offer the customer alternative goods and services.
Quotations are sales query documents that you create when a customer requests specific information
about a product. For example, you can use a quotation if a customer makes a query regarding how much goods or services cost or you can use a query if a customer asks when goods will be available for shipping.
You can create quotations from scratch or you can create them by copying inquiries. If a customer is
interested in the products or services after they have made an inquiry, you can provide a quotation based on the original inquiry. R/3 allows you to copy the information directly from an inquiry to a quotation.
Let's say an inquiry was created when a customer inquired whether your company, could manufacture
twenty motorcycles. Assume a quotation was created by copying this inquiry when the customer called
back to inquire how much twenty motorcycles would cost. You can use quotations to enter information and descriptions for goods and services that are to be researched. You can also use them to carry out automatic pricing and to check goods availability. You can use quotations to calculate the probability that a customer will buy the goods or services entered on a quotation. This function is called order probability. You can also use quotations to enter details about alternative goods or services. These are goods or services that a customer did not inquire about but that you think they will consider purchasing. Once you have created a quotation for a query in R/3, you send the quotation to the customer who made the query. The quotation represents a binding offer made to the customer that includes quantity and cost details.
You create a free of charge delivery when you send free samples of any goods that your company
produces to customers. These contain information about the goods that are delivered but they don't
include the corresponding pricing information for them.
Let's look at the sales orders that exist in R/3.You create a sales order when a customer has ordered
goods or services from your company. They are a part of the customer order management cycle.
You can carry out automatic pricing in sales orders to enter the price of goods or services.
R/3 will also run a credit check on the customer to see if they will be exceeding their credit limit.
You can also check whether ordered goods will be available in your company's warehouse for delivery.
Examples of types of sales order include
• standard orders
• consignment orders
• cash orders
• rush orders
You create standard orders for goods and services that will be delivered or rendered according to
the standard R/3 sales cycle. This means that goods are ordered, picked from the warehouse, and
then shipped before customers are billed for them. Likewise, services are rendered before customers
are billed for them.
Your company may store its goods in its customers' warehouses. You create a consignment order when a customer is ready to retrieve stock from the warehouse.
SAP can propose the most suitable stock to retrieve, including third-party stock.
A consigment order is like a standard sales order for goods but it doesn't have any delivery
information.
You create cash orders and rush orders for the sale of goods only.
You create a cash order when a customer picks up and pays for a delivery as soon
as it is ordered. And you create a rush order when the customer picks up the goods on the
same day as the order is placed. In this case, the invoice is created later.
You can arrange to deliver goods or render services in installments. To do this, you create an
outline agreement. Examples of some types of outline agreement include :
• quantity and value contracts
• master contracts
• scheduling agreements
• service contracts
You create a quantity contract if a customer has agreed to order a certain quantity of goods from your company during a specified period.
And you create a value contract if a customer has agreed to order goods of a certain cumulative value from your company during a specified period.
Quantity and value contracts do not include delivery dates, so releases are made using a sales order.
You can unite multiple contracts in a single master contract.
Let's say you create a quantity contract because a customer has agreed to order 500 engines in the first six months of the current year. If the customer orders 100 of these engines in January, you create a sales order called a release order.You refer to a quantity contract in a release order. So you refer to the quantity contract created for the 500 engines in each release order created for these engines. R/3 will then update the quantity contract automatically so it contains the correct number of remaining engines to be ordered.
Scheduling agreements specify the installments in which goods will be delivered to a customer. They include the quantity of a product that will be delivered in each installment. And they include the delivery date of each installment. You process a delivery for each installment contained in the scheduling agreement in the same way that you process a delivery for a regular sales order.No sales documents, such as release orders, are created before the products included on a scheduling agreement are processed for delivery.
You create a service contract if a customer requests a service over a particular period of time. For example, you could create a service contract if a customer ordered five one-hour maintenance checks from your company's motorcycle repair department.
You create complaint sales documents if there has been a fault with any goods that have been delivered, or with any services rendered, by your company.
For example, you create complaint sales documents if customers have been billed
incorrectly for an item or service, or if goods are faulty.
Different types of complaint sales document include
• returns
• credit memo requests
• debit memo requests
You create a returns document if a customer returns goods they have purchased from you because they are not satisfied with them. You can create returns from scratch or you can create them by copying the sales order that was originally created for the returned delivery.
A returns document records that you expect stock to be returned to your warehouse.
You can create one or more credit memo requests if a customer has been overcharged for a quantity of goods or services. You can also create a credit memo request if goods were damaged during transit and you want to credit the customer for the goods damaged.
When you create a credit memo request, your Accounting department reviews it to confirm that it can be justified. If the credit memo request is approved, the Accounting department creates a credit memo based on the request. You can create credit memo requests by copying other sales documents such as the sales order where the overcharge occurred.
You create debit memo requests when customers have been undercharged for products or services. Your company’s Accounting department can then create an invoice to bill the undercharged customer.
This document is adopted from Smart Force Campus Course Material
____________ _________ _________ _____
MM Flow

PR >Release the PR>RFQ>Quotation>Quotation Comparison>PO>Release the PO>GR>Invoice Verification
MM Process flow:
Process Flow
The typical procurement cycle for a service or material consists of the following phases:
1. Determination of Requirements
Materials requirements are identified either in the user departments or via materials planning and control. (This can cover both MRP proper and the demand-based approach to inventory control. The regular checking of stock levels of materials defined by master records, use of the order-point method, and forecasting on the basis of past usage are important aspects of the latter.) You can enter purchase requisitions yourself, or they can be generated automatically by the materials planning and control system.
2. Source Determination
The Purchasing component helps you identify potential sources of supply based on past orders and existing longer-term purchase agreements. This speeds the process of creating requests for quotation (RFQs), which can be sent to vendors electronically via SAP EDI, if desired.
3. Vendor Selection and Comparison of Quotations
The system is capable of simulating pricing scenarios, allowing you to compare a number of different quotations. Rejection letters can be sent automatically.
4. Purchase Order Processing
The Purchasing system adopts information from the requisition and the quotation to help you create a purchase order. As with purchase requisitions, you can generate Pos yourself or have the system generate them automatically. Vendor scheduling agreements and contracts (in the SAP System, types of longer-term purchase agreement) are also supported.
5. Purchase Order Follow-Up
The system checks the reminder periods you have specified and - if necessary - automatically prints reminders or expediters at the predefined intervals. It also provides you with an up-to-date status of all purchase requisitions, quotations, and purchase orders.
6. Goods Receiving and Inventory Management
Goods Receiving personnel can confirm the receipt of goods simply by entering the Po number. By specifying permissible tolerances, buyers can limit over- and under deliveries of ordered goods.
7. Invoice Verification
The system supports the checking and matching of invoices. The accounts payable clerk is notified of quantity and price variances because the system has access to PO and goods receipt data. This speeds the process of auditing and clearing invoices for payment.

Pur info record is nothing but a master data like thing which will be maintained for different materials to determine the prices etc.It Specifies the number that uniquely identifies a record.
For Example: an info record is based on Plant Vendor and Material Based on these three the Material Prices will be calculated for different combinations different values are taken into consideration.
During pricing it brings these values automatically based on this info record.
Use ME11 Tcode to create this record.

Common Tables used by SAP MM
Below are few important Common Tables used in Materials Management Modules:
EINA Purchasing Info Record- General Data
EINE Purchasing Info Record- Purchasing Organization Data
MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created
A501 Plant/Material
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/ dependent requirements
T161T Texts for Purchasing Document Types

Tcodes:

RFQ to Vendor - ME41
Raising Quotation - ME47
Comparison of Price - ME49
Creation of PO - ME21N
Goods Receipt - MIGO
Invoice (Bill PAssing) - MIRO
Goods Issue - MB1A
Physical Inventory - MI01( Create doc)
MI04 (Enter Count)
MI07 (Post)
____________ _________ _
FICO

The FI module has 8 sub modules:
FI-GL: General Ledger Accounting
FI-LC: Consolidation
FI-AP : Accounts Payable
FI-AR : Accounts Receivable
FI-BL : Bank Accounting
FI-AA :Asset Accounting
FI-SL : Special Purpose Ledger
FI-FM : Funds Management
CO Controlling
represents the company's flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur.
The CO module has following sub modules:
CO-OM : Overhead Costing (Cost Centers, Activity Based Costing, Internal Order Costing)
CO-PA : Profitability Analysis
CO-PC : Product Cost Controlling