This series of documents for FI-SD integration is divided into 4 parts. This document is the second part of the series. Adding links for other parts before I start with the content.

Even though the document title says FI-SD Integration – I, it is the second part because part I was the pre-requisites required for the integration.

Part-I : Pre-requisites for FI-SD Integration

Part-III : FI-SD Integration – II

Part-IV : FI-SD Integration III


Automatic Account Determination

The accounting entries with respect to the billing will generally result in

    • Debit Customer account
    • Debit Freight-out account
    • Credit Revenue account
    • Credit Excise Duty Payable account
    • Credit Sales Tax Payable account

Hence, primarily, one side of the account is a Customer and the other is a revenue account. The customer account gets picked up from the customer master data and the revenue account is configured based on certain inputs so that correct account is hit during FI posting. This automatic account determination is configured not only for revenue, but also, other elements like Freight, surcharges, sales deductions etc.

The account determination can be done to be based on the following criteria:

    • Application
    • Condition Type
    • Chart of Accounts of Company Code
    • Sales Organization
    • Customer Account Assignment Group
    • Material Account Assignment Group
    • Account Key

Note: The above mentioned fields are standard fields included by default. More fields can be added as criteria.

Configuration Steps

The configuration steps required for this activity can be found by following path SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination


As seen in the screen shot above, there are 6 configuration steps.

Check Master Data Relevant For Account Assignment

The first step is setting up the master data relevant for account assignment. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Check Master Data Relevant For Account Assignment

There are two activities to be done in this step – material account assignment groups and customer account assignment groups.


The first activity is material account assignment groups maintenance. From the screen, double click on Materials: Account Assignment Groups. The screen for maintaining material groups will appear.


Use the New Entries button to create new groups. There are different material groups created as in the screen above which ensures that, for example, all the trading goods (Group 01) can be posted to different accounts than that of all the services (Group 20).


As already seen before, these material groups are assigned to materials in the view Sales: Sales Org. Data 2 of the material master. The system automatically proposes the account assignment group for the material in the Sales documents from the material master.


The second activity in this step is customer account assignment groups maintenance. From the screen, double click on Customers: Account Assignment Groups. The screen for maintaining customer groups will appear.

Use the New Entries button to create new groups. There are different customer groups created as in the screen above which ensures that, for example, all the domestic revenues (Group 01) can be posted to different accounts than that of all the foreign revenues (Group 02) or the affiliated companies’ revenue (Group 03).


As already seen before, these customer groups are assigned to customers in the tab Billing Documents of the Sales Area data in the customer master. The system automatically proposes the account assignment group for the customer in the Sales or Billing documents from the customer master.

Define Dependencies of Revenue Account Determination

The next step is defining the dependencies for revenue account determination – defining fields as well as condition tables. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define Dependencies Of Revenue Account Determination


As already mentioned, the purpose of setting up account determination is to be able to differentiate accounts for posting according to certain criteria like customer account assignment group, account key,  material account assignment group etc. Hence, the first activity here in this step is to decide which all criteria will be used for such differentiation. The field catalog contains fields that can be selected when we create or maintain a condition Table. These decided criteria are to be added by double clicking on the Field Catalog: Allowed fields for the tables option.


As seen in the screen shot above, the some of the required criteria are already present. If new ones are to be added, click on new entries and press F4. A list of all the fields in the tables that can be added as criteria is listed as shown below.


As shown above, if we want to add Payment cards: Card type as a criteria, double click on the entry and then press save. As seen below, this criterion has been added to the already existing list of criteria.

Once the fields have been selected, these fields have to be added to condition tables. There can be many tables, each with different combination of criteria that will be used for account determination. The existing tables can be displayed using Account Determination: Display Tables option.

Enter the table number for which we need to see the table details and press enter.


As seen in the screen above, table 9 uses Sales Organization, Distribution Channel and Division as criteria for account determination. The left pane shows the fields selected as criteria for this table and the right pane shows the field catalog i.e. the fields available from which the criteria can be added to the table.


The system already contains standard tables like the one shown above. Most of the times, these standard condition tables are sufficient. However, we can also create custom condition tables for specific requirements. These custom tables can range from 501 to 999. Some of the standard tables are

    • Table 001 – Customer group/ Material group/ Accounting key
    • Table 002 – Customer group/ Accounting key
    • Table 003 – Material group/ Accounting key
    • Table 004 – General
    • Table 005 – Accounting key

To create a new table, double click on Account Determination: Create Tables option. Here, a custom table 501 is being created with the Payment Card type field as criterion.

Enter table number 501 and press enter. If the table is to be copied from another existing condition table we can enter the existing table number in the field below the new table number.


Select the field payment card type and choose the Select field button.

As seen, now this field has been added to the table as criterion as it can be seen in the left pane. The description of the table can be changed using the highlighted button in the screen shot. Add all the required fields and press save. The new condition table has been created.

Note : The Field Catalog table is cross-client. Therefore, any changes done to this table will have effects in all clients on a server.

Define Access Sequences and Account Determination Types


The next step is defining account determination types and access sequences. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define Access Sequences And Account Determination Types


The first activity, Maintain access sequences for account determination is used to setup access sequences. Access sequences store information about which condition tables will be accessed for account determination, the sequence in which these tables will be accessed and the field contents of these condition tables. Double click on the option.


As seen, there are two standard access sequences defined in the system – KOFI and KOFR.  To create new access sequences use the new entries button. To view an already existing one, click on the entry and double click on the Accesses folder as highlighted on the left hand side.

The above screen shows the condition tables and the sequence in which they are accessed in the access sequence KOFI. The No. column gives the order in which the tables are accessed i.e. the one with the lowest number is accessed first. As shown in the above screen shot, system will access table 953 first during determination procedure as that is first in sequence. If system is able to find out necessary information in this table it will not access table 496 but otherwise it will access table 496 next. Usually, the sequencing of the tables is configured such that, the more specific tables are accessed first for the information and then the less specific ones follow. The Tab column contains the condition table number and the Description field contains the table description. To see the fields contained in the condition table, click on the respective row and double click on the Fields folder as highlighted on the left hand side. To add new tables to the access sequence use the new entries button, enter the values in the No. and Tab column and save.

The screen shot above shows the fields in table 496 – Condition Type/Account Key.


The screen shot above shows that the table 501 – Payment Card Type has been added to access sequence KOFI.


As seen, there is a column called Requirement. A requirement, simply put, is a routine or a small program, which one can specify as a precondition to decide that the access sequence is to be activated if that condition fulfilled. Say, for instance, an access is applicable only for export business, then, a requirement, say 8 is used. This requirement number checks if the order is of export business. If yes, then only the access is read. Otherwise it is not. So, it saves a lot of time for the system, improving the response time. The requirements for the various application areas such as pricing, material determination, account determination etc. are maintained using transaction code VOFM. Once the created, they can be assigned as required to access sequence’s / pricing procedures, etc.


Note : The Access Sequences table is cross-client. Therefore, any changes done to access sequences will have effects in all clients on a server.


The second activity in this step is Define account determination types. The account determination type is used for defining the control data for access sequence and the validity date. Double click on this option from the menu.

As seen in the screen shot, in this step, condition types are defined and then access sequences assigned to them. It is to be noted that these condition types are different from the condition types used in pricing procedures as discussed in the pre-requisites section. These condition types are used in account determination procedure. There are two standard condition types in the system – KOFI (for account determination without CO) and KOFK (for account determination with CO).


Note : Custom condition types and access sequences can be defined, but, it is recommended that these start with Z.

To report this post you need to login first.

70 Comments

You must be Logged on to comment or reply to a post.

  1. Bose GN

    Hi Sowmya,

    Your blog gives a very good idea on FI-SD integration. However I feel some continuity is missing on Pricing procedure to billing !!

    Accounting Key specified in condition type linked to Pricing procedure (here I am not understanding clearly, what happens after Pricing procedure? by searching in the web i read in some posts, as Pricing procedure will be assigned to Billing doc type, customer, Sales Org)…

    Can you please give some detail on this in your way of explanation (hope that goes a easy understanding), how pricing procedure is determined by system when billing document is processed

    PS: I thought to post this in the discussions, but i felt its close to your blog post so posting here

    Thanks,

    Bose

    (0) 

Leave a Reply