Transaction VOFM is a tool that was developed in R/3 to facilitate the definition of both SAP
delivered as well as customer defined routines / rules used in the system during various business
processes. VOFM routines are ABAP code written in Forms. VOFM provides the user with the
benefit of choosing from one of the standard delivered R/3 routines or writing their own. VOFM is
intended for the implementation team when configuring the system. It is not intended for the end
VOFM is divided up into four main areas. These include copying requirements, data transfer,
requirements, and formulas. This paper will focus on requirements that were delivered by SAP to
support the Sales & Distribution (SD) and Logistics Execution (LES) applications. At a high level,
requirements are rules that determine when a particular action should take place. For example, a
pricing requirement defines the circumstances under which an access to a particular type of pricing
record is made. Likewise, a material determination requirement specifies when a material
determination record should be accessed. Requirements are a great tool to aid system performance
by defining rules that eliminate unnecessary accesses to the database. They can also be used to set
certain variables in the coding, or even to call other programs.
2. Creating a New VOFM Requirement
In each area of VOFM, SAP delivers routines using the name space from 1 to 599. SAP customers
can create their own VOFM routines using the name space from 600 to 999. To create a new routine,
follow these steps:
1. First check to see whether you can use one of the requirements delivered in the standard system.
2. Either overwrite an existing requirement or enter a new number on a new line from the customer
name space 600 to 999. Also enter a short description of your requirement.
3. Program your requirement in the ABAP editor.
4. Activate the program.
5. Enter the application if you want to use the requirement in one particular application area. For
example, you have defined a new requirement for Output control that is only relevant for
6. Enter your new requirement in the appropriate area in customizing. For example, a new pricing
requirement could be assigned to a pricing procedure or access sequence. As another example,
credit check requirements would be assigned in customizing to the automatic credit controls.
Pricing requirements are typically used to define when an access should be made in pricing. They
can be assigned to a condition type in a pricing procedure or to an individual access in an access
sequence. An access will only be made if the requirement is met. Using requirements can improve
performance by eliminating unnecessary accesses to the database.
When pricing is carried out for a sales document, the system processes the pricing procedure one step
at a time. For example, the user may have listed condition type PR00 first to determine the price. If
a requirement has been assigned to PR00 in the pricing procedure, the system will check to see if it is
met. If it is met, the system continues to look for prices using the assigned access sequence. If it is
not met, the system skips that condition type and goes to the next level of the pricing procedure. The
same holds true for the individual levels of the access sequence. If a requirement is assigned, the
access is only made if the requirement is met.
When looking at the code for the standard delivered pricing requirements or when writing your own,
two common work areas are used. These include:
KOMK – Pricing communication structure containing header related fields from the sales document.
KOMP – Pricing communication structure containing item related fields from the sales document.
Following is a description of the pricing requirements delivered in the standard system related to SD