Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Bohdan
Active Contributor
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
9 Comments
pavan_kumar18
Advisor
Advisor
Good one Bohdan Petrushchak...
Great job! Thanks a lot for your document.
Hi,

 

For those who have implemented this BTE and dont know why its not stopping at your breakpoint. its because this BTE is being called in background. regular breakpoint wont work.
0 Kudos
Hi,

My case is different - i have a int. table with around 40000 lines to pay . Do you know a efficent way to build the payment proposal\pay without using the "poor" free selection way of f110 ?

the 40000 lines doesn't have any common fileds to make a free selection on them...

Thank you,

Koby
Gizem_S
Explorer
0 Kudos

Hi dear Bohdan,


 

I have a question, hoping you see.


We have an error F110 process.


I have shared the screen shots below.


What should we do to continue successfully ?




 

Regards,


Gizem

Bohdan
Active Contributor
0 Kudos
Hi ggokalp,

In this case, you can see the message FZ 396, but essentially it is just an information message that notifies you that BTE is active. But it is not causing any issues. Underlaying issue is caused by error message AAPO 219. Please check the following OSS-note 2850975 "AAPO 219 during clearing of down payments on asset". It provides the explanation as to the cause of the error.

Besides, please check out the OSS-note 1828338 - F110: Error AAPO 219 in down payment clearing. It is applicable to F110.

Regards,

Bohdan
Gizem_S
Explorer
Hi b.petrushchak

 

I got it. You mean that it is an information message but we should check the main error with number AAPO 219.  So, i will work on it.

Many many thanks for detailed answer.

Regards,

Gizem.
air06140104
Explorer
0 Kudos

Dear Bohdan,

 

I met a problem regarding the payment file separate by payment transaction amount.

The bank required the domestic payment by 2 file formats based on transaction amount:

one transaction < 1 billion, then it would be use payment file format A.

one transaction >= 1 billion, then it would be use payment file format B.

Do you have any experience or idea regarding this?

Looking forward for your replying.

Thanks & Best Regards

Li Yan

Bohdan
Active Contributor
0 Kudos
Hi air06140104,

No, I have no experience with that and do not have experience with payments of such order (i.e. over 1 billion).

Do you have many payments of this kind ? Does the requirement apply to the amount of separate line items or does it apply to the amount of payment, which might cover several invoices at the same time (i.e. group payment) ?

I'd expect that the number of payments exceeding 1 billion should be rather rare. So if we speak about the distinction on a line item level, you can set up two different payment methods linked to two different payment formats - one for payments under 1 billion, another for the payments above the limit. Substitution logic can be implemented so that it fills the appropriate payment method based on invoice amount.

However, if the requirement applies to group payments, than you will have to manage the selection of payment methods manually. But you can use the enhancement described here to control the selection of line items.

Regards,

Bohdan
Labels in this area