Wednesday, November 8, 2017

Closing Cockpit Without Transport Request


Closing Cockpit without transport request:

Clocking Cockpit is used for month end/quarter end/yearend activities with some defined steps as per the client needs. There are some situations where you may have to add additional step for that month end or quarter end, in those situation we have to create that step in development system and transport that entry into production system. This process is little time consuming and client cannot wait to perform his month end/quarter end activities.

We can bypass the transport creation with standard code enhancement .Also we can put some additional conditions like based on users and system wise.

Step 1: Go to transaction code SE24 and enter object type CFC and display.

Step 2: Open the method Transport and click on Enhance button.

Step 3: Now click on show implicit or explicit enhancements options.

Step 4: Create enhancement on the top of the code and add the logic to skip the code inside the method when user accessing closing cockpit transaction.

Test Data creation at Runtime from SRM to ECC


Capture test data at runtime in standard function modules from SRM to ECC.

In day to day life, we come across situations where we have to debug standard code or transaction codes for different issues from SRM to ECC systems. Being standard code, sometimes it may take days to find exact root cause of the issue. Finally after completing the analysis we may end up saying as data issue, based on the data provided at the time of updating or posting to standard FM’s BAPI_PO_CHANGE or BAPI_PO_CREATE etc... So, it will be useful if we have test data created in those function modules at the time of transaction executed.

Below are the steps to activate test data creation:

Step 1: On ECC, set the parameter FBGENDAT ‘X’ in the backend system for the RFC user of the SRM system.

Step 2: on ECC, execute report FBGENDAT in the mode ‘B’.

Step 3: on SRM, reproduce the issue from start.

Step 4: on ECC, check if a test data record was generated in the function builder.

Step 5: on ECC, deactivate the generation of test data records by deleting the entries in report FBGENDAT and resetting the user parameter.

Wednesday, April 23, 2014

Code useful for executing ALV Grid report in Background mode causing short dump

 
Whenever an ALV grid control program is executed in background, a short dump occurs
Error:   GUI cannot be reached 
Reason
Whenever an ALV grid control program is executed in foreground it tries to create some front-end related objects. But when the same program is executed in background, the above error occurs as it fails to create front-end objects (GUI objects). So in order to rectify this problem, we need to use the docking container instead of custom container.
The docking container doesn't need any of the custom controls on the screen, instead it attaches an area to any or all of the four edges of the screen (top, left, right or bottom).
The behavior of the areas in the container is determined by the sequence in which they are initialized. Docking Containers are attached to the screen from the inside out. This means that when you create a second container, it is attached to the edge of the screen, and the container that was already there is pushed outwards.
We can use the below code when ALV is used in background programs
DATA : or_doc TYPE REF TO cl_gui_docking_container.
IF cl_gui_alv_grid=>offline( ) IS INITIAL.
 CREATE OBJECT or_custom_container
   EXPORTING
    container_name = c_container.
 CREATE OBJECT or_grid
   EXPORTING
    i_parent = or_custom_container.
ELSE.
  CREATE OBJECT or_grid
   EXPORTING
    i_parent = or_doc.
ENDIF.
We can also use  SAP system variable SY-BATCH  is ‘X’ to check if the program is being executed in background or foreground


Wednesday, July 25, 2012

To find the IP address of application server in SAP

TYPES: BEGIN OF kernel_version,
         key(21) TYPE c,
         data(69) TYPE c,
      END OF kernel_version.
  DATA : gt_kernel_version TYPE STANDARD TABLE OF kernel_version,
         gw_kernel_version TYPE kernel_version.
  DATA ip_address(69) TYPE c.
  CALL 'SAPCORE' ID 'ID' FIELD 'VERSION'
                 ID 'TABLE' FIELD gt_kernel_version[].
  READ TABLE gt_kernel_version INTO gw_kernel_version INDEX 11.
  ip_address = gw_kernel_version-data.
WRITE ip_address.

Shift negative sign from right to left in ABAP

DATA: gv_amount type konp-kbetr.
DATA: gv_amount_text(15)  type c.
gv_amount = 100.
gv_amount = gv_amount * -1.
gv_amount_text = gv_amount.
Now value will be 100 -
CALL FUNCTION 'CLOI_PUT_SIGN_IN_FRONT'
    CHANGING
      value         = gv_amount_text.
Now final value will be -100

Details of messages being displayed on WEB UI in SAP CRM

In order to figure out the details of the messages being displayed on WEB UI in SAP CRM for analysis purpose, the following steps can be performed:
1.      Put a break-point in the method ADD_MESSAGE of the message service class CL_BSP_WD_MESSAGE_SERVICE  and replicate the scenario for which the error message is appearing on the WEB UI. The  import parameters IV_MSG_ID and IV_MSG_NUMBER of this method would have the message details.
2.      The standard database table T100 maintains the standard error messages and their message class and message number.

3.      The method call stack in the debugger (‘Standard’ tab) can then be used to trace where in the logic this message is being added.

Grey out fields on ME21N/ME22N/ME23N

How to grey out fields on ME21N/ME22N/ME23N

For certain Purchase orders, based on some condition, we need to grey out the fields NETPR & KBETR.

In order to do this, we need to find the right BADI or the right user exit to code our functionality. For this debug tool is a must to know where and how these fields are populated on the purchase order screen.

This functionality can be achieved by following the below steps.

For the PO creation/change screen below is the solution to gray out the required fields (NETPR & KBETR)

1. for NETPR:

The field catalog that fills NETPR is TC_1211 Actually in standard program SAPLMEGUI, there is a call to the FM MEGUI_BUILD_PO_ITEMOV_PLUGIN.. Inside that, in line 44, TC_1211 gets populated. This contains all field catalog values. So in BADI, code to disable field NETPR by reading values using field symbols.

In SE19:

Create Implementation — > Classic BADI –> ME_ACTV_CANCEL_PO –> Implementation name ZCL_IM_TEST

In method CHECK_ACTIVITY code the following:

Method IF_EX_ME_ACTV_CANCEL_PO~CHECK_ACTIVITY.
FIELD-SYMBOLS :<fs>        TYPE ANY TABLE,
<ls>        TYPE ANY,
<lr_screen> TYPE screen.

ASSIGN (‘(SAPLMEGUI)TC_1211-COLS’) TO <fs>.
IF sy-subrc IS INITIAL.
LOOP AT <fs> ASSIGNING <ls>.
ASSIGN COMPONENT ’SCREEN’ OF STRUCTURE <ls> TO <lr_screen>.
IF <lr_screen>-name = ’MEPO1211-NETPR’.
<lr_screen>-input = 0.
ENDIF.
ENDLOOP.
ENDIF.

endmethod.

Activate the implementation. NETPR will be disabled in the header when u try to create or change purchase order.

2. for KBETR

In Screen 6201 of program SAPLV69A -> LV69AO03à Module FELDAUSWAHL, there is a User Exit: PERFORM userexit_field_modification.

Inside this EXIT, change the contents of TCTRL_KONDITIONEN-COLS [6]-SCREEN-INPUT to 0. KBETR will get grayed out.