FI-MM Integration Configuration & Key fields

involved
Materials management module is tightly integrated with FI. The integration bridge for Fi
& MM is Goods Receipt. This document explains the configurations involved in FI-MM
Integration and significance of the key fields related to FI-MM Integration

Valuation Classes
In this step, you define which valuation classes are allowed for a material type.
If a user creates a material, he must enter the material's valuation class in the accounting data. The R/3
System uses your default settings to check whether the valuation class is allowed for the material type.
The valuation class is a group of materials with the same account determination. If a transaction is to be
posted to different accounts depending on the valuation class, create an account determination for each
valuation class in the step Create automatic postings.
The valuation classes allowed 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 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.

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.

Under Further information there is a list of transactions in Materials Management and their
definitions.

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 R/3
System automatically finds the accounts to which postings are to be made using 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 R/3 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

If the automatic account determination within a chart of accounts is to run differently for certain company
codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas.
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 (internal processing key)

Posting transactions are predefined for those inventory management and invoice verification transactions
relevant to accounting. Posting records, which are generalized in the value string, are assigned to each
relevant movement type in inventory management and each transaction in invoice verification. These

contain keys for the relevant posting transaction (for example, inventory posting and consumption
posting) instead of actual G/L account numbers.
You do not have to define these transaction keys, they are determined automatically from the transaction
(invoice verification) or the movement type (inventory management). All you have to do is assign the
relevant G/L account to each posting transaction.

Account grouping (only for offsetting entries, consignment liabilities, and price differences)

Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for
example, goods issue, scrapping, 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.
An account grouping is assigned to each movement type in inventory management which uses the
posting transaction "Offsetting entry for inventory posting".
Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for
every account grouping, that is, assign G/L accounts.
If you wish to post price differences to different price difference accounts in the case of goods receipts for
purchase orders, goods receipts for orders, or other movements, you can define different account
grouping codes for the transaction key.
Using the account grouping, you can also have different accounts for consignment liabilities and pipeline
liabilities.

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. for example: you post a goods receipt of a raw material to a different stock account than if the
goods receipt were for trading goods, even though the user enters the same transaction for both
materials.
You can achieve this by assigning different valuation classes to the materials and by assigning different
G/L accounts to the posting transaction for every valuation class.
If you do not want to differentiate according to valuation classes you do not have to maintain a valuation
class for a transaction.

Valuation area:
Stock of a material owned by a company is an asset to the company. Valuation area defines the
organization level at which materials are valuated.
SAP has provided two options for valuation.
1. Valuation at plant level: All materials are valuated at plant level.
2. Valuation at company code level: All materials in all plants of a company are valuated at 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 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 transaction code.
EG: If we go to MIGO, default movement type 101 is displayed by system.

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

Valuation class allows posting of stock values of

1. Materials of 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 type to same G/L account (Same valuation class is assigned to materials
of different material type)
Note: G/L accounts can be defined at valuation class level along with other parameters.

Valuation grouping code:

Valuation grouping code combines the valuation areas having same business properties for the account
determination. This reduces number of entries to be created for automatic account determination for the
stock postings.
EG: Valuation area 1 and 2 are required to be posted to same G/L account, these are grouped to
valuation grouping code ABC and G/L is determined based on valuation grouping code and valuation
class.
Before using valuation grouping code, it needs to be activated in OMWM.

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

Account modification/General modification:

This key is used to determine different G/L account for the same kind of goods movement based on origin
and target.
EG: During Goods issue, offsetting G/L is determined from transaction key GBB. If business wants to post
to different G/Ls for goods issue for cost centers (Movement type 201) and good issues to orders
(Movement type 261) for the same material and plant, 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.
Transaction key which we see in OBYC is determined based on the movement type. In below screenshot,
you can see all parameters are same for movement type 201 and 261 except account modification.
When material document is posted with these movement types, offsetting account is determined from
transaction key GBB based on account modifier and valuation class.
From below screenshot, you can see that, different offsetting G/L account can be determined for the same
transaction key and valuation class.

By Default, Standard SAP defines account modification keys for 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 stock of material provided to vendor

VBR: for internal goods issues (e.g., for cost center)

VKA: for consumption for sales order 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 different set of fields appears for different transaction keys in OBYC while maintaining
G/L account? Yes. This is defined in Rules for the transaction key.
EG: Select transaction key AUM in OBYC and click on "Rules" in toolbar.

You can see that general modification and valuation modifier is active.

If you go to G/L account maintenance for this key, you would see the same fields.

Purchase to Pay Cycle in SAP with Accounting in

Entries
The P2P cycle captures the entire business processes between the Organization and
the Vendors.
The five key stages within this cycle are:

Purchase Order
Goods Receipt
Invoice Verification
AP Invoice
Outgoing Payment

Purchase Order
A PO is the process by which you purchase goods from a supplier (vendor). It forms
a legal contract between the buyer (your Organization) and the vendor. It contains
the list of materials you are buying, quantities, prices and delivery information.

A PO may be created based on a Purchase Requisition or a previous PO. Information

is also pulled from info records that contain purchasing related information for the
vendor-material combination.
The PO details the materials that you are procuring. A material is assigned an
account assignment object, such as profit center, which ensures that it is properly
represented in reports.
PO can be created in T.code ME21N, as shown below

There is no accounting entries during PO creation and hence no FI document is

created in SAP.
Goods Receipt
A Goods Receipt is posted in the system when materials are received into inventory
(stock). The main purpose of GR is to ensure that the items you received match the
information that was originally part of the PO, especially when you receive items in
more than one delivery.
Goods Receipt is the integration point between MM and FI.
Goods Receipt can be posted in MIGO, as shown below

GR has been posted for the above PO.

The accounting entry at the time of GR posting:
Inventory Account (stock Raw material) Dr
To GR/IR clearing Account Cr
The GR posted will be updated in the corresponding PO, as shown below

Click on the GR document, and select the FI document icon, as highlighted below

Select the Accounting Document in the pop-up

FI Document during GR posting:

The account determination for GR posting is done in T.code OBYC.

Inventory account is provided under Transaction Type: BSX

The valuation class can be obtained from the material master, as shown below

GR/IR account is provided under Transaction Type: WRX

The valuation class determines the GL accounts to hit, when a specific transaction
happens. Usually, for a group of materials, a valuation class will be assigned from
MM side in material master data (MM01). In OBYC, as shown above different
transaction keys eg: BSX, WRX..etc) would be defined. These transaction types
determines the type of transaction ( accounting entries).The transaction keys are
assigned to the respective movement types in MM side. In OBYC, for respective
transaction keys the required GL accounts to hit are configured.
Valuation modifier should be enabled to maintain GL accounts plantwise.
Invoice Verification
Here the vendor invoices are validated before any payments are made to them. The
invoice verification is done based on goods receipt and follow a three-way matching
policy (among the invoice, the goods receipt and the PO).
The system not only validates the quantity, but also the value in goods receipt while
doing invoice verification. If there are variances, system creates variance postings.
Variance postings are posted to general ledger which are customized in MM
automatic account determination tables.
Invoice Verification can be posted in T.code: MIRO for the PO created.

As shown below, Invoice has been created for the above PO, as highlighted.

The invoice document posted can be obtained in PO under tab PO history, as

highlighted below

Click on the invoice document in Purchase Order.

Click on icon Follow-On Documents, as highlighted above to get the accounting

document

The Accounting entry during Invoice verification is:

GR/IR Clearing Account Dr
To Vendor Account Cr

Accounts Payable Invoice

The invoice verification process takes place within MM, but this generates as AP
invoice within the AP subcomponent (FI Document).

The accounting document for the invoice posted in MIRO is shown above.
For all inventory-related purchases invoice is created based on PO in MIRO
transaction code. For non-inventory related purchases, there wont be any PO or
goods receipt process. Invoice is posted directly in FB60.

Outgoing Payments
Outgoing payments will make the payment to the open vendor invoices. Either it
can be made manually or by using automatic payment program.

Manually, the payment can be made in T.code: F-53

Enter the details such as bank account no. from which payment has to be made, as
shown above and click on Process open items icon highlighted above.

Select the appropriate line item (invoice to br paid), activate the item and make
sure that the not assigned amount is zero before posting the payment document.

The accounting entries while payment for the discussed case is shown below. It will
be obtained during simulation.

Automatic Payment can be made in T.code: F110 and the configuration for APP
should be done in T.code: FBZP in prior

The Accounting entry while making the payment to Vendor is:

Vendor Account Dr
To Bank Account Cr

Once the invoices (open items) are paid, those open items will be updated as cleared in
T.code: FBL1N (Line item Display)