Purpose

The purpose of this wiki is to provide an overview of account assignment in purchasing document, it also contains information about the customizing and the functionalities.

Overview

1.Definition.

2.Database table.

3.Account assignment category.

4.Customizing.

5.Function groups.

6.Function modules.

7.Special functionalities.

8.Tips and tricks.

Definition:

Specification of the objects (e.g. cost center, sales order, project) that are charged in the case of a purchase order for a material that is intended for direct usage or consumption

Database table:

EKKN for purchasing documents such as purchase orders, contracts...),

EBKN for purchase requisitions

T163K account assignment category customizing

T162K field selection

T163A combination of item category and account assignment category.

Account Assignment Category

The account assignment category determines:

The nature of the account assignment (cost center, sales order, and so on)

Which accounts are to be charged when the incoming invoice or goods receipt is posted

Which account assignment data you must provide

Customizing

The account assignment categories can be maintained in transaction code OME9. Table T163K for setting the detailed information Table T162K for setting the field selection information.

The automatic account assignment determination can be customized under:

Materials management - Valuation and account assignment - account determination - account determination without wizard - configure automatic postings



The G/L accounts are maintained under transaction FS03:

Financial accounting - General Ledger accounting - G/L accounts - Master records - G/L account creation and processing - edit G/L account (individual processing) - Edit G/L account centrally

One important customizing for the G/L account is the field status group which is on the tab create/bank/interest. If you have a look inside the maintained field status group you can find many fields which can also be customized in the account assignment category customizing from purchasing. The field status from both customizing must fit together.

Materials management - Valuation and account assignment - account determination - account determination without wizard - configure automatic postings The G/L accounts are maintained under transaction FS03: Financial accounting - General Ledger accounting - G/L accounts - Master records - G/L account creation and processing - edit G/L account (individual processing) - Edit G/L account centrally One important customizing for the G/L account is the field status group which is on the tab create/bank/interest. If you have a look inside the maintained field status group you can find many fields which can also be customized in the account assignment category customizing from purchasing. The field status from both customizing must fit together. The field status are set up in two places. on G/L account ( FS03 display, OB14 Maintain ) on account assignment category in purchasing ( OLME -> OME9)

Both settings must fit to each other. If not, you receive error message ME 045 says that G/L account cannot be used.

'Earmarked fund' should never be 'Req. Entry in G/L account's field status group setting.

Because the MIGO document will not store 'earmarked fund' therefore no earmarked fund in accounting document either.



Function groups:

Functional group MEPO Subroutine ITEM_PROCESS_MAIN check accounting information Subroutine MEPO_ACCOUNTINGS_PROCESS normal checks Subroutine KNT_COBL_PRUFEN_OHNE_KNT Co checks when account assignment category is initial Subroutine FINANZMITTEL determine FM account assignments

Function group MEACCTVI

This function group is for account assignment screens. The account assignment screen are used both in PO and PR. Screen 1000 multiple account assignment screen Screen 1100 single account assignment screen Screen 1200 header screen

This function group is for account assignment screens. The account assignment screen are used both in PO and PR.

Function modules

ME_ACCOUNTING_CHECK (only for enjoy transactions):

The main checks are made here. The structure COBL is used to call different function modules from other components with the same interface.

Some of these functions are: K_COBL_CHECK: Function that belongs to the component CO-OM (Overhead Cost Controlling). SD_ORDER_CHECK: Function that belongs to the component SD-SLS-GF-CO (SD CO interface). FI_COBL_CHECK: Function that belongs to the component FI (Financial accounting). CASH_FORECAST_MM_RELEVANT: Function that belongs to the component TR-CM-CM (Cash Management). AC_COBL_FAREA_SET: Function that belongs to the component FI-GL (General Ledger Accounting). AMIN_ORDER_ON_ASSET_CHECK: Function that belongs to FI-AA-AA (Asset Accounting). FMRE_COBL_CHECK: Function that belongs to PSM-FM-PO-EF (Public sector - Funds management).

The main checks are made here. The structure COBL is used to call different function modules from other components with the same interface. Some of these functions are: ME_ACCOUNT_ASSIGNMENT:

It determines the G/L account for process GBB or BSX. ( each movement type has its own transaction/process).

With this function module we prepare the data to finally call the function module MR_ACCOUNT_ASSIGNMENT which delivers the correct G/L account according to the value maintained in the automatic G/L account determination in customizing (TA OMWB):

Function module ME_ACCOUNT_ASSIGNMENT is used each time where a new G/L account has to be determined in purchasing applications.

When changing account assignment category, G/L account will always be filled by the new derived G/L account. If no G/L account derived, the G/L account field is initialized in screen.

It determines the G/L account for process GBB or BSX. ( each movement type has its own transaction/process). With this function module we prepare the data to finally call the function module MR_ACCOUNT_ASSIGNMENT which delivers the correct G/L account according to the value maintained in the automatic G/L account determination in customizing (TA OMWB): Function module ME_ACCOUNT_ASSIGNMENT is used each time where a new G/L account has to be determined in purchasing applications. When changing account assignment category, G/L account will always be filled by the new derived G/L account. If no G/L account derived, the G/L account field is initialized in screen. ME_ACCOUNTING_TYPE_CHANGE:

This function module is called when the account assignment category is changed. A very important subroutine here is the subroutine COBL_REDUCE. In this subroutine all fields are cleared which are suppressed by customizing for the new account assignment category (see also the FAQ note 496082 question 20).

Special functionalities

In a document, only 1 CO real object with maxim 3 CO statistical objects is allowed. Refer to note 41103. But for CO commitment updating, it does not matter if the object is real or statistical, the determine is done in function module K_OPEN_ITEM_PO

WBS-ELEMENT:

For the WBS-Element we have to different values: the external presentation and the internal presentation. The external presentation which will be seen and maintained on the dynpro is the value in field PS_POSID, the internal number is the one in field PS_PSP_PNR. Only the internal number will be saved in table EKKN/EBKN. There are two function modules to convert these numbers into each other. These are: PSPNUM_EXTERN_TO_INTERN_CONV PSPNUM_INTERN_TO_EXTERN_CONV.

For the WBS-Element we have to different values: the external presentation and the internal presentation. The external presentation which will be seen and maintained on the dynpro is the value in field PS_POSID, the internal number is the one in field PS_PSP_PNR. Only the internal number will be saved in table EKKN/EBKN. There are two function modules to convert these numbers into each other. These are: PSPNUM_EXTERN_TO_INTERN_CONV PSPNUM_INTERN_TO_EXTERN_CONV. Real estate objects (IMKEY):

If we have a accounting with reference to an real estate object the checks to this real estate object will be done in subroutine ENCODE_IMKEY in ME_ACCOUNTING_CHECK.

If we have a accounting with reference to an real estate object the checks to this real estate object will be done in subroutine ENCODE_IMKEY in ME_ACCOUNTING_CHECK. Assets:

We call the function module AMIN_COST_OBJECTS_GET before we read table TRWPR in ME_ACCOUNTING_CHECK. The speciality for the asset is that we always determine special fields from the asset.

Example:

In the asset a cost center is maintained -> this cost center will always be determined from the asset and cannot be maintained manually in our screen. If the cost center is changeable in our transaction and is changed manually the system will always switch this value back to the asset cost center.

We call the function module AMIN_COST_OBJECTS_GET before we read table TRWPR in ME_ACCOUNTING_CHECK. The speciality for the asset is that we always determine special fields from the asset. Example: In the asset a cost center is maintained -> this cost center will always be determined from the asset and cannot be maintained manually in our screen. If the cost center is changeable in our transaction and is changed manually the system will always switch this value back to the asset cost center. SD order (third party PO):

SD creates a purchase requisition with account assignment to a sales order. When such a purchase requisition is created we take over the order number (AUFNR) and save the purchase requisition with accounting reference to this order. The rest of the account assignment information will be determined from SD_ORDER_CHECK in ME_ACCOUNTING_CHECK. A PO can be created from this PREQ but the order number can never be changed.



When enter a sales order to PO as account assignment, in ME_ACCOUNITNG_CHECK, RWIN calls SD_ORDER_CHECK, SD_ORDER_CHECK determines cobl-kzbws (valuation of special stock) for the sales order, if cobl-kzbws is changed, system will determine the G/L account again according to the IMG settings ( Transaction OVZG and OMWB )

SD creates a purchase requisition with account assignment to a sales order. When such a purchase requisition is created we take over the order number (AUFNR) and save the purchase requisition with accounting reference to this order. The rest of the account assignment information will be determined from SD_ORDER_CHECK in ME_ACCOUNTING_CHECK. A PO can be created from this PREQ but the order number can never be changed. When enter a sales order to PO as account assignment, in ME_ACCOUNITNG_CHECK, RWIN calls SD_ORDER_CHECK, SD_ORDER_CHECK determines cobl-kzbws (valuation of special stock) for the sales order, if cobl-kzbws is changed, system will determine the G/L account again according to the IMG settings ( Transaction OVZG and OMWB ) Functional area

Functional area can be entered manually or be derived by system.

CO will initialize the functional area if funds management is not active.

This may causes problem if customer always enter the functional area manually.

Note 1061814 will take the original functional area if there is no new functional area derived.

Note 1047795 make sure MM passes G/L account to CO, therefore CO will initialize the functional area only if account assignment data are changed.

Functional area can be entered manually or be derived by system. CO will initialize the functional area if funds management is not active. This may causes problem if customer always enter the functional area manually. Note 1061814 will take the original functional area if there is no new functional area derived. Note 1047795 make sure MM passes G/L account to CO, therefore CO will initialize the functional area only if account assignment data are changed. Funds management/cash forecast management:

Unassigned Purchasing document

The funds management must be activated on company code level.

If funds management is active, system will show the account assignment tab on item detail level in the new purchasing transactions.

On this tab the fields FIPOS, FISTL, GEBER, KBLNR, KBLPOS and GRANT can be maintained and will be stored in EKPO or EBAN.

It is not possible to maintain multi account assignment lines and there is no EKKN or EBKN entry for such items.

Tips and tricks:

When you delete the account assignment category in line item, all account assignments are deleted automatically. You enter the new account assignment category afterwards, system will re-derive the account assignment objects again.

If you change the account assignment category from A directly to B, system takes all account assignment objects from A as manual entry, and derive other account assignment objects, afterwards according to the field status' setting to display or hide the account assignment objects. Exception is G/L account.

The account assignment category determines: