Standard SAP SD



Partner Determination in SAP Sales and Distribution
Overview
This a procedure by which system selects the assigned sales relevant partner function/functions to
the object in Order to Cash process.
In brief, sales partner are business parties which are involve/relevant to a sales
process/transaction. Each partner are defined/identified based on role & function they play in
those sales process/transaction. These can internal or external to an organization. To setup,
determine & copy these business partners in a sales process or specific sales process or master in
SAP SD, we use a search technique, known as Partner Determination.
Main Components in Partner Determination
1 Partner Function
2 Customer Account Group
3 Partner Determination Procedure
Partner Object
Following are the Partners object with respective key area for which partner determination can
take place-
• Customer
• Sales Document Header
• Sales Document Item
• Delivery Document
• Shipment Document
• Billing Document Header
• Billing Document Item
SPRO path/Transaction Code
Transaction VOPAN / VOPA
Code
SPRO Path Sales and Distribution - Basic Functions - Partner Determination - Set Up Partner Determination

Configuration Steps
Let us go through the configuration steps involved in partner determination. Here we would take
focus on partner determination for a customer master.
Existing Sales Partner in Customer Master Determination:
Partner Function Languag Name Language-specific
e Partner Func.
AG EN Sold-To SP
Party
RE EN Bill-to Party BP
RG EN Payer PY
WE EN Ship-to SH
Party
The following are the steps involved in adding a new partner type, say, JP, for customer master
for partner determination:
Step 1. Partner Functions
Maintain a new partner function, JP, under partner function node with respective partner type
(KU for Customer, LI for Vendor) & indicator for Uniqueness in the master data.

Step 2. Assigned Partner Function to Account Group

Assigned newly created partner function JP to corresponding account group of your desire.
Step 3. Create Partner Determination Procedure
Select partner determination procedure if your requirement is met. Otherwise copy existing
Partner determination procedure.

Step 4. Maintain relevant Partner to determine under Partner

Determination Procedure
Under partner determination procedure sub-dialog, you assign required partners to partner
determination procedure. Here you specify whether the assigned partner can be:
• modified in object or not
• whether it is mandatory
• sequence in which partners are determined (may differ with object).

Step 5. Assign Account Group to Partner Determination Procedure

Assign Partner determination procedure to account group. It is assumed that required account
groups are available in the system.

In case of other objects same procedures can be followed. It differs at step 5, where you assign
partner determination procedure to respective object.
Partner Object Partner Determination
Procedure assigned to
Customer Customer Account Group
Sales Document Header Sales Document Type
Sales Document Item Item Category
Delivery Delivery Type
Shipment/Transportatio Shipment Type
n
Billing Header Billing Type
Billing Item Billing Type



Route Determination In Sales Order
Determination
Route is determined automatically in the sales order based on:
1. Departure zone or country of the delivering plant.
2. Destination zone or country of the Ship to Party.
3. Shipping condition from the customer master.
4. Transportation group from the material master.
5. Weight Group.

Configuration
Follow this:
Step: 1 - Define Modes of Transport
Path: SPRO - Logistics Execution - Transportation - Basic Transportation Function - Routes -
Define Routes - Define Modes of Transport.
Step: 2 - Define Shipping Types
Path: Under the Same Menu path - Define Shipping Types
Select New Entries and Assign the Shipping Type (e.g. Road or Train) and Assign Mode of
Transport (Mdtr) and Assign Shipping type Procedure group.
Step: 3 - Define Transportation Connection Point
Path: Under the Same Menu path - Define Transportation Connection Point.
Step: 4 - Define Routes and Stages.
Path: Under the Same Menu path - Define Routes and Stages.
Select the New Entries and Enter the Details
Then Select the Routes stages and define
Step: 5 - Maintain Stages for all Routes.
Path: Under the Same Menu path - Maintain Stages for all Routes.
ROUTE DETERMINATION
Step: 6 - Define Transportation Zone
Path: SPRO - Logistics Execution - Transportation - Basic Transportation Function - Routes -
Route Determination - Define Transportation Zone.
Step: 7 - Maintain County and Transportation Zone
for Shipping Point.
Path: Under the Same Menu path - Maintain County and Transportation Zone for Shipping Point.
Select the Shipping point and enter the Country and Transportation Zone
Step: 8 - Define Transportation Groups.
Path: Under the Same Menu path - Define Transportation Groups
Step: 9 - Maintain Route Determination
Path: Under the Same Menu path - Maintain Route Determination.
Go to Customer master data.
In Address of General data. Enter the Transportation Zone id. and save
You will get the route.
The system takes into account the following 4 conditions for determining the Route
a.) The country and the Departure Zone of the shipping point
b.) Shipping Conditions agreed in the sales document type or with the sold to party
c.) Transportation Group assigned to the material
d.) The country & Transportation Zone of the ship to party (in CMR)
Route can be manually overwritten during a sales order processing. You can re-determine the
route in the outbound delivery based on weight (weight group) provided it is allowed in the
configuration of the delivery type.
Scheduling takes into account the following times -
a.) Transit Time
b.) Loading Time
c.) Pick/Pack Time
d.) Transportation Lead/Planning Time.
The loading time and pick/pack time come from the shipping point whereas the transit time
and transportation lead time come from the route.
The system performs backward scheduling first to confirm the required quantity checking the
material availability on the material availability date. If the material availability date or the
transportation planning date falls before the order date, the system automatically carries out
forward scheduling and will propose a future date. A delivery type can be customized to carry out
rescheduling if required during the delivery processing.




Output Determination Using Condition

Technique
Overview
Outputs are an essential media of communication with various business partners & internal
partner within the organization during or for sales processing. These output can be either be taken
as print on paper or generated PDF files or sent by mails/electronically. You can even restrict or
allow the trigger of these output.
Output determination using condition technique majorly defines 3 functions:
1. Automatic determination of output in respective object.
2. Processing of output based on some events.
3. Respective parameter/medium for print.
So, output types are assigned to
4 Partner functions,
5 Transmission media and
6 Dispatch time.
You need to co-ordinate with ABAPers for output processing program and form.
Output determination is carried out through condition technique in Sales and Distribution.
Applicatio Keys Area
n
V1 Sales
V2 Shipping
V3 Billing
V6 Handling
Units
V7 Transport
Types of Output
• Print Output,
• Fax,
• Telex,
• E-Mail
• EDI (Electronic Data Interchange)
Output Determination
Output is determined using condition technique.
Output can be determined from customer master, but it is recommended that Output in sales
document through output determination procedure(Condition technique). Output can be
determined separately for Sales Document: Header and Sales Document: Item level.
Unlike any other determination procedure getting determined through condition technique. The
output determination also involves,
• Condition Table
• Access Sequence
• Condition Types
• Output Determination Procedure
• Output Determination Procedure Assignment

1.) Condition Table

TCode V/57
SPRO IMG - SD - Basic Function - Output Control
Path - Output Determination using Condition Technique
- Output Determination for Sales Documents
- Maintain Condition Table
You have to define combination of fields for which you want condition records in condition
tables of output. Provided existing standard condition tables does not meet your requirement. In
case of new condition table enter name of condition table, the number of table must be starting
from 900. Select the fields for table from allowed fields and generate new condition table.

2.) Access Sequence

SPRO IMG - SD - Basic Function - Output Control
Path - Output Determination using Condition Technique
- Output Determination for Sales Documents
- Maintain Access Sequence

You have to define new access sequence by copying existing one and change to your
requirement, provided standard access sequence does not meet you requirement. It is search
strategy which system uses to find out condition records stored in condition tables for condition
types. Unlike pricing, all output type has access sequence. Therefore, you maintain output
condition record for all output types.
3.) Output Types
TCode V/30
SPRO IMG - SD - Basic function - Output control
Path - Output determination using condition technique
- Output determination for sales documents
- Maintain Output Types
You have to define new Output types by copying existing one and change to your requirement,
provided standard output type does not meet you requirement.
• Languages of Output
• Print Program: print specification
• SAP Script: layout
• Partners (to whom you need to send output)
• You need to mention Partner function wise Output type.
3.1.) Assign Output types of Partner Function
SPRO IMG - SD - Basic Function - Output Control
Path - Output determination using condition technique
- Output determination for Sales documents
- Assign Output type to Partner Function

Here you assign Output types to desired Partner function like SP/SH/PY etc.. Generally that
would be the intent recipient of that output type.
4.) Maintain Output Determination Procedure
SPRO IMG - SD - Basic function - Output control
Path - Output determination using condition technique
- Output determination for sales documents
- Maintain Output determination procedures

You have to define new Output determination procedure by copying existing one and change to
your requirement, provided standard output determination procedure does not meet you
requirement.

5.) Assign Output Determination Procedure

TCode V/43
Assign Output determination procedure to Sales document header level
TCode V/69
 Assign Output determination procedure to Sales document item category
SPRO IMG - SD - Basic Function - Output control
Path - Output determination using condition technique
- Output determination for sales documents
- Assign Output determination procedures
You need to assign output determination procedure to Sales document. You may assign as per
your requirement Header level and item level.
Similar steps could be followed for output determination for Sales activities and Billing
documents
Define Communication Strategy
SPRO IMG - SD - Basic Function - Output Control - Determine Communication Strategy
Path

You need to create communication strategy, system should search for communication methods in
case of transmission medium 5.
Output Determination Level & Assignment in Sales
Output Determination - Level Assign to
Output Determination - Level Assign to
Output Determination - Sales Document: Header assigned to Sales Document Type
Output Determination - Sales Document: Item assigned to Sales Document Item Category
Output Determination - Delivery Document: Header assigned to Delivery Type
Output Determination - Delivery Document: Item assigned to Delivery Item Category
Output Determination - Billing Document: Header assigned to Billing Type
Output Determination - Billing Document: Item assigned to Billing Type

Some Standard Output Types

Output Type relevant Sales Document Standard Output Type
Transfer Order WMTA
Packing PL00
Sales Orders BA00
Cash Sales RD03
Sales Invoice RD00
Delivery Note LD00

Condition Record
Without or in absence proper condition record maintenance, the desired output type will not
determine in relevant sales document type. Therefore condition record is crucial in Automatic
determination of output type.

TCode Condition Record Maintenance for

VV11 / VV12 / Sales Document relevant Output Type
VV13
VV21 / VV22 / Delivery Document relevant Output Type
VV23
VV31 / VV32 / Billing Document relevant Output Type
VV33

 Defining Text Procedure in SD
Overview:
Texts are used in SD documents (Sales Order, Delivery and Billing) and in Customer & Material
master records. Texts are located at header and item level in SD documents. Texts can be used as
an exchange of information between business partners in Sales and Distribution. They can be
used as an exchange of information between business partners in Sales and Distribution.

Definition: A text type is the classification for various user-defined texts in master records or
documents.
If a text ID is created for multiple text objects, it will be pulled through the various objects (for
example, sales order à delivery note).
Text can be proposed in the documents automatically from below mentioned points by a text
procedure:
• customer master
• material master
• one SD document into another (e.g., from sales order to delivery) at either header or item level
In this document, I will explain how to configure the Text in Sales & Distribution Module.

Text Configuration Steps:

To create a text type for a Sales Order line item, follow the below mentioned path in SAP
IMG.

Or Go to transaction VOTXN.

Define Text Types:

Explanation is given only for creating text type configurations of Sales Order line item. Creating
the text types will remains same for all other documents too.
• Go to transaction VOTXN.
• Select the radio button ‘Sales Document ->Item’ and click on ‘Text Types’ button. (Make sure
you have necessary authorization to create new entries. You may face pop up No
maintenance authorization for cross-client tables (see Help))
• Press ‘New Entries’.
• Enter ID and Description for your newly created Text Types.
• Save
• Press ‘Back’ button and come out to ‘Customizing Text Determination’ screen.

Text determination configuration steps:

• From ‘Customizing Text Determination’ screen, again select radio button ‘sales order ->Item’
and press ‘Change’ button.
•

•
• Now it is required to define own text determination procedure.
• Under ‘Textprocedure’, press ‘New Entries’ to create a new procedure.
•
•
• Save.
• Select the newly created procedure and double click on ‘Text ID’s in Text Procedure’ node.
•

•
• Again press ‘New Entries’ and add the text ID’s as per your business requirement from F4
(help). Also make sure to assign unique 'Sequence Number'.
• Save.
Note: If the text needs to be mandatory in sales document, then select ‘Text is obligatory’ and it
will be added in the Incompletion Log in ‘Text is obligatory’ column.
Once the text configuration is done, we have to assign the text to 'Text Determination Procedure'
to relevant item category in tab 'Text Procedure Assignment'.

After referring this document you will be able to create the Text Procedures, Text Types and Text
ID's in text procedure.
 Pricing Procedure in SD
There are many queries on Pricing Procedures in SD module in the forum.
Pricing Procedure is indeed an heart of SD module, reason being if everything else is working
fine, but price is not being calculated correctly, the purpose of billing fails.
An Overview of Determination & Configuration of Pricing Procedure is as follows:
In SD, Pricing Procedure (TCode OVKK) is determined based on :
Pricing Procedure = Sales Organization + Distribution Centre + + Customer Pricing Procedure + Document Pricing Procedur
Division

Sales Area is determined in Sales Order Header Level. Customer Pricing Procedure is determined
from Customer Master - Sales Data - Sales Tab - Pricing Section. Document Pricing Procedure is
determined from Sales Document Type (TCode VOV8) / Billing Type (TCode VOFA) (if
configured). Once the pricing procedure is determined, Condition records are fetched. If
appropriate condition records are found, the price is determined. If Mandatory pricing condition
is missing, system will through an error message.
In SD, the steps to configure Pricing procedure are as under:

Step 1:
Condition table (TCode V/03, V/04 & V/05): If existing condition table meets the
requirement, we need not create a new condition table. Considering the requirement for new
condition table, the configuration will be done in SPRO as follows: IMG - Sales & Distribution -
Basic Function - Pricing Control - Condition Table (select the required fields combination, which
will store condition record).
Step 2:
Access Sequence (TCode V/07) : If existing access sequence meets the requirement, we need
not create a new access sequence. Considering the requirement for new sequence, the
configuration will be done in SPRO as follows: IMG - Sales & Distribution - Basic Function -
Pricing Control - Access Sequence (Access sequence is made up of Accesses (Tables) & the
order of priority in which it is to be accessed. Here we assign the condition table to access
sequence.). So, we can say that the access sequence is a search strategy which the System uses to
search for condition records valid for a condition type. We create new or modify an existing
access sequence follow rule "Specific to General" while maintaining the accesses for the access
sequence by specifying the condition tables in the desired sequence. For example,
Step 3:
Condition Type (TCode V/06) : If existing condition type meets the requirement, we need not
create a new condition type. Considering the requirement for new condition type, the
configuration will be done in SPRO as follows: IMG - Sales & Distribution - Basic Function -
Pricing Control - Condition Type. It is always recommended to copy an existing similar condition
type & make the necessary changes. Here we assign Access sequence to Condition type.
Step 4:
a. Pricing Procedure (TCode V/08) : It is recommended to copy a similar pricing procedure &
make the necessary changes in new pricing procedure (Note: It should suffice business
requirement). Pricing Procedure is a set of condition type & arranged in the sequence in which it
has to perform the calculation. Considering the requirement for new Pricing Procedure, the
configuration will be done in SPRO as follows: IMG - Sales and Distribution - Basic Function -
Price Control - Pricing Procedure - Maintain Pricing Procedure.
b. Pricing Procedure Determination (TCode OVKK) : After maintaining the pricing
procedure the next step will be determination of pricing procedure. Configuration for determining
pricing procedure in SPRO is as follows: IMG - Sales and Distribution - Basic Function - Price
Control - Pricing Procedure - Determine Pricing Procedure.
Step 5:
Condition record (TCode VK11, VK12, VK13) : Condition record is a master data, which is
required to be maintained by Core team / person responsible from the client. During new
implementation, the condition records can be uploaded using tools like SCAT, LSMW, etc. It is
assumed that document pricing procedure, customer pricing procedure , ... and other required
config& Determination are in place.


 Revenue Account Determination - Configuration

Introduction
Revenue account determination is one critical integration point between Sales & Distribution and
Financial Module.
Here on posting a billing document to account, based on this revenue account determination,
system determines relevant G/L accounts for revenue posting. As like any other basic function
configuration like pricing, its configuration also based on condition technique.
Steps in Configuration
The following are the steps involved in configuring revenue account determination:
Step 1. Check Master Data Relevant For Account Assignment
SPRO IMG - SD - Basic Function - Account Assignment - Account Assignment/Costing -
Path Revenue Account Determination - Check Master Data relevant for Determination
Condition Short Available in Transp.
Table Description Transaction Table
Number VKOA Name
1 Cust.Grp/MaterialGrp/AcctKey YES C001
2 Cust.Grp/Account Key YES C002
3 Material Grp/Acct Key YES C003
4 General YES C004
5 Acct Key YES C005
7 Vendor C007
400 IS-H: Account key/case type/private/ext.physician C400
401 IS-H: Acct key/case type/srv.catalog/srv./private/ext.phys. C401
410 Chart of accts / Account key - acct assign for ED rev C410
495 Document Category/Condition Type/Own-External/Account Key C495
496 Condition Type/Account Key C496
497 Document Category/Condition Type/Account Key C497
498 Doc. Category/Condition Type/Own-Ext./Actvty Type/Acc. Key C498
499 Doc. Cat./Cond. Type/Own-Ext./Acty Type/Ctlg Group/Acc. Key C499
TCode OVK5
Here you set up field for maintaining option master data
1. Account assignment group for material
2. Account assignment group for customer
Based on these fields, account determination in respective sales document will take place.
Step 1.1 Materials: Account Assignment Groups
Here you maintain option for Account assignment group for Material. This allows you to divide
materials into different groups, services and retails groups. From master data point of view, you
maintain this in Material Master(MM01/MM02) under Sales: Sales Org 2 view.
Step 1.2 Customer: Account Assignment Groups
Here you maintain option for Account assignment group for Customer. This account assignment
group relevance is maintain for Payer partner function. This allows you to divide customer into
different groups, e.g. domestic and overseas customer. From master data point of view, you
maintain this in Payer Customer Master(VD01/XD01/VD02/XD02) under billing document tab
of Sales Area Data.
Step 2. Define dependency of Revenue Account Determination
Here we can create & display condition table for revenue account determination by selecting
appropriate fields. Based on this field key combination, system will fetch relevant data from the
determination maintained.
SPRO IMG - SD - Basic Function - Account Assignment - Account Assignment/Costing -
Path Revenue Account Determination - Define dependency of Revenue Account Determination

Some TCode related to condition table

TCod Desc
e
V/12 Account determination: Create tables
V/13 Account Determination: Change table
V/14 Account determination: Display tables
OV25 Field catalog: Allowed fields for the tables
Following are some standard condition table available:
Following are some of the example for custom condition table may be created based on your
requirement
Condition Short
Table Description
Number
901 Sales org./AcctAssgGr/AcctAsgnmt/Acct key/Ord.reason
902 Sales org./Plant/AcctAssgGr/AcctAsgnmt/Acct key/Ord.reason
903 Sales org./Cond.type/Acct key/Plant
904 Sales org./Plant/AcctAssgGr/AcctAsgnmt/Acct key/Ord.reason
Step 3. Define Access Sequence and Account Determination
Type
In standard revenue determination, KOFI is used as account determination types/condition type.
Based on your requirement and addition of new condition table in access sequence, you can
create and assign new access sequence. As there may be have to shuffle the key
combination(condition table) based on your requirement. Say,
Ste Condition Table Desc Requirement
p
10 902 Sales org./Plant/AcctAssgGr/AcctAsgnmt/Acct key/Ord.reason 0
20 901 Sales org./AcctAssgGr/AcctAsgnmt/Acct key/Ord.reason 0
30 1 Cust.Grp/MaterialGrp/AcctKey 0
40 2 Cust.Grp/Account Key 0
50 3 Material Grp/Acct Key 0
60 904 Sales org./Cond.type/Acct key/Plant 0
70 496 Condition Type/Account Key 0
80 5 Acct Key 0
90 4 General 0
As these key combination in an access sequence is maintain from specific to general. Unlike
pricing it doesn't have any exclusive indicator.
Step 4. Define And Assign Account Determination Procedures
Step 4.1 Define Account Determination Procedure
Following are the fields under Account Determination:
1 2 3 4 5
St Count Condition Description Requirement
ep er Type
10 1 KOFI Account 3 - Without CO acct.ass.
Determinat.
Here Account Determination Procedure is maintained specifying the Requirement account
determination with controlling or not.
Step 4.2 Assign Account Determination Procedure
In this step account assignment procedure is assigned to respective Billing Type.
Step 5. Define and Assign Account Key
These are assigned to the condition types in the pricing procedures; this allows conditions such as
freight conditions to posted to special freight revenue accounts.
Step 5.1 Define Account Key:
We can create our own Account Keys by specifying Account Number & Description.
Step 5.2 Assigning Account Key:
Here we assign Account Keys to respective Pricing Condition Type. If the you assign/change a
account key to condition type, it will automatically maintain/change the account key your pricing
procedure and vice versa.
Step 6 Assignment of G/L Account
Here you will be display/maintain all the possible key combination Based on your condition table
maintain in access sequence which is assign to the revenue account determination procedure.
Say, your want to maintain account determination based on key combination
a. Condition Type
b. Charts of Account
c. Sales Organisation
d. Account Keys
Then you would have to maintain value in access 5 - Acct Key
Applicatio Condition Type Charts of Account Sales Organisation Account Keys G/L
n Account
V KOFI INT 0001 ERL 150000
Else, Say, your want to maintain account determination based on following key combination
a. Condition Type.
b. Charts of Account.
c. Sales Organisation.
d. Account Assignment Group for Payer.
e. Account Assignment Group for Materials.
f. Account Keys.
Then you would have to maintain value in access 1 - Cust.Grp/MaterialGrp/AcctKey
Applicatio Condition Charts of Sales Organisation Account Assignment Group Accoun
n Type Account for Customer for Mat
V KOFI INT 0001 01 - Domestic Revenue 03 - Fin


Rebate Processing
Rebates:Rebate agreement is a special agreement granted to the
customer on a specific volume of sales over a specific period of time.

Configuration Path:
IMG>SD>Billing>Rebate Processing>Rebate
Agreements>Define Agreement Types>
Step 1: Define Agreement Type
Select”Define Agreement type ” from choose activity,double click on it

Select an Agreement click on copy button and rename it

here I selected standard and renamed “0002-Material Rebate” to “Z002-

Material Rebate-AA11”
Step 2: Condition Type Groups

2.1:Click on Define condition Type groups

Click on New Entries
Enter your Copied Condition Type group which you created and
Maintain “Blank” for Category of the condition type group
 Step 2.2: Assign Condition Types /tables to Condition Type groups

Click on New Entries

Assign Condition Type “Bo02” and Condition Table “1”to your
Condition Type Group”Z002”

Step 2.3: Assign Condition Type groups to rebate agreement types

Click on it, Assign Condition Type group to Agreement Type

Step 3: Condition Technique for Rebate Processing

Click on it
Same as like Pricing Procedure configuration
Step 3.1: Select Maintain condition table for Rebates
Select Maintain Condition Tables for Rebate and Click on Choose
Based on requirement we can create new condition table
Save and exit (if anything created)
3.2: Maintain Access Sequence
Select Maintain Access Sequence
Click on Choose, Go to New Entries and Maintain Access Sequence
Maintain “1” Relevant for Rebates
Step 3.3: Define Condition Types:
Choose Define condition types
Select it and click on Choose
Rebate condition types (BO01, BO02, BO03, BO04, BO05, BO06)are
available in Standard SAP
Assign Access sequence to condition Type (if copied)
Step 3.4: Maintain Pricing Procedure:
Select Maintain Pricing Procedure and click on Choose
Choose Standard or copied Pricing Procedure by use
Click on Position Button left side Dialog Structure
Make sure that Rebate condition types must available in (copied) pricing
procedure
With Requirement-24 (only in Billing Document)

Account Key – ERB

Accruals – ERU

Step 4: Account Determination for Rebates

(If your are good at Account determination Procedure configuration no need
to fallow this)
The same process like Account Determination Procedure

Step 4.1: Define A/C keys

(Standard keys available in SAP)
ERB -Rebate Sales deduction
ERU –Rebate accruals
Step 4.2: Assign Account Keys to our Pricing Procedure
In standard pricing procedure it’s available
Steps 901 to 905

Step 4.3: Maintain Access Sequence

(standard already created like Accounting Determination Procedure)
Step 4.4: Define Account Determination Types
Assign access sequence to Condition type
Step 4.5: Assign G/L Account

Choose table 1-customer group/Material Group/Account Key

Click on Assign button and Maintain G/L Account Provision Account

Step 5: Activate Rebate Processing

IMG>SD>Billing>Rebate Processing>Activate Rebate Processing
Click on “Activate Rebate Processing”

Select “Billing Documents for Rebate Processing” in Choose Activity.

Step 5.1: Select Billing Document for Rebate Processing
T-Code: OVB0

(Or) T-code: VOFA

Enter billing Document Type and put check mark for Relevant for
Rebates

Go back, Select “Activate Rebate Processing for Sales Organizations”

Step5.2: Activate Rebate processing for sales organization

Click on Choose
(Or) Go to Enterprise structure

T-code: OVX5
Select your sales organization
Put check mark for Rebate process Active

Step 5.3: The payer must be relevant for rebate processing.

Go to XD01 or XD02 Payer customer master record
Go to sales are data tab then choose Billing tab put check mark for
“Rebates”
Step 6: Create Rebate Agreement
T-code: VBo1 or SAP Easy Access Path
SAP Menu>Logistics>Sales and Distribution>Master
Data>Agreements>Rebate Agreement
(VBO1-Create/VBO2-Change/VBO3-Display)

Choose created one (Ex: Z002)

Specify the rebate recipient [Customer master payer number]
Specify the validity period of the agreement
Specify the agreement status: Blank [] = Open
Specify the verification level [F] = Display totals by Payer/Material
Then click on Conditions on top
Maintain (Accruals amount) condition record for material rebate how much
rebate we want to give it to the customer

If we click on scales button

Here I maintained for each product 1 rupee
go back

save it.
With this configuration part is completed
Step7: create sales order
T-code: VA01
Specify Organizational details
Press F8(document Complete)
Check item conditions
Save it
Step 8: Create Delivery
T-code: VL01n
Step 9: create Billing document

Check ITEM conditions BO02 will display in conditions tab because we

maintained requirement ‘24’ in our pricing procedure

save it
Now Rebate Settlement to customer
Step 10: Go to VBo2 rebated agreement
Enter rebate agreement which we created
Ex: 34

Check agreement status to ‘B’

On the menu bar choose “Rebate Payment”

Here Customer is eligible for 50 Rs rebate accruals amount
If we observe Verification Levels
Will get details of payer customer master total rebate accruals amount
We can settle the rebate amount by manual or automatic

Manually we can select the customer eligible amount

Then we can save it

It will create automatically credit memo request
Here I have chosen 5Rs/- and save it
We will get the message like this bottom of the screen.

Or if we want to give full settlement to the customer click on

It will create automatically Rebate Request for Manual Accruals for entire
eligible pending amount.
It will happened in the back ground
If we want to check that go to this path or Click T-code: VOV8
Select any one of the above document type
B1, B2, B3 OR B4 click on details icon
Coming back to Rebate credit memo request
Back ground automatically created we can check these details by using T-
code: VA03
Now create Billing Document by using sales order number
Check the conditions
Save it
Billing document will be generated
Rebate accrual amount 5Rs
Check Accounting Document

General ledger view

With this Rebate agreement process is completed.

Standard Programs in SD
SAPMV45A - Sales Order Processing
SAPFV45P - Sales: Item Processing
SAPFV45K - Sales: Processing Header Data
SAPMV60A - Processing Billing Documents
RSNAST00 - Selection Program for Issuing Output
SAPMV13A - Condition Maintenance
MV45AFZB - User Exits
MV50AFZ1 - User Exit as of 21D for Delivery Processing
RVKRED77 - SD: Reorganization of credit data after update errors
RLB_INVOICE - Invoice print program
SDBILLDL - Maintain Billing Due List
RVADIN01 - Print program for invoices
RV60SBAT - Creating Background Jobs for Billing
RV60BFZA - User Exits
RV60AFZB - General billing interface: user exit for CPD addresses
RVIVAUFT - Intercompany invoices with order purchase
RVAFSS00 - Invoicing External Transactions
SDBLBDDL - Release Billing Documents for Accounting
SDRQCR21 - Recovery of Sales and Delivery Requirements
SAPMV13B - Output Maintenance
Difference between BDC and BAPI

BDC is traditional way of coding the transactions for uploading the legacy
data, Sap is changing all transactions to Object oriented programming. Since
BAPI is Object based and supports all the new transactions it is preffered
over BDC. More over BAPI's process data faster than BDC.

BAPI is a SAP-supplied function module with a defined interface, which

allows you to interact with various business objects. SAP guarantees the
integrity of your database for anything updated using a BAPI. BDC is a
method of driving screens programatically, for updating SAP data. BAPIs
are generally faster than BDCs.

A BAPI is faster because it is updating the DB "directly". Whereas BDC

with call
transaction goes through the whole screen sequence like any user would do,
simply put, fills screens.

However - there is not always a BAPI for a particular transaction and not all
functions that are performed by a transaction can be done by a BAPI. BDCs
produce error sessions which can be processed by the user, while BAPIs
don't.

First choose the BAPI ,if there is no BAPI go for BDC.

why BAPI first not BDC.

SAP comes up with Change in Version, so each and every time they will
change the screens/number etc.
so you have to change your BDC programs accordingly.
and also Most of the Latest versions transactions are Enjoy Transaction. they
will not support BDC's in Background.

But Using BAPI's No such disadvantages.

A BAPI is faster because it is updating the DB "directly" through ABAP

code.

A BDC with call transaction goes through the whole screen sequence like
any user would do, simply put, it is filling screens.
Actually it depends on your requirement but BAPI is more effective as it is
standard function module to update SAP databases rather than BDC.

usingbdc over bapi has advantages and also disadvantages

advantages:
1. usingbdc we can upload data into database tables using 2 ways
1. foreground -
means that user interaction is there for each and every record.
2. back ground -
no user interaction and tasks are done automatically.
using these two options is one of the greatest advantage over bapi.

2. inbdc call transaction method we can control the display of screen

resolution which is not possible with bapi's

3. bdc is generally used for transferring of large amount of data than bapi's

4.session method of bdc allows us to place data directly in application server

and then finally transfered into sap database tables

disadvantages:

1.bdc is only used for sap to sap system data transferring

2. bapis's generally works more faster than bdc's

3. usingbapis we can connect to remote systems and also to non sap systems.

A BAPI is a method of a SAP Business Object. BAPI enables SAP and third
party applications to interact and integrate
with each other at the Business Object / Process level.

Batch Data Communication (BDC) is the oldest batch interfacing technique

that SAP provided since the early versions of R/3. BDC is not a
typical integration tool, in the sense that, it can be only be used for
uploading data into R/3 and so it is not bi-directional.
BDC works on the principle of simulating user input for transactional
screen, via an ABAP program. Typically the input comes in the form
of a flat file. The ABAP program reads this file and formats the input data
screen by screen into an internal table (BDCDATA). The
transaction is then started using this internal table as the input and executed
in the background.

In ‘Call Transaction’, the transactions are triggered at the time of processing

itself and so the ABAP program must do the error handling.
It can also be used for real-time interfaces and custom error handling &
logging features. .

Main differences are...

In case of bdc data transfer takes place from flat file into sap system ie the
file existing in sap system to sap sytem
where is bapi's r remotly enabled function modules which are assigned to
some business objects n used to transfer the data between different business
partners who are using different systems other than sap.
not only that...
when you plan to upgrade your system version then bdcwillnot support those
upgradations where as bapi's will support.

MAKE TO ORDER configuration requirement

1) You need to have a material with item category group 0001 = MTO (Normal Item)

In MM01, basic data tab, Gen.Item category field 0001= MTO , 0002 for configurable
material

2) In MTO availability check - checking group is 02 (individual requirement) in

General/Plant tab.

3) Create an order VA01 there you will see item category as TAK, schedule line as CP,
and requirement type as KE

In VOV7 TAK Billing relavence is A and pricing is X.

In VOV6 for CP the movement type is 601

4) MB1C to initialize the stock with special stock indicator E (means 561E)

5) MMBE to check the stock if it has been created or not.

Important Links

https://wiki.scn.sap.com/wiki/display/ERPLO/Partner+determination+procedure+i
n+SD


https://wiki.scn.sap.com/wiki/display/ERPLO/Route+Determination+In+Sales+Or
der



https://wiki.scn.sap.com/wiki/display/ERPLO/output+determination+using+condit
ion+technique



https://wiki.scn.sap.com/wiki/display/SD/Defining+Text+Procedure+in+SD



https://wiki.scn.sap.com/wiki/display/ERPLO/Pricing+Procedure+in+SD



https://wiki.scn.sap.com/wiki/display/ERPLO/Revenue+Account+Determination+
-+Configuration



https://blogs.sap.com/2012/12/31/idoc-basics-for-functional-consultants/