Enhancing Output Determination

Enhancing Output Determination
Technical Solution Guide
The Smith Consulting Group, Inc.

PO Box 703
Flanders, NJ 07836-0703
973-713-5846
SAPtechsolutions.com
SAP and R/3 are the trademarks or registered trademarks of SAP AG in Germany and in several other countries.
Copyright © 2004 The Smith Consulting Group, Inc. All Rights Reserved.
Enhancing Output Determination ............................................................................................. 3
Condition Usage Code .............................................................................................................. 3
Application Area....................................................................................................................... 4
Application Areas Relevant for Output Determination ........................................................ 4
Communication Structures........................................................................................................ 6
Communication Structures by Application Area.................................................................. 8
The Field Catalog.................................................................................................................... 10
Field Catalog Structure ....................................................................................................... 10
Maintaining the Field Catalog ............................................................................................ 12
Building Condition Tables.................................................................................................. 14
Processing Function Modules ................................................................................................. 15
Relevant OSS Notes................................................................................................................ 15
Process Flow ........................................................................................................................... 15
Step 1 Filling the Header Structure................................................................................ 17
Step 2 Call Function COMMUNICATION_AREA_KOMKBV1 ................................ 18
Step 3 Call Function KOMKBV1_FILL ....................................................................... 19
Step 4 Filling the Item Structure .................................................................................... 20
Step 5 Call Function COMMUNICATION_AREA_KOMPBV1................................. 21
Step 6 Call Function KOMPBV1_FILL ........................................................................ 22
Step 7 Call Function MESSAGING .............................................................................. 23
Sales Order Confirmation Output Enhancement Example ..................................................... 24
Business Requirement......................................................................................................... 24
Solution ............................................................................................................................... 24
Step 1 Create a new field for use in Output Determination ........................................... 25
Step 2 Make ZZ_RTI_ORDER available to the field catalog ....................................... 27
Step 3 Populating the ZZ_RTI_ORDER indicator ........................................................ 29
Step 4 Adding ZZ_RTI_ORDER to the field catalog.................................................... 31
Step 5 Building the new condition table ........................................................................ 32
Step 6 Adding the new condition table to the access sequence ..................................... 33
Step 7 Creating a Sales Rep customer master................................................................ 34
Step 8 Maintaining the condition record........................................................................ 35
Billing Output Enhancement Example ................................................................................... 37
Business Requirement......................................................................................................... 37
Solution ............................................................................................................................... 37
Step 1 Create a new field for use in Output Determination ........................................... 38
Step 2 Populating the AUART field .............................................................................. 40
Step 3 Build the Requirement Routine .......................................................................... 42
Step 4 Assigning the routine to an output type .............................................................. 44
Step 5 Testing the process.............................................................................................. 45
Step 6 Running the VOFM regeneration ....................................................................... 46
6/19/2005 Page 2 of 47 Technical Solution Guide
Output Determination is one of several functions that use the R/3 condition technique. The
purpose of this document is to demonstrate how to enhance output determination using the
standard user exits built into R/3. In many cases, designing a successful enhancement
requires both functional configuration and program logic. This document explains the user
exit functionality, and then details two sample enhancements taken from actual projects. The
examples were built on a 4.6C system.
Thisdoc ume nta ssumest ha

tt hereade runde
rst
andst
hec
ondi
ti
ont
echni
quea
ndi
t’
s
configuration for Output Determination.
Condition Usage Code

The condition technique is used in several areas of SD (Pricing, Output Determination, etc.).
All of these areas share the same functions and programs for maintaining condition records,
etc. To differentiate between these areas, the Condition Usage Code is used. The condition
technique for output determination is identified viaus agec ode‘ B’ .Ma nyoft heobj ects
related to output determination contain this code in either the object name or as a high order
key in configuration tables. For example, building condition table 900 in output
determination creates a physical table name B900. In pricing, where the condition usage code
is‘A’ ,thephy sicalt ablena mei sA900.
Application Area
The Application Area subdivides the condition usage of the condition technique (for
example, sales order, billing, purchase order). The communication structures and processing
functions for output determination are built separately for each application area. Table
T681A contains all application areas defined in R/3. Table T681Z contains the subset of
those application areas that are relevant for output determination. The following list is from
T681Z.
Application Areas Relevant for Output Determination
Area Description
CF Error control
CV Document administration
DB Customers
E1 Inbound delivery
EA Purchasing RFQ
EF Purchase Order
EL Purchasing Scheduling Agreement Release
ES Data entry sheet
EV Purchasing Outline Agreement
K1 Sales activities
M1 Rough Goods Receipt
MD Direct buying
ME Inventory management
MR Invoice verification
NF Nota fiscal
P1 Direct Manufacturing
PA JIT call
RS Automotive
V1 Sales
V2 Shipping
V3 Billing
V4 Shipping (Special case)
Area Description
V5 Groups
V6 Handling units
V7 Transport
W0 All. table Group
W1 Sales promotion group
WA Allocation table
WB Retail promotion
WE Labeling
WN Free Sett. Rel. Del.
WR Agency Business
WS Free Sett. Agreement
WT Trading contract
Communication Structures
R/3 uses work areas called communication structures to pass data from the calling
application to the output determination functions. There are separate structures for header
and item data (when relevant). In many cases, the communication structures contain special
includes for customer specific enhancements. Only these special includes should be modified
by the customer. The following example is the delivery header communication structure. The
first screen displays the top portion of the structure.
Towards the bottom of the structure, the include for customer enhancements is found
(KOMKBZ4). These includes always contain the field DUMMY. This field exists because in
earlier versions of R/3, the data dictionary did not allow structures that contained no fields.
SAP put the DUMMY field into these structures just to get around this requirement. When
customer specific fields are added to these structures, the DUMMY field should be deleted.
On several occasions, we have seen programmers actually leave the DUMMY field as is, but
use it as an indicator for some purpose. We strongly recommend that this practice not be
used. If a field is required, it should be created with a relevant name and data element.
Communication Structures by Application Area

Table T681Z contains the communication structure names for each application area. The
name usually corresponds to the application area, but there are exceptions. Notice in the
following list that application areas EA and EF use the same header structure.
Area Header Structure Item Structure

CF KOMKBCF
CV KOMKBCV
DB
E1 KOMKBE1
EA KOMKBEA
EF KOMKBEA KOMPBEA
EL KOMKBEA
ES KOMKBES
EV KOMKBEA
K1 KOMKBK1
M1 KOMKBM1
MD KOMKBMD
ME KOMKBME KOMPBME
MR KOMKBMR KOMPBMR
NF KOMKBNF
P1 KOMKBP1
PA KOMKBPA
RS KOMKBRS
V1 KOMKBV1 KOMPBV1
V2 KOMKBV2 KOMPBV2
V3 KOMKBV3 KOMPBV3
V4
V5 KOMKBV5
V6 KOMKBV6
V7 KOMKBV7
W0
Area Header Structure Item Structure
W1
WA KOMKBWA KOMPBWA
WB KOMKBWB KOMPBWB
WE KOMKBWE
WN KOMKBWN
WR KOMKBWR KOMPBWR
WS KOMKBWS
WT KOMKBWT KOMPBWT
The Field Catalog

The field catalog is a configuration table (T681F) that contains all fields that can be used as
key fields when building condition tables. When the field catalog is maintained, the available
field list is based on the fields contained in the field catalog structure.
Field Catalog Structure

There are separate field catalogs for each condition usage code. For output determination, the
field catalog structure is KOMB. Like the communication structures, the field catalog
structure contains an include for customer specific fields (KOMBZ).
In this example, the KOMBZ include has been modified with several new fields. The
DUMMY field was removed.
Maintaining the Field Catalog

The field catalog maintenance transaction is found next to the corresponding condition table
maintenance transaction in the IMG. Although the field catalog transaction is listed second, it
is processed first.
The field catalog maintenance program is a standard SM30 screen that maintains table
T681F. All field catalogs used in the condition technique are contained in T681F. The high
order keys of this table are the condition usage code and application area. Since this
transaction maintains the field catalog for sales orders, the T681F entries maintained are from
condi t
ionus ag ec ode‘ B’a nda ppl i
c at
iona rea‘V1’ .Whi l
ea ddi
ngf ields,theva lidf ie
ldl ist
consists of the fields in the field catalog structure (KOMB).
Building Condition Tables

When building condition tables, the available fields in the right pane, are the fields from
T681Fint hec orres
pondi ngc ondi tionus a gea nda pplic at
iona r
e a.(‘
B’ ,‘V1’ ).
Processing Function Modules

There are two main function groups used for output determination. V61B contains the main
functions that enable output determination. VCOM contains functions and user exits for
filling the communication structures with document data from the calling programs.
Relevant OSS Notes

The following OSS notes may be helpful in understanding output determination
enhancements.
Note Description
32662 User name added to new condition table
39462 Expand field catalog in message determination
159684 Not all fields are displayed in condition table
Process Flow
The following diagram and screen shots illustrate how the processing functions are called
using sales order output as an example.
Program SAPMV45A
Global Data Area Calls Function COMMUNICATION_AREA_KOMKBV1

passing sales order data.
Calls Function COMMUNICATION_AREA_KOMPBV1

passing sales order data.
XVBAK
XVBAP Calls Function MESSAGING.
XVBPA
Function Group V61B
Global Data Area Function Modules
FUNCTION COMMUNICATION_AREA_KOMKBV1
Receives sales order data.

KOMKBV1 Calls Function 'KOMKBV1_FILL' passing sales order data.
Updates KOMKBV1 work area.
FUNCTION COMMUNICATION_AREA_KOMPBV1

KOMPBV1
Calls Function 'KOMPBV1_FILL' passing sales order data.
Updates KOMPBV1 work area.
FUNCTION MESSAGING
Executes the condition techniique routines for output
determination using the filled data areas.
Function Group VCOM
Global Data Area Function Modules
FUNCTION KOMKBV1_FILL

KOMKBV1 Populates KOMKBV1 with sales order header data.
Performs USEREXIT_KOMKBV1_FILL.
Updates KOMKBV1 work area.
FUNCTION KOMPBV1_FILL

Populates KOMKPV1 with sales order item data.
KOMPBV1 Performs USEREXIT_KOMPBV1_FILL.
Updates KOMPBV1 work area.
Form Routines
FORM USEREXIT_KOMKBV1_FILL.
* ........
END FORM.
FORM USEREXIT_KOMPBV1_FILL.
* .......
END FORM.
Step 1 Filling the Header Structure

Function COMMUNICATION_AREA_KOMKBV1 is called. All of the relevant order data
is passed to the function module (VBAK, VBUK, VBPA, VBAP). The function module is
cont ai
ne di nf unc t
iong roupV61B.Thi sf unctiong roup’ sgloba lda
taa
reai
swhe
ret
he
communication structure data is held during the output process.
Step 2 Call Function COMMUNICATION_AREA_KOMKBV1

This function calls the communication structure fill function KOMKBV1_FILL passing the
order data structures. The KOMKBV1 communication structure is returned from the call and
is now completely filled. The structure is defined in the global data area of V61B and will
remain in memory until the output is processed by subsequent function calls.
Step 3 Call Function KOMKBV1_FILL

This function fills the header communication structure. It also calls the user exit routines
associatedwi tht hes tructur
et ype.
Alloft he‘ fill
’func tionsa ndus e rexi t
sa rec ont ai
ne di n
function group VCOM.
Step 4 Filling the Item Structure

After the previous function calls, control has been returned to the sales order program. The
next step is to fill the item structure. Function COMMUNICATION_AREA_KOMPBV1 is
called. The same order data is passed to the function module (VBAK, VBUK, VBPA,
VBAP).
Step 5 Call Function COMMUNICATION_AREA_KOMPBV1

This function calls the communication structure fill function KOMPBV1_FILL passing the
order data structures. The KOMPBV1 communication structure is returned from the call and
is now completely filled. The structure is defined in the global data area of V61B and like the
header structure, will remain in memory until the output is processed by subsequent function
calls.
Step 6 Call Function KOMPBV1_FILL

This function fills the item communication structure. It also calls the user exit routines
associated with the structure type.
Step 7 Call Function MESSAGING

This function triggers the output. It is contained in function group V61B and has access to
the communication structures that were filled by the previous function calls.
Sales Order Confirmation Output Enhancement Example

The following section demonstrates how to enhance output determination using the user exits
provided. Although this is a sales order example, the basic process is the same for all other
output.
Business Requirement
During order entry, the system has been configured to generate an order confirmation using
the standard configuration. The order confirmation is sent to the customer. The company has
introduced a new product line and wants to re-direct the order confirmations to an internal
sales person for all orders that contain at least one of the new products. All of these
confirmations are to be emailed to the same sales person.
Solution
To solve this problem, a new condition table will be added to the access sequence for the
order confirmation. A condition record will be found only if one of the new products is
contained in the order. The table will be positioned first in the access sequence and when
accessed successfully, the remaining tables will not be processed. A field will be created to
denote that one of the new products is present on the order. A user exit will be written to
examine the materials on the order, and set the indicator accordingly.
Step 1 Create a new field for use in Output Determination

For header level sales order output determination, the system uses communication structure
KOMKBV1 to pass order data to the output determination processing routines. In addition to
the standard fields, this structure contains an include for customer defined fields
(KOMKBZ3).
Using the customer modification structure KOMKBZ3, new field ZZ_RTI_ORDER was
added. This field is an indicator that will be set if the sales order contains an item for the
special subset of materials.
Step 2 Make ZZ_RTI_ORDER available to the field catalog

Since we plan to use this field as a key to a condition table, it must be available in the field
catalog for output determination. Structure KOMB contains all fields that are available in the
field catalog. This structure contains an include for customer defined fields (KOMBZ).
Using the customer modification structure KOMBZ, new field ZZ_RTI_ORDER was added.
This field is an indicator that will be set if the sales order contains an item for the special
subset of materials.
Step 3 Populating the ZZ_RTI_ORDER indicator

During order output, the system calls function KOMKBV1_FILL to populate the
communication structures with sales order data. All of the relevant order data is passed into
this function having been read previously. The function calls form
USEREXIT_KOMKBV1_FILL, which is the header level user exit routine.
In this user exit, the new logic loops thru the items (COM_VBAP_TAB) and using the
product hierarchy, determines if any of the new products exist on the order. If any are found,
the ZZ_RTI_ORDER indicator i ssett o‘X’ .
Note that no data base selects are required for this. The most common error made with these
enhancements is the programmer redundantly selecting data that already resides in memory.
Step 4 Adding ZZ_RTI_ORDER to the field catalog

Using transaction V/86, the ZZ_RTI_ORDER field is added to the field catalog for sales
order related output determination.
Step 5 Building the new condition table

Using transaction V/57, condition table 901 is created. The only field in this table will be the
ZZ_RTI_ORDER indicator.
Step 6 Adding the new condition table to the access sequence

Using transaction V/48, condition table 901 is added to access sequence Z002. The table is
inserted as the first table in the sequence. Access Z002 is assigned to the order confirmation
output type.
Step 7 Creating a Sales Rep customer master

At this client, sales reps are defined using customer master records. Order confirmations are
sent via email to a contact person assigned to the customer. Here we defined the contact
person for our special email.
Step 8 Maintaining the condition record.

Using transaction VV11, a single condition record is added to table 901.
Billing Output Enhancement Example

The following section demonstrates how to implement a requirement routine to prevent
condition access in output determination. Although this is a billing document example, the
basic process is the same for all other output.
Business Requirement
Thec ustome rha sde finedas pe cial‘Noc ha rge’or dertypet hatisused to ship sample
products. For these orders, billing output is to be suppressed. The billing type associated with
these orders is the standard F2.
Solution
To solve this problem, an output requirement routine will be coded and assigned to the output
type within the relevant output determination procedure. Within this routine, we need to
examine the sales order type associated with the invoice. Unfortunately, the order type is not
included in the communication structures used for billing output. Therefore, a user exit will
be coded to provide it.
Step 1 Create a new field for use in Output Determination

For header level billing output determination, the system uses communication structure
KOMKBV3 to pass order data to the output determination processing routines. In addition to
the standard fields, this structure contains an include for customer defined fields
(KOMKBZ5).
Using the customer modification structure KOMKBZ5, the order type field AUART was
added.
There are many who debate whether or not a standard field name (i.e. AUART) should be
specifiedi naus ere xitstruc t
ure.Eve nSAPwoul dproba blyre comme ndus inga‘ Z’f ield( i
.e.
ZZAUART). They will argue that if SAP were to add the standard field in a future release, a
syntax error would result. While true, we feel that ending up with redundant fields is worse
than fixing a syntax error. To correct the error would simply require that the field be deleted
from the user exit structure.
Step 2 Populating the AUART field

During billing output, the system calls function KOMKBV3_FILL to populate the
communication structures with billing document data. All of the relevant billing data is
passed into this function having been read previously. The function calls form
USEREXIT_KOMKBV3_FILL which is the header level user exit routine. For this project,
we need to add the sales order type. Since order information is not passed into this function
module, we will need to select it in our user exit.
In this user exit, the new logic determines the sales order type and moves it to the
KOMKBV3 communication structure.
Step 3 Build the Requirement Routine

Using transaction VOFM, create the requirement routine. The standard SAP routine is
number 062. We cloned it to 962.
One line of code was added to each form routine to check the sales order type. When it is
ZNC, the return code will be set to 4 and the output will not be sent.
Step 4 Assigning the routine to an output type

Using transaction V/42, assign the new requirement routine to the relevant output types in the
output determination procedure.
Step 5 Testing the process

Below is the output determination process log of an invoice that originated from a ZNC
order. The output was not sent due to requirement 962.
Step 6 Running the VOFM regeneration

Whenever a VOFM routine is created, a special generation program should be run in each
system that the routine is moved to. The program is usually executed by the Basis Team.
Note: This is a critical step that should not be overlooked. If this step is not executed, short
dumps can be the result.
The RV80HGEN completed.

Enhancing Output Determination

Uploaded by

Copyright:

Available Formats

Enhancing Output Determination

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enhancing Output Determination

Uploaded by

Copyright:

Available Formats

Enhancing Output Determination

Technical Solution Guide

The Smith Consulting Group, Inc.

6/19/2005 Page 2 of 47 Technical Solution Guide

Thisdoc ume nta ssumest ha

Condition Usage Code

6/19/2005 Page 3 of 47 Technical Solution Guide

Application Areas Relevant for Output Determination

6/19/2005 Page 4 of 47 Technical Solution Guide

6/19/2005 Page 5 of 47 Technical Solution Guide

6/19/2005 Page 6 of 47 Technical Solution Guide

6/19/2005 Page 7 of 47 Technical Solution Guide

Communication Structures by Application Area

Area Header Structure Item Structure

6/19/2005 Page 8 of 47 Technical Solution Guide

6/19/2005 Page 9 of 47 Technical Solution Guide

The Field Catalog

Field Catalog Structure

6/19/2005 Page 10 of 47 Technical Solution Guide

6/19/2005 Page 11 of 47 Technical Solution Guide

Maintaining the Field Catalog

6/19/2005 Page 12 of 47 Technical Solution Guide

6/19/2005 Page 13 of 47 Technical Solution Guide

Building Condition Tables

6/19/2005 Page 14 of 47 Technical Solution Guide

Processing Function Modules

Relevant OSS Notes

6/19/2005 Page 15 of 47 Technical Solution Guide

Global Data Area Calls Function COMMUNICATION_AREA_KOMKBV1

Calls Function COMMUNICATION_AREA_KOMPBV1

Function Group V61B

Global Data Area Function Modules

Receives sales order data.

Receives sales order data.

Function Group VCOM

Global Data Area Function Modules

Receives sales order data.

Receives sales order data.

6/19/2005 Page 16 of 47 Technical Solution Guide

Step 1 Filling the Header Structure

6/19/2005 Page 17 of 47 Technical Solution Guide

Step 2 Call Function COMMUNICATION_AREA_KOMKBV1

6/19/2005 Page 18 of 47 Technical Solution Guide

Step 3 Call Function KOMKBV1_FILL

6/19/2005 Page 19 of 47 Technical Solution Guide

Step 4 Filling the Item Structure

6/19/2005 Page 20 of 47 Technical Solution Guide

Step 5 Call Function COMMUNICATION_AREA_KOMPBV1

6/19/2005 Page 21 of 47 Technical Solution Guide

Step 6 Call Function KOMPBV1_FILL

6/19/2005 Page 22 of 47 Technical Solution Guide

Step 7 Call Function MESSAGING

6/19/2005 Page 23 of 47 Technical Solution Guide

Sales Order Confirmation Output Enhancement Example

6/19/2005 Page 24 of 47 Technical Solution Guide

Step 1 Create a new field for use in Output Determination

6/19/2005 Page 25 of 47 Technical Solution Guide

6/19/2005 Page 26 of 47 Technical Solution Guide

Step 2 Make ZZ_RTI_ORDER available to the field catalog

6/19/2005 Page 27 of 47 Technical Solution Guide