Transparent table.
From SAP help: There is a physical table on the database for each transparent table. The names of the physical table and the logical table definition in the ABAP/4 Dictionary agree. All the business and application data is stored in transparent tables.
Structure.
From SAP help: No data records exist on the database for a structure. Structures are used for the interface definition between programs or between screens and programs.
Cluster table.
From SAP help: Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table category. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Pooled table.
From SAP help: Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.
General view structure.
From SAP help: A structure is generated for a view during activation. This structure is used as the interface for the runtime environment. It is not usually displayed in the ABAP Dictionary.
Append structure.
From SAP help: An Append structure defines a subset of fields which belong to another table or structure but which are treated as a separate object in the correction management. Append structures are used to support modifications.
Saturday, April 28, 2012
SAP Enterprise Structure
SAP enterprise structure is organizational structure that represents an enterprise in SAP ERP system. It consists of some organizational units which, for legal reasons or for other specific business-related reasons, are grouped together. Organizational units include legal company entities, sales offices, profit centers, etc. Organizational units handle specific business functions.
Organizational units may be assigned to a single module (such as a sales organization is assigned to Sales and Distribution (SD) module, or to several modules (such as a plant is assigned to Materials Management (MM) and Production Planning (PP) module). SAP ERP system can represent a complex enterprise structure.
Enterprise structure design is a fundamental process in a SAP implementation project. The design is mainly determined by the business scenarios performed in an enterprise. Once the design is determined, it will affect many things such as how to perform a transaction and generate reports on SAP system. Although it’s possible, it requires great effort to change the enterprise structure. So , we must ensure that the enterprise structure designed in the SAP implementation project can accommodate all business scenarios and enterprise’s requirements for current and future situation.
The SAP Enterprise Structure is a fundamental setting and needs a comprehensive understanding of the business processes and their integration. We have to work with other departments and SAP modules, such as Accounting department (FI), and Sales department (SD).
This book explains in details about the basic concept of SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) and step by step how to configure it in SAP ERP system. To make it more understandable, it is supplied with a case study and the screen shots of each configuration step.
It's written in a simple-to-understand way, so you can learn it easily. You don't need to have extensive SAP configuration skill and experience to be able to configure the SAP Enterprise Structure.
Table of contents of the e-book:
Chapter 1: Case Study Business Scenario
Chapter 2: SAP Enterprise Structure
Enterprise Structure in Financial Accounting
Enterprise Structure concept in Financial Accounting
Define Company
Define Company Code
Assign Company Code to Company
Define Business Area...page 13
Enterprise Structure in Logistics – General
Enterprise Structure concept in Logistics
Define Plant
Define Valuation Level
Define Division
Assign Plant to Company Code
Assign Business Area to Plant/Valuation Area and Division
Enterprise Structure in Sales and Distribution (SD)
Enterprise Structure concept in Sales and Distribution
Define Sales Organizations
Define Distribution Channel
Assign Sales Organization to Company Code
Assign Distribution Channel to Sales Organization
Assign Division to Sales Organization
Setup Sales Area
Assign Sales Organization – Distribution Channel - Plant
Business Area Account Assignment
Enterprise Structure in Material Management (MM)
Enterprise Structure concept in Material Management
Maintain Storage Location
Maintain Purchasing Organization
Assign Purchasing Organization to Company Code
Assign Purchasing Organization to Plant
Assign Standard Purchasing Organization to Plant
Assign Purchasing Organization to Reference Purchasing Organization
SAP MM Config - Create a New Plant
IMG for SAP Plant Maintain
How to Configure a New Plant in SAP?
Plant 0001 is the SAP default provide for your reference.
OX14 - Define Valuation Area (Tick one only- Once your system go live, no more changes)
Most company take the SAP recommended choice - Value Material Stock at Plant level
Value Material Stock at Plant or Company Level
If you valuate material stocks at plant level, the plant is the valuation area.
If you valuate material stocks at company code level, the company code is the valuation area.
The decision you make applies to the whole client.
OX10 - Create / Change / View Plants
OVXB - Create / Change / View Division
OX18 - Assign Plant to company code
e.g. 0001 - 0001 - All Plants
Px1 - Plant Px1
Px2 - Plant Px2
OX19 - Assignment of company code to the Controlling Area
OB38 - Assign company code to Credit Control Area
OMJ7 - Assign business area to Plant/Valuation area and division
e.g. Plant Px1 - Business Area Bx1
Bx2
Assign Valuation area to the Business Area
.e.g. Valuation area Vx1 - Business Area Bx1
Business Area Bx2
OMS0 - Assign Factory Calendar to the Plant and Business Area
The plant plays an important role in the following areas:
Material Valuation - If the valuation level is the plant, the material stocks are valuated at plant level. Each plant can have its own material prices and account determination.
Inventory Management - The material stocks are managed within a plant.
MRP - Material requirements are planned for each plant. Each plant has its own MRP data. Analyses for materials planning can be made across plants.
Production - Each plant having they own production/planning.
Costing - In costing, valuation prices are defined only within a plant.
Plant Maintenance - If a plant performs plant maintenance planning tasks, it is defined as a maintenance planning plant. A maintenance planning plant can also carry out planning tasks for other plants (maintenance plants).
If you want to use the application PP (production planning) or product costing and job-order costing, you must set valuation at plant level.
The valuation level that you choose affects
the maintenance of material master records
the G/L accounts in which material stocks are managed
the G/L accounts to which transactions are posted in Materials Management
Effect on the maintenance of material master records:
Depending on the valuation level chosen,
you maintain accounting data in the material master record for each plant or for each company code
you define a valuation price for the material in each plant or in each company code
Effect on G/L accounts:
If material stocks are valuated at company code level, all plant stocks of a material are managed in a joint stock account for each company code.
If material stocks are valuated at plant level, you can manage the material stocks for each plant in different accounts. For each plant, you can define a separate determination.
If several plants are to use account determination, you can group these plants in "Valuation and Account Assignment" Customizing.
MM Configuration: Define Plant
Step-by-Step SAP Material Management (MM) Configuration: Define Plant
This post will explain a step by step SAP MM configuration of how to define a plant in an SAP client.
A plant is the place of production, or branch of a company, or simply a collection of several locations of material stocks in close physical proximity.
A plant is represented by a client-unique 4-digit alpha-numeric.
Plant is used in Material Management (MM), Production Planning (PP), Sales and Distribution (SD), and Plant Maintenance (PM) module.
A plant is assigned to one company code.
One company code can have more than one plant.
One Business Area is assigned to plant.
Several plants can have same business area.
We can define Plant in a SAP R/3 client with T-code: SPRO.
SAP Screenshots of How to define a plant are:
Go to the menu: IMG – Enterprise Structure – Definition – Logistic-General – Define, Copy, Check, Delete Plant:
The above image is © SAP AG 2010. All rights reserved
Click Execute button, the next screen is:
The above image is © SAP AG 2010. All rights reserved
Select “Define Plant” if we want to create a plant from the scratch, or select “copy, delete, check plant” if we want to copy a plant from an existing plant. In this example we will create a plant from the scratch. The next screen is:
The above image is © SAP AG 2010. All rights reserved
Click “New Entries” button. The next screen is:
The above image is © SAP AG 2010. All rights reserved
Fill the Plant code that we want to create (client-unique 4-digit alpha-numeric) in the plant field. Then click “address” icon. The next screen is:
The above image is © SAP AG 2010. All rights reserved
Fill the required field as above image, and click “OK” button or press “Enter”. The next screen is:
The above image is © SAP AG 2010. All rights reserved
Click the “save” button. And the next screen is:
The above image is © SAP AG 2010. All rights reserved
The GC01 plant has been created. Then we need to assign this plant to a company code and business area.
SAP Study Materials Series e-Book
To get more details on SAP Enterprise Structure, you can buy my e-book (50 pages .pdf file) at SAP Study Materials Store.
The e-book explains in details about the SAP Enterprise Structure (MM and related modules such as FI, Logistics, and SD) Concept and Configuration Guide. Just like other articles on my SAP Study Materials blog, I wrote the e-book in a simple-to-understand way, so you can learn it easily. You don’t need to have extensive SAP knowledge and experience to be able to configure the SAP Enterprise Structure, as the e-book start explaining each step with the basic concept behind it. After understanding the concept, the e-book will show the step-by-step configuration with the screen shots.
Maintaining Vendor Master Records
Use
If you wish to store information on your vendors in the SAP System, the following functions are available:
Create vendor master record
Change vendor master record
Block vendor master record
Use one-time vendor
Display list of vendors
Procedure
Create Vendor Master Record
Choose Master data Vendor Central Create from the Purchasing menu.
Enter the purchasing organization and an account group. If you want to use another vendor master record as a reference, enter the account number of that vendor in the Vendor (creditor) field (under Reference). Press ENTER .
The Create Vendor: Address screen appears. Enter the address and press ENTER .
The Create Vendor: Control screen appears. On this screen, enter the accounting data needed by the payment and dunning program, and data for declarations to the tax authorities. Also populate the Debtor (customer) field where necessary (the data in this field is needed in the case of deliveries to the vendor in connection with Returns and Subcontracting Components.
Press ENTER and enter the necessary data on the subsequent screens that appear.
On the Purchasing Data screen, enter purchasing-specific data such as the order currency or the key for the terms of payment and then press ENTER .
You can record the Terms of Payment that you agree with a vendor in the vendor master record. They automatically appear as default values in any purchase orders created for the vendor in question; however, you can change them as needed.
Terms of payment can also be entered in the vendor's invoice. These are then applied by the payment program.
The Create Vendor: Partner Roles (partner functions) screen appears. Maintain the necessary partner roles on this screen. (See Partner Roles in Purchasing.)
Click to save the vendor master record.
Change Vendor Master Record
Choose Master data Vendor Purchasing ® Change.
Enter the vendor number and the purchasing organization, and select the data you wish to change. Press ENTER .
Enter your changes and click to save your input.
Block Vendors
Suppose you would like to prevent further deliveries from a vendor who has supplied goods of poor quality. You can freeze or "block" the vendor account in the vendor master record.
Once you have set the blocking indicator in the vendor master record, purchase orders can no longer be placed with this vendor. The "blocked" status for the vendor applies until such time as you cancel the blocking indicator.
To block a vendor, proceed as follows:
Choose Master data ® Vendor ® Purchasing ® Block. Enter the vendor number and the purchasing organization. Then press ENTER .
A screen appears, on which you can indicate whether the vendor is to be blocked for a specific purchasing organization or for all purchasing organizations.
If QM is active within the procurement function, you can impose a block for quality reasons. (See the documentation Quality Management (QM) Overview of Procurement Activities)
Click to save your input.
You can block a vendor for an individual material via the source list.
For more information, refer to the section Optimized Purchasing.
Use One-Time-Vendor
You can create special vendor master records for vendors from whom you procure goods only once or rarely, so-called One-Time Vendor Master Records.
For example, suppose you order goods from a vendor with whom you usually do not place orders, because your main vendor was not able to supply the required items. In this case, you would use a "one-time vendor" master record.
In contrast to other master records, a "one-time vendor" master record is used for several vendors. The purpose of this is to avoid the unnecessary creation of an excessive number of individual vendor master records. For this reason, you may not store any vendor-specific data in a "one-time vendor" master record.
When creating a "one-time vendor" master record, you must assign a one-time account group. This account group determines that the vendor-specific fields are suppressed. You don’t need to enter this data until the time a purchasing document (e.g. a PO) is created.
When you create a purchasing document with a one-time vendor, you will be asked to enter the vendor address. Enter the vendor’s name and address.
Like all other master records, you can display, block, or delete one-time vendor master records.
Display List of Vendors
You can create a list of different vendors. This list contains important information on individual vendors: the purchasing organizations for which material was procured from a vendor, the terms of payment, and the blocking status of the vendor, for example.
Choose Master data ® Vendor ® List displays, then Purchasing list.
Enter your selection criteria and run the analysis.
Parameters
Syntax
PARAMETERS name(length) [TYPE type or LIKE obj] DECIMALS d.
Examples
PARAMETERS: char1(20) TYPE C,
date1 LIKE SY-DATUM,
number1 TYPE P DECIMALS 2.
Options
DEFAULT
Example:
PARAMETERS p1(5) TYPE C DEFAULT ’we’.
MEMORY ID
Example:
PARAMETERS p2(5) TYPE C MEMORY ID pid.
LOWER CASE
Example:
PARAMETERS f1(10) LOWER CASE.
VISIBLE LENGTH
Example:
PARAMETERS f1(10) TYPE C VISIBLE LENGTH 4.
OBLIGATORY
Example:
PARAMETERS f1(10) TYPE C OBLIGATORY.
MATCHCODE OBJECT
Example:
PARAMETERS p_belnr LIKE BKPF-BELNR MATCHCODE OBJECT zsh_f4_belnr.
VALUE CHECK
Example:
PARAMETERS p_belnr LIKE BKPF-BELNR OBLIGATORY VALUE CHECK.
AS CHECKBOX
Example:
PARAMETERS: c1 AS CHECKBOX DEFAULT ’X’.
RADIOBUTTON GROUP
Example:
PARAMETERS: r1 RADIOBUTTON GROUP rad1 DEFAULT ’X’,
r2 RADIOBUTTON GROUP rad1,
r3 RADIOBUTTON GROUP rad1.
NO-DISPLAY
Example:
PARAMETERS: f1(10) TYPE C NO-DISPLAY.
MODIF ID
Example:
PARAMETERS: f1(10) MODIF ID GR1.
Tuesday, October 25, 2011
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.
(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.
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
Subscribe to:
Posts (Atom)