Nueva Solapa en tx ME51n/ME52n/ME53n

La ampliación es la MEREQ001 – Para usarle es necesario crear un projecto en la CMOD.

clip_image002

1 - Primero hay que ampliar el include CI_EBANDB con los campos que nosotros vamos a desear. (esto extenderá la tabla EBAN).

Ejemplo ZLAND1 y ZXBLNR

clip_image004

2- Modificamos la Screen, la ampliación hay que modificar la subscreen 0111

clip_image006

Ejemplo simple

clip_image008

3- Modificamos principalmente las funciones EXIT_SAPLMEREQ_001 y EXIT_SAPLMEREQ_003

La EXIT_SAPLMEREQ_001 es para pasar la información al customer exit y la EXIT_SAPLMEREQ_003 para grabar los datos de exit a las tablas.

 

EXIT_SAPLMEREQ_001

*&---------------------------------------------------------------------*
*&  Include           ZXM02U01
*&---------------------------------------------------------------------*
data   :  i_mereq_item type mereq_item,
          gf_aktyp type aktyp,
          lc_garg type eqegraarg,
          lc_edit(1),
          ls_head type mereq_header,
          lc_header type ref to if_purchase_requisition,
          ti_enq type table of seqg3 .
CLEAR lc_edit.
if im_req_item is initial.
else.
  i_mereq_item = im_req_item->get_data( ).
endif.
" Chequeo para visualizar/modificar el campo (ya que por default está simpre editable
if sy-tcode eq 'ME53N'.
    lc_header = im_req_item->get_requisition( ).
concatenate sy-mandt ls_head-banfn '*****' into lc_garg.
call function 'ENQUEUE_READ'
exporting
        gclient = sy-mandt
        gname   = 'EBAN'
        garg    = lc_garg
        guname  = sy-uname
tables
        enq     = ti_enq.
if ti_enq[] is not initial.
      lc_edit = 'X'.
else.
clear lc_edit.
endif.
endif.
EXPORT g_edit = lc_edit TO MEMORY ID 'FLAG_EDIT'.

 

EXIT_SAPLMEREQ_003

*&---------------------------------------------------------------------*

*&  Include           ZXM02U03
*&---------------------------------------------------------------------*
tables: ci_ebandb.
data : l_mereq_item type mereq_item.
if not im_req_item is initial.
   l_mereq_item = im_req_item->get_data( ).
if ( ci_ebandb-zland1 ne l_mereq_item-zland1 ).
   move-corresponding  ci_ebandb to l_mereq_item .
   call method im_req_item->set_data( l_mereq_item ).
   ex_changed = 'X'.
endif.
endif.

En el PBO de la SubScreen agrego la lógica para determinar si hay que grisar el campo o no.

module status_0111 output.
*  SET PF-STATUS 'xxxxxxxx'.
set titlebar 'TEST'.
data: l_edit(1).
* se chequea que se esté en la ME51N/2 o 3 en modo edición
import g_edit to l_edit from memory id 'FLAG_EDIT'.
loop at screen.
if  sy-tcode = 'ME51N' or sy-tcode = 'ME52N' or ( sy-tcode = 'ME53N' and l_edit = 'X' ).
screen-input = 1.
else.
screen-input = 0.
endif.
modify screen.
endloop.
endmodule.                 " STATUS_0111  OUTPUT

 

 

RESULTADO FINAL

Visualización

clip_image010

Modificación

clip_image012

Al grabar se grabará el campo creado en la EBAN.

 

 

 

A modo informativo dejo la función del resto de las funciones, sirven para hacer validaciones, mostrar mensajes, etc.

Function exits

The screen is linked to the standard program via function modules. There are function modules that:

o Provide your subscreen with data (export)

- EXIT_SAPLMEREQ_001 Export Data to Customer Subscreen for Purchase Requisition(PBO)

- EXIT_SAPLMEREQ_002 Prepare Customer Subscreen for Requisition (PAI Before Subscreen PAI)

o Get data from your subscreens (import)

- EXIT_SAPLMEREQ_003 Import Data from Customer Subscreen for Purchase Requisition

You can set or supply your own data fields in the PBO function modules.You receive the current (possibly changed in comparison to the PBO call) standard program data in the PAI function module. You can return your fields to the standard program in the import function modules. For this purpose, read the current status of the purchase requisition object using the method get_data in a local structure of type mereq_item. Now write the customer data in this structure and reset the data in the purchase requisition object using the method set_data.

You should note that function exits 001, 002, and 003 are determined for dialog purposes only and are not headed for when creating purchase requisitions using function modules or BAPIs. Do not issue any error messages in these function modules either. There is a separate function exit for verifying the customer fields (EXIT_SAPLMEREQ_005 Checking Customer's Own Purchase Requisition Data (Without Dialog)). The object reference, the new data, the data from the last verification, and the database status of the purchase requisition items are available to you here. Parameter IM-FULL_CHECK is set if the user has chosen to update or check explicitly. Parameter IM_ITEM_HAS_ERRORS informs you whether the purchase requisition item has been classified by the standard program as containing errors.

The task of this function exit is to ensure the consistency of the customer-specific fields. You can also change standard fields using the public interface if_purchase_requisition_item. The fields listed in structure MEREQ_ITEM_S_CUST_ALLOWED are available for changing. You fill the return table EX_MESSAGES to issue the errors and warnings to the standard program and the user. The fields TYPE, ID, NUMBER, and MESSAGE_V1 thru MESSAGE_V4 are analyzed and added to the standard error log. You have to set the return parameter EX_RECHECK_ITEM if you have changed standard fields. The standard program checks the purchase requisition

item after exiting the function exit again. You should note that the functions exits are chosen again when this is done. To avoid endless loops, you should not set this parameter every time. The purchase requisition is updated in two steps. In the first step (PREPARE), the function exit EXIT_SAPLMEREQ_008 (Prepare for Update of Customer's Own Purchase Requisition Data) is called up. The system tells you the old (temporary) purchase requisition number and the new purchase requisition number. In addition, the changes are given to tables EBAN and EBKN. You can no longer change the fields here. You use this module to prepare for updating your own data and tables. Do not execute any database operations or call any function modules for the update (in update task). Make a note of which data you want to update in your function group. You should note that more than one purchase requisition can be processed at the same time (for example, source of supply assignment or collective release). This function exit is processed once for each header in the purchase requisition. The second step in the update process performs the database operations  or calls the update modules. Function exit EXIT_SAPLMEREQ_006 (Update o Customer's Own Purchase Requisition Data for all PReqs Prepared). This function exit is called up only once for all purchase requisitions that have been changed. You now update the data that you noted in the first step. When all purchase requisitions have been successfully updated, function exit EXIT_SAPLMEREQ_004 (Reset Customer Data After Updating All Purchas Requisitions (Without Dialog)). You reset the data for your function group(s) here.

If you want to read your own tables for this, you should use the function module EXIT_SAPLMEREQ_007. This is called when the purchase requisition is read from the database. You receive the transaction type via the purchase requisition header. The interface if_purchase_requsition_item provides a method,  GET_REQUISITION, that returns the purchase requisition header. Using method GET_TRANSACTION_STATE for interface if_purchase_requisition, you can determine the transaction type from field ex_document.

o A Display

o V Change

o H Create