The key to the most important FI-CA configuration piece

[Francois_Dekker]

The key to the most important FI-CA configuration piece

When a new instance of FI-CA is configured, it is almost universally done by the consultancy company that is engaged in the project, and it is almost certain that anything that was done at the previous clients’ implementation, is duplicated from the previous implementation. The current client, not being familiar with the new system, is unaware that the configuration would most probably not be the most efficient for their end-users and reporting systems.

The keystone configuration for FI-CA is setting up die posting combinations that will determine the general ledger accounts the system will post to when that combination is used. In SAP lingo it is setting up the MAINs and the SUBs, and is configurable from:

FICAIMG -> Basic Functions -> Postings and Documents -> Document -> Maintain Document Assignments

In combination with the Company Code and Account Determination Identification, the Main will determine the underlying Reconciliation Account of the Contract Account that is posted to, while the SUB will determine the general ledger account (either Balance Sheet or Income Statement account).

Having a predetermined naming convention and nomenclature can save the company hours of work and thousands of dollars if designed and implemented correctly.

The following guidelines can be used to assist in achieving this:

(1) Never create MAINS or SUBs with leading zeros

This sounds as if 999 combinations are specifically omitted from creation and reducing the number of combinations available to the business. However, since both parameters are alpha-numeric, it would be almost impossible to exhaust the number of combinations.

Main/Sub combinations are used in several reports that are either exported or imported from and to Excel, text or csv files. Whenever these files are opened in Excel, the leading zeros are dropped and when consumed for a data upload will fail SAP’s validation test.

There is also a variance in the number of characters and spaces in the master data table for the MAINs and SUBs (TFKHVO/TFKTVO) and exporting the account assignment data in list format from EK01/EK02. This makes a reconciliation between the two datasets a cumbersome exercise, whereby, if there were no leading zeros present, a simple export of both in combination with an Xlookup in Excel would yield results in minutes.

(2) Develop and use a nomenclature that is geared towards end-users and reporting

The consultancy company assisting with a new implementation will almost universally bring a set of configurations from their previous client with them. Even if this set works well for the previous client, it can be generally agreed that it will not be the best set-up for the new client. Programmers will copy previously used code and implement the code, as is; never taking end-users into account. As examples, a specific debit entry (0300/0230), can be created with an off-set of (0300/0330) and another credit (1500/0840) with an off-set of (1500/0850). In the first case, the debit and credit entries appear to be connected, with the difference of 0100 between them, and in the second case the credit and debit seems connected with a difference of 0010 separating them. In both cases, the debit and the credit end with zeros. This set-up impacts end users negatively in two ways: first when making a posting, and two when pulling data from tables and/or cloud reports.

When making a posting (e.g. with FPE1), SAP will display a list of possible entries for both the MAIN and the SUB when the field is active. Unless the end-user knows the specific posting combo that will be used, they need to scroll through the list and often increase the number of hits that are displayed to find the correct posting. Unless the sign is part of the description, the end-user will not know if it is a debit or a credit entry, unless they display (simulate) the entry.

Noncontiguous or poorly grouped posting combos also make reporting more difficult. An example of a naming convention/nomenclature that can work is to always have SUB credit entries end with 1, 3, 5 and 7 and the corresponding debit entries end with 2, 4, 6 and 8; 9 and 0 can then be reserved for statistical posting combinations.

Cr	Dr	Description	Note
2431	2432	Residential Sec Dep Payment	No requirement to add Dr or Cr in the description as the nomenclature indicates the sign
2433	2434	Commercial Sec Dep Payment
2435	2436	Industrial Sec Dep Payment
2437	2438	Municipal Sec Dep Payment
2439	2430	Sec Dep Request	Statistical Posting
3301	3302	Winter 2024 Rebate	No Statistical Posting Combo required
3303	3304	Spring 2024 Rebate
3305	3306	Summer 2024 Rebate
3307	3308	Fall 2024 Rebate
3311	3312	Winter 2025 Rebate
3313	3314	Spring 2025 Rebate
3315	3316	Summer 2025 Rebate
3317	3318	Fall 2025 Rebate

From the examples above, it can be observed that it would be extremely easy to pull data from cloud reports, S4 tables and/or exported Excel spreadsheets, and convert the data into meaningful reports.

(3) Where at all possible, create off-setting entries

When a new instance of SAP is installed, the business will attempt to duplicate settings from the legacy system in the new SAP environment, without knowing that SAP would require different functionalities or offer better capabilities. Certain postings might be considered sign specific, in effect they will always post either as a debit or a credit; an example could be a ‘Promotion Credit”, which should always post as a credit. Since any posting can be reversed with FP08, the initial conclusion would be that no debit posting combination needs to be created for this transaction. However, there are several advantages to creating off-setting entries.

The configuration path where the posting combo’s sign is assigned is:

FICAIMG -> Basic Functions -> Postings and Documents -> Document -> Maintain Document Assignments -> Maintain Transactions for IS-U -> Maintain Transactions for Charges

Define Sub-Transaction -> Configure General Settings -> Maintain Attributes per Company Code and Division

These types of credits are often posted in mass which often requires that some of the transactions also need to be reversed in mass. Since not all transactions need to be reversed, a mass reversal might not be the best.  An offsetting posting combo will allow for selective mass reversals. This will also be the case when individual accounts’ credits should be reduced, either by different percentages or different amounts.

If these reversals and/or adjustments are made in a different period, business often would prefer to run a report containing these reversals and/or adjustments depending on the posting period. This can be accomplished by directly querying the DFKKOP table with the specific posting combo as the input parameters. If the reversals were done with a mass reversal of the original posting combo, it would require pulling the data by clearing document details, which are not always available to the business, and a more complex process.  

Even in cases where the business specifies that a specific transaction will only be posted with one sign, reiterate the scenario where adjustments might be needed. It is also often needed to offset migrated items, and in these cases, migrated reconciliation accounts cannot be posted to, and reversals of such migrated items can lead to ledger imbalances.

Note, through configuration, reversals can be routed automatically to different MAIN/SUB posting combinations other than the original posting combination, or to a generic MAIN/SUB combo that records all reversals. This will still require that all the combinations be created and available for posting.

(4) Avoid Alpha Numeric entries that can lead to confusion.

Do NOT create combinations that include O (alpha) and 0 (numeric), l (alpha) and 1 (numeric) or something similar. This is especially true when only two characters are used; examples are O0 / 0O as a Tax Determination code or 1l / l1 as an interest key code. Especially avoid these combinations if the data field will be used in interface files with 3rd parties.

(5) Create a custom table to hold descriptions for Bill Printing

It is often necessary to have line items on Customer’s bills that make more sense to the customer than the generic description that is necessary for the end user or internal reporting purposes. As an example, we could have different MAIN/SUB posting combinations for several rounds or levels of levies/discounts charged/provided during the year. Below are examples:

MAIN	SUB	Internal Description	Bill Print Description
8000	4411	Bronze level credit	Seasonal Discount credit
8000	4413	Silver level 1 credit	Seasonal Discount credit
8000	4415	Silver level 2 credit	Seasonal Discount credit
8000	4417	Gold level 1 credit	Seasonal Discount credit
8000	4421	Gold level 2 credit	Seasonal Discount credit

In this case, the organization can avoid customer inquiries as to the meaning of the different credit levels and why they fall within a specific level. The descriptions on the custom table can also easily be changed if certain posting combinations need to be recycled, without making any changes to internal SAP config tables.