Hello SAPers!
Quite often in the process of gathering business requirements regarding management of payables due date, you will come across a requirement to have payment terms with fixed date e.g. on 15th of December. SAP provides provides extensive configuration options to customize different payment terms with fixed date (please check out this excellent blog post for more details), but at the same time they are not flexible enough to cover this particular requirement without additional development efforts.
One option to address this requirement is to combine configuration of payment terms with custom logic that will be triggered by business transaction even 1120 (DOCUMENT POSTING: Field substitution header/items). You can check out blog post by vinod.vemuru2 for more details.
The purpose of this blog post however is to describe how to achieve determination of fixed due date via substitutions mechanism. It also provides additional insights on how to deal with some issues associated with substitutions of due date (or "baseline date" from technical point of view).
1.1 Activate “Baseline date” for substitution
“Baseline date” (BSEG-ZFBDT) is not available for substitution in standard SAP setup. That’s why this field should be specifically activated as a prerequisite step. Navigate to maintenance view VWTYGB01 (SM30) and select field ZFBDT of table BSEG. Deactivate checkbox “Exclude” and save the changes.
Please note! “Baseline date” will be visible as a field available for substitution immediately after its activation. However, it might still be the case that the posting of a document will crash before reaching the substitution logic. Typically, it occurs when you customize substitution in a test client, but user exit logic is written in a development client. To avoid this issue, you should regenerate substitution-related program routines in each client before their use. See OSS-note 842318 “Frequently asked questions about validations and substitutions” for additional details.
Launch t-code SE38 and execute program RGUGBR00. Indicate application area “FI” and callup point “0002” (i.e. substitution on line item level). Activate the checkboxes relevant to substitutions as well as first two checkboxes. Execute the program.
Reminder! Do not forget to regenerate source code in each target client after successful transport of a substitution that involves new fields. Please also check OSS-note 2512768 “Schedule the program run for RGUGBR00 after a successful transport request” for helpful tips.
1.2 Create payment terms with a fixed date
Go to transaction code OBB8 or follow menu path listed below to create new payment terms.
SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business Transactions → Incoming Invoices / Credit Memos → Maintain Terms of Payment
Payment terms due on a fixed date might be configured as follows (see the screenshot below). As you can see, there are no specific settings that will enable the system to arrive at 15th of December as a baseline date. Essentially you can indicate any default option for baseline date (except “No default”). Regardless of the selected option, baseline date will be overwritten in substitution.
1.3 Create user exit for substitution
Substitution setup will involve small user exit to handle the determination of baseline date. That’s why, it should be created prior to configuration of substitution step. User exit should be created in the system-specific program for user exits. Please check out my previous blog on substitutions for some tips. Source code for user exit can be found below.
First part of the code covers adding of user exit ZTRM to the exits pool:
Second part contains source code for user exit ZTRM:
Please note, user exit is written in a way to support determination of baseline date for any payment term that might use fixed date logic (via CASE statement). The drawback of this solution however is that you’ll have to update this user exit each time whenever new payment term with fixed date will be added. Potential workaround that lets you avoid it is to save the mapping between payment terms (ZTERM) and baseline date (ZFBDT) outside of user exit. Possible options to store the mapping include: TVARVC variable, custom customizing table created specifically for this purpose or some company-specific customizing table for constants.
1.4 Configure substitution logic
Go to transaction code GGB1 and add a new substitution step on line item level. You can indicate as many attributes in prerequisites section as needed. I would suggest including check for payment terms not being empty as mandatory prerequisite. Choose field “Baseline date” (BSEG-ZFBDT) and indicate user exit as substitution option.
Well that's it. At the end, configuration of payment terms with fixed due date is not so complicated as it seems at first glance. I hope you'll find this post useful!
Regards,
Bohdan Petrushchak
Quite often in the process of gathering business requirements regarding management of payables due date, you will come across a requirement to have payment terms with fixed date e.g. on 15th of December. SAP provides provides extensive configuration options to customize different payment terms with fixed date (please check out this excellent blog post for more details), but at the same time they are not flexible enough to cover this particular requirement without additional development efforts.
One option to address this requirement is to combine configuration of payment terms with custom logic that will be triggered by business transaction even 1120 (DOCUMENT POSTING: Field substitution header/items). You can check out blog post by vinod.vemuru2 for more details.
The purpose of this blog post however is to describe how to achieve determination of fixed due date via substitutions mechanism. It also provides additional insights on how to deal with some issues associated with substitutions of due date (or "baseline date" from technical point of view).
1.1 Activate “Baseline date” for substitution
“Baseline date” (BSEG-ZFBDT) is not available for substitution in standard SAP setup. That’s why this field should be specifically activated as a prerequisite step. Navigate to maintenance view VWTYGB01 (SM30) and select field ZFBDT of table BSEG. Deactivate checkbox “Exclude” and save the changes.
Please note! “Baseline date” will be visible as a field available for substitution immediately after its activation. However, it might still be the case that the posting of a document will crash before reaching the substitution logic. Typically, it occurs when you customize substitution in a test client, but user exit logic is written in a development client. To avoid this issue, you should regenerate substitution-related program routines in each client before their use. See OSS-note 842318 “Frequently asked questions about validations and substitutions” for additional details.
Launch t-code SE38 and execute program RGUGBR00. Indicate application area “FI” and callup point “0002” (i.e. substitution on line item level). Activate the checkboxes relevant to substitutions as well as first two checkboxes. Execute the program.
Reminder! Do not forget to regenerate source code in each target client after successful transport of a substitution that involves new fields. Please also check OSS-note 2512768 “Schedule the program run for RGUGBR00 after a successful transport request” for helpful tips.
1.2 Create payment terms with a fixed date
Go to transaction code OBB8 or follow menu path listed below to create new payment terms.
SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business Transactions → Incoming Invoices / Credit Memos → Maintain Terms of Payment
Payment terms due on a fixed date might be configured as follows (see the screenshot below). As you can see, there are no specific settings that will enable the system to arrive at 15th of December as a baseline date. Essentially you can indicate any default option for baseline date (except “No default”). Regardless of the selected option, baseline date will be overwritten in substitution.
1.3 Create user exit for substitution
Substitution setup will involve small user exit to handle the determination of baseline date. That’s why, it should be created prior to configuration of substitution step. User exit should be created in the system-specific program for user exits. Please check out my previous blog on substitutions for some tips. Source code for user exit can be found below.
First part of the code covers adding of user exit ZTRM to the exits pool:
program zrggbs000.
*---------------------------------------------------------------------*
* EXIT-pool for FI substitutions *
*---------------------------------------------------------------------*
include fgbbgd00.
* Activate tables types, that you want to use
type-pools: GB002.
tables: BKPF,
BSEG,
COBL,
CSKS,
ANLZ,
GLU1.
*&---------------------------------------------------------------------*
*& Form get_exit_titles
*&---------------------------------------------------------------------*
form get_exit_titles tables etab.
data: begin of exits occurs 50,
name(5) type c,
param like c_exit_param_none,
title(60) type c,
end of exits.
exits-name = 'ZTRM'.
exits-param = c_exit_param_field.
exits-title = text-900. " Substitution for payment terms
append exits.
include rggbs_ps_titles.
refresh etab.
loop at exits.
etab = exits.
append etab.
endloop.
endform. " get_exit_titles
Second part contains source code for user exit ZTRM:
form ztrm using zfbdt.
data: lv_zterms type bseg-zterm,
lv_zfbdt type bseg-zfbdt,
lv_year(4) type c.
" Substitute the baseline date based on payment terms kez
lv_zterms = bseg-zterm.
case lv_zterms.
when '1512'.
lv_zfbdt = '1215'.
when 'XXXX'. " any other payment terms might be indicated here
lv_zfbdt = 'MMDD'. " concatenate month & day
when others.
" Exit the subroutine and do nothing
exit.
endcase.
" Generate new baseline date
if bkpf-budat+4(2) >= lv_zfbdt(2) .
lv_year = bkpf-budat+0(4).
lv_year = lv_year + 1.
concatenate lv_year lv_zfbdt into lv_zfbdt.
else.
concatenate bkpf-budat+0(4) lv_zfbdt into lv_zfbdt.
endif.
zfbdt = lv_zfbdt.
endform.Please note, user exit is written in a way to support determination of baseline date for any payment term that might use fixed date logic (via CASE statement). The drawback of this solution however is that you’ll have to update this user exit each time whenever new payment term with fixed date will be added. Potential workaround that lets you avoid it is to save the mapping between payment terms (ZTERM) and baseline date (ZFBDT) outside of user exit. Possible options to store the mapping include: TVARVC variable, custom customizing table created specifically for this purpose or some company-specific customizing table for constants.
1.4 Configure substitution logic
Go to transaction code GGB1 and add a new substitution step on line item level. You can indicate as many attributes in prerequisites section as needed. I would suggest including check for payment terms not being empty as mandatory prerequisite. Choose field “Baseline date” (BSEG-ZFBDT) and indicate user exit as substitution option.
Well that's it. At the end, configuration of payment terms with fixed due date is not so complicated as it seems at first glance. I hope you'll find this post useful!
Regards,
Bohdan Petrushchak
- SAP Managed Tags:
7 Comments
