Sap Modules >
SAP SD
Define Sensitive Fields for Dual Control (Customers)
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. Example 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. Activities 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. Features 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. |
Creating a New VOFM Requirement
1 Overview 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 user. 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 deliveries. 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. 3. Pricing 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 and LES |
| Attachments:
VOFMRequirementRoutines.pdf
Standard SAP SD Reports
|
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