Sap Modules >
The sensitive fields in the customer/vendor master records which are controlled using dual control are defined in the Customizing table T055F.
Make the settings in IMG > Financial Accounting > Accounts Receivable and Accounts Payable > Customer Accounts > Master Records > Preparations for Creating Customer Master Records > Define Sensitive Fields for Dual Control (Customers)
Define Sensitive Fields for Dual Control (Customers)
In this activity you define the fields for dual control in the customer/vendor master records.
If you define a field in the customer/vendor master record as "sensitive", the corresponding customer/vendor account is blocked for payment if the entry is changed. The block is removed when a second person with authorization checks the change and confirms or rejects it.
The alternative payee field has been defined as sensitive in the Customizing table. If the accounting clerk responsible changes the entry in this field in the customer/vendor master record, the account is blocked for the payment run until a second person with authorization confirms the change to the master data.
Define the required fields as sensitive. You can choose the fields using the possible entries button.
You must be authorized to change master records. You also define authorizations in Customizing (IMG) for Financial Accounting. To do so, choose Financial Accounting Â® Financial Accounting Global Settings Â® Maintain Profiles. The person who makes the changes is never allowed to confirm his or her own changes.
You can define the required master data fields as sensitive in Customizing.
When an authorized accounting clerk changes a sensitive field in the customer or vendor master record (such as Alternative payee), the relevant account is automatically blocked for the payment run.
The account remains blocked until a second authorized person confirms the master data changes. However, it is still possible to make a further change to an account that is already blocked.
The second authorized person is informed of the changes by mail or by other means, and then uses the function Master records Â® Confirmation of change Â® Single (or Â® List) to edit the changes.
If the second authorized person cannot confirm the change to the master data, the master data object is returned to the clerk. Where this happens, the reply contains an explanatory text requesting that the clerk alters his or her change, or resets the master data.
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
Sales summary – VC/2
Display Customer Hierarchy – VDH2
Display Condition record report – V/I6
Pricing Report – V/LD
Create Net Price List – V_NL
List customer material info – VD59
List of sales order – VA05
List of Billing documents – VF05
Inquiries list – VA15
Quotation List – VA25
Incomplete Sales orders – V.02
Backorders – V.15
Outbound Delivery Monitor – VL06o
Incomplete delivery – V_UC
Customer Returns-Analysis – MC+A
Customer Analysis- Sales – MC+E
Customer Analysis- Cr. Memo – MC+I
Deliveries-Due list – VL04
Billing due list – VF04
Incomplete Billing documents – MCV9
Customer Analysis-Basic List – MCTA
Material Analysis(SIS) – MCTC
Sales org analysis – MCTE
Sales org analysis-Invoiced sales – MC+2
Material Analysis-Incoming orders – MC(E
General- List of Outbound deliveries – VL06f
Material Returns-Analysis – MC+M
Material Analysis- Invoiced Sales – MC+Q
Variant configuration Analysis – MC(B
Sales org analysis-Incoming orders – MC(I
Sales org analysis-Returns – MC+Y
Sales office Analysis- Invoiced Sales – MC-E
Sales office Analysis- Returns – MC-A
Shipping point Analysis – MC(U
Shipping point Analysis-Returns – MC-O
Blocked orders – V.14
Order Within time period – SD01
Duplicate Sales orders in period – SDD1
Display Delivery Changes – VL22
1-3 of 3