Monday, November 24, 2008


SAP ERP: A Trusted Foundation for Business Excellence and Innovation

Improved alignment of your strategies and operations. Enhanced productivity and insight for your enterprise. That’s the power of SAP ERP — helping you adapt quickly to support changing industry requirements.

The SAP ERP application is world-class, integrated enterprise resource planning (ERP) software that addresses the core business software requirements of the most demanding midsize and large organizations around the world — in all industries and sectors. SAP ERP includes four individual solutions that support key functional areas:

* SAP ERP Financials
* SAP ERP Human Capital Management
* SAP ERP Operations
* SAP ERP Corporate Services

With the general release of SAP ERP 2005, SAP is pleased to announce more than 300 functional enhancements that add value to your business.

SAP ERP software addresses your business needs based on three decades of SAP experience:


Built on the SAP NetWeaver platform — Reduces IT complexity while supporting scalability and growth through a comprehensive integration and application platform

Tightly integrated to optimize cross-functional business processes — Enables comprehensive collaboration within and beyond your organization

Enhanced by industry-specific features and best practices — Enables you to reduce total cost of ownership, achieve a faster return on investment, and benefit from a more flexible IT infrastructure that helps drive innovation
* Designed to support international operations — Promotes efficient and successful global operations and competition

Sunday, November 23, 2008


Views : Data about an application object is often distributed on several tables. By defining a :view, you can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.

The data of a view is derived from one or more tables, but not stored physically. The simplest form of deriving data is to mask out one or more fields from a base table (projection) or to include only certain entries of a base table in the view (selection). More complicated views can comprise several base tables, the individual tables being linked with a relational join operation.

The base tables of the view must be selected in the first step of a view definition. In the second step, these tables must be linked by defining the join conditions. It is also possible to use the join condition from a foreign key defined between the tables .

In the third step, you must select the fields of the base tables to be used in the view. Selection conditions that restrict the records in the view can be formulated in the fourth step.

Four different view types are supported. These differ in the way in which the view is implemented and in the methods permitted for accessing the view data.

· Database views implemented with an equivalent view on the database.

· Projection views used to hide fields of a table (only projection).

· Help views used as selection method in search helps

· Maintenance views permit you to maintain the data distributed on several tables for one application object at one time.

Database views implement an inner join . The other view types implement an outer join

The join conditions for database views can be formulated using equality relationships between any base fields. The join conditions for the other view types must be obtained from existing foreign keys. Tables therefore can only be combined in a maintenance view or help view if they are linked to one another with foreign keys.

The maintenance status whether you can only read data with the view or whether you can also insert and change data with it.

Database Views :

Data about an application object is often distributed on several database tables. A database view provides an application-specific view on such distributed data.

Database views are defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.

Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL. However, the data is actually selected in the database. Since the join operation is executed in the database in this case, you can minimize the number of database accesses in this way. Database views implement an inner join (see Inner and Outer Join )

If the database view only contains a single table, the maintenance status can be used to determine if data records can also be inserted with the view. If the database view contains more than one table, you can only read the data.

Database views should be created if want to select logically connected data from different tables simultaneously. Selection with a database view is generally faster than access to individual tables. When selecting with views, you should also ensure that there are suitable indexes on the tables contained in the view.

Since a database view is implemented in the database, a database view may only contain transparent tables.

The technical settings of a database view control whether the view data should be buffered.

Projection Views :

Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed.

A projection view contains exactly one table. You cannot define selection conditions for projection views.

There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.

The maintenance status of the view controls how the data of the table can be accessed with the projection view.

Help Views:

You have to create a help view if a view with outer join is needed as selection method of a search help

The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help, you should generally use a database view as selection method. However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a help view as selection method.

All the tables included in a help view must be linked with foreign keys. Only foreign keys that have certain attributes can be used here . The first table to be inserted in the help view is called the primary table of the help view. The tables added to this primary table with foreign keys are called secondary tables .

The functionality of a help view has changed significantly between Release 3.0 and Release 4.0. In Release 3.0, a help view was automatically displayed for the input help (F4 help) for all the fields that were checked against the primary table of the help view. This is no longer the case in Release 4.0.

As of Release 4.0, you must explicitly create a search help that must be linked with the fields for which it is offered (see Linking Search Helps with Screen Fields ).

Existing help views are automatically migrated to search helps when you upgrade to a release higher than 4.0.

A help view implements an outer join, i.e. all the contents of the primary table of the help view are always displayed. You therefore should not formulate a selection condition for fields in one of the secondary tables of the help view. If records of these secondary tables cannot be read as a result of this selection condition, the contents of the corresponding fields of the secondary table are displayed with initial value.

Search Helps :

The input help (F4 help) is a standard function of the R/3 System. The user can display the list of all possible input values for a screen field with the input help. The possible input values can be enhanced with further information. This is meaningful especially when the field requires the input of a formal key.

Standard Input Help Process

A user calls an input help with the following steps (some steps can be omitted, depending on the definition of the input help):

The user starts the input help to display the possible input values for a field (search field) in a screen template.

The system offers the user a number of possible search paths. The user selects one of these search paths. Each search path offers a number of restrictions to limit the number of possible input values. These values are offered in a Dialog box for value restriction when the search path is selected.

The user enters restrictions if required and then starts the search.

The system determines the values that satisfy the entered restrictions (hits) and displays them as a list (hit list).

The user selects the most suitable line from the hit list by double-clicking. The value of the search field is returned to the screen template (possibly together with other values).

Steps 2 and 3 are omitted if there is only a single search path available. In this case the dialog box for the value selection is offered immediately. You can also output the hit list directly after starting the input help. Steps 2 to 4 are omitted in this case.

Function of a Search Help

This standard process can be completely defined by creating a search help in the ABAP Dictionary. This search help only has to be assigned to the screen fields in which they should be available .

There are two types of search help:

· Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behavior of the search help).

· Collective search helps combine several elementary search helps. A collective search help thus can offer several alternative search paths.

Maintenance Views :

Maintenance views offer easy ways to maintain complex application objects.

Data distributed on several tables often forms a logical unit, for example an application object, for the user. You want to be able to display, modify and create the data of such an application object together. Normally the user is not interested in the technical implementation of the application object, that is in the distribution of the data on several tables.

A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.

All the tables in a maintenance view must be linked with foreign keys, that is the join conditions for maintenance views are always derived from the foreign key

cannot directly enter the join conditions as for database views.

There are some restrictions for the attributes of the foreign keys with which the tables in a maintenance view can be linked .

A standardized table maintenance transaction is provided (SM30), permitting you to maintain the data from the base tables of a maintenance view together.

Maintenance mechanisms, like screens and processing programs, must be created from the view definition with the transaction Generate Table View (SE54). This makes it possible to create easy-to-use maintenance interfaces in a simple manner.


Choosing a Table Type

The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

Table type

The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:

Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.

Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.

Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.















ABAP-List of SAPMF05A Transactions

Program SAPMF05A occurs in the following transactions:

Transaction code - (Screen number) - Text

ABAD - (0100) - Asset retirement, sale to customer

ABF1 - (0100) - Post document

ABZK - (0100) - Asset acquisition, purchase from vendor

ABZV - (0122) - Asset acquisition to clearing account

F-01 - (01009 - Enter sample document

F-02 - (0100) - Enter G/L account posting

F-03 - (0131) - G/L account clearing

F-04 - (0122) - Release clearing

F-05 - (0100) - Post foreign currency valuation

F-06 - (0103) - Post incoming payment

F-07 - (0103) - Post outgoing payment

F-19 - (0116) - Reset statistical posting

F-20 - (0102) - Reset bill of exchange commitment

F-21 - (0100) - Enter transfer posting

F-22 - (0100) - Enter customer invoice

F-25 - (0116) - Release check/bill of exchange

F-26 - (0123) - Incoming payment fast entry

F-27 - (0100) - Enter customer credit memo

F-28 - (0103) - Post incoming payment

F-29 - (0111) - Post customer down payment

F-30 - (0122) - Transfer posting and clearing

F-31 - (0103) - Post outgoing payment

F-32 - (0131) - Customer clearing

F-33 - (0101) - Post bill of exchange usage

F-34 - (0101) - Post collection

F-35 - (0101) - Post forfaiting

F-36 - (0122) - Bill of exchange payment

F-37 - (0113) - Customer down payment request

F-38 - (0109) - Enter statistical posting

F-39 - (0115) - Release customer down payment

F-40 - (0122) - Bill of exchange payment

F-41 - (0100) - Enter vendor credit memo

F-42 - (0100) - Enter transfer posting

F-43 - (0100) - Enter vendor invoice

F-44 - (0131) - Vendor clearing

F-46 - (0121) - Reset refinancing acceptance

F-47 - (0112) - Down payment request

F-48 - (0110) - Post vendor down payment

F-49 - (0108) - Customer held items

F-51 - (0122) - Transfer posting and clearing

F-52 - (0103) - Post incoming payment

F-53 - (0103) - Post outgoing payment

F-54 - (0114) - Release vendor down payment

F-55 - (0109) - Enter statistical posting

F-56 - (0116) - Reset statistical posting

F-57 - (0108) - Vendor held items

F-90 - (0100) - Asset acquisition, purchase from vendor

F-91 - (0122) - Asset acquisition to clearing account

F-92 - (0100) - Asset retirement, sale to customer

FB01 - (0100) - Post document

FB05 - (0122) - Posting with clearing

FB08 - (0105) - Reverse document

FB10 - (0126) - Invoice/credit memo fast entry

FB11 - (0107) - Post held document

FB1D - (0131) - Customer clearing

FB1K - (0131) - Vendor clearing

FB1S - (0131) - G/L account clearing

FB21 - (0109) - Enter statistical posting

FB22 - (0116) - Reset statistical posting

FB31 - (0108) - Enter held items

FB41 - (0100) - Post tax payable

FBA1 - (0113) - Customer down payment request

FBA2 - (0111) - Post customer down payment

FBA3 - (0115) - Release customer down payment

FBA6 - (0112) - Vendor down payment request

FBA7 - (0110) - Post vendor down payment

FBA8 - (0114) - Release vendor down payment

FBB1 - (0100) - Post foreign currency valuation

FBD1 - (0106) - Enter recurring entry

FBD5 - (0125) - Realize recurring entry

FBM1 - (0100) - Enter sample document

FBP1 - (0132) - Entering Payment Requests

FBR1 - (0104) - Posting with reference document

FBR2 - (0104) - Post document

FBS1 - (0100) - Enter accruals document

FBVB - (0100) - Post parked document

FBW1 - (0119) - Enter bill of exchange receivable

FBW2 - (0120) - Post bill of exchange in accordance with request

FBW3 - (0101) - Post bill of exchange usage

FBW4 - (0102) - Reset bill of exchange commitment

FBW5 - (0117) - Check/bill of exchange (customer)

FBW6 - (0118) - Check/bill of exchange (vendor)

FBZ1 - (0103) - Post incoming payment

FBZ2 - (0103) - Post outgoing payment

FBZ3 - (0123) - Incoming payment fast entry

FBZ4 - (0130) - Payment with printing

ABAP-DART Standard Views

The views mentioned refer to the data catalog of the DART Version 2.4:

1SAP_FI01 - FI document header and item data

1SAP_FI02 - Vendor transactions

1SAP_FI03 - Customer transactions

1SAP_FI04 - G/L account transactions

1SAP_FI05 - Vendor transactions CPD

1SAP_FI06 - Customer transactions CPD

1SAP_FI07 - G/L account transaction figures

1SAP_FI08 - Open items - Vendors

1SAP_FI09 - Open items - Customers

1SAP_FI10 - Vendor VAT ID and master data

1SAP_FI11 - Customer VAT ID and master data

1SAP_XX01 - Dependency of tables and domains

ABAP-EDI and ALE Tables

EDI - Electronic Data Interchange

(Electronic Data Exchange is a technology to create and run distributed applications.)

EDIDC - Control record

EDIDS - Status records

EDIDD - Data records (2.x)

EDID2 - Data records (3.x)

EDID4 - Data records (4.x)

EDISEG -Idoc segments (3.x)

EDISEGMENT - Idoc segments (4.x)

EDFI2 - Last processed document in file

ALE - Application Link Enabling

(ALE is a mechanism for the exchange of business data between loosely-coupled R/3 applications, built by customers of SAP.)

TBD00 - Views of customer distribution model

TBD03 - Distribution model (3.x)

TBD05 - Distribution model for messages (4.x)

TBD06 - Distribution model for BAPI methods (4.x)

TBD52 - Function modules for inbound processing

TBDLS - Logical systems

TBDSE - Serialization groups (4.x)

BDCP - Change pointers

BDCPS - Status of change pointers

CDHDR - Change document header

CDPOS - Change document items

ARFC(S/R)STATE - Status of tRFC calls on (S)ender and (R)eceiver side

ARFC(S/R)DATA - tRFC call data for (S)ender and (R)eceiver