Skip to Content
Author's profile photo Bohdan Petrushchak

Payment terms with fixed date

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  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,     
*&      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.

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

  " 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.
    concatenate bkpf-budat+0(4) lv_zfbdt into lv_zfbdt.

  zfbdt = lv_zfbdt.


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!



Bohdan Petrushchak


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Essentially you can indicate any default option for baseline date.Regardless of the selected option, baseline date will be overwritten in backup

      Author's profile photo Shounak Dutta
      Shounak Dutta

      Hi Bohdan

      Thank you for the excellent explanation, however i have one doubt here. While adding the exit for the field 'Baseline Date', i find a check-box on my screen. Do we need to mark it as 'X' for the substitution to work?

      Thanks and Reg


      Author's profile photo Bohdan Petrushchak
      Bohdan Petrushchak
      Blog Post Author

      Hi Shounak Dutta ,

      Which check-box do you mean ? Could you please send over a screenshot ?



      Author's profile photo Shounak Dutta
      Shounak Dutta

      Hello Bogdan

      I am trying to derive profit center via substitution, please find the below screenshot with the highlighted checkbox i am referring to, do we need to mark that as 'X' for the substitution to take place?


      Below is the sample code written in the exit:

      FORM z101 USING im_prctr.

      DATA lwa_bseg TYPE bseg.

      MOVE-CORRESPONDING bseg TO lwa_bseg.

      SELECT SINGLE prctr FROM vbap INTO @DATA(lv_prctr)
      WHERE vbeln @lwa_bseg-vbeln
      AND posnr '10'.
      IF sy-subrc 0.
      im_prctr lv_prctr.


      Somehow breakpoints kept in this FORM does not get triggered while posting document via FB01.

      Any idea of what possibly is going wrong here?

      Thank you for your reply though!


      Author's profile photo Bohdan Petrushchak
      Bohdan Petrushchak
      Blog Post Author

      Hi Shounak Dutta ,

      You can use this check-box to select the substitution and delete it (if you have several substitutions within one step). Otherwise, no need to activate it.

      I do not see the definition of your pre-requisites and do not know what you use in terms of transactional data, therefore I cannot say why it is not triggered. Essentially, there are two potential reasons:

      1. Transactional data does not match the definition of the pre-requisitions.
      2. Considering that you added a new exit-based logic, you should run the program RGUGBR00 to regenerate the program pool. Did you run this program ? If not, then the program might not trigger the new routine.



      Author's profile photo Shounak Dutta
      Shounak Dutta

      Hi Bohdan

      Thank you so much for your insights! The problem is solved now, The prerequisite values were wrong. Substitution is working fine now.

      Your article was a complete guide for me in delivering this object, Thanks a lot!

      Warm Regards


      Author's profile photo Bohdan Petrushchak
      Bohdan Petrushchak
      Blog Post Author

      Hi Shounak,

      You're welcome !