Skip to end of metadata
Go to start of metadata

Purpose 

This is to provide clarity and guidance about how data is being determined from reference documents during a Purchase Order input.

Overview 

In many cases a Purchase Order is created by having multiple reference documents.

In these cases, there can be an uncertainty; from which reference document the logic copied the given data (field) to the header or item.

These documents can be:

  • Purchase Requisition
  • Purchase Order
  • Contract or Agreement
  • Purchasing Info Record
  • Material Master
  • Vendor Master

This behavior can be analyzed by checking the technical name of the given header or item field using the F1 key and navigating to the technical details.  

Then navigating to the header or item include:

For header fields this is the include: LMEPOF00.

For item fields this is the include:  LMEPOF7X.

The next step is to find the right Form.

This can be found by searching with the technical name of the field, based on the form name.

Here most of the forms have the following logic:

  1. A check to determine if anything important was modified in the Purchase Order.
  2. A determination of the right reference, based on the incoming data.

 

The logic checks if the PO is created from a reference document, if so, then the data is taken from the reference document.

If the PO isn’t created from copy, then the logic checks if it has a contract reference, then the info record reference, then the material master.

There are fields which can take values from the vendor master if there are no other references.

Once the technical name of the field is known, the right form can be found in the include, to check the standard determination.

The following table displays the used information sources.


Structure

Name

REKKO REKPO

Reference Purchase Order data

REBAN

Reference Purchase Requisition data

KEKKO KEKPO

Reference Contract/Agreement data

LFM1

Vendor Master data

EINE

Inforecord data

AEKKO 

Reference RFQ

Header Example

The Payment Term has the technical name: ZTERM and it is a header field, hence the relevant form can be found in the include: LMEPOF00.

Then by entering the Form, the determination of the Payment Term can be analyzed.

The determination logic can be seen in the form, which for the payment term is to get the data from the reference PO, contract, RFQ (if the document has ZTERM), inforecord and last from the vendor master.

Item Example

The unit of measure in a PO item has the technical name MEINS.

Hence with the same steps we can find the right form in the include LMEPOF7X.


Inside the form, there is a similar determination logic as it were in the payment terms form.

The code checks if anything important has changed then checks the reference document data.

This logic is a bit more complex, as the unit of measure can be different for a Stock Transport scenario and an item can also have material ID.

Enhancement

If the business requirement is to have a different behavior, then the BADI ME_PROCESS_PO_CUST can be used.

After the determination a custom code can be implemented in the BADI to change the Header or Item data of the PO to the required value, based on the given reference.

To do this, use the relevant Methods of the BADI: PROCESS_HEADER, PROCESS_ITEM.

Related Content 

Related SAP Notes/KBAs

KBA: 2895840 - Unit of measure conversion factors adoption to PO

KBA: 2634969 - ME21N - Payment terms is copied from PO but not contract

KBA: 2633613 - Payment terms not redetermined when creating a PO from a reference

  • No labels