SAP System Landscape:
(Kind Note: In this post i going to give a short hint about SAP system landscape don't consider this as a SAP Architecture. Often
times, SAP users, especially new comers misunderstands these two concepts.)
They system landscape basically is the set-up or arrangement of your SAP servers. Ideally, in an SAP environment, a three-system
landscape exists. A three-system landscape consists of the Development Server-DEV, Quality Assurance Server-QAS and the
Production Server-PROD. This kind of set-up is not primarily designed to serve as server clusters in case of system failure, the
objective to enhance "configuration pipeline management".
A Typical SAP Three-System Landscape would consist of one or two development system ==> one Quality system ==> Production
system. (but it is not must to keep separate server for each systems, you can configure DEV & QAS on a same server but it is
not advisable to keep PROD too in the same server)
Pipeline is the environment where the configuration in the development system is moved to the quality assurance system and finally
to the production system. The whole idea is to sync the configuration of these systems at any point in time.
Devlopment/configuration/changes are first made in the Development system, thoroughly tested in the Quality Assurance system
then loaded into the production system. TMS Does this process nicely. Transport management system is the coordination of the
movement of objects and configuration changes from the development system to the Quality Assurance system and then to the
Production system.
Tuesday, October 25, 2011
Friday, September 2, 2011
Wednesday, July 27, 2011
SAP MM module
SAP MM is the materials management module of the SAP ERP software package from SAP AG that is used for Procurement Handling and Inventory Management. Materials management is integrated with other modules such as SD, PP and QM. Materials management is used for procurement and inventory management.
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization.
SAP Materials management covers all tasks within the supply chain, including consumption-based planning, planning, vendor evaluation and invoice verification. It also includes inventory and warehouse management to manage stock until usage dictates the cycle should begin again. Electronic Kanban/Just-in-Time delivery is supported.
It can be divided into five major components. There are: materials management, plant maintenance, quality management, production planning and control, and a project management system. Each is divided into number of subcomponents.
SAP MM is all about managing the materials i.e the resources of an organization. These resources include man, manpower and materials. The main functionality within MM includes purchasing, Inventory management, valuation and assignment, batch management and classification
SAP MM Module :
SAP MM is the materials management module of the SAP ERP software package from SAP AG that is used for Procurement Handling and Inventory Management. Materials management is integrated with other modules such as SD, PP and QM. Materials management is used for procurement and inventory management.
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization.
SAP Materials management covers all tasks within the supply chain, including consumption-based planning, planning, vendor evaluation and invoice verification. It also includes inventory and warehouse management to manage stock until usage dictates the cycle should begin again. Electronic Kanban/Just-in-Time delivery is supported.
It can be divided into five major components. There are: materials management, plant maintenance, quality management, production planning and control, and a project management system. Each is divided into number of subcomponents.
SAP MM is all about managing the materials i.e the resources of an organization. These resources include man, manpower and materials. The main functionality within MM includes purchasing, Inventory management, valuation and assignment, batch management and classification
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization.
SAP Materials management covers all tasks within the supply chain, including consumption-based planning, planning, vendor evaluation and invoice verification. It also includes inventory and warehouse management to manage stock until usage dictates the cycle should begin again. Electronic Kanban/Just-in-Time delivery is supported.
It can be divided into five major components. There are: materials management, plant maintenance, quality management, production planning and control, and a project management system. Each is divided into number of subcomponents.
SAP MM is all about managing the materials i.e the resources of an organization. These resources include man, manpower and materials. The main functionality within MM includes purchasing, Inventory management, valuation and assignment, batch management and classification
SAP MM Module :
SAP MM is the materials management module of the SAP ERP software package from SAP AG that is used for Procurement Handling and Inventory Management. Materials management is integrated with other modules such as SD, PP and QM. Materials management is used for procurement and inventory management.
The module has two important master data - material and vendor. Broadly, the various levels that can be defined for a SAP MM implementation are: Client, Company Code, Plant, Storage Location and Purchase Organization.
SAP Materials management covers all tasks within the supply chain, including consumption-based planning, planning, vendor evaluation and invoice verification. It also includes inventory and warehouse management to manage stock until usage dictates the cycle should begin again. Electronic Kanban/Just-in-Time delivery is supported.
It can be divided into five major components. There are: materials management, plant maintenance, quality management, production planning and control, and a project management system. Each is divided into number of subcomponents.
SAP MM is all about managing the materials i.e the resources of an organization. These resources include man, manpower and materials. The main functionality within MM includes purchasing, Inventory management, valuation and assignment, batch management and classification
MM Process Flow
MM - Process Flow
Determination of Requirements
The user department responsible is manually passing a requirement for materials to the purchasing department via Purchase Requisition. Purchase requests are generated when business runs the MRP and Request are also generated based in Consumption based planning (CBP) for Production and Engg.Stores.
Determination of Source of Supply
The purchasing component helps the buyer determine the sources of supply. User use the determination of the source of supply to create Requests for quotation (RFQs) and then to enter quotations. User is accessing the existing Purchase Orders and Conditions in the System.
Vendor Selection and Comparison of Quotations
The System is capable of simulating pricing scenarios and simplifies the selection of vendors by making price comparisons between the various quotations.
Purchase Order Processing
The purchasing system adopts information from purchase requisition and the quotation to help to create Purchase Orders. They are also creating manual purchase order directly for stock, non-stock items, services etc.
Purchase Order Monitoring
The buyer monitor the processing status of the purchase order online at any time and determine whether goods or an invoice have been received for the relevant purchase order item.
Goods Receipt and Inventory Management
The Goods receiving requester confirms the receipt of the materials by simply entering the Purchase Order Number. The system compares the goods receipt quantity with the purchase order quantity. By specifying permissible tolerances, buyers can limit over deliveries and under deliveries of ordered materials.
PURCHASING
Purchasing Functionality is integrated with Inventory Management and Invoice Verification within MM.
Determination of Requirements
The user department responsible is manually passing a requirement for materials to the purchasing department via Purchase Requisition. Purchase requests are generated when business runs the MRP and Request are also generated based in Consumption based planning (CBP) for Production and Engg.Stores.
Determination of Source of Supply
The purchasing component helps the buyer determine the sources of supply. User use the determination of the source of supply to create Requests for quotation (RFQs) and then to enter quotations. User is accessing the existing Purchase Orders and Conditions in the System.
Vendor Selection and Comparison of Quotations
The System is capable of simulating pricing scenarios and simplifies the selection of vendors by making price comparisons between the various quotations.
Purchase Order Processing
The purchasing system adopts information from purchase requisition and the quotation to help to create Purchase Orders. They are also creating manual purchase order directly for stock, non-stock items, services etc.
Purchase Order Monitoring
The buyer monitor the processing status of the purchase order online at any time and determine whether goods or an invoice have been received for the relevant purchase order item.
Goods Receipt and Inventory Management
The Goods receiving requester confirms the receipt of the materials by simply entering the Purchase Order Number. The system compares the goods receipt quantity with the purchase order quantity. By specifying permissible tolerances, buyers can limit over deliveries and under deliveries of ordered materials.
PURCHASING
Purchasing Functionality is integrated with Inventory Management and Invoice Verification within MM.
Standard Reports in MM during Implementation & support projects
List of Standard Reports in MM
MB51 Material Doc. List
MB5L List of Stock Values: Balances MBBS Display valuated special stock MC$G PURCHIS: Material PurchVal SelectionMC$I PURCHIS: Material PurchQty SelectionMC.1 INVCO: Plant Anal. Selection: Stock MC.2 INVCO: Plant Anal.Selection, Rec/IssMC.5 INVCO: SLoc Anal. Selection, Stock MC.9 INVCO: Material Anal.Selection,StockMC.A INVCO: Mat.Anal.Selection, Rec/Iss MC.L INVCO: Mat.Group Analysis Sel. StockMC48 INVCO: Anal. of Current Stock ValuesMC50 INVCO: Analysis of Dead Stock MCBA INVCO: Plant Analysis Selection MCBC INVCO: Stor. Loc. Analysis SelectionMCBE INVCO: Material Analysis Selection MCBK INVCO: MatGrp Analysis Selection MCBR INVCO: Batch Analysis Selection MCE1 PURCHIS: PurchGrp Analysis SelectionMCE3 PURCHIS: Vendor Analysis Selection MCE5 PURCHIS: MatGrp Analysis Selection MCE7 PURCHIS: Material Analysis SelectionMCW3 PURCHIS: Evaluate VBD Header MCW4 PURCHIS: Evaluate VBD Item ME2L Purchase Orders by Vendor ME2M Purchase
MB51 Material Doc. List
MB5L List of Stock Values: Balances MBBS Display valuated special stock MC$G PURCHIS: Material PurchVal SelectionMC$I PURCHIS: Material PurchQty SelectionMC.1 INVCO: Plant Anal. Selection: Stock MC.2 INVCO: Plant Anal.Selection, Rec/IssMC.5 INVCO: SLoc Anal. Selection, Stock MC.9 INVCO: Material Anal.Selection,StockMC.A INVCO: Mat.Anal.Selection, Rec/Iss MC.L INVCO: Mat.Group Analysis Sel. StockMC48 INVCO: Anal. of Current Stock ValuesMC50 INVCO: Analysis of Dead Stock MCBA INVCO: Plant Analysis Selection MCBC INVCO: Stor. Loc. Analysis SelectionMCBE INVCO: Material Analysis Selection MCBK INVCO: MatGrp Analysis Selection MCBR INVCO: Batch Analysis Selection MCE1 PURCHIS: PurchGrp Analysis SelectionMCE3 PURCHIS: Vendor Analysis Selection MCE5 PURCHIS: MatGrp Analysis Selection MCE7 PURCHIS: Material Analysis SelectionMCW3 PURCHIS: Evaluate VBD Header MCW4 PURCHIS: Evaluate VBD Item ME2L Purchase Orders by Vendor ME2M Purchase
SAP MM Important tables and important fields
131 T165K Copying Options: Header Texts
132 T165P Copying Options, Item texts
133 T166A Supplement Text in Purchasing Document Printouts
134 T166C Print-Relevant Purchasing Document Changes
135 T166K Header Texts in Purchasing Document Printouts
136 T166P Item Texts in Purchasing Document Printouts
137 T166T Change Texts in Purchasing Document Printouts
138 T166U Headings in Purchasing Document Printout
139 T167 Number Range Management for Purchasing Master Data
140 T167T Transaction Description
141 T168 Screen Control, Purchasing
142 T168F Function Codes, Purchasing
143 T168T Screen Titles
144 T16FB Release Indicators: Purchasing Document
145 T16FC Release Codes
146 T16FD Description of Release Codes
147 T16FE Descriptions of Release Indicators: Purchasing Documents
148 T16FG Release Groups
149 T16FH Descriptions of Release Groups
150 T16FK Release Statuses
151 T16FS Release Strategies
152 T16FT Descriptions of Release Strategies
153 T16FV Release Prerequisites
154 T16FW Assignment of Role to Release Code
155 T16LA Texts on Status of Requisition Processing
156 T16LB Scope of List: Purchase Requisitions
157 T16LC Description of Scope of List: Purchase Requisitions
158 T16LD Routines for Structure of Requisition Lists
159 T16LE Texts for Routines for Structure of Requisition Lists
160 T16LF Routines for Data Retrieval in Requisition Lists
161 T16LG Texts for Routines for Data Retrieval in Requisition Lists
162 T16LH Default List Scope for Requisitions in Transactions
163 T16LI Data Retrieval for List Scope: Purchase Requisitions
164 T16LL Routines for List Scope: Purchase Requisitions
165 T170 Copying Control: Texts in Purchasing
166 T460Q Special Procurement Types per Procurement Type
167
132 T165P Copying Options, Item texts
133 T166A Supplement Text in Purchasing Document Printouts
134 T166C Print-Relevant Purchasing Document Changes
135 T166K Header Texts in Purchasing Document Printouts
136 T166P Item Texts in Purchasing Document Printouts
137 T166T Change Texts in Purchasing Document Printouts
138 T166U Headings in Purchasing Document Printout
139 T167 Number Range Management for Purchasing Master Data
140 T167T Transaction Description
141 T168 Screen Control, Purchasing
142 T168F Function Codes, Purchasing
143 T168T Screen Titles
144 T16FB Release Indicators: Purchasing Document
145 T16FC Release Codes
146 T16FD Description of Release Codes
147 T16FE Descriptions of Release Indicators: Purchasing Documents
148 T16FG Release Groups
149 T16FH Descriptions of Release Groups
150 T16FK Release Statuses
151 T16FS Release Strategies
152 T16FT Descriptions of Release Strategies
153 T16FV Release Prerequisites
154 T16FW Assignment of Role to Release Code
155 T16LA Texts on Status of Requisition Processing
156 T16LB Scope of List: Purchase Requisitions
157 T16LC Description of Scope of List: Purchase Requisitions
158 T16LD Routines for Structure of Requisition Lists
159 T16LE Texts for Routines for Structure of Requisition Lists
160 T16LF Routines for Data Retrieval in Requisition Lists
161 T16LG Texts for Routines for Data Retrieval in Requisition Lists
162 T16LH Default List Scope for Requisitions in Transactions
163 T16LI Data Retrieval for List Scope: Purchase Requisitions
164 T16LL Routines for List Scope: Purchase Requisitions
165 T170 Copying Control: Texts in Purchasing
166 T460Q Special Procurement Types per Procurement Type
167
SAP Implementation Roadmap and Project Plan
SAP Implementation Phases i.e ASAP methodology
ASAP methodology (AcceleratedSAP) : A comprehensive solution for the introduction of the R/3 System in your enterprise. ASAP and most of its tools can be used independently of an R/3 installation. The tools available for ASAP are:
1. Project Estimator, an internal SAP tool which enables SAP consultants to accurately gauge the required resources, the costs and the time frame of implementation. The Project Estimator takes into account the project scope and several project and risk factors.
2. Concept Check Tool, a tool enabling you to carry out quality checks on the project preparation, technical infrastructure and R/3 configuration settings. This is done mainly during the first two implementation phases of the R/3 project. In this way you are alerted to potential data volume and configuration conflicts that could lead to performance issues if not addressed.
3.Implementation Assistant: The ASAP navigation tool that accompanies you through the five phases of implementation down to the task level. It includes a description and a detailed "how-to" for each task in the Roadmap. Along with that, many tools, templates and documents are hyperlinked to the task. The Implementation Assistant contains the following elements:
Generally ASAP incorporates standard design templates and accelerators covering every functional area within the system, as well as supporting all implementation processes. SAP Project Implementation is one of the components of Project Management and required a great degree of project related Knowledge such as Project Management, Change Management, Risk Analysis and Review Programs.
ASAP Implementation Roadmap and Project Plan. The Roadmap contains the five phases namely,
1.Project Preparation Phase – First Phase of SAP Implementation. In this phase, following are discussed and documented ,
• Project Planning & Procedures
• Project Team Members & their Training
• Project Kickoff /Start off /Sign on
• Technical Requirements
2.Business Blueprint Phase - In this phase, all the details of the projects are set, The project manager from implementers side and from client side, then the whole team is selected of both sides, sometimes there are interviews of consultants as well from the client and sign up of the project is done and also each modules consultants will sign up if the project start has big difference in dates. This AS-IS process (existing), the MM consultant and power users from client sit down and jot down all the current settings of the client ,and decides and researched how their current system is configured, and active settings for client process in SAP are framed i.e.Org. Str. like no.of plants, purchase organizations, pur.groups, material groups, material types,no.range for master record, document types ,document types for PR,PO,contract, Framework order(Blanket P.O), Source Lists, MRP type, subcontract, consignment process etc.
Once you get all the data in AS-IS, you create blueprint based on this information which will contain every info, i.e. how many plants will be created, what numbers, how many storage locations with names and numbers for each plant, how many purchase organization with details, purchase groups, document types of prs, pos, with number ranges, release strategy, and total process flow in this documentation and what can and what cant be configured in SAP, thus the TO BE pre-stage to finalized document for client business Process) . Here client views your document and if there are any reservations they are pointed out, if any deletion addition is needed to the document they are notified to the consultants, necessary changes are made to the blueprint and this up/down in changes keeps on going, until the blueprint is signed (Finalized document of the project)detailed study of business processes and business requirements are undertaken by the Project Team members. This is the phase where Project Team Members (SAP Consultants along with Project Manager) interact with respective Core Team Members (Non SAP Consultant) or Process Owners. The whole requirements are gathered in this phase and following are discussed and documented,
• Project Management
• Organizational Change Management
• Training
• Develop System Environment
• Organizational Structure Definition
• Business Process Analysis
• Business Process Definition
3.Realization Phase - In this phase, all the business and process requirements are implemented as documented in Business Blueprint. SAP R/3 system is configured step by step in two work packages, Baseline and Final configuration. How these configurations will be done and how it will be tested.
• Baseline Configuration and Confirmation
• System Management
• Final Configuration and Confirmation
• Development of external Programs & Interfaces
• Unit Testing & Documentation
• Final Integration Test
• Business Scenarios & Process Documentation
• End User Training & Documentation
• Quality Check
4.Final Preparation Phase - During this phase, following activities are discussed, completed and documented, successful completion of these activities leads to transition of all configurations settings to live R/3 System
• System Management
• Stress & Volume Tests
• Cutover Strategies & Plans
• End User Training
• Quality Check
5.Go Live and Support Phase – This is phase where all configurations/customizations are transported to live production operation and business starts all its activities in the SAP R/3.
During this phase, all the problems/issues related to hardware, network, operating system, database, training, and application system are addressed by the project team members and they help the end users in achieving their day to day task/assignments. This phase is further divided as:
• Application Production Support and Maintenance
• Project Implementation End
5.Continuous Improvement Phase – Towards continuous improvement and to overcome the organizational, business & technology changes the followings are covered under this phase:
• Post go-Live Support
• Improve System performance
ASAP methodology (AcceleratedSAP) : A comprehensive solution for the introduction of the R/3 System in your enterprise. ASAP and most of its tools can be used independently of an R/3 installation. The tools available for ASAP are:
1. Project Estimator, an internal SAP tool which enables SAP consultants to accurately gauge the required resources, the costs and the time frame of implementation. The Project Estimator takes into account the project scope and several project and risk factors.
2. Concept Check Tool, a tool enabling you to carry out quality checks on the project preparation, technical infrastructure and R/3 configuration settings. This is done mainly during the first two implementation phases of the R/3 project. In this way you are alerted to potential data volume and configuration conflicts that could lead to performance issues if not addressed.
3.Implementation Assistant: The ASAP navigation tool that accompanies you through the five phases of implementation down to the task level. It includes a description and a detailed "how-to" for each task in the Roadmap. Along with that, many tools, templates and documents are hyperlinked to the task. The Implementation Assistant contains the following elements:
Generally ASAP incorporates standard design templates and accelerators covering every functional area within the system, as well as supporting all implementation processes. SAP Project Implementation is one of the components of Project Management and required a great degree of project related Knowledge such as Project Management, Change Management, Risk Analysis and Review Programs.
ASAP Implementation Roadmap and Project Plan. The Roadmap contains the five phases namely,
1.Project Preparation Phase – First Phase of SAP Implementation. In this phase, following are discussed and documented ,
• Project Planning & Procedures
• Project Team Members & their Training
• Project Kickoff /Start off /Sign on
• Technical Requirements
2.Business Blueprint Phase - In this phase, all the details of the projects are set, The project manager from implementers side and from client side, then the whole team is selected of both sides, sometimes there are interviews of consultants as well from the client and sign up of the project is done and also each modules consultants will sign up if the project start has big difference in dates. This AS-IS process (existing), the MM consultant and power users from client sit down and jot down all the current settings of the client ,and decides and researched how their current system is configured, and active settings for client process in SAP are framed i.e.Org. Str. like no.of plants, purchase organizations, pur.groups, material groups, material types,no.range for master record, document types ,document types for PR,PO,contract, Framework order(Blanket P.O), Source Lists, MRP type, subcontract, consignment process etc.
Once you get all the data in AS-IS, you create blueprint based on this information which will contain every info, i.e. how many plants will be created, what numbers, how many storage locations with names and numbers for each plant, how many purchase organization with details, purchase groups, document types of prs, pos, with number ranges, release strategy, and total process flow in this documentation and what can and what cant be configured in SAP, thus the TO BE pre-stage to finalized document for client business Process) . Here client views your document and if there are any reservations they are pointed out, if any deletion addition is needed to the document they are notified to the consultants, necessary changes are made to the blueprint and this up/down in changes keeps on going, until the blueprint is signed (Finalized document of the project)detailed study of business processes and business requirements are undertaken by the Project Team members. This is the phase where Project Team Members (SAP Consultants along with Project Manager) interact with respective Core Team Members (Non SAP Consultant) or Process Owners. The whole requirements are gathered in this phase and following are discussed and documented,
• Project Management
• Organizational Change Management
• Training
• Develop System Environment
• Organizational Structure Definition
• Business Process Analysis
• Business Process Definition
3.Realization Phase - In this phase, all the business and process requirements are implemented as documented in Business Blueprint. SAP R/3 system is configured step by step in two work packages, Baseline and Final configuration. How these configurations will be done and how it will be tested.
• Baseline Configuration and Confirmation
• System Management
• Final Configuration and Confirmation
• Development of external Programs & Interfaces
• Unit Testing & Documentation
• Final Integration Test
• Business Scenarios & Process Documentation
• End User Training & Documentation
• Quality Check
4.Final Preparation Phase - During this phase, following activities are discussed, completed and documented, successful completion of these activities leads to transition of all configurations settings to live R/3 System
• System Management
• Stress & Volume Tests
• Cutover Strategies & Plans
• End User Training
• Quality Check
5.Go Live and Support Phase – This is phase where all configurations/customizations are transported to live production operation and business starts all its activities in the SAP R/3.
During this phase, all the problems/issues related to hardware, network, operating system, database, training, and application system are addressed by the project team members and they help the end users in achieving their day to day task/assignments. This phase is further divided as:
• Application Production Support and Maintenance
• Project Implementation End
5.Continuous Improvement Phase – Towards continuous improvement and to overcome the organizational, business & technology changes the followings are covered under this phase:
• Post go-Live Support
• Improve System performance
Friday, July 1, 2011
Simple way of defining Select-options in Module Pool Programming
Simple way of defining Select-options in Module Pool Programming
Defining select-options in selection-screen is easy task but in module pool it is slightly tricky.
Selection-screen can be defined as subscreen and can be applied in the subscreen area of module pool program.
Create report with following code.
REPORT zselectoptions.
TABLES : vbrk , vbrp .
SELECTION-SCREEN BEGIN OF SCREEN 400 AS SUBSCREEN.
PARAMETERS : p_vkorg TYPE vbrk-vkorg OBLIGATORY DEFAULT '1000'.
SELECT-OPTIONS : s_vbeln FOR vbrk-vbeln,
s_posnr FOR vbrp-posnr.
SELECTION-SCREEN END OF SCREEN 400 .
START-OF-SELECTION .
CALL SCREEN 100 .
*&---------------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
* SET PF-STATUS 'xxxxxxxx'.
* SET TITLEBAR 'xxx'.
ENDMODULE. " STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
ENDMODULE. " USER_COMMAND_0100 INPUT
Define screen 100 with subcreen area SEL as shown in below .
Define PF status and title bar with any names. This is not shown in screen shot.
Put code in PBO and PAI of screen as shown in below screen shot.
Call subscreen sel including sy-repid ‘400’.
Activate all objects and execute the report you should get following module pool screen with select-options.
Defining select-options in selection-screen is easy task but in module pool it is slightly tricky.
Selection-screen can be defined as subscreen and can be applied in the subscreen area of module pool program.
Create report with following code.
REPORT zselectoptions.
TABLES : vbrk , vbrp .
SELECTION-SCREEN BEGIN OF SCREEN 400 AS SUBSCREEN.
PARAMETERS : p_vkorg TYPE vbrk-vkorg OBLIGATORY DEFAULT '1000'.
SELECT-OPTIONS : s_vbeln FOR vbrk-vbeln,
s_posnr FOR vbrp-posnr.
SELECTION-SCREEN END OF SCREEN 400 .
START-OF-SELECTION .
CALL SCREEN 100 .
*&---------------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
* SET PF-STATUS 'xxxxxxxx'.
* SET TITLEBAR 'xxx'.
ENDMODULE. " STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
ENDMODULE. " USER_COMMAND_0100 INPUT
Define screen 100 with subcreen area SEL as shown in below .
Define PF status and title bar with any names. This is not shown in screen shot.
Put code in PBO and PAI of screen as shown in below screen shot.
Call subscreen sel including sy-repid ‘400’.
Activate all objects and execute the report you should get following module pool screen with select-options.
Display Logo on Screen
You can display logo(s) on your screen using the custom control function. A custom control is an area on the screen, created using the screen painter. Custom controls are used to embed controls. Container controls are instances of special global classes from the SAP Control Framework. The global class for custom controls is called CL_GUI_CUSTOM_CONTAINER. To link a custom control to a container control, pass the custom control name to the CONTAINER_NAME parameter of the container control constructor when you instantiate it. The following is a sample program to demonstrate the logo display using the custom control. This program was written in SAP4.6C. Design a screen with the custom control, by name PICTURE_CONTAINER. It has the following flow logic:
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
*
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
The GUI status SCREEN100 has the functions BACK, EXIT, and CANCEL (all with type E).
Code
REPORT ZSURESH_TEST .
* Type declarations.....................
TYPES pict_line(256) TYPE c.
* data declarations......................
DATA :init,
container TYPE REF TO cl_gui_custom_container,
editor TYPE REF TO cl_gui_textedit,
picture TYPE REF TO cl_gui_picture,
pict_tab TYPE TABLE OF pict_line,
url(255) TYPE c.
CALL SCREEN 100.
* Dialog modules......................................
MODULE status_0100 OUTPUT.
SET PF-STATUS 'SCREEN100'.
IF init is initial.
init = 'X'.
CREATE OBJECT:
container EXPORTING container_name = 'PICTURE_CONTAINER',
picture EXPORTING parent = container.
ENDIF.
IMPORT pict_tab = pict_tab FROM DATABASE abtree(pi) ID 'ENJOY'.
CALL FUNCTION 'DP_CREATE_URL'
EXPORTING
type = 'IMAGE'
subtype = 'GIF'
TABLES
data = pict_tab
CHANGING
url = url.
CALL METHOD picture->load_picture_from_url EXPORTING url = url.
CALL METHOD picture->set_display_mode
EXPORTING display_mode = picture->display_mode_fit_center.
ENDMODULE.
MODULE cancel INPUT.
LEAVE TO SCREEN 0.
ENDMODULE.
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
*
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
The GUI status SCREEN100 has the functions BACK, EXIT, and CANCEL (all with type E).
Code
REPORT ZSURESH_TEST .
* Type declarations.....................
TYPES pict_line(256) TYPE c.
* data declarations......................
DATA :init,
container TYPE REF TO cl_gui_custom_container,
editor TYPE REF TO cl_gui_textedit,
picture TYPE REF TO cl_gui_picture,
pict_tab TYPE TABLE OF pict_line,
url(255) TYPE c.
CALL SCREEN 100.
* Dialog modules......................................
MODULE status_0100 OUTPUT.
SET PF-STATUS 'SCREEN100'.
IF init is initial.
init = 'X'.
CREATE OBJECT:
container EXPORTING container_name = 'PICTURE_CONTAINER',
picture EXPORTING parent = container.
ENDIF.
IMPORT pict_tab = pict_tab FROM DATABASE abtree(pi) ID 'ENJOY'.
CALL FUNCTION 'DP_CREATE_URL'
EXPORTING
type = 'IMAGE'
subtype = 'GIF'
TABLES
data = pict_tab
CHANGING
url = url.
CALL METHOD picture->load_picture_from_url EXPORTING url = url.
CALL METHOD picture->set_display_mode
EXPORTING display_mode = picture->display_mode_fit_center.
ENDMODULE.
MODULE cancel INPUT.
LEAVE TO SCREEN 0.
ENDMODULE.
Step-by-Step guide to develop Outbound ABAP Proxy from SAP with PDF attachment
In order to develop a ABAP Proxy first we need to have a Proxy Configured in the transaction SPROXY, this is to be done by PI or XI consultant, as a ABAPer you are not concerned with this.
The Proxy configured in SPROXY will look like.
By Clicking on the structure we can also see the structure of the Proxy, which is in tree structure.
In this case, proxy have 4 structured to be filled with data and then trigger the proxy to PI.
In order to create the proxy from the namespace given, we need to do following
1.Right click on the Message interface(outbound) and click on create
2.After clicking on create it will ask for Transport Request no, prefix, proxy class and other details, that we need to give in order to create the proxy and then activate.
3.We need to create a simple report program using SE38 .
4.We need to create a structure that will refer to the proxy structure. We need to populate this in order to send our data.
g_t_header TYPE zintercompany_data _send .
5.Various data declalarions required for Proxy sending and PDF attachment sending are.
attch_protocol TYPE REF TO if_wsprotocol_attachments,
g_attachment TYPE REF TO if_ai_attachment,
g_attachments TYPE prx_attach, "Internal table for attachment
g_attach_xstring TYPE xstring, "variable of xstring type.
g_spool_id TYPE tsp01-rqident,
g_pripar TYPE pri_params,
g_arcpar TYPE arc_params,
g_pdfspoolid TYPE tsp01-rqident, "SPOOL ID
g_jobname TYPE tbtcjob-jobname, "Jobname parameter for SPOOL
g_jobcount TYPE tbtcjob-jobcount, "Jobcount Paramater for SPOOL
g_string TYPE string, "To convert 132 character data into 255 character data.
*Reference variables exception class
lo_sys_exception TYPE REF TO cx_ai_system_fault,
*Object declaration for Proxy Class
obj_invoice1 TYPE REF TO “Proxy class name”.
* creating proxy object
CREATE OBJECT obj_invoice1.
6.If some amount field is involved, we can use FM CONVERSION_EXIT_CUNIT_OUTPUT to put –ve sign on the left side.
7.Update the main structure with the data required, if some substructures are there, then also finally we need to fill the main structure we only, that will be passed while triggering the proxy.
g_t_header-invoice_details-invoice_line_item[] = g_t_tab_det[].
g_t_header-invoice_properties = wa_inv_pro.
8.Get all the data required for PDF into a internal table.
9.In order to send the PDF into the proxy we need to get all the data in a “Xstring” type variable. To do so first we need to create a SPOOL of the data in our internal table.
10.Use FM 'GET_PRINT_PARAMETERS', if some special format is required. Start the TRY-CATCH Block. To create SPOOL :
NEW-PAGE PRINT ON
PARAMETERS g_pripar
ARCHIVE PARAMETERS g_arcpar
NO DIALOG.
“Write your data that need to be printed , with the format required for PDF. Whatever written here will be converted into SPOOL.
g_spool_id = sy-spono.
NEW-PAGE PRINT OFF.
11.We need to convert this SPOOL into PDF format using FM 'CONVERT_ABAPSPOOLJOB_2_PDF'
CALL FUNCTION 'CONVERT_ABAPSPOOLJOB_2_PDF'
EXPORTING
src_spoolid = g_spool_id " SPOOL ID
no_dialog = ' '
IMPORTING
pdf_bytecount = g_size_bytes
pdf_spoolid = g_pdfspoolid
btc_jobname = g_jobname
btc_jobcount = g_jobcount
TABLES
pdf = g_table " All the data will be in this Data table
12.Converting the 132 character data to 255 character data
CLEAR g_string.
LOOP AT g_table INTO wa_table.
TRANSLATE wa_table USING ' |'.
CONCATENATE g_string wa_table INTO g_string.
ENDLOOP.
TRANSLATE g_string USING '| '.
DO.
wa_buf = g_string.
APPEND wa_buf TO g_t_buf.
SHIFT g_string BY 255 PLACES.
IF g_string IS INITIAL.
EXIT.
ENDIF.
ENDDO.
13.Appending 255 character data in one variable.
IF g_t_buf[] IS NOT INITIAL.
LOOP AT g_t_buf INTO wa_buf.
CONCATENATE
g_output
wa_buf
INTO g_output.
ENDLOOP.
14.Convert the Binary String to XSTRING
CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
EXPORTING
text = g_output
IMPORTING
buffer = g_outputx
15.Concatenating attach_xstring with the data field.We need to send this field to Proxy.
CONCATENATE g_attach_xstring g_outputx INTO g_attach_xstring IN BYTE MODE.
16.Below is the code required to send the proxy.
TRY-CATCH
* Get attachment protocol
TRY.
attch_protocol ?= obj_invoice1->get_protocol( if_wsprotocol=>attachments ).
g_attachment = attch_protocol->get_attachment_from_binary(
data = g_attach_xstring
type = if_ai_attachment=>c_mimetype_pdf
name = 'PDF Attachment' ). " Name of PDF to be uploaded
APPEND g_attachment TO g_attachments.
attch_protocol->set_attachments( g_attachments ).
*Sending Proxy fields to XI through EXECUTE ASYNCHRONOUS Method.
CALL METHOD obj_invoice1->execute_asynchronous
EXPORTING
output = g_t_header.
CATCH cx_ai_system_fault INTO lo_sys_exception.
COMMIT WORK.
ENDTRY.
CATCH cx_ai_system_fault INTO lo_sys_exception.
ENDTRY.
17.Other Exception Handling can be done as per the requirement. Using the “SXMB_MONI” TCode we can check whether the proxy has been sent successfully or not.
The Proxy configured in SPROXY will look like.
By Clicking on the structure we can also see the structure of the Proxy, which is in tree structure.
In this case, proxy have 4 structured to be filled with data and then trigger the proxy to PI.
In order to create the proxy from the namespace given, we need to do following
1.Right click on the Message interface(outbound) and click on create
2.After clicking on create it will ask for Transport Request no, prefix, proxy class and other details, that we need to give in order to create the proxy and then activate.
3.We need to create a simple report program using SE38 .
4.We need to create a structure that will refer to the proxy structure. We need to populate this in order to send our data.
g_t_header TYPE zintercompany_data _send .
5.Various data declalarions required for Proxy sending and PDF attachment sending are.
attch_protocol TYPE REF TO if_wsprotocol_attachments,
g_attachment TYPE REF TO if_ai_attachment,
g_attachments TYPE prx_attach, "Internal table for attachment
g_attach_xstring TYPE xstring, "variable of xstring type.
g_spool_id TYPE tsp01-rqident,
g_pripar TYPE pri_params,
g_arcpar TYPE arc_params,
g_pdfspoolid TYPE tsp01-rqident, "SPOOL ID
g_jobname TYPE tbtcjob-jobname, "Jobname parameter for SPOOL
g_jobcount TYPE tbtcjob-jobcount, "Jobcount Paramater for SPOOL
g_string TYPE string, "To convert 132 character data into 255 character data.
*Reference variables exception class
lo_sys_exception TYPE REF TO cx_ai_system_fault,
*Object declaration for Proxy Class
obj_invoice1 TYPE REF TO “Proxy class name”.
* creating proxy object
CREATE OBJECT obj_invoice1.
6.If some amount field is involved, we can use FM CONVERSION_EXIT_CUNIT_OUTPUT to put –ve sign on the left side.
7.Update the main structure with the data required, if some substructures are there, then also finally we need to fill the main structure we only, that will be passed while triggering the proxy.
g_t_header-invoice_details-invoice_line_item[] = g_t_tab_det[].
g_t_header-invoice_properties = wa_inv_pro.
8.Get all the data required for PDF into a internal table.
9.In order to send the PDF into the proxy we need to get all the data in a “Xstring” type variable. To do so first we need to create a SPOOL of the data in our internal table.
10.Use FM 'GET_PRINT_PARAMETERS', if some special format is required. Start the TRY-CATCH Block. To create SPOOL :
NEW-PAGE PRINT ON
PARAMETERS g_pripar
ARCHIVE PARAMETERS g_arcpar
NO DIALOG.
“Write your data that need to be printed , with the format required for PDF. Whatever written here will be converted into SPOOL.
g_spool_id = sy-spono.
NEW-PAGE PRINT OFF.
11.We need to convert this SPOOL into PDF format using FM 'CONVERT_ABAPSPOOLJOB_2_PDF'
CALL FUNCTION 'CONVERT_ABAPSPOOLJOB_2_PDF'
EXPORTING
src_spoolid = g_spool_id " SPOOL ID
no_dialog = ' '
IMPORTING
pdf_bytecount = g_size_bytes
pdf_spoolid = g_pdfspoolid
btc_jobname = g_jobname
btc_jobcount = g_jobcount
TABLES
pdf = g_table " All the data will be in this Data table
12.Converting the 132 character data to 255 character data
CLEAR g_string.
LOOP AT g_table INTO wa_table.
TRANSLATE wa_table USING ' |'.
CONCATENATE g_string wa_table INTO g_string.
ENDLOOP.
TRANSLATE g_string USING '| '.
DO.
wa_buf = g_string.
APPEND wa_buf TO g_t_buf.
SHIFT g_string BY 255 PLACES.
IF g_string IS INITIAL.
EXIT.
ENDIF.
ENDDO.
13.Appending 255 character data in one variable.
IF g_t_buf[] IS NOT INITIAL.
LOOP AT g_t_buf INTO wa_buf.
CONCATENATE
g_output
wa_buf
INTO g_output.
ENDLOOP.
14.Convert the Binary String to XSTRING
CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
EXPORTING
text = g_output
IMPORTING
buffer = g_outputx
15.Concatenating attach_xstring with the data field.We need to send this field to Proxy.
CONCATENATE g_attach_xstring g_outputx INTO g_attach_xstring IN BYTE MODE.
16.Below is the code required to send the proxy.
TRY-CATCH
* Get attachment protocol
TRY.
attch_protocol ?= obj_invoice1->get_protocol( if_wsprotocol=>attachments ).
g_attachment = attch_protocol->get_attachment_from_binary(
data = g_attach_xstring
type = if_ai_attachment=>c_mimetype_pdf
name = 'PDF Attachment' ). " Name of PDF to be uploaded
APPEND g_attachment TO g_attachments.
attch_protocol->set_attachments( g_attachments ).
*Sending Proxy fields to XI through EXECUTE ASYNCHRONOUS Method.
CALL METHOD obj_invoice1->execute_asynchronous
EXPORTING
output = g_t_header.
CATCH cx_ai_system_fault INTO lo_sys_exception.
COMMIT WORK.
ENDTRY.
CATCH cx_ai_system_fault INTO lo_sys_exception.
ENDTRY.
17.Other Exception Handling can be done as per the requirement. Using the “SXMB_MONI” TCode we can check whether the proxy has been sent successfully or not.
Wednesday, June 29, 2011
What Are The Events In ALV
What Are The Events In ALV
What are the events in alvs and which events not used in alvs?
Events in alv and their FM The main events in alv and their FM and why we use these:
1. SLIS_PRINT_ALV.
2. SLIS_T_LISTHEADER.
3. SLIS_T_EVENT.
4. SLIS_T_SORTINFO_ALV.
5. SLIS_T_LAYOUT_ALV.
6. SLIS_T_FIELDCAT_ALV.
and in classic reports what is the sequence of events: === Events are
At selection-screen output.
Initialization.
At selection-screen on field
At selection-screen on end of field
At selection-screen on Radiobutton Group R1. (If you have any radio buttons)
At selection-screen on block b1. (If you have any blocks)
Start-of-selection.
Get node. (if the data is retreived from a logical database)
Get node late. (if the data is retreived from a logical database)
Top-of-page. (if the write statement is in the end-of-selection event or we can say that before the first write statement)
end-of-selection.
and fuction modules are
LISTHEADER - Is used to print the header information in the ALV List. Name, Date, Time, ALV Name and other details are called as Header information. EVENT - Basically this is the FM to handle Event's. When the user needs to do some event operation like when double clicking the a particular field we need to perform some operation. These events are captured by this FM. LAYOUT - This FM is used to define the layout of the List. There are many options available in this FM to define the Layout style. FIELDCAT - These are used to populate the List header. We can change them according to our req.
User-defined Text Output Event
Application
print_end_of_list
Define output text to be printed at the end of the entire list
print_top_of_list
Define output text to be printed at the beginning of the entire list
print_end_of_page
Define output text to be printed at the end of each page
print_top_of_page
Define output text to be printed at the beginning of each page
subtotal_text
Define self-defined subtotals texts
Mouse-controlled Actions in the Grid Control Event
Application
button_click
Query a click on a pushbutton in the ALV Grid Control
double_click
Query a double-click on a cell of the ALV Grid control
hotspot_click
Query a hotspot click on columns defined for this purpose in advance
onDrag
Collect information when elements of the ALV Grid Control are dragged
onDrop
Process information when elements of the ALV Grid Control are dropped
onDropComplete
Perform final actions after successful Drag&Drop
onDropGetFlavor
Distinguish between options for Drag&Drop behavior
Processing of Self-defined and Standard Functions Event
Application
before_user_command
Query self-defined and standard function codes
user_command
Query self-defined function codes
after_user_command
Query self-defined and standard function codes
Definition of Self-defined Functions Event
Application
toolbar
Change, delete or add GUI elements in the toolbar
menu_button
Define menus for menu buttons in the toolbar
context_menu_request
Change context menu
onf1
Define self-defined F1 help
All of these can be found under type group SLIS.
* Events
SLIS_EV_ITEM_DATA_EXPAND TYPE SLIS_FORMNAME VALUE 'ITEM_DATA_EXPAND',
SLIS_EV_REPREP_SEL_MODIFY TYPE SLIS_FORMNAME VALUE 'REPREP_SEL_MODIFY', SLIS_EV_CALLER_EXIT_AT_START TYPE SLIS_FORMNAME VALUE 'CALLER_EXIT',
SLIS_EV_USER_COMMAND TYPE SLIS_FORMNAME VALUE 'USER_COMMAND',
SLIS_EV_TOP_OF_PAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_PAGE',
SLIS_EV_DATA_CHANGED TYPE SLIS_FORMNAME VALUE 'DATA_CHANGED',
SLIS_EV_TOP_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_COVERPAGE',
SLIS_EV_END_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'END_OF_COVERPAGE',
SLIS_EV_FOREIGN_TOP_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_TOP_OF_PAGE', SLIS_EV_FOREIGN_END_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_END_OF_PAGE',
SLIS_EV_PF_STATUS_SET TYPE SLIS_FORMNAME VALUE 'PF_STATUS_SET',
SLIS_EV_LIST_MODIFY TYPE SLIS_FORMNAME VALUE 'LIST_MODIFY',
SLIS_EV_TOP_OF_LIST TYPE SLIS_FORMNAME VALUE 'TOP_OF_LIST',
SLIS_EV_END_OF_PAGE TYPE SLIS_FORMNAME VALUE 'END_OF_PAGE',
SLIS_EV_END_OF_LIST TYPE SLIS_FORMNAME VALUE 'END_OF_LIST',
SLIS_EV_AFTER_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'AFTER_LINE_OUTPUT', SLIS_EV_BEFORE_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'BEFORE_LINE_OUTPUT',
SLIS_EV_SUBTOTAL_TEXT TYPE SLIS_FORMNAME VALUE 'SUBTOTAL_TEXT'.
What are the events in alvs and which events not used in alvs?
Events in alv and their FM The main events in alv and their FM and why we use these:
1. SLIS_PRINT_ALV.
2. SLIS_T_LISTHEADER.
3. SLIS_T_EVENT.
4. SLIS_T_SORTINFO_ALV.
5. SLIS_T_LAYOUT_ALV.
6. SLIS_T_FIELDCAT_ALV.
and in classic reports what is the sequence of events: === Events are
At selection-screen output.
Initialization.
At selection-screen on field
At selection-screen on end of field
At selection-screen on Radiobutton Group R1. (If you have any radio buttons)
At selection-screen on block b1. (If you have any blocks)
Start-of-selection.
Get node. (if the data is retreived from a logical database)
Get node late. (if the data is retreived from a logical database)
Top-of-page. (if the write statement is in the end-of-selection event or we can say that before the first write statement)
end-of-selection.
and fuction modules are
LISTHEADER - Is used to print the header information in the ALV List. Name, Date, Time, ALV Name and other details are called as Header information. EVENT - Basically this is the FM to handle Event's. When the user needs to do some event operation like when double clicking the a particular field we need to perform some operation. These events are captured by this FM. LAYOUT - This FM is used to define the layout of the List. There are many options available in this FM to define the Layout style. FIELDCAT - These are used to populate the List header. We can change them according to our req.
User-defined Text Output Event
Application
print_end_of_list
Define output text to be printed at the end of the entire list
print_top_of_list
Define output text to be printed at the beginning of the entire list
print_end_of_page
Define output text to be printed at the end of each page
print_top_of_page
Define output text to be printed at the beginning of each page
subtotal_text
Define self-defined subtotals texts
Mouse-controlled Actions in the Grid Control Event
Application
button_click
Query a click on a pushbutton in the ALV Grid Control
double_click
Query a double-click on a cell of the ALV Grid control
hotspot_click
Query a hotspot click on columns defined for this purpose in advance
onDrag
Collect information when elements of the ALV Grid Control are dragged
onDrop
Process information when elements of the ALV Grid Control are dropped
onDropComplete
Perform final actions after successful Drag&Drop
onDropGetFlavor
Distinguish between options for Drag&Drop behavior
Processing of Self-defined and Standard Functions Event
Application
before_user_command
Query self-defined and standard function codes
user_command
Query self-defined function codes
after_user_command
Query self-defined and standard function codes
Definition of Self-defined Functions Event
Application
toolbar
Change, delete or add GUI elements in the toolbar
menu_button
Define menus for menu buttons in the toolbar
context_menu_request
Change context menu
onf1
Define self-defined F1 help
All of these can be found under type group SLIS.
* Events
SLIS_EV_ITEM_DATA_EXPAND TYPE SLIS_FORMNAME VALUE 'ITEM_DATA_EXPAND',
SLIS_EV_REPREP_SEL_MODIFY TYPE SLIS_FORMNAME VALUE 'REPREP_SEL_MODIFY', SLIS_EV_CALLER_EXIT_AT_START TYPE SLIS_FORMNAME VALUE 'CALLER_EXIT',
SLIS_EV_USER_COMMAND TYPE SLIS_FORMNAME VALUE 'USER_COMMAND',
SLIS_EV_TOP_OF_PAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_PAGE',
SLIS_EV_DATA_CHANGED TYPE SLIS_FORMNAME VALUE 'DATA_CHANGED',
SLIS_EV_TOP_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_COVERPAGE',
SLIS_EV_END_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'END_OF_COVERPAGE',
SLIS_EV_FOREIGN_TOP_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_TOP_OF_PAGE', SLIS_EV_FOREIGN_END_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_END_OF_PAGE',
SLIS_EV_PF_STATUS_SET TYPE SLIS_FORMNAME VALUE 'PF_STATUS_SET',
SLIS_EV_LIST_MODIFY TYPE SLIS_FORMNAME VALUE 'LIST_MODIFY',
SLIS_EV_TOP_OF_LIST TYPE SLIS_FORMNAME VALUE 'TOP_OF_LIST',
SLIS_EV_END_OF_PAGE TYPE SLIS_FORMNAME VALUE 'END_OF_PAGE',
SLIS_EV_END_OF_LIST TYPE SLIS_FORMNAME VALUE 'END_OF_LIST',
SLIS_EV_AFTER_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'AFTER_LINE_OUTPUT', SLIS_EV_BEFORE_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'BEFORE_LINE_OUTPUT',
SLIS_EV_SUBTOTAL_TEXT TYPE SLIS_FORMNAME VALUE 'SUBTOTAL_TEXT'.
CONSITENCEY THROUGH INPUT CHECKS:
CONSITENCEY THROUGH INPUT CHECKS:
The domain describes the value range of a field by specifying its data type and field length. If only a limited set of values is allowed, they can be defined as fixed values.
Specifying fixed values causes the value range of the domain to be restricted by these values. Fixed values are immediately used as check values in screen entries. There is also an F4 help.
Fixed values are only checked in screens. No check is made when data records are inserted in a table by an ABAP program.
Fixed values can either be listed individually or defined as an interval.
The value range of a field can also be defined by specifying a value table in the domain.
In contrast to fixed values, however, simply specifying a value table does not cause the input to be checked. There is no F4 help either.
If you enter a value table, the system can make a proposal for the foreign key definition.
A value table only becomes a check table when a foreign key is defined.
If you refer to a domain with a value table in a field, but no foreign key was defined at field level, there is no check.
In the ABAP Dictionary, such relationships between two tables are called foreign keys and they must be defined explicitly for the fields.
Foreign keys are used to ensure that the data is consistent. Data that has been entered is checked against existing data to ensure that it is consistent.
In order to define the foreign key, these three fields are assigned to fields of the foreign key table (foreign key fields) with which the input to be checked is entered on the screen. In table SBOOK these are the fields: MANDT, CARRID, COUNTER. The entry is accepted if it represents a valid counter; otherwise the system will reject it.
The foreign key is defined for field SBOOK-COUNTER (check field), which means that the entry in this field is checked. Field COUNTER is therefore called the check field for this foreign key.
A combination of fields of a table is called a foreign key if this field combination is the primary key of another table.
A foreign key links two tables.
The check table is the table whose key fields are checked. This table is also called the referenced table .
An entry is to be written in the foreign key table. This entry must be consistent with the key fields of the check table.
The field of the foreign key table to be checked is called the check field.
Foreign keys can only be used in screens. Data records can be written to the table without being checked using an ABAP program.
In the ABAP Dictionary, the same domain is required for the check field and referenced key field of the check table so that you do not compare fields with different data types and field lengths. Domain equality is essential. Different data elements can be used, but they must refer to the same domain.
The requirement for domain equality is only valid for the check field. For all other foreign key fields, it is sufficient if the data type and the field length are equal. You nevertheless should strive for domain equality. In this case the foreign key will remain consistent if the field length is changed because the corresponding fields are both changed. If the domains are different, the foreign key will be inconsistent if for example the field length is changed.
If the domain of the check field has a value table, you can have the system make a proposal with the value table as check table. In this case a proposal is created for the field assignment in the foreign key.
CAUTION!
The constellation that a domain that itself has table SAIRPORT as value table is used following field SAIRPORT-Airport is correct !! However, a foreign key is never defined on this field (avoiding a loop).
The cardinality describes the foreign key relationship with regard to how many records of the check table are assigned to records of the foreign key table. The cardinality is always defined from the point of view of the check table.
The type of the foreign key field defines whether or not the foreign key field identifies a table entry.
This means that the foreign key fields are either key fields or they are not key fields or they are a special case, namely the key fields of a text table.
There are the following kinds of foreign key fields:
not specified: No information about the kind of foreign key field can be given
no key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates).
The foreign key fields therefore do not (partially) identify the foreign key table.
Key fields/candidates:
The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.
Key fields of a text table :
The foreign key table is a text table of the check table, i.e. the key of the foreign key table only differs from the key of the check table in an additional language key field. This is a special case of the category Key fields / candidates.
Only one text table can be created for a table.
The domain describes the value range of a field by specifying its data type and field length. If only a limited set of values is allowed, they can be defined as fixed values.
Specifying fixed values causes the value range of the domain to be restricted by these values. Fixed values are immediately used as check values in screen entries. There is also an F4 help.
Fixed values are only checked in screens. No check is made when data records are inserted in a table by an ABAP program.
Fixed values can either be listed individually or defined as an interval.
The value range of a field can also be defined by specifying a value table in the domain.
In contrast to fixed values, however, simply specifying a value table does not cause the input to be checked. There is no F4 help either.
If you enter a value table, the system can make a proposal for the foreign key definition.
A value table only becomes a check table when a foreign key is defined.
If you refer to a domain with a value table in a field, but no foreign key was defined at field level, there is no check.
In the ABAP Dictionary, such relationships between two tables are called foreign keys and they must be defined explicitly for the fields.
Foreign keys are used to ensure that the data is consistent. Data that has been entered is checked against existing data to ensure that it is consistent.
In order to define the foreign key, these three fields are assigned to fields of the foreign key table (foreign key fields) with which the input to be checked is entered on the screen. In table SBOOK these are the fields: MANDT, CARRID, COUNTER. The entry is accepted if it represents a valid counter; otherwise the system will reject it.
The foreign key is defined for field SBOOK-COUNTER (check field), which means that the entry in this field is checked. Field COUNTER is therefore called the check field for this foreign key.
A combination of fields of a table is called a foreign key if this field combination is the primary key of another table.
A foreign key links two tables.
The check table is the table whose key fields are checked. This table is also called the referenced table .
An entry is to be written in the foreign key table. This entry must be consistent with the key fields of the check table.
The field of the foreign key table to be checked is called the check field.
Foreign keys can only be used in screens. Data records can be written to the table without being checked using an ABAP program.
In the ABAP Dictionary, the same domain is required for the check field and referenced key field of the check table so that you do not compare fields with different data types and field lengths. Domain equality is essential. Different data elements can be used, but they must refer to the same domain.
The requirement for domain equality is only valid for the check field. For all other foreign key fields, it is sufficient if the data type and the field length are equal. You nevertheless should strive for domain equality. In this case the foreign key will remain consistent if the field length is changed because the corresponding fields are both changed. If the domains are different, the foreign key will be inconsistent if for example the field length is changed.
If the domain of the check field has a value table, you can have the system make a proposal with the value table as check table. In this case a proposal is created for the field assignment in the foreign key.
CAUTION!
The constellation that a domain that itself has table SAIRPORT as value table is used following field SAIRPORT-Airport is correct !! However, a foreign key is never defined on this field (avoiding a loop).
The cardinality describes the foreign key relationship with regard to how many records of the check table are assigned to records of the foreign key table. The cardinality is always defined from the point of view of the check table.
The type of the foreign key field defines whether or not the foreign key field identifies a table entry.
This means that the foreign key fields are either key fields or they are not key fields or they are a special case, namely the key fields of a text table.
There are the following kinds of foreign key fields:
not specified: No information about the kind of foreign key field can be given
no key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates).
The foreign key fields therefore do not (partially) identify the foreign key table.
Key fields/candidates:
The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.
Key fields of a text table :
The foreign key table is a text table of the check table, i.e. the key of the foreign key table only differs from the key of the check table in an additional language key field. This is a special case of the category Key fields / candidates.
Only one text table can be created for a table.
INTERNAL PROGRAM MODULARIZATION:
INTERNAL PROGRAM MODULARIZATION:
An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.
Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.
There are various kinds of ABAP processing blocks:
Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.
Subroutine processing is triggered by an ABAP statement. Parameters can be passed to
subroutines using an interface and subroutines can contain local variables.
Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.
Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.
In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.
The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.
Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.
All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.
The easiest events to understand are those for an executable program (type 1).
The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:
First, the INITIALIZATION event block is called
Then a selection screen is sent to the presentation server
After the user leaves the selection screen, START-OF-SELECTION is called
If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.
The list buffer is subsequently sent to the presentation server as a list.
Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.
In executable programs, there are different event blocks for the various tasks involved in creating lists.
In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.
Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.
START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.
INITIALIZATION is an event that you can use if you need to set a large number of default values.
This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.
Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.
You can navigate from the program object list to the subroutines.
The where-used list for a subroutine displays all the program lines that call the subroutine.
Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:
Subroutine name
Interface parameters it accesses (read-only): the parameters are listed after the USING addition.
The type and sequence of the interface parameters is important.
Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.
When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:
After USING, the parameters that the subroutine only needs to read are listed.
After CHANGING, the parameters that are changed in the subroutine are listed.
If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.
You can track runtime behavior in the debugging mode. This gives you various options:
You can go through the entire program, including the subroutine, line by line, using Single Step
You can go through a processing block line by line using Execute. Subroutines are then executed as a whole
You can leave single -step processing of a subroutine and return to the calling program using Return
The method used for calling the interface parameters is set in the subroutine interface. The
parameters can be called either by reference or by value.
Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.
Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:
Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.
Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.
The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .
You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.
When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:
Complete type checks:
TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.
Partial type checks of generic types
TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.
TYPE all unspecified information from generic
Dictionary types is inherited by the formal parameter from an actual parameter.
The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.
An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.
Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.
There are various kinds of ABAP processing blocks:
Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.
Subroutine processing is triggered by an ABAP statement. Parameters can be passed to
subroutines using an interface and subroutines can contain local variables.
Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.
Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.
In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.
The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.
Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.
All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.
The easiest events to understand are those for an executable program (type 1).
The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:
First, the INITIALIZATION event block is called
Then a selection screen is sent to the presentation server
After the user leaves the selection screen, START-OF-SELECTION is called
If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.
The list buffer is subsequently sent to the presentation server as a list.
Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.
In executable programs, there are different event blocks for the various tasks involved in creating lists.
In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.
Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.
START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.
INITIALIZATION is an event that you can use if you need to set a large number of default values.
This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.
Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.
You can navigate from the program object list to the subroutines.
The where-used list for a subroutine displays all the program lines that call the subroutine.
Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:
Subroutine name
Interface parameters it accesses (read-only): the parameters are listed after the USING addition.
The type and sequence of the interface parameters is important.
Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.
When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:
After USING, the parameters that the subroutine only needs to read are listed.
After CHANGING, the parameters that are changed in the subroutine are listed.
If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.
You can track runtime behavior in the debugging mode. This gives you various options:
You can go through the entire program, including the subroutine, line by line, using Single Step
You can go through a processing block line by line using Execute. Subroutines are then executed as a whole
You can leave single -step processing of a subroutine and return to the calling program using Return
The method used for calling the interface parameters is set in the subroutine interface. The
parameters can be called either by reference or by value.
Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.
Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:
Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.
Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.
The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .
You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.
When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:
Complete type checks:
TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.
Partial type checks of generic types
TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.
TYPE all unspecified information from generic
Dictionary types is inherited by the formal parameter from an actual parameter.
The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.
Display more than one Internal Table in ALV using Object Oriented ABAP Programming
By Ashwini Thoutireddy, Phifer Wire Products Inc
Applies to:
This document applies to SAP ECC 6.0, SAP Net weaver 2004s.
Scenario
Displaying more than one table in ALV grid report by splitting the custom container.
TABLE 1 TABLE 2
TABLE 3
Step by step Solution
Step 1: Creating Screen
Go to Screen painter Transaction Code SE51.
Create a screen with no 9010.
Provide description for the screen and click on the Layout Button.
Place a Custom container UI element and give name as ‘CCONTAINER’ now you will have a screen with custom container as below screen shot. Activate the Object.
Step 2: Flow Logic
Go to the Flow Logic Tab to write coding for PBO & PAI.
Step 3: Report
Go to SE38 and create a program in Z name space and paste the following code snippet.
Click here to continue...
...Previous
*&---------------------------------------------------------------------*
*& Report ZPC_CONTAINER_CONTROL *
*&---------------------------------------------------------------------*
REPORT zpc_container_control.
*Declaration
DATA: Splitter_1 TYPE REF TO cl_gui_splitter_container,
Splitter_2 TYPE REF TO cl_gui_splitter_container,
Container TYPE REF TO cl_gui_custom_container,
Container_1 TYPE REF TO cl_gui_container,
Container_2 TYPE REF TO cl_gui_container,
Container_3 TYPE REF TO cl_gui_container,
Grid1 TYPE REF TO cl_gui_alv_grid,
Grid2 TYPE REF TO cl_gui_alv_grid,
Grid3 TYPE REF TO cl_gui_alv_grid.
DATA: Gt_sflight_1 TYPE TABLE OF sflight,
Gt_sflight_2 TYPE TABLE OF sflight,
Gt_sflight_3 TYPE TABLE OF sflight,
G_container TYPE scrfname VALUE 'CCONTAINER'.
DATA: ok_code TYPE sy-ucomm.
* fetching data from table for different internal tables
SELECT * FROM sflight INTO TABLE gt_sflight_1. “Itab 1
SELECT * FROM sflight INTO TABLE gt_sflight_2 UP TO 3 ROWS. “Itab 2
SELECT * FROM sflight INTO TABLE gt_sflight_3 UP TO 2 ROWS. “Itab 3
CALL SCREEN 9010.
*&---------------------------------------------------------------------*
*& Module STATUS_9010 OUTPUT *
*&---------------------------------------------------------------------*
MODULE status_9010 OUTPUT.
SET PF-STATUS 'TEST'.
*creating object reference for container
CREATE OBJECT container
EXPORTING
container_name = 'CCONTAINER'. “Pass name of container created in Screen no 9010
*splitting the main container into 1 row & 2 coloum
CREATE OBJECT splitter_1
EXPORTING
Parent = container
Rows = 1
Columns = 2.
*getting the reference for the splited container (row 1 & col 1 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_1.
*getting the reference for the splited container (row 1 & col 2 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 2
RECEIVING
Container = container_2.
*splitting the 2nd coloum container in to 2 rows & 1 coloum
CREATE OBJECT splitter_2
EXPORTING
Parent = container_2
Rows = 2
Columns = 1.
*getting the reference for the splited container2 (row 1 & col 2 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_2.
*getting the reference for the splited container2 (row 2 & col 1 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 2
Column = 1
RECEIVING
Container = container_3.
*populating first internal table to the container
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid1
EXPORTING
i_parent = container_1.
CALL METHOD grid1->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_1.
*populating second internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid2
EXPORTING
i_parent = container_2.
CALL METHOD grid2->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_2.
*populating third internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid3
EXPORTING
i_parent = container_3.
CALL METHOD grid3->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_3.
ENDMODULE. “STATUS_9010 OUTPUT
*&---------------------------------------------------------------------*
*& Module EXIT INPUT *
*&---------------------------------------------------------------------*
MODULE exit INPUT.
*free the container memory when exit
CALL METHOD container->free.
LEAVE PROGRAM.
ENDMODULE. “EXIT INPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_9010 INPUT *
*&---------------------------------------------------------------------*
MODULE user_command_9010 INPUT.
CALL METHOD cl_gui_cfw=>dispatch.
CASE ok_code.
WHEN 'BACK'.
LEAVE SCREEN.
WHEN 'CANCEL'.
LEAVE PROGRAM.
WHEN 'EXIT'.
LEAVE SCREEN.
ENDCASE.
ENDMODULE. “USER_COMMAND_9010 INPUT
By Ashwini Thoutireddy, Phifer Wire Products Inc
Applies to:
This document applies to SAP ECC 6.0, SAP Net weaver 2004s.
Scenario
Displaying more than one table in ALV grid report by splitting the custom container.
TABLE 1 TABLE 2
TABLE 3
Step by step Solution
Step 1: Creating Screen
Go to Screen painter Transaction Code SE51.
Create a screen with no 9010.
Provide description for the screen and click on the Layout Button.
Place a Custom container UI element and give name as ‘CCONTAINER’ now you will have a screen with custom container as below screen shot. Activate the Object.
Step 2: Flow Logic
Go to the Flow Logic Tab to write coding for PBO & PAI.
Step 3: Report
Go to SE38 and create a program in Z name space and paste the following code snippet.
Click here to continue...
...Previous
*&---------------------------------------------------------------------*
*& Report ZPC_CONTAINER_CONTROL *
*&---------------------------------------------------------------------*
REPORT zpc_container_control.
*Declaration
DATA: Splitter_1 TYPE REF TO cl_gui_splitter_container,
Splitter_2 TYPE REF TO cl_gui_splitter_container,
Container TYPE REF TO cl_gui_custom_container,
Container_1 TYPE REF TO cl_gui_container,
Container_2 TYPE REF TO cl_gui_container,
Container_3 TYPE REF TO cl_gui_container,
Grid1 TYPE REF TO cl_gui_alv_grid,
Grid2 TYPE REF TO cl_gui_alv_grid,
Grid3 TYPE REF TO cl_gui_alv_grid.
DATA: Gt_sflight_1 TYPE TABLE OF sflight,
Gt_sflight_2 TYPE TABLE OF sflight,
Gt_sflight_3 TYPE TABLE OF sflight,
G_container TYPE scrfname VALUE 'CCONTAINER'.
DATA: ok_code TYPE sy-ucomm.
* fetching data from table for different internal tables
SELECT * FROM sflight INTO TABLE gt_sflight_1. “Itab 1
SELECT * FROM sflight INTO TABLE gt_sflight_2 UP TO 3 ROWS. “Itab 2
SELECT * FROM sflight INTO TABLE gt_sflight_3 UP TO 2 ROWS. “Itab 3
CALL SCREEN 9010.
*&---------------------------------------------------------------------*
*& Module STATUS_9010 OUTPUT *
*&---------------------------------------------------------------------*
MODULE status_9010 OUTPUT.
SET PF-STATUS 'TEST'.
*creating object reference for container
CREATE OBJECT container
EXPORTING
container_name = 'CCONTAINER'. “Pass name of container created in Screen no 9010
*splitting the main container into 1 row & 2 coloum
CREATE OBJECT splitter_1
EXPORTING
Parent = container
Rows = 1
Columns = 2.
*getting the reference for the splited container (row 1 & col 1 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_1.
*getting the reference for the splited container (row 1 & col 2 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 2
RECEIVING
Container = container_2.
*splitting the 2nd coloum container in to 2 rows & 1 coloum
CREATE OBJECT splitter_2
EXPORTING
Parent = container_2
Rows = 2
Columns = 1.
*getting the reference for the splited container2 (row 1 & col 2 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_2.
*getting the reference for the splited container2 (row 2 & col 1 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 2
Column = 1
RECEIVING
Container = container_3.
*populating first internal table to the container
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid1
EXPORTING
i_parent = container_1.
CALL METHOD grid1->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_1.
*populating second internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid2
EXPORTING
i_parent = container_2.
CALL METHOD grid2->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_2.
*populating third internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid3
EXPORTING
i_parent = container_3.
CALL METHOD grid3->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_3.
ENDMODULE. “STATUS_9010 OUTPUT
*&---------------------------------------------------------------------*
*& Module EXIT INPUT *
*&---------------------------------------------------------------------*
MODULE exit INPUT.
*free the container memory when exit
CALL METHOD container->free.
LEAVE PROGRAM.
ENDMODULE. “EXIT INPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_9010 INPUT *
*&---------------------------------------------------------------------*
MODULE user_command_9010 INPUT.
CALL METHOD cl_gui_cfw=>dispatch.
CASE ok_code.
WHEN 'BACK'.
LEAVE SCREEN.
WHEN 'CANCEL'.
LEAVE PROGRAM.
WHEN 'EXIT'.
LEAVE SCREEN.
ENDCASE.
ENDMODULE. “USER_COMMAND_9010 INPUT
SAP LANDSCAPE.
SAP Landscape
ü Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the server’s viz. SAP is divided into three different landscapes DEV, QAS and PROD.
DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test. QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training. PROD may have something like a 200 Production. These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how are the client's business scenario.
Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving every time. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).
You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) clients. This is a configuration only client. Now upon a successful transport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.
But in the Testing client you cannot even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practiced in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.
The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.
ü In summary:
Landscape: is the arrangement for the servers
Landscape: is the arrangement for the servers
IDES: is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
Ø DEVELOPMENT: is where the consultants do the customization as per the company's requirement.
Ø QUALITY: is where the core team members and other members test the customization.
Ø PRODUCTION: is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.
1. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.
2. Development Server: - Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.
3. Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new development is done is development client and the request is transported to production.
These three are landscape of any Company. They organized their office in these three ways. Developers develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.
Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.
Application Server - Where SAP Installed.
Database Server - Where Database installed.
o Why do we call client 000 as golden client?
Golden client contains all the configuration data and master data so some extent. All the configuration settings are done in golden clients and then moved to other clients. Hence this client acts as a master record for all transaction settings, hence the name "Golden Client".
DEVELOPMENT
| SANDBOX |
| GOLDEN |
| QUALITY |
| ABAP |
| LIVE DATA USER |
PRODUCTION.
o What is the meaning of "R" in R/3 systems?
R/3 stands for real-time three tier architecture. This is the kind of architectures SAP R/3 system has.
R/3 means three layers are installed in Different system/server and they are connected with each other.
1) Presentation
2) Application
3) Database
2) Application
3) Database
Using ME57 to create an RFQ from multiple lines on multiple PRs
When using ME57 to create RFQs how can I select multiple line items from multiple purchase requisitions to turn into a single RFQ? If I select multiple lines and then use 'RFQ with Vendor', it only selects one line item. After further research it appears that you can only create only line at a time (very time consuming).
If you use ME41 and create with reference to PR then you cannot sort or filter columns to allow for easy consolidation.
Another forum recommended the following when using ME57 which works but it again adds extra steps to the process.
The whole process is as follows -
1) When you are in the 'Assign and Process Purchase Requisition' screen, select related PR and then click on 'Without Vendor' icon to flag all PRs for RFQ processing.
2) Select these PRs again and click further on 'Assignment Overview' icon (Shift and F5). The next screen will appear - Assign and Process requisitions - Overview of Assignments screen.
3) Select the 'PReq' column and then click further on 'Process Assignment' icon (F2). The next screen will appear where you have to maintain the 'quotation deadline' information.
4) Then click on 'Continue' icon (enter).
http://www.sapfans.com/forums/viewtopic.php?f=6&t=198768
So is there any way to either 1) enable sorting of data in ME41 or 2) use ME57 to create one RFQ from multiple line items of multiple purchase requisitions when selecting 'RFQ with Vendor'.
If you use ME41 and create with reference to PR then you cannot sort or filter columns to allow for easy consolidation.
Another forum recommended the following when using ME57 which works but it again adds extra steps to the process.
The whole process is as follows -
1) When you are in the 'Assign and Process Purchase Requisition' screen, select related PR and then click on 'Without Vendor' icon to flag all PRs for RFQ processing.
2) Select these PRs again and click further on 'Assignment Overview' icon (Shift and F5). The next screen will appear - Assign and Process requisitions - Overview of Assignments screen.
3) Select the 'PReq' column and then click further on 'Process Assignment' icon (F2). The next screen will appear where you have to maintain the 'quotation deadline' information.
4) Then click on 'Continue' icon (enter).
http://www.sapfans.com/forums/viewtopic.php?f=6&t=198768
So is there any way to either 1) enable sorting of data in ME41 or 2) use ME57 to create one RFQ from multiple line items of multiple purchase requisitions when selecting 'RFQ with Vendor'.
purchase requisition
· SAP Purchase Requisition 1
This series of article introduces the purchase requisition as an in-house instrument for entering requirements. The creation of purchase requisitions is shown using an example of consumption material with and without a material master record.
Following will also be covered in these articles:
- Use of transaction ME51N for purchase requisitions
- Creating a purchase requisition with items with single and multiple account assignments
- Requesting a material without a material master record
A practical example would be that in any plant maintenance department, you must have sensors and a particular testing instrument. Because this testing instrument is required for only one time, you do not want to create a material master record for it. Now you want to test the use of a purchasing requisition to process the internal requisition of these materials directly for your cost center.
Purchase Requisition in Procurement
In procurement, the internal requisition for materials or services triggers a procurement process. Purchase requisitions are internal documents for asking your Purchasing department to procure a particular quantity of a material or a service for a particular date. A purchase requisition (PReq) can be created directly or indirectly in the SAP R/3 system.
SAP MM Consumption Material Procurement PR
Figure SAP MM Consumption Material Procurement PR
“Direct” means that a purchase requisition is created manually in the department that made the request. Whoever creates the purchase requisition determines which material or service is ordered, and the quantity and date.
“Indirect” means that that purchase requisition from another SAP component is created automatically. Purchase requisitions can be created automatically, as follows:
- in MRP
- with maintenance orders
- with production orders
- with networks
- Purchase requisitions can also come from the SAP Advanced Planner and Optimizer (SAP APO) or the SAP Enterprise Buyer (SAP EBP).
SAP MM Purchase Requisitions
Figure SAP MM Purchase Requisitions
When you create a purchase requisition for materials that have a material master record, SAP R/3 transfers data in the material master record to the purchase requisition. You can convert purchase requisitions into RFQs, purchase orders or outline agreements.
SAP Purchase Requisition - 2
In this article we will discuss the structure of the purchase requisition. By highlighting common features and differences between a purchase requisition and a purchase order, such as the following:
- Missing a “proper ” document header in the purchase requisition • Specifying the vendor at item level of the purchase requisition is possible, but not compulsory
- Document overview in transactions ME21N and ME51N
In the transactions for creating, changing or displaying a purchase requisition (ME51N, ME52N, ME53N), there are single-screen transactions, just as in the purchase order. The division into different screen areas (header data, item overview, item details, document overview) and the operation correspond with the purchase order transaction.
SAP MM Purchase Requisition with ME51N, ME52N, ME53N
Figure SAP MM Purchase Requisition with ME51N, ME52N, ME53N
Entering the Account Assignment
If you want to request materials or services directly for an account assignment object, for example, for your cost center or for an asset, you must specify in the item overview the corresponding account assignment category. This means that you have to enter additional account assignment data in the item detail on the Account assignment tab.
If you have the single account assignment screen displayed on the Account assignment tab, you can use Multiple account assignment to switch to the multiple account assignment screen. On the multiple account assignment screen, choose Single account assignment to switch to the single account assignment screen. The SAP R/3 system stores your last setting. On the multiple account assignment screen, you can also create single account assignments.
With multiple account assignment, you can distribute the costs for one purchase order item among several cost centers, for example. In this case, the created account assignment data represents individual account assignment items. With multiple account assignment for an item, you must decide whether the value of the item is to be distributed on a quantity basis or as a percentage (for example, 10 pieces or 10% of the purchase order value to cost center 1000).
SAP MM Single or Multiple Account Assignment
Figure SAP MM Single or Multiple Account Assignment
If there are partial invoices, you can choose whether
- the partial invoice amount is distributed proportionally to the account assignment items
- the partial invoice amount is distributed to the account assignment items one after the other
The partial invoice indicator can also be derived automatically from the account assignment category if a partial invoice indicator is specified in Customizing for the account assignment category. For items with multiple account assignments, the system automatically sets the GR non-valuated indicator.
If you want to distribute the quantity in a purchase requisition item with account assignment to the different account assignment items, you just need to enter the account assignments, but not the quantity. The system automatically distributes the requested quantity proportionally to the existing account assignment items. If you change the requested quantity in the item overview, the quantity is adjusted in the relevant account assignment items. As soon as you change the quantity or percentage of the account assignment item, the system can no longer execute an automatic distribution.
SAP MM Single or Multiple Account Assignment
Figure SAP MM Single or Multiple Account Assignment
Example of an automatic account assignment distribution: You have requested 90 office chairs and assigned them equally to three cost centers. However, because you require 120 office chairs, you change the requested quantity in the item overview. The system then automatically changes the distribution so that 40 office chairs are assigned to each cost center.
SAP Purchase Requisition – 3
Features of the Purchase Requisition
In this article, we will start discussing the most important features of the purchase requisition: account assignment category unknown is allowed and then valuation price will be discussed.
Account assignment category: Unknown
If you do not know the account assignment object for which the material is being procured when you create the purchase requisition, you can use account assignment category U (unknown) in the purchase requisition
Then you do not need to enter any more account assignment details. If you create a purchase order with reference to this purchase requisition, you must specify precise account assignment information because account assignment category Unknown is not allowed in the purchase orders. Account assignment category U is allowed in purchase orders for external services and blanket purchase orders.
SAP MM Features of Purchase Requisition
Figure SAP MM Features of Purchase Requisition
Valuation price
When you create a purchase requisition item for valuated material, the valuation price is pulled from the material master record. For non-valuated material or material without a master record, the creator must manually enter the valuation price. This valuation price can be used for a value-related release procedure. The release can refer to the value of the individual item or to the total value of the requisition. If a previously defined release strategy becomes effective, you can create a request or a purchase order with reference to a purchase requisition only after the purchase requisition has been released. You can also dispense with the manual entry of a valuation price and use the missing valuation price as a criterion for your release strategy.
Status and Creation Indicator
If you want to trace whether your purchase requisition items have been processed, evaluate the processing status of the item. You can see the processing status on the Status tab page in the item detail area. The processing status provides information about whether the item has been ordered, not ordered or requested, or whether the item has been converted into an outline agreement. On this tab, the purchase order history of referenced purchasing documents (created with reference to this purchase requisition item) is listed. You can obtain information about previously posted goods receipts and invoices.
SAP MM Processing Status and Creation Indicator
Figure SAP MM Processing Status and Creation Indicator
For you as a buyer, it might be interesting to see how the purchase requisition was created in the system, manually or automatically (for example, through materials planning). In the item detail on the Contact person tab, the creation indicator can provide information.
Subscribe to:
Posts (Atom)