Nothing lasts forever – then again perhaps recurring entries in SAP actually do?

Nothing lasts forever, you might think. But today we are going to be talking about recurring entries. In many places, SAP offers the option of automating repetitive activities and thus minimizing the expense of, for example, the monthly posting of rent.

This all sounds very good and helpful at first glance, but where there is light, there is also shadow. What if there are no longer any original documents for these templates and the postings based on these templates are nevertheless still carried out? Or what if the balance sheet accounts in your SAP system change, but the templates continue to be executed as before? In the first case we have postings without a document, and the latter case may lead to incorrect statements in the balance sheet and income statement.

A regular check of recurring entries is therefore advisable and we recommend performing such a check within the framework of Journal Entry Testing.

How can recurring entries be tracked down in SAP?

As you know, all roads lead to Rome. This also applies in the case of an analysis of recurring entries. First we will look at how to perform an evaluation using SQL before going on to show you the manual procedure using the transactions “SE16N” and “SQVI” at the end of the article. You can jump directly to the instructions for the procedure without SQL by clicking here.

A simple “SELECT” on the “BKPF” table (document header for accounting) with a view to the data field “BSTAT” gives an overview of the recurring entry templates currently stored in the system:

SELECT BKPF.BUKRS, BKPF.BELNR, BKPF.GJAHR, BKPF.BUDAT FROM BKPF WHERE BKPF.BSTAT = 'D' ORDER BY BKPF.GJAHR, BKPF.BUKRS ASC

BUKRSBELNRGJAHRBUDAT
10009100000000199519950127
10009100000004199619960702
30009100000000200320030411
10009100000000200420040319
30009100000001201220121103
22229100000000201420140407

In this case, “BUDAT” shows the date on which this template was created. These are not yet posted as business transactions because they are only templates / blueprints.

More details of these individual templates can be found in the “BKDF” table (document header supplement for recurring entry):

SELECT BKDF.BUKRS, BKDF.BELNR, BKDF.GJAHR, BKDF.DBMON, BKDF.DBTAG, BKDF.DBBDT, BKDF.DBEDT, BKDF.DBZHL FROM BKDF ORDER BY BKDF.GJAHR, BKDF.BUKRS ASC

BUKRSBELNRGJAHRDBMONDBTAGDBBDTDBEDTDBZHL
100091000000001995012819950101199631121
100091000000041996031519960215202011150
300091000000002003010320030101200512310
100091000000002004011520040312200412282
300091000000012012013020121130201512311
222291000000002014010120140101201812312

The data field “DBMON” shows the planned execution in months. 01 stands for monthly execution, for example. 00? “DBBDT” shows when this recurring entry is to be used for the first time, “DBEDT” shows when it is to be used for the last time. Here it is noticeable that some entries in “DBZAHL” – the field that shows how often posting data was created from these templates – have never been used (0) or only been used very rarely (once, twice). This raises the question of why templates have been created and not been used at all. Furthermore, the second line in the results is also worth mentioning: a document has never been created here before, but the template can still be used until 15/11/2020. This raises the question of whether an original document still exists in the case of a posting based on this template.

The link from tables “BKDF” and “BKPF” with a “left join” lists the posting documents created from each template and shows when a business transaction was created from the template.

SELECT BKDF.BUKRS, BKDF.BELNR DBBLG, BKDF.GJAHR, BKPF.BELNR, BKPF.BUDAT, BKPF.BKTXT FROM BKDF LEFT JOIN BKPF ON (BKDF.MANDT = BKPF.MANDT AND BKDF.BUKRS = BKPF.BUKRS AND BKDF.GJAHR = BKPF.GJAHR AND BKDF.BELNR = BKPF.DBBLG) ORDER BY BKDF.GJAHR, BKDF.BUKRS, BKPF.BUDAT ASC

The end result shows that the document header texts (column BKTXT) also have clear potential for optimization with regard to completeness and traceability.

Evaluation of recurring entries with SE16N and SQVI in SAP

After taking a look at the pretty straightforward procedure for performing the evaluation using SQL, we are now going to show an alternative method using the transaction “SE16N”. The “BSTAT” field (document status) is restricted to recurring entries (D = recurring entries). The counterpart to the first SQL query then looks like this with the mask for “SE16N”:

Recurring-entries-SE16N-fields

Accordingly, the result (F8) shows the complete list of available templates for recurring entries:

Recurring-entries-overview

The table “BKDF” is required to check whether the templates were also used. Therefore we select the following fields in the data entry mask for “SE16N”:

BKDF-SE16N-mask-for-recurring-entries

The result (F8) shows all templates for recurring entries and the number of uses (field DBZHL – number):

BKDF-amount-of-recurring-entries-in-SAP

So far so good. But if you now try to execute the table join of the “BKPF” table to the “BKDF” table in SAP with the “SQVI” (Quickviewer) transaction, you will soon notice that the “Left outer join” function only works in one direction. For inexplicable reasons, however, SAP “joined” the “BKPF” table to the “BKDF” table in the standard system and not the “BKDF” to “BKPF” as intended. For this reason, it is not possible to perform an analysis in this way. Do you know of any alternative? – If so, then please let us know in the comments.

In summary, a regular review of recurring entries is something that should be firmly anchored in the internal control system. Paying attention to the following points can help avoid mistakes:

  • Limit the duration of recurring entry documents to their duration
  • Use comprehensible document header texts in the template and the generated documents.
  • Check regularly which templates exist and how they are used.

Artikel teilen

Facebook
Twitter
XING
LinkedIn