Hello Word!

Getting back to the S/4 Workflow series:

Sometimes SAP standard does not meet all requirements and that’s where the “Custom Code” comes in…

Today let’s talk about the FSCM Credit Management Workflow (Credit Limit), that you can find more details here.

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.

Again, read more details here.

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).

Hope it helps! Enjoy it…

Best regards.