INTRODUCTION: The document gives the details of the methods to enhance the screen in the purchase order considering example scenarios.
Modification to purchase order screen
Problem Statement: Consider a scenario, where there is a need to add field(s) in the purchase order header and to add the desired functionality there upon.
Analysis of problem Statement: There is no direct way to add a field to any of the existing screens neither in header data screen nor in Item screen i.e. there are no enhancements provided for the existing tabs.
For example there is no enhancement to customize Org. Data Tab in ME21N.
Solution: First priority is to introduce a new field into the Purchase Order Header table and add functionality accordingly.
For this, what needs to be done is the addition of the field in Include structure CI_EKKODB meant for enhancement in Purchase order header table (EKKO) The visual description for the same is shown in the below screenshot.
For this, we need to introduce a new field into the include standard structure of EKKO, ‘CI_EKKO’ same goes with EKPO as ‘CI_EKPO for purchase order item table.
As shown above,‘ZZTEST1’ is added into EKKO table.
The appending a field to Header table is done and next step is to add it to the purchase order screen.
To add any field to the purchase order screen (ME21N, ME22N, and ME23N) a custom tab needs to be created.
Steps:
In the above screenshot “Customer Data” is the custom created Tab.
This can be achieved via enhancements or via BADI.
- Method 1: SCREEN EXIT.
- Method2: BADI.
Method
Screen Exit Method:
Tech Specs:
Enhancement: MM06E005
Create project to implement this enhancement, activate this.
In the above screenshot i.e. in the screen exit screen no. 101, 111, 201, 211, 301, 311.
Basically, these are to add a new tab to header as well as item data part. The description for screen is provided in below two lines through which one can classify item and header level screens.
101, 201, 301-> Header Data New Tab
111, 211, 311-> Item Data New Tab
Here in Include Table you might be seeing two include structure i.e. CI_EKKODB, CI_EKPODB.
The structure I_EKKODB is for appending any additional fields to PO header table (EKKO).
The structure I_EKPODB is for appending any additional fields to PO Item table (EKPO).
Consider a scenario here requirement is to add a tab to header data, so we use 101 to achieve the equirement.
- Double click on screen ‘0101’ then it ill redirect to module pool program screen. Click on the layout and draw a field in the screen, the way it is depicted in the screen below, then activate the changes.
2. After activation a new tab in the screen will be created with name Customer data, as shown in the screenshot below.
3. In order to change the ‘Customer Data’ tab name to any custom tab name the below steps can be followed:
Go to Program: SAPLXM06 in SE38
Then goto->Text Element->Text Symbols
Make a new text symbol with the same number as of your screen number in layout of which you inserted a new field.
Say “IGTR” (Tab’s new name) -> activate.
4. After activating the name will be changed from ‘Customer Data to’ -> ‘IGTR’ or the custom name you gave in SAPLXM06.
As shown in example below.
Now it can be considered that most of the part of our requirement is done i.e. The screen is made so is the field in the screen.
Now, the next step is to make this field store and retrieve the values to and from the Purchase order header table (EKKO) as per the user actions. For this logic is to be written in the identified exit.
We use EXIT_SAPMM06E_012 is highlighted as this the exit can be used to fill the additional fields in PO header.
Can be seen in debugging mode the field(s) in the structure reflects i.e. the same fields that were added in PO header include Structure.
Let’s say we have set the additional field ZZTEST1 For which the value is being updated in purchase order header table (EKKO).
Now it is observed that we are done with the changes into the Header table.
Consider a PO in which the field is populated i.e. when a Purchase Order is opened in ME22N, ME23N it should reflect on screen.
The change has to be done in the PBO of the screen as well i.e. the screen’s layout in which the field(s) was/ were introduced. Just Retrieve the data based on your required condition and populate to the screen field as shown below:
* Fetching the Header data through Field Symbol
ASSIGNEKKOTO<FS>.
SCREEN-FIELD = <FS>-ZZTEST1.
Note: Case needs to be considered:
While creation of PO through ME21N, say we create one item in the PO and delete it.
Then ME21N screen re-opens (we are not opening new transaction) and the header data still remains with the additional field set.
So, if the item is created and deleted, header field still remains in the header which is not correct.
Steps: Check the PO item table i.e. EKPO i.e. if it contains the data, else clear the flag.
ASSIGN T_EKPO data TO<F_EKPO>.
IF T_EKPO ISINITIALAND SY-TCODE = 'ME21N'.
CLEAR: <screen-field>.
ENDIF.
Note: The main draw back in this method of field addition is that the new tab can’t be controlled and will appear in all the PO’s once it is created.
The second method though the BADI overcomes this issue.
Method 2:
BADI: ME_GUI_PO_CUST
Method: SUBSRCIBE
Primarily Create an instance say X through which the tab elements needs to be referred to the program i.e. as of type of work area bearing the structure of RE_SUBSCRIBERS table.
Then what needs to be check is the application i.e. whether it is PO, SO, Delivery via parameter IM_APPLICATION and current operating position of the program needs to be checked whether it is item or header level via IM_ELEMENT.
There are various other parameters which need to assign via instance created i.e.
- NAME, which deals with the tab name that will be displayed in ME21N, ME22Nand ME23N.
- DYPRO, the screen number which it will refer to.
- PROGRAM, the program name where the DYNPRO (screen) can be traced.
- STRUCT_NAME, the structure to which the field has been appended i.e. in PO header or PO item level.
- POSITION, the position of the tab among the existing tabs, the height of the screen can be defined here. Currently it supports two screen sizes i.e. when value <=7 a seven line sub screen, when it is >7, then a 16 line sub screen.
POINTS TO NOTE:
- In Method1 i.e. through screen exit, the whole of the code will only work upon click on check button or save button.
- However, to trigger the same logic before save or check ,we need to implement BADI ‘ME_PROCESS_PO_CUST’ and the method in which you need to write the same logic in method ‘PROCESS_ITEM’.
- In Method 1 i.e. through screen exit we won’t be able to control the custom tab i.e. say IGTR (as it appears in screenshot on page 7), If this is required we should go for method 2. Through BADI ‘ME_GUI_PO_CUST’.
If specific requirement is not provided i.e. the Tab is not restricted to any particular order Type then I would recommend going with method 1 as in terms of complexity it is low and is easier as compared to the second method.