Page tree
Skip to end of metadata
Go to start of metadata

Purpose

The purpose of this wiki is to explain the functionality of Commitments in Purchasing.

Overview

1. Introduction.

        1.1 Commitment Definition.

        1.2 Commitments in Purchasing.

        1.3 Design.

        1.4 Relationship to other Applications.

2. Handling Process.

3. Quantity based X Value Based..

4. Commitment Relevant items.

        4.1 Prerequisites for Commitment Updating.

5. Commitments for Purchasing Requisitions.

6. Commitments for Purchasing Orders.

7. Delivery costs.

8. Multiple Account.

        8.1 Invoice Behavior

        8.1 Goods receipt Behavior

9. Structures.

        9.1 EKPR.

        9.2 EKBP.

10. Tables.

        10.1 TRWPR.

        10.2 EKBE.

        10.3 EKBZ.

11. Interface RWIN.

12. Function Modules

13. COOI.

14. TRANSACTIONS.

15. Useful reports/tools in Commitment Management.

16. Related SAP Notes/KBAs.

1. Introduction

1.1 Commitment Definition

It is the amount of allotment or lower level authority committed in anticipation of an obligation.  In other words, it’s a budget reservation for consumption.

1.2 Commitments in Purchasing

When a purchasing document is created it’s possible to assign account information to the purchasing order item. The purchasing system is responsible to provide the relevant information as account used and corresponding values to Controlling (CO), Funds Management (FM), Financial (FI) applications, referred on this document as the Financial Area. Based on this information, the Financial Area is able to determine that consumption from a budget exists and as consequence, it commits the corresponding value.

This means that this part of the budget is committed to a purchasing document indicating that consumption for this budget (accounting) will exist.

It’s possible to commit values for purchasing orders and requisitions.

The commitment reduction for purchasing requisitions are based on the purchasing orders created with correspondence to the purchasing requisition.

For Purchasing orders, the commitment reduction, and as consequence, the consumption confirmation, is processed based on the related documents posted against the purchasing document like goods receipt (GR), invoices (IV), credit memo (CM), etc.

If in PO, the goods receipt flag is set, it means that incoming goods are expected. The flag 'goods unvalued' available on the PO document, controls whether the commitment is decreased when goods are received or when an invoice has been posted.  When the indicator “goods receipt non-valuated” is set, it means that the information from IV will be used to reduce the commitments created for the PO.

1.3 Design

1.4 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.

2. Handling Process

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

The function modules that establish the connection are contained on database TRWPR.

The Purchasing application is responsible to check this information when a process has been started that could have changed any relevant information regarding the commitments and to call these functions in order to provide the relevant information to the accounting interfaces.

In order to obtain this information, function RWIN_CHECK is called and the functions to be called are stored on internal table TRWIN.

After this process, the information from the purchasing document like purchasing order value, quantity, account information, as well as the relevant documents posted with reference to this purchasing order (here denoted as the purchasing order history) are collected, resumed and passed to the FI area via the functions provided by RWIN_CHECK.

On the communication structures (EKBP / EKPR) all information regarding the purchasing document should always be provided to the financial areas, independently from the event.

This means that when posting an invoice for a purchasing order, the purchasing quantities and values and the goods receipt quantities and values are also relevant and should be correctly available on the communication structure.

3. Quantity based X Value Based

For purchasing orders, the commitments can be value based or quantity base handled, based on the unit of measure used on the PO.

For positions that are using quantity-based commitments, the commitments will be reduced based on the quantity from the goods receipt/invoice and not in the value.           

In customizing, the unit of measure can be checked via transaction CUNI  [since 40A], or in the field T006-KZWOB (set means value related).

(Customizing -> General settings -> Check unit of measurement).

For purchasing requisitions, the commitments reduction can only be valued based for service items. For non-service items, the purchasing requisitions commitments reductions is always quantity based (note 355793).

4. Commitment Relevant items

Specifies that commitments management is relevant for an item. Normally the commitments are handled when this functionality has been activated in the respective financial application.

4.1 Prerequisites for Commitment Updating

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

Also, the object concerned must be able to accept commitments, in other words for:

- Orders: switch in the Order Type

- Cost Centers: Lock indicator not set in master data (KS03, button 'Indicators')

- Projects: see note 47992

On tables EBAN and EKPO there is the field XOBLR, which indicates whether the commitments should or not be handled for a PR/PO position.

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

5. Commitments for Purchasing Requisitions

The communication structure used to pass the information regarding a purchasing requisition to the financial applications is the EKPR.

For purchasing requisitions, commitments are created based on the requisition quantities and values. On EKPR, fields BAWTW - Purchase requisition value (transaction currency = TW), BAWHW - Purchase requisition value (local currency = LC) and MENGE - Purchase requisition quantity.

The commitments reduction is based on the purchasing order quantities and value for the documents created with reference to a requisition. On EKPR, fields BSMNG - Purchase order quantity and BEWTW - Real total value (purchase order currency = TC).

For non-service items, the purchasing requisitions commitments reductions is always quantity based (note 355793).

Breakpoints:

 

ME_STATISTICS_EBAN_RKO

On this function, the information regarding a PR is processed.

Check if in the T_EBAN the positions are commitments relevant (XOBLR).

At the end of this function, it’s possible to set a breakpoint in order to check the information in XEKPR that will be provided to the financial area:

  LOOP AT trwin.

    CALL FUNCTION trwin-function

      EXPORTING                                             "4.0C/PH

        i_refresh      = i_refresh  "4.0C D023145

        i_actual_vrgng = original_ev                        "4.0C/PH

        i_orgvg        = vg_rq                              "4.0C/PH

      TABLES

        t_ekpr         = xekpr.

  ENDLOOP.

At this point it’s possible to check if the sentences in XEKPR are correct, if the PR values and quantities are correct.

6. Commitments for Purchasing Orders

The communication structure is EKBP.

On EKBP, the purchasing order values are represented on BEWTW - value in transaction currency and BEWHW - value in local currency.

The goods receipt information is available on fields WEMNG - goods receipt quantity, WEWTW - goods receipt value in transaction currency and WEWHW – goods receipt in local currency. The values from these fields are responsible to reduce or increase the budget when on the purchasing order, the goods receipt are set as “valuated”  - on EKBP field WEUNB.

The invoice information is available on REMNG – invoice quantity, REWTW – invoice values in transaction currency and REWHW – invoice values in local currency.

The values from these fields are responsible to reduce or increase the budget when on the purchasing order, the goods receipt are set as “non-valuated”  - on EKBP field WEUNB.

On the actual logic, the quantities and values from the documents posted with reference to a purchasing order that represents consumption like a goods receipt or invoices are added on the respective fields in EKBP. The information from these documents is taken from the purchasing database EKBE. On EKBE debit documents are stored with SHKZG (Debit/credit indicator) = ‘S’.

Documents, that reduces the consumption, as goods receipt canceling or credit memo are used to reduce the values and quantities from the corresponding fields on EKBP. On EKBE credit documents are stored with SHKZG (Debit/credit indicator) = ‘H’.

 

Breakpoints:

 

ME_STATISTICS_RKO

This function is called when a PO has been create / changed. A good place to set a breakpoint is just before calling the financial applications:

   IF i_appl_refresh EQ space.

      LOOP AT trwin.

        CALL FUNCTION trwin-function

          EXPORTING

            i_actual_vrgng   = original_ev

            i_flg_check_only = i_flg_check_only             "610635

          TABLES

            t_ekbp           = xekbp.

      ENDLOOP.

    ELSE.

Here is possible to check whether the information XEKBP is correct or not.

 

FORM RKO_STATISTICS

This routine checks whether the PO item are commitment relevant or not. It also check when a PO has been changed if something relevant for the commitments has been changed.

FORM RKO_EKKO

On this routine, information from the EKKO (header) is used to format the correspondent fields on XEKBP.

FORM RKO_EKPO

On this routine, information from the EKPO (Item) is used to format the correspondent fields on XEKBP.

FORM RKO_EKKN

On this routine, the account information (EKKN) is used to format the correspondent fields on XEKBP. Each combination of account/schedule line will have a corresponding sentence on XEKBP.

FORM RKO_EKET

On this routine, the information from the schedule lines is used to format the XEKBP. The PO quantity – BEMNG and PO value – BEWHW and BEWTW are calculated based on the schedule line information. Each combination of account/schedule line will have a corresponding sentence on XEKBP. Here the sentences for XEKBP are appended on this internal table.

FORM RKO_KOMV

On this form routine the commitments are create in XEKBP for delivery costs. Each delivery costs represents a sentence in XEKBP.

FORM RKO_EKBE

Here the purchasing order history is processed.

FORM RKO_EKBZ

Here the delivery costs in the purchasing order history are processed.

FORM XEKBP_BEREITSTELLEN

On this form routine, system search the corresponding sentences in XKEBP, in order to assign the values from the goods receipt and invoices documents. Multiple account assignments are identified by ZEKKN (Sequential number of account assignment). When ZEKKN is different than ‘0’, it means that the document has multiple account assignment.

FORM VERTEILUNG

Here the goods receipt / Invoices values and quantities are assigned to the corresponding sentence on XEKBP. At this point the WEMNG / WEWHW / WEWTW / REMNG / REWHW / REWTW are filled.

FORM ACC_ASSIGN_RE

The unplanned account assignments are processed on this form routine.

7. Delivery costs

On purchasing order conditions, it’s possible to introduce delivery costs. The delivery costs are incorporated to the item effective price and for this reason, these values are also committed, once it also indicates consumption. The reductions of the committed delivery cost are also processed for debit documents as GR and IV.

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

Note 670489 - Commitments for delivery costs

Breakpoints:

 

FORM RKO_KOMV

On this form routine the commitments are create in XEKBP for delivery costs. Each delivery costs represents a sentence in XEKBP.

FORM XEKBP_BEREITSTELLEN

On this form routine, system search the corresponding delivery costs sentences in XKEBP, in order to assign the values from the delivery costs from the goods receipt and invoices documents. Each delivery cost has a different STUNR (Number that determines the sequence of the condition within a procedure). Based on this information, system can match the information from EKBE and XEKBP for delivery costs.

FORM RKO_EKBZ

Here the delivery costs in the purchasing order history are processed.

8. Multiple Account

In the Purchasing component, you can assign a purchase order item to several account assignment objects (for example, you can distribute the costs for an item to several orders or cost centers). The system updates the purchase order commitment on the corresponding account assignment objects accordingly.

This means that in the XEKBP, there will be a sentence for each account with different ZEKKN information.

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

8.1 Invoice Behavior

On invoices documents it’s possible to change the account provided. 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).

Values from unplanned accounts are distributed among the planned accounts in “Follow in a row” way.

In the case of multiple account assignment, you can distribute the total amount of partial invoices among the individual accounts in two ways ( EKPO-TWRKZ - Partial invoice indicator ) :

  • On a progressive fill-up basis (Following Row)
  • On a 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.

Example

100 pieces of a material have been ordered 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:

Cost Center

Ordered

Proportional

Progressive Fill-Up

A

50 PC

350 USD

500 USD

B

40 PC

280 USD

200 USD

C

10 PC

70 USD

0 USD

Total

100 PC

700 USD

700 USD

 

8.1 Goods receipt Behavior

On goods receipt documents it’s not possible to change the account information. The sentences in EKBE (for non-service items) have the field ZEKKN = ‘0’ and the quantities and values are distributed among the accounts in a progressive fill-up way.

9. Structures

9.1 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.

9.2 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.

10. Tables

10.1 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.

11. Interface RWIN

The RWIN is SAP’s standard accounting interface in R/3. A sender application notifies multiple receiver applications about a document that might have an impact in accounting. The sender application can be any R/3 component; the receiver 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).

Total reduction of commitments by ELIKZ / EREKZ / LOEKZ

If the commitment reduction takes place with goods delivery and the flag 'final delivery' (ELIKZ) is set in the order item, then the commitment will be completely reduced (set to zero).  The same applies with commitment reduction via invoice with the flag 'final invoice' set (EREKZ).

When a position has been deleted (LOEKZ), the corresponding commitments are also deleted.

12. Function Modules

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.

14. BADI’s

 

From 47.0 release, there are some BADI available that activate some 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

13. COOI

This the database table on CO side which controls the commitments:

COOI - Commitments Management: Line Items

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

WTGBTR - Total value in object currency

BUDAT - expected debit date (delivery date)

Please note that fields that begin with ‘ORG’ (original), represents the committed values. Fields beginning with ‘W’ represents 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.

14. TRANSACTIONS

KS02 – transaction for cost center commitments

CUNI – Unit of measure.

OKKP – commitments management

15. Useful reports/tools in Commitment Management

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

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.)

CJEN:

Reconstruction of the project information database.

RBPFCON1/RBPFCPN1:

Reconstruction of availability control.

Related Content

Related SAP Notes/KBAs

SAP Note: 355793 Note:qty-based reductn of purchase requistn commtmt

SAP Note: 639523 Commitments reduction behavior for Purchasing

SAP Note: 534993 Short instructions RKANBU01

SAP Note: 152571 Composite Note: Missing or Incorrect Commitments- CO side

SAP Note: 670489 commitments for delivery costs

2 Comments

  1. I was not able to find Badi MEPOBADI_CHOICE_OBLIGO.

    Excellent summary, anyhow.

  2. Former Member

    Thank you, useful  document