Commitments

Commitments in Purchasing
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

• Page restrictions apply

• Attachments:11
• Added by Guest, last edited by Jimmy Zhang on Nov 16, 2009 (view change)
Comment:
view

Commitments in Purchasing
Author: I007379
MM-PUR IMS Palo Alto
October 2008
Contents:
• Commitments in Purchasing
• Commitment Overview
○ Definition
○ Design
○ Relationship to other applications
• Commitment Process
○ Quantity / Value based
○ Commitment relevant items
○ Purchase Requisitions
○ Purchase Orders
○ Delivery Costs
 Total Commitment Reduction
○ Parked Invoices
• Multi Accounts
○ Invoice
 Invoice (I)
 Invoice (II) EXAMPLE
 ○ GR
• Technical Details
○ Structures & Tables
○ 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
○ Transactions & Reports
 Transactions
 Useful reports/tools in Commitment Management (I)
 Useful reports/tools in Commitment Management (II)
○ Notes
 MM-PUR issue identification
○ 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 Process
The 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-WEUNB
if set -> valuation at IR
if 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 commitments
if 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 RWIN
The 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_RKO
Function module called when creating or changing Purchasing orders.
ME_STATISTICS_EBAN_RKO
Function 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_RKO
Function module called when documents with reference to a purchasing order are posted.
ME_ACCOUNTING_CHECK
Function 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 EINS
FM '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 EINS
FM '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
*commitments
CALL FUNCTION 'AC_DOCUMENT_PARKING_NO_UPDATE'
IMPORTING
e_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 structure
Check 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