BAdI Name Package

BADI_UJ_PARAM_CHANGE UJA

BADI_UJ_BPF_SUBMIT_LOGIC UJB

BADI_UJC_COMMENT_PREPROCESS UJC

BADI_UJCTRL_RUN_CONTROL UJCTRL

BADI_UJD_RETRACT UJD

BADI_UJD_ROUTINE UJD

UJE_DIM_PROCESSED_BADI UJE

BADI_UJE_DYNAMIC_DAP UJE

BADI_UJJ_CALCULATED_AMOUNT UJJ

BADI_UJ_CUSTOM_LOGIC UJK
BADI_UJO_WRITE_BACK_NOTIFY UJO

BADI_UJ_SQE_POST_PROCESS UJQ

BADI_UJR_WRITE_BACK UJR

BADI_UJ_VALIDATION_RULE_LOGIC UJV
BADI_UJW_STATE_CHANGE UJW

UJW_LOCKOUT_SCHEDULE_BADI UJW
Description

BPC: BADI For Appset/Application Param Change

BPC: BADI for submitting Logic of BPF Step Region to SUBMITTED status.

BPC: Pr4eprocess BADI for comment saving

BPC: BAdI Definition for Custom control rule

BPC: BADI for DM Retract

BPC: BADI for DM Routine

enhancement spot for DAP update when dimension is processed

BAdI for customizing dynamic DAP

BPC: BADI to add calculated amounts on journal save

BPC: BAdI Definition for Custom Logic

Obsolete, please DO NOT use!

BPC: BAdI Definition for Custom Logic

BPC: Preprocess BAdI of WriteBack module

BPC: BAdI Definition for Rule Logic in Validation

BADI For Changing Work State

Enhancement spot for data locking

Comment

Triggered when user change a parameter in IMG. Normally it's used by

BPC internally to apply some specific check when maintaining an IMG
parameter.

When submitting an activity, (not completing the activity, i.e. the

activity needs to be reviewed), customer could customize the
implementation to decide the "submit" success or not. When
implement the logic, you could get template/instance/step region
information via CL_UJB_TMPL-> DS_TMPL / CL_UJB_INST ->DS_INST /
CL_UJB_STEP_RGN-> DS_STEP_RGN.

Provide pre-process capability to customer when BPC comment related

operation occured. By implementing the BAdI interface, customer
should be able to add extra backend logic to comments before which
were saving back to database table.

Provide the ability to check data with customer code. In order to use
this badi, customer need to create one custom control in BPC web client
and do not need to specify the badi implementation. BPC will filter the
badi implementation with the filter appset_id and appl_id. If no
corresponding badi implementation exists then we regard this control
rule result is passed.

The data which will be retracted into ERP has two types: masterdata and
transaction data. There will be two process types to call the BADI for
masterdata and the BADI for transaction data. There will be two process
chains to call the process types: one is for retract masterdata and
another is for retract transaction data.The names of the BADI are fixed.
The user needs to specify the filter in the data package script to show
which BADI implementation will be called.At one time, only one BADI
implementation will be decided by the filter.For master data, the BADI is
based on table level.For transaction data, the BADI is based on package
level.
The user will define *start_routine and *end_routine in transformation
file.

It will be triggered when dimension is processed (for example, updating

dimension data through BPC web client or DM package).

1.Customer can apply dynamic security strategy with BAdI

implementation. For example, with BAdI, customer can read security
setting from other tables( which might be shared with other
applications ) and overwrite static data security setting.
2.Reduce the number of Data Access Profiles(DAP).

When saving a journal, you can add or calculate extra amounts by

implementing the Business Add-In (BAdI) UJJ_CALCULATED_AMOUNT.
You use this instruction to call any custom ABAP programming you have
written.
There are two methods for this BAdI,
IF_UJQ_SQE_POST_PROCESS~POST_PROCESS and
IF_UJQ_SQE_POST_PROCESS~CUSTOMIZE_PROPERTIES, which are for
different purpose.

POST_PROCESS is triggered after data is read from database. Specific

logic can be implemented here to manipulate data before it is sent to
frontend.

CUSTOMIZE_PROPERTIES is triggered before web report is displayed. By

master data properties with BAdI implementation, customer can change
member description and input enablement on BPC web reporting.

This BADI will be executed before data is submitted to cube, which

means it can manipulate data as a pre-process step. This BADI filter is
defined with specific BPC environment, model and input module.

If user chooses Use BAdI implementation in validation rule definition,

whether the data entry could pass validation would be defined in the
customized logic in BAdI implementation.

This BAdI could be implemented under filter for specific BPC model and
input module. If the BAdI is implemented, the BAdI implementation
would be called during work status check before data input to replace
the default work status logic. Thus user could customize the specific
logic to determine whether the data entry should be locked according to
the customized work status logic during runtime.