SAP Accounting Consulting

Symptom
In the new General Ledger Accounting, you activate the cost of sales accounting for one or more company codes and expect that the system as a rule determines the functional area using the master data or the substitution on the entry screen (see the V_FAGL_ACTIVECFC view).
However, if you enter the functional area on the entry screen of any transaction manually or you subsequently change a account assigment relevant for the functional area, then the system does not derive the functional area again.
To ensure that the system always posts the functional area, you want the system always to check the functional area of the entry screen against the derived functional area and generate a message when necessary.
Other terms
FBCJ, FB01, MIGO, ME21N, ME51N, FB01, FKBER, K_COBL_CODINGBLOCK_DERIVATION, FAREA_DRV_ALWAYS, FAREA_FROM_COBL

Reason and Prerequisites
As of ERP 2004, the system determines the functional area on the entry screen by default with a new installation.
The default logic is as follows:
If the functional area is empty, the system derives it again.If the functional area is already filled, then the system will NOT derive again. The system assumes that the functional area was filled by the user or the sending application.

But in the process, the following problems may arise:
On the entry screen, you enter an accounting object, such as a cost center. Using the cost center, the system derives the functional area again and updates it to the respective field on the entry screen (visible or hidden).
If you then change the cost center or another dependent field subsequently, the system checks as per the logic above whether the functional area already exists. Since the functional area was already filled by the initial entry, the system does not derive the functional area again.
In most cases, this is not desired.

Solution
Due to the design, many entry programs cannot detect whether or the functional area was set manually by the user, by the derivation rule or by the sending application.
Therefore, a distinction must be made between two cases:
1. Programs whose entry screen does NOT permit entry and overwrite of the functional area Fields that are used to derive the functional area can be changed, however.2. Programs whose entry screen does permit entry and overwrite of the functional area.
In the first case, the user has no option to correct the functional area. The application program must provide for a new derivation. In this case, look for a corresponding note for the entry program concerned (such as Note 1135452) or enter a customer message.
In the second case, the user may change both the functional area and the fields used for derivation (such as transaction FB01 or FBCJ). In this case, the system has no chance of finding out from where the system took the functional area.
The user must manually delete the functional area so that the system will derive again.
The possible solution is an FI validation at event 2, which compares in a user exit the derived functional area with the current functional area from the entry program and issues a message depending on the request.
Proceed as follows:
Create a user exit. In transaction GCX2, you can see under the GBLR application area in which FORM pool you have to create the user exit. Choose a user exit name that is not yet assinged (here in our example U110) and insert in the FORM pool the following lines:
…
TABLES: BKPF,
BSEG,
COBL,
…
FORM get_exit_titles TABLES etab.
…
exits-name = ‘U110′. “User exit U110
exits-param = c_exit_param_none.
exits-title = ‘Validation of Functional Area’.
APPEND exits.
…
ENDFORM. “GET_EXIT_TITLES
…

*&———————————————————————*
*& Form U110 Version 2.0
*&———————————————————————*
* Validation of Functional Area
*———————————————————————-*
* –>B_RESULT False = Error Message / Posting not posible
*———————————————————————-*
FORM U110 USING b_result.
DATA LS_COBL LIKE COBL.

B_RESULT = B_TRUE.
CHECK NOT bseg-fkber IS INITIAL.
* Additional Checks for User/Reference Transaction/…
* CHECK BKPF-AWTYP eq ‘CAJO’.
* CHECK BKPF-AWTYP ne ‘AUAK’.
* CHECK SY-UNAME ne ‘SMITHA’. “User can manually change FA
MOVE-CORRESPONDING BKPF TO ls_cobl.
CALL FUNCTION ‘MOVE_BSEG_TO_COBL’
EXPORTING
I_BSEG = BSEG
CHANGING
C_COBL = ls_cobl
EXCEPTIONS
INTERNAL_ERROR = 1
OTHERS = 2.
IF SY-SUBRC <> 0.
B_RESULT = B_FALSE.
ENDIF.
CHECK B_RESULT = B_TRUE.
CLEAR ls_cobl-fkber.
CALL FUNCTION ‘FAGL_FUNC_AREA_FRM_COBL_DERIVE’
EXPORTING
I_COBL = ls_cobl
IMPORTING
E_COBL = ls_cobl
EXCEPTIONS
ERROR_OCCURRED = 1
NOT_FOUND = 2
OTHERS = 3.
IF SY-SUBRC <> 0.
B_RESULT = B_FALSE.
ENDIF.
IF ls_cobl-fkber <> bseg-fkber.
B_RESULT = B_FALSE.
ENDIF.
ENDFORM. “U110
Save and activate the FORM pool.
Call transaction OB28. Here, you can assign the respective validation to the company code. To create the validation, choose the F2 function key or choose “Environment > Validation”.
Create new validation under “Line item” (CTRL+SHIFT+F4) or if you already use a validation, then add an additional step (CTRL+SHIFT+F5).
If, for instance, you want to validate the functional area from the cash journal, then enter SYST-TCODE = ‘FBCJ’ as prerequisite. You can also use any other transaction or all transactions (TRUE).
In the “Check” area, enter the user exit above. The system must display it on the “Exits” tab page.
Create a message with the “E” message type, and enter a helpful text so that the blocked user knows what to do, at least in the long text.
If you issue an error message for programs from case 1, these may look like this: “The functional area does not match the derivation” “Delete the functional area field for a new derivation”Then save the validation and return to the initial screen of transaction OB28. Then assign the validation to the company code concerned and set the activation level as required.
Using this user exit, you can again check prior to posting any document as to whether the functional area from the entry program matches that from the derivation.