HR_99S_INTERVAL_BETWEEN_DATES : Difference between two dates in days, weeks, months
WEEK_GET_FIRST_DAY : Get the first day of the week
FIMA_DAYS_AND_MONTHS_AND_YEARS : Find the difference between two dates in years, months and days.
DATE_TO_DAY : Returns the Day for the entered date.
Wednesday, July 29, 2009
Color single row in ALV
REPORT z_alv_color.
TYPE-POOLS: slis.
DATA: BEGIN OF it_flight OCCURS 0,
carrid LIKE sflight-carrid,
connid LIKE sflight-connid,
fldate LIKE sflight-fldate,
seatsmax LIKE sflight-seatsmax,
seatsocc LIKE sflight-seatsocc,
color(4),
END OF it_flight.
DATA: it_fieldcat TYPE slis_t_fieldcat_alv,
layout TYPE slis_layout_alv.
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
i_program_name = sy-repid
i_internal_tabname = 'IT_FLIGHT'
i_inclname = sy-repid
CHANGING
ct_fieldcat = it_fieldcat
EXCEPTIONS
inconsistent_interface = 1
program_error = 2.
SELECT carrid
connid
fldate
seatsmax
seatsocc
FROM sflight
INTO CORRESPONDING FIELDS OF TABLE it_flight
UP TO 20 ROWS.
*-conditionally populate the color
LOOP AT it_flight.
IF it_flight-seatsocc eq 0.
it_flight-color = 'C600'.
ENDIF.
MODIFY it_flight.
ENDLOOP.
*-Pass the color field information to layout
layout-info_fieldname = 'COLOR'.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
i_callback_program = sy-repid
is_layout = layout
it_fieldcat = it_fieldcat
TABLES
t_outtab = it_flight
EXCEPTIONS
program_error = 1.
TYPE-POOLS: slis.
DATA: BEGIN OF it_flight OCCURS 0,
carrid LIKE sflight-carrid,
connid LIKE sflight-connid,
fldate LIKE sflight-fldate,
seatsmax LIKE sflight-seatsmax,
seatsocc LIKE sflight-seatsocc,
color(4),
END OF it_flight.
DATA: it_fieldcat TYPE slis_t_fieldcat_alv,
layout TYPE slis_layout_alv.
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
i_program_name = sy-repid
i_internal_tabname = 'IT_FLIGHT'
i_inclname = sy-repid
CHANGING
ct_fieldcat = it_fieldcat
EXCEPTIONS
inconsistent_interface = 1
program_error = 2.
SELECT carrid
connid
fldate
seatsmax
seatsocc
FROM sflight
INTO CORRESPONDING FIELDS OF TABLE it_flight
UP TO 20 ROWS.
*-conditionally populate the color
LOOP AT it_flight.
IF it_flight-seatsocc eq 0.
it_flight-color = 'C600'.
ENDIF.
MODIFY it_flight.
ENDLOOP.
*-Pass the color field information to layout
layout-info_fieldname = 'COLOR'.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
i_callback_program = sy-repid
is_layout = layout
it_fieldcat = it_fieldcat
TABLES
t_outtab = it_flight
EXCEPTIONS
program_error = 1.
Sunday, June 7, 2009
Important tables in FI
Financial Accounting tables
BKPF Accounting Document Header
BSEG Accounting Document Segment
BSID Accounting: Secondary Index for Customers
BSAD Accounting: Secondary Index for Customers (Cleared Items)
BSIK Accounting: Secondary Index for Vendors
BSAK Accounting: Secondary Index for Vendors (Cleared Items)
BSIP Index for Vendor Validation
BVOR Inter Company Posting Procedure
FRUN Run Date of a Program
KNB4 Customer Payment History
KNB5 Customer Master Dunning Data
KNBK Customer Master Bank Details
KNC1 Customer Master Transaction Figures
KNC3 Customer Master Special GL Transactions Figures
LFB5 Vendor Master Dunning Data
LFBK Vendor Master Bank Details
LFC1 Vendor Master Transaction Figures
LFC3 Vendor Master Special GL Transactions
KNB1 Customer Master (Company Code)
LFA1 Vendor Master (General Section)
LFB1 Vendor Master (company Code Section)
SKA1 G/L Account Master (Chart of Accounts)
SKAT G/L Account Master (Chart of Accounts Description)
BKPF Accounting Document Header
BSEG Accounting Document Segment
BSID Accounting: Secondary Index for Customers
BSAD Accounting: Secondary Index for Customers (Cleared Items)
BSIK Accounting: Secondary Index for Vendors
BSAK Accounting: Secondary Index for Vendors (Cleared Items)
BSIP Index for Vendor Validation
BVOR Inter Company Posting Procedure
FRUN Run Date of a Program
KNB4 Customer Payment History
KNB5 Customer Master Dunning Data
KNBK Customer Master Bank Details
KNC1 Customer Master Transaction Figures
KNC3 Customer Master Special GL Transactions Figures
LFB5 Vendor Master Dunning Data
LFBK Vendor Master Bank Details
LFC1 Vendor Master Transaction Figures
LFC3 Vendor Master Special GL Transactions
KNB1 Customer Master (Company Code)
LFA1 Vendor Master (General Section)
LFB1 Vendor Master (company Code Section)
SKA1 G/L Account Master (Chart of Accounts)
SKAT G/L Account Master (Chart of Accounts Description)
Important tables in PP
Production Planning Tables
STKO BOM Header
STPO BOM Positions (detail)
MAPL Assignment fo Task Lists to Materials
PLKO Routing Group Header
PLSO Routing Group Sequence
PLPO Routing Group Operations
AFKO Production Order Header
AFPO Production Order Position (details)
STKO BOM Header
STPO BOM Positions (detail)
MAPL Assignment fo Task Lists to Materials
PLKO Routing Group Header
PLSO Routing Group Sequence
PLPO Routing Group Operations
AFKO Production Order Header
AFPO Production Order Position (details)
Important tables in MM
Materials Management Tables
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
Purchasing TablesA501 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
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
Purchasing TablesA501 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
Important tables in SD
Sales and Distribution Tables
KONV Conditions for Transaction Data
KONP Conditions for Items
LIKP Delivery Header Data
LIPS Delivery: Item data
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBBE Sales Requirements: Individual Records
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBFA Sales Document Flow
VBLB Sales document: Release order data
VBLK SD Document: Delivery Note Header
VBPA Sales Document: Partner
VBRK Billing: Header Data
VBRP Billing: Item Data
VBUK Sales Document: Header Status and Administrative Data
VBUP Sales Document: Item Status
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)
VEPVG Delivery Due Index
KONV Conditions for Transaction Data
KONP Conditions for Items
LIKP Delivery Header Data
LIPS Delivery: Item data
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBBE Sales Requirements: Individual Records
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBFA Sales Document Flow
VBLB Sales document: Release order data
VBLK SD Document: Delivery Note Header
VBPA Sales Document: Partner
VBRK Billing: Header Data
VBRP Billing: Item Data
VBUK Sales Document: Header Status and Administrative Data
VBUP Sales Document: Item Status
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)
VEPVG Delivery Due Index
Reports
Reports:
A report is an executable program which takes some input, fetches the relevant data, processes it and gives some output.
There are 7 types of reports. They are:
1. Interactive reports
2. Classic reports
3. Logical database reports
4. Alv reports
5. Graphic reports.
6. ABAP query
7. Report writer.
1. Classical Reports
In classic reports, we can see the output in single list where as in interactive reports we can see the output in multiple lists.
These are the simplest reports. Programmers learn this one first. It is just an output of data using the Write statement inside a loop.
• Classical reports are normal reports. These reports are not having any sub reports. IT IS HAVING ONLY ONE SCREEN/LIST FOR OUTPUT.
Events In Classical Reports.
• INTIALIZATION: This event triggers before selection screen display.
• AT-SELECTION-SCREEN: This event triggers after processing user input still selection screen is in active mode.
• START OF SELECTION: Start of selection screen triggers after processing selection screen.
• END-OF-SELECTION: It is for Logical Database Reporting.
2. Interactive Reports
As the name suggests, the user can Interact with the report. We can have a drill down into the report data. For example, Column one of the report displays the material numbers, and the user feels that he needs some more specific data about the vendor for that material, he can HIDE that data under those material numbers.
And when the user clicks the material number, another report (actually sub report/secondary list) which displays the vendor details will be displayed.
We can have a basic list (number starts from 0) and 20 secondary lists (1 to 21).
Events associated with Interactive Reports are:
1. AT LINE-SELECTION
2. AT USER-COMMAND
3. AT PF
4. TOP-OF-PAGE DURING LINE-SELECTION.
HIDE statement holds the data to be displayed in the secondary list.
sy-lisel: contains data of the selected line.
sy-lsind : contains the level of report (from 0 to 21)
Interactive Report Events:
• AT LINE-SELECTION : This Event triggers when we double click a line on the list, when the event is triggered a new sublist is going to be generated. Under this event what ever the statements that are been return will be displayed on newly generated sublist.
• AT PFn: For predefined function keys...
• AT USER-COMMAND : It provides user functions keys.
• TOP-OF-PAGE DURING LINE-SELECTION :top of page event for secondary list.
3.Logical Database Reports
Logical database is another tool for ABAP reports. Using LDB we can provide extra features for ABAP reports.
While using LDB there is no need for us to declare Parameters.
Selection-screen as they will be generated automatically.
We have to use the statement NODES in ABAP report.
If there are many tables the Performance will be slow as all the table data will be read from top node to bottom node .
4. Alv reports
ALV means ABAP List Viewer.
ALV is available in two modes: list and grid. List mode is good old list processing with standard functionalities, and grid mode is using a new OCX object displaying grids
ALV LIST- the commonly used ALV functions are
1.REUSE_ALV_VARIANT_DEFAULT_GET
2.REUSE_ALV_VARIANT_F4
3.REUSE_ALV_VARIANT_EXISTENCE
4.REUSE_ALV_EVENTS_GET
5.REUSE_ALV_COMMENTARY_WRITE
6.REUSE_ALV_FIELDCATALOG_MERGE
7.REUSE_ALV_LIST_DISPLAY
8.REUSE_ALV_POPUP_TO_SELECT
5) Graphical reports
Graphical -- Redirecting sap data into Business graphics
Here by using
Graph_2D, Graph_3D function modules we can get the 2D and 3D graphical reports.
6. ABAP Query Reports
ABAP query is another tool for ABAP. It provides efficency for ABAP reports. These reports are very accurate.
Transaction Code : SQ01
Report Writer
Key Concept :
Super users and end users can use Report Painter/Report Writer tools to write their own reports.
Giving them the ability to report on additional fields at their discretion shifts the report maintenance burden to them, saving SAP support groups time and effort normally spent creating and maintaining the reports.
Instead of using ABAP code to write a report in FI and CO, many users build a Report Painter/ Report Writer library using transaction MC27.
However, this workaround has some drawbacks. Little known transaction GRCT solves these problems in most cases, and eliminates the need to use transaction MC27.
7. report painter / report writer
You use the Report Painter to create reports from data in the Special Purpose Ledger (FI-SL) application component and other SAP application components to meet your specific reporting requirements.
Many reporting requirements can be met using the standard reports provided by various SAP application components. However, if your reporting requirements are not fulfilled by SAP’s standard reports, you can use the Report Painter to quickly and easily define your own reports.
The Special Purpose Ledger (FI-SL) application component does not provide any standard Report Painter reports because you must first install your FI-SL system setup (database tables and so on) to meet your specific business requirements.
Advantages of the Report Painter include:
• Easy and flexible report definition
• Report definition without using sets
• Direct layout control
In addition to the Report painter, you can use the Report Writer to define reports. You use the Report Writer to create reports from data in the Special Purpose Ledger (FI-SL) application component and other SAP application components to meet your specific reporting requirements.
The Report Writer is a tool using which you can define reports.
Many reporting requirements can be met using the standard reports provided by various SAP application components. However, if your reporting requirements are not fulfilled by SAP's standard reports, you can also define complex reports using the Report Writer.
With the Report Writer, you can organize reports to meet the specific needs of your enterprise. The Report Writer uses reporting building blocks, such as sets, which can be used in any report.
ABAP Report Types
ABAP report types are those ones available in some report's attributes screen, i.e. :
• Executable program
• Function group (containing function modules)
• Include
• Interface pool
• Class pool
• Module pool
• Subroutine pool
A report is an executable program which takes some input, fetches the relevant data, processes it and gives some output.
There are 7 types of reports. They are:
1. Interactive reports
2. Classic reports
3. Logical database reports
4. Alv reports
5. Graphic reports.
6. ABAP query
7. Report writer.
1. Classical Reports
In classic reports, we can see the output in single list where as in interactive reports we can see the output in multiple lists.
These are the simplest reports. Programmers learn this one first. It is just an output of data using the Write statement inside a loop.
• Classical reports are normal reports. These reports are not having any sub reports. IT IS HAVING ONLY ONE SCREEN/LIST FOR OUTPUT.
Events In Classical Reports.
• INTIALIZATION: This event triggers before selection screen display.
• AT-SELECTION-SCREEN: This event triggers after processing user input still selection screen is in active mode.
• START OF SELECTION: Start of selection screen triggers after processing selection screen.
• END-OF-SELECTION: It is for Logical Database Reporting.
2. Interactive Reports
As the name suggests, the user can Interact with the report. We can have a drill down into the report data. For example, Column one of the report displays the material numbers, and the user feels that he needs some more specific data about the vendor for that material, he can HIDE that data under those material numbers.
And when the user clicks the material number, another report (actually sub report/secondary list) which displays the vendor details will be displayed.
We can have a basic list (number starts from 0) and 20 secondary lists (1 to 21).
Events associated with Interactive Reports are:
1. AT LINE-SELECTION
2. AT USER-COMMAND
3. AT PF
4. TOP-OF-PAGE DURING LINE-SELECTION.
HIDE statement holds the data to be displayed in the secondary list.
sy-lisel: contains data of the selected line.
sy-lsind : contains the level of report (from 0 to 21)
Interactive Report Events:
• AT LINE-SELECTION : This Event triggers when we double click a line on the list, when the event is triggered a new sublist is going to be generated. Under this event what ever the statements that are been return will be displayed on newly generated sublist.
• AT PFn: For predefined function keys...
• AT USER-COMMAND : It provides user functions keys.
• TOP-OF-PAGE DURING LINE-SELECTION :top of page event for secondary list.
3.Logical Database Reports
Logical database is another tool for ABAP reports. Using LDB we can provide extra features for ABAP reports.
While using LDB there is no need for us to declare Parameters.
Selection-screen as they will be generated automatically.
We have to use the statement NODES in ABAP report.
If there are many tables the Performance will be slow as all the table data will be read from top node to bottom node .
4. Alv reports
ALV means ABAP List Viewer.
ALV is available in two modes: list and grid. List mode is good old list processing with standard functionalities, and grid mode is using a new OCX object displaying grids
ALV LIST- the commonly used ALV functions are
1.REUSE_ALV_VARIANT_DEFAULT_GET
2.REUSE_ALV_VARIANT_F4
3.REUSE_ALV_VARIANT_EXISTENCE
4.REUSE_ALV_EVENTS_GET
5.REUSE_ALV_COMMENTARY_WRITE
6.REUSE_ALV_FIELDCATALOG_MERGE
7.REUSE_ALV_LIST_DISPLAY
8.REUSE_ALV_POPUP_TO_SELECT
5) Graphical reports
Graphical -- Redirecting sap data into Business graphics
Here by using
Graph_2D, Graph_3D function modules we can get the 2D and 3D graphical reports.
6. ABAP Query Reports
ABAP query is another tool for ABAP. It provides efficency for ABAP reports. These reports are very accurate.
Transaction Code : SQ01
Report Writer
Key Concept :
Super users and end users can use Report Painter/Report Writer tools to write their own reports.
Giving them the ability to report on additional fields at their discretion shifts the report maintenance burden to them, saving SAP support groups time and effort normally spent creating and maintaining the reports.
Instead of using ABAP code to write a report in FI and CO, many users build a Report Painter/ Report Writer library using transaction MC27.
However, this workaround has some drawbacks. Little known transaction GRCT solves these problems in most cases, and eliminates the need to use transaction MC27.
7. report painter / report writer
You use the Report Painter to create reports from data in the Special Purpose Ledger (FI-SL) application component and other SAP application components to meet your specific reporting requirements.
Many reporting requirements can be met using the standard reports provided by various SAP application components. However, if your reporting requirements are not fulfilled by SAP’s standard reports, you can use the Report Painter to quickly and easily define your own reports.
The Special Purpose Ledger (FI-SL) application component does not provide any standard Report Painter reports because you must first install your FI-SL system setup (database tables and so on) to meet your specific business requirements.
Advantages of the Report Painter include:
• Easy and flexible report definition
• Report definition without using sets
• Direct layout control
In addition to the Report painter, you can use the Report Writer to define reports. You use the Report Writer to create reports from data in the Special Purpose Ledger (FI-SL) application component and other SAP application components to meet your specific reporting requirements.
The Report Writer is a tool using which you can define reports.
Many reporting requirements can be met using the standard reports provided by various SAP application components. However, if your reporting requirements are not fulfilled by SAP's standard reports, you can also define complex reports using the Report Writer.
With the Report Writer, you can organize reports to meet the specific needs of your enterprise. The Report Writer uses reporting building blocks, such as sets, which can be used in any report.
ABAP Report Types
ABAP report types are those ones available in some report's attributes screen, i.e. :
• Executable program
• Function group (containing function modules)
• Include
• Interface pool
• Class pool
• Module pool
• Subroutine pool
Wednesday, May 20, 2009
BAPI
A Business Application Programming Interface (BAPI) is a precisely defined interface providing access to processes and data in business application systems such as R/3.
BAPIs are defined as API methods of SAP business object types. These business object types and their BAPIs are described and stored in the Business Object Repository (BOR). A BAPI is implemented as a function module, that is stored and described in the Function Builder.
As of Release 4.5A BAPIs can also describe interfaces, implemented outside the R/3 System that can be called in external systems by R/3 Systems. These BAPIs are known as BAPIs used for outbound processing. The target system is determined for the BAPI call in the distribution model of Application Link Enabling (ALE).
BAPIs used for outbound processing are defined in the Business Object Repository (BOR) as API methods of SAP Interface Types. Functions implemented outside the R/3 System can be standardized and made available as BAPIs. For further information see BAPIs Used For Outbound Processing.
BAPIs can be called within the R/3 System from external application systems and other programs. BAPIs are the communication standard for business applications. BAPI interface technology forms the basis for the following developments:
· Connecting:
· New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business Information Warehouse (BW).
· Non-SAP software
· Legacy systems
· Isolating components within the R/3 System in the context of Business Framework
· Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)
· Connecting R/3 Systems to the Internet using Internet Application Components (IACs)
· PC programs as front-end to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age for Java (IBM).
· Workflow applications that extend beyond system boundaries
· Customers' and partners' own developments
BAPIs are defined as API methods of SAP business object types. These business object types and their BAPIs are described and stored in the Business Object Repository (BOR). A BAPI is implemented as a function module, that is stored and described in the Function Builder.
As of Release 4.5A BAPIs can also describe interfaces, implemented outside the R/3 System that can be called in external systems by R/3 Systems. These BAPIs are known as BAPIs used for outbound processing. The target system is determined for the BAPI call in the distribution model of Application Link Enabling (ALE).
BAPIs used for outbound processing are defined in the Business Object Repository (BOR) as API methods of SAP Interface Types. Functions implemented outside the R/3 System can be standardized and made available as BAPIs. For further information see BAPIs Used For Outbound Processing.
BAPIs can be called within the R/3 System from external application systems and other programs. BAPIs are the communication standard for business applications. BAPI interface technology forms the basis for the following developments:
· Connecting:
· New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business Information Warehouse (BW).
· Non-SAP software
· Legacy systems
· Isolating components within the R/3 System in the context of Business Framework
· Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)
· Connecting R/3 Systems to the Internet using Internet Application Components (IACs)
· PC programs as front-end to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age for Java (IBM).
· Workflow applications that extend beyond system boundaries
· Customers' and partners' own developments
ALE
Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems.
In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment the distributed applications have to be linked. This can be done through Application Link Enabling (ALE).
ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes.
Besides the business processes there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization and tools for monitoring or error handling. ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework
Different types of views
Views:
A view is a logical view on one or more tables, that is, a view is not actually physically stored, instead being derived from one or more other tables.
Types:
Database views
The view defined in the ABAP Dictionary is reproduced in the underlying database. You can use both ABAP Open SQL and ABAP Native SQL to access such views from ABAP programs, but you can only define them using transparent tables. If you define a database view using only one table, you can make changes to the view. For database views containing several tables, however, only read accesses are allowed.
Projection views
Projection views are used to suppress certain fields from a table in the interests of minimizing interfaces. A projection view can only refer to one table and, in contrast to database views, you cannot specify any restrictions with regard to table type. This view type also permits both read and write accesses with ABAP Open SQL.
Help views
Help views are used as the selection method of elementary search helps if the selection is too complex to be defined with a single database table. In contrast to database views, help views implement an outer join. For this reason they are suitable for linking supplementary information such as explanatory text from secondary tables. If the supplementary information were missing in an inner join, the entire dataset would not be selected.
Maintenance views
Maintenance views provide you with a business view of the data. You can change it either with the table maintenance transaction SM30, which allows you to maintain data from the base tables in a view at the same time, or with the customizing transaction. The mechanisms for data maintenance such as screens and processing programs can be created with a special transaction (SE54).
A view is a logical view on one or more tables, that is, a view is not actually physically stored, instead being derived from one or more other tables.
Types:
Database views
The view defined in the ABAP Dictionary is reproduced in the underlying database. You can use both ABAP Open SQL and ABAP Native SQL to access such views from ABAP programs, but you can only define them using transparent tables. If you define a database view using only one table, you can make changes to the view. For database views containing several tables, however, only read accesses are allowed.
Projection views
Projection views are used to suppress certain fields from a table in the interests of minimizing interfaces. A projection view can only refer to one table and, in contrast to database views, you cannot specify any restrictions with regard to table type. This view type also permits both read and write accesses with ABAP Open SQL.
Help views
Help views are used as the selection method of elementary search helps if the selection is too complex to be defined with a single database table. In contrast to database views, help views implement an outer join. For this reason they are suitable for linking supplementary information such as explanatory text from secondary tables. If the supplementary information were missing in an inner join, the entire dataset would not be selected.
Maintenance views
Maintenance views provide you with a business view of the data. You can change it either with the table maintenance transaction SM30, which allows you to maintain data from the base tables in a view at the same time, or with the customizing transaction. The mechanisms for data maintenance such as screens and processing programs can be created with a special transaction (SE54).
Types of tables in Data Dictionary
Transparent table
There is a physical table on the database for each transparent table. The names of the physical tables and the logical table definition in the ABAP/4 Dictionary correspond.
All business data and application data are stored in transparent tables.
On the other hand, pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and technical settings for pooled and cluster tables.
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
There is a physical table on the database for each transparent table. The names of the physical tables and the logical table definition in the ABAP/4 Dictionary correspond.
All business data and application data are stored in transparent tables.
On the other hand, pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and technical settings for pooled and cluster tables.
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
How to Debug a Sap Script ?
They are two ways to debug the SAP Script.
1. Use Tools - Word Processing - Layout Set (SE71). Enter name of layout set and then Utilities - Activate Debugger. It is of no consequence which layout set you enter when selecting the SAP script debugger. (Menu path: Tools-Word processing - Forms, Utilities - Activate Debugger) The next layout set called will invoke the debugger.
2. Another way to set the SAP Script debugger is to run program RSTXDBUG.
When you debug Print program it is same as you debug any other ABAP program. While when you debug SAP Script, you actually debug the code ( scripting) you have written SAP Script Form.In transaction SMARTFORMS look up the name of the generated function module for your smart form. Copy the name and go to transaction SE37. Get into the source code of the function module; via menu Go to -> Main Program and then find your piece of code by SEARCH 'VBELN1 = GS_HD_REF-ORDER_NUMB'. Put a breakpoint there and print your smart form. It will stop at the breakpoint.Script: In SE71 give your form name and in Utilities-->Active debugger.Then put a break point in your print program where ever you want to stop it.After that you need to go to your transaction like VF03/../..Etc for Invoice you need to execute it by giving Output type. Then it will debug step by step .
1. Use Tools - Word Processing - Layout Set (SE71). Enter name of layout set and then Utilities - Activate Debugger. It is of no consequence which layout set you enter when selecting the SAP script debugger. (Menu path: Tools-Word processing - Forms, Utilities - Activate Debugger) The next layout set called will invoke the debugger.
2. Another way to set the SAP Script debugger is to run program RSTXDBUG.
When you debug Print program it is same as you debug any other ABAP program. While when you debug SAP Script, you actually debug the code ( scripting) you have written SAP Script Form.In transaction SMARTFORMS look up the name of the generated function module for your smart form. Copy the name and go to transaction SE37. Get into the source code of the function module; via menu Go to -> Main Program and then find your piece of code by SEARCH 'VBELN1 = GS_HD_REF-ORDER_NUMB'. Put a breakpoint there and print your smart form. It will stop at the breakpoint.Script: In SE71 give your form name and in Utilities-->Active debugger.Then put a break point in your print program where ever you want to stop it.After that you need to go to your transaction like VF03/../..Etc for Invoice you need to execute it by giving Output type. Then it will debug step by step .
Subscribe to:
Posts (Atom)