Introduction
Following the SAP Best Practice approach regarding the setup of GL accounts in SAP ERP and SAP S/4HANA any account allows a detailed reporting on line item level.
We can select any available field to sort or group accounts. So far all seems to be set and no further discussion is needed on the question how to group line items. And indeed, as long as there is a common field, selected items can be sorted and everything is fine.
However, things are getting more complex when combining company codes in reporting and processes are not 100% alike on company code level. E. g. in company code A the grouping criteria for a certain business process may be the customer number whereas in company code B it is the SD order number.
Background
In reporting this can be handled by executing specific reports multiple times using different layouts. In automatic clearing things are different since when defining clearing rules the field company code isn't available:
Customizing: Additional Rules for Automatic Clearing
At first sight this seems to be no-brainer: we just use BUKRS as Criterion 1 and the job is done… Taking a closer look at the underlying table TF123 shows that this idea is never going to fly, since none of the five criteria are part of the table key:
Definition of table TF123
So what we need is a different approach. And taking again a closer look at table TF123 we should consider rephrasing the question. So instead of asking:
- How can we group G/L accounts differently on company code level?
we have to have a more technical view on the matter and rephrase it to
- Which common field allows us to have company code specific information automatically recorded on line item level?
To answer this question we must have closer look on the account maintenance, especially to the tab "Control Data":
G/L Account Maintenance: Control Data
The relevant entry is the highlighted Sort key. Looking back to the early days of SAP like R/2 this information was really relevant for sorting since sorting was limited to certain fields of which one was the field Assignment. But this is history. Looking at SAP S/4HANA sorting is no longer limited to any field, but the functionality to take over certain field values exists.
Let's have a look on what the idea behind the sort key is. In former times the fields to sort results were specific to primary key fields. Looking at database table BSEG only the fields BUKS, BELNR, GJAHR and BUZEI are available and the field ZUONR is just another field to report the result.
However, looking at the tables BSIS, BSAS, BSID, BSAD, and so on, things are different since the field ZUONR is part of the primary key. Taking the functionality of the Sort key was a big step in having more flexibility in reporting.
To make a long story short, the "Sort key" is tightly connected to the field ZUONR. The functionality in a nutshell is, it copies a value from one filed or a combination of fields into another one.
Example:
In each line item where the account from the screenshot above is used in company code 0001 the value of the "Settlement period" is copied over into the field ZUONR.
Whereas the sorting as already said is no longer an issue the functionality to take over values is still in place.
Solution
Since the "Sort key" is assigned on company code level and this key influences what information is recorded in the field Assignment (ZUONR) we have everything together to answer the initial question,
- How can we group G/L accounts differently on company code level?
The answer is:
- Rather than directly use the relevant field for grouping, use the Assignment field and transfer the information relevant for grouping into this very field by using the "Sort key" in the according master data record.
In standard we already have some pre-defined "Sort keys" that are ready to be used:
Sort key
If you can't find what you are looking for you may define your own key. The only restriction is that it must be a field in one of the database tables BKPF, BSEG, BSEC, or BSED.
Definition: T-Code SH02 / View V_TZUN - Determine Standard Sorting for Line Items
Another restriction is that the length is restricted to 18 characters. But other than that we are free to transfer any field value or a combination of up to four we want just out-of-the-box without having to develop anything. Regarding the usable fields you may refer to 39065 - Sort key in master record.
Now, assume you want to clear items in one company code on document number and in another one on reference document number level. In this case you would assign this very general ledger account for the first company code to sort key 002 and for the last one to 009:
Sort Key 002 - Document Number / Fisc Year
Sort Key 009 - Reference Document Number
Let's have again a look on how the default customizing regarding Chart of Accounts INT looks like:
Customizing: Additional Rule for Automatic Clearing
In order for an automatic clearing of such an account to work, it must have an entry in this table. E. g. for Chart of Accounts INT this setup would work for the general ledger accounts 113101, 113102 and 131511. For all other G/L Accounts the according information is transferred into the Assignment field, however, automatic clearing would not take it into account.
Conclusion
If you want certain accounts to get considered differently by automatic clearing, the sort key in combination with the assignment do provide a sophisticated solution. The only limitation is that the basic setup is part of customizing and based on the Chart of Accounts.
This means for the business to take the full capacity of automatic clearing an accounting manual is required that considers the dependency between
- Chart Of Account
- Account Number
- Sort Key.
Feel free to comment on this blog. I'm curious on your experiences regarding using the sort key in line reporting and in clearing open items.
- SAP Managed Tags:
