Custom logic for selection of open items for payment program

[Bohdan]

Hello SAPers!

Here is another post on enhancements techniques for automatic payment program. I hope you'll find something interesting for yourself.

Typical question that often arises during implementation of automatic payment program is how to apply custom logic for selection of open items i.e. how to exclude specific positions from payment proposal if they meet certain requirements. The scenarios might be different and might deal with:

1. authorization issues (e.g. exclude line item if accountant has to authorization for specific authorization group maintained in vendor master data);


2. legal / compliance procedures (e.g. exclude line item if vendor didn’t provide signed invoice with all supporting documentation) etc.

SAP provides business transaction event (i.e. BTE) 00001820, which can be used to implement customer-specific checks during selection of open items for payment program. Some details on how to implement this logic can be found below.

Launch t-code FIBF, proceed to menu “Settings → Products → … of a customer” and create new product e.g. ZAPP. Activate the product by selecting respective checkbox.



Once the product is defined proceed to menu “Settings → Process Modules → … of a customer”. Assign custom function module e.g. ZFI_F110_CHECK_ITEM_SELECTION to BTE 00001820.



Custom FM for BTE 00001820 should be created via copying of standard FM SAMPLE_PROCESS_00001820. FM is processing one open item at a time. FM interface offers the following parameters:

• Line item data (I_BSIK / I_BSID – attributes of AP / AR open item);


• Account type (I_KOART);


• Date attributes (I_BUDAT, I_NEDAT, I_FDEBI);


• Controlling parameters for free selections (E_NO_FREE_SELECTIONS / T_FLDTAB_1820);


• Payment attributes (C_ZLSPR / C_ZLSCH) for determination of payment block / payment method respectively.

Let’s consider specific requirement: exclude open items if user is not authorized for specific authorization group that is maintained in vendor master data. From technical perspective that means that you should check authorization group in vendor master record and check if the user is authorized for field BRGRU of authorization object F_LFA1_BEK.



You can use the following logic to implement this requirement:

function zfi_f110_check_item_selection.

*"----------------------------------------------------------------------

*"*"Local Interface:

*"  IMPORTING

*"     REFERENCE(I_BSID) TYPE  BSID OPTIONAL

*"     REFERENCE(I_BSIK) TYPE  BSIK OPTIONAL

*"     REFERENCE(I_KOART) LIKE  BSEG-KOART

*"     REFERENCE(I_BUDAT) LIKE  F110C-BUDAT OPTIONAL

*"     REFERENCE(I_NEDAT) LIKE  F110V-NEDAT OPTIONAL

*"     REFERENCE(I_FDEBI) LIKE  F110V-FDEBI OPTIONAL

*"     REFERENCE(I_TRACE) LIKE  TRCOPT STRUCTURE  TRCOPT OPTIONAL

*"  EXPORTING

*"     REFERENCE(E_NO_FREE_SELECTIONS) TYPE  C

*"  TABLES

*"     T_FLDTAB_1820 STRUCTURE  F110_FLDTAB_1820 OPTIONAL

*"  CHANGING

*"     REFERENCE(C_ZLSPR) LIKE  BSEG-ZLSPR

*"     REFERENCE(C_ZLSCH) LIKE  BSEG-ZLSCH

*"----------------------------------------------------------------------



  constants:

    lc_block      type dzlspr value '*', " Skip document for payment

    lc_vendor     type koart  value 'K',

    lc_auth_group type begru  value 'ZGRP'.



  data:

    lv_auth_group_int type lfb1-begru,

    lv_auth_group_ext type ust12-von.



  check i_koart = lc_vendor.



  select single begru

    from lfb1

    into lv_auth_group_int

    where bukrs = i_bsik-bukrs

    and   lifnr = i_bsik-lifnr.



  " Perform authorization check if authorization group is not initial

  if sy-subrc is initial and lv_auth_group_int is not initial.



    lv_auth_group_ext = lv_auth_group_int.



    call function 'AUTHORITY_CHECK'

      exporting

        user                = sy-uname

        object              = 'F_LFA1_BEK'

        field1              = 'BRGRU'

        value1              = lv_auth_group_ext

      exceptions

        user_dont_exist     = 1

        user_is_authorized  = 2

        user_not_authorized = 3

        user_is_locked      = 4

        others              = 5.



    " Mark line item as blocked for payment

    if sy-subrc = 3.

      c_zlspr = lc_block.

    endif.

  endif.



endfunction.

When you assign payment block in FM you have three choices:

• to use standard block “*” – you’ll see the exception in proposal log, but it will not be visible in exceptions list. Consequently, the user wouldn’t be able to change block manually via editing of proposal;


• to use payment block without option “Change in payment proposal” (e.g. A or B) – you will see the exception in proposal log and the item in exceptions list. However, the user wouldn’t be able to remove payment block.


• to use payment block which can be changed in payment proposal. If you use this payment block, you will also see exception in payment proposal and the user would be able to remove this block via editing option.

Overview of typical payment blocks as defined in t-code OB27 can be found below:



Typical entry in payment proposal log looks as follows:



The last useful feature that should be mentioned here deals with controlling parameters for free selections. If you set parameter E_NO_FREE_SELECTIONS value to “X”, the program will disregard any filters that were applied on “Free selection” tab. This might be useful if you want to make sure that users do not exclude at their own discretion open items from payment proposal.

Alternatively, you can apply additional filters in source code by appending internal table with additional values. Below you can take a look at the values in this table at a runtime:



I hope that this post was interesting and you found something of value:) Your suggestions and comments are welcome!

 

P.S. You can also check out my follow-up post on debugging of this BTE event for APP.

 

Regards,

Bohdan Petrushchak