On the text above, as you can see, SAP tells you that the user needs the authorization so he can accept or reject the new credit limit for the BP. But why the user?
The user requests a new credit limit for a BP like this:
And after that (new value requested), as you can see, 2 buttons (approve/reject) comes up to handle the actions (by a user). Also, a standard workflow (classical) can get triggered.
So let’s take a look at this standard Workflow WS01700048.
As mentioned on the documentation, the event WF_TRIGGER of object CL_UKM_ACCOUNT get’s triggered:
But looking at the design of this Workflow, we can see a simple (one task) flow:
Where this only task get’s sent to the initiator of the Workflow:
And when he executes (there is no approve/reject button), it’s open BP for him to edit (taking a look at the ABAP code as well):
Where then (in the transaction) he can execute the action (approve/reject) button:
But in most cases that will not do, specially if:
1. The customer want’s a multi level approval process, and only after all approvals release the credit limit.
2. The customer need’s a custom application process that will execute the approval in background for some reason (app or something…);
3. Etc.
So by taking a look at the standard code behind those buttons, something like this:
I came up with this function, that can approve/reject (i_ok = ‘X’ approves and i_ok = ” rejects) the credit limit in background mode (without any need to go to the transaction):
FUNCTION zwfbp_credit_action.
*"----------------------------------------------------------------------
*"*"Interface local:
*" IMPORTING
*" REFERENCE(I_PARTNER) TYPE BUT000-PARTNER
*" REFERENCE(I_SEGMENT) TYPE UKMBP_CMS_SGM-CREDIT_SGMNT
*" REFERENCE(I_OK) TYPE CHAR1
*"----------------------------------------------------------------------
DATA: go_account TYPE REF TO cl_ukm_account.
DATA: go_facade TYPE REF TO cl_ukm_facade,
go_bupa_factory TYPE REF TO cl_ukm_bupa_factory.
DATA:
ls_bp_cms_sgm TYPE ukm_s_bp_cms_sgm,
l_old_valid_date TYPE ukm_s_bp_cms_sgm-limit_valid_date.
go_facade = cl_ukm_facade=>create(
i_activity = cl_ukm_cnst_eventing=>bp_maintenance ).
go_bupa_factory = go_facade->get_bupa_factory( ).
CALL METHOD go_bupa_factory->get_credit_account
EXPORTING
i_partner = i_partner
i_credit_sgmnt = i_segment
RECEIVING
ro_credit_account = go_account.
* remember last valid to date
CALL METHOD go_account->get_bp_cms_sgm
IMPORTING
es_bp_cms_sgm = ls_bp_cms_sgm.
l_old_valid_date = ls_bp_cms_sgm-limit_valid_date.
* Here is where the magic happens…
CALL METHOD go_account->handle_requested_limit
EXPORTING
i_confirm = i_ok.
CALL METHOD go_account->get_bp_cms_sgm
IMPORTING
es_bp_cms_sgm = ls_bp_cms_sgm.
* in case it return an initial value set the old value - if any
IF ls_bp_cms_sgm-limit_valid_date IS INITIAL
AND l_old_valid_date <> ls_bp_cms_sgm-limit_valid_date.
ls_bp_cms_sgm-limit_valid_date = l_old_valid_date.
CALL METHOD go_account->set_bp_cms_sgm
EXPORTING
is_bp_cms_sgm = ls_bp_cms_sgm.
ENDIF.
DATA lt_return TYPE ukm_t_monitor_return.
go_bupa_factory->save_all(
EXPORTING
i_with_chdocs = abap_true
i_upd_task = abap_true
i_with_external_scorings = abap_true
RECEIVING
et_return = lt_return
EXCEPTIONS
failed = 1
OTHERS = 2 ).
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ELSE.
COMMIT WORK.
MESSAGE 'Success' TYPE 'S'.
ENDIF.
ENDFUNCTION.
That in the end will generate something like this:
Where the Workflow user will release the credit limit. So now, you can create a complex custom Workflow (classical or flexible) that can perform at the end, in background mode, the credit limit actions (approve/rejects).
No comments:
Post a Comment