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:
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:
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:
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!
Regards,
Bohdan Petrushchak
Okumaya devam et...
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:
- authorization issues (e.g. exclude line item if accountant has to authorization for specific authorization group maintained in vendor master data);
- 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!Regards,
Bohdan Petrushchak
Okumaya devam et...