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.
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.
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
Function modules
ME_ACOUNTING_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).
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.
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.
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.
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.
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 )
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.
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.
