Commitments

Commitments in Purchasing

Page restrictions apply Attachments:11 Added by Guest, last edited by Jimmy Zhang on Nov 16, 2009  (view change)

Commitments in PurchasingAuthor: I007379MM-PUR IMS Palo AltoOctober 2008

Contents:

Commitments in Purchasing Commitment Overview

o Definition o Design o Relationship to other applications

Commitment Process o Quantity / Value based o Commitment relevant items o Purchase Requisitions o Purchase Orders o Delivery Costs

Total Commitment Reduction o Parked Invoices

Multi Accounts o Invoice

Invoice (I) Invoice (II) EXAMPLE

o GR Technical Details

Link to this Page Link Tiny Link Wiki Markup Close Move Page – ‘Com

Set Page Location Move OK Cancel Click to select the Search

Recently View ed There w ere no re Know n Location The specified pag Brow se Error reading the

You could try relo HTTP Status You must make a Failed to retrieve There w ere no pa Show ing <b>{0}<

Move failed. Ther You cannot move Commitments in P Purchasing (MM-P ERPSCM

ERP SCM You cannot move Page Ordering Back Reorder Move

Unknow n user or Page Restrictions Editing restricted Cancel Close Save

107610964

view

o Structures & Tables o Important Programs & BADIs

COOI: Commitments Management: Line Items MM-PUR Commitment Functions Func Group: EINS Commitment for Purchase Requisitions Program - Breakpoints Commitment for Purchase Orders (I) Program - Breakpoints Commitment for Purchase Orders (II) Program - Breakpoints Commitment for Purchase Orders (III) Program - Breakpoints Commitment for Purchase Orders (IV) Program - Breakpoints Delivery Costs Program - Breakpoints GR/IR processing (I) GR/IR processing (II) Parked Invoices Program - Breakpoints BADIs

o Transactions & Reports Transactions Useful reports/tools in Commitment Management (I) Useful reports/tools in Commitment Management (II)

o Notes MM-PUR issue identification

o Sources of Information

Commitment Overview

Definition

A commitment is a budget reservation for consumption — an allotted amount committed in advance of an obligation.

Purchase Requisitions and Purchase Orders can both commit values

Relevant information is passed from purchasing to Controlling (CO), Funds Management (FM), Financial (FI)

Based on this information, the Financial Area is able to determine that consumption from budget exists and as consequence, it commits the corresponding value.

Design

Purchasing Requisitions: based on the purchasing orders created with correspondence to the purchasing requisition.

Purchasing Orders: based on the related documents posted against the purchasing document (goods receipt (GR), invoices (IV), credit memo (CM), etc.)

Relationship to other applications

Controlling (CO)The interface to the cost accounting system (Controlling) can be seen in the case of purchase orders for materials intended for direct consumption and for services, since these can be directly assigned to a cost centre or a production order.

Financial Accounting (FI)Purchasing maintains data on the vendors that are defined in the system jointly with Financial Accounting. Information on each vendor is stored in a vendor master record, which contains both accounting and procurement information. The vendor master record represents the creditor account in financial accounting. Through PO account assignment, Purchasing can also specify which G/L accounts are to be charged in the financial accounting system.

Funds Management (FM)The functions in this component support the budget creation. The tasks of Funds Management are to budget all revenues and expenditures for individual responsibility areas, monitor future funds movements in light of the budget available, and prevent budget overruns. Funds Management is fully integrated with MM. When a purchase order has been posted, availability control checks whether sufficient budget is available. If it is, the posting data is passed automatically to Funds Management and displayed in the information system as expenditures, under "Purchase orders". If there are not enough budgets, the system rejects the purchase order.

Commitment ProcessThe purchasing system is integrated with the CO/FI/FM applications. The link between the applications is made via different function modules.

Database table TRWPR contains the relevant functions that will be called in these applications, depending on the transaction being performed.

Function RWIN_CHECK is called during commitment relevant processes (ex. PO creation). The system checks table TRWPR, and stores the functions to be called in internal table TRWIN.

Info from the purchasing document like purchasing order value, quantity, account information, as well as the relevant documents posted with reference to this purchasing order (purchasing order history) are calculated and provided to CO/FI/FM via the relevant functions for the transaction.

XEKBP: Information from Purchase Order XEKPR: Information from Purchase Requisition

Quantity / Value based

Purchase Requisitions: Non-service items - quantity based Service items - value based Note 35793

Purchase Orders: Value based or quantity based - determined by unit of measure:

transaction CUNI  (Customizing -> General settings -> Check unit of measurement)

T006-KZWOB ( if set = value related). Note 639523

Commitment relevant items

Commitments handled when functionality has been activated in the relevant FI application.

First, in the Controlling Area, Commitment Management must be active for the current fiscal year (transaction OKKP).

Second, the object concerned must be able to accept commitments: Orders: switch in the Order Type Cost Centers: Lock indicator not set in master data (KS03, button 'Indicators') Projects: note 47992

Field XOBLR indicates whether the commitments should be or should not be handled for a PR/PO position (tables EBAN or EKPO)

Function ME_ACCOUNTING_CHECK, checks whether the commitments are active or not. When the commitments are active, XOBLR is filled with 'X'.

Purchase Requisitions

For purchase requisitions, commitments are created based on the requisition quantities and values.

EKPR - communication structure used to pass the information regarding a purchase requisition to the financial applications.

BAWTW - Purchase requisition value (transaction currency = TW) BAWHW - Purchase requisition value (local currency = LC) MENGE - Purchase requisition quantity.

Also there are commitments based on the purchasing order quantities and value for the documents created with reference to a requisition.

BSMNG - Purchase order quantity BEWTW - Real total value (purchase order currency = TC). BEWHW - Real total value (local currency = LC)

For non-service items, the purchase requisitions commitment reductions is always quantity based ( See note 355793).

Purchase Orders

For Purchase Orders, commitments are based on PO quantity and values, account assignment data, and quantities and values from follow-on docs (GR or IR depending on how valuation is done - GR non-valuated: WEUNB?).

EKBP - communication structure used to pass the information regarding a purchase order to the financial applications.

BEMNG - Purchase Order Quantity BEWTW - Value in transaction currency BEWHW - Value in local currency. WEMNG - Quantity of Goods Received WEWTW - Goods receipt value (purchase order currency = TC) WEWHW - Goods receipt value (local currency = LC) REMNG - Quantity invoiced REWTW - Real invoice value (purchase order currency = TC) REWHW - Real invoice value (local currency = LC) WEUNB - Goods Receipt, Non-Valuated ELIKZ - Delivery Completed Indicator LOEKZ - Deletion Indicator in Purchasing Document

The information from these documents is taken from the purchasing database EKBE. debit documents are stored with SHKZG (Debit/credit indicator) = 'S'. credit documents are stored with SHKZG (Debit/credit indicator) = 'H'.

Delivery Costs

Purchase order conditions include delivery costs. Since these are incorporated into the item effective price they are also subject to commitments.

Reductions of the committed delivery cost can be processed for debit documents like GR and IV.

The delivery costs are displayed individually according to origin (for example, freight costs, duty costs, packaging) on CO side.

Statistical conditions in the calculation schema, but included in the effective value: EFFPR - effective price EFFWR - effective value

See note 670489 which describes commitments for delivery costs

Total Commitment Reduction

PO Commitment will be completely reduced (set to zero), and item considered closed for commitments when:

Item has been fully delivered and/or received (depending on when valuation is done) GR valuated: delivery completed indicator (EKPO-ELIKZ) set IR valuated: final invoice indicator (EKPO-EREKZ) set Deletion indicator (EKPO-LOEKZ) set

Depends on valuation - check gr non-valuated flag EKPO-WEUNBif set -> valuation at IRif blank -> valuation at GR

Parked Invoices

3 scenarios

not completely parked - never update commitments completely parked - update commitments badi ME_COMMITMENT_PARKING activated - decides if completely parked invoices

update commitmentsif NOT -> set if_no_update_parked_iv to 'X' in form check_pre_iv

Multi Accounts A purchase order item can be assigned to several account assignment objects

XEKBP will have a record for each account with different ZEKKN information.

The account information of a purchasing order can only be changed if no goods receipt or invoices have been posted.

Invoice

Invoice (I)

In invoice documents it's possible to change the account. This means that it's also possible to introduce an account that doesn't exist on the purchasing document. In this case, this information will be treated as "UNPLANNED"  (EKBE-XUNPL).

The total amount of partial invoices can be distributed among the individual accounts in two ways ( EKPO-TWRKZ - Partial invoice indicator ) :

progressive fill-up basis (Following Row) proportional basis

If you enter a partial invoice at invoice receipt, the system calculates the distribution of the costs in invoice verification according to the partial invoice indicator entered and suggests the relevant values for the individual accounts.

You can overwrite these values if you want to use a different distribution to that planned in the purchase order.

Invoice (II) EXAMPLE

100 pieces of a material have been ordered at $10 per piece for various cost centers as follows:

50 pieces for cost center A 40 pieces for cost center B 10 pieces for cost center C

A partial invoice is entered for this purchase order.The invoice amount is $700, covering 70 pieces. The invoice amount is distributed as follows depending on how the PO has determined the split should happen:

GR

In goods receipt documents it's not possible to change the account information.

The records in EKBE (for non-service items) have the field ZEKKN = '0' . The quantities and values are distributed among the accounts in a progressive fill-up way.

Technical Details

Structures & Tables

EKPR

DDIC structure which contain the relevant information regarding the purchasing requisition documents.

This is the structure passed to the commitments interfaces registered on TRWPR when a process that may change the commitments for a purchasing requisition has been processed.

EKBP

DDIC structure which contain the relevant information regarding the purchasing orders documents.

This is the structure passed to the commitments interfaces registered on TRWPR when a process that may change the commitments for a purchasing order has been processed.

The value on this table should always represents the Purchasing order information, as well as the PO history.

TRWPR

Interface table that contains function calls. The key fields of this table are: process (e.g. DOCUMENT), event (e.g. CLOSE) and a

sequence number. The calling applications know the process, the event and the corresponding interface. The

caller reads all the functions for a certain process and event in the order of the sequence number. The main advantage of this design:

New receiver functions can be added to the table TRWPR without modifying any code.

10.2 EKBE

Database, which contains the purchasing order history. It contains information from documents posted with reference to a purchasing order like goods

receipt, invoices, credit memos, etc.

10.3 EKBZ

Database, which contains the delivery costs in the purchasing order history. It contains information from the delivery costs for documents posted with reference to a

purchasing order like delivery costs for goods receipt, invoices, credit memos, etc.

Interface RWINThe RWIN is SAP's standard accounting interface in R/3.

A sending application notifies multiple receiving applications about a document that might have an impact in accounting. The sending application can be any R/3 component; the receiving applications are accounting applications.

The sender document and all resulting receiver documents use an identical key (AW*-fields) to identify all documents belonging to one sender document.

The most important functions of the RWIN are AC_DOCUMENT_CREATE (publishes the information of the document) and AC_DOCUMENT_POST (publishes the number AWKEY of the sender document).

All the senders are called via the TRWPR mechanism (process DOCUMENT).

Important Programs & BADIs

COOI: Commitments Management: Line Items

This the database table on CO side which controls the commitments:On this table, it's possible to check the commitments created for a purchasing order. Here you can check important information for a PO commitment like:

REFBN - reference document number - Purchasing order number RFPOS - reference document item number - Purchasing order item

BLDAT - document date GESMNG - purchased quantity MEGBTR - open quantity (purchased quantity - reduced quantity) ORGWTH - purchased value in local currency WHGBTR - open value in local currency (purchased value - reduced value) ORGWTT -Planned value in object currency - Total value in object currency BUWTGBTR DAT - expected debit date (delivery date)

Fields that begin with 'ORG' (original), represent the committed values.Fields that begin with 'W' represent the actual committed values.The information on this table can also be checked with KS02 transaction or in the purchasing document: Environment -> AC Commitment Documents.

MM-PUR Commitment Functions Func Group: EINS

ME_STATISTICS_RKOFunction module called when creating or changing Purchasing orders.

ME_STATISTICS_EBAN_RKOFunction module called when creating or changing Purchasing requisitions. This function is also called when a PO with reference to a PR has been created or modified or goods were received or invoices were posted for the PO.

ME_STATISTICS_EKBE_RKOFunction module called when documents with reference to a purchasing order are posted.

ME_ACCOUNTING_CHECKFunction module, that checks whether the commitments are active by the financial applications or not. This function is used to updates the field XOBLR.

Commitment for Purchase Requisitions Program - Breakpoints

Function Group EINSFM 'ME_STATISTICS_EBAN_RKO'

In this function, the information regarding a PR is processed. Check if in the T_EBAN the positions are commitments relevant (XOBLR).

Set a breakpoint at end of function (where mm-pur calls applications) in order to check the information in XEKPR that will be provided:

Commitment for Purchase Orders (I) Program - Breakpoints

Function Group EINSFM 'ME_STATISTICS_RKO'

This function is called when a PO has been create / changed. Set a breakpoint at end of function (where mm-pur calls applications) in order to check the

information in XEKBP that will be provided:

Commitment for Purchase Orders (II) Program - Breakpoints

Commitment for Purchase Orders (III) Program - Breakpoints

Commitment for Purchase Orders (IV) Program - Breakpoints

Delivery Costs Program - Breakpoints

GR/IR processing (I)

Function me_statistics_ekbe_rko-> form ekbe_verteilung          loop zekbe (all documents in PO history).         1 record moved to structure EKBE          -> form ekbes_bereitstellen             zekbes - 1 record per PO position (accumulation of whole PO history for item)                 Price is found using info from zekbes for 1 unit:                      total invoiced value / quantity = value of 1 unit (used in calculation of invoice value)

GR/IR processing (II)

form RKO_EKBE called from ekbe_verteilung after ekbes_bereitstellen-> form rko_verteilung

-> form verteilung (xekbp updated here)

Parked Invoices Program - Breakpoints

LEINSF08 Form initialize_pre_iv*when the Badi is active the parked invoices should not update the*commitmentsCALL FUNCTION 'AC_DOCUMENT_PARKING_NO_UPDATE'IMPORTINGe_parking_no_update = lf_no_update_parked_iv.

There is then a check on lf_no_update_parked_iv. If set, then no parked invoices (even completely parked) should update commitments.

BADIs

From 47.0 release, there are some BADIs available that activate additional functionalities:

MEPOBADI_CHOICE_OBLIGO - commitments for release strategy /parked PO. ME_COMM_STO_ACTIVE_CHECK - commitments for stock transport orders. AC_DOCUMENT_PARKING_NO_UPDATE - commitments for parked invoices/credit

memo ME_COMMTMNT_REQ_RELE - (sap use) - release status taken into consideration ME_COMMTMNT_REQ_RE_C - (customer use) (Note 716735) ME_COMMITMENT_PARKING - available in 470. customer must create the method. Not

in standard. Note 604033

Transactions & Reports

Transactions

KS02 - transaction for cost center commitments CUNI - Unit of measure. OKKP - commitments management

Useful reports/tools in Commitment Management (I)

RKANBU01: This report rebuilds the commitment information based on the purchasing order

information and purchasing order history. It's very useful to correct wrong commitments when a problem has been found.

534993 - Short instructions RKANBU01 RFFMRP02N :

FM note 525247 & 452257 RKACOR04:

If one performs an analysis of the commitments and states that the line items are correct, but the summary record does not equal the total of the items, the out of balance can be corrected with program RKACOR04. See note 21649.

Since the parameters needed to start the program are very technical (for example, Object number OR000...) one should copy into the message the parameters the customer should use and limit the records to be processed as much as possible (for example, because of correction of commitment data do not mark ‚actual', indicate Cost Elements, etc.)

Useful reports/tools in Commitment Management (II)

CJEN: Reconstruction of the project information database.

RBPFCON1/RBPFCPN1: Reconstruction of availability control.

Notes

355793 - Quantity-based reduction of purchase requisition commitment 639523 - Commitments reduction behavior for Purchasing 534993 - Short instructions RKANBU01 152571 - Composite Note: Missing or Incorrect Commitments- CO side 670489 - Commitments for delivery costs

MM-PUR issue identification

When is it our problem?To identify if the problem is in the MM-PUR code, put a breakpoint in the appropriate function module and examine the XEKPR or XEKBP structureCheck before calls to Finance routines:LOOP AT trwin.CALL FUNCTION trwin-function

Breakpoints in:

Purchase Requisition - Function ME_STATISTICS_EBAN_RKO Purchase Order - Function ME_STATISTICS_RKO

The values should match what you see in the Requisition or in the Purchase Order and PO History. If values are correct in XEKPR/XEKBP, then issue is most likely in Finance routines.

Sources of Information

on-linedocumentation:http://help.sap.com/saphelp_47x200/helpdata/en/a9/ab7827414111d182b10000e829fbfe/frameset.htm

product support wiki - mm-pur:https://wiki.wdf.sap.corp/display/PSupportERPSCM/Commitments+in+Purchasing