SD – FI Account determination

The Integration between FI-SD will be happened through Account determination.

It is at the time of billing when the Actual integration will reflect from SD to FI.
Once the billing is done the Invoice is automatically created in FI.(Doc.type is RV)
The billing will flow from SD-FI as RV document(Sales Invoice= DR document).

The Price will be picked through a condition technique which is defined in the pricing procedure by
the SD consultants.
Access sequence will help to pick the most appropriate price depending upon the parameters.
Parameters here could be Material,Sales organisation,Customer etc...
Prices will be defined from Most specific to most general for various combination of parameters in
the access sequence.

Data will hit appropriate GL Accounts which you mention in T.code:VKOA

Sales Process: The sales order forms the basis of the sales process. Once a customer has placed
an order, a sales order must be created at the start of the process. The sales order is generated at
the distribution chain level. The ordered items can be from different divisions. The sales order is a
document in SD and does not cause any postings in Financial Accounting. When the sales order has
been entered, the system carries out an availability check for the required delivery date.
On the day of shipping, an outbound delivery document is created. Billing for the delivery can only
take place when the goods have been taken from the warehouse stock and posted as a goods
issue.
The warehouse management function is used for picking . A transfer order has to be created, which
generates the pick order. The requested goods are taken from the warehouse and prepared for
delivery.
The goods to be delivered are posted as a goods issue . A goods issue document is created in MM,
and an accounting document is created in FI so that the goods issue is posted to the correct G/L
accounts.
The last stage in the sales process is billing. A billing document is created in SD, and a printed
invoice is sent to the customer. At the same time, a document is created in FI so that the receivables
and revenues can be posted to the correct accounts.

This is known in the IMG as "revenue account determination", but it covers a lot more than that
(discounts, taxes etc). This is what determines how the financial impact of your SD Billing document
is posted into the FI General Ledger.
The integration is controlled both in SD and in FI.
In SD there is a awesome area of configuration called the pricing procedures. The pricing
procedure determines the final price quoted to the customer for a particular product. This could be a
complicated calculation taking into account the base price, any special prices or discounts that may
apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition
types'. This condition technique is used in a number of areas of SAP.
For now all we need to know is that each condition type is assigned to an account key (or in the case
of rebates two account keys). You can assign multiple condition types to the same account key.
There are a number of account keys that are pre-defined in the system. For example:
ERF freight revenues
ERL revenues
ERS sales deductions
EVV cash settlement
MWS sales tax
Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as
simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple
approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one
does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail
that you need in GL should be determined by your financial statement reporting requirements - you
may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities : procedures,
access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once
you have worked through it once in one area and encounter it in another then hopefully you will be
comfortable in knowing that most of the standard configuration can be left as is. )
We have to decide which access sequences we want to use (Five access sequences are defined in
the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the
access sequence "chart of accounts/sales org./account keys".
The chart of accounts part is standard in all account determinations, so let us look at the rest. This
access sequence allows us to specify different GL accounts for different Sales Organizations.
So if we had a billing document line item where the customer had some special deductions for one
of the products he purchased, we could map accounts by Sales Organization. To make it even
simpler a document is within one Sales Organization so we have an overall mapping as follows:
SD Line Item Condition type SD Amount Account Key Sales Organization GL Account
1 Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions
for 1000
Sales deduction for special promotion on particular product $15 ERS
Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
Total for item 1 $175
2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
Total for item 2 $ 100
Document Total $ 275
So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoice line item) Amount
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275
The GL document posting that the system will make to FI will look something like this though:
FI Line Item Debit / Credit Account Amount
1 Debit (PK=01) Customer (AR Account) $ 275
2 Credit (PK=50) Revenue (GL Account) -$ 300
3 Debit (PK=40) Sales Deduction (GL Account) $25
Balancing to 0 as all GL documents must.... $0

understand that the system uses condition tech. in revenue acc determination .i.e Chart of
accounts+Sales Org+AAG(Cust)+AAG(MAT)+Acc Key+GL Acc
You are maintaining the same in VKOA.here Account key and g/l plays the major role.
Account key you will be assigning against to condition type in pricing procedure.
Value of the same condition type in the invoice will be carried forwarded to accounting through
account key and respective G/l which you have assigned in the VKOA.
2.We assign the KOFI100 in Billing type, what role does it has in Revenue acc det.
KOFI100 is a procedure which will have condition types KOFI and KOFK.IF You check VKOA you
an find these condition types.usually KOFI will be assigned for revenue accounts..

MM – FI Account determination

Purpose
The purpose of this page is to describe the main customizing settings for Account Determination.

Overview
For every goods movement created for a valuated material, the SAP system can create two types of documents: a material
document and an accounting document. The SAP system follows the accounting principle that for every material movement,
there is a corresponding document that provides details of that movement. In addition, an accounting document is produced
that describes the financial aspects of the goods movement.

The material document and accounting (FI) document creation depend on the movement type configuration.

Through the movement type configuration and based on the customizing settings defined for the account determination the
SAP System can do automatic account postings.

To determine the customizing settings for Account Determination you should GO through the following customizing
path: SPRO -> IMG -> Materials Management -> Valuation and Account Assignment -> Account Determination.
 Below sections describe the two ways to define the account determination: Account Determination Wizard and Account
Determination without Wizard.

Account Determination Wizard

It is a proposal from SAP System to define the account determination.

In this step, you can quickly configure the system to make automatic postings by answering the wizard's questions. The
wizard undertakes the functions of the following steps:

1. Defining valuation control

2. Grouping valuation areas

3. Defining valuation classes

4. Defining account grouping for movement types

5. Purchase account management

6. Configuring automatic postings

You can continue to use these transactions either in conjunction with or instead of the wizard.

Account Determination Without Wizard

In this step, you can manually define the settings for account determination in Inventory Management and Invoice
Verification.

Account determination without the wizard enables you to make a more complex configuration than account determination
with the wizard, but requires that you are already familiar with the principle of automatic account determination in the ERP
System.

You can configure account determination with the wizard in the first instance, for example. Then, if the wizard does not meet
your company's account determination requirements, you can work without it.

You have to work without the wizard if you use the material ledger (this is standard).
• Define Valuation Control
 It can be configured by the following customizing path: SPRO -> IMG -> Materials Management -> Valuation and Account
Assignment -> Account Determination -> Account Determination without Wizard-> Define Valuation Control.

It defines if the valuation areas will be grouped by activating the valuation grouping code. This makes the configuration of
automatic postings much easier.

In the standard SAP R/3 System, the valuation grouping code is set to active as default setting.

Firstly, you should create the valuation grouping code.

It corresponds to the transaction OMWM.

OMWM - Valuation Control

• Group together Valuation Areas

It can be configured by the following customizing path: SPRO -> IMG -> Materials Management -> Valuation and Account
Assignment -> Account Determination -> Account Determination without Wizard-> Group together Valuation Areas.

In this step, you assign valuation areas to a valuation grouping code.

Valuation area corresponds to the organization level in which the valuation will occur. Or the valuation occurs at the plant
level or it occurs at the company code level.

The valuation grouping code makes it easier to set automatic account determination. Within the chart of accounts, you
assign the same valuation grouping code to the valuation areas you want to assign to the same account. The chart of
account is a list of accounts.

Within a chart of accounts, you can use the valuation grouping code:
• to define individual account determination for certain valuation areas (company codes or plants)

Example:

The valuation areas 0001 and 0002 are assigned to company codes which use the same chart of accounts. For both
valuation areas, however, you would like to define a different account determination.

You must assign different valuation grouping codes (for example, 0011 and 0022) to both valuation areas.
• to define common account determination for several valuation areas (company codes or plants)

Example:

Valuation areas 0003 and 0004 are assigned to company codes which use the same chart of accounts. Account assignment
for both valuation areas should be similar.

You assign the same valuation grouping code (for example, 0033) to both valuation areas. Thus, you only have to define
account assignment for both valuation areas once.

Requirements:
• You must have activated the valuation grouping code in the step Define valuation control (OMWM).
• You must have defined the valuation level in corporate structure Customizing. The valuation level is defined in transaction
OX14 where you should decide if the valuation will occur at the plant level or company code level.
• You must have assigned each plant to a company code in "Enterprise structure" into the Customizing. When assigning your
plants, the valuation areas are defined automatically. To assign a plant to company code you should go to transaction OX18.

OX14 - Define Valuation Level

Recommendation:

SAP recommends that you only use a valuation grouping code within a chart of accounts in order to prevent account
determination from becoming confusing.

Default settings

In the standard SAP system, valuation is predefined at plant level. All plants are grouped together via valuation grouping
code 0001.

Group together Valuation Areas corresponds to the transaction OMWD.

OMWD - Account Determination for Valuation Areas

• Define Valuation Classes

It can be configured by the following customizing path: SPRO -> IMG -> Materials Management -> Valuation and Account
Assignment -> Account Determination -> Account Determination without Wizard->Define Valuation Classes.

In this step, you define which valuation classes are allowed for a material type.

If an user creates a material, he/she must enter the material's valuation class in the accounting data (Accounting 1 and 2
views). The ERP system uses your default settings to check whether the valuation class is allowed for the material type.

The valuation class is a key to group materials with the same account determination. The valuation classes depend on the
material type. Several valuation classes are generally allowed for one material type. A valuation class can also be allowed
for several material types.

The valuation class determines the G/L accounts which will be updated as result of the goods movement generated for the
material.

The valuation class makes it possible to:

• Post the stock values of materials of the same material type to different G/L accounts
• Post the stock values of materials of different material types to the same G/L account

MM03 - Display - Acoount 1 view

The link between the valuation classes and the material types is set up via the account category reference.

The account category reference is a combination of valuation classes. Precisely one account category reference is assigned
to a material type.

Requirements
• You must have defined your material types.
• You must have defined the chart of accounts.
• You must have agreed with Financial Accounting which materials are assigned to which accounts.

Default settings

In the standard SAP R/3 System, an account category reference is created for each material type. The account category
reference is, in turn, assigned to precisely one valuation class. This means that each material type has its own valuation
class.

OMSK – Account Category reference/valuation class

OMSK – Account category reference button

 OMSK - Valuation Class Button

OMSK - Material Type/Account category reference

• Define Account Grouping (account modifier) for Movement Types

Using this function, you can assign an account grouping to movement types. The account grouping is a finer subdivision of
the transaction/event keys for the account determination.

The account grouping is provided for the following transactions keys:

• GBB (offsetting entry for inventory posting)
• PRD (price differences)
• KON (consignment liabilities)

The account grouping in the standard system is only active for transaction key GBB (offsetting entry for inventory posting).

OMWN - Define Account Grouping for Movement Types

• Purchase Account Management

It is used to attend legal requirement from specific countries (France, Italy, Finland, Belgium, Spain and Portugal). In this
step, you will define a specific valuation and a separate accounting document for Purchase Order postings.
• Configure Automatic postings
In this step, you enter the system settings for Inventory Management and Invoice Verification transactions for automatic
postings to G/L accounts.

You can then check your settings using a simulation function.

What are automatic postings?

Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions
relevant to Financial and Cost Accounting.

Example:
Posting lines are created in the following accounts in the case of a goods issue for a cost center:
• Stock account
• Consumption account

How does the system find the relevant accounts?

When entering the goods movement, the user does not have to enter a G/L account, since the ERP system automatically
finds the accounts for each posting based on the following data:
• Chart of accounts of the company code

If the user enters a company code or a plant when entering a transaction, the ERP system determines the chart of accounts
which is valid for the company code.

You must define the automatic account determination individually for each chart of accounts.
• Valuation grouping code of the valuation area

You must define the automatic account determination individually for every valuation grouping code within a chart of
accounts. It applies to all valuation areas which are assigned to this valuation grouping code.

If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the
valuation grouping code.
• Transaction/event key

You do not have to define these transaction keys, they are determined automatically from the transaction (invoice
verification) or the movement type (inventory management). In this step, you can only insert the account number for each
transaction key.
• Account grouping (modifier) (only for GBB, PRD and KOM)

Since the transaction key GBB is used for different transactions (for example, goods issue, scraping, physical inventory),
which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory
differences), it is necessary to divide the posting transaction according to a further key: account grouping code.
• Valuation class of material or (in case of split valuation) the valuation type

The valuation class allows you to define automatic account determination that is dependent on the material.

You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the
transaction key for every valuation class.

Default settings:

G/L account assignments for the charts of accounts INT and the valuation grouping code 0001 are SAP standard.

OMWB - Configure Automatic Postings

OBYC - Maintain FI configuration

How to test my account determination settings?

You should go to transaction OMWB and click on ‘simulation’ button. Then, insert the affected material, the correspondent
plant and the movement type. After that, click on ‘account assignments’ button and you will see the simulation’s result.

OMWB - Simulation
Important:

Report DFKB1INT: Display the source code in transaction SE38. It is used to shows us the possible values for the account
determination customizing settings. If the customer changed something here, it is not standard anymore.