MM-FI integration: A conceptual

understanding
When it comes to MM-FI integration, many of us find difficulties in understanding the concepts and
account determination process. When I was trying to analyze my first issue related to how a stock
account is determined in a valuated transaction, I was lost in OBYC. Let us try to understand a few
terminologies used in MM-FI integration concepts. Once we are familiar with the concepts, we will further
discuss the account determination process in a stock movement-related transaction.

Valuation area:

The stock of materials owned by a company is an asset to the company. The valuation area defines the
organization level at which materials are valuated.

SAP has provided two options for valuation.

1. Valuation at the plant level: All materials are valuated at the plant level.

2. Valuation at the company code level: All materials in all plants of a company are valuated at the
company code level.

This setting is defined in t-code OX14.

Valuated stock:

Total valuated stock = Stock in unrestricted use + Stock in transit between storage locations/warehouses
of a plant + Stock in quality inspection.

Material type:
This defines the type of material. EG: Raw material, finished goods, etc.

Material type is defined during material master data creation.

Movement type:

This defines the type of material movement from one place to other. Movement type enables the system
to find predefined posting rules determining how the stock and consumption accounts are to be posted.
All possible goods movements are already defined by standard SAP

EG: Movement type 101 refers to goods receipt

Movement type is entered while posting stock movement-related transactions. Most of the time, standard
SAP automatically derives the movement type based on the transaction code.

EG: If we go to MIGO, the default movement type 101 is displayed by the system.

Valuation class:

Valuation class is defined for the combination of plant and material (In Accounting 1 view of material
master).

The valuation class allows the posting of stock values of

1. Materials of the same material type to different G/L account (Different valuation class is assigned in
different plants for the same material)

2. Materials of different material types to same G/L account (Same valuation class is assigned to
materials of different material types)

Note: G/L accounts can be defined at the valuation class level along with other parameters.

Valuation grouping code:

The valuation grouping code combines the valuation areas having the same business properties for
account determination. This reduces the number of entries created for automatic account determination
for the stock postings.

EG: Valuation areas 1 and 2 are required to be posted to the same G/L account, these are grouped to
valuation grouping code ABC and G/L is determined based on the valuation grouping code and valuation
class.

Before using valuation grouping code, it needs to be activated in OMWM.

The valuation grouping code is assigned to the valuation area in t-code OMWD.

In the example below, five valuation areas are assigned to the same valuation grouping code.

Account modification/General modification:

This key is used to determine different G/L accounts for the same kind of goods movement based on
origin and target.

EG: During the Goods issue, offsetting G/L is determined from transaction key GBB. If the business wants
to post to different G/Ls for goods issues for cost centers (Movement type 201) and good issues to orders
(Movement type 261) for the same material and plant, the Account modifier can help here. To understand
this better, let us go to t-code OMWN where we define the transaction key and account modification for
the movement type.

The transaction key, which we see in OBYC, is determined based on the movement type. In the below
screenshot, you can see all parameters are the same for movement types 201 and 261 except for
account modification.

Please read F1 help on different fields on this screen to know more about the functionality of each field.

T-code OMWN:
When a material document is posted with these movement types, the offsetting account is determined
from transaction key GBB based on the account modifier and valuation class. From the screenshot below,
you can see that different offsetting G/L accounts can be determined for the same transaction key and
valuation class.
By Default, Standard SAP defines account modification keys for the below transaction keys. User-defined
keys can also be defined and respective account determination settings can be maintained.

 GBB (offsetting entry for inventory posting)

 PRD (price differences)
 KON (consignment liabilities)

Below are the modification keys defined by SAP (Extracted from F1 help).

Modifiers for GBB

For the transaction/event GBB (offsetting entry for inventory posting), the following account groupings have already
been assigned to the relevant movement types:

 AUF: for goods receipts for production orders with account assignment
 BSA: for initial entries of stock balances
  INV: for expense/revenue from inventory differences
 VAX: for goods issues for sales orders without account assignment object
 VAY: for goods issues for sales orders with account assignment object
 VBO: for consumption from the stock of material provided to the vendor
 VBR: for internal goods issues (e.g., for cost center)
 VKA: for consumption for sales orders without SD
 VNG: for scrapping/Destruction
 VQP: for sampling
 ZOB: for goods receipts without purchase orders
 ZOF: for goods receipts without production orders

Modifiers for PRD

If you also activate account grouping for transaction/event PRD (price differences) when you make the settings for
automatic postings, the following account groupings are already assigned to the relevant movement types in the
standard:

 none for goods receipts and invoice receipts for purchase orders
 PRF: for goods receipts for production orders
 PRA: for goods issues and other goods movements

Modifiers for KON

If you also activate account grouping for transaction/event KON (consignment liabilities) when you make the settings
for automatic postings, the following account groupings are already assigned to the relevant movement types in the
standard:

 none for consignment liabilities

 PIP: for pipeline liabilities

How are the account determination attributes determined for each transaction
key/event?

Did you observe a different set of fields appearing for different transaction keys in OBYC while
maintaining a G/L account? Yes. This is defined in the Rules for the transaction key.

EG: Select transaction key AUM in OBYC and click on “Rules” in the toolbar.

You can see that the general modification and valuation modifier is active.
If you go to G/L account maintenance for this key, you would see the same fields.

MM-FI integration: Account determination simulator

Now we know how MM and FI are integrated, and how the account determination happens. If we want to
test inventory account determination, you need to neither do actual material posting in the system nor go
through master data and customization to identify the accounts. SAP has delivered an account
determination simulation tool.

This helps to find how an account is determined while posting stock-related transactions. We just need to
input plant, material, and movement type and select the transaction we would like to check say GR for the
purchase order, GR for process orders, etc. Based on the above inputs, the system would read
customization, and master data, and simulate the account determination process. Apart from the above,
the system would also identify missing account assignments for a given transaction. This would further
help to analyze issues in an easy manner.

Go to T-code OMWB and close the initial popup. Click on the Simulation button.

Fill in a plant, material, and movement type, and enter. The transaction list would be
automatically refreshed based on the movement type. Double-click on the required type
of transaction to be checked say GR and click on Account assignments.
In the next screen, we can see the list of all available transactions possible for this
movement type, plant, and material combination. Some fields like those that material
type, valuation class, etc. are derived from material master data. Some fields like
valuation area, valuation-grouping code, etc.; are derived from the customization of the
plant.
In this screen, we can see what all accounts are determined for different kinds of
transactions.

EG: For Inventory posting, you can see Debit/Credit posting keys and respective G/L
accounts. If there are any missing account assignments for a given transaction, this is
also highlighted with text as “Missing”.

In the above example, you can see this happened for the Purchase account and
purchase offsetting account. We do not have any account assignments here as we are
not using this scenario. In this way, we can clearly identify the gaps in account
assignments without even doing the actual posting.

We can change to different movement types and transaction combinations and see how
to account determination happens and based on what fields it happens. You can try this
in your system for various permutations and combinations.
The second feature available with this tool is, to check the screen layout. This would
help to identify any conflicts in screen layout rules for the inventory G/L account item
during material document posting.

The screen layout for the inventory account item is determined at two levels.

1. From field status group of movement type

2. From field status group of inventory G/L account.

Click on the “Check screen layout” button. In the Next screen, we can see what the
field is status set at the movement type level and G/L account level. We should ensure
that there is no conflict between these two-field status exist.

EG: We cannot have a field mandatory in one FSG and suppressed in another FSG.
Posting would fail in such cases.

Sample output:

Just hover on the small ICON to see if a field is Mandatory/Optional/Suppressed/Display

only. Any conflicts found should be reported in the error log in the toolbar.

In case of conflicts, priority would be given in the sequence below with the exception of
required and suppressed combinations, which are not allowed.

1. Suppressed
2. Display
 3. Required
4. Optional

The third option provided by this tool is, “where used list of G/Ls”. This would help to
Identify in what all scenarios a G/L has been configured in the system.

From the main screen of OMWB, click on where used list of G/L.

Enter the company code and valuation area in the next screen and execute.

Sample output:

This output shows the list of valuation classes and transaction keys a G/L has been
assigned to.

The hierarchy is as below.

Chart of accounts

|-G/L account

|-Valuation class

|-Transaction event key

|-Account grouping code

Material Type is linked to A/C Category Reference

A/C Category Reference is linked to Valuation Class
So Indirectly Material Type gets linked to Valuation Class
There is a link to the Valuation Area i.e. Plant + Company Code +Chart of Account +
Valuation Grouping Code
Diff. Valuation Areas are grouped together under one Valuation Grouping Code.
There is linking of the following as well -
Movement Type + Valuation Strings + Transaction Key + Account Modification