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!
Showing results for 
Search instead for 
Did you mean: 
Custom developments happen. A lot. They can be complex involving multiple parametrization like company-code-specific parameters which you can easily maintain in OBY6 with your own parameters.

Sometimes you need to build an output file that must be flexible based on different parameters - you could use DMEE for that.

Developments, especially in Finance area, tend to automate posting finance journals. In such way the previously mentioned option do not provide possibility to make your own custom account determination.

While designing such reports functional consultants are very often limiting (or limited by company policy) their options to:

  • Hardcode values (very bad idea)

  • Make GL accounts available on selection screen (error prone)

  • Add entries in global parameters table (company specific table with generic fields)

  • Create custom table to store account determination

Any of these solutions have its pros and cons but the last 2 are the most preferred options by many companies/ consultants. Experience shows me that having a global parameter table is great but it is hard to keep documentation about it and it is hard to understand, without reading the code or documentation, what entry does what.

Custom tables are most effective but when you create too much of them then it is hard to keep the record of all of them– because many companies do not extend their IMG Paths to store custom table and only access them via ...

The magic of T030

Starting learning SAP Finance will establish your close relationship with FBKP transaction keeping record of (almost) all automated postings in standard SAP finance area. It is based on various T030 tables where the T030 itself holds most of the entries.

T030 is a generic table based on 4 characteristics:

  • Chart of Accounts

  • Transaction key

  • Grouping Code

  • Account modification

  • Valuation class

The parameters are generic so they keep both MM as various FI characteristics (like cash discount taken/ granted accounts ) inside. You can see the definitions of the fields under ‘Rules’ section of each posting schema.

The fields Grouping Code/ Account Modification are generic and can be use with any kind of value.

Exploring this table will quickly reveal that some of important accounting posting rules are not maintained there. Mainly those ones which are related to period-end-closing and are using the ‘adjustment-account + target account’ procedure – like F.19 or foreign currency valuation does.

That investigation bring to light more tables which are prefixed with T030:

Table Usage
T030U Account Determination for Balance Sheet Transfer (Adjustment) Postings
T030H Account Determination for Exchange Rate Differences
T030S Account for Foreign Currency GL Accounts Exchange Rate Differences (based on Exchange Rate Difference Key)
T030K VAT Tax Accounts Determination
T030G Account Determination for Business Area Breakdown

Additionally to that table T001U holds the cross-company clearing accounts.

But why?

The automated postings and account findings are core functionality of SAP Finance. When you introduce your own posting schemas then you add new automatic account finding on top of the existing standard one.

Keeping them in different custom tables or generic tables with no explanation on which elements they are dependent makes them hard to track.

Doing any analysis by consultants / business on accounts that are involved in automated processes would require extremely much work to identify. In case you use global operative chart of accounts changes to any accounts could end up in unplanned impact.

SAP delivers an overview of automated postings used in T030* tables via transaction S_ALR_87101048 (program RFAUDI30 ) – why not include your accounts in the overview? That would reduce the questions which accounts are used where and would definitely give a overview of all accounts used by accounting automated postings in one place.


Adding your own group of custom postings

FBKP welcomes you with summarized view of all postings:

The highlighted area is the one which is going to be extended. When you click on the entry system shows logical groups of operations:

At first we need to define our own group. It should be a logical group of operations – it is identified by a key and name. That could be for example ‘My company :Additional period end-posting’.

Access table view T030X via SM30:

Here you define a key of the group:

Remember that here could also be standard groups existing with Z/Y-name that were created by SAP (like ZAH) so I just created custom one starting with Z and digit inside – Z0A. Your entry will be saved in workbench transport.

As next a name needs to be assigned to the group using table view T030Y:

Here you assign, language-dependent, description of the group:

Create transaction keys

Having setup the group we need to decide which transactions by means of transaction keys should be handled inside of the newly created group. That is specified in table view T030A:

Here you assign which transaction keys which represent actual posting scenario – like cash discount taken/ given etc. In our example it will be reposting between GL accounts based on segments and profit centers:

Besides giving the transaction key ID you can enter the documentation reference (in Field Name) field and the search help function (in field +). Up to 3 fields can be used – fist two ones represent Grouping Code / Account Modification and the last one the valuation class.

Two transaction keys have been created and both assigned to grouping Z0A:

  • Z01

  • Z02

Fist one is based on Segment and Profit Center characteristic and second is based on account that should be adjusted using the adjustment account + target account schema. It does not have to be an organizational level – it could be anything – like posting rule, custom field etc. – literally anything.

Search help for the field is entered in field ‘+’ by means of search help function or reference table. Search help function module needs to be prefixed by single underscore _ sign. Table and field reference must be entered following patter *TABLENAME*FIELDNAME:

F1 Help Function is provided based on fields of structure RFCU5:

Specify the field name of the table and it will call up its help function. If any of the functions are missing you can append it and system will call the field documentation of the data element.

Having defined the keys the descriptions should be entered in same way as it was done for group of transactions. Enter view T030W in SM30:

Here you can define the the name of the transaction key and each of it column headings:

For columns headings the approach is similar to the definition of key – each of the column headings represent a column of Grouping Code (KOMOK) / Valuation class / Account Modification (BWMOD).

Assign T030* table to transaction keys

At the end, when we have groups and transaction keys specified it is time to specify which table should be updated for each transaction key. The tables referenced in section The magic of T030 can be used in customizing.

That is the only place where no customizing view exists and the determination is done based on ABAP code. The include DFKB1INT determines which of the fields and tables should be updated:

The include has an implicit enhancement point at the end of the code:

Where I suggest to enter your own include so that the enhancement will not always be edited with each new entry but only the include should be modified.

The entry needs to be done in following way:

Declare data that is exactly 9 characters long with exactly same name as transaction key – so Z01/ Z02.

Each character has a meaning for T030 and other tables:

Character in string Meaning
1 Account finding is possible (X – Yes / Space – no)
2 Special GL Indicator update (X – Yes / Space – no)
3 KOMK (Account grouping code) is active (X – Yes / Space – no)
4 BWMOD (Account Modification ) is active (X – Yes / Space – no)
5 BKLAR (Valuation Class) is active

Table to be updated:

1 = T030

2 = T030U

3 = T001U

4 = T030H

5 = T030S

6 = T030K

7 = T030G
7 Debit/ Credit account definition (if not marked then only 1 account is possible to select).  (S – Yes / Space – no)
8 Maximum length of KOMK field – SAP restriction is 4 characters
9 Maximum length of BWMOD field – SAP restriction is 3 characters

Once you specify the entries then your entries should look like that:

That completes the settings.

Have a look at FBKP now

After all steps have been customized we can have a look at our FBKP:

The new group is visible and once it is selected it shows both keys:

Select first entry to specify the determination rules:

The names correspond to entries in T030W table. Under posting keys the posting keys for automated postings can be read:

In Accounts parts the account finding can be updated:

For each of the Profit Center/ Segment fields the search help works as defined in customizing.

The values are saved correctly in T030 table:

In second transaction the table T030U should be update with adjustment and target account:

For that table there is no Grouping Code / Valuation class / Account Modification available but values are update correctly in the table:

Use in custom coding


After we defined the entries they can be picked up in custom coding by selecting directly from selected table.
SELECT SINGLE * FROM t030 WHERE ktopl = chart_of_accounts                            
AND ktosl = transaction_key
AND bwmod = grouping_code
AND bklas = valuation_class
AND komok = account_modification
into @data(my_account_determination).

The transaction key can also be updated in GL lines in posting by BAPI_ACC_DOCUMENT_POST by using the field ACCOUNTGL- ACCT_KEY. The value is then visible in BSEG-KTOSL field and helps identifying the source transaction for posting.

Account assignment overview

The accounts defined in T030* tables can be checked in account detective transaction S_ALR_87101048 which shows usage of all accounts in all automated account finding tables:

The result shows that this acocunt is used in transaction key Z01:

And Z02:


How do you keep record of custom account findings in your companies? Is using standard tables something you would consider for better visibility?


Thank you for reading,

Marek Turczyński