Reason of using OK_CODE
In the ABAP dynpro programming, we always deals with OK_CODE which contains the function code user triggers. For each screen, there is a default UI element with type OK. The element is used to pass function code to the program for further processing.

But new comer may raise a question: the system field SY-UCOMM also contains the function code that user triggers. Why we still need another field OK_CODE for this purpose.
There are two reasons for this: Firstly, the ABAP program has full control over fields declared within it, and secondly, you should never change the value of an ABAP system field. However, you should also always initialize the OK_CODE field in an ABAP program for the following reason:
In the same way that the OK_CODE field in the ABAP program and the system field SY-UCOMM receive the contents of the corresponding screen fields in the PAI event, their contents are also assigned to the OK_CODE screen field and system field SYST-UCOMM in the PBO event. Therefore, you must clear the OK_CODE field in the ABAP program to ensure that the function code of a screen is not already filled in the PBO event with an unwanted value. This is particularly important when the next PAI event can be triggered with an empty function code (for example, using ENTER). Empty function codes do not affect SY-UCOMM or the OK_CODE field, and consequently, the old field contents are transported.
Below is the code snip to show how to use field OK_CODE:
* Global data declarations: DATA: OK_CODE LIKE SY-UCOMM, SAVE_OK LIKE SY-UCOMM. * PAI module: MODULE USER_COMMAND_100 INPUT. SAVE_OK = OK_CODE. CLEAR OK_CODE. CASE SAVE_OK. WHEN... ... ENDCASE. ENDMODULE.