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 SM30.
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 Modificationaregeneric 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:
|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.
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.
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 groupsexisting with Z/Y-name that were created by SAP (like ZAH) so I just created custom onestarting 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:
Having setup the group we need to decidewhich transactions by means of transaction keysshouldbe handled inside of the newly created group. That is specified in table view T030A:
Here you assign which transaction keys which representactual postingscenario – 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:
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 nameof the transactionkey 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).
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.
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:
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.
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:
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,