Show TOC

Create New Fields (Using Condition Technique)

Modififying the condition technique

Since many functions of the SD System are based on the condition technique, system modification is closely related to the condition technique. In Sales and Distribution, this technique is used in pricing, output control, account determination, listing, exclusion and substitution, to determine a price or an output category, for example. The following elements are relevant for the modification of the system:

For each application, all fields allowed for accessing condition records are combined in particular communication structures. Thus, communication structures contain all data fields that can be used for accessing condition tables.
The communication structures KOMK (header fields) and KOMP (item fields), for example, contain all fields that are used to access condition tables in the area of pricing. The fields in the communication structures will be referred to as source fields.
When you create a condition table, you define one or more fields as table keys. A Condition table contains all fields on which the determination of a price or an output can depend. All fields that have been selected for a condition table in the area of pricing can be used for the determination of a price. The condition types and the corresponding condition records are based on the selected key fields. The fields in the condition tables will be referred to as target fields.
The access sequence constitutes the link between the communication structure and the condition table. Target and source fields control each individual access . Target fields are the fields that appear in the condition table and in the corresponding condition records. The source fields are the corresponding document fields, from which the system pulls the data using the condition technique. Each access of an access sequence applies to a condition table and can search for valid condition records based on the fields (the key) defined in this table. The access sequence contains the keys of the condition tables in the sequence in which the individual accesses are carried out.

For a detailed description of the condition technique see the "SD Guide to Pricing and Conditions" or the "Pricing" chapter of the Implementation Guide.

Basics of the System Modification

As mentioned above, the communication structures contain source fields used for accessing a condition table. If you want to add data fields to a function, the new fields must be available as key fields for the creation of condition tables and must be included in the respective communication structures.
The following overview lists all communication structures relevant for the modification of the system according to function:
For the sake of showing the full range, communication structures of applications are named here that are not used by the condition technique
KUAGV, KUWEV, KUREV, KURGV
In all communication structures INCLUDES in which you enter new data fields are integrated. They are protected and cannot be overwritten during a release changeover.
User exists are FORM routines that are called up to supply
communication structures or fields. Customer-specific modifications are carried out in the user exists which are located in parts of the program protected by SAP.
Table T681 defines the allowed fields for the condition tables for each application and as well as in which application a field is to be used. Depending on the allocation of fields to the individual applications, only a selected number of fields is available for the creation of a condition table. A field can be assigned to more than one application.

Creating New Data Fields in a Communication Structure

Data fields are created in the Data Dictionary. You create data elements and fields in the Data Dictionary as well as integrate them in the relevant structures. Use following check list when you create new data fields:

1. Check whether an identical data field already exists in the standard system
Remember that new data fields must begin with the letter "ZZ" or "YY" because SAP has selected this name convention to protect modifications of the customer during a release changeover. Create a new domain for the new data element.
2. Using the source tables, check wether the field is used at header or at item level, which determines the structure in which the field is included. The source tables are listed in the section "Supplying Fields Within the Communication Structure and Using Them in Condition Tables" below.
The order reason, for example, is included in table VBAK, the product hierarchy in table VBAP.
3. Integrate the field in the appropriate communication structure by means of an INCLUDE.
For pricing, for example, you include header fields in KOMKAZ, item fields in KOMPAZ: For the field name enter the field description new fields and make sure that they begin with ZZ or YY. For example, enter ZZAUGRU, ZZPRODH, and ZZVRTZ1 and assign them to the SAP data element AUGRU, or the new data elements you have just created ZZPRODH1 and ZZVRTZ1.
The description of the individual functions will inform you about the structures into which the fields must be integrated.
4. Activate the structure.
5. Include a new field in table T681 and allocate it to the application in which is to be used.
Example
A new field for pricing, has the allocation A, V, 001.

Supplying Fields Within the Communication Structure and Using Them in Condition Tables

The fields included have to be supplied in such a way that they are filled with the required document fields when the document is processed. Each routine of the individual application contains user exits defined for that specific purpose. The description of the individual functions informs you about the members contained in each user exist.

To supply the fields, proceed as follows:

1. Check in which source table the document field is found.
VBUK SD document: Header status and administrative data
VBAK Sales document: Header data
VBKD Sales document: Business data
KUWEV Ship-to party view of customer master
KURGV Payer view of customer master
KUREV Bill-to party view of customer master
KUAGV Sold-to party view of customer master
TVAK Sales documents: Types
TVTA Organizational unit: Sales areas
VBAP Sales document: Item data
VBAPD Dynamic part: Order items
TVAP Sales documents: Item types
VBRK Billing document: Header data
KUWEV Ship-to party view of customer master
KURGV payer view of customer master
KUREV Bill-to party view of customer master
KUAGV Sold-to party view of customer master
VBKD Sales document: Business data
VBAK Sales document: Header data (for creation, not for change)
VBRP Billing document: Item data
VBAP Sales document: Item data (only for creation)
2. Supply the new field by means of a MOVE command in the defined user exit.
Beispiel
The routines for the supply of the new fields in order processing are found in member MV45AFZZ. The MOVE command for the supply of the new
field ZZAUGRU would be:
FORM USEREXIT_PRICING_PREPARE_TKOMK.
MOVE VBAK-AUGRU TO TKOMK-ZZAUGRU.
ENDFORM.
3. In table T681F allocate the new field to the usage and the application area, in which it is to be used.

Test of the Changes Carried Out

To test the changes carried out, proceed as follows:

1. Create a new condition table.
For partner determination you might be able to use condition tables already existing and do not need to create new ones.
2. Create a condition type.
3. Create a pricing procedure.
4. Assign the condition type(s) to a procedure.
5. Create an access sequence.
6. Create condition records for the condition type
7. Create a sales order and check whether pricing was carried out according to your changes.
In case pricing did not lead to the expected results you can use the pricing analysis to search for the possible errors.