SAP SD Configuration Document

SAP SD Configuration Material
By Srinivasulu Algaskhanpet (Sr. SAP SD Consultant) Page 1
I. Organizational Structure: The general organizational structure in any company.
 In SD highest organizational element in “Sales Organization”.
 In FI highest organizational element is “Company Code”.
 In MM highest organizational element is “Purchasing Organization”.
 In PP highest organizational element is “Plant”.
 In CO highest organizational element is “Controlling Area”.

1. Enterprise structure in Smart Phones India Ltd:
Company Code: Company code is a legal entity which is responsible for all business/financial
transactions within the company. Field Name - BUKRS
A Company code is physical location i.e., it will have address.
A company code is a 4 digit code. It can be numeric, character and even alpha-numeric.
Path: SPRO > Enterprise structure > Definition > Financial accounting > Edit,copy,delete,check
company code > Edit company code
SPIL : Smart Phones India Ltd
After creating company code click on the red highlighted icon (address icon) enter the address of the
company code.
The address contains information regarding physical location, country, region, time zone, telephone
numbers, fax, mail ids etc.
The below screenshot shows all the details regarding the address details of the company code.

Sales Organization: It is the Organizational unit which is responsible for all sales related
activities and services happens within the company code. Field name - VKORG
It is an organizational unit where strategic decisions related to sales will be taken and where
you find vice president sales and director sales.
Sales Organization is a physical location i.e., it will have address.
A sales organization is a 4 digit code. It can be numeric, character and even alpha-numeric.
In our project we have 2 sales organizations. One for domestic and other for export.
Path: SPRO > Enterprise structure > Definition > Sales and distribution > Def,copy,del,check
Sales Organization
SPIL: Domestic Sales Org SPI1: Export Sales Org

After creating Sales Organization click on red highlighted icon (address) to enter the communication
details of the Sales Organization.

Distribution Channel: It is the channel through which the good/products/services are
distributed to the end customer. Field Name - VTWEG
Distribution channel is a 2 digit code. It is a logical entity. We don’t have location address for
this.
Path: SPRO > Enterprise structure > Definition > Sales and distribution > Def,copy,del,check
Distribution channel
SP: Dealers
IL: Retailers
The combination of Sales org and distribution channel together is called “Sales Line”.
Division: A division is a range of products or it’s a product line i.e., grouping of products which
will have similar in nature. Field Name - SPART
Division is 2 digit code.
The combination of Sales org, distribution channel and division is called as “Sales Area”.
Sales Area plays a vital role in SD, because whatever we do in sales it should be routed to a
particular sales area.
Path: SPRO > Enterprise structure > Definition > Logistics – General > Def,copy,del,check
division
SP: Mobile Division
SQ: CDMA Division

Sales Office: It is a physical location where group of people work together to perform sales.
Sales office is a 4 digit code. SD consultant is responsible to define sales office.
Path: SPRO > Enterprise structure > Definition > S&D > Maintain Sales office
Sales office is a physical location. Field Name - VKBUR
SPIL: SPIL Sales Office
Click on the Address icon to enter the communication details regarding the sales office.

MaintainSales group: It is a group of people within a sales office working for different sales
activities. Field Name - VKGRP
Sales group is a 3 digit code. SD consultant is responsible to define sales group.
Path: SPRO > Enterprise structure > Definition > S&D > Maintain Sales group
SPI: SPIL Sales group
Plant/Depot/C&F: Plant is a physical location where we do the process of manufacturing
finished goods. Field Name - WERKS
Depot is a physical location where we store finished goods for easy distributing goods to
customers.
If 3rd party person is taking care of depot then we call it as C&F (Carry and Forward).
In SAP Plant, Depot and C&F are one and the same. These are differentiated by PP consultant.
In Sales point of view we call plant as “Delivering plant” (is a place where we deliver the goods
to customers).
In MM point of view, they call plant as “Storage Plant”.
In PP point of view, they call plant as “Manufacturing Plant”.
MM Consultant is responsible to define plant in SAP.
For practice purpose we’ll define 2 plants.
SPI1: SPIL Plant 1
SPI2: SPIL Plant 2

To add address to a plant click on the address tab which is highlighted with the red circle.
SPI1: SPIL Plant 1
SPI2: SPIL Plant 2

Storage Location: A Storage location is a place where we store goods with in a plant.
MM Consultant is responsible to define storage location. Field Name - LGORT
Storage location is a 4 digit code.

Path: SPRO > Enterprise structure > Definition > MM > Maintain storage location
SPI1: SPIL Storage 1
SPI2: SPIL Storage 2
We need to maintain storage location within the plant.
Shipping Point: Shipping point is a physical location where we do the process of loading the
goods into trucks for dispatching to the customers. Field Name - VSTEL
We have 3 types of shipping points
I. Manual shipping point (labor involves)
II. Automatic shipping point (Machinery involves)

III. Immediate shipping point
It is a 4 digit code and SD consultant is responsible to define shipping point.
Path: SPRO > Enterprise structure > Definition > Logistics execution > Def, copy, del, check
shipping point
SPI1: Automatic Shipping Point
SPI2: Manual Shipping Point
SPI3: Immediate Shipping Point

Company: It is an organizational unit which will group multiple company codes into one.
E.g.: TATA group, Reliance group
FI consultant is responsible to define company.
Business Area: It is an organizational unit which will help to generate internal financial
reports.
FI consultant is responsible to define business area.
Credit Control Area (CCA):It is an organizational unit which specifies group of people
responsible for credit activities (Credit Department).
FI consultant is responsible to define Credit Control Area.
Controlling Area: This organizational unit specifies the group of people responsible for cost
controlling activities.
CO consultant will define controlling area.
This ends the 1st chapter of defining the organizational elements of the Smart Phones India Ltd.
In next chapter we’ll discuss about the assignment of these organizational elements and their
relation in an entity.
2. Assignment of Organizational Units:
Assign Company code to Sales Organization: Here the relation is one to many i.e., one
company code can have many sales organizations but one sales organization is assigned to
single company code.
SD consultant is responsible to assign sales organization to company code.
Path: SPRO > Enterprise structure > Assignment > S&D > Assign Sales organization to company
code

Assign distribution channel to sales organization: Here the relation is many to many
i.e., one sales organization can have many distribution channels and one distribution channel
can be assigned to many sales organizations.
SD consultant is responsible for this assignment.
Combination of Sales organization and distribution channel is called as “sales line”.
Path: SPRO > Enterprise structure > Assignment > S&D > Assign distrbn channel to sales orgsn
Assign Division to Sales Organization: The relation is many to manyi.e., one sales
organization can have many divisions and one division can be assigned to many sales
organization.
SD Consultant is responsible for this assignment.
Setup Sales Area: A Sales area is combination of sales organization, distribution channel and
division.
Sales area plays a vital role in SD. Any transaction you do in sales it should be routed to
particular sales area.
SD consultant is responsible to set up sales area.

Assign Sales office to Sales area: The relation is many to many.
We assign domestic sales areas to sales office.
SD consultant is responsible to assign sales office to sales area
Path: SPRO > Enterprise structure > Assignment > S&D > Assign sales office to sales area
Assign Sales group to Sales office: The relation is many to many.
SD consultant is responsible to assign sales group to sales office.
Path: SPRO > Enterprise structure > Assignment > S&D > Assign sales group to sales office.
Assign Plant to Company code: The relation is one to many i.e., One company code can
have many plants but one plant should be assigned to single company code.
Path: SPRO > Enterprise structure > Assignment > Logistics-General > Assign plant to company
code

Assign Sales Orgsn, distrbn channel to plant: In a standard business process we can
assign sales organization to plant if and only if they both belong to the same company code.
SD consultant is responsible for this assignment.
Path: SPRO > Enterprise structure > Assignment > S&D > Assign sales orgsn, distrbn channel to
plant
Assign Shipping point to plant: The relation is one to many.
But, if the plants are located at same premises the relation is many to many.
SD consultant is responsible for assignment.
Path: SPRO > Enterprise structure > Assignment > Logistics execution > Assign shipping point
to plant

Organizational structure of SPIL
SPIL
SPIL SPI1
SP IL
SP SQ SP SQ
Domestic
Sales Area
SPIL
SPI

Explanation for sales organization fields: Important
The address text fields in sales organization will help to determine the address of sales
organization and prints it in the output.
Output may be a printout, email, fax etc.
Rebate Proc.active: This field is a pre-requisite to process rebate in an organization. So, always
check this option in sales organization.
A rebate is a conditional discount which will be valid over a period of time. If the customer
reaches the condition then only he is eligible for rebate.
ALE: Data for purchase order: ALE - Application Link Enabling
In Third Party and IPO process if you create sales order system automatically creates PR
(purchase requisition) in the background. But if you want system to generate automatic PO

(purchase order) then we have to maintain ALE data for purchase order in the definition of sale
organization.
Sales Organization calendar: Sales organization calendar specifies the working days and
holidays of an organization.
Explanation for shipping point fields: Important
Loading time: It is the time taken to load the goods for dispatching it to the customers.
Pick/Pack time: It is the time taken to pick the material from the storage location and to pack it.
Note: Pick/pack time and loading time will be used to perform delivery scheduling in a sales
document.
Delivery scheduling is a process of determining delivery dates and confirmed quantities into the
sales document.
The address texts in shipping point helps in determining the address of the shipping point and
print it in relevant outputs.

Defining calendar in SAP: Calendar specifies working days and holidays.
Path: SPRO > SAP Netwever > General settings > Maintain calendar
In calendar we can maintain public holidays, and we can use same for holiday calendar which is
assigned to the factory calendar.
SAP has already defined required public holidays, if we want to define any other public holidays
we can define in public holidays, for that select public holidays and click on change button
which is highlighted in the screen shot.
To assign defined holidays to the holidays calendar select holiday calendar and click on change
button.
Here we can assign all the public holidays to the calendar. Public holidays may differ from
region to region.
Give calendar ID and description and click on assignment tab as shown in below screenshot, we
will get all defined public holidays from where we need to select and assign to the holiday
calendar.

After defining holiday calendar assign the same to the factory calendar.
Assigned public holidays will be displayed in the public holiday calendar details as shown in the
below screen shot.

To assign public holiday calendar to factory calendar, select factory calendar and click on
change.
Factory calendar is shown in the below screenshot.
Defining factory calendar is responsibility of HR people.
Note: We cannot process the transaction on any given holiday. But in some cases we need to
do as the urgency of the customer. For example, we cannot create delivery on a given holiday
according to our factory calendar. But if at all we want to create a delivery in SAP system on a
holiday we can select special ruleswhere we can define the holiday as a working day and we
can do the process. This special rules is used only in special business process.
In SAP the factory calendar is assigned at three places.
1. Sales organization
2. Plant and
3. Shipping point.

II. MASTER DATA:
It is the data which is stored centrally and used in day to day transactions.
It is the data which cannot be changed frequently.
The advantages of having master data:
a. It will save the time of end users.
b. It will avoid manual mistakes.
In SAP SD we have 4 types of master data.
1. Customer Master
2. Material Master
3. Customer Material Info Record (CMIR)
4. Condition Master
Customer Master: It is the data of the customer which is stored centrally and used in day to
day transactions.
E.g. Customer name, Phone number, Address, Payment details etc.
End users will create customer master data.
In real time every company will have one or two people who are users who are authorized to
create customer master data.
Material Master: It is details of the product/material which is stored centrally and used in
day to day transactions.
Customer Material Info Record (CMIR): We use this master data if customers are placing
order with their material code.
By using this master data we assign customer material with our material number. When user
enters customer material number in sales order system automatically determines our material
number with the help of CMIR.
Condition Master: It is the master data for pricing.

1.Customer Master:
Creation of customer master involves 5 steps:
i. Defining Account Group
ii. Creating Number Range
iii. Assign Number Range to account group
iv. Defining Partner Determination Procedure (PDP)
v. Creating the customer.
i. Defining Account Group:
The standard account groups are
0001 - Sold to party (SP)
0002 - Ship to party (SH)
0003 - Payer (PY)
0004 - Bill to party (BP)
The purpose of account group is:
a. Number Ranges
b. Controlling fields in customer master
c. Controlling partner functions.
Controlling fields is nothing but making the fields as mandatory or optional or display or
suppress.
Path: SPRO > Logistics-General > Business Partner > Customers > Control > Define account
groups and field selection for customers
T.Code: OVT0

Number Range: We create number ranges based on the client requirement and assign it here.
One-time account: We check this field only for one time customer. One time customer is the
customer who may not place the order for the second time.
For those onetime customers we don’t create master data and we don’t waste space of
database
We create one common customer master record, whenever any onetime customer places
order we will use the common customer number. One time customer master doesn’t have
name and address.
If we check one time account, while creating sales order for onetime customer system
automatically asks for name and address.
The standard one time account group is CPD & CPDA.
Field Status: Field status will helps to control the fields in customer master. Controlling is
nothing but making fields mandatory, optional, display or suppress.

Text Procedure: Text procedure consists of customer specific text like packing instruction,
payment instruction, terms & conditions etc., these texts we maintain in customer master
which will be copied into order, delivery and invoice. These customer specific texts will be
printed in relevant output.
We maintain text in customer master in extras > texts
Customer pricing procedure: If we maintain customer pricing procedure here system proposes
it by default while creating customer master.
Partner determination procedure: It will help to determine partner functions in customer
master.
The standard partner determination procedure for sold to party is "AG". AG partner
determination procedure will have four partner functions i.e., SP, SH, PY & BP.
The standard partner determination procedure for ship to party is "WE", this partner
determination procedure will have only one partner function i.e., SH.
The standard partner determination procedure for payer is "RG", this partner determination
procedure will have only one partner function i.e., PY.
The standard partner determination procedure for bill to party is "RE", this partner
determination procedure will have only one partner function i.e., BP.
Output determination procedure: The standard output determination procedure for customers
is "db0001".
In output determination procedure configuration if "access to conditions" is unchecked then
system will try to determine output type from customer master with the help of "db0001"
output procedure.
In customer master we will maintain output type in "documents" tab.
After creating Account Group we need to create Number ranges and we need to assign to the
respective account group.
ii. Creating Number Range: We will create number ranges based on client requirement and
assign it here.
Path: SPRO > Logistics-General > Business Partners > Customers > Control > Define and assign
customer ranges > Define number ranges for customer master.
T.Code: OVZC

Click on change intervals which are highlighted with red circle.
Maintain Customer Intervals screen will open as shown in below screenshot.
Click on Insert Interval which is highlighted with the black circle, system will provide you an
empty space to maintain number range which is highlighted with the green color. After
maintaining the number ranges save the entries.
Number ranges can be internal or external. Internal means while saving the customer master
system will propose the number automatically. External means while creating customer master
user has to give the number manually.
Number ranges can be numeric, alpha numeric or character. Alpha numeric or character should
be always external whereas numeric can be external or internal.
Number ranges cannot be transported form one server to another server.
NR Status Tab in number range will help to change the current number.
After defining number ranges, assign them to respective account groups.
iii. Partner Determination Procedure(PDP): In order to get the required partner functions into
customer master record, we have to configure partner determination procedure. For this go to

Path: SPRO > S&D > Basic functions > Partner determination > Set up partner determination >
set up partner determination for customer master
a. Partner functions:
Partner type Unique
SP KU
SH KU
PY KU
BP KU
For each partner function we have to assign a corresponding "Partner Type" which controls the
functionality of that partner.
For example : If we specify the partner type as "KU" it becomes a customer where as if we
specify the partner type as "LI" it becomes a vendor.
Only for sold to party we need to check "unique" field. If we check this system will not allow
adding one more partner function of sold to party in customer master.
ii. Account group - Function assignment:
In this configuration step we assign partner functions account group.
SP - S001 PY - S003
BP - S004 SH - S002

iii. Partner determination procedure:
In this step we need to define partner determination procedure.
In our project we have defined 4 partner determination procedures.
SAG - Sold to party SRG - Payer
SWE - Ship to party SRE - Bill to party
iv. Partner Functions in procedure:
Select the defined partner determination procedure and double click on partner functions in
procedure where we assign partner functions to the procedure.
For SAG partner determination procedure we will assign all partner functions SP, SH, PY and BP.
For SWE partner determination procedure we will assign only SH partner function.
For SRG partner determination procedure we will assign only PY partner function.
For SRE partner determination procedure we will assign only BP partner function.

If you check "not modifiable", system will not allow changing the partner function in customer.
If you are doing partner determination procedure for sold to party then SP will have not
modifiable check.
All four partner functions will be mandatory in sold to party.
If you check "mandatory", system will not allow saving customer master if any of the partner
function is missing.
v. Partner determination procedure assignment: In this step we are going to assign required
account group to the procedure.
To configure partner determination procedure we need to follow these steps. Using this
account group and partner determination procedure end user will create master data for their
customers.

1. Customer Master: Customer Master is an integration between SD & FI. Because customer
master data consists of personal information, financial information and sales information.
The length of customer master code is 10 digits.
T.Codes to create customer master.
T.CODE CENTRALLY CO.CODE VIEW SALES VIEW
TO CREATE XD01 FD01 VD01
TO CHANGE XD02 FD02 VD02
TO DISPLAY XD03 FD03 VD03
Customer Master will be divided into 3 screens
i) General Data ii) Company code data iii) Sales area data
GENERAL DATA COMPANY CODE DATA SALES AREA DATA
1) General data consists
personal info of customer
1) Company code data
consists financial information
of the customer
1) Sales area data consists of
sales info of the customer
2) General data is further
classified into 7 tab pages
i. Address
ii. Control data
iii. Payment transaction
iv. Marketing
v. Unloading point
vi. Export data
vii. Contact person
2) Company code data is
divided into 4 tab pages
i. Account Management
ii. Payment transactions
iii. Correspondence
iv. Insurance
2) Sales area is further
classified into 4 tab pages
i. Sales
ii. Shipping
iii. Billing
iv. Partner functions

Creating Customer in SAP:
T.Code: XD01
Select Account group and give company code and sales area and press enter.
Whenever we create customer for the first time with new organization structure we will get the
error message as "sales area is not define for customer".
To solve this error go to
Path: SPRO> S&D > Master Data > Define Common distribution channels and divisions
Select our sales organization and assign the same distribution channels in "Dch-conds & Dch-
cust/mt" and save.
And also define common divisions.

Go to your sales organization and divisions and assign same divisions in "Div-con & Div-cust".
GENERAL DATA:
1. Address: This tab consists of customer name, address and communication information.

3. Control data: This tab consists of the tax information of the customers.
3. Payment Transactions: This tab consists of the bank details of the customers and the
payment card details. This tab consists customer payment details.

4. Marketing:
i. Nielsen ID: This field helps to track the customers who are located in market survey regions.
Whenever company launches a new product we will do market survey in specified regions
(locations). By using this field company can track all the customers who are in market survey
region and send samples to customers and will take results from them.
Path: SPRO > S&D > Master Data > Business partners > Customers > Marketing > Define
Nielsen ID
ii. Customer Classification: Classifying the customers based on their sales turnover.
Purpose of customer classification is
a. Pricing (discounts)
b. Reporting (Analysis)
c. Fixing Credit limits

Note: User creates master data. SD consultant’s job is they need to define all new entries in the
required fields as per the client requirement.
Path: SPRO > S&D > Master data > Business partners > Customers > Marketing > Define
customer classification
iii. Industry: Classifying the customer based on the Industry.
The purpose of this field is
a. Reporting (analysis)
b. Pricing
iv. Industry code 1: This field is sub classification of Industry.
v. Regional Market: Classifying the customer’s location into A-class, B-class, or C-class.
The purpose of this field is analysis.
We don’t have any entries here; we just need to enter the class.
vi. Key figures: This is only for reporting purpose. This field will help to compare last year sales
with present year sales.
vii. Legal Status: This field controls whether the customer is registered or not if registered
whether it is a pvt ltd or public ltd or partnership.
5. Unloading Point: It is the place where we unload the goods at customer location. Unloading
Points will help to plan the deliveries to the customers.
In unloading points we need to maintain goods receiving hours of the customers.
Defining goods receiving hours:
Goods receiving hours specify the timings in which the goods can be unloaded at customer’s
location.
Path: SPRO > S&D > Master data > Business partners > Customers > Shipping > Define goods
receiving hours
Goods’ receiving hours helps in performing delivery scheduling.

6. Export Data: If customer is located outside country then we need to maintain data in export
data tab.

7. Contact Person: He is the employee of customer who is responsible for various activities at
the customer’s location.
e.g.: for payments, for sales, for dispatching etc.
COMPANY CODE DATA:
Company code data is further classified into 4 tab pages
i. Account Management iii. Correspondence ii. Payment transaction iv. Insurance

Finance person is responsible to maintain company data.
i. Account management:
Reconciliation account: Reconciliation account in G/L accounting is an account which is
updated parallel to the sub-ledger account for normal account postings.
Whenever we create invoice, system will post the invoice values into accounting. The
accounting entry is
Customer a/c dr.
To revenue a/c cr.
ii. Payment Transaction:
Terms of payment: It is an agreement between company and customer, which is composed of
payment periods and cash discounts.
We also call it as credit period.
Payment History record: If we check this field, system records the payment history of customer
and updates the same information in credit management.

Defining Terms of Payment: We need to define terms of payment and we need to assign the
same in customer master under company code data in payment transaction tab.
Path: SPRO > S&D > Master data > Business Partner > Customers > Billing document >define
terms of payment
Baseline date calculation: It is the day from which system starts calculating payment terms.
Generally base line date is invoice date.
Fixed day: If we mention calendar day here then every month system starts calculating
payment terms from that particular day onwards. Fixed day becomes baseline date.
Additional months: If we mention no. of months here, then system will wait for that many
months and it starts calculating the term of payments.
Default for base line date: Posting date is accounting document creation date.

Document date is billing document creation date.
Entry date is manually entered date in billing document. We use entry dates in month end
activities to post the previous months invoice.
Day limit: It will be used if we want to consider only working days of customer to calculate
payment terms.
E.g.: If customer is working 5 day a week then maintain day limit as 22.
Terms of payments are one of the split criteria for billing document.
SALES AREA DATA: Sales area data is further classified into 4 tab pages.
i. Sales iii. Billing
ii. Shipping iv. Partner function
Sales District: It is a further classification of sales office for the purpose of generating sales
report.
Path: SPRO > S&D > Master data > Business Partner > Customers > Sales > Def sales district
Sales office: Specifies the sales office in which customer exists.
Sales Group: Specifies the sales group taking care of the customer.
Customer Group: Grouping of customers who will share same attributes. The purpose of this
field is reporting and pricing.
Path: SPRO > S&D > Master data > Business partners > Customers > Sales > Define customer
group
ABC Classification: Classifying customers into A or B or C class keeping into consideration his
turnover, his payments, his bulkiness and buying behavior.
Currency: In this particular field we will maintain customer currency. If customer currency
differs from that of company codes currency then we should maintain "exchange rate type".
T.Code for maintaining exchange rate is "OC41".
In sales order and invoice system display the amount in the customer currency. But while
posting the invoice values into accounting, system will convert the document value from
customer currency to company code currency.

Switch off rounding: If we check this field the order quantity of the material will not be
rounded in the sales document.
Order Probability: The probability of the customer confirming the inquiry or quotation item as
part of sales order.
Item Proposal: Listing of items which customers regularly orders for and calling this document
while creating sales order.
Exchange Rate Type: If customer’s currency differs from that of company code then we are
going to maintain exchange rate type.
The standard exchange rate type is "M".

PP Cust. Proc: Determines which product proposal the system uses automatically when you
create a sales document for a customer.
Price Group: Grouping of customers who share same pricing requirement/attributes.
Price group will be used to maintain discounts.
It is also used to simplify the maintenance of conditions records.
Path: SPRO > S&D > Basic functions > pricing > Maintain price-relevant master data field >
define price group
Customer pricing procedure: This field is one of the parameter to determine pricing procedure
in sales document.
Price list: Grouping of customers who will share the same price of the product.
Price list will be used to maintain base price.
E.g.: Dealer price list, distributor price list, institutional price list etc.
Customer Statistics Group: This field controls whether to update customer sales data into LIS
(Logistics Information System) or not.
ii. Shipping:
Delivery Priority: This field helps in classifying the customers based on their priority of delivery.
Generally we classify the customers into high delivery, medium and low delivery priority.
The purpose of this field is it helps to process back orders and rescheduling.
Back order processing is when a high delivery priority customer places order but stock is not
available then we go back to the open orders of low delivery customers and cancel the
confirmations and assign it to high delivery priority customer orders.
Rescheduling is doing the back order process automatically by the system.
Order Combination: By using this field we can combine multiple orders into single delivery. If
we check this field then only system allows combining multiple orders into single delivery.
Shipping Conditions: This is one of the parameter to determine shipping point in sales
document.

Delivering Plant: If we assign delivering plant here it will determine into sales document
automatically.
The criteria for determining plant into sales document.
CMIR > Customer Master > Material Master
First system will check in CMIR, if system finds plant then it determines into sales document if
not then system will check in customer master, if system finds plant then it determines into
sales document. If plant is not found here then system takes from material master.
Relevant for POD: If we check this field customer becomes relevant for proof of delivery i.e., he
sends acknowledgement to the company after receiving the goods. If this field is checked

system will not allow creating invoice until company receives acknowledgement from
customer.
When we create invoice system copies quantity from POD.
T.Code for POD is "VLPOD"
POD time frame: If we mention number of days here and if customer fails to send the
acknowledgement within the time period then system by default considers that
acknowledgement has been received and will allow creating invoice.
But in this case the invoice is raised against delivery document not with POD.
Complete delivery required by law: If we check this field system will not allow creating partial
deliveries.
Partial Delivery per Item: This field controls whether to allow partial deliveries or not and it
also controls how many partial deliveries to be allowed.
If we maintain "C" here then system will not allow partial deliveries, if we maintain "blank" then
system will allow partial deliveries up to 9, if we maintain "D" here then system will allow
unlimited partial deliveries.
Unlimited Tolerance: If we check this field then systems will allow increasing or decreasing the
quantities in delivery without any limitations.
Under delivery Tolerance: If we maintain some percentage here then system will allow
decreasing the quantity in the delivery up to that percentage. If the percentage exceeds then
system will give warning message.
Over delivery Tolerance: If we maintain some percentage here then system will allow
increasing the quantities in delivery document up to that percentage. If that percentage
exceeds then system will give warning message or error message.
iii. Billing Documents:
Rebate: This field is pre requisite to process rebate for the customers.
Invoicing Dates: If the client requirement is to generate invoice on a specific date of every
month for all the dispatches made during the month then we use this field.
Path: SPRO > S&D > Master Data > Business Partners > Customers > Billing document > Define
billing schedule.

Here we are going to define factory calendar using special rulesand assign the same in
corresponding customer master.
Invoicing List Dates: Consolidating all the invoices raised to different bill to parties into one and
sending it to payer.
T.Code - VF21/VF24
Configuration is same as that of invoicing dates.
Inco-terms: It is an international commercial terms which is an agreement between shipper and
receiver for successful completion of deliveries.

Inco terms specify who will take care of what?
E.g.: freight charges, insurance etc.,
An Inco term is one of the split criteria for deliveries. Inco terms will be used to maintain freight
charges (freight condition record).
Terms of Payment: It is an agreement between the company and customer regarding payment
periods and cash discounts.
Payment guarantee procedure: If we maintain this field for the customer, system will not allow
creating delivery until company receives payment guarantee from customers.
Generally payment guarantees are letter of credit (LoC) and Bank guarantee.
Generally foreign customers are applicable for payment guarantee.
Credit Control Area: It is an organizational unit which takes care of all credit management
activities in company code.
Account Assignment Group: This field enables the system to post the sales value of different
customers to the corresponding G/L accounts during revenue account determination
procedure.
For customer account system determine G/L accounts from reconciliation account and for
revenue account system determines G/L account from revenue account determination.
iv. Partner Functions: Partner functions specify the type of partners associated with the
customer.
Default Partner
Specifies a partner as the default for a particular partner function.
When you enter more than one partner for a particular partner function (for example, you
define three different ship-to parties), you can select one partner as the default. During sales or
purchasing processing, if you have defined multiple partners for a partner function, the system
prompts you to choose just one partner. The system presents the default partner as the first
choice in the pop-up window.

Extending Customers to Other sales areas:
T. Code: XD01
* Select account group
* Give the customer number
* Mention Company Code
* Mention sales area

* Enter reference data and create customer master.
Transaction Codes for Customer Master:
Sl. No T. Code Usage
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
XD01
XD02
XD03
XD04
XD05
XD06
XD07
XD99
OVT0
SE93
SE16
Customer Creation mode
Customer Change mode
Customer display mode
Tracking changes in customer master
Blocking or unblocking the customers
Customer flag for deletion
Changing the customer account group
Customer master mass maintenance
Account group for Customer master
To see all Transaction codes
T.Code to see the Table entries

Tables in Customer Master:
Sl.No. Table Table Name
1.
2.
3.
4.
5.
6.
7.
8.
KNA1
KNB1
KNVV
KNVP
ADRC
KNKA
KNKK
KNVS
General Data
Company Code Data
Sales Area Data
Partner Data
Address Data
Customer Master Credit Mgmt.
Customer Master CCA
Customer Master Shipping Data
2.MATERIAL MASTER:
Material Master is integration between SD, MM, PP, FI, CO.
Material Master is created by end users. Defining new entries in material master is done by
consultants.
The length of material code is 18 characters.
Material code logic: The designing of the material code should be user friendly.
For example: Lexime, Vaccine, Revital
4char4char3char3char
LEXI 1020 100 STR
Here LEXI is Product Name, 10-20 is age group, 100 is dosage and STR is packing.
The material code will have both external and internal. While creating material master if we
mention some code then system will treat it as external number. While creating material
master if we leave it blank then system will treat it as internal number and system will propose
the number while saving material master.

We have different types of material types
ROH : Raw Materials
HALB : Semi finished Goods
FERT : Finished Goods
HAWA : Trading Goods
Sales people will take care of only finished goods and trading goods.
Material Master is classified into various views.
Basic Data 1 Sales general plant
Basic Data 2 MM Sales Text SD
Sales Org data 1 foreign trade export
Sales Org data 2 SD
Foreign trade import Plant data storage 1 MM
Purchasing MM Plant data storage 2
MRP 1 Accounting 1
MRP 2 PP Accounting 2 FI
MRP 3 Costing 1
MRP 4 Costing 2 CO
T.Code to create Material Master: MM01

After entering material number, select industry sector and material type and press enter.
In this field we are going to select the views which are required to create a material master
data.
S-Mobile: Solar Mobile
After selecting views click on default values and press enter. If we click on default values
whenever we create new material system proposes views by default.
In next step we are going to give organizational units in which material is going to be created.
Material is created using organizational elements like plant, storage location, sales organization
and distribution channel.

After entering all the required details system enters into material master creation screen.
We'll discuss fields which are required.
Basic Data 1:
Base Unit of Measure: This is the unit of measure in which the product is manufactured and
stored.
Material Group: Grouping of materials which share same attributes/requirements.
Old Material Number: If the material code is different from SAP to Legacy system then in this
field we are going to maintain legacy material code. The purpose of this field is for reference.
Division: If we maintain division here, during the document processing system automatically
proposes division into sales document line item.
Product allocation: Allocating the goods/products to the customers or distribution channels for
future requirements.
X-Plant material status: If we want to block material across all the plants then we maintain x-
plant material status.

Product Hierarchy: Maintenance of product at different levels. The purpose of this field is
reporting and pricing.
Gross Weight: It is the total weight of the product including packing.
Net Weight: It is the actual weight of the product. If we maintain weight here it will be
determined into sales document during document processing.
Gen.Item Cat Group: This field will be used to determine item category in inbound del. process.
Sales Org 1:

Sales Unit: It is the unit in which we are going to sell goods/products to the customers.
If sales unit differs from that of base unit, we need to maintain conversion factors.
Sales unit not vary: If we check this system will not allow changing the sales unit in the sales
document line item.
X-Distribution chain status: If we want to block material for sales across all distribution
channels then we will maintain this field.
The material may be a part under development or one to be discontinued.
DChain specific status: If we want to block material for sales in a specific distribution channel
then maintain this field.
The material may be a part under development or one to be discontinued.
Delivering Plant: If we maintain plant here it will be determined into sales document line item.
The criteria for determining plant into sales document is:
i. CMIR
ii. Customer Master
iii. Material Master
Cash Discount: This field is pre-requisite to determine cash discount condition type (SKTO) into
sales document.
If we check this then only material is relevant for cash discounts.
Tax Classification: This field controls whether the material is relevant for tax or not.
If it is relevant for tax then maintain "1", if it is not relevant for tax then maintain "0".
Min. Order Quantity: If we maintain minimum order quantity here, while creating sales order
system will check sales order quantity with minimum order quantity.
If sales order quantity is less than minimum order quantity then system will give warning
message.
Min. Del. Quantity: If we maintain minimum delivery quantity here, while creating delivery
system will check delivery quantity with minimum delivery quantity.

If the delivery quantity is less than minimum delivery quantity then system will give warning
message or error message depending on the configuration.
Sales Org 2:
Material statistics group: This field controls whether to update material sales data into LIS or
not.
Material Pricing Group: Grouping of materials which will share the same pricing
attributes/requirements. We use this field for group condition concept in pricing i.e., grouping
of several materials for group condition concept.
Volume Rebate Group: We use this field for group rebate concept. Grouping of materials for
the purpose of announcing rebates.

We have 4 types of rebates.
i. Group Rebate (Group of materials)
ii. Material Rebate
iii. Customer Rebate
iv. Independent of sales volume
Account Assignment Group: This field will help to determine G/L account while posting invoice
values into accounting.
When you create invoice, in the background system generates accounting document. And the
accounting entry is
Customer a/c Dr.
To Revenue a/c Cr.
Item Category Group: This field will help to determine item category into sales document.
Pricing Reference Material: If pricing is same for some group of materials then instead of
maintaining pricing for all materials we maintain pricing for one material, and that material is
assigned in the field pricing relevant material for all other group of materials.
Sales General Plant:
Availability Check: This field is pre-requisite to perform availability check in sales document.
Availability check is a process of checking the stock availability of the materials while creating
sales order.
01 - Daily requirement
02 - Individual requirement
KP - No Check
If we maintain it as "01" in material master then system cumulates the sales order quantities of
a particular material in that particular day and updates in single line in MRP.
If we maintain it as "02" in material master then each sales order requirement will be updated
in MRP in a separate line along with the sales order number.
If we maintain it as "KP" then system will not perform availability check.

If we maintain "01" in material master then back order processing and rescheduling is not
possible.
Batch Management: Batch is a unique number generated for the single lot of manufacturing.
The purpose of batch is it helps to track defective goods, expiry dates and also persons
responsible.
If the material is relevant for batch then check this.
Transportation Group: Grouping of materials which has same route and transportation
requirements. This field will help to determine route in sales document.

Loading Group: Grouping of materials which have same loading requirements. This field will
help to determine shipping point in sales document.
Shipping point is determined into sales document based on shipping conditions, loading group
and plant.
Sales Text: In Sales text we can maintain material specifications and this will be copied into
sales document line item.

Purchasing:
Purchasing group: Group of people responsible for different purchasing activities.
Plant specific material status: If we want to block a material in a particular plant then maintain
plant specific material status.
Automatic PO: If we check this, while creating sales order during third party process and IPO
process system automatically generates PO in the background.
Purchasing Value Key: This field will help to send reminders to vendors to deliver the goods on
time.
GR Processing time: After unloading the goods into plant, how much time it will take to receive
the goods into storage location.

MRP 1:
MRP Group: This field will help to determine requirement type into sales document.
MRP Type: This field controls whether the material is relevant for planning or not. If the
material is relevant for planning then maintain "PD", if it is not relevant then maintain "ND".
This field will help to determine schedule line category into the sales document.
This filed also helps in determining requirement type into sales document.
MRP Controller: The person responsible to run MRP.

MRP 2:
Procurement type: This particular field differentiates whether the procurement is internal or
external procurement.
In-house production: It is the time taken to manufacture the goods in house.
Planned delivery time: It is the time taken to deliver the goods from vendor’s location to plant
location.
Safety Stock: It is the minimum stock which company has to maintain to meet the future
emergency requirements.

MRP 3:
Strategy Group: This field controls whether the material is make-to-stock or make-to-order. If it
is MTO maintain strategy group as "20", if it is MTS maintain strategy group as "10".
Strategy group will help to determine requirement type into sales document.
The criteria for determining requirement type into sales document is
i. Strategy Group
ii. MRP group iii. Item category + MRP type
Total Replenishment Lead Time (RLT):It is the total time taken to manufacture the goods and
finally taken into ready stock. This field is one of the parameter to perform delivery scheduling.
Delivery scheduling is the process of determining delivery dates and confirmed quantities into
the sales document.
System considers RLT only if stock is not available. If stock is available it considers loading time
and pick/pack time from shipping point.

Plant data/storage 1:
Storage Conditions: This field is one of the parameter to determine storage location in delivery
document.
Storage location will be determined based on shipping point, plant and storage conditions.
Total shelf life: This field will help to determine expiry date.
Accounting 1:
Valuation Class: This field helps to determine G/L accounts while generating inventory
accounting document. Inventory document generates after PGI.
The inventory accounting entry is

Cost of goods sold (COGS) a/c Dr.
to inventory a/c Cr.
The valuation class for finished goods is "7920"
The valuation class for trading goods is "3100".
Price Control: This field specifies whether the cost of the product is standard or moving
average. Standard cost means fixed cost, moving average cost means fluctuates.
Finished goods price control is standard "S".
Trading goods price control is moving average "V".
If we maintain cost here then it will e determined into sales document with the help of VPRS
condition type.

Creating Material Master Record:
The following are the 3 ways to create Material Master.
1. The Immediate Process T. Code: MM01
2. The Scheduling Process T. Code: MM11
3. The Special Process
Material Types:
Sl. No Material Type Description
1.
2.
3.
4.
5.
6.
7.
8.
FERT
HALB
HAWA
ROH
DIEN
KMAT
VERP
LEER
Finished Goods
Semi-finished Goods
Trading Goods
Raw Materials
Services
Configurable Material
Packaging Material
Empties
T. Codes in Material Master:Material Master Table:
Sl. No T. Code Usage Sl. No Table Description
1.
2.
3.
4.
5.
MM01
MM02
MM03
MM04
MM17
Create Material Master
Change Material Master
Display Material Master
Display the changes made
Mass Maintenance
1.
2.
3.
4.
5.
MARA
MARC
MVKE
MBEW
MDTP
Mat. Master General data
Mat. Master Plant data
Mat. Master Sales data
Material Valuation
MRP Table

3. CUSTOMER MATERIAL INFO RECORD:
T.Code: VD51
We use CMIR if customers are placing order with their own material code. By using CMIR we
maintain customer material code with our material code.
While creating sales order user will enter customer material code then system automatically
determines with our material code.
T.code to create CMIR: VD51.
Path: Logistics > S&D > Master Data > Agreements > Customer Material Info > VD51-create
After giving the details press enter. It will take us to over view screen.

Give the Material number and Cust. Material and click on details if at all we want to maintain
any additional details related to the material.
As seen in the above screen shot, we can maintain details related to the material.
Whatever information we have in CMIR, system will give preference to it while determining it
into sales document.
The fields which we have in CMIR are:
Plant, delivery priority, minimum delivery quantity, partial delivery per item, max. Partial
deliveries, under delivery tolerance, over delivery tolerance, unlimited tolerance, item usage.
In CMIR we can maintain only shipping related views.
Note: We don’t have payment terms fields in CMIR
KNMT is the table for customer material info record

III SALES DOCUMENT:
Structure of Sales Document:
The entire data in the sales document lies at 3 levels:
They are Header Data, Item Data, and Schedule line data.
1. Header Data: Any information which is applicable for the entire sales document is called
Header data.
E.g.: sold-to-party, ship-to-party, document currency, document date etc.,
The source of Header data is from customer master, configuration data and control data
(organizational units).
The table for sales document header data is "VBAK".
The header data will be controlled by document types.
2. Item Data: Item data is the data which applies to particular line item in the sales document.
Even though the general data entered at header level by default applies to all the items in the
sales document, each and every item will have its own related information called item data.
e.g.: Material code, ordered quantity, unit of measure, price, weight etc.
The source of item data is Material master, configuration data, CMIR, condition master
(pricing).
The table for sales document item is "VBAP".
Item data is controlled by Item Categories.
3. Schedule Line Data: Schedule line data gives information about the delivery dates and
confirmed quantities. Depending up on the availability of material each item in the document
will have one or more number of schedule lines.
The source of schedule line data is from configuration data.
The table for sales document schedule line data is "VBEP".

Schedule line data is controlled by schedule line categories.
Status of Sales Document:
We have 3 different types of status for a sales document, they are: "open, being processed and
completed"
"The status of the document depends on the status of the items in the document". If the status
of all the items in the document is "open", the status of the document itself is "open". If the
status of all items in the document is "completed", then the status of document is "complete".
If the status of any one of the items in the document is either "open" or "being processed", the
status of the document is "being processed".
"The status of the item depends on the quantity that has been referenced". If the entire
quantity of item is referenced, the status of the item is "completed". If it is partially referenced
the status of the item is "being processed". If it is not at all referenced, the status of the item is
"open".
Tables in Sales document types:
Sl.No Table Table Name
1. VBAK Sales document Header Data
2. VBAP Sales document Item Data
3. VBEP Sales document Schedule line Data
4. VBUK Sales document header status
5. VBUP Sales document Item status
6. VBFA Document Flow
7. VBPA Sales document Partner Data
8.
9.
KONV
VBKD
Sales document Pricing
Sales document business data

Sales Document Types: T. Code: VOV8
Path: SPRO > S&D > Sales > Sales doc > Sales doc Header > Define sales doc type
Sl.No. Process T.Code Document Type
1. Inquiry VA11 IN
2. Quotation VA21 QT
3. Order VA01 OR
4. Cash Sales VA01 CS
5. Rush Order VA01 RO
6. Returns VA01 RE
7. Credit Memo Request VA01 CR
8. Debit Memo Request VA01 DR
9. Invoice Correction Request VA01 RK
10. Free of charge VA01 FD
11. Subsequent del. free of charge VA01 SDF
12. Consignment Fill up VA01 CF
13. Consignment Issue VA01 CI
14. Consignment Returns VA01 CONR
15. Consignment Pickup VA01 CP
16. Quantity Contract VA41 QC
17. Value Contract General VA41 WK1
18. Value Contract Mat. Specific VA41 WK2
19. Scheduling Agreement VA31 DS
Inquiry: Whenever customer enquires about the product and its specifications and its price
then we create inquiry document in SAP.
Inquiry is an internal document which consists of customer details, material details, quantity
and validity period

Inquiry will be used for reporting purpose.
T. Code: VA11 Document Type: IN
Quotation: Whenever customers enquire about the product, in return we give quotation to the
customers. It consists of customer details, material details, quantities, validity period, price,
terms and conditions.
Whenever we create quotation in SAP, we will send quotation output to customers.
T. Code: VA21 Document Type: QT
Sales Order: If Customer satisfies with quotation then he will place order to the company which
we call it as sales order. Sales order is a legal document.
A sales order is an agreement between company and customer for supplying of goods to
customers.
T. Code: VA01 Document Type: OR
Cash Sales: We also call it as counter sales.
Customer walks into the outlet picks the goods, pays cash at counter, takes goods along with
him.
T. Code: VA01 Document Type: CS
Rush Order: It is also called as immediate delivery or express delivery order.
When customer wants delivery immediately then we do rush order process.
T. Code: Va01 Document Type: RO
Returns: It is the process of taking the goods back from the customers. The below scenarios we
take goods back from the customers.
i. Damaged goods ii. Defective goods iii. Expired stock
Whenever customer finds defective/damaged goods, customer will inform to the company,
company will send employee, then customer place the defective goods for cross check. After
cross checking, employee will prepare return note.
Return note contains the details of material and quantity. This return note is signed by
customer and employee and submits to the company.

Process: Return order > Return delivery > Return Invoice
Return invoice is with reference to return delivery.
T. Code: VA01 Document Type : RO
Credit Memo Request: We do credit memo request if we want to deduct amount from
customers outstanding. The below scenarios where we deduct amount from customers
outstanding.
i. If goods are totally damaged which are not in a position to take back.
ii. User mistakenly overcharged in previous invoice.
Process: Credit memo request > Credit memo.
T. Code: VA01 Document Type: CR
Debit Memo Request: We do debit memo request, if we want to add amount to customers
outstanding. The below scenarios we add the amount to customers outstanding.
i. Interest charges.
ii. User mistakenly undercharges the previous invoice.
Process: Debit memo request > Debit memo
T. Code: VA01 Document Type: DR
Invoice Correction Request: We do this process if there is any correction required by previous
invoice. It can be adding amount to customer’s outstanding or deducting amount from
customers outstanding.
Process: Invoice correction request > Credit memo
T. Code: VA01 Document Type: RK
Free of Charge: We also call it as sample process.
We do free of charge if we want to send the goods to the customers without charging. Free of
charge is not relevant for billing.
Process: Free of charge > Delivery > Pro-forma Invoice (Dummy Invoice)
Pro-forma invoice is a dummy invoice which will not post values to according.

T. Code: VA01 Document Type: FD
Subsequent Delivery Free of Charge: It is a replacement of return goods to the customers
without charging.
We do this process whenever customers return the goods instead of deducting the amount
from customers outstanding. If we want to replace the same quantity of goods to the
customers without charging.
We create subsequent delivery free of charge with reference to invoice.
Process: SDF > Delivery > Pro-forma invoice
T. Code: VA01 Document Type: SDF
Consignment: Dumping the stock at customers place and keeping ownership with the company.
i. Consignment Fill up
ii. Consignment Issue
iii. Consignment Returns
iv. Consignment Pickup
i. Consignment Fill up: Consignment fill up is dumping the stock at customers place and keeping
ownership with the company i.e., delivering the goods to the customers without charging and
without raising the invoice.
Process: CF > Delivery > Pro-forma Invoice
T. Code: VA01 Document Type: CF
ii. Consignment Issue: If our customers sold consignment goods to their customers then we do
consignment issue i.e., we transfer ownership to our customer (we create invoice to our
customer).
Process:CI > Delivery > Invoice
T. Code: VA01 Document Type: CI
iii. Consignment Returns: If end customer returns the consignment goods to our customer then
we do consignment returns.
Process: CONR > Return delivery > Return Invoice

T. Code: VA01 Document Type: CONR
iv. Consignment Pickup: If customer asks company to take back the remaining consignment
stock then we do consignment pickup process.
Process: CP > Return delivery
T. Code: VA01 Document Type: CP
Quantity Contract: It is an agreement between the company and the customer for supplying
the goods of a specific quantity for a specific period of time.
Any agreement there should be mutual benefits for both the parties. Here the benefit for the
company is assured sales and the benefit for the customer is discounts.
Process: QC > Release Order > Delivery > Invoice
T. Code: VA41 Document Type: QC
Value Contract: It is an agreement between company and the customer for supplying the goods
of a particular value within a specific period.
Process: Value contract > Release order > Delivery > Invoice
T. Code: VA41 Document Type: WK1 (Value contract General)
WK2 (Value contract material specific)
Scheduling Agreement: It is an agreement between company and the customer for supplying
the goods of a particular quantity with in a specific period with pre-defined delivery dates and
confirmed quantities.
Process: DS > Delivery > Invoice
T. Code: VA31 Document Type: DS
Functionality of Sales Document Types:
T.Code: VOV8
Path: SPRO > S&D > Sales > Sales document > Sales document header > Def. Sales document
types
1. SD document category: The document category controls the functioning of the sales
document.

The document category for an Inquiry is "A"
The document category for Quotation is "B"
The document category for Order is "C"
The document category for Returns is "H"
The document category for credit memo is "K"
The document category for debit memo is "L"
The document category for free of charge/Sub. Free of charge delivery is "I"
The document category for Contracts is "G"
2. Sales document block: If we want to block any sales document types for creating sales
document then maintain "X".
Number system:
3. Internal/External number range: In sales document we have option of both internal and
external number. Internal number means system proposes the number while saving the
document. External means user has to maintain the number manually while creating the sales
document.
4. Item number Increment: This field controls how the line item number should be
incremented in the sales document.
5. Sub item number increment: This field controls how the sub item number should be
incremented into the sales document.
Sub item concept comes in BOM, Free Goods, and Material Determination and cross selling.
General Control:
6. Reference Mandatory: This field controls whether any preceding document is required or
not to create a sales document.
The standard SDF and RK will have reference mandatory.
SDF: Reference mandatory is "C" RK : Reference mandatory is "M"

7. Check Division: It control how system should respond if the division in the header changes
from the division in the item. i.e., whether to give warning message or an error message or no
message at all.
Blank: No message; 1: Warning message; 2 : Error message.
8. Item Division: If we check this the line item division will be copied from material master. If
we uncheck this the division in the line item will be copied from header division.
9. Probability: This field controls what is the chance of converting the document into order.
10. Read Info Record: If we check this system will red customer material info record and
determines it into sales document. If we uncheck this system will not determine CMIR
information to sales document.
11. Check credit limit: This field controls whether to process simple credit check or automatic
credit check. This field will be used in credit management concept.
Credit management is managing credit limits of customers. It can be configured in two ways.
a. Simple credit check
b. Automatic credit check

Simple Credit check: In simple credit check, if customer credit limit exceeds we can block only at
order level.
In simple credit check there is no concept of risk categories.
In simple credit check system considers only receivables while performing credit check.
Receivables mean open items. Open items means invoice raised but not yet paid by the
customer.
Automatic Credit check: If customer credit exceeds we can block at order level, delivery level or
PGI level.
In automatic credit check we have risk categories.
In automatic credit check system considers open item values, open delivery values, open
invoice values and open order values.
If we want to process simple credit check then we should maintain either A or B or C.
A - Run simple credit check and give warning message
B - Run simple credit check and give error message
C - Run simple credit check and assign delivery block
If we want to process automatic credit check then maintain D.
12. Credit Group: This field specifies which transaction to block if the customer’s credit limit
exceeds.
13. Check Purchase order number: If we maintain this then while creating sales order system
will check the PO Number in the database. If the same purchase order exists then system will
give warning message. This field will help to restrict the duplication of sales order.
14. Enter PO Number: If we check this then if PO Number is blank in sales order, then system
copies sales order number as PO Number. This will help to track the sales orders for which we
did not receive PO from the customer.
15. Commitment Date: If we maintain this, we will get extra field in schedule line data i.e.,
committed quantity. Any order with committed quantity will be given first preference while
dispatching goods to customers.
16. Screen sequence group: This field controls what screen to be determined basing on sales
document type.

17. Display Range: This field controls whether to display all items or main items or selected
items. This field will be used where you have main items and sub items concept.
18. Incompletion Procedure: It consists list of mandatory fields which user has to enter while
creating sales document. If any of the listed field is missing in the sales document then system
will give message to enter the mandatory field.
19. F.Code for overview screen: Function code
This field controls what could be the default tab system should propose while entering into the
sales document.
20. Transaction group: It controls the T.Code of the sales document type.
21. Quotation messages: If we maintain this while creating sales order system checks whether
any open quotation are existing or not for particular customer. If yes, system will display the list
of open quotations.

22. Outline agreement messages: If we maintain this while creating sales order system checks
whether any open agreements are existing or not. If yes, system will propose the list of open
agreements.
23. Document Pricing Procedure: This field is one of the parameter to determine pricing
procedure in sales document.
The pricing procedure is determined based on sales area, document pricing procedure and
customer pricing procedure.
24. Status Profile: It is a document release process. After creating sales order by the user the
order will be sent to authorize people. The authorized person has to cross check the order. If
everything is fine then they will release the order. Then only system will allow creating delivery
and invoice.
25. Alternate sales doc1/ Alternate sales doc2:These fields will help to shift the sales
document from one document type to another document type.
EX: User has created sales document with document type OR, later he comes to know that this
is not normal order and it is a cash sale order. Then instead of going out from the sales
document, by using this functionality we shift the sales document from OR to CS.
26. Incompletion message: If we check this system will not allow to save the sales document if
any of the mandatory field is missing. If we uncheck this system will give an option to save an
incomplete document or to edit the document.
27. Variant: Variant will help to control the fields in sales documents i.e., whether to make it
mandatory, optional, display or suppress.
The T.Code for creating transaction variant is "SHD0".
Shipping:
28. Delivery Type: If we assign delivery type here, it automatically determines while creating
delivery documents.
The standard delivery type is "LF"
Return delivery type is "LR"
Delivery without order returns is "LO"
Stock Transfer: Transferring the stock from one plant to another type.

Stock transfer delivery type is "NL"
Stock transfer returns delivery type is "NLR"
Intercompany stock transfer delivery type "NLCC"
Intercompany stock transfer returns delivery type "NCR"
Intercompany stock transfer is nothing but stock transfer between the two company codes.
29. Delivery Block: If we maintain delivery here it automatically blocks the order for delivery.
The authorized person has to cross check the order and release the delivery block. Then only
system will allow creating delivery.
30. Immediate Delivery: If we check this then delivery will be created automatically in the
background while creating sales order.
We check this for cash sales (CS) and Rush Order (RO).

31. Shipping conditions: This field helps to determine shipping point into sales document.
If we maintain shipping conditions here it over writes the shipping conditions in customer
master while determining shipping point into sales document. We maintain shipping conditions
in sales document type only for CS and RO. The reason is to determine immediate shipping
point.
32. Shipping cost info profile: We use this field in transportation. This field will help to plan
shipment during order.
Billing
33. Billing Type: If we maintain billing type here it automatically determines billing type while
creating billing document.
The standard billing type is "F2"
Returns billing type is "RE"
Cash sale billing type is "BV"
Credit memo billing type is "G2"
Debit memo billing type is "L2"
Pro-forma Invoice is "F8" (Delivery related)
Pro-forma Invoice is "F5" (Order related) Intercompany invoice is "IV"
Standard process is delivery related billing.
Rush order, consignment issue are delivery related billing.
Return process, cash sales process, credit memo, debit memo, third party and consignment
returns are order related billing.
34. Billing Block: If we maintain some parameter here then it automatically blocks the order for
billing.
The authorized person has to cross check the order and release the billing block, then only
system will allow to create billing document.
In standard all complaint process will have billing block.
EX: RE, CR, DR, RK

35. Condition type line items: We have two cost condition types "EK01" and "EK02".
We use "EK01" if selling price is totally dependent on cost, and if we use "EK02" if selling price
is not dependent on cost.
36. Billing plan type: We have two types of billing plans
a. Periodic billing (Billing on regular intervals)
EX: Service contracts, Rental contracts etc., (monthly billing)
b. Milestone billing (Activity based billing i.e., based on work done)
Requested delivery date/Pricing date/Purchasing date
37. Lead time in days: If we maintain lead time in days here then it over writes the RLT in
material master while performing delivery scheduling.
38. Propose delivery date: If we check this system proposes today's date as requested delivery
date while creating sales document.
39. Propose PO date: If we check this then system proposes today's date as PO date while
creating sales document.
If we uncheck this system will not propose PO date.
40. Date Type: This field controls in which format the delivery date should be proposed into
sales document i.e., whether it should propose day format, week format or month format.
41. Proposal for pricing date: Pricing date will help to determine valid price on that particular
date.
42. Indicator: If we maintain indicator as "D". It controls each line item from invoice will be
copied as two line items in invoice correction request document.
These are the important fields in sales document type. The important thing which we need to
do is comparing one sales document type to another sales document type in order to get
perfection in sales document types.

Item Category:
Item data of the sales document is controlled by item category.
Every line item in the sales document should have item category. Without item category system
will not allow to save the sales document.
T.Code: VOV7
Path: SPRO > S&D > Sales Documents > Sales document item > Define item categories
Item categories are of two types:
a. Document type related item categories
EX: Inquiry, Quotation, Order, Rush Order, Cash Sales, Returns, Credit memo request, Debit
memo request, Invoice correction request, Free of charge, Subsequent free of charge delivery,
Quantity contract, Value contract general, Value contract Material specific, Scheduling
agreement, Consignment fill up, consignment issue, consignment pickup and consignment
returns.
b. Special Item categories (Process related item categories)
EX: Free goods, Third Party, Individual Purchase Order (IPO), and Make to Order (MTO), Text
Item, BOM Item categories, Material determination, Stock transfer order and Intercompany
stock transfer.
Now we shall see all item categories which are document related as well as special item
categories.
a. Document related item categories
Sl.No Process Document Type Item Category
1. Inquiry IN AFN
2. Quotation QT AGN
3. Order OR TAN
4. Cash Sale CS BVN
5. Rush Order RO TAN
6. Returns RE REN

7. Credit memo request CR G2N
8. Debit memo request DR L2N
9. Invoice Correction request RK G2N
10. Free of Charge FD KLN
11. Subsequent free of charge delivery SDF KLN
12. Quantity Contract QC KMN
13. Value Contract General WK1 WKN
14. Value Contract Material specific WK2 WKN
15. Scheduling agreement DS LPN
16. Consignment Fill up CF KBN
17. Consignment Issue CI KEN
18. Consignment Pickup CP KAN
19. Consignment Returns CONR KRN
b. Special Item categories:
1. Free Goods item category: TANN
2. Third Party item category: TAS
3. Individual purchase order: TAB
4. Make to Order : TAK
5. Text Item : TATX
4. BOM Header Pricing BOM Item Pricing
Computer TAQ Computer TAP
CPU TAE CPU TAN
Monitor TAE Monitor TAN
Mouse TAE Mouse TAN

5. Material Determination
Header Pricing Item Pricing
X TAX X TAPA
Y TAPS Y TAN
6. Stock Transfer order Item categories
STO Item Category : NLN
STO Returns : NRN
Intercompany STO : NLC
Intercompany STO Returns: NCRN
Item Category Controls: Business Data
1. Item Type: This field controls functioning of the line item i.e., whether it is normal item or
text item or value item or packing item.
Standard item is the item which we sell to the customers.
Text item is the item which we never sell to the customer but we send it to the customer along
with the main product. EX: User manuals, product catalogs etc.,
Value item is the item which we never sell to the customer but we send it to the customers
which will have some value. EX: Gift vouchers
Packing item is the item which is used to pack the finished the goods and customer has to
return after consuming the goods. EX: Soft drink bottles, Cylinders etc.,
2. Business Item: This field controls whether to change the business data at item level or not.
Business data is the data which copies from sales tab, shipping tab and billing tab of customer
master into the sales document.
If we check this system will allow changing business data at item level. If we uncheck this
system will not allow changing the business data at item level.

3. Completion Rule: This field controls when the status of the line item should be completed.
The completion rule for inquiry, quotation, order and contracts is
IN - AFN - A: Item is completed with the first reference
QT- AGN - B: Item is completed after full quantity has been referenced
QC-KMN - C: Item is completed after the target quantity is fully referenced
WKN - E: Item is completed after full target value is referenced.
Note: Completion rule is applicable only between sales document to sales document i.e., if the
target document is also sales document then completion rule is applicable. That is the reason
TAN doesn’t have completion rule. Because after order we create delivery which is not a sales
document.
This field will have relationship with "+ or - quantity" field in copy controls.
4. Schedule line: This field controls whether the item is relevant for schedule lines or not. If we
check this it is relevant for schedule lines and system proposes schedule line tab in sales

document. If we uncheck this the schedule line tab will not be determined into sales document
line item.
The below item categories will have schedule line allowed uncheck.
Credit Memo: G2N Text Item: TATX Value Contract: WKN
Debit Memo: L2N Quantity Contract: KMN Invoice correction Request: G2N
Whenever schedule line is unchecked, system considers the sales document quantity as target
quantity. If we check schedule line allowed then system considers sales document quantity as
order quantity.
5. Special stock: We have two types of special stocks
a. Consignment stock, the indicator is "W"
b. Orders on Hand, the indicator is "E"
a. Consignment stock is the stock kept at customers place but ownership remains with the
company.
We assign special stock indicator "W" to the following item categories:
Consignment Issue : KEN
Consignment Returns : KRN
When we do consignment issue system will deduct the stock from consignment stock not from
unrestricted stock. This happens with the indicator "W".
In consignment returns the stock will be added to the special stock (Consignment stock). It also
happens with special stock indicator "W".
Make to Order or Order on Hand is the stock which will not maintain it as unrestricted stock. It
is the stock which we reserve to that particular sales order number.
We assign special stock indicator "E" to the following item categories:
Make-to-Order : TAK
Individual Purchase Order: TAB
In Make-to-Order and IPO the stock should be reserved to that particular sales order number.
While creating delivery system will check the sales order stock not unrestricted stock.

6. Item relevant for delivery: This field is applicable only for text item or value item. This field is
not applicable for standard item.
If text item or value item is relevant for delivery then we have to check this field, because text
item and value item schedule lines allowed is unchecked. So, with this field we can deliver the
text item or value item to the customer.
Note: While creating order for text item, enter only description in line item and save the order
and do the delivery.
7. Billing Relevance: This field controls whether the item is relevant for delivery or not, and it
also controls whether it is a order related billing or delivery related billing.
The controls of billing relevance are as follows:
Blank - Not relevant for billing
A - Delivery related billing
B - Order related billing-status according to the order quantity
C - Order related billing-status according to the target quantity
D - Pro-forma Invoice
F - Order related billing-status according to the invoice quantity
G - Order related billing of the delivery quantity
K - Delivery related invoices for partial quantity
Item categories which are not relevant for billing:
Inquiry : AFN Consignment Issue : KBN
Quotation : AGN Consignment Pickup : KAN
Text Item : TATX STO : NLN
Quantity Contract : KMN BOM Header : TAE
Value Contract : WKN BOM Item : TAP
Free of Charge : KLN

Note: In STO, Free of charge and Consignment Fill up standard SAP says item is not relevant for
billing. But in Indian scenarios we have to raise at least proforma Invoice to deliver the goods.
For these three item categories (NLN, KLN, KBN) we have to maintain billing relevance as "D"
Item Categories relevant for delivery related billing:
Standard Order: TAN - A IPO: TAB - A
Rush Order: TAN - A MTO: TAK - A
Consignment Issue: KEN - A BOM Header : TAQ - A
Scheduling agreement: LPN - A
Item categories relevant for order related billing:
Cash Sale: BVN - B Credit Memo: G2N - C
Returns: REN - B Debit Memo : L2N - C
Consignment Returns: KRN - B Third Party: TAS – F
Third Party without shipping Notification:
Company (1) PR (2) PO (3) MIRO (6)
Invoice
Order (Vendor Invoice company)
Invoice to customer (7)
Customer Vendor (4)
Delivery (5)
TAS: F (Billing relevance)
Billing relevance "F" controls, while creating invoice to customer in third party process system
will check whether MIRO (Vendor invoice to company) has been created or not. If MIRO is
created then only system will allow creating invoice to customer. If MIRO not created then
system will not allow creating invoice to customer. The reason why system is checking MIRO is
for delivery confirmation. Because in third party process vendor is directly delivering the goods

to the customer. Before creating invoice to the customer we should know how much quantity
vendor has delivered to the customer. The quantity which vendor delivered to the customer is
the quantity vendor is going to raise invoice to the company. That is the reason we do MIRO
while creating invoice to the customer in third party process.
Third Party with shipping Notification:
TAS: G (Billing relevance)
If we want to process Third party process with shipping notification the billing relevance is "G".
Company (1) PR (2) PO (3) MIGO (6)
Order Shipping Notification
Invoice to customer (7)
Customer Vendor (4)
Delivery (5)
Billing relevance "G" controls, while creating invoice to customer in third party process system
checks whether MIGO has been created or not.
If created, then only system will allow creating invoice to customer.
If not, system will not allow creating invoice to customer.
Billing relevance: K
If we maintain billing relevance as "K", system allows creating partial invoices for single
delivery.
8. Returns: If we check this system treats the line item as returns item and system will deduct
the amount from customers outstanding.
The below item categories will have return check:
Returns - REN Consignment Pick - KAN
Consignment Returns - KRN Credit Memo - G2N
Q. Sales document value is showing in negative, what could be the reason?

A. For item category TAN, returns field might have checked.
Note: Returns field will have relationship with document category in sales document type. Any
document type with document category "H/K" should have returns checked in corresponding
item category.
9. Billing Plan Type: We have similar filed in sales document types. If we maintain billing plan
type in sales document type then in will be applicable to total document.
If we maintain billing plan type in item category then it will be applicable only to a particular
line item.
10. Weight/Volume relevant: If we check this particular field in item category systemcalculates
the weight/volume of the material and determines the same into the sales document line item.
If we uncheck this system will not calculate weight/volume.
11. Billing Block: We have similar field in sales document type. If we maintain billing bock in
sales document then it will be applicable to the whole document.
If we maintain billing block in item category it will be applicable to particular line item in the
sales document.
12. Credit Active: This field controls whether to update line item value into the credit
management or not.
If we check this the line item value will be updated in the credit management.
If we uncheck this the line item value will not be updated in the credit management.
The item categories which will have Credit Active Check are:
Standard Order: TAN Scheduling agreement: LPN
Consignment Issue: KEN Debit Memo: L2N
Make to Order: TAK BOM Header: TAQ
Third Party: TAS Material Determination Header: TAX
Individual Purchase Order: TAB

Item categories which don't have credit active are:
Inquiry: AFN Value Contract: WKN
Quotation: AGN Returns: REN
Cash Sales: BVN Text Item: TATX
Consignment Fill up: KBN Scheduling agreement: KLN
Quantity contract: KMN Credit Memo: G2N
13. Determine Cost: This field controls whether to determine the cost of the product (cost
condition type) into sales document or not.
If we check this then VPRS condition type will be determined into sales document.
This field will have relationship with requirement field in pricing procedure.

Q. The client requirement is, any customer if they purchase slow moving items the value should
not be updated in credit management?
A. For the above requirement we copy TAN to YTAN, where we uncheck credit active and
determine YTAN for slow moving item. And the item category for the slow moving item should
ZORM (we can give any code not mandatorily ZORM) not NORM.
X A - 2, 00,000/- TAN Customer Credit: 5, 00,000
Slow moving item B - 1, 00,000/- In this case only 3, 00,000 will be updated in
YC - 1, 00,000/- YTAN credit management
14. Pricing: This field controls whether the material is relevant for pricing or not. And it also
controls whether the material is 100% discount (Free Goods)
If the material is relevant for pricing then maintain "X"
If the material is not relevant for pricing then maintain "blank"
If the material is free goods then maintain "B"
The item categories which are not relevant for pricing are:
Free of Charge : KLN BOM Header : TAE
Text Item : TATX BOM Item : TAP
Consignment Fill up : KBN Material Determination Header : TAPS
Consignment Pickup : KAN Material Determination Item : TAPA
The item category which is relevant for 100% discount is TANN; pricing field is "B".
Any item category if the pricing field is "B" then "R100" condition type determines into sales
document and makes the line item value "Zero".
If pricing field is "Blank" then system will not determine pricing into sales document.
Note: This field will have relationship with "Requirement" field in pricing.
15. Statistical Value: If we maintain "X" for this field, then the line item value will be inactive, it
doesn't have any effect on net value.
Q. The client requirement is they have BOM header, when they enter main item (EX: Computer)
system explodes all sub items (EX: monitor, keyboard, mouse etc.,). System proposes price for

only main item and components value is zero, because item category TAE is not relevant for
pricing. But client wants to determine price of components also into sales document and it
should not have any effect on net value?
A. In item category TAE, maintain indicators pricing: X
Statistical Value: X
Q. The client requirement is they have sample process (Free of charge) while creating sample
process system will not determine pricing. Because KLN item category is not relevant for
pricing. But management is asking report like every month what is the value of samples we
send to the customer?
A.In item category KLN, maintain indicators pricing: X
Statistical Value: X
16. Automatic Batch Determination: If we check this the batch number will be determined
automatically into sales document.
Generally we don't determine batch in sales document. We determine batch in delivery
document.
17. Rounding Permitted: If we check this system will convert the quantity decimals to the
nearest number.
18. Order quantity=1: If we check this system will restrict the order quantity to "1".
19. Status Profile: If we maintain status profile in the item category then it will be applicable to
each and every line item. The authorized person has to release each and every line item. Then
only system will allow creating delivery and invoice.
20. Create PO automatically: If we check this field, during third party process while creating
sales order system automatically generates purchase order.
21. Structure Scope: This field controls whether to explode BOM or not, and it also controls
whether to explode single level BOM or multi-level BOM.
We maintain structure scope for TAQ and TAP.
Blank: Do not explode
A: Single level BOM B: Multilevel BOM

22. Value Contract Material: This field is only applicable for value contract general WKN. If we
maintain material here then it will be determined into value contract general as dummy
material. Because value contract general is not specific to one material and without material we
cannot create document. That is the reason we determine dummy material from item category.
23. Contract release control: This field controls how system should respond if the order value
exceeds the value contract value i.e., whether to give warning message or an error message.
Blank: No message
A: Warning message
B: Error message
For understanding item category controls in better way try to compare with each other. Then
we can get the differences between the item categories.
Item Category Determination: While creating sales order the item category will be determined
automatically into sales document. Without item category system will not allow to create a
sales document.
The item category will be determined based on following parameters:
- Sales Document
- Item category group
- Item Usage = Default item category
- Higher level item category
- Item category group: We have item category group in material master sales org2 view.
The standard Item category group: Norm
BOM Header Pricing (main item): ERLA
BOM Item pricing (main item): LUMF
Third party item category group: BANS
IPO item category group: BANC
Make to Order Item category group: 0001

- Item Usage: System considers item usage whenever sub item is automatically determining
into sales document other than BOM.
The scenarios where sub item automatically into sales document other than BOM:
a. Free Goods - FREE
b. Cross Selling - CSEL
c. Material Determination: Header Pricing - PSHP (Main item)
PSEL (Sub item)
Item Pricing - PSA1 (Main item)
PSA2 (Sub item)
System considers item usage if you want to determine different item category with the same
combination of sales document type and item category group.
- Higher level item category: System considers higher level item category while determining
item category for sub item.
The below scenarios where sub item appears
a. BOM
b. Free Goods
c. Cross Selling
d. Material Determination
The item category determination is "VOV4".
Path: SPRO > S&D > Sales > Sales documents > Sales document Item > Assign item category
In item category determination we have 4 scenarios:
1. Item category determination based on only sales document.
2. Item category determination based on sales document type and item category group.
3. Item category determination based on higher level item category.
4. Item category determination based on item usage.

Q. The client requirement is any customer if they purchase slow moving material they don't
want to update the item value into credit management?
A. i. For this requirement copy TAN to YTAN and remove credit active check
ii. Create new item category group. Say for example ZORM, and assign this item category
group ZORM in slow moving material.
iii. Go to item category determination and maintain the combination of
OR ZORM ---- ---- YTAN
Let us discuss item category determination scenario wise:
1. Item category determination based on sales document type:
Sl.No Sales doc type Item cat group Item usage Higher level item
category
Default item cat
1. IN NORM __ __ AFN
2. QT NORM __ __ AGN
3. OR NORM __ __ TAN
4. CS NORM __ __ BVN
5. RO NORM __ __ TAN
6. RE NORM __ __ REN
7. CR NORM __ __ G2N
8. DR NORM __ __ L2N
9. RK NORM __ __ G2N
10. FD/SDF NORM __ __ KLN
11. SDF NORM __ __ KLN
12. QC NORM __ __ KMN
13. WK1 NORM __ __ WKN
14. WK2 NORM __ __ WKN
15. DS NORM __ __ LPN

16. CF NORM __ __ KBN
17. CI NORM __ __ KEN
18. CP NORM __ __ KAN
19. CONR NORM __ __ KRN
2. Item category determination based on item category group:
Sl.No. Sales doc type Item cat group Item usage Higher level item cat Default Item cat
1. OR NORM __ __ TAN
2. OR BANS __ __ TAS
3. OR BANC __ __ TAB
4. OR 0001 __ __ TAK
5. OR ERLA __ __ TAQ
6. OR LUMF __ __ TAP
3. Item category based on higher level item category:System considers higher level item
category to determine item category for sub item. The sub item concept comes in BOM, Free
Goods, and Material determination and cross selling.
BOM Header Pricing BOM Item Pricing
Monitor TAE Monitor TAN
Mouse TAE Mouse TAN
Keyboard TAE OR Keyboard TAN OR
CPU TAE ERLA CPU TAN LUMF
OR __ OR __
NORM __ NORM __
__ TAQ __ TAP
TAQ TAP
TAE TAN

Item Category determination for Manual free goods:
X TAN OR
NORM
Y TANN OR __
NORM __
__ TAN
TAN
TANN
Multi-level BOM Header Pricing: Multi level BOM Item Pricing:
Mouse TAE Mouse ZTAN
Monitor TAE OR Monitor ZTAN OR
Keyboard TAE ERLA Keyboard ZTAN ERLA
CPU TAE __ CPU ZTAN __
Hard disk TAE __ hard disk TAE __
RAM TAE TAQ RAM TAE TAP
OR OR
NORM NORM
OR __ OR __
NORM TAQ NORM TAP
__ TAE __ ZTAN
TAE ZTAN
TAE TAE

The reason why we are using ZTAN in multi-level BOM item pricing instead of TAN is: If we use
TAN for multi-level BOM item pricing, this combination over writes manual free goods item
category determination. To overcome this we copied ZTAN from TAN for first level components
and the we can determine TAE for second level components.
4. Item category determination based on Item Usage:
System considers item usage to determine item category for sub item. Whenever sub item is
automatically determining into sales document other than BOM.
System also considers item usage to determine different item category with the same
combination of sales document type and item category group.
The scenarios where sub item automatically determines into sales document other than BOM:
a. Free Goods: FREE
b. Cross Selling: CSEL
c. Material determination header pricing: X PSHP
Y PSEL
Material determination item pricing: X PSA1
Y PSA2
i. Automatic Free Goods ii. Cross Selling
X TAN X TAN
Y TANN Y TAN
OR OR OR OR
NORM NORM NORM NORM
FREE __ CSEL __
TAN __ TAN __
TANN TAN TAN TAN

iii. Material det Header Pricing iv. Material det Item Pricing
X TAX X TAPA
Y TAPS OR Y TAN OR
NORM NORM
OR PSHP OR PSA1
NORM __ NORM __
PSEL TAX PSA1 TAPA
TAX TAPA
TAPS TAN
NOTE: Normally system considers item usage automatically while determining item category
based on the process.
EX: Free goods, cross selling, material determination
But at one place we can control item usage manually i.e., CMIR.
Q. The client requirement is, some customers if they purchase come slow moving items system
should not update the value into credit management.
A.1. Copy TAN to YTAN and remove credit active check
2. Create new item usage
Path: SPRO > S&D > Sales > Sales documents > Sales document item > Define item cat usage
(For example: I001)
3. Maintain CMIR for the customer and material combination. Select the material and go to
the details and assign item usage and save.
Do the same thing to the selected customers who are purchasing slow moving items.
4. Maintain item cat determination in the combination of (OR NORM I001 __ YTAN).

Schedule Line Category:
Schedule line data is the data which consists of delivery dates and confirmed quantities.
Schedule line data is controlled by schedule line categories.
Sl.No. Process Doc
Type
Item Cat Schedule line cat
1. Inquiry IN AFN AT - With MRP
AN - Without MRP
2. Quotation QT AGN BT - With MRP
BN - Without MRP
3. Order OR TAN CP - With MRP
CN - Without MRP
4. Returns RE REN DN
5. Consignment Fill up CF KBN E1
6. Consignment Issue CI KEN C1
7. Consignment Pickup CP KAN F1
8. Consignment Returns CONR KRN D0
Stock Transfer – NN STO Returns - NR
Intercompany STO – NC Intercompany STO Returns - NS
BOM Header Pricing: BOM Item Pricing:
TAQ - CP TAP - CT
TAE - PP TAN - CP
Material det Header Pricing: Material det Item Pricing:
TAX - CX TAPA - CD
TAPS - PP TAN - CP

Third Party: Individual Purchase Order:
TAS - CS TAB - CB
T. Code for schedule line category is "VOV6"
Path: SPRO > S&D > Sales > Sales documents > Schedule lines > Define schedule line cat
1. Delivery Block: If we assign delivery block here, it will e applicable to particular schedule line
in the sales document line item. If we assign this the schedule line will be blocked for delivery.
The authorized person has to cross check and release the block. Then only system allows
creating delivery.
2. Movement Type: Every physical movement of goods requires movement type information.
System considers movement type while performing PGI.
Every movement type will have four effects:
a. Stock Updating

b. Inventory accounting management
c. LIS is updated
d. Updates the document flow in the sales document
A. Standard Movement Type: 601 - CP
Effects of movement type 601:
a. Stock will be reduced from unrestricted stock
b. Inventory accounting document generates
The accounting entry is: COGS dr.
To Inventory a/c cr.
The Movement for reverse PGI: 602
a. Stock will be added to unrestricted stock
The accounting entry is: Inventory account a/c dr.
To COGS cr.
B. Returns - DN: 651 (Returns Stock)
Effect of movement type 651:
a. The stock will be added to return stock
b. No inventory accounting document is generated
Returns - DN: 653 (Unrestricted Stock)
a. The stock will be added to un-restricted stock

The accounting entry is: Inventory a/c dr.
To COGS cr.
Returns - DN: 655 (Quality Inspection Stock)
a. Stock will be added to quality inspection stock
To COGS cr.
Returns - DN: 657 (Blocked Stock)
a. Stock will be added to quality inspection stock
To COGS cr.
Q. Why inventory account will not generate for 651(Return Stock) movement type.
A. The reason is return stock is not a permanent stock. Once you receive the goods then we do
analysis then we decide whether to transfer the stock to un-restricted stock or quality
inspection stock or blocked stock. At that time system generates inventory accounting
document.
>Reverse PGR for 651 is 652
C. Consignment Fill up - E1: 631

a. When we do consignment fill up stock will be reduced from un-restricted stock and the stock
will be added to consignment stock.
b. Inventory accounting document will not generated
Consignment Issue - C1: 633
a. Stock is reduced from the consignment stock
b. Inventory accounting document is generated
The accounting entry is: COGS a/c dr.
Consignment Pickup - F1: 632
a. Stock will be reduced from consignment stock and added to the un-restricted stock
b. Inventory document will not generated
Consignment Returns - D0: 634
a. Stock will be added to consignment stock
b. Inventory accounting document is generated
To COGS a/c cr.
D. Stock Transfer: NN
Stock Transfer - Two-step process - NN - 641
In two step process, when we do delivery, in supplying plant the stock is reduced and will be
displayed as stock in transit in receiving plant.

Supplying plant
Delivery w.r.to PO (2)
PO (1) VL10D
MIGO (3)
Goods Receipt
Effects of Movement Type-641:
a. Stock will be reduced from supplying plant and the stock will be displayed as stock in
transit in receiving plant.
b. Inventory a/c document generates.
The accounting entry is: Stock Outward movement cr.
To stock inward movement dr.
Stock Transfer - One Step - NN - 647:(Generally we don't use this process in real time)
In one step process, when we do delivery, in supplying plant the stock is reduced and is
updated automatically in receiving plant.
Delivery w.r.to PO (2)
PO (1) VL10D
Manufacturing
Plant
Depot(receiving
plant)
Supplying
Plant
Receiving
Plant

Effects of Movement Type-647:
a. Stock will be reduced from supplying plant and will be added in receiving plant.
b. Inventory a/c document generates.
The accounting entry is: Stock inbound movement dr.
To Stock outbound movement cr.
Stock Transfer Returns: NR
Two Step Process movement type - 671
Effects of movement type -671:
a. It reduces the stock from receiving plant and it displays the stock as stock in transit in
supplying plant.
b. Inventory a/c generates.
Stock Transfer Returns (One step) - NR - 677
Effects of movement type: 677
a. It reduces the stock from receiving plant and it will be added to the stock of supplying plant
b. Inventory a/c document generates
E. Intercompany STO: NC
Two Step Process - NC - 643
a. Stock will be reduced from supplying plant and stock will be updated as stock in transit in
receiving plant
b. Inventory a/c generates

One Step Process- NC - 645
a. Stock will be reduced from supplying plant and stock will be added to receiving plant
Intercompany STO Returns: NS
Two Step Process - NS - 673
a. Stock reduces from receiving plant and stock will be displayed as stock in transit in supplying
plant
To COGS cr.
One Step Process - NS - 675
a. Stock will be reduced from receiving plant and stock is added in supplying plant
b. Inventory a/c document generates
The accounting document is: Inventory a/c dr.
To COGS cr.
Note: In SD movement type starts with 6 series
In MM movement type starts with 5 and 1 series.
Movement type 561: Initial Stock Upload
Movement type 101: Goods receipt

3. Item relevant for Delivery: This field controls whether the standard item is relevant for
delivery or not. If we check this it is relevant for delivery otherwise it is not relevant for
delivery.
The schedule lines which are not relevant for delivery are:
Inquiry: AT
Quotation: BT
Third Party Sales: CS
NOTE: Any item if we want to display it in delivery document but the stock should not be
reduced. For this requirement, for that schedule line category check item relevant for delivery
and remove movement type.
For this requirement the schedule line category is "CT". In CT we have item relevant for delivery
but we don't have movement type.
4. Order Type: We use this only for third party and IPO i.e., CS and CB.
For CS and CB we maintain order type as "NB".
Order type "NB" will help to generate purchase requisition automatically in the background
while creating sales order during third party and IPO process.
5. Item Category: Without item category system will not allow us to create sales document. In
the same way MM documents also require item category information while creating purchase
requisition manually. MM users will maintain item category manually. But in 3rd party and IPO
we are generating purchase requisition automatically in the background itself. So, we are
passing the item category information from schedule line category to purchase requisition.
If we don't maintain item category here, system will not generate purchase requisition (PR)
automatically in the background.
For third party we maintain item category as 5, item category 5 controls, even if we do MIGO in
3rd party process system will treat it as dummy MIGO and stock will not be updated.
We use item category 5 in third party with shipping notification.
For CB item category is 0. It controls, if we do MIGO in IPO process then stock will be updated.
6. Account Assignment Category: This field will be used only for CS and CB. This field controls
whether to generate inventory accounting document at the time of MIGO and PGI.

For CS the account assignment category is "1"
For CB the account assignment category is "E"
7. Purchase requisition delivery schedule: We check this only for IPO (CB). If we check this the
delivery dates and confirmed quantities information will be copied from sales order to purchase
requisition.
8. Requirement/Assembly: This field is pre-requisite to transfer the requirements to MRP. This
field is also pre-requisite to perform availability check in sales document.
If we check this the sales requirements will be transferred to MRP.
The difference between CP and CN i.e., CP will have Requirement check where as in CN this
field is unchecked.
9. Availability: This field is pre-requisite to perform availability check in sales document. If we
check this then only system will perform availability check.
CP will have availability field checked.
10. Product Allocation: Reserving the stock to customer or customer groups or distribution
channels to meet future requirements. If we want to perform availability check based on the
reservations, then check this field.
Schedule Line Category Determination:
Schedule line category determines based on "Item category and MRP Type". We have MRP
Type in Material Master MRP1 View.
TAN + PD = CP
TAN + ND = CN
The T. Code for Schedule line category determination is "VOV5".
Path: SPRO > S&D > Sales > Sales documents > Schedule lines > Assign schedule line
categories
If item category and MRP type combination is not there, then system will give only preference
to item category while determining schedule line categories.
SAP has provided 9 manual schedule line categories. Manual schedule line categories will help
to change the schedule line category manually into sales document.

Delivery Types:
The structure of delivery document is divided into two parts:
i. Header Data
ii. Item Data
Source of header data is sales document and ship to party.
Source of Item data is sales document and material master.
Delivery Header Table: LIKP
Delivery Item Table: LIPS
Header data is controlled by Delivery types and item data is controlled by Delivery Item
categories.
The standard Delivery Type is "LF"
The standard Returns delivery is "LR"
Delivery without order reference is "LO"
Cash sale Delivery Type is "BV"
STO Delivery Type "NL"
STO Returns Delivery Type is "NLR"
Intercompany STO Delivery Type is "NLCC"
Intercompany STO Returns Delivery Type is "NCR"
Inbound delivery "EL"
The T. Code for delivery type is OVLK
Path: SPRO > logistics execution > Shipping > Deliveries > Define Delivery Types
Delivery Type Controls:
1. Document Category: It controls the functioning of the delivery document.
The document category for LF is J.

The document category for LR is T.
Q. While doing returns delivery how system is proposing post goods receipt tab. Where is the
control?
A. Document Category: T
2. Item Number Increment: This field controls how the line item number in the delivery
document should be incremented.
3. No. Range internal and No. Range external: In delivery document we have option of internal
and external number ranges.

4. Order Required: This field controls whether any preceding document is required or not to
create a delivery.
For LF: Sales order required
For LO: No preceding document is required
For LR: Sales order required
For NL: Purchase order required
For NLR: Purchase order required
For NLCC: Purchase order required
For NCR: Purchase order required
5. Default Order Type: System considers default order type DL, whenever the order required is
not sales order required to determine movement types while doing PGI.
DL > NORM > DLN > CN > 601
System considers default order type DL for delivery types LO, NL, NLR, NLCC, NCR. Because all
these delivery type order required is not sales order required.
6. Item Requirement: This field controls whether to add new line items in the delivery
document or not. If you want to add new line items then maintain item requirement as 202. If
we want to restrict adding new line item in the delivery document then maintain item
requirement as 201.
7. Storage Location Rule: Storage location rule will help to determine storage location in
delivery document.
We have 3 storage location rules:
i. MALA
ii. RETA
iii. MARE
MALA rule specifies that storage location rule is determined based on shipping point, plant and
storage conditions.

RETA rule specifies that storage location is determined based on Plant, situation and storage
condition.
MARE rule specifies that first check MALA if not then check RETA.
Storage location determination:
SPRO > logistics execution > shipping > picking > determine picking location > Assign picking
location
Delivery Item Categories:
The T. Code to define delivery item categories is "0VLP"
The delivery item categories will be same as sales document item categories.

1. Mat. No. 0 allowed: If we check this system will allow creating a delivery without material
number.
2. Item Cat. Statistics group: This field controls whether to update delivery item data into LIS or
not.
3. Check Quantity 0:This field controls how system should respond if the quantity in the
delivery document is zero i.e., whether to give warning message or error message or no
message.
4. Check minimum quantity: This field controls how system should respond if the delivery
quantity is less than minimum delivery quantity which is maintained in material master i.e.,
whether to give warning message or error message or no message.
5. Check Over Delivery: This field controls how system should respond if user is increasing the
quantities in the delivery document more than order quantity i.e., whether to give warning or
error or no message.
This field will have relationship with over delivery tolerance in customer master.
Check over delivery will not work if we check unlimited tolerance in customer master.
6. Availability Check off: This field controls whether to perform availability check for the
delivery item or not. Normally system performs availability check in sales order.
For some scenarios we have to perform availability check in delivery document.
i. Del. without order reference
ii. STO
iii. Adding new line item in del. document
iv. Increasing quantities in delivery document.
Blank: Check availability
X: Do not check
7. Rounding: This field controls whether to round or not to round the delivery quantity.
8. Relevant for picking: This field controls whether the item is relevant for picking or not. If we
uncheck this the picking quantity field in delivery document will be disabled.
The below items are not relevant for picking:

Cash Sale - BVN
Returns - REN
Consignment Pickup - KEN
Consignment Returns - KRN
9. Storage location is required: If we check this field the storage location becomes mandatory
for the delivery item before it can be further processed.
10. Determine storage location: Along with the storage location rule this field will help to
determine storage automatically into delivery document.
11. Don't check storage location: If we check this field the system will not run a check for the
storage location entered for the delivery item.
12. No Batch check: If we check this field the system will not run a check for the batch number
entered for the delivery item.
13. Automatic Batch determination: If we check this field the system automatically determines
a corresponding batch number for the delivery item.
14. Packing control: This field controls whether the item must be packed or cannot be packed
or can be packed.
Delivery Item cat. determination: The delivery item category determines based on
i. Delivery type
ii. Item category group = Default item category
iii. Item usage
iv. Higher level item category
If we create delivery with reference to order then item category will be copied from sales order
to delivery document.
If we create delivery without order reference then only the item category will be determined in
delivery document.
The below scenarios system determines item category in delivery document.
i. Delivery without order reference "LO" LO NORM -- DLN

ii. STO Process
NL NLR NLCC NCRN
NORM NORM NORM NORM
V V V V
-- -- -- --
NLN NLRN NLC NCRN
iii. Adding new line item in delivery document LF NORM -- -- TAN
iv. Batch Split LF NORM CHSP -- TAN
Billing Types: The structure of the billing document will be divided into two parts:
i. Header data
ii. Item data
Billing document header table is VBRK
Billing document item table is VBRP
The standard billing types are:
Sl.No. Description Billing Type
1. Order related billing F1
2. Delivery related billing F2
3. Returns RE
4. Credit Memo G2
5. Debit Memo L2
6. Intercompany IV
7. Pro-Forma (Order related) F5
8. Pro-Forma (Delivery related) F8

9. Invoice Cancellation S1
10. Returns Cancellation S2
11. Credit memo cancellation S2
12. Cash Sale invoice BV
The T. Code for billing type is "VOFA"
Path: SPRO > S&D > Billing > Billing documents > Define billing type
Billing Type Controls:

1. Number range internal assignment: For billing SAP has provided only internal number. The
reason is billing document number should be always in sequence.
2. Item no. Increment: This field controls how item number should be incremented in billing
document.
3. SD document category: This field controls accounting entry by posting invoice values to the
accounting document.
For F2 - M
RE and G2 - O
F5 and F8 - U
If document category is "M" the accounting entry is:
Customer account Dr.
To Revenue account Cr.
If document category is "O" the accounting entry is:
Customer account Cr.
To Revenue account Dr.
If document category is "U" accounting entry is not possible.
4. Posting Block: If we check this the accounting document will not be generated automatically
in the background. The user has to post it manually.
The T. Code to post the invoice values into accounting manually is "VFX3"
5. Statistics: This field controls whether to update billing document data into LIS or not.
6. Document Type: The document type for accounting document is "RV".
7. Negative Posting: This field controls whether to post negative invoice values to accounting
document or not.
8. Relevant for Rebate: This field is pre-requisite to process rebates for a billing type.
9. Invoice List Type: Invoice list is consolidating all invoices raised to the customer during a
particular month into one and sending it to payer.

The invoice list type is "LR".
T. Code for creating invoice list is "VF21/VF24"
10. Cancell. Billing type: The invoice cancellation type is "S1"
T. Code to cancel billing type is "VF11"
11. Accounting det. procedure: Account determination procedure will help to determine G/L
account by posting invoice values into accounting document.
The standard account determination procedure is "KOFI00"
12. Doc. Pricing. Procedure: This field is one of the parameter to determine pricing procedure
in billing document.
The below scenarios we determine pricing procedure in invoice:
i. Delivery without order reference
ii. STO Process
13. Acct. det. reconciliation account: The standard procedure for reconciliation is "KOFIAB"

Normally when we create invoice.
The accounting entry is: Customer a/c Dr.
To Revenue a/c Cr.
For customer account system picks G/L accounts from reconciliation account which we
maintained in customer master.
If the client requirement is reconciliation account should not be determined from customer
master. It should be determined based on some other combination like plant & division or sales
area etc.
For this requirement we need to maintain this field.
14. Acct. det. Cash settlement: We use this field for only cash sale process.
The standard procedure is "KOFIAC"
When we create cash sale invoice.,
The accounting entry is: Cash settlement a/c Dr.
To Revenue a/c Cr.
Split Criteria for Deliveries and Billing (Important)
Split Criteria for Deliveries:
The standard split criteria for deliveries are:
i. Shipping point
ii. Ship to Party
iii. Delivery dates
iv. Inco terms
The activities systemperforms when we do PGI:
i. Stock Updates
ii. Inventory accounting document generates

iii. Updates document flow
iv. Updates in billing due list
v. Updates in credit management
vi. Updates in LIS
Split Criteria for Billing:
The standard split criteria for billing are:
i. Payer
ii. Payment Terms
iii. Invoice Dates
The activities systemperforms when we create invoice:
i. Accounting document generates
Customer a/c Dr.
To Revenue a/c Cr.
ii. Profitability analysis document
iii. Cost center document
iv. Updates in document flow
v. Updates in credit management
vi. Updates in LIS
Restricting no. of line items in Invoice:
Path: SPRO > S&D > Billing > Billing document > Country specific features > Maintain
maximum no. of invoices (billing)
Go to your sales organization and maintain no. of items.

Inquiry to Billing Cycle: 1
Till now we discussed about the basic configurations for SD. No we’ll try to check the process
from Inquiry to Billing.
In order to do the process first we need to post the stock in the plant. So first we will post the
stock which is required to run the cycle.
T. Code to post the stock is "MB1C".
Mention the movement type as 561, plant, storage location and press enter.
When trying to post stock we will get error messages.
Posting Stock:
To create order, delivery and invoice first of all we need to have stock.
T. Code to post the stick is "MB1C".
Mention the movement type as 561, plant, storage location and press enter.
When trying to post stock we will get error messages.
i. Parameters for plant not maintained in inventory management
To solve this go to the path
Path: SPRO > MM > Inventory management > Physical Inventory > Plant Parameters
Select the standard plant "1000/2000" and click on copy and give our plant and save. Maintain
for all our plants.
To solve same error message, follow the path. We need to solve by both the paths.
Path: SPRO > Production > Materials Requirements Planning > Plant Parameters > Carry out
overall maintenance of plant parameters.
Click on copy, mention the standard plant "1000/1200" in from field and mention our plant and
click on copy.
Maintain for all our plants.
a. Go to T. Code "OBY6"

Go to our company code and maintain chart of accounts "INT", fiscal year "V3", field status
variant as "1000", and posting period variant as "1000" and save.
b. Go to T. Code "OMSY"
Go to our company code, mention year (2013) and period as (1).
ii. No stock posting possible for this material
To solve this go to the T. Code "OMS2"
Select the material type FERT and double click on quantity/value updating.
Select our plant (Valuation area), select quantity updating and value updating for our all plants
and save.
Select material type HAWA and double click on quantity/value updation.
Select our plant (Valuation area), select quantity updating and value updating for our all plants
and save.
iii. Account determination for entry INT GBB ________ BSA 3100 not possible
Go T. Code "OMWB" and click on cancel and then click on account assignment.
Search for GBB (transaction) and double click on it, mention chart of account INT and press
enter.
Search for BSA 3100, select that and click on copy and remove 0001 from valuation and save.
iv. Maintain tolerance limits for tolerance key VP in company code
Double click on the error message and click on "Define tolerance limits" and click on "Set
tolerance limits".
Select standard company code with "VP" combination, copy and maintain for our company
code and save.
v. Account determination for entry INT _____ _____ BSX 3100 not possible.
Follow step iii to solve this error.
vi. Number range interval 49 doesn’t exist.
To solve this go to T. Code "FBN1"

Mention our company code and click on "change intervals", click on insert interval, mention the
interval no. 49, year 2013 and mention from and to number and press enter and save.
vii. TRANS/EVENT WE/WA not possible for year 2013.
To solve this go to T. Code "OMBT" and click on change groups.
If it asks for WA select "WA" and click on change button. Place the cursor in 2012, go to edit
and select insert year.
Mention year 2013 and give from and to number and enter and save,
viii. Posting period not open for period 2013 01 for account type S.
To solve this go to T. Code "OB52"
In the second year column change the year to 2014 or 2015 against variant 1000. Change all
years against 1000.
ix. Movement type 601 or 561 and G/L account xxxxxxx is not possible.
To solve this go to T. Code "SE38"
Mention program name as "RM07CUFA" and execute.
Give movement type, G/L account which is shown in the error and give our company code and
execute.
Search for "red color entry" and click on "movement type" and select all tabs as an optional. Go
back and click on a/c and select all tabs as an optional.
x. G/L account 799999 doesn’t exist in company code.
T. Code FS00
G/L account: 799999, company code: 9001
Click on create with template
G/L account: 799999, company code: 1000
xi. Company code not assigned to country or country to calculation procedure.
a. T. Code : OBCL
Select our company code and mention 0% Tax.

b. T. Code : OBBG
Select "country" and assign "tax procedure".
xii. Balancing field "segment" in the line item 001 not filled.
Path: SPRO > Financial a/c (New) > General ledger accounting (New) > Business transactions >
Document splitting > Define document splitting characteristics for general ledger accounting
Uncheck "mandatory" field against the "Field segment".
Errors while Creating Order:
T. Code: VA01
When we are creating sales order for the first time with new organizational unit we will get
some error messages.
i. Order type OR has not defined in sales area
To solve this
Path: SPRO > S&D > Sales > Sales document > Sales document header > Assign sales area to
sales document type > Combine sales orgsn.
In the same way maintain combined distribution channels and combined divisions.
After maintaining combine sales orgsn, combined distribution channels, combine division the
next step is to assign sales order types for sales area. For that follow the same path as
mentioned above.
Then again try to create order
ii. No pricing procedure could be determined.
Go to T. Code OVKK.
Go to new entries and assign pricing procedure RVAA01(standard) in the combination of sales
area, document pricing procedure (A), cust pricing procedure (1) and save.
Again try to create order
iii. We will get the message mandatory pricing condition pr00 is missing
Go to T. Code VK11 and maintain price for the material.

Creation of Inquiry:
T.Code: VA11
Enter the details in the initial screen and press enter, it will take us to overview screen.

When customer enquires about the product we’ll create inquiry document in SAP system with
material details, customer details, price details etc.
Creating Quotation:
T.Code: VA21
Enter the Quotation type “QT” and click on create with reference, system will pop up a new
window where we need to give inquiry number and click on copy so that all the details will be
copied into quotation.

We create quotation and send into the customer with order quantity, order value, payment
terms, price details etc.
If customer satisfies with the quotation he’ll place order. If customer is not satisfied with the
quotation he’ll go for negotiations. If negotiations work out we’ll create another quotation with
the previous quotation. And with reference to that particular quotation we’ll create order.
Creating Order:
We can create Order with reference to quotation or if we want even we create without
referring to quotation.
We’ll create Sales order with reference to quotation.
T.Code: VA01
Enter the order type and click on create with reference; system will pop a window as shown in
the screenshot. Enter the quotation number and click on copy. So that it will copy all the details
for the quotation. If we want we can edit them in the Sales order.
Sales order is a legal document. In sales order system will copy all the details related to the
customer details, material details, order details, terms of payment, delivery dates etc.

Creating Delivery:
In this step we are going to deliver the goods ordered by the customer as per the scheduled
dates.
T.Code: VL01N

By default delivery is created with order reference. When we enter into the overview screen by
default system proposes Item Overview.
Click on picking tab and check the picked quantity. According to the picked quantity the overall
pick status will be changed. If we don’t enter any picked quantity the status will be not yet
picked.
If we enter partial quantity the overall pick status will be partially picked.
If we enter complete quantity the overall pick status will be fully picked.

After picking the quantity click on tab.
Then the delivery has been saved and goods have been issued.
Creating Invoice:
We are going to bill the customer for the delivered quantity.
T.Code: VF01
When we execute the transaction by default system will take the delivery document number.
Press enter it will take us to overview screen.
The above screen shows the overview of the billing document where it gives the net value for
which we billed the customer.
Save the billing transaction. System will generate the accounting document while saving the
transaction. To see the accounting document go to VF02 and check the document.

Pricing
Pricing is based on Condition Technique.
Condition technique is a process of determining condition records into sales document.
Condition technique consists of condition records. Condition records are stored in condition
tables. Condition tables are placed in access sequence from most specific to most general.
Access sequence is assigned to condition type. These condition types are placed in pricing
procedure.
Pricing Procedure V/08
Condition Types V/06
Access Sequence V/07
Condition Tables V/03
Condition Records VK11
1. Condition Record: Condition record is the master data for pricing.
The T. Code to create condition record is "VK11"
2. Condition Table: Condition table is the combination of fields.
Ex: Customer/Material
Price list/Material
Material
The condition table specifies for what combination the pricing should be maintained.
The T. Code to create condition table is "V/03"

3. Access Sequence: Access sequence is a search strategy which will search for valid condition
records from most specific to most general.
Exclusive indicator in access sequence: If we check this, if the system finds valid condition
records at any combination system will come out of search strategy and determines price into
sales document.
If we uncheck exclusive indicator even if system finds valid condition record at any combination
system will not come out of the search strategy. System will go and search all combination of
prices and determines it into sales document.
If it is base price it activates the last one and deactivates the previous one.
If it is discounts/surcharge it activates all.
T. Code to create access sequence is "V/07".
4. Condition Type: Condition type controls the price components or price elements.
i. Base Price
ii. Discounts
iii. Surcharge (Packing, Insurance, loading)
iv. Sales Tax (CST, VAT)
v. Excise Duties
vi. Freight
The standard condition type for Base Price is "PR00"
The standard condition types for discounts are: K004 - Material Discount
K005 - Cust/Material discount
K007 - Customer discount
The standard condition type for freight is "KF00"
The standard condition for sales tax is "MWST"
But for Indian scenarios sales tax is "JCST & JVAT"

5. Pricing Procedure: Pricing procedure consists of list of all the condition types which will be
placed in a sequence.
The T. Code to create pricing procedure is "V/08"
The common T. Code for pricing is "VOK0"
Pricing Procedure Determination:
T. Code : OVKK
We determined pricing procedure with the combination of sales area, document pricing
procedure and customer pricing procedure.
Configuration of Pricing:
1. Creation of Condition Tables:
T. Code : V/03
Path: SPRO > S&D > Basic Functions > Pricing > Pricing Control > Define Condition tables >
Create condition tables
The user define condition table number should be above 500.
Field Catalog: Field catalog consists of allowed fields to create condition table.
650 - Customer/Material
> Click on Generate
> System will pop up a message click on yes
> Condition tables will be saved in workbench request. All workbench requests are cross client.
> If we save condition table in "local object" this cannot be transported from one server to
another server.
> If we save condition table in "package" then system generates request number then we can
transport from one server to another server.
Basis consultant will give packages. With the help of package we can track the enhancements.
> Any condition table by mistakenly if we save in local object and if we want to retrieve it and
change, then go to change mode of condition table.

From menu go to > Object directory entry.
650 - Customer/Material
651 - Price list/Material
652 - Material
2. Access Sequence: Access sequence is a search strategy which will search for condition
records from most specific to most general.
Access sequence is a cross client i.e., if we create access sequence in one client it automatically
updates in other clients with in one server.
T. Code : V/07
Path: SPRO > S&D > Basic functions > Pricing > Pricing Control > Define access sequence >
Maintain access sequence
> Go to new entries and create new access sequence "YR00".
> Select the created access sequence and double click on access.
> Go to new entries and place the condition tables from most specific to most general and
check "Exclusive" indicator.
> Select the condition table and double click on fields. This step we call it as field assignment.
> Do the same thing for other tables.
Access sequence is also saved in workbench request.
3. Create Condition Type: Condition type controls the price elements or price components.
T. Code : V/06
Path : SPRO > S&D > Basic functions > Pricing > Pricing Control > Define Condition Types >
Maintain Condition Types
> The standard condition type for Base Price is "PR00".
> Select standard condition type "PR00" then click on copy and maintain own condition type
"YR00".
> Assign access sequence "YR00" to the new condition type "YR00".

Save the condition type.
4. Define Pricing Procedure:
T. Code : V/08
Path: SPRO > S&D > Basic functions > Pricing > Pricing control > Define and Assign pricing
procedure > Maintain pricing procedure
The standard pricing procedure is "RVAA01"
> T. Code : V/08
> Go to new entries and create procedure "YVAA01".
> Select the pricing procedure and double click on control data.
Go to new entries :
step Co CType Description From To Statistical Requirement AccK
10 - YR00 - - - 2 ERL
> Save Pricing Procedure.
5. Pricing Procedure Determination:
T. Code : OVKK
Path : SPRO > S&D > Basic Functions > Pricing > Pricing control > Define & Assign pricing
procedure > Define pricing procedure determination
> We assign pricing procedure to the combination of sales area, document pricing procedure
and customer pricing procedure.
> And also assign condition type "YR00" in "OVKK".
> If we want to differentiate the pricing based on transaction then we control through
"Document pricing procedure".
> If we want to differentiate pricing based on customer then we control through "Customer
pricing procedure".
Q. Why we assign condition type in "OVKK"?

A. We assign condition type in "OVKK", to see the condition type amount in sales document line
item overview or to maintain the price manually in line item overview.
Scenarios for base price determination in order:
1. Customer/Material
711/Vaxine1500 - 9000/-
712/Vaxine1500 - 9000/-
2. Price list/Material
Z1/Vaxine1500 - 9800/-
Z2/Vaxine1500 - 9600/-
Z3/Vaxine1500 - 9500/-
3. Material
Vaxine1500 - 10,000/-
Note: Create different customers as above and check.
Till now we have done pricing procedure only for base price. We'll maintain same thing for
discounts, surcharges.
Discounts:
The standard discounts are:
K004 - Material Discount
K005 - Customer/Material Discount
K007 - Customer Discount
Condition Table: Create condition table only for customer discount as we have already created
two condition tables for the field combinations of material and customer/material. So, we can
use same tables even for discounts. The condition table is
653 - Customer
Access Sequence: For every combination we need to create new access sequence. So, for every
discount condition type we will define new access sequence.

Here we are going to define 3 access sequences.
Y004 - Material
Y005 - Customer/Material
Y007 - Customer
Condition Type: Create 3 condition types
Y004 - Material Discount
Y005 - Customer/Material discount
Y007 - Customer discount
> Assign access sequence in condition types.
> Place condition types in pricing procedure.
Step Co CType Description From To Statistical Requirement AccK
10 - YR00 - - - 2 ERL
20 - Y004 10 - - 2 ERS
30 - Y005 10 - - 2 ERS
40 - Y007 10 - - 2 ERS
50 - Total Discount 20 49 * - -
60 - Gross Value 10 49 * - -
> Anything which we maintain using description it will be statistical.
> Maintain condition records for discount condition types.
> Create order and check.
Create Price Grp/Material condition type:
> Create condition table for Price Grp/Material.
> Create access sequence (JDIS)
> Place all tables in "JDIS" access sequence.

> Create condition type "JDIS" - combination discount.
Copy JDIS from K004 condition type.
> Assign access sequence "JDIS" to the condition type "JDIS".
> Place condition type "JDIS" in pricing procedure "YVAA01".
Step Co CType Description From To Statistics Requirement AccK
45 - JDIS 10 - - 2 ERS
> Maintain condition record for Price Grp/Material.
Note: To run this scenario assign price group in customer master sales tab.
Note: All the discount condition types starts with "K".
Surcharges:
Surcharges include packing, insurance and freight charges.
Condition table: For packing and insurance we don't need to create condition table and access
sequence as packing and insurance charges are going to be calculated based on material.
We have already defined Condition table for material. We can use the same table.
652 - Material
Access Sequence: Even we can use same access sequence which we defined for condition table
652.
Y004 - Material access sequence
Condition Type: Copy condition type "YPAC" from "K004"
In "YPAC" condition type the plus/minus field is positive i.e., surcharge.
Place access sequence in condition type "YPAC".
Pricing procedure: Place this condition type in pricing procedure "YVAA01".
Condition Records: Maintain condition records for YPAC.
Note: Do the same thing for Insurance "YINS" also.

step Co CType Desc From To Req Statistical AccK
70 - YPAC 60 - 2 - ERF
80 - YINS 60 - 2 - ERF
90 - - NET VALUE 60 89 - * -
Freight Charges:
The standard condition type for freight is "KF00"
Freight will be calculated based on weight. The combination of freight is Incoterms 1 and
Incoterms 2 and Incoterms1
Condition table: Create two condition tables for both combinations
655 - Incoterms & Incoterms (Part2)
656 - Incoterms
Access Sequence: Create freight access sequence
YF00 - Freight access sequence
And place both the tables (655 and 656) in access sequence and do the field assignment.
Condition Type: The standard condition for freight is "KF00"
Copy "YF00" from standard condition type "KF00" and assign access sequence.
Pricing Procedure: Place "YF00" in our pricing procedure "YVAA01"
Step Co CType Description From To Statistical Requirement AccK
85 - YF00 60 - - 2 ERF
Condition Records: Maintain condition records for both the combination and check.
Header Conditions: Header condition is the condition which applies to all the line item in the
sales document.
HB00 - Header Fixed discount
HA00 - Header percentage discount
HD00 - Header freight

HM00 - Header Order value
Header condition should be always process manually. Header condition doesn't have an access
sequence.
HB00: HB00 is "group condition as well as header condition"
If we check group condition in condition type then the amount will be distributed among line
items in proportionate to the value of the line item.
Step Co CType Description from to manually statistical requirement AccK
46 - HB00 10 - * - 2 ERS
> After placing condition type "HB00" in pricing procedure "YVAA01" create order.
> After creating order click o display header document.
>In conditions enter header condition type and amount.
> Select header condition type and click on activate.
> Check the net value.
HA00: HA00 is "group condition as well as header condition"
47 - HA00 10 - * - 2 ERS
HD00: HD00 is only header condition
86 - HD00 - - * - 2 ERF
HM00: HM00 is both "header and group condition"
100 - HM00 - - * - 2 ERL

Statistical Conditions:
Statistical conditions means it is only for display purpose.
The value of condition type doesn't have any effect on net value and the value of condition type
will not be posted into accounting.
VPRS - Cost condition type
We maintain cost in material master accounting 1 tab. That cost will be determined into sales
document with the help of "VPRS" condition type.
SKTO - Cash discount condition type
We maintain cash discount percentages in terms of payment. That percentage is copied into
sales document with the help of "SKTO" condition type.
KUMU - Cummulation condition
"KUMU" will be used in BOM concept. It will help to cumulate the values of component and
displays it in main item as statistical.
PI01 - Intercompany price
Step Ctype Description Subtotal Statistical Requirement CalType Base Type
110 VPRS 2 * 4 - -
120 Profit Margin * - 11 -
130 SKTO * 9 - 11
> The pre-requisite to determine cost condition type (VPRS) in to sales document line item is
determine cost in item category.
> The pre-requisite to determine cash discount into sales document is check cash discount in
material master sales org1.
Free Goods condition type:
R100 - 100% discount
R100 will appear for free goods line item and makes the net value "0".
NRAB - Free goods without item generation

NRAB condition type will deduct the value of free goods from main item.
Step Ctype Description From To Statistical Requirement Base type AccK
150 R100 90 - 55 28 ERS
170 NRAB 90 - 59 29 ERS
Rebate Conditions:
BO01 - Group Rebate
BO02 - Material Rebate
BO03 - Customer Rebate
BO06 - Sales independent rebate
List of Condition Types:
PR00 - Base Price
Discounts:
K004 - Material
K005 - Customer/Material
k007 - Customer
K020 - Price Group
K029 - Material Pricing group
K030 - Customer/Material pricing group
K031 - Price group/Material pricing group
K032 - Price group/Material
Header Discounts:
HA00 - Header percentage discount

HB00 - Header fixed discount
HD00 - Header Freight
HM00 - Header order value
Statistical:
VPRS - Cost condition type
SKTO - Cash discount condition type
KUMU - Cummulative condition
PI10 - Intercompany pricing
Rebates:
BO01 - Group rebate
BO02 - Material rebate
BO03 - Customer rebate
BO06 - Sales independent rebate
Other condition types:
PMIN - Minimum price
EDI1 - Customer expected price
EDI2 - Customer expected value
AMIW - Min. Sales order value
AMIZ - Min. Value surcharge
PDIF - Difference value
DIFF - Rounding off
EK01 - Cost condition type
EK02 - Cost condition type

Condition Type Controls:
1. Condition Class: Condition class specifies the type of price component.
A - Discount/Surcharge D - Taxes
B - Prices
C - Expense Reimbursement (Rebates)
2. Plus/Minus: This field controls whether to deduct the condition type amount from net value
or whether to add to the net value.
This filed is only applicable for condition types which has condition class "A".
For a condition type if we specify the value "negative" it becomes discount and if we specify the
value "positive" it becomes surcharge.

3. Calculation Type: Calculation type controls how system calculates the condition amount.
This field specifies how the condition amount of condition type is calculated.
The system can calculate the price based on quantity, volume or weight.
For Base price "PR00" calculation type is "C"
For Freight "KF00" the calculation type is "D"
For discounts calculation type can be "A or B or C"
4. Condition category: Condition category is sub classification of condition class. Based on
condition category system will come to know which condition should be re-determine into
target document.
This field will have relationship with the "pricing type" in "copy controls".
Pricing type controls how the pricing should be copied from source document to the target
document i.e., whether to copy the pricing as it is or whether to re-determine only taxes or
whether to re-determine only freight.
5. Rounding Rule: This field controls whether to perform commercial rounding or roundup or
round down.
6. Structure Condition: We use this field in BOM concept. This field will help to cumulate the
values of components and display it in main item.
The standard condition type for cummulation is "KUMU".
7. Group Condition: We use this field if we want to give discount based on "order value" or
"group of material value".
Ex: The client requirement is if the total "sales order value" reaches to 10L then propose 10%
discount or the "group of material value" reaches to 10L then propose a discount of 10K.
If we check group condition, the group condition amount will be distributed among all the line
items in proportionate to the line item value.
8. Group condition routine: This field controls whether to consider total value or group of
materials value.
If we want to consider total document value maintain "1"
If we want to consider group of materials value maintain "3"

To group the materials for group condition concept we use the field material pricing group in
material master sales org2.
9. Rounding difference comparison: If we check this while distributing the group condition
amount among all the line items if there is any left-over amount, that amount will be added to
the largest item (in terms of value).
10. Manual Entries: This field controls whether the condition type can be entered manually
during pricing in the sales document or it has to be automatically determined by the system.
If it is "Blank or C" we can process manually
If it is "D" then we cannot process manually
11. Amount/Percent: This field controls whether we can change the condition amount of
condition type during pricing in the sales document or not.
If we check we can change or else we cannot.
12. Value: This field controls whether we can change the condition value of condition type
during pricing in the sales document or not.
If we check we can change or else we cannot.
13. Delete: This field controls whether we can delete a condition type during pricing in the sale
document or not.
If we check we can delete or else we cannot.
Q. There is a manual condition type which user enter manually into sales document. But after
entering the condition type system should not allow to change condition type amount or value.
Where is the control?
A. The control lies with the fields "Amount/Percent and Value"
14. Header Condition: If we check this field for a condition type it becomes header condition
where it has to be entered at header level in the sales document.
Header condition is a condition which is applicable to all the line items in the sales document.
Header condition should be always processed manually.
Header condition doesn't have an access sequence.

After specifying the header condition type in the sales document we have to select the
condition type and we need to activate that by clicking on "activate" button.
15. Item Condition: If we check this field for a condition type it becomes an item condition
where it has to be entered at item level in the sales document.
The condition amount of the item condition is specific to that particular line item for which it is
entered.
Q. Difference between group condition and header condition?
Header Condition Group Condition
1. Header condition amount will be
applicable to all the line items in the sales
document.
EX: HD00
1. Group condition amount will be distributed
among all the line items proportionate to the
value of line item.
EX: K029, K030
2. Header condition should be always
processed manually.
2. Group condition can be processed
automatically.
3. Header condition doesn't have access
sequence.
3. Group condition can have access sequence.
HA00, HB00 and HM00, all these condition types are both header as well as group condition
types.
16. Calculation type: If we check this field the calculation type of condition type can be changed
during pricing in the sales document.

17. Valid From and Valid To: If we maintain valid from and valid to here then system by default
proposes validity dates while creating condition records.
18. Pricing Procedure: We use this field for condition supplement.
Condition Supplement is the concept of adding one condition record to another condition
record.
If the main condition record determines then only the supplement condition record will be
determined into the sales document.
EX: If the client requirement is that they want to offer 3% discount to the customers who are
getting maximum price. To do this go to the condition records of material combination and add
supplement condition of 3%.

Configuration of condition supplement:
> Create new condition type "YSUP", copy from "K004" and save.
> Place the condition type in our main pricing procedure "YVAA01" (in discounts).
> Create new supplement pricing procedure "YSUP01".
> Select the supplement pricing procedure and double click on control and go to new entries.
> Place the main condition type "YR00" and supplement condition type "YSUP" in supplement
procedure "YSUP01".
step CType Description From To Requirement AccK
10 YR00 - - 2 ERL
20 YSUP 10 - 2 ERS
and save.
> Go to the main condition type "YR00" and assign supplement pricing procedure "YSUP01".
> Go to the supplement condition "YSUP" and assign supplement procedure "YSUP01".
> Go to condition record (VK12) of material combination and maintain 2nd record.
> Select already existing condition record and click on supplement icon and maintain additional
record "YSUP" as 3%.
19. Delete from data base: This field controls whether to delete the condition records
permanently from data base or not.
Go to "VK12" delete the condition record and check.
20. Condition Index: Condition index will be used to display all combination of prices in a single
window. We can also change all combination of prices in single window.
Configuration of Condition Index:
> Check the field condition index in condition type.
> Create condition table with material combination

Path: SPRO > S&D > Basic functions > Pricing > Maintain condition index > Maintain condition
tables for index
657 - Material
> Activation of condition index
Path: SPRO > S&D > Basic functions > Pricing > Maintain condition index > Activate condition
index
Go to the condition table and check the activate box.
> Maintain condition record
> The path for executing condition index
Go to easy access
Path: Logistics > S&D > Master Data > Condition > Select using condition index (V/I5)
and save.
> Go to VK12 and check whether the condition record is updating or not.
21. Condition Update: Condition update specifies whether we can restrict the condition record
to a particular quantity or document value or no.of orders.
SAP restricts no.of orders to 3
EX: Whenever company is launching new product, to motivate the customers to purchase the
new product they will launch the schemes like below:
Whoever customer purchases up to first 50,000 cartons then they will be getting 60% discount.
> If we check condition update we will be getting 3 extra fields in condition records i.e., "limits
for pricing"
To check go to "VK12" select the record and click on additional data icon.
> Create new condition type "YUPP" which we should copy from "K004" and calculation type is
Quantity.
> Add condition type in pricing procedure.
> Maintain condition record for "YUPP".

> Click on record and click on additional data and maintain "limits for pricing".
> Create order and check the scenario.
In condition update concept system updates the quantities based on "Info structure S071".
The T. Code to see the Info-structure is "OMO1".
22. Reference condition type: If pricing is same for multiple condition types then instead of
maintaining pricing for all condition types, we maintain pricing for one condition type and that
we assign it as reference condition type for the remaining condition type.
We use this concept in intercompany sales.
In intercompany sales we have two condition types:
i. PI01
ii. IV01
We maintain condition records for PI01 and PI01 is assigned it as reference condition type for
IV01.
For any condition type if we maintain reference condition type then go to the pricing procedure
in which main condition type exists and check transaction specific (TSP).
Scales:
Scale is maintaining the prices in the slab system
EX: 0 to 100 - 10,000/-
101 to 200 - 9,800/-
201 to 300 - 9,600/-
23. Scale Basis: This specifies what could be the base for maintaining slab price.
24. Check Value: This field controls whether to maintain slab price in ascending or descending
order.
25. Scale Type: We have two types of scales
i. Normal Scale ii. Graduated Scale
"Normal Scale" system directly picks the slab price in which order quantity list

"Graduated Scale" System determines all combination of slab prices based on order quantity.
Note: In standard no 2 base price condition type is active in single sales document. System
activates last one and deactivates previous one.
But only in gradated scales multiple base prices are active.
24. Exclusion: If we maintain "X" in any condition types and if the condition type determines
into sales document then system eliminates all the below condition type for which we have
same pricing requirement. EX: "2"
Exclusion can be maintained in two places
i. Condition type level
ii. Condition record level (in details icon)
25. Pricing Date: Pricing date will help to determine valid condition record on that particular
date.
16 fields of Pricing Procedure:
1. Step: Step specifies a sequential number of a condition type in pricing procedure.
Step is also used to determine the base value for calculating the condition type (used in from
and to fields).
2. Counter: Counter specifies a sequential number of condition type within the step in pricing
procedure.
3. Condition Type: Specify the condition type in this field. Condition type controls the price
elements or price components.
4. Description: It specifies the description of condition type which will be automatically
determined from the definition of condition type.
We also use description for bifurification of pricing structure.
EX: Gross value, Net value, Total value etc.,
5. From: (Standard base value) This field will help to determine the base value for calculating
the condition type.
6. To: This field will help to cumulate the values of multiple steps which are in sequence.

Note: If we specify reference steps in from and to fields the condition values of the two steps
specified and the condition values of the steps in between will be totalled.
7. Manual: If we check this, system will not propose the condition type automatically into the
sales document. User has to enter it manually.
Generally all header conditions are manual.
8. Required: If we check this field for a condition type it becomes mandatory during pricing in
the sales document. System will not allow to save the sales document if the condition type
value is missing.
9. Statistical: It has two effects
i. If we check this the value of condition type doesn't have any effect on net value.
ii. The values of condition type will not be posted into accounting.
10. Print: This field controls whether to print the condition type into the outputs or not.
EX: Print outs, fax, e-mail etc.,
"X" - Print at item level
"S" - Print at header level
11. Subtotal: Subtotal will be used to store the values of condition types in some temporary
tables and fields for the purpose of further classification (Alt Cal Type & Alt Base Type).
Subtotal will be used to update the values of sales document into credit management.
Subtotal will also be used to update the billing document values into rebate agreement.
The subtotal for credit management is "A"
The subtotal for rebate agreement is "7"
The subtotal for VPRS condition type is "B"
12. Requirement: Requirement is a condition which system checks every time while
determining the condition type into sales document pricing. If the requirement fulfills then only
the condition type will be determined into sales document.
If the requirement is not fulfilling then the condition type will not be determined into sales
document.

> The standard requirement is "2"
Requirement "2" checks that pricing field in item category should be "X" or " B"
It also checks condition exclusion.
> Requirement for VPRS condition type "4"
Requirement "4" checks that whether the determine cost field in item category is checked or
not.
> Requirement for SKTO condition type is "9"
Requirement "9" checks that the cash discount field in material master is checked or not.
> Requirement for R100 condition type is "55"
Requirement "55" checks that the pricing field in item category should be "B"
> Requirement for NRAB condition type is "59"
> Requirement for rebate conditions is "24"
Requirement "24" checks that the document should be billing document.
> Requirement for PI01 condition type is "22"
Requirement "22" checks that the ordering company code and delivering company code should
be different.
Note: The T. Code to develop new requirements is "VOFM"
User defined requirement should be 900 and above.
13. Alternate calculation type: Alternation calculation type is a formula which will help to
calculate the value of the condition type and proposes the total value of the condition type.
We use alternate calculation type if the calculation part of the condition type is not standard.
If we maintain formula in alternate calculation type then no need to maintain condition records
because system will directly propose total value of the condition.
EX: The standard formula for profit margin is "11"
"11" will deduct the cost from net value.

14. Alternate base type: The standard base is "from"
Alternate base type is a formula which will calculate and proposes the base value of the
condition type. Further we have to maintain condition record to convert base into conversion
value.
We use alternate base type if the base value of condition type is not standard.
Note: The T. Code to develop formula is "VOFM". Formula should be 900 and above.
15. Account Key: This field is one of the parameter to determine revenue G/L account while
posting invoice values into accounting.
ERL : Base Price
ERS : Discount
ERF : Freight
MWS : Sales Tax
MW3 : Sales Tax
ERB : Rebate
ERU : Accruals
Q. What happens if i check statistical and if i assign account key?
A. It won't post to accounting.
16. Accruals: The accrual key enables the system to post "Rebate Accruals" to the
corresponding G/L account.
Q. There is a condition type which is statistical but i wnat to post it into some G/L account? How
is it possible?
A. It is possible in case of rebates with the help of accruals "ERU".
The control is condition class "C" along with "ERU".
Condition Exclusion Group:
Grouping of multiple condition types into one and asking the system to propose the best or the
least condition type.

I. Configuration of Exclusion Group: (Best or Least condition b/n condition types within one
group)
> Create Exclusion group
Path: SPRO > S&D > Basic functions > Pricing > Condition Exclusion > Condition exclusion for
group of conditions > Define condition exclusion group
8000 - Exclusion Group1
8001 - Exclusion Group2
> Assign condition type to the exclusion group
group of conditions > Assign condition types to the exclusion group
In this step we will assign condition types to the exclusion group.
> Maintain condition exclusion for pricing procedure
group of conditions > Maintain condition exclusion for pricing procedure

Create order and check how exclusion group is working.
Depending on the Condition exclusion procedure, system can use condition exclusion to select
the best price in six different ways:
* Selecting the best condition record of a particular condition type from within one
exclusion group.
* Selecting the least favorable condition within one exclusion group.
* Selecting the best conditions from different exclusion groups.
* Selecting the least condition from different exclusion groups.
* Selecting the best condition record for a condition type.

* Selecting the least favorable condition record for a condition type.
II. Configuration of Exclusion Group: (Best or Least condition b/n two condition groups)
> Create Exclusion group
group of conditions > Define condition exclusion group
> Assign Condition Types to the Exclusion groups
group of conditions > Assign condition types to the exclusion group
Here assign 2 condition types to one group and another 2 condition types to second group.
Here we can change the combination of assignment to check the result in sales document.

Create order and check the result.
Condition exclusion procedure (Cpr) controls whether to propose the best condition or least
condition.
Q. If the client requirement is any customer if they purchase slow moving items they want to
offer 20 days extra credit period?
A. To meet this requirement, first we need to create condition type "YPAY", which is a copy of
"K004" and place the condition type in pricing procedure in the last and make it statistical.
Step CType from Statistical
160 YPAY 11 *
Maintain condition record for "YPAY". Select the condition record and click on addition data
and give 20 in "Additional value days" and save.
Create Sales order and check in billing document.
Q. Can I have different payment terms material wise?
A. Yes, We can have.
In condition record, select the record and click on "additional data". In this tab we can maintain
payment terms.

Lower Limit and Upper Limit in condition record:
These fields will help to decrease or increase the price in the sales document upto that limit.
We need to maintain this limit in "Details tab".
Update button in sales document conditions tab:
"Update button" helps to update the sales document price.
Q. How system determines pricing into sales document?
A. i. System determines pricing procedure based on sales area, document pricing procedure
and customer pricing procedure.
ii. System will go inside pricing procedure and goes to the first step and checks the
requirement. If the requirement fulfills the system will go inside the condition type and search
for the valid condition record from more specific to the most generic.
If system finds the record then system determines the price.
Q. What sequence system follows in 16 fields of pricing procedure while determining the price?
A. i. Step ii. Counter iii. Condition Type iv. Requirement v. Subtotal vi. Alt. Base value
vii. Alt. Cal type Viii. From ix. To and rest all in the sequence.
Q. Client requirement is if they want to add new discount condition type in existing pricing
procedure. And he is having 1000 open orders and client wants to determine the new condition
type while creating invoice to already created open orders?
A. It is not possible to determine new condition type in already created orders. But we can
determine new condition type in invoice. For this do the below.
Go to the new condition type and maintain condition category as "L"
L - Generally new when copying

SAP SD Configuration Document

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to SAP SD Configuration Document (20)

Recently uploaded (20)

SAP SD Configuration Document