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
Monday, November 24, 2008
Sunday, November 23, 2008
TYPES OF VIEWS IN SAP
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.
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.
TABLE TYPES IN SAP
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.
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.
TABLE TYPES IN SAP
TABLE TYPES IN SAP
TYPES OF VIEWS IN SAP
ABAP DATA BASE UPDATES COMPLETE
SAP LOCK CONCEPT
ORGANIZING DATA BASE UPDATES
ENHANCEMENTS TO DICTIONARY ELEMENTS
DATABASE DIALOG
ABAP DICTIONARY
PERFORMANCE DURING TABLE ACCESS
DEPENDENCIES OF DICTIONARY OBJECTS
CHANGES TO DATA BASE TABLES
VIEWS IN ABAP
SEARCH HELP
TYPES OF VIEWS IN SAP
ABAP DATA BASE UPDATES COMPLETE
SAP LOCK CONCEPT
ORGANIZING DATA BASE UPDATES
ENHANCEMENTS TO DICTIONARY ELEMENTS
DATABASE DIALOG
ABAP DICTIONARY
PERFORMANCE DURING TABLE ACCESS
DEPENDENCIES OF DICTIONARY OBJECTS
CHANGES TO DATA BASE TABLES
VIEWS IN ABAP
SEARCH HELP
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
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
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
(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
Subscribe to:
Posts (Atom)