SD Study Material Part 1

1
SD Study material-Part I

1. SAP Screen Elements _________________________________________________________ 4
2. Enterprise Structure ___________________________________________________________ 6
ORGANIZATIONAL UNITS _____________________________________________________________ 7
Attributes & Application _________________________________________________________________ 12
3. MASTER DATA ________________________________________________________________ 13
4. CUSTOMER MASTER DATA ____________________________________________________ 15
Customer Master Mass Maintenance (T. Code: MASS or XD90) ______________________________ 23
CUSTOMER MATERIAL INFORMATION RECORD: ______________________________________ 24
5. COMMON DISTRIBUTION CHANNELS & DIVISIONS: ______________________________ 25
6. CUSTOMIZATION OF CMD or ACCOUNT GROUP: ________________________________ 29
6. MATERIAL MASTER DATA _____________________________________________________ 32
Material Master Mass Maintenance (T. code: MASS, _______________________________________ 38
8. SALES DOCUMENTS ___________________________________________________________ 39
Sales order: ____________________________________________________________________________ 41
STRUCTURE OF SALES DOCUMENT: ___________________________________________________ 41
FUNCTIONS OF SALES DOCUMENT: ___________________________________________________ 43
Types of Sales Documents used in Business process ___________________________________________ 44
Sources for Document Data ______________________________________________________________ 59
Sales Document (VOV8) DETAILS: _______________________________________________________ 62
9. SPECIAL BUSINESS TRANSACTIONS (Cash order & Rush order sales) ____________ 63
10. ITEM CATEGORY ______________________________________________________________ 67
FUNCTIONALITY OF ITEM CATEGORY ________________________________________________ 68
Types of Item Category __________________________________________________________________ 68
ITEM CATEGORY DETERMINATION ___________________________________________________ 70
11. SCHEDULE LINE CATEGORY __________________________________________________ 70
Schedule Line Category Controls __________________________________________________________ 71
12. SALES ORDERS ______________________________________________________________ 73
Blocking Sales Orders ___________________________________________________________________ 74
Setting a Delivery Block _________________________________________________________________ 74
BASIC FUNCTIONS ______________________________________________________________ 75
13. PARTNER DETERMINATION: VOPA ____________________________________________ 75
Partner Types and Assigned Partner Functions ______________________________________________ 77
14. CONDITION TECHNIQUE STEPS _______________________________________________ 80
15. OUTPUT DETERMINATION ____________________________________________________ 81
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P
AppsTwo_SAP_O2C_RP Sept 2011

2
16. MATERIAL DETERMINATION __________________________________________________ 85
17. MATERIAL LISTING & EXCLUSION _____________________________________________ 87
18. PRODUCT PROPOSAL / ITEM PROPOSAL ______________________________________ 88
19. BILL OF MATERIALS (BOM): __________________________________________________ 89
20. CONSIGNMENT STOCK PROCESSING _________________________________________ 92
21. THIRD PARTY ORDER PROCESSING _________________________________________ 110
Process Flow for 3rd Party Sales _________________________________________________________ 115
22. SALES INCOMPLETION LOG / INCOMPLETION LOG ___________________________ 118
23. SHIPPING ___________________________________________________________________ 124
SHIPPING POINT DETERMINATION: __________________________________________________ 125
OUT BOUND DELIVERY IN SHIPPIG (VL01N) __________________________________________ 129
TYPES OF DELIVERY DOCUMENTS ___________________________________________________ 130
DELIVERY SCHEDULING ____________________________________________________________ 136
ROUTE DETERMINATION ____________________________________________________________ 138
BATCHES ___________________________________________________________________________ 144
SERIAL NUMBERS ___________________________________________________________________ 145
PRICING IN THE OUTBOUND DELIVERY ______________________________________________ 146
PICKING IN SHIPPING (LT03) _________________________________________________________ 148
GOODS ISSUE in SHIPPING (VL02N) ___________________________________________________ 158
EFFECTS OF GOODS ISSUE POSTING _________________________________________________ 159
PROOF OF DELIVERY (POD) __________________________________________________________ 161
24. BILLING _____________________________________________________________________ 162
STRUCTURE OF BILLING DOCUMENT ________________________________________________ 163
BILLING TYPE CONTROLLS __________________________________________________________ 173
COPYING CONTROL _________________________________________________________________ 188
BILLING DOCUMENT TYPE: __________________________________________________________ 197
BILLING DOCUMENT CONTROLS: ____________________________________________________ 197
SUMMARY OF BILLING ______________________________________________________________ 199
BILLING FI POSTINGS ______________________________________________________________ 203
SD / FI INTERFACE IN BILLING DOCUMENT __________________________________________ 205
Reference Numbers and Allocation Numbers _______________________________________________ 207
SD / CO - PA Interface _________________________________________________________________ 208
25. CUSMTOMER COMPLAINTS __________________________________________________ 211
26. PRICING ____________________________________________________________________ 223
Functionality of Condition Types: ________________________________________________________ 230
Different Condition Types in Pricing ______________________________________________________ 239
HEADER & ITEM CONDITIONS _______________________________________________________ 245
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

3
PRICING SCALES ____________________________________________________________________ 246
CONDITION SUPPLEMENTS __________________________________________________________ 247
PRICING LIMITS (UPPER & LOWER LIMITS): _________________________________________ 247
CONDITION UPDATE ________________________________________________________________ 248
CONDITION EXCLUSION GROUP _____________________________________________________ 248
FREE GOODS DETERMINATION ______________________________________________________ 250
Bonus Buy ____________________________________________________________________________ 255
ADVANCEED PRICING _______________________________________________________________ 259
Understanding certain complex pricing requirements ________________________________________ 263
Release Procedure for conditions _________________________________________________________ 275
27. REBATE AGREEMENTS ______________________________________________________ 278
Retroactive Rebate Processing ___________________________________________________________ 282
28. CREDIT MANAGEMENT ______________________________________________________ 285
Update group _________________________________________________________________________ 290
SUMMARY OF CREIDT MANAGEMENT CONFIG STEPS ________________________________ 294
Additional checks - in Automatic credit control _____________________________________________ 298
29. INTERCOMPANY SALES & BUSINESS PROCESSING __________________________ 301
Pre-requisites for Inter company sales processing ________________________________ 302
FI posting in Intercompany sales process __________________________________________________ 310
30. AVAILABILITY CHECK _______________________________________________________ 317
Types of Availability Check _____________________________________________________________ 317
Prerequisites for Availability Check ______________________________________________________ 319
Availability Check - Configuration _______________________________________________________ 321
TOR Configuration___________________________________________________________________ 327
Availability Check with RLT: ___________________________________________________________ 331
31. CROSSING SELLING _________________________________________________________ 333
32. Batch Management __________________________________________________________ 336

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

4
1. SAP Screen Elements

Command field: You can use the command field to go to applications directly by entering the
transaction code. You can find the transaction code either in the SAP Easy Access menu tree (see
next slide) or in the relevant application under System Status.
Menu bar: The menus shown here depend on which application you are working in. These
menus Contain cascading menu options.
Standard toolbar: The icons in the system function bar are available on all R/3 screens. Any
icons that you cannot use on a particular screen are dimmed. If you leave the cursor on an icon for
a moment, a small flag will appear with the name (or function) of that icon. You will also see the
corresponding function key. The application toolbar shows you which functions are available in
the current application.
Title bar: The title bar displays your current position and activity in the system.
Check boxes: Checkboxes allow you to select several options simultaneously within a group.
Radio buttons: Radio buttons allow you to select one option only.
Status bar: The status bar displays information on the current system status, for example,
warning and error messages.
A tab provides a clearer overview of several information screens.
Options: You can set your font size, list colors, and so on here.

What is full form IMG and SPRO?
IMG :- Implementation Guide.
SPRO: - SAP Project Reference Object.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

5

Use the menu option System User profile Own data to set your own personal profile. You
can choose between the Address, Defaults and Parameters tabs.
Address: You can create and maintain personal data here, for example, name, function, room
number, telephone number, e-mail addresses and so on.
Defaults: Defaults include the date display format, the decimal notation format, the default
printer, the logon language, and so on.
Parameters: Use this to assign entries to commonly used fields. This is only available for input
fields that have been allocated a parameter ID.
Procedure for finding out a fields Parameter ID: Go to the input field to which you want to
assign a value. Choose F1, then the Technical info pushbutton. This opens a window that
displays the corresponding parameter ID (if one has been allocated to the field) in the Field data
section.
The User profile menu also contains, among others, the following options:
Hold data, Set data, Delete data. Use Hold data to keep data values that you have entered in
fields in an application for the duration of a user session. When you call up the application again,
you can overwrite these values. Once you have set data, you can no longer overwrite these values
and have to use Delete data if you want to enter different values.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

6

2. Enterprise Structure

Enterprise Structure or Organizational Structure is a framework in which all business transactions can
be processed.

ENTERPRISE STRUCTURE IN SAP

Level
Enterprise
Structure
Organization Structure in SAP Module
1 Cost Account Controlling Area CO
2 External Logistics Sales Org Purchase Org SD / MM
3 Accounting Company Code FI
4 Valuation Areas MM
5 Internal Logistics Plants MM
6 Inventory Mgmt Slocs/ Special Stocks / Batches MM

Company Code: it is the company for which we implement SAP. It is defined by FI. (4 digits
code). It is the highest level of organizational element in Ent Stru, which allows posting
revenues to G/L accounts.
Sales Organization: (4 digits code) is an organizational unit responsible for sale and
distribution of goods and services.
Distribution Channel: (2 digits code) is a channel through which goods or services reach the
customer.
Division :(2 digits code) the range of goods or services that the company manufactures falls
into different divisions.
Sales Area: combination of Sales Organisation, Distribution Channel and Division.
Distribution chain: combination of Sales Organisation and Distribution Channel.
Sales Office: geographical aspect of the organization. Sales offices are assigned to sales
areas.
Sales District: Also referred as customer districts, can be geographical area or regions. You
find this field in Customer master data that are copied into the Header & Item data of the sales
order. It is used for statistics purposes as well as for pricing.
Plant: the factory is called the plant in SAP.

RELATION SHIPS: -
o Company Code to Sales Organisation: One to Many
o Sales Organisation to Distribution Channel: Many to Many
o Distribution Channel to Division: Many to Many.
o Plant to Company Code: Many to One. In Intercompany: Many to Many
o Plant to Shipping Point: One to Many. Many to Many if in one geo area.
o Plant to Sales Organisation: Many to Many.

o Division is always organization specific.
o If sales organisation wants to use a plant, that plant must be assigned to the sales orgn.
o Master data records are multiplied by each additional organizational element you have.

Menu Path for Sales Orgn/ Distbn Channel/ Sales Office/ Sales Group:
SPRO- IMG- Ent. Stru. - Defn. - S.D.- Define, Copy, Delete, Check Sales Orgn/ Distbn Channel/ Sales
Office/ Sales Group.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

7

Menu Path for Division Creation:
SPRO- IMG- Ent. Stru. Defn. Logistics General- Define, copy, delete, check div.

Defining Plant:
SPRO- IMG- Ent. Stru. Defn. Logistics General- Define, copy, delete, check plant.
A plant, though always linked to one company code, can be linked to several sales organizations.

Assigning Plant to Company Code:
SPRO- IMG- Ent. Stru. Assignment- Logistics General- assign plant to company code.

Define Sales District: OVR0
SPRO- IMG- Master Data- Business Partner- Customer- Sales- Define Sales District.
Assignment Path:
SPRO- IMG- Ent. Stru. Assignment Sales & Distbn. :
Assign Sales orgn to company code: company code 4 digits code.
Assign Distbn channel to Sales orgn
Assign Division to Sales orgn
Set up sales area
Assign sales office to sales area
Assign sales group to sales office
Assign plant to sales orgn Distbn channel
Business area account assignment:
Define rules by sales area
Assign business area to plant & Item Division.
Assign business area by sales org, Distribution channel and Item Division.

Organisation in Shipping & Transportation:
A delivery is always carried out by one shipping point only.
Shipping points are subdivided into loading points.
Shipping point is assigned to a plant.

The shipping point depends on the following:
Shipping Conditions
Loading Group
Delivering Plant
ORGANIZATIONAL UNITS

1. ORGANISATIONAL STRUCTURE: ENTERPRISE

Structures represent the legal and organizational structure of a company. Structure is possible from
the point of view of SD, FI & MM. It is possible to combine these structures. The organizational
structures form a framework in which all business transactions can be processed.

2. ORGANIZATIONAL STRUCTURE: Client

Represents Corporate Group
All Org units within a Client are under one Business Control
Self contained Technical Unit
General Data & Tables are stored at Client Level

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

8

3. ORGANISATIONAL STRUCTURE: Finance / Controlling

a) Company Code (FI, SD):
Legal and independent accounting entity.
Smallest Org unit in external accounting. Represent Independent Companies in a Group.
Required to create balance sheets and profit and loss statements.
Company Codes are independent from each other in the legal sense.
Each Company Code uses exactly one Chart of Accounts. Several Company Codes can
use same Chart of Accounts
All FI transactions are maintained at Company Code level.
One Company Code must be created

b) BUSINESS AREA
Separate Business Unit for which Cross-Company Code reporting can be carried out
Not limited by Company Codes
Used to calculate Profit & Loss Statements across Company Codes, only for Internal
Reporting.
Business Areas in all Company Codes must have same description.
GL Accounts can be posted by Business Area.
Assigned to a Sales Area, determined at item level in document based on 3 fixed rules:
Plant and Item Division.
Sales Area of the Document.
Sales Org, Dist Channel & Item Division.
Optional

4. ORGANISATIONAL STRUCTURE: Sales & Distribution

c) Sales Organization (SD only):
Org unit within logistics that structures the Company according to its sales requirements.
Responsible for the Sales and Distribution of goods and services.
Represents the selling unit as a legal entity. Responsible for product guarantees and other
rights to recourse, for example.
Regional subdividing of the market can also be carried out with the help of Sales Orgs.
Highest Summation Level in Sales Statistics.
Has own Master Data.
Each business transaction is processed within a Sales Org and must be specified in all
documents in SD.
It is therefore available for all basic functions of SD (such as pricing, availability, etc.).
Assignment to Company Code: Many : One
Assignment to Plant: Many: Many (Sales Org can be assigned to Plant from another
Company Code -> Inter-Company Billing)
Uses of Sales org:
A Sales Organization is the highest level of organizational Unit in SD
A new Sales Organization should always be created by copying an existing one
Sales Organization has address, calendar, Statistical Currency and controls Rebate
Processing, Inter-Company Sales
Assigning Sales Organization to Company Code establishes a link between SD and FI
system
Reports can be generated at Sales Organization level

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

9

d) Distribution channel (SD only):
Represents the channel through which salable materials or services reach customers (e.g.
wholesale, retail and direct sales).
General Structure for distributing goods.
Can be used to define responsibilities, achieve flexible pricing, and differentiate sales
statistics.
Master data relevant for sales can differ for each Sales Org and Distribution Channel.
Assignment to Sales Organization: Many: Many

e) Division (SD only):
Used to group Materials and Services based on responsibility for sales or profits from
saleable materials or services.
Product Group or Product Line.
Material can belong to one Division only.

f) Sales Area (SD only):
Combination of Sales Organization, Distribution Channel & Division.
Creating a Sales Area allows you to exclude certain combinations of the different
organizational areas.
Each SD document is assigned to a Sales Area.
Master Data & Analyses can be maintained for a Sales Area.
Mapping to Company Code: Many: One (based on assignment of Sales Organization).

g) Distribution Chain (SD only):
Combination of Sales Org & Distribution Channel
Delivering Plant is assigned to Distribution Chain

h) Common Distribution Channel / Division: Common Dist Channel or Division is representative
for the actual Dist Channels / Divisions assigned to it (defined separately for Customer / Material
Masters & Condition Masters). Thus, there is lesser need for Master Data Maintenance in
Customer / Material or Condition Masters.

5. ORGANIZATIONAL STRUCTURE: Sales / Business Development

The Sales Organization is represented by the elements: sales office, sales group and salespersons.

i) Sales Office:
Represents geographical aspects of the organization in business development and sales
Can be considered as a subsidiary.
Establishes contact between the firm and the regional market.
Assignment to Sales Area: Many: Many

i) Sales Group:
Subdivision of the staff of the Sales Office.
Assignment to Sales Office: Many: Many

j) Salespersons:
Sales Representatives.
Assigned to Sales Office & Sales Group in Employee Master Record (HR). Can be selected
as Business Partner in Sales Document or Customer Master.
Assignment to Sales Office & Sales Group: Many: Many
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

10

6. ORGANIZATIONAL STRUCTURE: Logistics Execution / Shipping

k) Plant (SD, MM):
Central Role in Logistics
MM: Location where materials are kept
PP: Manufacturing facility
SD: Location from where goods / services are distributed (must be configured as Delivering
Plant)
Essential for determining Shipping Point
If Delivering Plant of Distribution Chain belongs to different Company Code, then it leads to
Cross-Company Sales / Inter-Company Billing.
Assignment to Company Code: Many : One
Assignment to Distribution Chain: Many: Many

l) Storage Location (MM):
Location where Material Stock is stored.
Stock is managed at Storage Location level.
m) Shipping Point (SD):
Created at Client Level.
Highest-level Org Unit in Shipping.
The shipping point is the part of the company that is responsible for the type of shipping, the
necessary shipping materials and the means of transport. Is a physical place and should be
near the plant to which it is assigned.
Each outbound delivery is processed by one Shipping Point.
Can be set as Goods Receipt Point.
Assignment to Plant: Many: Many
n) Warehouse
An organizational division of a plant for managing materials stored in different places.
Warehouse number Assigned to combination of Plant and Storage Location.
Several Storage locations within a Plant can have same Warehouse Number.

2) ORGANIZATIONAL STRUCTURE ASSIGNMENT SUMMARY

Level 1 2 3 4 5 6 7 8 9 10
Lev
el
Can be assigned to ->
Cmpy
Code
Chart
of
Acct
Sales
Org
Dist
Chanel
Dist
Chain
Divi
Sales
Area
Sales
Off
Sales
Group
Plants
Ship
Point
1 One Company Code - One Many - - - Many - - Many -
One Chart of Acct Many - - - - - - - - - -
2 One Sales Org > One - - Many x Many X - - Many -
3 One Dist Channel > - - Many - x Many X - - - -
4 One Dist Chain > - - x X - - - - - Many -
5 One Division > - - Many Many - - x - - - -
6 One Sales Area > One - x X - x - Many - - -
7 One Sales Off > - - - - - - Many - Many - -
8 One Sales Group > - - - - - - - Many - - -
9 One Plant > One - Many - Many - - - - - Many
10 One Ship Point > - - - - - - - - - Many -
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

11

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

12

Attributes & Application

Org Units Attributes Application
Sales Organization Name and
Address
Language and
Currency
Factory Calendar
Rebate Processing
Intercompany Sales
Account Determination
User Level Authorization
Distribution Channel Name Controls Material Master Sales
View ( along with Sales Org)
Other master data such as
Conditions
Division Name Master Data creation such as
Customer & Conditions
A Material belongs to exactly
one Division
Sales Area Assignment Only Pricing
Free Goods
Output Determination
Partner Determination
Document Types
Company Code Name and
Address
Language and
Currency
Balance Sheet & Profit & Loss
statement.
Transfers financial Information to
Controlling
Revenue Accounting
Credit Policies
Plant Name and
Address
Language and
Currency
Factory Calendar
Taxation
Inter-company Sales
Master data maintenance
Storage Location Name and
Address
Physical Inventory
Delivery Processing
Reporting
Shipping Point Name and
Address
Factory Calendar
Working hours
Lead Time
Delivery Processing
Transportation

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

13
3. MASTER DATA

USE:

Master data is centrally stored (shared across departments) and processed to eliminate data
redundancy.
Master Data helps in keeping validation & fast user entry for transactions.
One time creation of data which is rarely changed. Only the incremental data required to be
maintained

Master data in SD is divided into 5 main areas:

1. Customer master data:- Customer related information is stored in CMD.
The customer master contains all customer-relevant data necessary for processing inquiry,
quotation, order, delivery, invoice and customer payments

Depending on the Configuration settings, Customer Masters can have System generated or
manually assigned numbers

Mostly customers will belong to one Sales Area. They can also be extended to many other
sales areas. During order entry SAP will prompt you to choose the relevant one

2. Material master data:- Material related information is stored in MMD.
Same Material is used by different Department, hence material has many Views.

Material Master has main view (Basic Data, MRP, Purch. Org) and Additional Views (UOM,
Text, etc)

In Material Master some views are maintained at Client Level where as the others are
maintained at other Org level like Plant Level.

The data in Material Masters are either descriptive (name, size, etc) or can control certain
functions (material grp, procurement key).

Material Master has apprx. 800 fields.

3. Customer material info record:- Customers own description of the material which differs
from the original material of the organization. Customer Material Info Record is basically used to
store the information about how a particular material is referred by a customer. Customer-
Material Info Record has priority over Customer Master & Material Master data. For example
during Delivering Plant determination the CM Info Record is accessed first

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

14
4. Condition master data: - Condition Master is stored in the form of Condition record
(information on prices, texts, partners, substitute materials etc) during sales order processing,
the system uses the condition technique to determine these data

Condition Master Example

All of the pricing elements that you use in your day-to-day pricing procedures - the prices,
surcharges, discounts, freight charges, and taxes - are defined in the R/3 system as condition
types.
During sales order entry, the system can calculate prices automatically by finding a gross price,
deducting all the relevant discounts and adding any surcharges such as freight and sales tax.
Depending on the pricing policies of your company, you may be able to change prices manually
during sales order processing. You may, for example, be able to enter or change certain
discounts within a specified range.

5. Additional master data: - It is nothing but out put master data. It is media of communication
send to customer thru various ways. Ex: Printout, Email, Fax. Generally SAP looks from the highest
level of data to the lowest.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

15
4. CUSTOMER MASTER DATA

The customer master data is the basis for all sales transactions as well as deliveries and payments.
A business partner can be a customer and vendor at the same time. You create a link between both
the master records by entering the vendor number in the customer master record and the customer
number in the vendor master record.

Menu path and transaction code for customer creation:
Easy access- logistics- SD- master data- business partner- customer- create, change, display.
VD01 & XD01 to create and MK01 to create Vendor

T Code / Views opens General Data Company Code data Sales area data
XD01/02/03 Opens Opens Opens
VD01/02/03 Opens X Opens
FD01/02/03 Opens Opens X

Structure of Customer Master Data:
General data: FI & SD
Company code data: FI
Sales area data: SD
General Data Screen:
General data does not depend on the company code.
1. Address: transportation zone.
2. Control Data: Vat Registration No. & Vendor
3. Marketing: Customer Classification.
4. Payment Transactions: Name of Bank.
5. Unloading Points: Goods Receiving Hours. OVSC
6. Export Data
7. Contact Person.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

16
Important
Fields
Screen
Application
Search Term Address Short description used for search helps. All entries are automatically
converted into capital letters. There are two such fields for search
terms which can be used independently of each other.
Transportation
Zone
Address The system automatically proposes a suitable route by using the
transportation zone of the goods recipient in combination with other
information about the delivery, such as the Countries of origin and
destination, Shipping conditions & Transportation group.
Country Key Address The country key contains information which the system uses to check
entries such as the length of the postal code or bank account number.
VAT
Registration
number
Control Data The VAT registration number is used within the EU for tax-exempt
deliveries for the "EC sales list". The check rules are defined for each
EU country and cannot be changed.
Vendor Control Data In case of Stock transfer one plant to another plant. The plant will
need to create as customer & a vendor. The code is maintained in
both the masters.
Industry Marketing Industry code can be used for reporting analysis. (for example)
Industry wise sales of the customers).
Customer
Classification
Marketing The customer can classify as per the reporting requirements for that
industry & can be used for reporting.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

17
Company Code Data Screen:
Account Management: Reconciliation account, the reconciliation account in general ledger
accounting is the account, which is, updated parallel to the sub ledger account for normal
postings.
Payment Transactions: Payment terms
Correspondence
Insurance

Important
Fields
Screen
Application
Reconciliation
Account
Account
Management
This is a mandatory field. The reconciliation account in
G/L accounting is the account which is updated parallel to
the sub ledger account for normal postings.
Payment
Methods
Payment
Transactions
List of payment methods which may be used in automatic
payment transactions with this customer/vendor if you do
not specify a payment method in the item to be paid.
Terms of
payment
Payment
Transactions
Key for defining payment terms composed of cash
discount percentages and payment periods.
Dunning
Procedure
Correspondence When the customer needs to be send reminders for
payment. Then dunning procedure can be maintained.
Policy Number Insurance In case of export credit insurance, the policy number &
amount insured etc details are maintained in Insurance
screen

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

18
Sales Area Data Screen: includes pricing data, delivery priority and shipping conditions.
Sales:
Sales Order: Sales District OVR0, Sales Office, Sales Group, Customer Group OVS9, and Item
Proposal.
Pricing & Statistics: Price Group, Customer Pricing Procedure & Price List Type.

Shipping:
Delivery Priority, Shipping Conditions, Delivering Plant, Order Combination, Complete Delivery,
Partial Delivery & Transportation Zone.
Billing:
Invoice Dates, Invoice List Dates, Rebates, Inco Terms, Terms of Payment, Account
Assignment Group & Tax Classification.

Partner Functions Screen.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

19
Important
Fields
Screen Application
Sales office Sales Sales Office defines Geographical aspects of the organization
in business development and sales. Used for Reporting.
Sales group Sales The staff of a sales office may be subdivided into sales
groups. Used for Reporting.
Customer
pricing
procedure
Sales
Determines which pricing procedure the system should apply
when you create a sales document for the customer.
Customer
Statistics
Group
Sales Specifies a statistics group for this customer and helps
determine which data the system updates in the logistics
information system.
Shipping
Conditions
Shipping General shipping strategy for the delivery of goods. The
Shipping condition along with other entities determines the
shipping point & Route proposed by the system.
Account
Assignment
Group
Billing Group of customers with the same accounting requirements.
The grouping can be domestic customers, foreign customer,
an affiliate customer etc.
Tax
classification
Billing The indicator with which the system determines output tax for
the customer when processing sales and distribution-specific
documents.

Customer Master CIN Details

Additional Component - CIN details enables you to capture the tax related information for the
customer.
This information can be maintained either in customer master additional component - CIN
details or in J1ID CIN master data transaction

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

20

Customer Master Transactions

Transaction Codes Application
VS00 SD Main Menu for Customer
XD01 Create Customer (Centrally)
XD02 Change Customer (Centrally)
XD03 Display Customer (Centrally)
XD04 Customer Changes (Centrally)
XD05 Block Customer (Centrally)
XD06 Mark for Deletion (Centrally)
XD07 Change Customer Account Group
XD99 Mass Maintenance: Indus. Matl Master
VXBC List of Blocked Customers

CREATE WITH REFERENCE: only data, which can be identical for both master records, is copied, for
e.g., Address, Unloading points, Vat reg., Contact person, and Tax classification are not copied. While
country, language, account group are.
DISPLAYING CHANGES IN CMD:
Sales & Distribution: VD04
Several Customers: OV51
BLOCKING A CMD: VD05
DELETING A CMD: VD06.The master data is deleted after all dependent data has been deleted
CHANGING ACCOUNT GROUP: XD07. Changes to the account group and the accompanying partner
functions can only be made from a lower level to a higher level.

MAIN MENU BAR IN VD02 CONTAINS:
Extras: Customer Account Group details, Blocking Data (VD05), Deletion Flags (VD06),
Text data can be maintained.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

21
Options for
Maintaining Customer
Master Data Purpose
Blocking Data This contains blocking of customer at company code level and Sales Areas
level. The posting Block can be for All Company code or Selected Company
Code. The Sales & Distribution Blocks can be for All Sales Areas or Selected
Sales Area for Order, Delivery, and Billing & Sales Support Blocks.
Deletion flag The customer can be flagged for deletion for All Sales Areas or Selected
Company Code or Selected Sales Area. The deletion blocks can be for
General Data or Selected company code including general data. Data records
such as Customers & Materials can be flagged for deletion but they do not get
deleted from the system and can be used to process a transaction. To avoid
any confusion, the name / description of these records is changed to <DO NOT
USE xxxx>.
Administrative Data It shows for which account group that customer is created. What levels (i.e.
General Data, Company Code Data and Sales Area Data), it has been created
by whom & when.
Confirmation of Change The confirmation of change status can be given central or at company code
level with changes to sensitive field. The current status can be confirmed or
rejected.
Text The customer master text can be maintained for General data level applicable
at client level and / or Company code and / or sales area data level.
Customer links to
Documents
Any documents / records with version applicable for that customer can be
linked in the customer master data.
Additional Customer
Data
SAP provides 10 freely definable fields for attributes & 5 additional fields for
condition determination & pricing.

Environment Credit Management (FD32), Customer Material Info Record (VD51), List Documents
(sales orders- VA05)

Options for Maintaining
Customer Master Data Purpose
Account Changes This functionality allows you to view changes to all fields or changes to the
sensitive fields (for example Payment Terms). Sensitive fields need to be
configured so in Customizing in FI menu. The changes include Deletions if
any.
Customer Material
Information
This menu option directly takes you to the view of the customer material info
records VD53 transaction.
Credit Management
This search criteria takes you to the customer credit management
FD33 transaction for the to view the credit limit details of the customer.
List Documents This functionality allows you to view list of documents ( Inquiries,
Quotations, Orders, Contracts, Deliveries & Billing documents) created for
that customer.

NOTE:
You would not have different customer numbers if your customer is serviced by more than one
company code or sales organisations.
You may have different data for the same customer no. in different sales areas.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

22

When you change a master record after having used it to create documents (orders, deliveries,
billing documents,), the changes do not affect the documents already created. However, the
address in the customer master is an exception. Therefore, if it was necessary, you would have
to change the data in the documents manually, except for the address.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

23
Customer Master Mass Maintenance (T. Code: MASS or XD90)

For processing large amount of data, Mass maintenance transaction is used
Mass maintenance is possible for a specific table(s) & field(s) within a table
Data also can be copied from a reference Customer master
If you wish to change a large number of objects simultaneously, you should choose
background mode.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

24
CUSTOMER MATERIAL INFORMATION RECORD: VD51

Customer uses a number or description for a material, which differs from the number or description of
your company uses to identify it, you can store the material number or description used by the
customer in the customer material information record.

Menu path: Easy Access- Logistics- SD- Master Data- Agreements- Customer mat info- Create/
change / display.
T. Code:
VD51 Create
VD52 Change
VD53 - Display

Customer material info record is information on a material that applies to a specific customer. This data
includes:
The customer-specific material number
The customer-specific material description
Customer-specific data on deliveries and delivery tolerances.
Plant
Delivery Priority
Minimum Delivery Quantity.
Item Usage
The data in the customer material info record has priority when master data is copied into SAP. In the
sales order the customer material must be entered in the customer material field.
Make sure the relevant indicator is set on the sales doc type in order for the system to read the cust
mat info record.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

25

5. COMMON DISTRIBUTION CHANNELS & DIVISIONS:
You can define common distribution channels & divisions. This is possible for 2 areas of SAP, for all
master relevant data, and for all condition relevant data.

Menu Path: SPRO- IMG- SD- Master Data- Define common Distribution Channels & Define common
Divisions. (Transaction Code: VOR1 & VOR2 respectively)

After creating the organizational structures and relevant master records you want to use as masters,
that is, in the distbn channels & divisions you are going to use as a reference, you can group distbn
channels & divisions separately for master data (which combines customer master & mat master
records), group cond records, or both master data & cond records.

Lets say you have a product range that is not different for the four different distbn channels you have
(the channels could be telesales, retail, industry & wholesale). Neither is there a diff in the customers
details when they purchase through one or the other. Thus, you will not want to create a multiple 4 view
of CMD & MMR. Merely create the CMD & MMR in one of the distbn channels, such as retail. Then
assign the other distbn channels you created in the organizational structure setup to this one.
Dont forget this means you can only create or change master data in the distbn channel that is
being referred. In the scenario above, this means you can only change the data for the retail
distbn channel. If you select other distbn channels, you will receive a message sales area is not
defined
Sales Orgn Dist Chan Descp Dist Chan Cond Descp Dist Chan Cond Descp

Reference distribution channel for conditions
Specifies a distribution channel that you want to use as a reference for condition data for other
distribution channels.

Procedure:
You can specify one distribution channel as the source of condition data for other distribution channels.
You need then only to maintain the data in one place.
Example:

In this example, only distribution channels 01 and 04 have condition data defined. Distribution channels
01, 02, and 03 share the master data that you defined for distribution channel 01. Distribution channel
04 has its own master data. When you create a sales order in distribution channel 03, the system
checks the condition data against the data defined for distribution channel 01.

Distbn Channel Ref Distbn Channel
01 01
02 01
03 01
04 04
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

26

Reference Distbn Channel for cust and material masters:
Specifies a distribution channel that you want to use as a reference for customer and material master
data for other distribution channels.
Procedure
You can specify one distribution channel as the source of customer and material master data for other
distribution channels. You need then only to maintain the data in one place.
In this example, only distribution channels 01 and 04 have customer and material master data defined.
Distribution channels 01, 02, and 03 share the master data that you defined for distribution channel 01.
Distribution channel 04 has its own master data. When you create a sales order in distribution channel
03, the system checks the customer and material master data against the data defined for distribution
channel 01.
Sales Orgn Div Descp Div Cond Descp Div Customer Descp
Reference division for conditions
Specifies a division where you can define conditions and share them with other divisions.
In this example, only divisions 01 and 04 have conditions defined. Divisions 01, 02, and 03 share the
conditions defined for division 01. Division 04 has its own conditions. If you create a sales order in
division 03, the system applies the conditions from division 01. You cannot create condition data for
divisions 02 and 03, since it would never be used.
Reference division for customers
Specifies a division where you can define customer master records and share them with other divisions
In this example, only divisions 01 and 04 have customer master data defined. Divisions 01, 02, and 03
share the customer master data defined for division 01. Division 04 has its own customer master data.
If you create a sales order in division 03, the system checks the customer master data from division 01.
You cannot create customer master data for divisions 02 and 03, since it would never be used.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

27

You can use this kind of processing to enter multiple materials with various divisions in sales
order.
You can control the following in Customizing, according to the sales document type:
Whether it is possible to enter multiple materials with various divisions for an order.
The way the system responds (with or without a warning message).
Whether the division on item level is copied from the material master record or whether the
division in the document header is also copied into the item.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

28

You cannot use this kind of processing to enter multiple materials with various divisions in an
order.
This can be controlled in Customizing, according to the sales document type.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

29

6. CUSTOMIZATION OF CMD or ACCOUNT GROUP: OVT0
Spro- IMG- Logistics General- Business Partner- Customer- Control- Define Account Group & Field
Selection For CMD.

When you create a master record for a business partner, you must enter an account group.
The account group determines:
Which screens & fields are necessary for entering master data
How master record numbers are assigned (externally or internally)
Which partner functions are valid
Default value for pricing procedure indicator
Out put control
Whether the business partner is a one time customer or one time vendor.
Suppressed Entry, Required Entry, Optional Entry & Grayed Out or Displayed.

NOTE: Dont forget to allocate this new account group into the list of allowed account numbers for
partner determination. The Account groups are defined in Finance.

No. Range customization for account group: OVZC
SPRO- IMG- Logistics General- Business Partner- Customer- Control- Define no range for CMD
OVZA: is for no range customization of sales documents.

Can be
defaulted in
the Master
Record
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

30

Customers are created in the following account groups and those are mandatory partner functions
required to process sales order.
SOLD TO PARTY: - Who places orders. Only needs sales relevant data. However a sold to party
can also be created as all the partner functions.
SHIP TO PARTY: - Who ships or receives goods. Only needs shipping relevant data, such as
unloading points and so on.
BILL TO PARTY: - Who receives Bills or Invoices. Only needs Basic data such as address and
out put fields.
PAYER: - Is the individual or company who settles the Invoices for a service or for delivered
goods.
Number Assignment
Use: A unique number is assigned to each business partner master record. You can use this number to
access the master record, or to refer to the business partner when processing business transactions.
Features: The number for a business partner master record can be assigned in one of the following
ways:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

31
Externally: You assign the number. In this case, you define a number range that allows for
alphanumerical number assignment. The system checks whether the number you enter are
unique and within the number range defined by the account group.
Internally: The system assigns a consecutive number automatically from a number range
defined by the account group.
The account group determines whether external or internal number assignment is allowed for a
business partner master record. For account groups 0001 to 0005, for example, only internal number
assignment is allowed in the standard R/3 System.

Number Range: A number range can be valid for more than one account group. You can use the
number range to assign different numbers to a head office and subsidiaries. In the standard R/3
System, the account groups for the following customer partner functions are in the same number range
so the numbers for these customer master records are assigned consecutively:
Sold-to party
Ship-to party
Bill-to party
Payer
Integration
A customer's number is unique for all sales areas and company codes. A vendor's number is unique for
all purchasing organizations and company codes. You first create a master record for your business
partner in one sales area. You then create a second master record for the same business partner in
another sales area. In this case, the system identifies the business partner number and does not
display the existing general data from the first master record for maintenance. You can use the change
and display functions to access the general data.
Prerequisites
In Customizing you define the number ranges that are to be available. You do this in the following
activities:
Logistics Basic Data: Business Partners
o Define and Assign Customer Number Ranges
o Define Number Ranges for Vendor Master Records
Accounts Receivable and Accounts Payable
o Create Number Ranges for Customer Accounts
o Assign Number Ranges to Customer Account Groups
o Create Number Ranges for Vendor Accounts
o Assign Number Ranges to Vendor Account Groups

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

32
6. MATERIAL MASTER DATA

Material Type and Industry sector Controls: Field Selection, Screen Sequence and Number Range.

Material Type:
When creating a material master record, the user must assign the material to a material type.
Materials with the same basic attributes are grouped together and assigned to a material type.
Permits user to manage different materials in a uniform manner in accordance with your
companys requirements.
The material type determines certain attributes of the material and has important control
functions.

Material Types Are:
1. Raw materials
2. Trading goods: HAWA
3. Semi-finished goods
4. Finished products: FERT
5. Services: DIEN
6. Non-stock material: NLAG

Menu path:
Easy access- Logistics- SD- Master Data- Products- Material- Other Material- Create, Change &
Display. MM01
Posting of the Stock: MB1C
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

33
To know the Stock Position: MMBE.

Industry Sectors: construction, chemical, mechanical, Media and pharmaceutical.
Unit of Measure:-
1. Base unit (Piece)
2. Alternative unit (12 pieces = 1 box)
3. Sale unit (Unit relevant for sales process)
4. Delivery unit (Unit in which material can be delivered)
Minimum order quantity
Minimum delivery quantity

Item category group: - (NORM) determines how the material processed in the sales order. For
example pricing does not take place for free of charge item. The system determines Item category
based on Item category group.

Customization of Material Master Data: T.Code: OMS9
How to delete a Material (MM06): - Easy access Logistics SD Master data Products Material
other material change. Or from main menu bar select material then flag for deletion.
How to block a material or in a particular season: - select MM02, go to sales org 1, under General
data, give blocking reason in the field D-Chain spec status.
Maintaining / extending view of Material: go to T.Code - MM50

If you go to MM02 Main menu bar, you will find the following information in
Environment tab page:
1. Display changes (MM04): - you will find what are the changes have you done to the particular
material with date, time, T.Code.
2. Stock overview (MMBE): - stock position details.
3. List of referring materials.

SD VIEWS ON MMR:
Basic data 1, Basic Data2
Sales orgn1, Sales orgn2
Sales General Plant
Sales Text
Foreign trade 1 & 2
Basic Data 1:
Base unit of measure
Division
Material group
Gross weight
Net weight
Weight unit: gm or kg
Basic Data 2: dangerous goods details

Sales Orgn 1:
Delivery plant
Tax classification of material
Minimum order quantity
Minimum delivery quantity
Sales unit
X- Distbn. Chain Status: (The cross-distribution-chain material status
restricts the usability of the material for all the distribution chains.)
D chain specific status: (restricts the usability of the material for the
distribution chain concerned.)
Cash Discount
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

34

Sales Orgn 2:
Item category group
General item category group
Material Pricing Group
Pricing Reference Material
Sales General Plant:
Availability check
Transportation group: rail, road.
Loading group: crane, forklift.
Sales Text: text about material.
Foreign Trade 1 & 2: if the company has got foreign trade.
Accounting 1: contains the cost of the product.

Material MasterBasic data: Basic data is valid for the whole company. The Organizational
Levels dialog box does not appear before you access this data screen

Important
Fields
Screen Application
Material description Basic Data 1 Text containing up to 40 characters that describes the material
in more detail. This defaults from Basic Data 1.
Base Unit of
Measure
Basic Data 1 Unit of measure in which stocks of the material are managed.
This defaults from Basic Data 1.
Division Basic Data 1 This filed also appears in the Sales Views and is generally
populated from there.
Material Group Basic Data 1 Key that you use to group together several materials or
services with the same attributes. This is a very important field
for reporting & analysis
X-plant material
status
Basic Data 1 It restricts the usability of the material for all plants, that is, it
defines whether a warning or error message is displayed if
you include the material in a particular unction for
Procurement, Production etc.
Size/Dimensions Basic Data 1 Its a Text field that you can use as you like. The filed length is
32 characters.
Material is
Configurable
Basic Data 2 If this indicator is set, you can assign a variant class to the
material, making it possible to use it as a configurable
material. The indicator is defaulted for material type KMAT

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

35

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

36
Material Master Sales Views

Important
Fields
Screen
Application
Sales Unit of
Measure
Sales: Sales
Org. 1
Enter a value in this field only if you want to use a unit of
Measure differing from the base unit of measure.
Delivering Plant Sales: Sales
Org. 1
This plant is automatically copied into the sales order item
as the default value
Tax
classification
material
Sales: Sales
Org. 1
The indicator with which the system determines output tax
for the material when processing sales and distribution-
specific documents.
Material
Statistics Group
Sales: Sales
Org. 2
Specifies a statistics group for this material and helps
determine which data the system updates in the logistics
information system.
Account
assignment
group
Sales: Sales
Org. 2
Group of materials with the same accounting requirements.
Item category
group
Sales: Sales
Org. 2
Materials grouping that helps the system to determine Item
Categories during sales document processing.
Checking Group
for Availability
Check
Sales:
General/Plant Specifies whether and how the system checks availability
and generates requirements.
Transportation
group
Sales:
General/Plant
A grouping of materials that share the same route and
transportation requirements.
Loading group Sales:
General/Plant
A grouping of materials that share the same loading
requirements.

Material Master Environment
Options in Material
Master Data Purpose
Defaults Data This option in Material Master allows you can set Industry Sector Default, Hide
Industry Sector in Industry Sector, Default views & Default the organizational
data for the material.
Information on
Material
This is the only place wherein we can see the material details in change or
display mode of the transactions. These details are Industry sector, Material
Type, Created by, Creation date, changed by, changed date, View wise status
information such deletion flags or locks for a material.
Display Changes
List of all change documents for the material
Stock Overview This search will directly take you to MMBE transaction for stock display at plant &
storage location level.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

37

Material Master Additional Data: Descriptions in different languages, Units of measure, Basic
Data Text etc can be maintained in Additional data

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

38
Adding Division does not multiply the material master views. But it does multiply the
customer master views.
Division creates material master. Division is a field in material master; it is not an
organizational unit.

Material Master Transactions

MM01 Create Material
MM02 Change Material
MM03 Display Material
MM04 Display Material Change Documents
MM06 Flag Material for Deletion
MM17 Mass Maintenance: Indus. Matl Master
MM50 List Extendable Materials
MM60 Materials List
MM70 Select Materials Flagged for Deletion
MMSC Enter Storage Locations Collectively
MMAM Change Material Type
MR21 Change Material Price

Material Master Mass Maintenance (T. code: MASS, MM17)

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

39
8. SALES DOCUMENTS

Purpose:

The sales department of any organization carries out a wide range of activities, each involving a great
deal of variation in and of itself.
This range from processing requests for quotations, sales orders to pricing, credit and product
availability.
The employees in a sales department are involved in many activities such as
- interacting with customers
- answer to their queries,
- provide them estimates,
- give updates of availability of products,
- offer appropriate products based on the buying pattern of the customer,
- perform order entry in the system and
- Maintain basic information about the customers, products and services that they
consume.

Challenges:
The challenges in the Sales are:
Different pricing for different customers
Delivery date confirmation with assured quantities
Online status update and Document history
Tracking of Materials and customer accounts
Updating of Information system to plan and control of sales
Monitor customer credit worthiness
Monitor follow up activities from sales support
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

40

Definition: Sales related business transactions are recorded in the system as sales documents.
These are grouped in to 4 categories:
Pre-sales document: Inquires & Quotations.
Sales Orders: OR/ RO/ CS.
Outline Agreements: Contracts & Scheduling Agreements.
Customer Complaints: Free of Charge Delivery (FD), Free of Charge Subsequent Delivery
(SDF), Credit Memo (G2), Debit Memo (L2), Returns (RE).

This slide represents the relationship between the processes in sales order processing in the
SAP
System. The sequence from top to bottom represents the order of events in the sales process.
The boxes represent sales and financial accounting documents.
Sales activities and promotions are documents for sales support in pre-sales.
Sales documents are documents that are entered during pre-sales and sales order processing.
Inquiries, quotations, contracts, scheduling agreements and standard orders are examples of sales
document types.
Outbound deliveries, transfer orders and shipments are documents in shipping processing. The
goods issue document contains changes involving stock and is the basis for the relevant
accounting documents.
The billing document is a document in billing and is the basis for the relevant accounting
documents.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

41
The left and right sections of this slide represent key interfaces between Sales and Distribution
and the Sales Information System (SAP data warehouse), Materials Management and Production
Planning.

Sales order:
Sales order is a contractual agreement between a organization and a customer about delivering
products or providing a service for defined prices, quantities and times

Sales Orders normally contain information on Customer, Material, customer material information,
pricing conditions for each item, Delivery dates and quantities for each item, Shipping processing
information and Billing information.

STRUCTURE OF SALES DOCUMENT: All sales documents have basically the same
structure.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

42
Header Data:(VBAK):

Item Data :( VBAP): This is controlled by sales item category, such as TAN.

Schedule Line Data :( VBEP): This is controlled by schedule line category, such as CP.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

43

FUNCTIONS OF SALES DOCUMENT: During sales order processing, the system carries out
basic functions, such as:

Determining the delivering plant, Shipping point & Route automatically

Availability check Systems ability to automatically determine a delivery (promise) date
for a sales order

Delivery Scheduling determines lead times for delivery processing.

Transfer of requirements - determines the item requirements to be passed to
materials planning (MRP)

Pricing- indicates how a price should be determined for the sales order item.

Sales Information System - dictates how the sales information system is updated with
sales order information to plan and control sales.

Checking Credit Limits
Output
Text

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

44
Types of Sales Documents used in Business process
1. INQUIRY (IN): Non-Binding Agreement: For example, a customer inquires whether we have a
certain product in our warehouse, how much it will cost, or whether the product will be available for a
certain date. The inquiry will not be sent to the customer.
A customers request to a company that they provide a quotation or sales information without
obligation. Doc Type: IN, Trans Code to Create inquiry: VA11. The standard item category for inquiry is
AFN.
2. QUOTATION (QT): Binding Agreement from <Client>: A quotation presents the customer with
a legally binding offer for delivering a product or service within certain fixed conditions, such as the
validity period and the terms and conditions.
Doc Type: QT, Trans Code to Create Quotation: VA21. The standard item category used in
quotation is AGN.
3. Out Line Agreements: These are further divided into
(A) SCHEDULING AGREEMENTS: Outline agreements with determined schedule lines. A
delivery note is created directly from the scheduling agreement (release order is not required)
A customer scheduling agreement is an outline agreement with the customer containing delivery
quantities and dates. Trans Code: VA31. Doc Types: DS- Scheduling Agreements, COB- Sch
Agreements BR, BL- Sch Agreement w/del schedule.
(B) Contracts (VA41):- Outline agreements with fixed quantity or value that a customer promises to
order over a specified period of time, as well as the price involved. It requires a release order to make a
delivery. Pricing (procedure and/or discounts) is copied to release order from the contract
Delivery quantities and specific dates are not mentioned. Ex: 600 quantities in 3 months.
Types of contracts. 1. Quantity contracts. 2. Value contracts 3. Service contracts. 4.
Master contracts. 5. Sub contracts.
4. Standard order (OR): Normal standard order contains, Sales order Delivery PGI Invoicing
or Billing.
5. Rush Order (RO): It means immediate delivery, but account is not settled immediately. Sales
order PGI Invoicing or Billing.
6. Cash Sales (CS): Known as plant sales, means stock supplied immediately and account is
settled immediately. Delivery and Picking done at background by the system. Sales order PGI
Invoice.
7. Consignment stock processing: - Keeping Companys stock at customers place.
Consignment Fill up (CF): Ex: Assume that company kept 100 boxes of Crocin tabs at NIMS
hospital. But it is property or owner ship is with company. This is called as consignment Fill up. No
Billing will be done here.
Consignment Issue (CI): Invoice is raised whatever the consumed quantities by NIMS. EX: 15
boxes of crocin sold by NIMS hospital. So Bill will be raised for 15boxes only.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

45
Consignment Return (CONR): Stock return by the customer to NIMS hospital. Ex: 2 boxes of
Crocin returned by customer to NIMS.
Consignment Pick up (CP): what ever the remaining quantity and received returns by
customers is send to company by NIMS. That is called consignment pick up. Ex: 87 boxes send back to
company.
8. Third party order processing: Documents used OR / RO. EX: LG show room sells only TVs,
but received order from a customer for TVs and stabilizers. LG show room informs to a Vendor
to supply stabilizers directly to customer. Bill sends to LG and LG sends bill to customer.
9. Individual purchase order processing: EX: LG show room sells only TVs, but received order
from a customer for TVs and stabilizers. LG show room gets stabilizers from a Vendor. And LG
show room sends stock of TVs and Stabilizers to customer.
10. Inter company sales: with in the company sales organization will bill to the other sales org and
sales org supplies to customer. Documents used OR or RO.
11. Returnable package (RP): EX: Coke / chemicals / Gas. Customer has to return the container
to the company. Coke Company supplies to distributor. He was charged only for drink not for
bottle. Bottle has to returned by distributor to company.
12. Make to order: Once company receives order from customer then only it starts manufacturing
the product. Ex: Boeing Flights.
13. Sales Returns (RE): Goods returned by customer due to non moving or damaged.
14. Credit memo request (G2): if customer requests to raise a credit memo for returned stock.
15. Debit memo request (L2): If company charges any extra price to customer, then company
raise a debit memo request.
16. Free of charge delivery (FD): Ex. Sending Free samples by company to Drs or customers
without charging price.
17. Subsequent free of charge delivery (SDF): If customer requests for replacing any other
product towards stock returned by him.

TYPES OF SALES DOCUMENTS: VOV8
OR Standard order RO Rush order
CS Cash sales IN Inquiry
QT Quotation DS Scheduling agreements
B1 Rebate credit memo request B2 Rebate correction request
CD Free of charge delivery SDF Subsequent free of charge del
CF Consignment fill up CI Consignment issue
CONR Consignment return CP Consignment pick up

Sales Document Type - Controls

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

46

Note: Activating checks can affect the system performance.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

47
DOCUMENT FLOW (Details)

SALES COMPLAINTS
Doc
Type
Parameter
Std Order
Cash
Sales
Rush
Order
Service
Free
Goods
Returns Dely FoC
Subs
Dely FoC
Credit
Memo
Debit
Memo
Invoice
Correct
Ref Doc
IN, QT,
OR
- - Ord / Bill - RE Ord / Bill Ord / Bill F1, F2
Doc Type OR BV RO OR RE FD SDF RK
Sales
Doc
Item Catg TAN BVN REN TAD TAN/TANN REN KLN KLN
Dely Type LF BV LF LR LF LF - - -
Delivery
Dely Item Cat TAN BVN REN REN KLN KLN - - -
Billing Type F1, F2 BV F2 F1 RE - - G2/L2
Billing
Billing Item REN - -
Cancel Cancel Doc S1 SV - -
Important Features

Contract Bill Plans
Doc
Type
Parameter
Fill-up Pick-up Issue Return
Gen
Value
Matl-
Related
Service Periodic Milestone
Ref Doc
IN, QT,
OR
- -
Doc Type OR CS RO WK1 WK2
Sales
Doc
Item Catg WKN WVN TAO
Dely Type LF BV
Delivery
Dely Item Cat
Billing Type BV
Billing
Billing Item
Cancel Cancel Doc

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

48
DOCUMENT FLOW OR SALES ORDER CYCLE:
Sales Order Cycle starts with:
Inquiry- Quotation- Sales Order- Delivery- Invoice- Returns - Credit memo or SDF.

What is a Sales order?
A sales order is a contractual agreement between a sales organization and a customer
(sold to party) for the supply of services or products over a specific period or time with certain
quantities.

VA00 is transaction code used for Sales overview screen.

Normal sales order process has got the following procedure.
Sales order Delivery or out bound delivery Picking Goods Issue (PGI) Billing or Invoice.

The following mandatory information is required to fill in the initial screens.
1. To create a Sales order (VA01/02/03):-
Order type:
Sales organization:
Distribution channel:
Division:

2. To create Delivery or Out bound delivery (VL01N/2N/ 3N):
Shipping point :
Selection date : (Automatically come from sales order. If it does not come give selection
date as requested delivery date found in sales order screen)
Order : (AUTO)

3. Picking or Transfer order (LT03):
Wear house No :
Plant :
Delivery : (Auto)
4. Goods Issue (PGI) (VL02N):
Out bound delivery: (Auto)
5. Invoice or Billing (VF01):
Invoice No: (Auto).

Note: To check status: Go to VA02. Enter then click on Display Document Flow icon.

Sales - Transactions

VA11 / 12 / 13 Create / Change / Display Inquiry
VA21 / 22 / 23 Create / Change / Display Quotation
VA41 / 42 / 43 Create / Change / Display Contract
VA31 / 32 / 33 Create / Change / Display Scheduling Agreement
VA01 / 02 / 03 Create / Change / Display Sales Order

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

49
Inquiry:
Customer contact records which capture pre-sales information
Can be for material or text items
Serve as system references for future activity
Serve as follow up for business that did not happen
The validity period can be used as a processing limit

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

50
Quotation
A quotation can be created with or without reference to an inquiry
Quotations are offers from a sales area to a customer for delivering materials or providing services
under specified conditions.
Quotations are legally binding throughout the given validity period.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

51
Sales Order Header

Important
Fields
Screen
Application
Sold to Party Main Screen Each sales order is assigned to unique sales area (sales organization,
distribution channel, or division). If there is master data for the sold-to
party in several sales areas, a selection screen appears where you can
choose the sales area you require.
If there are several possible sold-to parties for the ship-to party, the
system displays a selection screen with the possible alternatives.
Order type Sales View A classification that distinguishes between different types of sales
document.
Blocking
Document
Sales View In sales orders, you can block the transactions for shipping or for billing.
Billing block can be set in the document header, and also in the individual
item.
Reason for
Rejection
Sales View You can reject items in sales documents. This gives the items the status
of completed. The business transaction thus be concluded without
deleting the item.
Also a reason for rejection allows you to find out what your customer
thinks of your products during a certain time period.
Account
Assignment
category
Billing Using the account assignment criteria as a variable G/L account can be
determined

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

52
Sales Order - Item

Important
Fields
Screen
Application
Material Sales For each material in the sales order, the system automatically proposes data
from the relevant material master records, such as data for pricing, delivery,
scheduling, availability check, tax determination, weight and volume
determination.
Delivering
Plant
Sales A plant is required to source inventory for a sales order. The plant can be
defaulted on the priority to customer material information record, then look in
the ship to party customer master and then the material master.
Shipping
Point
Shipping The shipping point is automatically determined on the combination of the
delivering plant based on plant determination or manual override of the sales
order item, the shipping condition of the sold to party customer master record
(Sales Area Data, view: Shipping) and the loading group in the material master
(Sales: General/Plant Data View)
Shipping
condition
Shipping The shipping condition in the customer master is used to define customers
delivery requirements (Sales Area Data, view: Shipping).
Route Shipping A Route is transportation path of an outbound delivery from the delivering plant
to the ship-to party. SAP R/3 uses four data element as search keys for
determining the route automatically. These data elements are : The departure
transportation Zone found in customizing for the shipping point definition, the
shipping condition found in the customer master of the sold party (Sales Area
Data; Shipping view), the transportation group found in the material master
(Sales: General/Plant Data View) and the destination transportation zone
found in the ship-to party master data record (General/Plant; Address view)
Pricing Condition The PR00 is defined as the mandatory pricing condition.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

53
Sales Order Environment

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

54
Sales Order Enhanced Functions

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

55
Contract
A contract includes quantity contracts, value contracts & rental contracts.
QC Quantity Contract, WK1 General value Contract, WK2 Material Value contract, QP Rental
Contract and SC Service and maintenance

Scheduling Agreement:
Contains fixed delivery dates and quantities.
Once the scheduling agreement is due for delivery, you can create the delivery as
normal or by using a delivery due list

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

56

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

57

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

58

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

59
Sources for Document Data

During data input for sales documents, the system supports you by analyzing various sources of
information. The aim is to make creating documents easier by using default values or fixed
reference data. Possible sources of information are:
Master data: The system reads the master data defined for a customer, a material, or a pricing
condition. For example, the specific terms of payment for a customer can be found. The sales
information from a material master can serve as the source of the delivering plant.
Existing document data: Document data that has already been entered or determined
automatically by the system can be used to enter additional documents data. For example, the
delivering plant is used - along with other information - to determine the shipping point.
Customizing: Default values for creating documents can be defined in Customizing. For
example, you can set a default value for the delivery date or configure a delivery or billing block in
the sales document type. You can also define strategies in Customizing for determining document
information based on combinations of several criteria (for example: determining the shipping point
through a combination of delivering plant, loading group, and shipping condition).
Hard-coded controls: Hard-coded controls can be used to weight the different sources of
information (example: proposing plants automatically).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

60

Sales processes are controlled by Customizing for sales documents.
Customizing for sales documents can be done at header, item or schedule line level, depending
on the structure of the document. The instruments for control are the sales document type, item
category and schedule line category.
You need to make settings in Customizing so that the item and schedule line categories are
determined automatically in the sales document.
To complete the setup of a business process in your system, you need to configure the system
for forwarding data from the sales document to subsequent documents according to your needs.
You can do this in copying control.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

61

The diagram contains examples with settings as they are provided in the standard R/3 System.
Every item in a sales document is controlled through its item category. This enables you to
Use different item categories in different sales document types,
Realize different business processes for each item in the sales document.
You can configure the functions of the item categories according to your requirements. For
example:
You want schedule lines for a free-of-charge item in the sales order (item category TANN)
but
You do not want to carry out pricing for this item or transfer it to billing.
You do not need pricing or delivery quantities and dates (that is, schedule lines) for a text
item
(Item category TATX) in the standard order. However, if you need the item in the delivery or
billing documents, you can indicate it as relevant for delivery or billing.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

62
Sales Document (VOV8) DETAILS:
Item No. Increment: how line items no should increase in documents.
Check Division: Controls how the system reacts during sales order processing when a
division that is entered or proposed at the item level differs from the division in the
document header
Item Division: Indicates whether the division at the item level is proposed from the
material master record of the item or whether the division you enter in the sales document
header also counts for all items. If you mark this field, the system proposes the division from
the material master record of the item. If you leave the field blank, the division in the
document header also counts for all items.
Probability: IN: 30%, QT: 70% and Order: 100%
Check Credit Limit: how system should respond to check during order processing
Read Info Record
DoPP: the key that specifies the pricing proc for this type of sales doc.
Display Criteria: should system display only main or sub items or all items in sales doc
F.Code Overview Screen: after you enter the data in the initial sales doc screen, which
overview screens the customer wants.
Quotation Messages:
Incompletion Message: check this field & u cant save an incomplete doc.
Delivery Type: LF for OR and RO. BV for CS
Delivery Block
Shipping Conditions: specify a value here and the value in CMD is not taken.
Delivery Related Billing Type & Order Related Billing Type
Billing Block
Proposes Del Date: Indicates whether the system automatically proposes the current date
as the delivery date.
Business Transaction: This entry makes it possible to use the availability check settings in
the APO planning system for this order type. Use: Using the business transaction, you can
control in which business contexts a rule-based availability check is carried out. A rule-
based availability check is therefore, as a rule, not sensible for a rush order.
When called from the ERP system, this value is created using the order type for the sales
order from which calling takes place.
Lead Time In Days: specify the number of days after the current date that the proposal for
the requested delivery date in the sales doc should be.
Immediate Delivery.
1) COMPARISON BETWEEN DIFFERENT SALES DOCUMENTS

Imp
Fields
Std
Ord
Rush
Ord
Cash
Sls
Retur
ns
Cr
Req
Dr
Req
Cons
Fill
Cons
Issue
Cons
Pick-
up
Cons
Retur
ns
Dely
FoC
Subs
Dely
FoC
Doc
Type
OR RO CS RE CR DR CF CI CP CR FD SDF

Mand
Ref
- - - Yes - - - - - -
-
Yes
Item
Divn

Ship
Cond
01

Immd
Dely
- Yes Yes

Dely
Type
LF LF BV LR

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

63
Bill Type F2 BV RE G2 L2 - F2 - F2

9. SPECIAL BUSINESS TRANSACTIONS (Cash order & Rush order sales)

1) RUSH ORDERS

Rush order is used when the customer wants to picks up the goods immediately or when the goods
have to be delivered the same day.

The delivery document is created automatically as soon as the order is placed.
Rush Order
(RO)
Delivery
(LF)
Billing

Transfer order

Created
Automatically
Invoice
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

64
Billing is processed in the standard way-based on the delivery.
Availability check is carried out, and only available quantity is delivered.

2) CASH SALES

a) Immediate Delivery, Billing Date = Today
b) Invoice printed directly from Cash Sales Order with same number as Cash Sales Order.
c) Order-related Billing.
d) Picking & Availability Check normally not necessary.
e) Collective PGI.
f) Billing can be done only after PGI.
g) For Invoice: No Output, no new Price Determination,
Order type BV, Billing type BV, Delivery type BV, Special Account key -- EVV is used for
cash sales.
Billing type SV is used for cancellation of cash sales.
For cash sales payment is made when the goods are ordered.
The Invoice is also printed at the same time
The order, Delivery and picking are created in one step, although you receive documents for
each. It is an order related billing (F1) since delivery is created automatically.
The Goods Issue is posted at a later time as separate transaction, so the customer does not
have to wait.
It has own output type RD03 which allows you to print an invoice from the order.
Pricing type D is used in Copy control.
In Cash sales customers belongs mostly one time customer. They are created in the account
group of CPDA.
Cash sales triggers Petty cash account or Cash settlement account , not to the customer
account.
Cash Sales
(BV)
Delivery
(BV)
Billing
(BV)
Transfer Order
Created
Automatically
in the ack
Invoice
(RD03)
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

65

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

66

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

67

10. ITEM CATEGORY
The item category controls what the item does in the sales doc & in any later processing for that
business transaction. It controls the sales doc & affects the schedule line category.
A classification that distinguishes between different types of items (for e.g., free of charge items & text
items) & determines how the system processes the item. E.g., if you identify an item as a free of
charge item, you tell the system, in this case to ignore the normal pricing procedure.
The system uses an item category to process a material differently in each sales doc type: in inquiry,
the standard item is priced but not relevant for delivery. For the free of charge item, no pricing & no
delivery. But in sales order both the items are relevant for delivery and pricing is carried out for the
standard item.
Standard Item: (AFN: Inquiry), (AGN: Quotation), (TAN: Sales Order)
Free of Charge Item: (AFNN: Inquiry), (AGNN: Quotation), (TANN: Sales Order)
Non-Stock Item: (AFX: Inquiry), (AGX: Quotation), (TAX: Sales Order)
Text Item: (AFTX: Inquiry), (AGTX: Quotation), (TATX: Sales Order)
Item Category Controls: document, billing, pricing, delivery/shipping & incompletion log.
Whether the item refers to a material master record (or is a text or value item)
Whether schedule lines are allowed
Whether pricing is relevant
Whether billing is relevant
Which data is required for the item (will appear in the incompletion log)?
Whether the business data in the item can be different to that of the doc header.
Defining Item Category: VOV7: SPRO- IMG- SD- Sales- Sales Document- Sales Document Item-
Define Item Category.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

68

The Item Category for the sub item on a sales document is determined by Sales document type,
Item category group and Item category of higher level item
FUNCTIONALITY OF ITEM CATEGORY
Item Type: whether standard or text or value item
Completion Rule: The rule for establishing when a quotation or contract is complete.
Business Data Item: whether business data in the item can be different to that of the doc header.
Relevant for billing
Schedule Line Allowed: Items that are relevant for del will always have schedule lines.
Order Quantity = 1
Item Relevant for Delivery: we need to check this field in item cat: TATX.
Create Delivery Group: You use a delivery group to determine a common delivery date for all
the items that it contains. Especially used in BOM.
Determine Cost: Indicates whether, during pricing, the system determines the cost (stock
value) of a sales document item.
Relevant for weight and volume
Credit active.
Pricing: In the case of text items, however, pricing would not make sense.
Types of Item Category
BVN Cash Sale TAS Third party
TAB Individual order purchase REN Returns
G2N Credit memo L2N Debit memo
TAK Make to order TAC Configurable material
KBN Consignment fill up KEN Consignment issue
KRN Consignment return KAN Consignment Pickup
TAQ Extent delivery- BOM TAP Extent delivery- higher lever item in BOM
TAE Explanation- BOM TAW Value Item
BANS Third party Item cat group BANC Individual purchase Item category group
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

69
Text items do not require processing for pricing, taxes & weight calculations
Items that are not relevant for del, such as credit memo requests, do not have schedule lines.
Usually, items that do not have schedule lines cannot be copied in to a delivery. Text items are
an exception.

To configure Item Categories: IMG ->Sales and Distribution -> Sales -> Sales Documents ->
Sales document Item -> Define Item Categories
Functions Example
Standard item in QT Pricing, Schedule Line Allowed, Not relevant for billing, AGN
Standard item in Order Pricing, Schedule Line Allowed, Relevant for billing TAN
Free of Charge Item in order No pricing, Schedule line allowed, not relevant for billing TANN

Text item in Order No pricing, No schedule lines, relevant for billing TATX
You do not need pricing or del quantities & dates (i.e. schedule lines) for a text item (item
cat: TATX), in the standard order.
COMPARISON BETWEEN DIFFERENT ITEM CATEGORIES

Item Cat AGN TAN TANN TAP TAQ TAE TAD TATX TAK KLN TAO WVN

BoM
H
BoMH
BoM
S
Mile Perio
Business It -
Pricing Y Std
100%
Disc
N Y N Y - N
Sch Lines Y Y Y Y Y Y Y -
Item Rel
Dely
- - - - - - - Y
Bill Relev - Dely Dely Dely Ord - N I
Struc Scop - - - 1 Lvl 1 Lvl - -
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

70
Deter. Cost Y Y Y Y -
ITEM CATEGORY DETERMINATION
Depending on the item category group that you apply & the sales doc type you are processing the
system automatically proposes an item category in the document.
Document type Item cat group Usage Higher level item category Default Item category
OR NORM TAN TANN
OR NORM TAN
OR NORM FREE TAN TANN
SPRO- IMG- SD- Sales- Sales Document- Sales Document Item- Assign Item Category (VOV4)

11. SCHEDULE LINE CATEGORY
DEFINE SCHEDULE LINE CATEGORY: VOV6
Subdivision, according to date & qty, of an item in a sales doc.
The schedule line category is used by the system to determine if the item is relevant for delivery. Only
those items that have schedule lines assigned will have a delivery created for them.
SPRO- IMG- SD- Sales- Sales Documents- Schedule Lines- Define Schedule Line Categories.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

71

Schedule Line Category Controls

AT: Inquiry schedule line
BN, CN, D0: No MRP & No Availability Check
CP / BP/E1/C1/F1: MRP & Availability Check
BV & CV: same as BN & CN, but MRP passed on for info purpose
Goods receipt is posted for the schedule line DN in a return doc
---------------------------------------------------------------------------------------
CN, CP, CT, CV: relevant for delivery, other Sch line cat are not
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

72
CP, CV, CN: sales order schedule lines
CP: deterministic MRP
CV: consumption MRP
CN: no leg
CS: third party item
BN: quotation
DN: returns
BP: deterministic MRP
BV: consumption MRP
CT: no inventory mgmt/ no goods issue
-------------------------------------------------------------------------------------------------------
Movement types: SD related movement types from 561.
601 Goods issue delivery 602 Returns
561 Posting the stock in the plant 301 Plant to plant stock transfer
302 Return of the stock transfer
451 Returns from customers 452 Returns from customer reversal
661 GI Returns to vendor 901 Return of stock to a supplier
631 Consignment fill up 634 Consignment Return
633 Consignment Issue 632 Consignment Pick up

ASSIGN SCHEDULE LINE CATEGORY DETERMINATION: VOV5
The schedule line cat depends on the item category of the item & MRP of the material. The MRP type
is found in the MMR, MRP 1 screen.
SPRO- IMG- SD- Sales- Sales Documents- Schedule Lines- Assign Sch Line Categories
Item Category MRP type Schedule line cat Manual Sch Line Cat
OR TAN PD CP (item rel for del)
IN AFN ND AT
QT AGN ND BN

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

73

12. SALES ORDERS
Sales Order is a contractual agreement between a sales orgn & sold to party abut delivering products
or providing a service for defined prices, quantities & times.
Standard Functions during Order Processing:
Pricing
Availability check (if this function is defined in MMR)
Transferring requirements to material planning (MRP)
Delivering scheduling
Shipping point & route determination
Checking credit limits.
Changes at Item Level:
Select Line Item & Go To & Select
Shipping: to change plant & shipping point
Schedule Lines: to change delivery dates
Partners: to change ship to party.
Making Fast Changes:
Using this function, you can change the following data for several or all items:
Reason for rejection
Delivery block
Billing Block
Delivery date
Delivery priority
Plant.
Choose EditFast Change of & the relevant process.
Transaction Code Standard Order Rush Order Cash Sales
VA01, 2,3 Order Order Order
VL01N, 2N, 3N Delivery --- ---
LT03 Picking Picking ---
VL02N Goods Issue Goods Issue Goods Issue
VF01, 02, 03 Invoice Invoice Invoice.
Type VA02 & click on Display Document Flow.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

74

Blocking Sales Orders
You can block sales orders for the following subsequent functions:
For shipping:
The system does not let you create a delivery for a sales order that is blocked for shipping. You
receive an error message telling you that the order is blocked for delivery.
For billing:
The system does not allow you to create a billing document for a delivery that is blocked for
billing in the underlying sales order. When you try to create individual billing documents, the
system enters a message in the relevant log. In the case of collective processing of billing
documents, the delivery is not included in the billing due list.
In addition, it is possible to block sales document types for certain customers, so that youi can prevent
certain types of sales documents being created for a particular customer.

Setting a Delivery Block
You can set a delivery block at header level as well as in the individual items and schedule lines:
To display this information at header level, choose the Shipping tab page from the overview
screen. You can set the delivery block in the Delivery block field.
You can set the delivery block at item level on the overview screen in the Shipping tab page, by
selecting the item and entering the block in the Delivery block field in the table.
To enter a delivery block in a schedule line, select the appropriate item on the Item Overview
tab page and then choose Goto Item Schedule lines. You can set a delivery block for the
schedule line in the Delivery block field in the table.
A delivery block at header level is only effective if it has been assigned to the
corresponding delivery type in Customizing (table TVLSP). Regardless of this
assignment, the delivery block is still effective at schedule line level.

Setting a Billing Block
You can set a billing block at header level and for the individual items:
To set the billing block at header level, choose the Sales tab page from the overview screen and
activate it in the Billing block field.
To enter a delivery block for an item, select the appropriate item on the Item Overview tab page
and then choose Goto Item Billing. You can then activate it in the Billing block field.

You can also use the fast change function to set delivery and billing blocks at header
and item level. For more information, see Making Fast Changes.

Blocking Sales Document Types
It is also possible to customize your system so that specific types of sales documents are blocked for
specific customers. For more information, see blocking a Customer Master Record.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

75

BASIC FUNCTIONS
13. PARTNER DETERMINATION: VOPA

The business partners that exist in the marketplace are represented with a partner type in the
R/3 System.
Partner types AP, KU, LI and PE are defined in partner processing for the Sales and Distribution
application module. These are defined as follows:
AP Contact person
KU Customer
LI Vendor
PE Personnel
In other applications (such as Service Management) different partner types have been defined (for
example, O for organizational unit, S for position, A for work center).
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

76

While the partner types allow us to distinguish between different business partners, the partner
functions represent the roles they play within the business transaction.
For example, different customers (customer partners) can assume certain roles in a business
transaction. The customer who places the order does not necessarily have to be the same
customer who receives the goods or the customer who is responsible for paying the invoice.
Assigning partner functions in the SAP system determine the function(s) of particular partners in
the sales process. One partner may take on several functions.
In the simplest case, all the partner functions within the customer partner type would be
assigned to one person. In other words, the same customer would be the sold-to party, ship-to
party, and payer and bill-to party.
You can enter contact persons for a customer directly in the customer master and they are
automatically assigned to that customer. The contact person can also be assigned to another
customer, for example, in a consultant role.
The forwarding agent is an example of a vendor.
Employees of your own company (such as sales representatives or clerks) are managed in the
employee master records. They can assume partner functions of partner type "Personnel", such as
partner function ER, responsible employee.

A business partner like Customer can play many roles (functions) in a transaction The partner functions
like of Sold-to Party, Ship-to Party, Bill-to Party and Payer are essential for sales document processing.

Sold-to Party: Sold- to party is the business partner to whom the goods are sold. It needs only
sales relevant data in customer master

Ship-to Party: Ship-to Party is the business partner to whom the goods are shipped. It needs
only shipping relevant data such as unloading point

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

77
Bill-to Party: Bill-to Party is the business partner to whom the bills is sent, needs only the basic
data such as address and output procedures

Payer: Payer is the individual or the company who settles the invoice

You can do partner determination in the following areas.
1. Customer master
2. Sales document Header
3. Sales document Item
4. Delivery
5. Transport
6. Billing Header
7. Billing Item
8. Sales Activities.
Partner Types and Assigned Partner Functions
Partner type Partner function, e.g.
Entry expected
from system
Type of master
record
Customer (KU) Sold-to party (SP)
Ship-to party (SH)
Bill-to party (BP)
Payer (PY)
Customer number Customer master
record
Vendor (V) Forwarding agent (fwdg agent) Vendor number Vendor master record
Human resources
(HR)
Employee responsible (ER)
Sales personnel (SP)
Personnel number Personnel master
record
Contact person
(CP)
Contact person (CP) Contact partner
number
(Created in customer
master record, no
master record of its
own)
No new partner types may be added to the partner types given by the system.
Activities: If a partner belongs to different partner types, you must create a corresponding amount of
master records for this partner. If, for example, a customer company also delivers goods to you, you
must create a customer master record as well as a vendor master record.
Menu path: SPRO- IMG- SD - Basic Functions- Partner Determination:
Partner Determination is maintained for various Partner Objects
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

78

Define partner functions
Define & Assign Partner Determination Procedure
Assign Partner Function on the debit side of the account group
1. Defining Partner Functions: here we must not define any partner functions. If we
check the field unique that partner function has to be unique in the CMD.
2. Assigning the Partner Functions to the Account Group: on the main menu bar, you
will find tab page called EnvironmentAccount Group Assignment. Go to new entries
and assign the required partner functions to the required account group & save it.
3. Defining the Partner Determination Procedure: replace AG with your 4-digit code.
Double Click on the 4-digit code and select the mandatory and not changeable partner
functions. (Click on partner procedures).
4. Procedure Assignment to Account Group: assign partner determination procedure to
the account group. (Click on procedure assignment).
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

79

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

80
14. CONDITION TECHNIQUE STEPS

The condition tech refers to the method by which the system determines elements from information
stored in condition records.
The cond tech is used by SAP to find a choice from among a number of alternatives. SAP makes the
choice based on conditions, hence the name Cond Tech.
1. Condition table: combination of fields that identifies a condition record. The fields that you
select are called Selected Fields. The fields from which you make your selection are called
Allowed Fields or Field Catalog. (Most general to most specific). Cond table contains the key
fields for maintaining cond records, i.e., cond records are stored in cond table.
2. Access Sequence: search strategy with the help of which the system gets valid cond records.
It contains the required cond table in required order (in which sequence should the system
search) (most specific to most general is the sequence)
3. Cond Type: is a representation in the system of some aspect of your daily (pricing) activities.
4. Maintain Proc: arranging Cond types logically.
5. Determination Rule: linking your proc, e.g. to cust, through CuPP.
6. Condition Records: where data is stored and retrieved.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

81
15. OUTPUT DETERMINATION
Output is a form of media from business to one of its business partners. The output can be sent to any
of the partners defined in the document. Outputs are usually in the form of Order Confirmations, Freight
List, Delivery Notes, Invoices & Shipping Notifications. Determining form of output is output
determination.
Output is a Means of communication for exchanging information between partners & systems.
Can be transmitted for different types of Sales Documents via different transmission methods.
Available at Header and Item level.

Out put determination can be done in the following areas.
Billing documents.
Delivery documents
Sales documents
Sales activities
Picking lists
Shipping units.
Groups (Type of collective processing)
Shipments

1) OUTPUT DETERMINATION PROCEDURE
Maintained separately for
Sales Documents (Header / Item)
Billing documents (Header)
Delivery Documents (Header / Item)

Step Step Description Remark
1
Maintain Condition Tables /
Accesses

2
Assign Accesses to Access
Sequence

3
Assign Access Sequence to
Output Type

4
Assign Output Types to
Procedures

5
Assign Procedure to Document
Types

--
Assign Output Type to Partner
Functions
To control which Output Types
can be sent to which Partner
Functions

2) ACCESS SEQUENCE
Priority
Conditio
n Table
Access Description
Require
ment
Exclusive
Key Fields for search
strategy
Normally X

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

82
3) CONDITION RECORDS FOR EACH OUTPUT TYPE
Partner Function
Transmission
Medium
Date / Time Language
Partner Function from
Document to whom to
send
Output.
Possible to create
output without Partner.
How output is
produced:
1) Print
2) Fax
3) Telex
4) External Send
5) EDI
Independent
1) As per
periodically run
program
2) User-specified
time
3) Explicit
Request

Dependent
4) Immediate
(as soon as
doc is posted)
Program to run Output is RSNAST00.

4) COMMUNICATION STRATEGY
Used in case Transmission medium is 5 (External Send) to define how system should find output
address from a sequence of Communication Types (Email / Fax number / Postal Address).

5) OUTPUT PROCESSING
a) Structure and Data of the documents used online are defined in the Database. To send output,
data must be procured from Database and prepared in accordance with Transmission Medium.
b) Steps to Print Output:
i) ABAP Processing Program reads Data from Database using Communication Structure
ii) ABAP Processing Program processes the data and passes it on to SAP Script (Output
Layout) containing.
iii) Output is transmitted

c) Communication Structures for Printing Documents:
Inquiry, Quotation, Sales
Order
Delivery Billing Document
Header VBDKA VBDKL VBDKR
Item VBPKA VBDPL VBDPR
INCLUDES VBDKAZ, VBDPAZ VBDKLZ, VBDPLZ VBDKRZ,
VBDPRZ

d) Pure Form Change: Change / New Field can be processed directly in SAP Form if field exists
in the Communication Structure, and/or Processing Program recognizes the field.
i) Field is available in Communication Structure
ii) Field is not already in the Form.
iii) Field can be integrated into the Form in existing Format.
e) New Fields: If field was not recognized by the Processing Program.
i) If field does not lie in communication structure, then they are included in INCLUDES.
f) Steps to add Fields to an Output:
i) If field is not in communication structure, add it by using INCLUDES
ii) If the field is not in the Processing Program, then add it.
iii) Add field to Layout.
g) New Output Type:
i) Create new Communication Structure (if required),
ii) Create new Processing Program and assign SAP Script to new Output type,
iii) Include Output type in Output Determination Procedure.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

83
6) Normal Output Types
Process Document Type Output
Quotation Quotation Confirmation AN00
Sales
Order
Order Confirmation BA00
Scheduling Agreement LP00
Delivery
Delivery Note LD00
Auto TO Creation WMTA
Shipping Order SA00
Freight List LL00
Outbound Shipping
Notification
LAVA
Packing List (Header
Level)
PL00
Shipping Label (Handling
Unit)
0001
EDI/ALE Idoc
Billing
Invoice RD00
Proforma Invoice RD01
Cash Sales Invoice RD03
Inter company Invoice RD04
Sales Activity KO00
MAIL Credit Processing KRML

7. How to determine Output Automatically in the sales order/ Delivery /

Two types of Out put determinations:-
1. Through condition technique.
2. Through customer master data i.e. while creating account group (OVT0). You find a field Out
put det procedure (sold to party / ship to party / bill to party / payer). If you select here
automatically extra tab page is incorporated in customer master data. But it has got limited
functionality, so always advisable to do through condition technique, which will provide you
more options.
Types of Output: Print Output, Fax, Telex, E-Mail & EDI (Electronic Data Interchange)
PRINT OUTPUT:
Menu Path: SPRO- IMG- SD - Basic Functions- Output Control- Output Determination- Output Det
using Cond Tech- Output Det for Sales Documents & output det for billing documents.
1. Create Condition Table: select the field Sales Doc Type from field catalog & save
2. Maintain Access Sequence: 4-digits code & description. Assign condition table to access
sequence. Select Accesses line item and Go To Fields. Fields will display the fields we have selected in
the condition table i.e. sales doc type.
3. Maintain Output Types:
AF00: Inquiry
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

84
AN00: Quotation
BA00: Order Confirmation
LD00: Delivery
RD00: Invoice
RD01: Proforma Invoice
RD03: Cash sales invoice
RD04: Inter company invoice.
Select BA00 & Copy & Rename. Give the same 4-digit code as given to acc seq.
You Can Maintain:
o Languages of Output
o Partners (to whom we want to send output)
o Print Program- print specification
o Sap Script- layout
4. Assign Output Types to Partner Functions: go to new entries & assign your output type to
partner functions.
5. Maintain Output Determination Procedure: V10000 (Standard Procedure). Go to new entries
& create your own 6-digit code with descp. Select the procedure & go to Control Data. Here
mention the output type i.e. cond type & leave requirement and manual only columns as blank.
6. Determination Rule: link the 6-digit procedure code to doc types.
7. Create Condition Records: VV11. Select document type and click on Communication. Mention
partner function, medium, time. Output device: LP01, Spool request Name: SD_003, Suffix 2:
order_confir & flag on print immediately.
Once you press enter you will come across 2 key combinations:
Sales organisation/ Customer Number: fill SO, Customer No, Partner Function
Abbreviation, Partner to whom the output should be sent, time, medium, language. {It
contains: Sales Orgn, Customer, Partner Function (The abbreviated form of the name
that identifies the Partner) (During output determination, the system determines the
recipient of the output from the master record for the specified partner function. In this
field, you can explicitly specify a recipient that will override the standard partner. There
must also be a master record for the partner that is specified explicitly.), Medium, Time &
Language.}
Order Type: Document Type, Partner Function (abbreviation), Partner, Medium, Time &
Language.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

85

16. MATERIAL DETERMINATION
Material Determination uses cond tech to swap one material for another in a sales order, when certain
conditions apply. Substituting one product with another product is called material determination. The
product is only substituted during the specific period.
Material determination, certain configuration options are available. You may configure he system to
automatically.
To swap the one material for another (for example obsolete products)
To swap one material for a number of other materials, the one material being determined based
on which one is available.
To swap the material for a number of materials, where the user is presented with a list ot choose
from.
You can use material det if you want the system to automatically substitute, for e.g.:
Customer specific product numbers with your own material numbers.
International article numbers (EANs) with your own material numbers.
Substituting discontinued materials with newer materials
Seasonal products.
MENU PATH: SPRO- IMG- SD- Basic Functions- Material Determination-
Maintain prerequisites for material determination
Assign procedure to sales doc types: determination rule
Define substitute reasons: OVRQ
1. Create Condition Table: select Material Entered from field catalogs & save
2. Maintain Access Sequence: go to new entries, give 4-digit code with descp. Select the 4-digit code
and go to Accesses and fill access no, table, descp, requirement (blank). Select the line and go to
Fields and save.
3.Maintain Condition Type: go to new entries, give the same 4-digit code as given to acc seq. Assign
acc seq to cond type and mention valid from and valid to date.
4. Maintain Procedure: go to new entries, define 6-digit code with descp. Select the 6-digit code and
go to control data and assign cond type to the procedure.
5. Assign Procedure to Doc Type: assign sales doc type to the 6-digit procedure.
6. Define Substitution Reasons: go to new entries, define 4-digit code with descp. In substitution
reasons you will also find entry, warning, strategy & outcome.
Entry: check this field if you want the original material and not substitutes to be printed in the
output.
Warning: check this field & a warning message is displayed before material is substituted
Substitution Strategy: controls whether product selection should occur automatically in the
background or whether the alternative materials should be offered for selection in a dialog box.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

86
Outcome of substitution: controls whether the outcome of product selection should replace
the original entry or whether it should be recorded as a sub item of the original entry
7. Condition Records: VB11, enter original material, substitute material, substitution reason & validity.
For multiple items select product & click on Alternative Materials Button.
o Leave the warning & strategy indicators blank, or you will not be able to perform
automatic product selection based on ATP.
o In outcome of Substitution, you must choose either A or B. Do not leave this field blank.
One of the most important decisions that you have to make about the product selection
process is whether or not substitutions determined in the order are to be redetermined in
the delivery.
Outcome A Outcome B
Create as sub items Yes Yes
New Product Selection in Delivery Yes No
Outcome A:
Product substitution redetermined when copying them from sales order to del.
Rush order not supported
Main items & sub items must be carried through from the sales docs, to the delivery, to the
billing doc.
If you use listing & exclusion in the sales doc process, the system does not take them in to
account while redetermining substitutions in the delivery.
Outcome B:
The system does not redetermine product substitution when copying them from sales docs to
the deliveries. All items are copied directly.
Rush orders fully supported
Main items & sub items do not have to be carried through from the sales doc, to the delivery, to
the billing document
If listings & exclusions are used in the sales doc process, the changes made as a result
influence the delivery documents. For e.g. refer book 1 page: 118.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

87

17. MATERIAL LISTING & EXCLUSION
Material Listing & Exclusion lets you control which materials specific customer may or may not buy.
Exclusion is given preference over listing.
The system will check the listing or exclusion for the sold to party first and if it finds, then no
other check takes place, other wise it checks for payers listing & exclusion.
SPRO- IMG- SD- Basic Functions- Material Listing/Exclusion
1. Maintain Condition Table: select Customer & Material from the field catalog
2. Maintain Access Sequence: go to new entries, give 4-digit code. Select the 4-digit code and go to
accesses and assign cond table to access sequence. Select access line item and go to fields and save.
3. Maintain Listing/Exclusion Condition Types:
Copy A001: for Listing, rename with descp
Copy B001: for Exclusion, rename with descp
Assign access sequence to the condition type. Also mention valid from & to dates.
4. Procedure for maintaining Listing/Exclusion: go to new entry. Give 6-digit code and descp.
Select the 6-digit code and go to control data and assign cond type.
5. Activate Listing/Exclusion by sales document type: Det Rule
6. Maintain Condition Records: VB01. Maintain Customer, From, To, Material(s).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

88

18. PRODUCT PROPOSAL / ITEM PROPOSAL: VA51
Item proposal is the same as product proposal and often SAP uses the two terms. You wil not find a
document type called item proposal. You will have document type product proposal. Dont worry about
confusing the two.
Frequently occurring material combinations & common delivery quantities can be stored as item
proposals. Item proposals are stored independently of customer.
Menu path: Easy Access Logistics SD Master data Products Item proposal create / change
/ display.
Go To T.Code. VA51, enter Doc Type: MS. Then enter Sales Area, and then you will enter a screen
when you can fill in frequently purchased materials and quantities. The system saves & assigns an item
proposal no.
Then Create order i.e. VA01. From the tool bar select Proposed Item Icon or from the main menu bar
go to EnvironmentListItem Proposal. The system will ask for Item Proposal No/ Default with
Quantity/ Default without Quantity & Selection List (from this list you can select with ever product you
want either with or without quantity). Then delivery, picking, goods issue & invoice.
Item proposals are stored independently of customer.
Document category D controls how the document behaves in the system. You find this in
VOV8- sales doc type details of MS.
Item proposal is merely a planning tool and is not valid fro deliveries or invoicing.
You can specify an item proposal no in CMD, in Sales Area DataSales Tab Page.
Item Proposals are sales area specific.
You can define the no intervals of the no range for item proposal
Remember that the product proposal uses item no range 11 for internal and 12 for external.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

89

19. BILL OF MATERIALS (BOM): CS01, 02, 03
A Bill of Material (BOM) describes the different components that together create a product. The sub
items of BOM along with header level item make up the BOM.
MENU PATH: Easy Access- Logistics- SD- Master Data- BOM- Create, Change, Display.
Processing at Main Item Level: ERLA: in Item Cat Group Field in the Sales Orgn 2 of MMR. The
system carries out pricing, inventory control & delivery processing at main item level. Sub item will be
ignored.
Processing at Sub Item Level: LUMF: Sub items are responsible for pricing, inventory control &
delivery processing.
Delivery Group: the sub items of a BOM may be available at different times due to the lead times in
Procurement (MM) & Production (PP). Thus if a delivery group is assigned to the item category of sub
items. The latest delivery date among all the components becomes the delivery date for the entire
delivery group, which means that all the sub items are delivered together. A delivery group can be
viewed in sales order in Shipping tab page.
CS01 and Press Enter:
Material: think center
Plant:
BOM Usage: 5 (usage 5 indicates the BOM is relevant for S & D documents)
Press Enter and You can fill in the sub items, which make the BOM.
ERLA: Item Category of Main Item is TAQ; Item Category of Sub Item is TAE
LUMF: Item Category of Main Item is TAP; Item Category of Sub Item is TAN
TAQ TAE TAP TAN
Relevant for Billing Yes No No Yes
Relevant for Pricing Yes No No Yes
NOTE:- SAP supports to create maximum 7 sub components for main item. It is possible to increase by
ABAPer as per the clients requirement.
BOM Tables

STKO -- BOM - header
STPO --- BOM - item
STAS --- BOMs - Item Selection
STPN ---BOMs - follow-up control
STPU --- BOM - sub-item
STZU --- Permanent BOM data
PLMZ ---- Allocation of BOM - items to operations
MAST --- Material to BOM link
KDST --- Sales order to BOM
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

90

A computer consists of several components. In turn, each of these components is constructed
from several individual parts.
You can store this structure in the system as a bill of material. All the items in the bill of material
(BOM) that you want to control in the sales document must be flagged as relevant for sales.
(Please note: the items in a bill of material are controlled differently than the item categories in a
sales document). If you create a BOM material with BOM usage 5 (SD), all the items in the bill of
material will be automatically flagged as relevant to sales.
By making the appropriate settings in Customizing for the item categories in the sales
document, you can copy the components in the bill of material to a sales order. To process the
sales document you only need to enter the material number of the BOM.
The BOM appears in the sales document as a structure with main and sub-items. The system
explodes the BOMs in the sales order by automatically generating sub-items for the components.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

91

The individual item categories control what a bill of material can do in a sales document. In
Customizing you define and assign item categories for the main and sub-items in the BOM in the
sales document.
A specific item category group assigned to the material master record of the main item defines
which item categories are assigned to the main item.
To determine how far the BOM should be exploded in the sales document, you need to define
the extent of the structure of the item category for the main item.
When you determine the sub-items, the system also needs to know the item category of the
higher-level item.
In Customizing for item categories, you control which item are relevant to pricing and how
you want to implement requirements transfer.

---------------------------------------------------------------------------------------------------------------------

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

92

20. CONSIGNMENT STOCK PROCESSING
Consignment refers to those goods which are stored at the customers location but are owned by the
business.
The consignment quantity is monitored and controlled separately from the rest of the stock.
The customer pays only for those goods used or consumed from the consignment stock.
The customer can usually return consignment goods which are not required.
There are four main transactions for processing consignment stock -
Consignment Fill-Up
Consignment Issue
Consignment Returns
Consignment Pick-Up
Note: Use T. Code: MB58 to know consignment at particular customer.
Since consignment stocks still form part of your valued stock, you must manage this stock in your
system, as special stock, separately from the rest of the stock and manage separately for each
customer, to keep track of returnable packaging stock by customer.
If the consignment stocks are not managed by the sold to party but by a central office, you can use the
partner function for special stock partner.
If you want to process your consignment goods using a special stock partner SB, proceed as follows:
Create a CMD for special stock partner using the same account group as if you were creating a
sold to party. (Account groups 0001 & DEBI are defined for this purpose).
Enter the special stock partner in the relevant CMD on the partner screen using the partner
function SB.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

93

Process Flow:
Doc
Type
Item Category Sch Line Category
Move
Type
Consignment
Fill Up
CF KBN Not relevant for
Billing & Pricing
E1 /E0 MRP & Availability check 631
Consignment
Issue
CI KEN Relevant for
Billing & Pricing
C1/C0 MRP & Availability check 633
Consignment
Return
CONR KRN Relevant for del
related billing &
pricing
D0 No MRP & No Availability
check
634
Consignment
Pick Up
CP KAN Not relevant for
Billing & Pricing
F1/F0 MRP & Availability check 632

Goods are delivered to customers premises, but are property of the Company till they are actually
used by the Customer. Invoice is created only when Customer withdraws goods from Consignment
stock.

a) Consignment Stocks remains as valuated Special stock of the Delivering Plant.
b) But maintained and displayed customer-wise for that Plant. It is not added to total Plant stock.
c) Special Stock Partner (assigned to Customer Master / Partner Functions / SB of the
Customer) has been defined for carrying out consignment stock processing by means of a third
party rather than the customer. Consignment goods, which have been entered in a consignment
fill-up, are always posted to the stock of the special stock partner when goods issue is carried
out.
Consignment Fill up: When consignment stock is shipped to the customer, the transaction is
referred to as consignment fill-up.
In consignment fill-up, goods are delivered to the customer but they remain the property of the
business.
The transaction is not relevant for pricing and billing. Hence no invoice is generated.
Companys
Plant
(Unrestricted
Stock)
Consignment
Stock
(Special Stock)
Customers
Stock
Consign Fill-up
Order (CF)
Delivery
Picking
PGI (631)
KBN / E0
Consign Issue
Order (CI)
Delivery (LF)
PGI (633)
Billing (F2)
KEN / C0
Consign Pick-up
Order (CP)
Delivery
PGR (632)
KAN / F1
Consign Returns
Order(CONR)
Delivery
PGR
Billing (G2)
634, KRN/D0

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

94
Goods issue of appropriate stock is posted from the unrestricted use stock to consignment
stock.
The total valuated stock for the plant remains the same.
Consignment fill-up is represented by the order document type CF.
Standard delivery type LF is used.
The standard item category used by consignment fill-up KBN is not relevant for pricing and
billing.
VA01, VL01N, LT03, VL02N & No Invoice (no billing doc type used , since stocks are
companys valuated stock)

Order Type:

Schedule Line Category

Consignment Fill-up

Customer

Business

Consignment
Fill-up
KB

Outbound
Delivery LF
Post
Goods Issue
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

95
The consignment fill-up uses the schedule line category E0 or E1.
Schedule line category E1 is used with MRP and uses availability checking.
Availability check is carried against the stock in the delivering plant.
Movement Type-631 enables the posting of the goods into a special consignment category in
the delivering plants stock for that particular customer and material.

Order Processing:
The transaction wherein the business delivers stock to a customer on consignment is recorded
using order type CF.

Delivery Processing:
The consignment fill-up order type is then followed by a standard delivery LF.
The document is relevant for Picking and PGI as it ensures the creation of consignment special
stock for the customer.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

96

Stock Overview:
When the goods issue is posted
A special stock is created for the customer.
The order quantity is moved from unrestricted use stocks in the plant and added to the special
stock for the customer.
The goods remain in the possession of the customer.
The total valuated stock for the plant remains the same.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

97
Consignment Issue: enables the customer to take consignment goods from the special stock for their
use or to sell. You record the transaction in your system by creating consignment issue order. As a
result, the relevant quantity is deducted from both the customers special stock & your own total
valuated stock. The transaction is relevant for billing since the goods now become the property of the
customer. KEN has schedule lines & should determine the cost of the item.
The customer or the consignee may use the stock at his site and indicates the business of the
same.
The consignment stock that is used now becomes the property of the customer.
The customer pays only for those quantities of goods consumed by him.
VA01, VL01N, VF01.

Order Type:
The consignment issue uses standard sales order document type CI.
It is followed by standard delivery type LF.
A delivery related billing type F2 is defined for this order type.

Consignment Issue

Customer

Consignment
Issue
KE

Outbound
Delivery LF
Post
Goods Issue

Billing
F2
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

98

Item Category:

Schedule Line Category:
The consignment issue uses the standard schedule line categories - C0 and C1.
Schedule line C1 performs MRP and availability check.
The goods movement type-633 checks for the available consignment stock at the customers
place.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

99

Order Processing
The business issues the sale, for the quantity consumed, to the customer thru the order type
Consignment Issue, CI.

Delivery Processing
The consignment issue order type is followed by a standard delivery LF.
The document is not relevant for Picking as the goods being dealt are from the special stock
already marked for the customer.
The goods issue triggers the transfers of goods ownership from the business to the
consignment consumer.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

100
Stock Overview
When the goods issue is posted
The order quantity is deducted from both the customers special stock and the business own
total valuated stock.
The goods become the property of the customer.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

101
Consignment Return: is a sales process flow that represents faulty materials or the product consumed
or sold by the consignee. The consignee puts the stock back in to his consignment stock as faulty &
requests a credit note for returns. The return should have a different no range for the visibility of
returned items. The return doc type should also promote a special shipping condition that causes a
special shipping point to be used in shipping point determination, which can be used to process all
return deliveries.
The stock is moved back into the customers consignment stock, not our plant. The customer
will call us to pick up.
The transaction is not relevant for billing as the returned stock was regarded as part of business
inventory.
The customer may then request for a credit note for returns.
VA01, VL01N, Credit Memo or Free of Charge Subsequent Delivery.

Order Type:
The sales order document type CONR is used for consignment returns.
The order is assigned returns delivery document type LR.
The order is relevant for order related billing type-RE.
Billing block is proposed to check if the credit is authorized and valid.

Consignment Returns

Customer

Consignment
Returns
KR

Returns
Delivery LR
Post
Goods Returns

Credit
for
Returns
G2

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

102

Item Category
Consignment returns uses item category - KRN.
Special stock indicator W is maintained indicating consignment process.
The item is relevant for pricing and order relevant billing based on the order quantity.

Schedule Line Category
The standard schedule line category used for consignment returns is D0.
The schedule line used standard movement type 634.
No transfer of requirements and availability check are carried out as the goods are being
received back to the consignment stock at the customers site.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

103

Order Processing
The faulty materials returned back by the customer is represented by the sales order document
type- CONR.

The returns are recorded in the standard returns delivery document type LR.
PGR causes the stock to move back into the customers consignment stock.
The ownership of the goods is passed from the customer back to the business.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

104

Stock Overview
When goods receipt is posted, the returns quantity is added to the customers special stock at
the plant where the goods are returned.
Thus the customers consignment stock will increase by the returns quantity.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

105

Consignment Pick Up:
Order Type
Consignment pick-up is represented by the order document type CP.
Standard returns delivery type LR is configured.
The transaction is not relevant for billing. Hence no values are maintained for delivery and
order-related billing types.

Item Category
Consignment Pick up uses the standard item category KAN.
The item is not relevant for billing and pricing as the stock is coming back into the warehouse
and hence there is no change of the ownership.

The consignment pick-up uses the standard schedule line categories F0 and F1.
The schedule line category F1 is relevant for transfer of requirements and availability check.
Availability check is carried against the stock on the customers consignment.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

106
It has standard movement type - 632.

Order Processing
All the excess material lying unconsumed and any faulty material at the customers site are
brought back to the business using the order document type CP.

Delivery is carried out using the standard returns document type-LR.
Goods receipt posts the stock back to the business warehouse.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

107

Stock Overview:
With the PGR the quantity gets deducted from the customers special stock and is added back
into the regular stock at the plant where the goods are returned.
The total valuated stock remains the same since the returned stock was regarded as part of the
business own inventory even while it was at the customers premises.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

108
Consignment Pick Up: picking of faulty materials as well as excess materials not yet consumed by the
customer. As the stock is coming back into the warehouse or plant, you will want a specific return
shipping point. No invoice is necessary, as the goods are not changing ownership.
The transaction is not relevant for billing as the returned stock is regarded as part of business
inventory.
VA01, VL01N, VL02N, VL09.

Consignment Pick-up

Business

Customer

Consignment
Pick-up
KA

Returns
Delivery LR
Post
Goods Returns
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

109

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

110

21. THIRD PARTY ORDER PROCESSING

In third-party order processing, the business passes the order from the customer, to a third-party
vendor who then ships the goods directly to the customer and bills the business.
When a third party order is saved, purchase requisition is automatically created and forwarded
to the purchase department.
The purchase department then creates the purchase order on the third-party vendor indicating
that all goods are to be delivered directly to the customer.
The vendor delivers the goods to the customer and bills the business for the same.
The business then bills the customer for the goods delivered by the vendor after verifying the
invoice receipt.
The purchase order of the customer is first entered in a sales organization of your company as a
sales order (application SD). A purchase requisition is automatically created from the order.
Afterwards, a purchase order for the external vendor is created in the MM purchasing
application. This order states that all goods are to be delivered directly to the customer.
As soon as the vendor confirms to you that the outbound delivery is complete, you post a goods
receipt so that this information is recorded in the system.
In the application MM Invoice Verification, you enter the invoice issued by the vendor to your
company for the goods delivered by the vendor to the customer.
Finally, you generate the SD billing activities to your customer.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

111

Third party order:
The processing of third-party orders is controlled via material types which define whether a material is
produced only internally, can be ordered only from third-party vendors, or whether both are possible.
If a material is always delivered from one or more third-party vendors, material is maintained as
third-party item. BANS is entered in the Item category group field in the Sales 2 screen of the
material master record. System determines the item category as TAS while processing the
material in the order.

In the case of a material that business delivers itself but occasionally orders from a third-party
vendor, the item category of the material is manually changed from TAN to TAS during sales
order processing.

Item Category
The item Category TAS is relevant for order related billing, quantity as per the goods receipt.
The item is also relevant for pricing.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

112

The system determines the standard third party schedule line CS.
The schedule line is not relevant for any goods movement type as the physical goods issue
does not take place from the business.
The standard purchase requisition-NB, Third party item category 5 and third party account
assignment Category 1are configured to enable the system to automatically create a purchase
requisition for the schedule line.

Third Party Order Sales
Third-party items are processed by creating a normal sales order.
The system uses TAS as the standard third party item category.
A sales order may consist partly or wholly of third-party items.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

113

Purchase Requisition
Purchase requisition is automatically created in purchasing once the sales order is saved.
Each third-party item in a sales order automatically generates a corresponding purchase
requisition item.
If a third-party order item has more than one schedule line, the system creates a purchase
requisition item for each schedule line.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

114
Purchase Order
Purchase order is created with reference to the purchase requisition.
The system automatically adopts the delivery address of the recipient from the sales order.
Third-party order items in purchase orders are marked with item category S.
Any quantity and date changes made in the purchase order are automatically copied into the
sales order.

Billing
Once the goods have been delivered to the customer by the vendor, the business then bills the
customer.
No delivery exists in the system for third-party order items.
The system is set for order related billing during selection of the documents to be billed.

In Third-party order processing, your company does not deliver the items requested by a customer.
Instead, you pass the order along to a third party vendor who then ships the goods directly to the
customer & bills to you. If the vendor delivers it to us, so that we can deliver to the customer, you can
use Individual Purchase Order Processing.
Automatic Third-Party Order Processing: to specify an item as a third party item, enter BANS in the
item cat group field of the Sales 2 Screen of MMR. During subsequent sales order processing, the
system automatically determines the appropriate item category for a third party item: TAS. Create the
material using Material Type: Trading Goods.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

115
NB: Third party purchase order type. F1: Order related Billing.
Process Flow for 3rd Party Sales
Customize the third party sales in summary:
1. Create Vendor XK01
2. Create Material Material Type as "Trading Goods". Item category group as "BANS".
3. Assign Item Category TAS to Order type that you are going to use.
4. A sale order is created and when saved a PR is generated at the background
5. With reference to SO a PO is created (ME21N). The company raises PO to the vendor.
6. Vendor delivers the goods and raises bill to company. MM receives the invoice MIRO
7. Goods receipt MIGO
8. Goods issue
9. The item cat TAS or Schedule line cat CS is not relevant for delivery which is evident from
the config and, therefore, there is no delivery process attached in the whole process of Third
party sales.
10. Billing

Sales order Create Sales Order
VA01
Order Type
Sales org, distr chnl, div
Enter
Sold to
PO #
Material
Quantity
Enter
Save
View the PR that is created with a third party sales order
VA01
Order Number
Goto Item Overview
Item ->Schedule Item
View the PR that is created
ME52N
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

116
Key in the PR number
Save
Assign the PR to the vendor and create PO
ME57
Key in the PR number
Toggle the "Assigned Purchase Requisition"
Execute
Check the box next to the material
Assign Automatically button
Click on "Assignments" button
Click on "Process assignment"
The "Process Assignment Create PO" box , enter
Drag the PR and drop in the shopping basket
Save
Receive Goods
MIGO_GR
PO Number
DN Number
Batch tab , click on classification
Serial Numbers tab
Date of Production
Flag Item OK
Check, just in case
Post
Save
Create Invoice
MIRO
Invoice Date
Look for the PO , state the vendor and the Material
Check the box
Clilck on "Copy"
Purchase Order Number (bottom half of the screen)
Amount
State the baseline date
Simulate & Post
Invoice Number
*Invoice blocked due to date variance
Create a delivery order
VL01N
In the order screen , go to the menu Sales Document , select "Deliver"
Go to "picking" tab
State the qty and save
Create a billing document
VF01
Ensure that the delivery document is correct in the
Enter
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

117
Go to edit -> Log
Save

1. Create Sales Order: VA01. You process third party items by creating a normal sales order. Select
the line item & Go to Schedule Lines. You will find 2 dates- Date Requested & Date Available. In
schedule line you will find Sales/Shipping/Procurement. Select Date Available and Go to Procurement.
When you save a sales order that contains one or more third party items, the system
automatically creates a purchase requisition in purchasing.
2.Create Purchase Order: ME58: On the left hand side you will find Open Purchase Requisition, Drag
it on to the right side and save the purchase order.
3. Goods Receipt: MIGO: Give the purchase order no and save. It is a logical goods receipt. Stock will
not come to our plant.
4. Invoice Verification: MIRO: give P.O. No & Tax amount at the rate of 16%
5. Invoice: VF01.
You can only change the address data for the ship to party in the Sales Order for third
party business transactions & not in the purchase order.
All changes made in the Purchase Order are automatically made in the sales order as
well. But vice versa is not, except for the address of the ship to party.
Item Category Group: BANS
Item Category: TAS
While creating a third party item, in the Purchasing View fill the Purchase Group
Item Category for Individual Purchase Orders: TAB.
Doc Used: OR/RO.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

118

22. SALES INCOMPLETION LOG / INCOMPLETION LOG

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

119

Status Groups:
Status Group is a grouping of different kinds of status. A group can consist of any combination of
general, delivery, billing, and pricing status.

Using status groups, you can determine which status messages appear when you process different
documents. The status group also provides the link, during sales order processing, between the
incompletion log (where the system prompts you to enter data in required fields) and the header and
item status screens in the sales document.

The fields that appear in the incompletion log are defined for each sales document by an incompletion
procedure, where you assign a status group to each field

Then, during sales order processing, if you omit to fill a required field, the system

o prompts you for the relevant information in the incompletion log

o records the status messages in the sales document, according the assigned status group

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

120

An incompletion proc inspects the object, such as a sales doc line item & inspects specific fields in
order to see if data has been maintained in these fields. Should data not be maintained in these specific
fields, the system is told how to respond, i.e., does it or does it not give a warning message & to what
extent does it allow further processing of the doc?
The incompletion log cannot register what data is maintained in the specific field & compare it to the
data that should be in the specific field.
One can create incompletion logs for the following:
Sales Doc Header Data: VBAK
Sales Doc Item Data: VBAP
Sales Doc Schedule Line Data: VBEP
Business Data: VBKD
Customer Data: KNA1 (general data: CMD)
Sales Area Data: KNVV
Delivery Header Data: LIKP
Delivery Item Data: LIPS

Incompletion Procedure Configuration: The following steps are involved in configuring
Incompletion procedure.

SPRO- IMG- SD- Basic Functions- Log of Incomplete Items:
Define Status Group: OVA0
Define Incompletion Procedures: OVA2
Assign Incompletion Procedures: VUA2

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

121
Define Incompletion Procedure:

In the next step in incompletion procedure definition, we assign the fields to the procedure which should
be checked for incompleteness as also if any warning message is to be issued if there are no data in
the fields.

Assign Incompletion Procedures:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

122

Define Status Groups:
In the status group we define which functions may be carried out by an incomplete sales and
distribution document or items

Define Status Groups:
First, one needs to define the status groups. This status groups are eventually assigned to the specific
field in the incompletion log. Thus, it is possible to specify in a sales doc that field A may be incomplete,
but not hinder the doc from being processed further, while field B may be incomplete and be the cause
of the same doc being blocked for further processing. The status groups will be assigned to field status
in define incompletion proc.
The statuses group settings are:
Status
Group
General Delivery Billing Doc Price Goods Movement Picking Packing

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

123
Define Incompletion Procedure: OVA2
By selecting Group A: Sales Header, Select Procedures, (& then click on display button), you can see
incompletion procedures. Then select incompletion group line item & go to fields
Procedures
Fields
Incompletion Group
Group Description
A Sales header
B Sales item
C Sales schedule line
D Partner
F Sales activity
G Delivery header
H Delivery item.

Error Group A
In Proc Description
10 Inquiry / quotation
11 Sales header
12 Outline agreements

Note that incompletion proc are assigned to various sales doc types & sales doc item categories
It is not possible to create your own error group such as a copy of Group A: sales header
You can create a copy of the assigned procedures to the error, such as a copy of the standard
procedure: 11- sales order.
To create your own incompletion proc, select the change display button. Then go to new entries.

One can see the table names with assigned field name & description of that field.
Table Name Field Name Descp Screen Status Warning
VBKD BSTKD P.O. No KDES 02 Flag on the Box

The assigned screen KBES is the screen that the system takes the user through in order to complete
the missing data. Assigned to the P.O. No is an indicator saying the system must display a warning
message in the sales order at the time that the system checks to see if the data is maintained for the
purpose of incompletion log. Should no warning indicator, be assigned the system will merely indicate
the sales doc is incomplete & offer an option.

Assign Incompletion Procedure to Sales Doc Types: VUA2
One can assign the procedure to each object that resembles an incompletion error group, such as
Group A: sales header. You can assign the proc for e.g. IL to OR (sales doc type)
Sales Doc Type Procedure Incompletion Message
OR IL Flag It on
Should one not require the pop up box, but merely allow the doc to be automatically saved, even
though it will still be blocked for further processing, if incomplete. One can select the indicator
incompletion message. If you mark this field & then try to save a sales doc in which info is missing,
the system advises you that the doc is incomplete.
For certain types of documents like rush orders, complaints; you can leave this field blank.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

124

23. SHIPPING

Functions supported by the R/3 System in shipping processing include:
Monitoring of deadlines for reference documents due for shipping (for example, customer
orders and purchase orders)
Creating and processing outbound deliveries
Monitoring goods availability
Monitoring capacity situation in the warehouse
Support for picking (with link to the Warehouse Management System)
Packing the delivery
Printing and transmitting shipping documents
Processing goods issue
Controlling through overviews of: - deliveries currently in process
- Activities still to be performed
- Possible bottlenecks
The deliveries in the shipping department that have already been posted for goods issue can
provide the basis for creating a work list for billing.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

125

A shipping point is an independent organizational unit at a fixed location that processes and
monitors outbound deliveries as well as goods issue. The shipping point is directly under the client
level.
An outbound delivery is processed from a single shipping point.
The responsible shipping point is determined in the order at item level.
A shipping point can process the outbound deliveries of several plants. This is only useful if the
plants are located in the same general vicinity.
Several shipping points can be assigned to one plant. They may, however, have different
loading equipment or different processing times.
The allowed combinations of shipping point and plant are defined in the Customizing application
of the enterprise structure.

SHIPPING POINT DETERMINATION:
Shipping Points are independent organizational units that are linked to plant & represent the point
of departure or receipt of materials.
A plant may have many shipping points.
Each & every outbound delivery will be processed from one shipping point only.
You cannot change shipping point in delivery
Shipping points are subdivided into loading points.
Shipping point is assigned to a plant.
One shipping point is assigned to multiple plants, provided they are in the same geographical
area.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

126
Menu Path: SPRO- IMG- Logistics Execution- Shipping- Basic Shipping Functions- Shipping
Point Determination.
Define shipping conditions
Define shipping conditions by sales doc type
Define loading groups
Assign shipping points
Assign goods receiving hours for inbound deliveries
The shipping point is the central key to a delivery; no delivery can be made without one. The shipping
point is determined by the system based on:
Shipping Conditions :(2 digits code) entered manually in the sales order or copied from the
CMD (shipping screen) or they can be defaulted to a particular sales doc type. Should they be
defaulted to a particular sales doc type, the system will ignore the settings on the CMD (this is
useful in returns).
Loading Group: (4 digits code) which is copied from MMR. As a del is not possible with a
loading group it is advisable to make this field as mandatory field.
Delivering Plant: of the line item (which is copied from Cust Mat Info Record, CMD, MMR) in
the sales order.
Shipping Conditions + Loading Group + Delivering Plant Shipping Point
To define shipping point: SPRO- IMG- Ent Stru- Defn- Logistics Execution- Define, copy, delete,
check Shipping Point.
To assign shipping point to plant: SPRO- IMG- Ent Stru- Assignment- Logistics Execution-
Assign Shipping Point to Plant.

A shipping point is determined for each order item. The system automatically proposes a
shipping point that you can change within given limits.
The shipping point depends on the following criteria:
The delivering plant that is determined for each order item (from the customer-material info
record, the ship-to party record, or the material master record)
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

127
The shipping requirements (for example, express) contained in the Shipping Conditions field
The required loading equipment contained in the Loading Group field in the material master
The shipping condition is proposed from the sales document type if a shipping condition has
been assigned to it. If not, the shipping condition is proposed from the master record of the sold-to party.
An outbound delivery is always processed by one shipping point. You cannot change the
shipping point in the outbound delivery.
When an order is processed for delivery by the shipping point, the system only copies into the
outbound delivery those order items that are defined for this shipping point. Order items with
different shipping points are therefore not copied into the same outbound delivery.
STORAGE LOCATION DETERMINATION:- (BY MM):
Shipping point + Delivering plant + Storage condition = Storage location.

In order to achieve efficient processing for goods receipt and goods issue, you can use the
following organizational units:
Warehouse number: The entire warehouse structure is managed under one warehouse
number. This number represents the warehouse complex.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

128
Storage type: The different warehouse areas, which differ with respect to their organizational
and technical features, are defined as storage types (for example, high-rack warehouse with
random storage, picking warehouse with fixed bins, shipping area).
Picking area: The picking area groups storage bins together in the storage type from the
picking Viewpoint. It is the opposite of the storage section, which groups storage bins together from
the put away viewpoint. For example, a delivery can be split up into different picking areas to make
parallel picking possible.
Staging area: The staging area is an area in the warehouse where the goods are stored
immediately after unloading or shortly before loading.
Door: A door within a warehouse can be used both for inbound delivery as well as outbound
delivery of goods.
The door and the staging area are already defined in the outbound delivery header. They can be
determined automatically, that is, depending on the customer.

The linkup of the organizational units in the warehouse to MM Inventory Management takes
place through the assignment of the warehouse number to a combination of plant and storage
location.
Several storage locations within a plant can point to the same warehouse number. They thus
form the warehouse complex from the different viewpoints of inventory management.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

129

OUT BOUND DELIVERY IN SHIPPIG (VL01N)

A delivery document consists of a header and a number of items.
The header contains data that applies to the whole document. This means that the ship-to party,
shipping point, route, and so on, is clearly displayed for each outbound delivery.
The items primarily contain information about the material to be delivered.
The information in the delivery document is displayed in different screens:
The overview screen displays selected header and item data, which is grouped according to
activity on tabstrips. This means that you find the important data all on one screen.
At both header and item level, you can access another screen to display detailed information.
Again, the information is grouped into processes on tab strips. At header level, this information
includes data on processing, picking, loading, and shipment, foreign trade/customs, texts, partners,
output, package monitoring, and conditions. At item level, the detailed screen displays similar tab
strips with information about the items.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

130

The delivery type controls the entire delivery. You see the delivery type in the delivery header.
The delivery types take into account the various business transactions in delivery processing.

TYPES OF DELIVERY DOCUMENTS defined in the standard system: 0VLK

LB: Delivery for subcontract order
LD: Decentralized shipping (used in decentralized shipping in connection with R/2 RV)
LF: Outbound delivery
LO: Delivery without reference (no sales order necessary in order to create a delivery)
LP: Delivery from project
LR: Returns delivery
NL: Replenishment delivery
RL: Returns vendor
BV: Cash sales.

Using control elements, you can configure each delivery type to carry out different functions.
You can adjust the delivery types in the standard system to meet your business requirements.
However, if major adjustments are required; we recommend that you create a new delivery type.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

131

The delivery item category controls how delivery items are handled and processed during the
shipping process. The control elements available provide a high degree of automatic determination
and checking.
You can also configure the item categories to meet the specific requirements of your system
installation.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

132

When you copy an order item to a delivery, the system copies the item category of the order
item to the delivery item.
If an order item category or the schedule line assigned to it is relevant for delivery; the same
item category is defined for the delivery process.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

133

The system cannot copy item categories for order-independent items in the delivery (for
example, packing material) or for deliveries without reference to an order (delivery type LO).
In this case, the system determines an item category for the delivery according to the
assignments specified in Customizing. For determining the item category, the system takes into
account the delivery type as well as the item category group (from the material master of the item).
Additional usages are set internally for some functions, such as:
PACK for generating packing items
CHSP for a batch split
PSEL for product selection
For the delivery items resulting from these functions, the system can determine a different item
category.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

134

In the copying control table you specify:
Which sales and distribution document types can be copied to which delivery types
Which item categories are copied from reference documents
You can also specify:
Under what conditions data is copied from the order to the outbound delivery
Under what conditions several orders can be combined in an outbound delivery
Which data is to be transferred
Whether the reference should be recorded in the document flow
Order items that are due for delivery that have the same shipping criteria are shipped together.
Required shipping criteria include the shipping point, the route, and the ship-to party.
Certain shipping criteria in the standard system are optional and can be removed as splitting
criteria from the copying control table.
You can also define additional splitting criteria that do not allow joint shipping if the defined fields
have different values.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

135

You control order types by specifying:
Which delivery type is proposed for the outbound delivery
Whether a requested delivery date is proposed in the order and how far it is in the future
Whether the outbound delivery is automatically created in the background when the order is
saved
Delivery relevance on the order item category level is valid only for text or value items. You can
set a text item as relevant for delivery, for example, so that it will be copied into the outbound
delivery from the standard order and recorded in the delivery note.
Physical deliveries using the interface to the MM Inventory Management component are only
possible if schedule lines are used. This is why in this standard case schedule lines must be
allowed for the order item category, and the schedule line category must be set as relevant for
delivery.
The goods issue movement type (or goods receipt movement type for returns deliveries) is
defined at the schedule line category level.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

136
DELIVERY SCHEDULING

During delivery and transportation scheduling, the point at which the goods arrive at the
customer can be confirmed (confirmed delivery date) Different lead times are taken into
consideration here: the pick/pack time, loading time, transportation lead time and the transit time
The following data plays a role in delivery scheduling:
Order date: Date on which the order was issued
Material availability date: Date on which sufficient goods should be available for picking and
Packing,
Loading date: Date on which picking and packing should be completed (and the mode of transport
should be there), in order that loading can begin on time
Goods issue date: the date on which the goods must leave the delivering plant, in order that they
arrive at the customer's at a specific time
Delivery date: Date at which the goods arrive at the customers. Here a difference is made
between:
Required delivery date: Date on which the customer wishes to receive his goods
Confirmed delivery date: Date on which the arrival of the goods at the customers can be
confirmed.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

137

When determining a delivery date, you can take into account the times required to deliver the
goods via a route to the customer.
The total time includes:
Transit time: time required to transport the goods to the customer
Transportation lead-time: time needed to prepare the transportation of the goods.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

138
ROUTE DETERMINATION

Route determination is carried out in the order item and depends on:
1. The country and the departure zone of the shipping point (assigned in Customizing)
2. The shipping condition defined in the sales document type or entered in the sold-to party
3. The transportation group assigned to the material
4. The country and the transportation zone of the ship-to party (assigned in the customer
master)
You can manually overwrite the route determined in the order item.
You can redetermine the route in the outbound delivery based on the weight. Whether the
route is redetermined depends on the configuration of the delivery type.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

139

When you create an order, the system can determine the required material availability date
based on the delivery date requested by the customer. The goods to be delivered must be
available for shipping at this point in time.
Scheduling takes into account the following times:
Transit time: Time required in order to ship a delivery to the ship-to party
Loading time: Time required for loading the goods
Pick/pack time: Time required for picking, packing, and so on
Transportation lead-time: Time required for organizing the transportation
Next, the system performs backward scheduling in the order. If the result is a date in the past,
the system automatically performs forward scheduling, which requires the confirmation of a new
requested delivery date. The same happens if the material is not available by the material
availability date.
When you create an outbound delivery you can carry out forward scheduling again. This is
generally done when the material availability date determined in the order falls in the past by the
time you create the outbound delivery (delay when creating the order). You can specify for each
delivery type whether scheduling should be redetermined.
For each shipping point, you decide whether the system performs precise or daily scheduling.
When you maintain the "working hours" for the shipping point, scheduling takes place according to
working hours and the results are displayed down to the minute.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

140

Delivery scheduling includes the pick/pack time and the loading time. These times depend
on the shipping point that delivers the order item.
You can specify for each sales document type if delivery scheduling is to be carried out.
For each sales document type, you can also define if only the pick/pack time (and not the loading
time) is to be considered during delivery scheduling.
You can also define for each shipping point whether the pick/pack time and/or the loading time
should be taken into account.
You can choose whether a global time specification for the pick/pack time and the loading time
is sufficient at shipping point level (default) or whether more detailed time specifications which
depend on further criteria should be used. These criteria are:
Shipping point
Weight group (for pick/pack time) or loading group (for loading time): From material master
Route (optional)
If the route is not necessary as one of the criteria for determining the pick/pack time and the
loading time, you can make an appropriate setting. In this case the route entry in the scheduling
table should be blank. It makes sense to differentiate between routes if you are using different
means of transport.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

141

The aim of shipping and transportation scheduling is for the customer to confirm a delivery date
for the material ordered.
In backward scheduling, the materials staging date and the transportation planning date are
calculated from the required customer delivery date. The outbound delivery must be created on the
earlier of the two dates (selection date of the outbound delivery)

-- If both dates are after the order date and the material is available on the materials staging date,
the required delivery date is confirmed to the customer. A schedule line is created for a sales
document item. The date of the schedule line corresponds to the confirmed delivery date, which
corresponds to the required customer delivery.

-- If one of the two dates is before the order date, three can be no confirmation of the required
delivery date. Therefore the system now tries to agree the next possible date (forward scheduling).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

142

If the result of backward scheduling means that the delivery date required by the customer
cannot be confirmed, the system updates scheduling with forward scheduling.

--- Forward scheduling takes into consideration the time parallels of the workflows for
transportation planning and retrieving and picking/packing of materials. The longer of the two
periods is relevant for scheduling. The selection date for the outbound delivery is the earlier of the
materials staging date or the transportation planning date.
---- The earliest time at which the material is available is the new material staging date. This is the
outgoing point for new delivery scheduling.
Two schedule lines are generated for the sales document item:
The date of the first schedule line corresponds to the customer's required delivery date and has no
confirmed quantity.
The date of the second schedule line shows the confirmed delivery date and the confirmed
amount.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

143

You can change or add to delivery documents after saving. However, you should ensure that
information such as ship-to parties and shipping points are not changeable once you have created
the outbound delivery.
For example, you can add items to the outbound delivery. These items can refer to other orders
(deliver order function). For adding order items, the same splitting criteria apply as for combining
orders during collective processing.
You can also add order-independent items to the outbound delivery. For this item, the system
determines an item type using the usual rules (see unit Controlling Elements of the Outbound
Delivery).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

144
BATCHES

You can specify a batch in the relevant detail screen for materials handled in batches
(whether or not a material is handled in batches is indicated in the material master record in the
"Storage 1" and "Purchasing" screens). When delivering a sales order, this batch is copied to the
outbound delivery. You cannot change it there.
If no batch has been specified in the sales order, you can enter one in the picking overview
screen of the outbound delivery. You must specify a batch, at the latest, before goods are issued.
Use the batch split function if the delivery quantities of an item are to be taken from different
batches. You can carry out batch splits as follows:
Manually in the batch split screen of the delivery item
When creating the outbound delivery using automatic batch determination (this function must
first be activated in the delivery item category)
Through manual batch determination in the batch split screen
In the Warehouse Management component
Course L0955 covers batch management in detail.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

145
SERIAL NUMBERS

You can assign a unique serial number to each material. This allows you to monitor goods
movement for individual materials, for example, when selling materials to a customer. Using
serial numbers you can also manage the maintenance of individual materials more easily in the
system. You must first create equipment master records, however, for these materials.
To use serial numbers; enter serial number profiles in the master record for the relevant
materials.
Serial numbers are usually specified in the delivery item. However, you can also define them in
the order.
You can also have the serial numbers assigned automatically by the system.
You must specify all serial numbers, at the latest, before posting goods issue.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

146
PRICING IN THE OUTBOUND DELIVERY

The outbound delivery can contain shipping-related conditions at header level, such as
shipping or freight costs (if you are not using the Transportation component).
You can enter the condition values manually or determine them using the SD pricing condition
technique. You can print the conditions on the delivery note as well as transfer them in the billing
document, but you cannot transfer them from the preceding documents to the outbound delivery.
To implement the conditions; use the standard Customizing settings for pricing (condition type
definition, maintaining the pricing procedure). Assign the pricing procedure to the delivery type.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

147

You can split existing deliveries into several smaller deliveries, which is useful if, for example,
there is not enough room in your truck to hold the entire delivery.
To do this, you can call up a list and select the delivery items, partial quantities of items, or
shipping units that are to be taken out of existing deliveries.
When you split a delivery, you create one or more new deliveries, called results, and the
remainder.
When you call the delivery split, specify a split profile to determine the type of split. The split
profiles contain control parameters, are defined in Customizing, and assigned to delivery types.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

148
PICKING IN SHIPPING (LT03)

Picking is the process of preparing goods for delivery to the customer with special attention
paid to dates, quantity, and quality.
You specify for each delivery item category whether it is relevant for picking .
Often, picking takes place using the printout of a picking list. SAP recommends that you use
the functions of the WM transfer order. For this purpose, you do not need to implement the
complete WM system; Lean WM is sufficient.
Using Lean WM means using a small part of the functionality of the R/3 component WM
(Warehouse Management).
With the help of the output control for the outbound delivery, you can also transmit data to a
subsystem that is implemented for the picking process.
In the standard configuration of the system, the prerequisite for posting goods issue is that
picking relevant items are completely picked. This means that the delivery quantity and the pick
quantity in the outbound delivery must be the same.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

149

To use WM in picking (either full WM or Lean WM), you create a transfer order (TO).
The transfer order is a document with which the goods movements within a warehouse
complex can be initiated and monitored. You create one or several transfer orders on the basis of
the items to be picked using WM.
Afterwards, you print out the transfer order. This step can be executed automatically by the
system.
Instead of printing the transfer order as a picking list, you can transfer the data of the transfer
order to an external system using portable data capture or to a warehouse control unit.
By confirming the transfer order, you verify the quantities removed from the warehouse. If you
are working with a confirmation requirement, you must perform this step separately. If there is no
confirmation requirement, the system automatically confirms the quantities when you create the
transfer order.
Finally, you can post the goods issue. This completes the shipping process.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

150

A transfer order is an instruction to move materials from a source storage bin to a destination
storage bin within a warehouse complex.
Transfer orders include the following information:
Material number
Quantity to be moved
Source and destination storage bin
When you create the transfer order, the system automatically copies the delivery quantity from
the outbound delivery to the transfer order as the picking quantity.
The picking quantity in the outbound delivery is entered automatically when you create the
transfer order. In Lean WM, the picking quantity is initially the same as the delivery quantity.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

151

If you have a warehouse with random storage, you need to use the WM System with full
Functionality. Since a material can be stored in different storage bins or even several storage bins
at the same time, precise inventory management at the level of the storage bin is required.
Lean WM does not have inventory management at the level of the storage bin and is therefore
more suitable for fixed bin warehouses. In a fixed bin storage area, the material is always in the
same storage bin.
To print the storage bin in the picking document, you must maintain the respective data in the
material master in the view "Storage 1". Maintenance of further warehouse data and the
Warehouse Management views is not required.
Some of the WM functions not included in Lean WM are listed below:
Storage sections
Reserve storage bins
Strategies for put away and picking
Replenishment
Inventory at storage-bin level, this considerably reduces implementation effort.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

152

Possible depiction of the warehouse structure of a fixed bin in the SAP System if Lean WM is
in use.
For Lean WM you need at least one warehouse number and at least one storage type from
which picking takes place and one storage type in which goods are stored (for example, picking
storage type as source storage type, shipping zone as destination storage type).
In the picking storage area, you can have storage bins grouped together from the stock removal
viewpoint (for example, to distribute the workload evenly). Picking areas can be defined for each
warehouse number and storage type.
In addition to the picking area, there are other organizational units in the warehouse. These are
the staging areas and the doors. They are defined in the outbound delivery or determined by the
system and they can also be printed out on the picking documents.
You can activate Lean WM in Customizing at the warehouse number level.
You assign a warehouse number to a combination of plant and storage type. In this way, the
organizational units in the warehouse are linked up to MM Inventory Management. Also, through
this assignment, a status for WM activities is assigned to the respective items in the outbound
delivery.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

153

There are several ways of creating a transfer order (TO). They differ only in the degree of
automation involved.
In individual cases, it is possible to create the transfer order as a follow-on function from the
delivery.
You can also create transfer orders separately. To do this, create the transfer order either with
reference to a specific outbound delivery, or use the delivery monitor to create transfer orders for
several deliveries at the same time.
The procedure "automatic/direct TO" is suitable if you want to have the transfer order created
automatically from each outbound delivery, without manual involvement or effort.
Using the collective processing procedure, you can group several outbound deliveries
together for the purpose of creating the transfer orders.
In WM, you have the following options for printing using a print code:
Single print: One page for each TO item (for example, item-by-item processing in the
warehouse)
Combined print: One list for the entire transfer order (also called "combined list")
Pick list: One list for several transfer orders that were created in collective processing

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

154

In picking, differences may occur between the quantity actually removed and the delivery
quantity. However, you can only post a goods issue if the picking quantity and delivery quantity are
the same.
One option is to copy the picking quantity as the delivery quantity and perform a partial
delivery. In the order, the status is set to partially delivered, and a new delivery is created for the
remaining items.
Alternatively, you can choose subsequent picking. In this case, you create a new transfer
order for the difference.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

155

When you create the transfer order, the system sets the delivery quantity as the picking quantity
so that the picking status is set to C (= fully picked).
If you wish to have the system record the fact that the picking procedure is complete; you can
set the confirmation requirement.
You must confirm the transfer order and therefore also the picked quantities (Pick qty field)
before the goods issue are posted.
If you have organized your warehouse so that picking causes changes to the outbound delivery
in only a limited number of cases, and the confirmation takes place on time, you can limit this step
to the deliveries to be changed and also work without the confirmation requirement.
During confirmation, it is possible to report differences in quantities. You can record the cause
for the difference in the system by entering a difference indicator.
As soon as confirmation is complete; the status of the WM activities is set to 'C', regardless of
the confirmed quantity. Only the pick quantity affects the picking status.
In Customizing, you define the confirmation requirement for each storage type. It will suffice if
you set either the "stock removal" (picking) in the source storage type or the "stock placement" (put
away) in the destination storage type as requiring confirmation.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

156

Packing is the process of assigning delivery items to shipping materials. This produces
shipping units, which can then have more shipping materials added for packing.
This creates new shipping units. You can use as many levels as required (multi-step packing).
You can also unpack items from shipping units, or you can break a shipping unit down into its
constituent parts and then delete it.
In Customizing, you specify for each delivery item category whether it is relevant for packing .
The settings are: packing allowed (default), packing not allowed, and packing mandatory.
The packing status is updated for each item in the outbound delivery (example: partially packed /
completely packed).
In the standard system, two output types are set up for printing:
packing list (at delivery level)
shipping label (at shipping unit level)
You can define your own output types.
Using the delivery item category, you can specify for items with batch split if the main item (with
the accumulated quantity of the batch split items) or the individual batch split items are to be
packed. If the individual batch split items are packed, you can identify in which shipping unit a
specific batch is contained.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

157

The packing function is available:
in orders (as packing proposals)
in the outbound delivery
in the shipment document
The packing proposal in the order can be copied to the outbound delivery. You control this at
the header level in the copy control table for deliveries.
You can make packing in the outbound delivery subject to certain conditions. To do this, you
need to make settings in Customizing (standard setting: packing cannot be carried out when the
delivery has been blocked by the credit check).
You can change packing in the outbound delivery as long as you have not posted the goods
issue.
Packing in the outbound delivery is copied to the shipment. You can then choose to pack all the
deliveries together.
Using user exits you can specify rules for automatic packing during outbound delivery creation.
The resulting proposal contains the shipping materials and the contents of each shipping unit.
Automatic packing is activated for each delivery type.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

158
GOODS ISSUE in SHIPPING (VL02N)

Posting goods issue for an outbound delivery completes shipping activities.
Posting goods issue requires that all mandatory shipping activities have been performed. For
example, if you are working with picking relevance and confirmation requirement, these steps must
first be completed.
Goods issue can be posted by changing a single outbound delivery. Alternatively, you can
use the collective processing function in order to select all deliveries for which goods issue is due
to be posted, and then post the goods issue for them. You can also use the outbound delivery
monitor to do this.
You can also post the goods issue when the transfer order is confirmed.
When you process a single outbound delivery, you can specify the actual goods issue date
without changing the planned date. A dialog box appears in which you can enter the actual goods
issue date, and then post goods issue for this date. The corresponding goods issue document is
then posted with the actual goods issue date. If no explicit specifications are made for the goods
issue date, the current date is taken as the goods issue date.
Goods issue applies to the whole outbound delivery.
Any errors are logged, for example, when data such as the batch or serial number is missing or
when picking has not been carried out fully for the items. In these cases, goods issue is not posted.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

159
EFFECTS OF GOODS ISSUE POSTING

After the goods issue has been posted; there is limited scope for changing the outbound
delivery. In particular, no changes can be made to the quantities. At this point in processing, the
delivery document has to reflect the actual physical delivery.
Goods issue
reduces warehouse stock
posts the value change to the stock accounts in inventory accounting
reduces delivery requirements
enters status information in the outbound delivery
is stored in the document flow
creates a work list for billing
To carry out billing before goods issue using the "Create billing document" transaction, you can
make the appropriate settings in copy control in Customizing.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

160

If goods issue for an outbound delivery is canceled; the goods issue posting is reset. The
system copies the quantities and values from the original goods issue document and carry out an
inventory posting based on these quantities and values with a reversed +/- sign.
If you cancel goods issue, this affects the entire outbound delivery. The cancellation document
created during cancellation is entered in the document flow for the outbound delivery.
After goods issue has been canceled, the goods movement status of the outbound delivery is
reset to "Not yet started". This allows you to further process the outbound delivery as usual. The
delivery requirements are also recreated.
Canceling goods issue comprises two steps if the outbound delivery has been fully or partially
billed. In this case you must first cancel the billing document. Then you can cancel goods issue.
For each movement type in MM Inventory Management, you must define a reversal movement
type in Customizing. No additional settings are required for the movement types used for goods
issue posting in the standard system.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

161
PROOF OF DELIVERY (POD)

Proof of delivery (POD) is essentially designed to support the process of only creating an
invoice once the customer has confirmed the arrival of the goods.
After receiving the goods, the ship-to party transfers the proof of delivery by IDoc to the R/3
System and thereby confirms the quantities for the whole delivery.
In most cases for which there are no discrepancies of quantity, this involves no extra effort,
because verification and confirmation are automated using the IDoc.
If differences are reported, the delivery cannot automatically be confirmed. In this case, you must
continue processing manually.
You can use work lists for processing documents in conjunction with POB - the outbound
deliveries for POB worklist and the Subsequent processing for POB worklist.
The system creates the billing document based on the correct (verified) quantity. Creating the
billing document via the billing due list is blocked until proof of delivery has been confirmed.
Before you can use the proof of delivery function, you need to define which delivery item
categories are relevant for the POB process. You also need to define reasons for deviation, and in
the customer master you are using for the POB process, specify POB relevance.
You can analyze deviation quantities and reasons for deviation (where, when, and why do the
deviations occur?).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

162

24. BILLING
Use:
Invoice is a legal document authenticating the transaction hence can be used as a reference for
all payment relevant correspondences

Useful for working out the sales statistics, profit and loss on buying price and selling price

Invoices are the proof sale hence can give details on taxes

Billing Functions:
The following functions are supported by billing:
Creation of invoices (and pro-forma invoices) on the basis of deliveries and services
Transferring posting data to financial accounting
Creation of credit and debit memos on the basis of requests
Cancelling business transactions

Billing Processing:
There are different ways to create a billing document:
by specifying the documents (Sales order or Delivery) to be billed
by processing manually from the billing due list
by having the system process a billing due list automatically as a background task

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

163
Also the following methods may be used for creation of an invoice.

Interface to Financial Accounting
During billing, the data relevant for accounting is passed on to financial accounting and posted to the
corresponding accounts.
These accounts are determined automatically on the basis of the account determination criteria in the
billing document.

STRUCTURE OF BILLING DOCUMENT
Header: VBRK: identification no of the payer, billing date, net value of the entire billing doc, doc
currency, terms of payment and inco terms, partner numbers, pricing elements.
Item: VBRP: material no, billing qty, net value of the individual items, weight & voln, number of
the ref doc for the billing doc, pricing elements relevant for the individual items.
The billing doc is controlled via the billing type
The header data of a billing doc defines how the invoice is to behave
It is not possible to have external no range for a billing doc.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

164

Copy Controls: How data is transferred in Billing Process?

Billing Document Create:
SAP Easy Access Sales and Distribution Billing Billing Documents Create
Transaction Code: VF01
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

165

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

166

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

167

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

168

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

169

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

170

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

171

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

172

The billing document represents the final function in the SD process chain.
The billing document has different effects on various areas of the R/3 System.
An important part of billing is the interface to Financial Accounting. This allows documents to be
created automatically in Financial Accounting and Controlling when you create billing documents.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

173
BILLING TYPE CONTROLLS

You can create new billing types or redefine existing ones in the standard R/3 System to
meet the requirements of your company installation.
Many of the control parameters in the billing type influence further processing in Financial
Accounting (posting block, account determination).
As of Release 4.0, new fields have been included in the billing type, representing special
features of the SD/FI interface, such as document type, negative posting, branch/head office
and value dated credit memos (see the unit on Special Features of the SD/FI Interface).
In Release 4.6 you can use the report SDCHECKVOFA to check various settings within
billing types for accuracy and consistency.
(Note: This report does not perform a complete check of all settings. You can find information
about it in the relevant report documentation).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

174

In Customizing for the item category, you can determine whether billing is to be carried out
with reference to a delivery or an order.
The system proposes a relevant billing type from the underlying sales document type.
Example: In delivery-related billing, a standard order (order type OR) is invoiced using billing
type F2.
You can change the proposed value when creating billing documents by entering the
required billing type in Default data.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

175

You can reference either an order or a delivery when creating an invoice.
If you want to ensure that goods have already been shipped before an invoice is created,
create an invoice with reference to a delivery..
Example: Delivering a carpet
You can use an invoice to refer to an order and a delivery simultaneously.
Example: You can create one invoice for goods (the carpet) and service (laying the carpet), as
long as the corresponding requirements for combining the two are met (see the unit on Types
of Settlements).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

176

If you want to invoice a customer for services rendered, you would normally create an
invoice with reference to the sales order, because deliveries are not usually created for
services.
Example: Laying a carpet

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

177

To cancel a billing document, you must create a cancellation document. The system copies
data from the reference document into the cancellation and offsets the entry in Accounting.
The reference document of the billing document (for example, the delivery for the cancelled
invoice) can now be billed again.
Credit memos can be cancelled with billing document type S2 in the standard system.
You do not need to make an entry in copying control for cancellations. The parameters to
be changed (for example, assignment number and reference number) are stored per billing
type directly in the Cancellation area of the screen.
As of Release 4.0B, you also have the option of canceling individual items in a billing
document.
Note: As of Release 3.0E, when you select cancellation, you branch to an overview screen
containing the original billing document as well as the cancellation. Before updating, you can
compare both documents in order to avoid any discrepancies during cancellation.
During the update, the system also attempts to complete the billing document and the
cancellation billing document, provided that forwarding of data to FI has not yet been carried
out. In this way, the complete process remains within SD and data does not need to be
forwarded to FI.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

178

You can create credit and debit memos either with reference to credit or debit memo
requests (sales documents), or - if your company does not require a release procedure in the
case complaints - directly with reference to a billing document (as of Release 4.5).
You can create credit and debit memo requests:
Without reference to a previous business transaction
With reference to an order
With reference to a billing document
You can control in Customizing whether the system is to set a billing block automatically for
a credit or debit memo request. The employee responsible can
- Release the credit or debit memo request after review. The employee can decide the amount
or quantity to be credited or debited.
- Reject items in the credit or debit memo request and enter a reason for rejection.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

179

You can release a credit memo request or return by removing the billing block.
If the complaint has not yet been justified you can enter a reason for rejection for each item.
The value of these items will not be copied into the billing document.
Using the reason for rejection allows you to control whether the item
- Is copied into the credit memo with a zero value (see above)
- Appears in the credit memo at all
Debit memo requests are processed in exactly the same way.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

180

The invoice e correction request represents a combination of credit and debit memo
requests.
On the one side, credit is granted fully for the incorrect billing item while it is simultaneously
debited (automatically created as a debit memo item). The difference created represents the
final full amount to be credited.
The invoice correction request must be created with reference to the corresponding billing
document (no reference to order or inquiry).
When creating an invoice correction request, the items are automatically duplicated (this
means that for every item in the billing document, a second item is created). The resulting item
categories must have opposite +/- values.
First all credit memo items are listed followed by all debit memo items. The reference to the
corresponding billing document is created when you specify the preceding document and the
preceding item.
The credit memo item cannot be changed. The corresponding debit memo item, however,
can be updated according to new characteristics (e.g. new pricing, change in quantity).
You can delete the credit and debit memos in pairs (unchanged pairs of items can be
deleted all at once in this way).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

181

Quantity difference is used when a customer complaint is being processed due to a certain
amount of damaged or sub-standard goods.
The system corrects the quantity to be billed via the debit memo item.
If other item pairs arise from the relevant billing document and these item pairs are
unchanged, they can be deleted in one step, using the Delete unchanged items function.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

182

Price difference is used when a customer complaint is being processed for incorrect pricing
of goods.
A correction of the pricing elements must be carried out in the debit memo.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

183

Billing types for pro forma invoices are available for export transactions.
You can create pro forma invoices with reference to orders or deliveries. You do not need
to post goods issue before creating a delivery-related pro forma invoice.
You can create as many pro forma invoices as required, since the billing status in the
reference document is not updated.
Data from pro forma invoices is not transferred to Accounting.
Note: In copying control, the field Quantity/value pos./neg. is not available for entry in order
to avoid the possibility of a pro forma invoice updating the quantity that has already been billed
in the reference document.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

184

Each-billing document requires a reference document (exception: billing external
transactions). This may be:
Sales document
Outbound delivery
Billing document
When billing explicitly, you must enter the number of the reference document as the
transaction to be billed.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

185

You must always refer to an existing document when creating a billing document.
Data will then be copied from the reference document to the billing document.
For delivery-based billing, the quantities to be billed, for example, can be taken from the
delivery; the prices, however are taken from the underlying order.
The reference document is displayed as the source at header level in the copying control
table.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

186

The network of documents in SD processing makes it possible for you to find all related
proceeding and subsequent documents quickly and easily. You can also display individual
documents from the document flow.
Note: You can call the document flow for the complete order or for individual items. (Tip: To
display the header document flow, you can branch directly to document flow from the Initial
screen via Environment)
Along with document flow, you can also use the status display to monitor processing of the
transaction.
Note: To ensure that you see all the subsequent documents created for the transaction
within the document flow, you can look it up from the order display screen.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

187

You can, to a certain extent, influence the data flow from reference documents to billing
documents. This is done using:
billing types (for example, for texts, partners)
copying control; the control options are as follows:
At header level:
Foreign trade data
Allocation number
Reference number
Item number assignment
At item level:
Quantity
Pricing
You can also use data transfer routines to influence the data flow to meet your individual
requirements. For example, terms of payment can be copied from the customer master instead
of the preceding sales document.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

188
COPYING CONTROL

The system administrator can define how data is transferred in the billing process in the
copying control table. Controls are determined for:
The header (target: billing type, source: sales document type)
The item (target: billing type, source: sales document type, item category)
The following controls are found at header level:
Reference document: which documents may be used as reference for billing?
Determination of foreign trade data, allocation numbers, reference numbers, and item
numbers
The following controls are found at item level:
Billing quantity: which quantity should be invoiced - the order or delivery quantity?
Pricing and exchange rate: Should pricing, for example, be carried out again or should
prices from the order be copied over, and at what exchange rate?
Updating the quantity and value in the reference document
Where should the conditions in the billing document be carried over from (for example,
copying
Over shipment costs from the shipment cost document)?
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

189

You can specify the requirements for billing a sales document under requirements in
copying control.
You can determine copying requirements for:
The header
Items
With the requirements in copying control you can, for example, specify whether goods
issue has to be posted before billing can be carried out.
You can define your own requirements using transaction VOFM.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

190

Delivery and order quantities are referenced in billing. You can also take into account the
quantity already billed (depending on the area for which the relevant billing type is used). The
above examples have been defined in the standard version.
This makes it possible, for example, to create an order-related billing document for
quantities already delivered.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

191

You may decide to create invoices using a background job because it is practical and
efficient. You can run the background job automatically in the following ways:
Periodically (for example, every Monday at 2 a.m.)
At a specific time (for example, June 19 at 8 p.m.)
The system can divide the billing due list into multiple background jobs and start them
simultaneously. In this way, you can make better use of your hardware by operating more than
one processor.
If you do not require a log or a detailed list, SAP recommends that you do not select these
options in the selection screen. This will improve performance considerably.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

192

As a rule, the system attempts to combine all compatible transactions into a single billing
document.
In the SAP R/3 System, it is possible to include both order-related and delivery-related
items in the same billing document.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

193

If the header partners or data in the header fields are not identical; the system will
automatically perform an invoice split.
All header partners and header fields in the billing document can cause an invoice split!
Example: Terms of payment in the two orders are different (see above).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

194

Invoice lists contain various billing documents (invoices, credit and debit memos) and can
be sent to a payer on specified days or at certain intervals.
The system administrator has to maintain the following data in Customizing for Sales and
Distribution:
If you have agreed upon a factoring discount, maintain condition type RL00 (factoring
discount) as well as condition type MW15.
Each billing type to be included in an invoice list must be assigned an invoice list type. The
SAP R/3 standard version includes two invoice list types: LR for invoices and debit memos, LG
for credit memos
You also need to maintain the following master data:
Define a factory calendar, which specifies when invoice lists are to be created. Enter this
factory calendar in the payer customer master record (Billing screen, Invoice list sched. field).
Maintain condition records for condition type RL00 for the payer.
Create output condition records for condition types LR00 and RD01 (You can determine
whether invoice papers are sent to the customer upon invoice creation or only when the
invoice list has been created).
As of release 4.5 you are able to cancel invoice lists. In the case of factoring discounts, a
corresponding cancellation document is created for FI.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

195

An installment plan allows the customer to pay in installments. Only one billing document is
created for all of the installment payments. The printed invoice is created on the basis of this
billing document and includes a list of individual payment dates and exact amounts.
Each installment payment creates an accounts receivable line item posting in FI.
You must define installment payment terms in Customizing.
For installment payment terms, you must specify the number and amount of the installment
in percentage and payment terms for each installment payment. When you post an invoice
with installment payment terms, the system will generate the appropriate number of postings in
the accounting document based on these specifications.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

196

When you save the billing document, the system automatically generates all the required
documents for accounting. In accounting, the R/3 system carries out a debit posting on the
customer receivables account and a credit posting on the revenue account.
The accounting document contains all the completed postings in financial accounting that
refer back to pricing in SD, for example, the receivable on the customer account or the
obtained net sales and taxes on the relevant G/L accounts.
When you save the billing document, further documents for accounting can be
automatically generated by the system, for example, for the components Controlling (CO),
profitability analysis, market segment analysis (CO-PA) or consolidation (FI-LC).
When the billing document is posted, the following also occurs:
the status in all related sales, delivery and billing documents, is updated
the sales statistics in the sales information system are updated
the customer credit account is updated
Umbrella term for invoices, credit memo, debit memos, proforma invoices & cancellation documents.
The billing doc is created with ref to a preceding document. The billing doc has header & item levels,
but no schedule line level.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

197
BILLING DOCUMENT TYPE: controls the entire billing doc. (Tcode: VOFA)
F1 Order related invoice F2 Del related invoice
F5 Proforma invoice for sales order F8 Proforma invoice for delivery
G2 Credit memo L2 Debit memo
RE Credit memo for returns S1 Cancellation invoice (VF11)
IV Inter company billing (Invoice) IG Inter company billing (Credit memo)
BV Cash sale S2 Cancellation credit memo
B1 Rebate credit memo B2 Rebate correction
B3 Rebate partial settlement B4 Rebate manual accruals

BILLING DOCUMENT CONTROLS:
The no range for the doc number
The billing type that can be used to cancel the billing doc
The transfer status of the billing doc: transferred to fin accounting, blocked from transfer, not
transferred
The proc for account assignment in fin accounting
The allowed output for a business transaction and the proc for output.
The partner functions allowed at header level
The partner functions allowed at item level
Texts
Rebates
Invoice list type
Delivery Related Invoice: if you want to ensure that goods have already been shipped before an invoice
is created, create del related invoice
Order Related Invoice: is created for services, since del is not created for service.
Proforma Invoice: does not post any financial amounts in to any ledger. Billing type F8.
Cancellation Invoice: is created when billing doc has errors or needs to be cancelled. Standard
cancellation invoice for a F2 invoice is the billing type S1.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

198

When processing the billing due list, the R/3 System consolidates as many items as
possible onto as few billing documents as possible. Depending on the system setting, these
can either be order items or outbound delivery items.
To be able to combine successfully, items must have specific common characteristics, for
example, the same billing date, the same ship-to party, payer or terms of payment.
The standard system contains a range of options for creating billing documents. You can
choose the option that best suits your requirements. Here are a few of the most common
options:
Invoice split: You have a sales order for which you want to set up an outbound delivery. Two
billing documents are created from the outbound delivery.
Separate billing document for each outbound delivery:
You have a sales order for which two outbound deliveries have been set up. Two billing
documents are created from the outbound delivery.
Collective invoice.
You have two sales orders for which three outbound deliveries have been set up (for example,
different ship-to party or partial delivery). A billing document is created from the outbound
deliveries.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

199
SUMMARY OF BILLING

1. TYPES OF INVOICES
a) Cancellation
To cancel Billing Document, so that Delivery or Order of Cancelled Billing Doc is due for
billing again.
Cancellation of Individual Items in a Billing Document also possible.
During Update of Cancellation document, system tries to complete both docs provided main
doc has not been forwarded to FI.
Copy Control: No requirement to maintain separate Copy Control for Cancellation
Documents. Already maintained in the Main Billing Document Type.
b) Invoice Correction (Credit or Debit Memo)
Can be created only with reference to a Billing Document.
Combination of Cr / Dr Memo Items for each item in the Invoice (because Inv Correction
Request has Indicator D).
For Qty (goods are damaged) or Price Corrections.
Cr Item cannot be changed. All changes done to Dr Item.
Final Amt / Qty Credited = Fixed Cr Amt / Qty Changed Dr Amt / Qty.
Automatic duplicate entries for each item (one for Cr & one for Dr) first all Cr Items, then
all Dr Items
Unchanged Items can be deleted in pairs (Cr Dr)
Copy Control (F2 RK): At Item level, two Item Categories (G2N & L2N) in RK are
proposed for one item category TAN in F2. Two pricing types exist = Invoice Correction
c) Proforma Invoices
For Export Transactions
Two types of PIs = Order-related (F5) & Delivery-related (F8)
No need for PGI in case of F8.
No Accounting Documents generated.
Cannot be cancelled.
Billing Status in reference doc not updated, so many PIs can be created.
In Copying Control, Qty/Val (+/-) is not available for entry to prevent PI updating Billed Qty in
reference doc.
d) Cash Sales
Order Related Billing
No new Price Determination (as Invoice has already been printed)
Can be made only after PGI
No Output Determination

e) Invoice List
Special Billing type which is a list of Invoices / Billing Documents made for a common Payer at
certain intervals or on specified days.
Individual Bill docs must be created and posted to FI before Invoice List can be created.
Invoice List type (LF for Invoices / Dr Memos and LG for Cr Memos) should be included in
the Billing Type.
Factory Calendar must be maintained in the Payer Master Record.
Condition RL00 (Factoring Discount) must be maintained for the Payer. This is statistical
condition maintained in normal pricing procedure, but has A/c determination key ERS.
Output Condition Types are LR00 and RD01.
Possible whether individual Invoices are sent to customer or only Invoice list is sent.
Has separate number range.
Incoming Payments can be posted against Invoice List number.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

200

2) REFERENCE DOCUMENTS

Process Primary Docs Reference Doc Billing Doc
Standard Order Order Delivery Invoice
Cash Sales Order Delivery Order Invoice
Services Order (no delivery) Order Invoice
Services &
Standard Item
Service Item
Standard Item
Order
Delivery
Invoice
Credit / Debit
Memo
Order
Credit Memo
Request
Credit Memo
Invoice
Credit Memo
Request
--
Credit Memo
Request
-- Invoice
Cancellation
Invoice
--
Original Invoice
Cancel Invoice
Cancellation Cr
Memo
--
Credit Memo Cancel Cr
Memo
Invoice Correction Original Invoice
Invoice Correction
Req
Cr / Dr Memo
External
Transactions
--
NO REFERENCE
(Doc no. of external
Doc)
Invoice
-- Delivery Invoice
Proforma Invoice
--
Order Proforma
Invoice
Order
Delivery Proforma
Invoice
Returns
Order / Invoice Returns
Order Delivery
Returns Order
Returns Cr
Memo
Rebates Invoice Rebate Request
Rebate Cr
Memo
Invoice List -- Billing Documents Invoice List
Inter-company
Billing
Delivery Invoice

3) CREATING BILLING DOCUMENTS
a) Billing can be Manual or Collective, Foreground or Background. Block has to be removed in
Reference Doc (Cr or Dr Memo).
b) Possible to bill partial qtys or individual items to be billed for deliveries or orders by using Item
Selection.
c) For Delivery-related Billing, this is possible only if the Item Category has Billing Relevance K.
d) Collective Billing using Billing Due List: Possible to Simulate Billing before doing it actually to
check for errors. Possible to do Split Analysis here.
e) Possible to include both order-related and delivery-related items in same Billing document.
f) Periodic Billing: All deliveries due for Billing on a certain date can be billed collectively into one
Invoice. Based on:
Maintain Individual Billing dates in Factory Calendar using special rules
Enter Factory Calendar in Payer Master Record.
g) Invoices created in Collective Run are combined under a group number.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

201
h) Billing Date is decided at the time of Sales Order. It is determined from Invoice Date from Billing
Schedule for the Customer else the Planned Goods Issue Date / Date of services rendered.
i) Background processing is more efficient. Can be periodic or at specific time.
j) Possible to collectively cancel Invoices created in one Collective run by reversing the run.
k) External Billing: Possible to Invoice external documents (Sales Orders, Deliveries) not created
in SAP.
Data must be in sequential file of specified format
Required fields: Specify min number of fields to be filled from the external Data
Optional fields: specify how remaining fields in Billing Document are to be populated
(external or SAP).
External order numbers can be entered.

4) EFFECTS OF BILLING
a) Before Release to Accounting:
Billing Status in Sales, Delivery and Billing Documents updated.
Sales Statistics in SIS updated.
b) After Release to Accounting:
All Accounting & CO Docs are generated. Receivables accounts are debited and Revenue
Accounts are credited. If no Release to Accounting is done (due to errors or Posting Block)
then NONE of the Accounting / CO documents are generated.
Posting to CO, CO-PA, and FI-LC also done.
Customer Credit Account is updated.

5) INVOICE COMBINATION & SPLIT
a) Deliveries can be combined if following are the same:
Payer
Billing Date
Destination Country
b) Invoice split can occur if Header Partner / Header Data have differences. Possible to define
additional Item-dependent split criteria in Copy Control in field VBRK-ZUKRI in Billing Doc
Header.
c) Individual Billing Documents for each Delivery / Sales Order (copy routine 3 Single Inv
containing Reference Doc number in VBRK-ZUKRI).

6) LINK TO FI
a) Changing Billing Document
Before Release to Accounting After Release to Accounting
Output
Billing Date
Pricing
Account Determination
Output

b) No Copy Control from SD FI
c) Posting Block (in Bill Doc Type): If no Posting Block, Release to Accounting is automatic on
saving Bill Doc. In case of Posting Block, Release to Accounting done as separate step after
saving the Bill Doc.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

202

d) Reference Number & Allocation Number
(From Copy Control at Header level from Sls Doc/Dely Bill Doc)
Reference Number Allocation Number
Header of Accounting Document
In Customer Line Item of the Accounting
Document
Used for Clearing incoming Payments for a
Customer
Used for sorting Line Items for a Customers
receivables
If Blank, then Bill doc number
If Blank, field remains blank. Stored as
Assignment in Bill Document Header. Can be
used as splitting criteria from Delivery to
Billing.
In Invoice List, reference no from Invoice List
overwrites reference from Individual Bill Docs
of that list.

A: PO Number
B: Sales Order Number
C: Delivery Number
D: External Delivery Number
E: Bill Doc Number
F: External Delivery Number or Delivery Number

e) Accounting Document Types: Contained in the Billing Type. If no document type is
maintained, then default type is RV.

f) Head Office / Branch: Helps to decide which Payer for Accounting Document (Payer or Sold-to
Party). For the Branch Customers, the Head Office field in Company Code view is populated
with the Customer Code of the Head Office.

g) Negative Postings: to post Cancellations / Credit Memos on same side of Account with
negative values so that totals are 0. Only display of open items is changed. No effect on the
Processes in FI.

h) Value Dated Credit Memos: For Credit Memos created with respect to an Invoice, Credit
Memo date should be later than the Invoice date even if Invoice Date is in future. If Invoice Date
is later than today, then Credit Memo date is taken as Invoice date, else Credit Memo date is
taken as today.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

203
BILLING FI POSTINGS
SAP AG 1999
SD Example
+ Sales order 10 pieces at $ 12 per piece
+ Goods issue: 10 pieces delivered, standard price $ 10 per piece
+ Invoice: 10 pieces at $ 12 per piece
+ Incoming payment: $ 120

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

204
SAP AG 1999
SD Example: Postings
Goods issue:
Material usage
(Expenses)
100
Stock
(Assets)
100
Sales revenue
(Revenues)
120
Receivables
(Assets)
120
Invoice:
Incoming payment:
Receivables
(Assets)
120
Bank
(Assets)
120

In the example of an SD business transaction, an accounting document is created at the
point of goods issue and/or invoice creation.
At the point of goods issue, the goods physically leave the warehouse. This results in a
stock-related and value-related posting. This means that the stock is reduced and the
materials used increased. The posting is therefore called "Materials used to stock".
At the point of billing, the customer accumulates receivables, and additions are posted to
sales revenues (posting record: Receivables to sales revenues).
If the incoming payment is made in FI, the receivables are reduced again and the amount of
the cash inflow is posted to a bank account (posting record: Bank to receivables).
Posting output tax has been ignored or the purposes of this simplified example.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

205
SD / FI INTERFACE IN BILLING DOCUMENT

The system sends billing data in invoices, credit memos, and debit memos to Financial
Accounting and posts them to the correct accounts.
The following data can be changed before an accounting document is created:
1. Billing date
2. Pricing
3. Account determination
4. Output determination data
Once the billing document has been released to accounts; you can only change output
data.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

206

Normally, the system automatically transfers accounting-related data to Financial
Accounting.
However, you might not want the data to be transferred automatically for certain billing
types. In that case you can set a posting block for the billing type concerned.
The system will then generate the accounting documents only after you have released the
billing documents.
This allows you to generate SD billing documents first, then print out the billing documents
and finally, transfer them to Financial Accounting. In this way you can improve system
performance, for example.
Note: The system either generates all or none of the accounting documents. This means
that if the posting block is active, or errors have occurred during account determination, the
system will not create CO documents. The accounting documents will not be created until you
have de-activated the block or corrected the error.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

207
Reference Numbers and Allocation Numbers

You can automatically fill the Reference number and Allocation number fields in the
accounting document with numbers from SD documents.
The reference number is in the header of the accounting document and is used for clearing.
The allocation number is in the customer line item and is used for sorting line numbers.
In Customizing for copying control in billing, you can define which numbers will be copied
as reference or allocation numbers:
A - Purchase order number
B - Sales order number
C - Delivery number
D - External delivery number
E - Billing document number
F - External delivery number if available, otherwise delivery number

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

208

SD / CO - PA Interface

There are two procedures for profitability analysis: costing-based and account-based.
Both procedures can be used in parallel. However, before drill-down reporting you must set
it to either costing-based or account-based.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

209

Order processing is the focal point of SD activities and contains three principle stages:
Order entry, delivery with goods issue, and billing.
In costing-based profitability analysis, data is transferred to CO-PA as soon as an order is
entered. The system generates a line item with a profitability analysis document for each sales
order item. In the same way, the billing data are also transferred online. The system generates
a line item for each billing item.
In account-based profitability analysis, data is transferred to CO-PA when it is posted to FI
from SD. This means that when the financial accounting documents are generated for goods
issue and in billing, the system creates line items in CO-PA and transfers the data to the
accounting valuation base. Data is not transferred when a sales order is entered because
nothing is posted to FI at that stage.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

210

CO-PA calculates the profit for a certain profitability segment by transferring data from SD.
The profitability segment is defined by certain characteristics and characteristic values and
these determine what should be evaluated.
Example: an evaluation is made for the profitability segment "motorcycles, retail,
southeast region".
These characteristic values can be freely defined. They are taken from the header or the
item in the sales document.
The real evaluation of profitability segments takes place using key figures (evaluation
sizes).
In costing-based profitability analysis, the key figures are the quantity and value fields
such as price, quantity, discount, and weight. This data comes from SD documents.
In account-based profitability segments, the evaluation takes place in account groupings.
The data is taken from the relevant accounting documents in FI.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

211

25. CUSMTOMER COMPLAINTS
ReturnsPurpose:
To address products that customer has returned due to complaints.
The complaints may be due to
1. Quality defects
2. Incorrect Deliveries
3. Products damaged in transit, etc..
Once the analysis of returned goods complete manufacturer determines :
1. Goods are sent either for rework or scrap
2. Whether customer will be credited for goods and if yes, in what amount
If Customer Returns the Goods: If Goods have been rejected by Customer and are returned.

Dotted line indicates that return doesnt have to refer preceding document.

VA01: Return Order (Order Type: RE) (Item Category: REN) & enter, Create Return Order with ref to Sales
Order No. Give order no & click on Copy (F5) and change the order quantity say from 50 boxes to 20 boxes.
VL01N: Return Delivery
VL09: Goods Reversal.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

212
If Customer Wants Refund For the Amount: or credit memo: Done if Goods have been
delivered and Billed to Customer, and customer complains about shortfall in quantity / quality
of the goods received.

If Item in Credit Memo Request has been assigned a Reason for Rejection, then it can either be
copied to Credit Memo with 0 value or does not appear in Credit Memo at all.
It can be defined that if Value of Cr Memo Request is below a certain limit, then Cr Memo Request
is released automatically.
VA01: (Order Type: RE), (Item Category: REN), (with ref to sales order)
VL09: Goods Reversal
VA01: Credit Memo Request (Order Type: G2), (Item Category: G2N), (with ref to Return Order,
please remove billing block)
VF01: Credit memo.
If the customer wants refund for the amount, enter a credit memo with ref to the return.
If Customer Wants Replacement: If the customer wants replacement product, enter a free of charge
subsequent delivery with ref to the return.
VA01: (Order Type: RE) with reference to Sales Order.
VL09: Goods Reversal
VA01: Free of charge Subsequent Delivery (Order Type: SDF)
VL01N: delivery
LT03: picking
VL02N: goods issue
The Customer Does Not Send the Goods Back:
If the customer wants a replacement product, you create a free of charge subsequent delivery
with ref to sales order
If the customer wants a refund, you enter a credit memo request, with ref to the sales order or
invoice.
VA01: credit memo request (G2) or free of charge subsequent delivery (SDF) with ref to sales
order. For SDF there will be delivery, picking, and goods issue.
VF01: invoice

Delivery
(LF)
Invoice (F2) Sales Order
(OR)
Credit Memo
(G2)
Credit Memo
Request
Remove Billing Block
Release to
A/c
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

213
For Damaged Replacement:
VA01: free of charge subsequent delivery (SDF) with ref to sales order
VL01N
LT03
VL02N
Debit Memo Request: (Order Type: L2) & (Item Category: L2N)
In case excess Goods have been delivered. Follow the same process as for credit memo. A debit
memo request is a sales document used in complaints processing to request debit for a customer. You
can create a debit memo request if the prices calculated for the customer were to low. Remove the
Billing Block.
VA01: debit memo request with reference to invoice or order
VF01: debit memo
Invoice Correction Request:
A sales doc used in complaints processing to correct the quantity or price of one or more items in an
invoice.
Each invoice correction request that is made in ref to an invoice contains 2 items for each item in the
invoice (you cannot create an invoice correction request in ref to a sales or delivery doc type), viz First-
credit item & Second Debit item. These contain the same value and quantity. The first item is the
copied value & quantity copied from the invoice, this item appears as credit item. The second item is
the debit item, which represents the correct quantity &/ or the value.
If you want the system to generate a credit memo for a +ve amount, and a debit memo for a ve
amount, you need to set an additional sales document type in customizing, for e.g., ZRK1 (invoice
correction request for debit memos). You can change these settings in customizing under Sales
Sales Document Sales Document Header Define Sales Doc Types in the Sales Catalog
Field.
If the invoice correction request is characterized as a credit memo request, that is, the doc type RK has
the characteristic as K in the sales doc catalog field & has order related billing assigned to it in the
form of G2 or credit memo, the system creates a credit memo for +ve value. For debit memo the
characteristic will be L & has order related billing assigned to it in the form of L2, the system creates a
debit memo for a ve value.
You create invoice correction request with ref to an invoice.
Price 100
o 110: credit memo
o 90: debit memo
VA01: (Order Type: RK) with ref to invoice
VF01: automatic credit or debit memo.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

214
Delivery Free of Charge: (Doc Type: FD)
A Free of Charge Delivery is used to send samples or free products to the customer free of charge.
The customer is not billed for the goods delivered.
Has Delivery Block, and can be rejected. No Invoicing. PI can be used.
Free of charge, is recorded using the order document type FD.
The delivery is actually only relevant for deliveries and not invoicing. The delivery type used is
the standard delivery type- LF.
The item category KLN is not relevant for billing and pricing.

VA01
VL01N
LT03
VL02N
When you create a free of charge delivery you must enter a value in the order reason field or
the system informs you that the doc is incomplete.

Order Type:
Delivery FoC
(FD)
Delivery (LF) Remove
Dely Block
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

215
Subsequent Delivery Free of Charge: (Order Type: SDF) (Item Category: KLN)
Subsequent Delivery Free of Charge involves the delivery of goods free of charge in response to
the complaints raised by the customers with respect to the quantity or quality differences.

A free of charge subsequent delivery document-SDF is used to send products later to the
customer free of charge against any complaints made by the customer.
The standard delivery type LF is configured for this transaction.
The transaction is not relevant for billing as the items are free.
The standard item category- KLN is used which is not relevant for billing and pricing.
A subsequent delivery of charge is usually created with reference to the previous order.

To deliver Free of Charge Goods if Customer receives too few goods or if the goods have been
damaged in the shipment. It must be based on existing Order. Has Delivery Block, and can be rejected.
No Invoicing. PI can be used.

To create a free of charge subsequent delivery, you have to refer to an existing sales doc, such as:
sales orders, contracts, and contracts release orders.
You do not have to use create with ref to free of charge subsequent deliveries, if you enter the order
type & choose enter, a dialog box will appear where you can enter the no of the order to which you are
referring. No invoice is created or necessary, as the items are free.

Returns: (Order Type: RE) (Item Category: REN)
A return is a sales document used in complaints processing for when a customer sends goods back.
You can create the return in one of the following ways: without ref to an order, with ref to an invoice,
with ref to contracts, contract release orders, billing doc.
It may be worthwhile ensuring the return order reason was entered on the sales doc. Thus, it may be
necessary to add this in an incompletion proc.
Order Type:
Subs
Delivery FoC
Delivery (LF) Sales Order
or Returns
(RE)
Remove
Dely Block
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

216
It is advisable to indicate a shipping cond that is specifically used for returns. This is useful when
running del due list.
Credit Memo: (Order Type: G2) (Item Category: G2N)
A credit memo request is a sales doc used in complaints processing to request a credit for a customer.
The credit proc generally follows 2 business procedures; the first being the scenario where the
customer returns products previously purchased & requires a credit. The second general form of credit
proc is when the customer is credit without ref to a return (goods not returned or customer
overcharged).
You can also set a mandatory that the credit memo request can only be created with ref. You can
create a credit or debit memo request with ref to an existing order, with ref to an existing order, with ref
to an invoice, with ref to contracts, contract release orders, billing doc.
You may not wish to credit for every thing, such as the entire freight charge from one invoice. You can
instead have a new pricing proc in the credit memo request that is similar to the standard pricing proc
you use, but not have the freight cond type. Thus the standard values are copied over, excluding
freight.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

217
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

218
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

219
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

220
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

221
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

222

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

223
26. PRICING
Pricing is the combination of creating correct pricing procedure that map the business needs &
processes, such as correct pricing & discounting, & keeping to the legal requirements placed on the
business, such as adhering to the tax laws of the country.
The term Pricing is used broadly to describe the calculation of prices and costs.
Condition Technique - Example

SPRO- IMG- SD- Basic Functions- Pricing- Pricing Control
Create Condition Table: V/03, V/04, V/05
Define Access Sequence: V/07
Define Condition Types: V/06
Define & Assign Pricing Procedure
o Maintain Pricing Procedure: V/08
o Define CuPP: OVKP
o Define DoPP: OVKI. The DoPP indicator is used to determine pricing in conjunction with
the sales area & CuPP.
o Assign DoPP to Order Types & Billing Types: OVKJ & OVTP
o Define Pricing Procedure Determination: OVKK

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

224
1. Create Condition Table: V/03, 04, 05
Condition table contain the key fields for maintaining condition records. In other words condition records
are stored in condition table. Put the most general field for e.g., Sales Orgn in the highest position &
the most specific field in the lowest. After organizational fields, place fields from doc header before
those that come from item level (customer comes before material).
A condition type can have multiple condition tables.
A condition table can be used for multiple condition types.
Sales Orgn, Distbn Channel, Div, Cust, Mat: Customer Specific Price
Sales Orgn, Distbn Channel, Div, Price List Type, Mat: Price List
Sales Orgn, Distbn Channel, Div, Mat: Material Price.
Menu path: IMG Sales and Distribution Basic functions Pricing Pricing Control Define
Condition table.
T-code: V/03

Condition Table - Configuration
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

225

2. Maintain Access Sequence: V/07 (Most specific to most general)
Access sequence is a search strategy with the help of which the system gets the valid condition
records. It contains the required condition tables in the required order. Go to new entries, define 4-digit
acc seq. Select acc seq, go to Accesses and place the cond tables and check exclusive indicator
(which determines that if a cond record is successfully found, the system will stop searching further).
Select each cond table and go to Fields.
There are few condition types for which you do not create cond records (header discounts that
you can only enter manually). These cond types do not require an access sequence.
An Access sequence can be used or assigned to multiple condition types.
Menu Path: IMG Sales and Distribution Basic functions Pricing Pricing Control Define
Access Sequence.
T-code: V/07

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

226
Access Sequence - Configuration
Access Sequence consists of accesses which specify the access number or the sequence in which the
system searches the condition tables for the required data.
Requirement can be specified for each condition table thereby ensuring system access that condition
record only on fulfillment of certain conditions.
Activation of exclusive indicator limits the access to the first match.

The access sequence refers to the fields which are relevant for pricing using the condition tables
contained in the access sequence.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

227
3. Define Condition Type: V/06: Condition type is a group of relevant conditions. It tells the behavior
of a record.
Condition types are used in the pricing procedure to define how the cond is going to perform, such as
either a %tage or a fixed amount. The cond type can be automatic or it can allow manual changes.
Copy the required cond type and rename. Then assign acc seq to cond type.
If you use different calculation types for what are otherwise the same conditions (for e.g.,
%tage, as fixed amt, qty dependent), you do not have to define different cond types in
customizing. You can set different calculation type when maintaining cond records.
Menu Path: IMG Sales and Distribution Basic functions Pricing Pricing Control Define
Condition type.
T-code: V/06

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

228
Condition Type - Configuration
Various control parameters are defined for each condition type, which determines its behavior while
pricing.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

229

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

230

Functionality of Condition Types:
Access Sequence: in this field specify the corresponding access sequence for the condition
type.
Condition Class: surcharge & discounts or prices
A Discount / surcharges
B Prices
C Expense reimbursement used in Rebates.
D Taxes
G VPRS.
Plus/Minus: -ve, +ve or both
Condition category: Its a classification of conditions according to pre-defined categories.
Calculation Type: fixed amt, %tage, qty, wt, voln
Rounding rule: commercial, round up and round down
Group Cond: if we check a header condition as a group condition the condition amount is
distributed proportionately among all the line items in the sales document.
Manual Entry: whether manual or automatic entry has priority
Header Cond: after entering the header cond type click on the button activate. The cond amt of
the header condition is copied as it is to all the line items in the doc.
Item Cond: if we check this field for a condition types it becomes item condition, which ahs to
be enter at the item level only.
Amount/ Percent: check & u can change the amount or % for the cond type during data
processing
Delete: check & the cond record may be deleted from the doc.
Value: check & the value of the cond type can be changed during data processing
Calculation Type: check & the cal type can be changed during doc processing
Valid from & to: specifies the beginning and ending of the validity date that the system
automatically proposes when we create condition records for the condition types.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

231
Scale Basis: determines how the system interprets a pricing scale in a cond, for e.g., the scale
can be based on qty, wt, voln
Check Value: indicates whether the scale rates must be entered in ascending or descending
order.
4. Define and Assign Pricing Procedure: V/08
A pricing proc consists a list of condition types in a defined order, such as price less discount plus tax.
Go to new entries; define 6-digit pricing proc with descp. Select the 6-digit pricing proc and go to
Control Data, you will be faced with an empty structure.
Menu Path: IMG Sales and Distribution Basic Functions Pricing Pricing Control Define
and assign Pricing Procedure.
T-Code: V/08

Pricing Procedure - Configuration
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

232
Pricing Procedure consists of a group of allowed condition types placed in the sequence of their
execution.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

233

Step: the no that determines the sequence no of a cond type with in a procedure
Counter: second mini step with in an actual step
Condition type: specify the cond type
Description: Description of the condition type, you need not type.
From & To: if you specify the ref steps in these fields, the cond values of the 2 steps specified
and steps in between are totaled
Manual: If you check this field the condition type is only included in determination either if they
are entered manually.
Mandatory: whether a cond type is mandatory when system carries out pricing. The Mdt
column identifies those condition types that are mandatory in the pricing procedure. Mandatory
condition types are the sales price or the cost price. Should a mandatory cond typ not be found
in the procedure, the system will throw an error in pricing?
Statistical: the value represented in this step will not alter the overall value. The condition type
marked as statistical or Stat will not be included in the net value calculation for that item. The
net value is displayed in the item details of the order and invoice, and the total of all items net
values is displayed on the order and invoice document.
Examples:
VPRS:- Cost
PI01 Inter company price.
SKTV Cash discount
SKTO Cash discount.
Print: which cond types should be printed on a doc (order confirmation, invoices)
Subtotal: controls whether & in which fields the cond amts or subtotals are stored. The subtotal
field assigns a subtotal key to a step in the pricing procedure. These subtotal fields are then
used in other areas of the system such as in logistics information system (LIS). For example, it
is recommended to assign the subtotal field 4 to the total value in the pricing procedure for
Freight.
Requirement: for a cond type to be executed in the sales doc the requirement specified here
must be satisfied. (It is a gateway). The requirement is used to assign a requirement to the
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

234
condition type. This requirement can then be used to exclude the system from accessing the
condition type and trying to determine a value.
2 Item with pricing used in discounts.
9 Cash discount after tax.
10 Plant is set, used for Tax condition.
14 Discount before tax
21 Invoice list control
24 Rebates get effect in Billing doc not in sales order
Alternative Calculation Type: The column AltCty specifies that the system is to use the
formula represented in this column as an alternative in finding the value of the condition type,
rather than by using the standard condition technique. For example, this can be used to
calculate complex tax scenarios.
Alternative formula to the formula in the standard system that determines the cond. In the std
SAP system for the cust expected price EDI1, the alt cal type is 9, which means it contains a routine
with a logic which states that the difference between the customer expected price & the net value is
zero.
2 Net value
6 Initial price
8 Expected value
9 Expected price
11 profit margin
Alternative Cond Base Value: alternative formula for determining the cond basis (amt to which
the discount or surcharge in a scale refers). The column AltCBV is a formula assigned to a
condition type in order to promote an alternative base value for the calculation of a value. For
example, one can specify a formula that uses a subtotal, such as 4, from the Subtotal field,
modify it slightly, such as dividing it by 2, and then using the resultant value as a base value for
the condition type.
2 Net value
3 Net price
4 Net value plus tax
11 cash discount base
28 100% discount
29 Free goods / Inclusive.
Account Key: this field enables the system to post the sales value to different G/L accounts.
ERL: sales revenues, ERS: sales deductions, ERF: freight revenue.
Accruals: this is exclusively for rebate cond types BO01 & BO02. Key, which identifies various
types of G/L accounts for accrual postings.
Note: To maintain your own requirements and routines use the transaction code -- VOFM
VPRS: Cost: Cost pick up from MMD of Accounting view 1.
TAX: MWST
Tax is calculated on the following parameters:
Plant
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

235
Ship to party region
Customer tax classification
Material tax classification
5. Pricing Procedure Determination: OVKK: Determination Rule
Before one can proceed with the determination rule, one needs to maintain the CuPP & DoPP. One
needs to assign a single character alphanumeric key with a short descp. Then assign the DoPP to the
sales doc types. This will ensure that for e.g., all sales orders created using order type OR, which has
been assigned a DoPP of 1, will all use the same pricing proc if created in the same sales area & with
the same CuPP. In some instances, you may not want to have the same pricing proc for a sales doc, as
you may want in a billing doc. For this reason, you may allocate a different DoPP to a billing doc.
Do not forget to assign the CuPP indicator to your CMD in the Sales Screen
Menu path: IMG Sales and Distribution Basic functions Pricing Pricing Control Define
and Assign Pricing Procedures Define Pricing Procedure Determination
T-code: OVKK

Sales Orgn + Distbn + Division + CuPP indicator + DoPP indicator = Pricing Procedure

To Create own Sales Doc Types:
SPRO- IMG- Sales Doc- Sales Doc Header-
Define sales doc types: VOV8. Copy std order type& rename
Assign Sales area to Sales Doc Types:
o Combine sales orgn
o Combine Distbn channel
o Combine division
o Assign sales order types to permitted sales area

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

236
To create Price List Types:
Pricing Relevant Customer Master Data Fields:
Menu Path: IMG Sales and Distribution Basic Functions Pricing Maintain Price-Relevant
Master Data Fields Define Price List Categories for Cust. & Define Pricing Groups for Cust.
T-Code: OVKP & VD02
Define price list category for customers: OVSI: assign to CMD sales area screen in price list
type field, in sales tab page in pricing and statistics section.
Define pricing group for customers: OVSL: assign to CMD sales area screen in price group
field, in sales tab page in pricing and statistics section.
Define material group: OVSJ: assign to sales orgn 2 view of MMR in Mat Pricing Group Field.
2 digits character key with description

Pricing Relevant Material Master Data Fields
Menu Path: IMG Sales and Distribution Basic Functions Pricing Maintain Price-
Relevant Master Data Fields Define Material Groups
T-Code: MM02
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

237

Pricing Relevant Sales Document Fields
Menu Path: IMG Sales and Distribution Basic Functions Pricing Pricing Control Define
and Assign Pricing Procedures Define Doc. Pricing Procedure & Assign Doc Pricing procedure to
Order types
T Code: OVKI & OVKJ

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

238
Pricing Relevant Data Fields - In Order

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

239
Different Condition Types in Pricing
Cond
Type
Description Cond Class Calculation Type
BO01 Group rebate Exp reimbursement Percentage
BO02 Mat rebate Exp reimbursement Qty (fixed)
BO03 Cust rebate Exp reimbursement Percentage
BO04 Hierarchy rebate Exp reimbursement Percentage
BO05 Hierarchy rebate / Mat Exp reimbursement Percentage
BO06 Sales Independent
Rebate
Exp reimbursement Fixed amount

EDI1 Cust Expected Price Prices Quantity
HB00 Discount (value) Discount / Surcharge Fixed amount
HD00 Freight Discount / Surcharge Gross weight

K004 Material Discount / Surcharge Qty / absolute
K005 Customer / Material Discount / Surcharge Qty / absolute
K007 Customer discount Discount / Surcharge Percentage
K020 Price group Discount / Surcharge Percentage
K029 Material Pricing Group Discount / Surcharge Absolute discount by wt
K030 Customer/ Mat Group Discount / Surcharge Percentage
K031 Price Grp/ Mat Pr Group Discount / Surcharge Percentage
K032 Price Grp/ Material Discount / Surcharge Quantity / absolute
KF00 Freight Discount / Surcharge Gross weight
NRAB Free Goods Discount / Surcharge Quantity

PI01 Inter company price Prices Quantity (fixed)
PI02 Inter company % Prices Percentage
RB00 Discount / value Discount / Surcharge Fixed amount
PR00 Price Prices Quantity
VPRS Cost Prices Quantity
RL00 Factoring Discount Discount / Surcharge Percentage
MW15 Factoring Discount Tax Taxes Percentage
SKT0 Cash discount

Customer Specific Price: sales orgn, distbn, division, customer & material
Price List Price: sales orgn, distbn, division, price list type & material
Material Price: sales orgn, distbn, division & material
Customer discount: sales orgn, distbn, division & customer
Customer material discount: sales orgn, distbn, division, customer & material or sales orgn,
distbn, customer & material.
Material discount: sales orgn, distbn, division & material or sales orgn, distbn & mat.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

240
6. Condition Records: VK11/12/13: Condition Records store the actual value for all the pricing
elements. Condition records allow you to store & retrieve pricing data in the system. Pricing elements
are generally managed at the sales orgn & distbn channel level. There fore you always have to specify
organizational level when creating cond records. In the case of cond records for price groups, freight
charges, & cust specific prices & discounts you must also enter the division. As a result, you can create
conditions according to product groups with these price elements.
Menu Path: Easy Access Logistics Sales and Distribution Master Data Conditions Select
using Condition Type Create
T-Code: VK11
Condition Maintenance Menu Path: Easy Access Logistics Sales and Distribution Master
Data Conditions Create
T-Code: VK31

Condition Record - Create
Condition records can also be created with reference to those already having similar data but
vary on accounts like validity period, etc. During the process, changes can be made to the rate,
validity period, and additional sales data, etc.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

241

Pricing Elements in Sales Order:
Price: the basis of pricing during sales order processing is the gross price of the mat. The
system selects the most specific record- the cust specific price. If it does not exist, the system
looks for price list type. If it also does not exist then system takes the basic material price. You
can define price list types by customer groups (wholesale or retail) or by currency (price lists for
each foreign country dealt with)
Surcharge & Discounts:
Freight Costs: you can create cond record either based on: the first part of the inco term (for
e.g. FOB) or on the combination of part 1 & 2 (for e.g. FOB & Boston). There are 2 predefined
freight conditions
o KF00: applies to each item in a sales doc.
o HD00: applies to entire document.
Sales Taxes:
Prerequisites for Automatic Pricing:
Necessary data must be maintained in MMR & CMD:
Material Master Data: the price related fields can be found in sales orgn 1 & 2.
Tax Classification
Price Material: you can specify another material as ref for pricing info
Material Group: defines a group of materials for which you want to apply the same cond
record.
Cash Discount: whether or not mat qualifies for cash discount
Customer Master Data: the price related fields appear on sales data screen.
CuPP: specify the pricing proc for a customer
Price List: Allow you to apply a mat price in a particular currency to a group of
customers e.g. wholesale customers.
Price Group: price group lets you apply a discount to a particular group of customers.
Tax Classification: billing tab page.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

242
Let Me:
Use the Transaction Codes below to create Pricing Condition Technique.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

243

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

244
Tips and Tricks
Pricing in the sales document can be analyzed using Analysis button in the conditions overview screen
at the Item level

With the help of analysis we can try to figure out how the system has carried out the pricing in the sales
document. Analysis provides information on:
Condition types accessed and their nature
No of Accesses available fro each condition type
Condition Record and their values.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

245
HEADER & ITEM CONDITIONS
The standard system includes cond types that you can apply at only the header level, the header
conditions. Cond types that you can only use for items are called item conditions. There are some cond
types that can be used at both header & item level:
RA01: percent from gross
RB00: absolute discount
RD00: weight discount
Header Conditions: you cannot create cond records for it; it is entered manually in order processing.
Automatic pricing does not take place for them.
HA00: percent discount
HB00: absolute discount
HD00: freight
HM00: order value
Item Conditions: in the std SAP most cond types are defined as item conditions:
K004: mat discount
K005: cust/ mat discount
K007: cust discount
PR01: mat price
KF00: freight
Distribution between Header & Item:
Header conditions apply to all items in the doc & are automatically distributed to all the items. It can be
either percentage or an absolute amount.
If you enter a header cond that is based on a percentage (e.g., a dis of 2% ) the system automatically
applies this percentage to all the items in the doc.
If the header cond is an absolute amount, there are 2 ways in which the system can distribute the
amount among the items in the doc:
Distributed proportionally among the items
Amount entered at header level is duplicated for each item.
You control the distribution of absolute header condition in the Group Price Field per cond type.
HB00: header discount distributed as percentage because it is marked as a header cond &
group condition. The system distributes the amt proportionally among the various items, in this
case according to the value of the items. The distribution of an absolute header cond need not
be based on value. For e.g. you can specify in customizing for sales that the distribution is
based on weight & volume of the different items. You can specify the basis of distribution in the
Alternative Cond Base Value field in the pricing screen.
RB00: assigns the header discount to each item identically, because it is only marked as header
condition.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

246
PRICING SCALES
Scale Basis:
In the standard system, a pricing scale can be based on any of the following criteria:
Value
Quantity
Gross weight
Net weight
Volume
A formula specific to your requirement.
The scale basis is defined in customizing for sales for each cond type
Creating Scales:
Select line item and choose Scales Icon from tool bar or choose Go To Scales in the fast entry
screen of the cond record.
Enter a scale quantity & a rate & save cond record
Scale can be descending scale (50/-, 40/-, 30/-) or ascending scale (2%, 3%, 4%)
Specifying Scale Types:
In each condition record where you define a scale, you can further specify the scale type. The scale
type determines whether the scale is a From-scale or a To-scale. For example, if you specify a From-
scale that is based on quantity, the scale determines different prices based on different quantities. To
change the scale type for a condition record, choose Go to Details. Specify the scale type you want
to use.
Special Features of Calculating the Scale Base Value:
In Customizing for Sales, you can define a condition type as a group condition (for a group cond to be
effective, the items must belong to a group. You can freely define the group to meet the needs of your
own orgn. A group condition means, for example, that the system bases a discount on the combined
quantities of more than one item in a sales document. The combined quantities may mean that the
customer gets a better price than if the items were priced individually. K020 is a group condition.
Pricing with Graduated Scales:
You can maintain condition records with graduated scales. Using a graduated scale allows you to price
an item for each level of a pricing scale. By comparison, when you use normal scales, the system
determines one price depending, for example, on the item quantity; the same price then applies to each
unit of the item. With graduated scales, the result is that multiples prices can appear in the pricing
screen for an individual item. For e.g. refer book 2 page 54.
How Graduated Scales are controlled:
The use of graduated scales is controlled in Customizing for SD. The scale type is entered for the
definition of a condition type. The standard R/3 System includes condition type PR02 (Price with
graduated scale)(Scale Type: D: graduated to interval scale).
Graduated scales are used in prices, discounts and surcharges. However you cannot use graduated
scales for group conditions.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

247
CONDITION SUPPLEMENTS
A Cond Supplement is a supplement for a particular cond type. A cond supplement is a group of
conditions that should be applied every time a certain cond is found.
For e.g., if you define a material price, you would enter cond records for every material. If, for one of
those materials, you also wanted to include a discount every time the price is determined, you can
enter the additional cond type as a cond supplement. When SAP determines the cond record in the
pricing proc, it will automatically also include the discount cond record.
Procedure:
Create the cond type that are to be defined as cond supplements
V/08: create a new pricing proc & list all the conditions that are to form the cond supplement in
this procedure.
V/06: in the cond type that the supplement applies to, enter the pricing proc one has just
defined. Master Data Pricing Proc Field.
Enter the cond record, select line item & Go To Conditon Supplement or just click on Cond
Supplement Icon from tool bar. You can enter the cond supplements for all the cond types
defined in the new pricing proc.
Determination Rule: S.O, Distbn, Div, CuPP, DoPP, New Pricing Proc, Old Cond Type e.g.,
RDIL, RW, GM, A, 1, NEWPR0, PR00.
You can only enter a cond supplement if the cond type you are working with has already been
defined in Customizing for Sales to include cond supplements.
PRICING LIMITS (UPPER & LOWER LIMITS): OVB2
Cond types offer an automatic or manually determined value according to their determination. If it can
be manually altered, it enables the user the opportunity to overcharge or undercharged. For this
reason, we can govern the cond type with limits.
SPRO- IMG- SD- Basic Functions- Pricing- Pricing Control- Define Upper & Lower Limits for Cond.
On the overview screen of the cond record, select the line item and then choose Go To
Details or simply click on Magnifying Glass on the tool bar. Here you can maintain upper &
lower limits.
The cond types calculation type controls the calculation type of the limit.
If during manual processing, you exceed or drop below a defined limit, the system informs you
with an error message.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

248

CONDITION UPDATE
V/06: Go To PR00 details & in the Master Data Check Condition Update.
VK11: Choose the line item & click on Additional Data Icon from tool bar or from the main menu
bar Go To Additional Data
Cond update provides the function for the following pricing functions:
o Maximum value
o Maximum quantity
o Maximum no of sales orders: three
Enter the max value / qty/ number in the max cond value, max cond base value, max no of
orders field
To view the cumulative value, quantity, no of orders for a particular condition record:
Within the condition record, choose Extras Cumulative values.
A dialog box displays the cumulative base value (in this case, the quantity) of sales orders
where this condition record was used.
Within the dialog box, you can branch to the cumulative value of related billing documents or to
a list of the latest sales orders. You can also branch to the individual sales orders.
CONDITION EXCLUSION GROUP
In pricing for sales and billing documents, more than one condition record may apply to a particular item
at any one time. You can use the condition exclusion process to compare possible conditions in order
to determine such things as the best price for a customer.
SPRO- IMG- SD- Basic Functions- Pricing- Pricing Control- Condition Exclusion- Cond Exclusion for
Group of Conditions:
Define cond exclusion group: OV31
Assign cond types to the exclusion groups: OV32
Assign exclusion to pricing procedure: VOK8
A cond exclusion group is merely a grouping of cond types that are compared to each other during
pricing & result in the exclusion of particular cond types with in a group or entire groups. The procedure
according to which the selection is carried out within or between the condition exclusion groups is
defined in the pricing procedure. The following options are possible:
Selection of the most (least) favorable condition type within a condition exclusion group
Selection of the most (least) favorable condition record of a condition type, if more valid
condition records exist (for example, selection from different condition records of the condition
type PR00)
Selection of the most (least) favorable of two condition exclusion groups (in this case, all
condition types of the two groups are cumulated and the totals are compared)
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

249
Exclusion procedure: If a condition type in the first group exists in the document, all condition
types in the second group are set to inactive.
Actions
Create a condition exclusion group by entering an alphanumeric key with a maximum of four
characters and a description.
Allocate the condition types to a condition exclusion group. A condition exclusion group can
contain any number of condition types.
Enter the condition exclusion group in the pricing procedure that you use in pricing (Go to ->
Exclusion groups).
The condition exclusion indicator is not valid for cond supplements. This means if a cond record
contains cond supplements they will be taken in to account during pricing.
After selecting the pricing proc for which you want the cond exclusion to be active, select the
button Exclusion.
Deactivate Exclusion in access sequence when ever you active exclusion group.

Best / Least cond records, with in cond types
Best / Least cond record, between cond types
Best / Least cond record, with in exclusion group
Best / Least cond record, between exclusion groups

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

250

FREE GOODS DETERMINATION: Free goods refer to the process where the business offers
a scheme where the customers can get free goods if they buy certain products of certain quantities

Constraints:
Free goods are currently only supported on a 1:1 basis.
Free goods is not currently supported in combination with material structures (e.g. product
selection, BOM, variants with BOM selection)
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

251
Free goods is currently only supported for sales orders with doc category C (not for quotations,
for e.g.)
Free goods is not currently supported for deliveries without ref to sales order
Free goods are not currently supported for make to order prodn, third party order processing &
scheduling agreements.
The following steps are involved in free goods determination:

Free Goods Determination Procedure:
Menu Path: IMG > SD > Basic Functions > Free goods > Condition technique for free goods.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

252

Determine Item Categories for Free Goods: The Item Category for Free Goods (standard TANN) is
determined as below. The determination combination has Usage as FREE and a Higher Level Item
Category as TAN.
IMG > SD > Basic Functions > Free goods > Determine item categories for free goods items
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

253

Control Free Goods Pricing: IMG > SD > Basic Functions > Free goods > Control free goods pricing

Maintain Copy Control: We maintain the copy controls at item category level. The control with the
'Structure/ New Free Goods' field is most relevant for free goods. Here we can control whether the free
goods should also be transferred when you copy from one order to another, or whether we should re-
determine them.
IMG > SD > Basic Functions > Free goods > Maintain copying control.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

254

Free Goods Condition Data

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

255
Maintaining Free Goods: You can do free goods using condition technique or using condition record. If
you have done free goods via condition technique, to create condition record T.Code: VBN1/2/3.
Go to VK11 and click on free goods icon on the tool bar & enter sales orgn, Distbn & div. Now maintain
the following data
Material: material for which free goods is to be granted.
Minimum Quantity: min qty for which free goods can be granted
From: qty of sales material
Free goods: qty of free goods material
Calculation Type: pro rata, unit reference, whole units
Delivery Controlling
Additional Material: only available for entry in exclusive free goods.
The system automatically calculates the percentage amount of the free goods with regards to
the quantity. If the sales material & free goods use different units of measure, then this
calculation is not possible.
If you do not enter an exclusive free goods material, the system automatically uses the sales
material.
If you want to use scales, select Scales
You can also enter free goods manually by entering item category TANN as the item category in
the double line entry. In this case, however the system will not access the master data & the
control parameters contained there in.
You can change free goods quantity. The system issues an error message if the free goods
exceed the quantity of the material ordered. Other than the qty, no other data is available for
entry in the free goods item.
Subsequent changes to quantities or dates can be made to the main item. This means that free
goods det is carried out again. This means that manual changes to the free goods qty are lost.
You can define different rules for determining the free goods quantity:
o Proportional rule
o Related to no of units
o Only for whole units
Activate free goods determination, if you are using your own sales org.
Bonus Buy
Bonus buys are deals, which grant special prices, discounts or free articles, if certain prerequisites
and general conditions are fulfilled. In the Bonus Buy, Coupons can be assigned as prerequisite.

Coupons in SAP R/3 Retail are treated like articles.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

256

The following steps are involved in configuring bonus buy:

Configuration: IMG > SD > Basic Functions > Bonus Buy
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

257

Bonus Buy Procedure:
IMG > SD > Basic Functions > Bonus Buy
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

258

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

259
ADVANCEED PRICING
Relevance of certain special condition types in Business scenarios:

--&&&&--------

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

260
VA00 It is the condition type to capture discounts for various variants of a product. Variant is the
different types for the same product range for which the price fluctuates. For example, Maruti Zen LXI
and Zen VXI are two variants of the same product line Maruti Zen for which the price differs and so
also any discount offered to them.

KP00 This is a standard discount condition type to capture pallet discount. For example, A company
sells their products in cases. Each of their materials has a conversion factor to pallets. When an order
is placed by a customer, the user would like the system to calculate the number of full pallets for each
line and to offer a 5 USD discount per full pallet ordered. The user sets up condition

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

261
AMIZ This is a condition type for capturing the minimum value surcharge. For example, a company would like
to define minimum order values for their customers. As an example, a minimum order value of 200 USD is
defined for Customer A. If Customer A places an order for anything less than 200 USD (before taxes), the system
should automatically compute a surcharge equal to the difference and apply it to the order. To accomplish this,
the user would configure pre-delivered condition types AMIW and AMIZ in their pricing procedure as defined
above and maintain a condition record for AMIW and Customer A equal to 200 USD.

AZWR This is a condition type to capture the down payment or settlement. Alternative calculation type formula
'48' is delivered to ensure that the down payment amount the user offsets in a billing document does not exceed
the actual down payment value. Condition value formula '48' is assigned to the condition type in the pricing
procedure representing down payments (R/3 delivered condition type AZWR).

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

262

SKTV This is a standard cash discount condition type which is applicable before tax. This is applied
as a group condition and is set as automatic condition.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

263
Understanding certain complex pricing requirements

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

264
Free goods pricing (55) This requirement is met if the item category for the item has the pricing
indicator B Pricing for free goods. 100% discount is applied automatically by the system using the
condition type R100 in the pricing procedure. Requirement 55 should be assigned to this condition
type in the pricing procedure so that it is applied to only free items.
Example
A company has a free goods agreement with their customers. For every 10 cases of Product A that the
customer buys, the customer receives 2 cases of Product B for free. From a pricing perspective, the
user wants to track both revenue and sales deductions for the free items. To do this, the user flags the
free goods item category with the pricing indicator B. In addition, the user adds the condition type
R100 to the pricing procedure at the point at which 100% discount should be applied. The user also
assigns requirement 55 to the condition in the pricing procedure so that it is applied for free goods
items.
Creating customized requirements, alternative calculation type and alternative condition base value
routines In addition to the sap provided requirements, alternative calculation type and base value
routines, we can create our own routines if the pricing demands so.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

265
Creating & Using Pricing Reports
In this activity, we define the screen layout for pricing reports. You use pricing reports to analyze
condition records according to different criteria. Technically, pricing reports are ABAP/4 programs.
T code V/LA

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

266
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

267

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

268
LetMe:
Create a free goods pricing where 2 cases of Product A is offered free with 10 cases of Product
B (Exclusive)

Create a inter-company procedure, where a discount of 40% would be offered in inter-company
billing document

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

269
Help Me:

Additional Info

How to add new fields in the pricing field catalogue

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

270
WORKING WITH CONDITION RECORDS
a) Pricing Reports:
List of existing Condition Records for analysis. Can be Customer-specific.
Method for creating report:
Decide in which view report is to be analyzed by selecting specific fields from existing Condition
Tables
System will generate list of tables which contain at least one of the selected fields
From this list are selected those tables which are to appear in the report.
List Layout is designed.

b) Maintain Condition Records using Pricing Reports:
Condition Records can be maintained using:
Mass Maintenance based on characteristics across all Condition Types & Tables. This can
configured using Area Menus (copy & adapt COND_AV and assigning User)
Using each Condition Types

c) Creating Condition Records with Reference
Multiple Condition Records can be created with reference to existing Condition Records based on Create
with Template. Changes can be made to Rate, Validity Period and additional Sales Data.

d) Changing Condition Records
Master Condition Records can be changed singly or en masse. Changes are recorded by system.

e) Copying Condition Records
Single Condition Record can be copied to create multiple Condition Records based on Copying Rules
(can be modified VOFM).
Single Customer-specific Price Record can be copied based on two rules:
Copy this record onto many customers for same material
Copy this record onto many materials for same Customer.

f) Net Price List
Price information for a Customer for specific materials by simulating Billing Document.

g) Condition Indexes
i) To search for Condition Records that were created for a variety of Condition Types & Condition
Tables e.g. all Condition Records, which apply to a certain Customer or Material.
ii) System can use Condition Index only if it is activated (in Customizing).
iii) System automatically updates Index as it is created.
iv) Update requirement must be specified for each Index.
v) For each Condition Type, it is specified whether system updates Condition Indexes as Condition
Records are posted for the corresponding Condition Type.

h) Release Status: If a condition table is not in release status, then it cannot be used in pricing. So if you
create a new condition table, you should not forget to tick that field on.
If the status is set at 'B', for example, then the corresponding records are taken into account during a
pricing simulation, but are not used in current documents.

The release status can only be maintained directly for agreements (sales deals). For condition records,
this is done via the processing status.
i) One can allow Release Procedure to be used when Condition Table (With Release Status checkbox),
which adds two fields to Table automatically
KFRST Release Status as last key field
KBSTAT Processing Status as non-key field (variable data part)
ii) Set indirectly by defining a Processing status and assigning Release Status to it (in Customizing).
iii) Appears in Condition Record entry, where updating Processing Status field automatically populates
Release Status field.
iv) Four Release Statuses are:
_ : Released
A: Blocked
B: Released for Price Simulation (Net Price List)
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

271
C: Released for Planning in COPA & Price Simulation

i) Changeable Calculation Types
Calculation Type for a Condition Record is determined from the Condition Type. But it can be changed
when Condition Record is being created.

j) Long Texts
Long Texts can be maintained for Condition Records to maintain information about Validity, Approvals
etc. Long Text from Rebates only is copied to the Documents. Texts are not copied when Condition
Records are created with reference.

5) SPECIAL FUNCTIONS
a) Group Conditions
i) Condition Type can be made group Condition. Condition Base Value is calculated as the sum of
individual items in the group so that Condition Scales are applicable to group (e.g. Material Pricing
Group) as a whole even if that scale is not applicable to the individual items. Only those materials
belonging to the Grouping defined in the Condition Type are grouped.
ii) Value of Header Condition Type is automatically split to individual items of the group based on the net
Value. This split can be based on other basis by specifying another routine in the AltCBV field in the
Pricing Procedure. If the Header Condition is not grouped, then the Header value is copied to each
item.
iii) Group Conditions with varying Keys: item qtys are accumulated for scale point determination
purposes but rate for each item is taken from its individual Condition Record. Group Keys are:
Complete Document: All qtys with same Condition Type are accumulated.
For all Condition Types: All qtys are accumulated which belong to Condition Type routine 2
Material Pricing Group: All qtys with same Material Pricing Group and Condition Type are
accumulated.

b) Best Price Using Condition Exclusion
Used to determine the best possible Price (from Customers point of view) from two sets of Condition
Types in a procedure.
i) Assign a set of Condition Types to each Exclusion Group
ii) Assign the two Exclusion Groups to the Pricing Procedure with Comparison Type:
A: All Conditions Records within first Exclusion Group are compared to each other and Condition
with best possible price is chosen. All others are deactivated.
B: All Conditions found for one Condition Type are compared and best is chosen.
C: Total of the Condition Records of first group is compared with that of the second group and
group with the best possible price is chosen. Conditions of the other group are deactivated.
D: If a Condition Record is determined for the Condition Types of first Exclusion Group, Condition
Records of the second Exclusion Group are deactivated.
E: As for B, but worst Condition Record is selected.
F: As for C, but worst Group is selected.
c) Tracking Cumulative Values in Condition Records
Values can be accumulated in Condition Records and tested against limits:
i) Max Condition value
ii) Condition Base Value
iii) Number of Orders.
For this, the field Condition Update in Condition Type has to be checked.
d) Condition Supplements
Condition Supplement Procedure contains group of Condition Types, which are to be accessed together
during Pricing. If the Exclusion Indicator is set for the main Condition Type, the supplementary Condition
Types will be deactivated.
e) Exclusion
Exclusion Indicators can be set either in the Condition Type or the Condition Record. All prices /
discounts below the Exclusion Indicator are ignored (based on the requirements set in the following
Condition Types). It is also possible to create new Exclusion Indicators.
f) Manual Changes / Entries
Conditions can be entered manually in the Sales Document. Also, automatically determined condition
records can be changed manually if allowed in Customizing. It is also possible to prevent manual
changes in Customizing.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

272
In the Sales document, it is possible to check for manual changes by using the Analysis function.
Manual only Condition Types dont have Access Sequences.
g) Header Conditions
Dont have Access Sequences.

h) Pricing Type
Pricing Type controls the New Pricing function in Sales Document & automatically during creation of
Billing Document. Can be done manually and be assigned to copy control.
Pricing Type Description
A Copy Pricing elements and update according to scale
B Carry out new Pricing
C Copy manual Pricing Elements, and new Pricing for others
D Copy Pricing elements unchanged
G Copy Pricing elements and re-determine Taxes
H Copy Pricing elements and re-determine Freight

i) Hierarchy Accesses
Using Hierarchy Accesses reduces no. of Condition Records (else a Condition Table would have to
be created for each combination and all the Accesses would have to be assigned to an Access
Sequence).
In Hierarchy Access, single Access to Condition Table is used.
Consists of Fixed Key Fields (Values Necessary, and at Header level of Condition Record) and of
Optional Fields (Hierarchy Levels and Material itself). Priorities are assigned to optional fields.
Possible for both Customer & Product Hierarchies.
Condition Record is applicable for all records belonging to the hierarchies below that hierarchy only.
So search is initiated at lowest level of the hierarchy and stops when a Condition value is obtained.
j) Data Determination & Data Use
For Pricing, it is possible to determine and use data that is not contained in the document.

k) Special Condition Types

Conditi
on
Type
Categor
y
Header
/ Item
Manual
Gr
ou
p
Remarks
HM00 Price Header Manual Yes
Order Value entered manually. Difference between old
and new order value is distributed between items (based
on net item value). Original Pricing Conditions and Net
Item values are deactivated. Taxes are redetermined.
PN00 Price Item Manual No
Net price for Item. All other Pricing / Discount Conditions
are deactivated.
AMIW Price Item Auto Yes
Min Order value. Statistical Condition. If value of the
order header falls short of AMIW, then AMIW value is
copied automatically as Net Order value. Original Net
Value is deactivated.
AMIZ Price Item Auto Yes
Calculation using Formula = 13 (AMIW - Net Item value).
Is calculated as surcharge on AMIW. Only statistical.
PMIN Price Item Auto No
Min Price for a material. It shows the difference between
the Net value of the Item and the PMIN defined for the
Item in the Condition Records. This PMIN value of the
document is added to the Net Value so that the new Net
Value is increased to match the PMIN of the Condition
Record.
PR02 Price Item Auto No
Price for Items using Graduated Interval scales.
Grouping not possible.
HI01 Discount Item Auto Yes
DIFF Rounding Header Auto No
Determines difference of Order Header Value from the
Rounding Unit and adds to Order value so that it is
rounded.
VPRS Cost Item Auto No Statistical. Is the Cost of the Material from Material
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

273
Master depending on Condition Category (normally G
as per Price Control / S Std / T Mvg)
Profit Margin = Formula 12 (Net Value 2 Cost)
SKTO
Cash
Disc
Item Auto No
Statistical. Cash Discount. Condition Category is E and
is calculated from the first % rate of the Item ToP.
EDI1 Price Item Manual No
Customer expected price, and can be manually entered
or retrieved from incoming IDoc / EDI. Maximum
Deviation is maintained (Calc formula 9). If Price varies
from EDI1 by more that Max deviation, the order is
Incomplete.
EDI2 Value Item Manual No Overall Item Value. Same as EDI1. (Calc formula 8)

8) PROMOTIONS & SALES DEALS
a) Promotions are General Marketing Plan for a product valid for a certain period of time.
b) Various Sales Deals are assigned to Promotions.
c) Each Sales Deal is linked to special Condition Records, which can be used for promotional Pricing or
Discounts.
d) Validity period of the Sales Deals of a Promotion should lie within the Validity Period of a Promotion and
similarly for Condition Records vs Sales Deals.
e) Every Promotion has a number, and this is assigned to a Sales Deal when it is created. In turn, each
Sales Deal has its own Sales Deal number. In the Condition Records, the discounts / special prices are
assigned to the Sales Deal number.
f) Each Sales Deal has a Release Status.
g) The Sales Deal & Promotion numbers appear in the Billing Item.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

274

You can create and use condition indexes to search for condition records that were created for a
variety of condition types and condition tables.
For example, you want to see all condition records that apply to a particular customer or
product.
The activation function displays a list of all available condition indexes and indicates which are
active. The system can use a condition index only when it is activated.
Before you can use the indexes that are delivered in the standard version, you must first activate
them in Customizing for sales.
However, if you create your own indexes, the system automatically activates each new index
when you generate it. In addition, you must specify an update requirement for each condition
index.
You can specify for each condition type you use whether the system updates the condition
indexes when you post condition records for the corresponding condition type.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

275
Release Procedure for conditions

You can allow a release procedure to be used when a condition table is created, by
selecting the With release status checkbox.
This adds the two following fields to the condition table automatically:
KFRST Release status as last key field
KBSTAT Processing status as a field of the variable data part (non-key field)
The release status is predefined. At present the following statuses are defined:
released
blocked
released for price simulation (net price list)
released for planning and price simulation (planning in CO-PA)
The release status is set indirectly by defining a processing status in Customizing for pricing
and assigning a release status to it.
Business Transaction Event 00503303 Maintain Conditions: Transfers is available for defining
individual processing logic for the processing status.
You can also convert old condition records without release indicators to new condition records
with release indicators. A model is provided for this purpose.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

276

The calculation type for a condition type is defined in Customizing. This calculation type
determines how prices or discounts and surcharges are calculated for a condition.
Before Release 4.6, this indicator was copied directly to the condition record.
When creating new condition records, you can now select a calculation type that differs from the
one set in Customizing.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

277

You can assign a rule (blank, A, B) at the sales organization level to determine the sales tax
identification number in the order and billing document (the tax classification determination is linked
to this)
For the status BLANK, the standard priority rules are as follows:
1. If PY has a sales tax ID and a different SP
The tax number and tax classification are taken from PY (the SH is then no longer relevant).
The tax number is determined according to the 'tax destination country'.
2. If 1. does not apply:
If the SH has a sales tax ID or the SP has NO sales tax ID, the tax number and tax classification
are taken from the SH.
3. If 2. does not apply:
Tax number and tax classification are transferred from the sold-to party.
With status 'A', the tax number and tax classification are generally transferred from the sold-to
party. The tax number is transferred according to the 'tax destination country'.
With status 'B': Data is transferred from the payer in the same way as rule A.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

278
27. REBATE AGREEMENTS
What do you mean by Rebate: - Rebate is a special kind of discount, which is paid retroactively to a
customer once he achieves or reaches the sales volumes, in a given period of time?
Rebate agreement: - A Rebate agreement is an agreement between the business and a customer.
The rebate is only relevant if the customer purchases the required sales volume. In rebate agreement,
you specify who receives the rebate payment and on what criteria rebate is based. Ex. Customer,
customer and material etc,.
Rebate agreement type: - The rebate agreement type determines which data the system is to
automatically propose for rebate agreement.
Structure:
You can define the following data in a rebate agreement:
Validity period
Status (whether the agreement is released for settlement)
Rebate recipient (the party who receives the credit memo)
Currency
Method of payment (cheque, bank transfer etc)
Data Defined In Condition Records:
Basis for rebate (customer, customer/ material, rebate group, etc)
Validity period (the validity must lie with in the validity of rebate agreement)
Cond rate
Material for settlement
Accrual rate
Other control data, such as pricing scale type
Prerequisites for Rebate Processing:
Sales orgn: must be relevant for rebate processing
Payer: must be relevant for rebate processing
Billing type: (invoice, credit memo etc) must be relevant for rebate processing
For performance reasons, you should deactivate rebate processing if it is not necessary.

Material for Settlement: In case of customer rebate where there is no material linked, a
dummy material is given as material for settlement.
You may have to create rebates that do not depend on a material, but instead, e.g. on:
A Customer
A Customer Hierarchy
A Group of Materials
You will then need to refer to a material for settlement. The system uses this material when you pay out
the rebate. It does not matter which material type & mat application type you use.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

279
When you create the cond record with in the rebate agreement, the system automatically asks you to
enter the no of material for settlement.
Manual accruals: Instead of posting accruals from the billing documents, manually we can post
accruals through the debit memo. If you activate this field if you want to be able to post manually for this
agreement type.
Reverse accruals:- Whatever manual accruals we have given can be reversed through the reverse
accruals. Mark this field if you want accruals to be reversed when a manual payment is made for a
rebate agreement of this type. The system uses reverses accruals for the amount of the manual
payment. If the cumulative accruals are not sufficient, the system reverses the accruals amount, which
exists.
Relationship to Pricing
Rebates differ from other kinds of discounts in that they are based on sales volume over time
and are paid retroactively.
However, the system processes rebates in much the same way as other kinds of pricing
elements.
Rebate data is saved in condition records.
Controlling for rebate processing is carried out via condition types, pricing procedures and
access sequences.
This control data is defined in Customizing for Sales and Distribution.
Rebate based on Group of Materials:
A rebate group consists of materials to which you want to apply the same rebate. You system
administrator can define rebate group in Customizing for Sales according to the need o f the orgn.
You can assign a material to a rebate group in the MMR: view- Sales, field- Rebate Grp. When you
create a cond record, you must enter a settlement material.

Rebate Agreement Types:
Agreement Type Basis for Rebate Cond Type
0001 Customer / Material % Rebate BO01
Customer / Rebate Group % Rebate BO01
0002 Customer / Material Quantity Dependent BO02
0003 Customer Percent rebate BO03
0004 Customer hierarchy Percent rebate BO04
Customer hierarchy / Material Percent rebate BO05
0005 Sales Volume Independent BO06
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

280
SPRO- IMG- SD- BILLING- REBATE PROCESSING:
Define rebate agreements
Condition type groups
o Define cond type groups
o Assign cond types to cond type groups
Maintain access sequence
Define condition types
Assign condition types to condition type groups
Maintain pricing procedure
o Assign condition type groups to rebate agreement types
Activate rebate processing
o Select billing documents for rebate processing3
o Activate rebate processing for sales organizations
o Activate at customer level.
1. Define Agreement Types:
Copy & rename: 0002 & go to Details
From
To
Reverse accruals: flag it on
Manual Accrual Doc Type: Doc Type (R4) & Billing Doc Type: B4
Verification level: payer, material
Partial payment: Doc Type (R3) & Billing Doc Type: B3
Rebate credit memo: Doc Type (R1) & Billing Doc Type: B1
2. Define Condition Type Groups:
Copy & rename: 0002. Give the same code as given to agreement type.
3. Assign Condition Type to Condition Type Group:
In this activity one needs to assign the cond type from the pricing procedure to the cond type group
found on the rebate agreement type. The sequence no column represents the fields in the cond table
that determines what the system is to use as the basis for rebate. In this e.g., 1 determines that the
cond type should use the fields customer & material. The cond type group 0002 will use pricing cond
type BO02. Before assigning cond type to cond type group, you have to create a cond type.
Cond Technique for rebate processing:
Create cond table
Maintain access sequence
Define cond type: BO02 is the cond type used in pricing, copy & rename.
Assign cond type to cond type group: BO02 to 0002
Maintain pricing procedure: assign cond type BO02 to pricing proc, after total discount & before
freight. Assign Subtotal: 7, Account Key: ERB, Accruals: ERU (keeping reserve money
from customer money), & Requirement: 24 (rebate will get affected in billing doc & not in
sales doc)
The cond type BO02 must use cond class C- expense reimbursement.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

281
The rebate procedure in BO02: indicates if the cond is dependent or independent of sales
volume
The accruals correction proc indicates if accruals must be corrected when this cond type is
accessed.
4. Assigning Cond Type Groups to Agreement Type:
Here you are presented with a list of agreement types as created in the system & you can
assign the relevant cond type group
5. Activate Rebate Processing: at the following levels.
Sales orgn level: activate rebate processing for sales organizations
Billing Document: select billing doc for rebate processing
Customer: active rebate in CMD Sales Area Data, Billing Tab Page.
Billing Document Types
F2 Standard Invoice F1 Order Related invoice
BV Cash Sale B1, B2, B3, B4 Rebate invoices
G2 Credit Memo L2 Debit Memo
S1 Invoice Cancellation S2 Cancel Credit Memo
IV Inter Company Sales
NOTE: - You cannot activate Rebates for Billing document type F5 & F8, since they are proforma
invoices.
Create Rebate Agreements: VBO1
Easy Access- Logistics- SD- Master Data- Agreements- Rebate Agreements- Create
Agreement type: 0002 & press enter. In the over view screen fill the following details:
Rebate recipient: payer no
Currency
Validity Period
Agreement Status: open
Then Go To Conditions Icon & Fill
Material, Rebate Amount, Accruals & save
Then create sales order, delivery, picking, goods issue & invoice
After this in order to see rebate in sales order cycle Go to: VF01 Go to Conditions (item). You
can check rebate in VF01 before saving or else you can also see in VF02.
Rebate Settlement: VBO2
The system uses the accumulated amounts in the rebate agreement to create a rebate
settlement.
The system generates a rebate credit memo request for the rebate payment amount
specified.
There are 3 statuses available for rebate agreements
1. Status A refers to an open rebate agreement.
2. Status B means the rebate is released for settlement.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

282
3. Status C means you have actually executed the settlement. The System creates
a credit memo request for the accrual amount.
You can display the sales volume and drill-down in the rebate agreement.
You can carry out a final settlement for the rebate agreement either:
a. Manually
b. Automatically
c. In the background (batch programs: RV15C001 and RV15C002)
Accruals are reversed as soon as the rebate agreement is settled by credit memo.
Process of Rebate settlement:
Use VBO2 and type in the agreement Number. Change the Agreement Status to B and click on
Final Settlements->Automatic. On doing so, a Credit Memo Request gets created.
Status is set to C. Save it.
A credit Memo Request Number is generated.
Go to VA02 and type in the Credit Memo Request number generated. Remove the Billing Block
and Save it.
Use VA02 to go to Sales Document and Click on Billing. On Saving it, the Credit Memo Request
is now Billed
Go to VBO3 and see the Agreement Status. It would have been set to D, which means that final
settlement of agreement has been carried out.
Important:-
1. When you save the rebate agreement, the system will automatically create a credit memo request.
The system uses this document to create a credit memo. When the credit memo is released, the
accruals are posted to FI.
2. If you have posted accruals manually, but these have not been passed on to financial accounting,
the manual accruals and manual payments in the rebate agreement are blocked.
3. The system can use the sold to party or ship to party as we as payer as the rebate recipient. You
cannot use alternative partner as the rebate recipient, such as alternative payer for the CMD of the sole
to party.

Retroactive Rebate Processing
You can create rebate agreement for which the validity period start date lies in the past. The system
takes into account all the rebate relevant billing documents that were created between the validity start
date & the date you created the rebate agreement. In addition to the credit memo request, the system
creates a correction sales doc (type B2) automatically for this amount.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

283
Create the rebate agreement in the usual way. The system recognizes that the rebate agreement is
retroactive.
Deleting Rebate Agreements:
In the change rebate agreement (VBO2) screen, enter the no of the rebate agreement that you
want to settle. And press enter
Select Agreement Delete, the system prompts you to confirm the deletion.
Press enter to delete the rebate agreement.
Result: the rebate agreement receives status C (settlement created)
Automatically Renewing Rebate Agreements:
Your system administrator is responsible for defining in Customizing for agreement type a calendar for
extending rebate agreements. You can set for each rebate agreement whether it is to be renewed
automatically or not. Select Extras Rebate Calendar Reactivate or Remove in the change rebate
mode.
Renewing Rebate Agreements:
Enter the screen rebate agreements: renewing: Logistics- SD- Master Data- Agreements-
Rebate Agreement- Extend & Choose Enter
The system issues a list of all rebate agreements which were renewed and which the system
could not renew are listed in the log.

Rebate Agreements are discounts paid retrospectively and are based on sales volume generated
by a Customer within a specified time period. They do not appear on the Invoice. Are calculated as
Condition Types in the normal Pricing Procedure assigned to the Billing Document. Are normally
based on Sales Volume, and have scales. Each Rebate Agreement contains Condition Types and
validity period.
h) Rebate Processing:
i) During processing of Rebate-relevant Billing documents, accruals are determined and
posted in FI Accrual Account automatically. Accrual is done at the rate fixed at the beginning
of the Rebate period.
ii) Rebates are calculated based on the Rebate Basis sub-total (Net Value) of the Item during
Billing.
iii) As soon as the Billing Doc is released to Accounting, the Rebate Accrual amount is posted
to FI. Accrual account is credited.
iv) Also the Rebate Basis & Accrual Amount is updated in the Rebate Agreement.
v) For settlement (final or partial), Credit Memo Request is made.
vi) Settlement of Rebate at end of the time period is through a Credit Memo based on the
Rebate Basis (Sales Volume) and the Rebate Rate. Final Settlement can be done
automatically, manually or in background.
vii) Rebate Credit Memo (Settlement) automatically reverses these accruals. Accrual Account is
debited for the Accrual amount. Customer Account is credited for the Calculated Rebate
Amount.
viii) Rebate Status:
A: Open Rebate Agreement
B: Released for Payment
C: Rebate Credit Memo Request
D: Accounting done for Rebate Credit Memo
i) Activating Rebates should be done in all of:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

284
i) Sales Organization
ii) Payer Master
iii) Billing Document type.
j) Creating Rebates:
i) Select Rebate Agreement Type
ii) Rebate Condition Type / Records:
Validity Rebate Base
Value
Rebate Amount Accrual Rates

k) Retroactive Rebates
i) To take into account Billing Documents created before the Rebate Agreement is created.
ii) Rebate basis for the previously created Billing Documents is accumulated and recorded in
the Rebate Agreement. But Accrual amount is not automatically updated and has to be done
manually.
iii) For Billing Documents created after the Rebate Agreement has been created, the Rebate
Basis & Accrual figures are updated automatically.
l) Partial Rebate Settlements
Retroactive rebate agreements allow you to take into account billing documents created before
the rebate agreement is created.
The rebate basis for the billing documents created previously is accumulated and recorded in
the rebate agreement
The accrual amount is not automatically updated for previously created billing documents. This
amount must be entered manually
Rebate-relevant billing documents created after the rebate agreement is created update both
the rebate basis and accrual fields automatically
Partial rebate settlements can be limited for each rebate agreement type as follows:
1. up to the accumulated accrual amount
2. up to the calculated payment amount for the current date
3. unlimited

Accruals are canceled automatically when a credit memo is created, provided that the rebate
agreement type is set accordingly in Customizing

i) Rebate Status must be changed to B (Released for Payment). Can be done for:
Up to accumulated accrual amount
Up to calculated payment amount for current date
Unlimited
ii) Rebate Credit Memo (Settlement) automatically reverses these accruals. Accrual Account is
debited for the Accrual amount. Customer Account is credited for the Calculated Rebate
Amount. For this, Reverse Accruals field in Rebate Agreement type has to be checked.

g) Final Settlement
Final Rebate Payment amount is calculated based on the Final Settlement Amount Amount
already paid. Rebate Settlement Credit Memo is raised for the Final Settlement amount and the
Accrued amount is reversed.
Settlement Material:
You may have a rebate that does not refer to a particular material, but rather to a group of
materials or to a customer. In this case, you must refer to a settlement material in order to
provide information at the material level
Maintain the rebate material in the material master in the Sales and Accounting views
When creating a credit memo, the settlement material is the source for important material
master data, for example, account determination

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

285

28. CREDIT MANAGEMENT
Purpose
Outstanding or uncollectible receivables can spoil the success of the company greatly. Credit
Management enables you to minimize the credit risk yourself by specifying a specific credit limit for your
customers. Thus you can take the financial pulse of a customer or group of customers, identify early
warning signs, and enhance your credit-related decision-making. This is particularly useful if your
customers are in financially unstable industries or companies, or if you conduct business with countries
that are politically unstable or that employ a restrictive exchange rate policy.
Decentralized Credit Management
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

286
If your credit policy requires decentralized credit management, you can define credit data for your
customer for each company code. The customer has a business relationship with two company codes.
You define a currency for each credit control area.
Central Credit Management
If your credit management is centralized, you can combine your company codes in one credit control
area. Credit management then regards the customer as valid for all company codes. The customer has
a business relationship to two company codes that are combined in one credit control area:
A credit limit may be a customers credit limit, which is the permitted limit of value of open items, such
as invoices not yet paid, plus the value of open sales orders.
Credit Exposure: Is the customer's credit exposure may not exceed the established credit limit. The
credit exposure is the total combined value of the following documents:
Open order value : The value of all sales order items which have not yet delivered
Open delivery value: The value of all delivery items which are not yet billed or invoiced.
Open Invoice or billing value: The value of all billing document items which are not yet
transferred to Accounting
Open Items: The open items represent documents that have been forwarded to accounting but not yet
settled by the customer.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

287
Credit Checks:
Simple credit Check: The value of all open items and the net value of the sales order for every item of
a sales document
Automatic credit check: The automatic credit check can target certain aspects during a check and run
at different times during order processing.
This can be,
Static Credit Check: Total value of open sales orders + open deliveries + open billing documents +
open items
Dynamic Credit Check: Total value of open deliveries + open billing documents + open items + open
sales orders for a specified horizon

Credit Management - Configuration

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

288

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

289

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

290

Update group: Basically it is an info structure where system stores all the data about credit limit. The
credit relevant data is updated in an info structure, where it is accessed & updated. Thus each
automatic credit control must be assigned an update group.
The three different update groups and functions are
Update group 000012
Sales order: Increases the open order value from delivery relevant schedule lines
Delivery: Reduces the open order value from delivery relevant schedule lines and
increases the open delivery value.
Billing: Reduces the open delivery value and increases the open billing document
value.
Update group 0000015
Delivery: Increases the open delivery value and increases the open billing document
value.
Update group 000018
Sales order: Increases the open delivery value.
Billing Document: Reduces the open delivery value and increases the open billing
document value.
Credit Master Data T Code: FD32
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

291

Simple Credit Check:
SPRO- IMG- SD- Basic Functions- Credit Mgmt/ Risk Mgmt- Simple Credit Check- Assign Credit Check
to Doc Types.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

292
Based on sales doc types
It will check all the above-mentioned docs & if the credit limit exceeds, the system responds in
the way defined by you in the configuration menu.
Cannot differentiate according to customer
3 ways to Control the Simple Credit Check:
A: warning: The document can be saved.
B: Error message: the document cannot be saved
C: warning message with delivery block: the doc can be saved but is automatically blocked
for delivery.
Automatic Credit Check:
This credit mgmt control is maintained by using the automatic credit control functionality. The automatic
credit control divides the sales doc types, the delivery doc types, & goods issue into specific credit
groups. It also uses the customers risk category as assigned to the CMD of the payer & assigns an
outcome proc to the combination of the above 2 objects, i.e. the credit group & customer risk category
along with the credit control area. The definition of customers risk category is carried out in the fin
accounting module.
A customers risk category is a grouping category that controls the credit check when automatic credit
control takes place. Thus one can assign high-risk customers to risk category for e.g. A01, medium risk
to B01 and low risk to C01.
Automatic credit check divides customers into 3 categories:
High-risk customers,
Low risk customers &
Medium risk customers.
A credit check can only occur at 3 places: Credit Group
Sales order: for high risk customers
Delivery: for medium risk customers
Goods Issue: for low risk customers
Credit Control Area (CCA): highest organizational element in credit management. A credit control
area is an organizational unit that is comprised of one or more company codes. A company code can
have no more than one credit control area. Defined by FI.
Menu Path to create Credit Control Area: OB45: FI people.
SPRO- IMG- Enterprise Stru- Definition- Fin Accounting- Define Credit Control Area
Credit Control Area Description
0001 Credit control area 0001
1000 Credit control area Europe
Menu Path to Assign Company Code to Credit Control Area: OB38: FI people.
SPRO- IMG- Ent Stru- Assignment- Fin Accounting- Assign Comp Code to CCA
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

293
It is possible to assign Credit Control Area to a Sales Area. This is more specific assignment
than the assignment to Company Code.
Company code Company name City Credit Control Area Over write CCA
Menu Path for Defining Risk Categories: OB01: FI people
SPRO- IMG- Fin Accounting- Account Receivables & Payables- Credit Mgmt- Credit Control Account-
Define Risk Categories.
Risk Category CCA Name
001 4500 Low risk
002 4500 Medium risk
003 4500 High risk
Menu Path for defining Credit Groups: OVA6
SPRO- IMG- SD- Basic Function- Credit Mgmt/ Risk Mgmt- Credit Mgmt:
Define Credit Groups: OVA6
Assign Credit Groups to Sales Docs & Delivery Docs
o Credit Limit check for Order Types: OVAK
o Credit Limit check for Delivery Types: OVAD
Define Automatic Credit Control: OVA8
Define Credit Croups: OVA6
One merely creates a credit group for each differentiation in the doc type. You enter the credit groups
when you configure the sales doc types for credit management & define the automatic credit check.
The following credit groups are contained in the standard R/3 system:
01: credit group for sales order
02: credit group for delivery
03: credit group for goods issue
CG (Credit Group) Doc Credit Group
01 Credit group for sales order
02 Credit group for delivery
03 Credit group for goods issue

Assign Sales Documents & Delivery Documents:
Sales Doc Type Descp Check Credit Credit Group
OR Std Order D 01

Define for each sales doc type
Delivery Type Descp Del Credit Group GI Credit Group
LF Delivery 02 03
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

294
whether a credit check should be carried out. Enter D if an automatic credit check should be
carried out.
Specify a Credit Group
Specify a Credit Group for the Delivery Type for which you want to carry out a credit check
Specify a Goods Issue Credit Group for the Delivery Type for which a credit check is to be
carried out for goods issue.
SIMPLE CREDIT CHECK CANNOT BE ASSIGNED TO DOCUMENTS.
Define Automatic Credit Control:
One can now assign settings to the combination of the Credit Control Area, the Customer Risk
Category & the Credit Group.
CCA Risk Cat Credit Group Credit Control
4500 001 01 Low risk sales orders
4500 001 02 Low risk deliveries
4500 001 03 Low risk goods issue
4500 002 01 Medium risk sales orders
4500 002 02 Medium risk deliveries
4500 002 03 Medium risk goods issue
4500 003 01 High risk sales orders
4500 003 02 High risk deliveries
4500 003 03 High risk goods issue
Select line item and go to details, you can decide whether to do Static or Dynamic Credit Check. Credit
Horizon can also assigned here. Additional function checks can be performed here:
A credit check when the maximum document value is exceeded.
A credit check when changing critical fields.
The risk category assignment occurs in the same place as the customers credit limit, which is the
customers credit management screen. That is, the risk category is assigned to the customer by the
Finance in transaction code FD32.
SUMMARY OF CREIDT MANAGEMENT CONFIG STEPS
1. Transaction OB38
Check which credit control area is assigned to the company code.
Company code:
Credit control area:

2. Transaction OVFL
Check which credit control area is assigned to the sales area.
Sales area:

3. Transaction XD02 or VD02
Check which credit control area is assigned to the payer.
Payer:

4. Transaction SE37
Is user exit EXIT_SAPFV45K_001 being used?
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

295

5. Transaction OBZK
For the settings under items 2 - 4, field "All company codes" must be marked in Transaction OB45, or
the credit control area must be entered under the relevant company code in table T001CM of the credit
control areas allowed.
Company code:
Credit control areas allowed:

6. Settings for the credit checks

7. Transaction OVAK
Which settings do exist for the sales document type used?
Sales document:
Check credit:
Credit group:

8. Transaction OVAD
Which settings do exist for the delivery type used?
Delivery type:
Credit group for delivery:
Credit group for goods issue:

9. Transaction OB01
Credit management/Change risk category
Definition of the risk category for each credit control area. You can
use Transaction FD32 to assign this risk category to a credit account.

10. Transaction OVA8
Here, the individual credit checks for key fields
credit control area
risk category
credit group
are set. Take these key fields from the above settings and go to the detail screen. In particular, check
whether fields "Reaction" and "Status/block" are set correctly. To carry out follow-up actions in case of
a credit block, the credit check status must be set (field "Status/block").

11. Transaction FD32
Credit master data for the payer of the relevant document.
Credit account:
Credit limit:
Risk category:
Currency:

12. Settings for updating the credit values
Update of the credit values is required for the limit check (static or dynamic credit limit check).

13. You want the item to be relevant for billing. If an item is not
relevant for billing or for pro forma billing, no update occurs.
14. Transaction OVA7
Update of the credit value is active for the corresponding item type if the check box is marked. This field
corresponds to field "Active receivable" in Transaction VOV7.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

296
Item type:
Active receivable:

15. Transaction V/08, Pricing
In the pricing procedure used for pricing, subtotal "A" must be entered in a line for determining the
credit value (mark the pricing procedure and doubleclick on "Control"). Usually, the net value plus taxes
is used. This way the system is determined to use this subtotal for credit pricing. The credit price is
stored in field VBAP-CMPRE and used for update and credit check.
You can find the used pricing procedure of the order under "Item -> Condition -> Analysis".
Pricing procedure:
Line with subtotal = 'A':

16. Transaction OB45
Which update group (field "Update") do you use in the relevant credit control area? The default setting
is "12". If you use another update group, check whether this is fine with you.
Update:

17. Transaction OMO1
Which kind of update did you choose for structure S066? In any case, "Synchronous update (1)" has to
be chosen as the kind of update. All other settings will lead to errors.

SAP SD Credit Management
All business have their own credit management needs, SAP allows you to specify your own automatic
credit checks based on a variety of criteria. You can also specify at which critical points in the sales and
distribution cycle the system carries out these checks.

SM30 - Table/View

V_TVTW - Define Distribution Channel
V_TVTA_KKB - Assign sales area to credit control area
V_T014 - FI - Define Credit Control Area
T001CM - FI - Assign Permitted Credit Control Area to company code
OVXG - Set up Sales Areas
e.g. Sales Organization
Distribution Channel
Division
Distribution Channel
Division
FD32 - Customer Credit Management

OVAK - Define credit limit check by sales document type

Check Credit
A - Credit limit check and warning message
B - Credit limit check and error message (no sales order can be created)
C - Credit limit check and delivery block (block delivery if hit credit limit)
Options B and C -> used for checking open order values (when you create/change the sales order)
D - Automatic credit control with open order values
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

297
More control in transaction OVA8 - Automatic credit control
You check for open orders and deliveries, or just open deliveries.
or open order values with other options
Credit group
Allows you to combine different sales document types for the credit limit check
VKM1 - Blocked SD Documents - Finance have to released the delivery block
OVAD - Define credit limit check by delivery order

whether the automatic credit check occurs at the time of delivery creation and/or goods issue
OVA7 - Define credit limit check by item category
Set whether to include/exclude item category for credit limit check
OVA6 - Define credit group. You can groups together different business transactions which should be
dealt with in the same manner with regard to the credit check.
You enter the credit groups when you configure the sales document types for credit management and
define the (D - automatic credit check).
SAP default credit groups
01 - credit group for sales order
02 - credit group for delivery
03 - credit group for goods issue
OVA8 - Automatic credit control - Double click on the line items

You can have the followings credit limit check: -

Static
Depends on the customer total value of open orders, deliveries, billing documents and open items.

Open items
No of days open
Overdue open items checks is based on the ratio of open items that are overdue by a certain number of
days.
Max open items %
The customer balance must not exceed a certain percentage.

Oldest open items
If you don't want to deliver to the customer at all when even only 1 invoice is overdue.
Tick the Check for Oldest Open Item and Set the field Days oldest item = 1.
Days oldest item
No of days allowed for overdue or payment terms.

Use of the credit checks Oldest Open Item. If a user attempts to alter the order quantity of a released
sales document
that was previously blocked, it would be reblocked again by the system. The system only reblocks the
sales document if the new order quantity is above a certain % amount.

Released documents are still unchecked
The preset % is whatever you want to set it as when configuring your automatic credit processing. You
enter a deviation % and number of days,eg, you can set it so that an order can be changed by up to 10%
within 30 days of original order entry date without it going back on credit block.

Next Review Date
If a customer has a credit limit of 1000 USD, and you would like to restrict this credit limit only to be
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

298
available in current month (say March). If the document day is in April then the credit limit is zero.
You can use the "Next Review date" and "Number of days" fields and combined it with the "Last
interview" field in customer credit master "Status" view (FD32).

VOKR - Display of work list for credit management (configure the display variant)
The customer credit master record is divided in to 5 views: (FD32)
1. Overview Screen: gives an overview of credit settings in relation to the customer, including his credit
limit, credit exposure, and the % tage of credit limit used, his payment data & his risk category.
2. Address: view gives the customers address details as they appear in CMD
3. Central Data: is a view that shows the total credit limit the customer can receive across all credit control
areas as well as the maximum limit he can receive in one credit control area.
4. Status: view shows the customers actual individual details according to particular CCA being
investigated. This includes his credit limit, percentage used, credit exposure, risk category, whether he is
blocked due to credit or not.
5. Payment history: view displays the payments made by the customer for a particular credit control area
where a comp code is assigned.
Additional checks - in Automatic credit control
Credit check on the basis of the maximum document value:- The sales order value or the
value of goods to be delivered must not exceed a certain value defined for the credit check. The
value is stored in the currency of the credit control area. In particular, this check is useful if the
credit limit of new customers has not yet been specified. This check can be accessed explicitly
by a risk class reserved for new customers.
Credit check when changing critical fields:- The credit check is started when changes are
made to credit-relevant document fields so that they differ from the default values proposed
from the customer master record (terms of payment, value days and fixed value date).
Credit check at the time of the next internal check:- The credit check is started automatically
on a certain date. All sales orders entered up to this time are regarded as not critical.
Credit check on the basis of overdue open items:- The ratio between open items, which are
overdue by more than a certain number of days, and the customer balance must not exceed a
certain percentage.
Credit check on the basis of the oldest open items:- The oldest open item may only be a
certain number of days overdue.
Credit check against maximum allowed dunning levels:- The dunning level of the customer
may only assume a certain maximum value.
Customer-specific credit checks: - If you require further checks to those defined in the
standard system, you can define them in the corresponding user exits (LVKMPTZZ and
LVKMPFZ1).
Static Credit Check Dynamic Credit Check
Open Order Open Order
Open Delivery Open Delivery
Open Billing Open Billing
Open Item Open Item
Compares the total combined values of the
above-mentioned documents to credit limit.
Plus credit horizon. Compares the values of the
following documents to credit limit + credit horizon.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

299
Credit horizon has an attached time period that states that the system is not to include sales
orders in the total of outstanding items created after that specified period i.e. for the purpose of
evaluating credit; you want the system to ignore all open orders that are due for delivery after the
horizon date. Maintained for low & medium risk customers.
Important fields in Automatic credit control settings: -
ITEM CHECK: - If we check this field the system carries out the credit limit check when we enter
the Items. Otherwise the check is carried out while we save the document.
REACTION: - Specifies whether the system reacts with a warning or error message when the limit
exceeds.
STATUS / BLOCK: - If we check this field the document will be blocked for processing, if the limit
is exceeds.
STATIC: - In this check yo7u have two check boxes OPEN ORDERS and OPEN DELIVERIES.
You can flag on as per the clients requirement.
Important Transactions
Transaction code Description
OB38 Assign Company code to Credit Control Area
OVFL Assign credit control area to sales area
XD02 Change Customer (Centrally)
OBZK Permited Credit Control Area for Company Codes
OVAK Sales Order Type Assignment
OVAD Delivery Type Assignment

Transaction Code Description
OB01 Defline Risk Categories
OVA8 Maintain Credit Checks
FD32 Credit Master Data
OVA7 Credit Relevancy of Item Categories
VOV7 Maintain Item Categories
V/08 Maintain Pricing Procedure
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

300
OB45 Define Credit Control Area
VKM4 Release all SD Documents
VKM5 Release delivery documents

Release Blocked Sales Order/ Deliveries:
VKM1: Blocked SD Documents
VKM2: Release SD Documents
VKM3: sales Documents
VKM5: delivery Documents.
VKM4: Sales and Delivery documents.
One can see the offending document. Note on the right hand side, the Status Field. This shows the
check, the doc failed. If this field is empty, the doc did not fail a credit check, even though it may be in
the list of SD documents that are required to be released.
To release the doc, one indicates the doc to be released and then clicks on the Release Button. The
result is the offending doc entry, highlighted green. One then proceeds to save, after which you are
informed the doc number has been released.
NOTE:- Net value with sub total A, in pricing proc, will be the basis for credit limit.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

301
29. INTERCOMPANY SALES & BUSINESS PROCESSING

When the goods in the purchase order have reached the customer, you first enter a sales
order in sales organization 2200. This belongs to the so-called ordering company code
(company 2200).
The plant from which the goods to be delivered are taken is referred to as the delivering
company code (company 1000).
As soon as the order is due for delivery, you create the delivery. The goods issue is posted
at the end of the shipping activity, and the goods are delivered to the customer.
Afterwards, the invoice for the end customer is created in sales organization 2200, that is,
in the ordering company code.
In order for intercompany billing to take place between the two companies involved, the
delivering company issues an internal invoice, through its sales organization 1000, to the
ordering company.
Depending on the agreement between the two connected companies, the entry of receipt of
invoice may take place automatically. If not, the received invoice is entered manually in the
financial accounting system of the ordering company.
An Inter company sale transaction takes place when a sale occurs & the selling sales orgn belongs to a
different company code than that of the delivery plant.
Intercompany business processing describes business transactions, which take place between two
companies (company codes) belonging to one organization. The ordering company orders goods from
a plant, which is assigned to another company code.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

302
Ordering company Supplying company
Company code: 5555 1000
Sale Organisation: 5555 PBIL
Distribution channel: 56 PW
Division: 58 GC
Plant: 5555 1000
Customer: 215 Product: Nimulid
Processing an Intercompany sale:
To create an Intercompany sales transaction proceed with creating the standard sales order. In the
sales order, change the delivering plant at the line item level & create a delivery for the new shipping
point represented for the delivering plant. Proceed with the delivery functions of selecting the packing &
posting the goods issue. Then create an external invoice that will be sent to the customer & create an
Intercompany invoice. That will represent the billing doc between the delivering plant & the selling sales
orgn.
An internal Intercompany invoice can be created by entering the delivery no again for processing when
using the transaction VF01. One can also select the doc due for Intercompany billing by using the
billing due list VF04. When using the billing due list be sure to select the Intercompany-billing doc as
the documents to be used, by checking Intercompany billing.
Definition:
A company arranges direct delivery of the goods to the customer from the stocks of another company belonging
to the same corporate group.
To put in simple terms, Company code A orders goods through its sales organization A from Plant B belonging to
Company code B.
It is imperative that both Plants A & B should have the material. In other words, the material is created for both the
Plants A & B + their respective storage locations.
Sales Organizations and Plants are uniquely assigned to Company codes. It is not possible to assign either a
plant or a sales organization to more than one company code.
Sales organizations and plants assigned to each other need not belong to the same company code.
In other terms, a plant belonging to Company code A & assigned to Sales Organization A can also be assigned to
Sales Organization B of Company Code B. This enables cross company sales.
PARTIES INVOLVED
1) End Customer 2) Ordering Company code 3) Supplying Company Code.
End customer:
Customer who orders goods from the ordering company code.
Ordering Company Code:
Which orders goods from Plant belonging to Supplying Company code through its sales organization and bills the
end customer.
Supplying Company Code:
Supplies goods from its plant to the end customer specified by the ordering company code and bill the ordering
company code.

Pre-requisites for Inter company sales processing
The ordering sales organization and delivering plant must belong to different company codes.
Required combination of Sales Organization and Delivering Plants has to be maintained.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

303
Sales Area-Sales Organization, Distribution Channel and Division, must be assigned to all the plants in
which Inter company sales processing is being carried out.
Inter company Billing Document type must be assigned for required sales document types.
An internal customer number must be created, to represent the ordering Sales Organization, in the Sales
organization representing the delivering plant.
Material must exist in all the plants participating in Inter Company Sales process.
Condition types representing the Inter company sales processing is to be maintained in the pricing
procedure.
Condition records have to be maintained for the required combination of sales organization and plants
CONFIGURATION SETTINGS
Step 1: DEFINE ORDER TYPES FOR INTERCOMPNY BILLING:
Inter company billing document type IV is assigned to all those order document types for which inter company
sales processing can be carried out
Menu Path: IMG-> Sales & Distribution ->Billing->Inter Company Billing-> Define Order Types For Inter Company
Billing.

Step 2: Assign Organizational Units by Delivering Plant:
Sales organization, Distribution Channel and Division are allocated to the plants for which inter company sales
processing is possible. The delivering plant uses these specifications to process inter company billing.
Menu path: IMG/ SD/Billing/Intercompany Billing/Define Order Types for Intercompany billing assign
Organizational units by Plant:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

304

Step 3: Assign Plant to Sales Organization and Distribution Channel:
Sales Organization and Distribution Channel have to be assigned to the Delivering Plant to enable sales
processing.
Menu Path: IMG-> Enterprise Structure->Assignment->Sales and Distribution-> Assign Plant to Sales
Organization and Distribution Channel.

Step 4: Master Data Customer
Create Internal Customer Number By Sales Organization:
A Customer Master record is to be created in the Sales Organization representing the Delivering Plant.
The Internal Customer created represents that Sales Organization belonging to the ordering Company Code.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Master Data -> Customer -> Create.
Code: XD01
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

305

Step 5: Configurations: Define Internal Customer Number By Sales Organization:
The Internal Customer number has to be assigned to the Ordering Sales Organization.
Menu Path: IMG-> Sales & Distribution ->Billing->Inter Company Billing-> Define Internal Customer Number By
Sales Organization

Step 6: Master Data Material: Extend the material in the Delivering Plant:
Enter the Delivering Plant in the material records, which will be relevant for sales processes carried out by the
Ordering Sales Organization.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Master Data -> Products -> Material -> Other
Material -> Change.
Code: MM02
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

306

Step 7: Configurations Condition Type: Creating Inter Company Condition Types:
The delivering plant uses one of the following condition types to bill the sales organization.
PI01 Inter company: fixed amount per material unit
PI02 Inter company: percentage of the net invoice amount.
These condition types specify that the price charged by the delivering plant to the sales organization is shown as
a statistical value in the sales order and an effective charge in the internal invoice.
Menu Path: IMG Sales and Distribution Basic functions Pricing Pricing Control Define Condition
type.
T-code: V/06

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

307
Step 8: Master Data Condition Records: Creating Inter Company Condition Records:
PI01 Inter company: fixed amount per material unit
PI02 Inter company: percentage of the net invoice amount.
Menu Path: Easy Access Logistics ( Sales and Distribution ( Master Data ( Conditions ( Select using
Condition Type ( Create
T-Code: VK11

Transaction Steps
Step 1: Order
Create Order: The ordering Sales Organization prepares the sales order.
The system checks for the company codes and the permissible combinations of the ordering sales organization
and delivering plant, to carry out the Inter Company Billing process.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Sales -> Order -> Create.
Code: VA01

The system automatically carries out pricing a per the pricing procedure assigned to the sales organization. The
inter company charge (PI01/PI02) appears in the conditions screen of the sales order as a statistical value -the
charge has no effect on the final value of the sales order for the customer.
The inter company charge is not printed out on documents for the customer
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Sales -> Order -> Create. Code: VA01
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

308

Step 2: Delivery
The Delivery is created by the Ordering Company from the Shipping Point which is assigned to the Delivering
Plant.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Shipping and Transportation -> Outbound
Delivery -> Create -> Single Document -> with ref to Sales Order.
Code: VL01N

Subsequently, Picking & PGI are carried out

Step 3: Billing
The Ordering Company creates the invoice for the end customer.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

309
The Payer and the Company Code are derived from the Order created by the Ordering Company Code.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Billing -> Billing document -> Create.
Code: VF01

The Company associated with the Delivering Plant bills the Ordering Company thru the means of Inter Company
Billing document.
The Payer and the Company Code are derived from the Order created by the Ordering Company Code.
Menu Path: Easy Access -> Logistics -> Sales & Distribution -> Billing -> Billing document -> Create.
Code: VF01

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

310

FI posting in Intercompany sales process
Company Code Delivering the Material:
1. PGI Stage
COGS - Dr
To Inventory - Cr

2. Intercompany Invoice
Intercompany - Dr
To Revenue - Cr

Company Code which received Sales Order & End Customer Billing:
3. 2nd Effect Entry in Billing Company Code's Books
COS A/c - Dr
To I/C - Cr

4. End Customer Invoice
End Customer - Dr
To Revenue - Cr
To Tax - Cr
Posting of the Inter Company Invoice
Manual posting of the invoice is done after good issue and system prints invoice document with the help of output
type RD00, which is then sent to the end customer. Automatic posting of the inter company billing document
is done via IDOC/EDI. The system uses the output type RD04 contained in the output determination procedure
V40000, which is assigned to internal billing type.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

311

Let Me:
IMG-> Sales & Distribution ->Billing->Inter Company Billing-
Define Order Types For Inter company Billing
Assign Organizational Units by Delivering Plant
Assign Plant to Sales Organization and Distribution Channel
XD01 Create Internal Customer Number By Sales Organization
Define Internal Customer Number By Sales Organization
MM02 Extend the material in the Delivering Plant
V/06 Create Inter Company Condition Types-PI01
VK11 Create Inter Company Condition Records
VA01 Create Order
VL01N Create Delivery
VF01 Create Standard Invoice
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

312
VF01 Create Inter Company Invoice

Step Menu Path / T Code Expected Result
1. Menu Path : IMG-> Sales & Distribution -
>Billing->Inter Company Billing-> Define
Order Types For Inter company Billing
Change View Sales Order for Inter-Company Billing:
Overview screen appears
2. Assign Inter-Company document type IV
against the required order document type
and Save
The system accepts the input and Data is saved
3. Menu Path: IMG-> Sales & Distribution -
>Billing->Inter Company Billing-> Assign
Organizational Units by Plant.
Change View Organizational Units for Internal costings per
Plant: Overview screen appears
4. Assign Sales Organization and Distribution
Channel to the Delivering Plant and Save
The system accepts the inputs and Data is saved
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

313
5. Enter Tcode: XD01 Customer Create : Initial Screen appears

6. Enter the data relevant to represent the
ordering sales organization. Eg:Address,
currency, Delivering Plant, Payment
Terms, etc and Save
System Displays the message Customer XXXX saved
7. Menu Path: IMG-> Sales & Distribution -
>Billing->Inter Company Billing-> Define
Internal Customer Number By Sales
Organization
Change View View for Inter-Company Billing: Overview
screen appears.
8. Assign the Internal Customer created in the
step: 6 to the ordering Sales Organization
and Save
The data gets saved.
9. Enter T code MM02 Change Material (Initial screen) appears
10. Enter the Delivering Plant in the material
records and Save.
System displays message : Material XYZ saved
11. Call Transaction VK11 and enter the
required condition type and maintain data.
Create ZZCC Condition (Fast Entry ) screen appears and the
system accepts and saves the data entered.
12. Call Transaction VA01 Create ZZZZ Sales Order : Initial screen appears
13. Enter Order Type, Sales Organization,
Distribution Channel & Division
Create ZZZZ Order: Overview screen appears
14. Enter Sold-to party, PO no, Material no. ,
Quantity and the Delivering Plant.
The system accepts the inputs and displays the Net Value of
the order on the top.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

314
15. Navigate to GotoItemConditions Create ZZZZ Order : Item Data screen appears
Check condition types PI01/PI02. They do not affect the Net
price of the item.
16. Go back after save the order. System displays the message ZZZZ Order ZZXX has been
saved
17. Call TCode: VL01N Create Delivery: Initial Screen appears.
18. Enter the shipping point and Order no
created in the step 17
Create Outbound Delivery with Order Reference screen
appears
19. Complete Picking and PGI activities and
save the Delivery.
System displays message Delivery No ZZYY Saved
20. Call Tcode: VF01 Create Billing: Initial Screen appears.
21. Enter the Delivery document created in the
Step:19 and Save.
Note the invoice value is based on the sale price derived from
the order document.
System displays the message Invoice ZZFF is saved
22. Again call Tcode: VF01 Create Billing: Initial Screen appears.
23. Enter the same Delivery document created
in the Step:19 and select the billing type as
IV
Intercompany Billing : Overview screen appears
24. Check the Payer, Net Value of the Invoice Internal customer no assigned to the ordering sales
organization in the Step: 8 is displayed as the Payer.
Net Value of the Inter Company invoice is different from the
value of the invoice created in Step: 10.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

315
25. Navigate to GotoItemConditions The net value of the item is based on values of Inter
Company conditions - PI01/PI02.
26. Save the invoice System displays the message Invoice ZZII is saved
Tips and Tricks
For the system to determine another delivering plant for the material in the customer order item,
when entering a sales document:
Ensure that the same delivering/supplying plant is maintained in the Customer material
info record, if any.
The internal customer master for the delivering sales organization must also contain the
same plant.
The delivering company must be created as a vendor to enable posting to the financial document
of the ordering company.

Additional Information:
PRICING:
We need to maintain two pricing procedures RVAA01 & ICAA01. Pricing procedure RVAA01 represents condition
type PR00 & any other discounts or surcharges that are meant for end customer.
We assign Pricing procedure RVAA01 to combination of Sales area (Of Ordering company code) + Customer
Pricing Procedure + Document Pricing Procedure of Sales document type.
This pricing Procedure (RVAA01) is determined both at Sales Order level & Billing processing for the end
customer. We maintain PR00 condition type to represent the ordering company code's price to the end customer.
Condition records for PR00 are maintained using organizational elements of Ordering company code, end
customer & the Material.
Eg: Sales Org. of Ordering company code + End customer + Material.
We also need to maintain PI01 condition type to represent costs to Ordering company code (in other words
revenue to supplying company code). It is statistical condition type & meant for information purpose only.
Condition records for PI01 are created with the following key combination:
Ordering sales Org + Supplying Plant + Material
Pricing Procedure ICAA01is determined at Intercompany billing processing level.
Pricing Procedure ICAA01 - Pricing Procedure for Inter Company billing is assigned to the combination of: Sales
Area (of supplying company code) + Document pricing Procedure of Billing document type IV + Customer Pricing
Procedure of the Internal customer.
Pricing Procedure ICAA01 has condition type IV01 that represents revenues for Supplying company code in the
inter company billing.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

316
PR00 condition type also appears in Intercompany billing document. It is for information purposes only and does
not have bearing on the value of the document.
PI01 represented under pricing procedure RVAA01 is reference condition type for IV01 and the same is defined in
the condition type IV01. Due to this these two condition types represent same value.
The condition type IV01 in inter company billing document represents revenue to the Supplying Company. But its
corresponding condition type PI01 in the billing document to the end customer is shown as a statistical item
meant for information purposes.

Condition Type VPRS in the inter company-billing document indicates cost to the supplying company code.

The use of two different condition types in Intercompany billing is necessary to ensure that data is transmitted
correctly to the financial statement (Component CO-PA).

OBSERVE THE CONDITIONS SCREEN OF THE INTERNAL INVOICE:
IV01 Condition type represents revenue for the supplying company code.
VPRS condition type represents cost to the supplying company code.
PR00 in Inter Company billing document displays amount billed to the end customer. It serves as just an
information item and is inactive.
If the ordering company enters the incoming invoice manually, the delivering company can print out an invoice
document with the help of output type RD00, which is then sent to the Payer.
If automatic invoice receipt has been agreed, we must use the SD output control functions to ensure that output
type RD04 is found in internal billing. In R/3 system, output determination procedure V40000, which includes this
output type, is assigned to Intercompany billing type IV.
The automatic posting to the vendor account is initiated when output type RD04 is processed. The system uses
the EDI output type INVOIC in the FI variant.
To ensure that payables are posted in financial accounts of the ordering company, the delivery company must be
created as a vendor.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

317

30. AVAILABILITY CHECK
Purpose:
When a customer places an order for a material and requests that the material be delivered to him on a
specific date. This delivery date can only be confirmed after ensuring the material availability after
considering all the inward as well as out ward stock movements
The availability check shall happen and take into account the respective activities that must be carried
before a delivery can take place
Similarly the procurement department is also to be informed on the quantities which sales require to be
able to deliver against the orders received. This information can trigger production orders for
manufacture
If sufficient quantities are not available to cover the requirements, purchase orders, can be created in
purchasing on the basis of transfer of requirements planning
Use:
The Availability Check and Requirement Transfer help to determine delivery date for a customer
These also help in determining whether the goods are ready or to be produced or to be procured
externally
Availability Check Overview:
Types of Availability Check
Scope of the Availability Check
Availability Check in Sales Order
Control of Availability Check
Types of Availability Check: There are three types of Availability check
Check on the basis of Available To Promise (ATP) Quantities
The ATP quantity is calculated from the warehouse stock, the planned inward
movements of stock (production orders, purchase orders, planned orders) and the
planned outward movements of stock (Sales Orders, deliveries, reservations). This type
of check performed dynamically in the transaction. Planned independent requirement
are not taken into account here
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

318
Check against product allocation
Product allocation facilitates period-based distribution of products for certain customers
or regions. This type of check is useful in a cases, for example, the production is very
low, customer requirement is high
Check against planning
The check against planning is performed against independent requirements which are
usually created for an anonymous market rather than being customer specific.
Scope of the Availability Check: The following elements can be included in the availability check:
Stock: Safety stock, Stock in transfer, Stock in quality inspection, blocked stock
Inward movement of goods: Purchase orders, Purchase requisitions, Planned orders, and Production
orders.
Outward movement of goods: Reservations, Dependent reservations and requirements, sales and
delivery requirements
Availability Check Sales Order
When you create an order, the system determines the required material availability date on the basis of
the customers requested delivery date. On this date you must begin picking, packing and loading the
goods. Therefore this is the date of significance for requirements planning on which the availability
check should be checked
The following data is required for determining this date:
Route from the shipping point to the ship to party
Shipping point from which the goods are issued
Loading group from the material master record
Weight group determined from the order using the order quantity
Control of Availability Check: The control features specific to Sales and Distribution are:
Checking group: It controls whether the system is to create individual or collective requirements in
sales and shipping processing. The checking group can also be used to deactivate the availability
check. It is proposed in the material master record on the basis of the material type and the plant, and
copied into the sales documents.
Checking Rule: The use of checking rule to control the scope of the availability check for each
transaction in sales and distribution. You also specify the check should including or excluding
replenishment lead time.
Schedule line category: Schedule line category controls whether an availability check and transfer of
requirements should be carried out in the sales documents
Delivery item category: The delivery item category can be used to control whether an availability
check takes place in deliveries.
Transfer of Requirement Overview:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

319
Types of Transfer of Requirements
Control of Transfer of Requirements
Types of Transfer of Requirements
Individual Requirements: A TOR occurs for each sales document that is created. The advantage is
that the source document can be identified by looking in the availability overview for each requirement.
Collective Requirements: Collective requirements combine several document quantities based on
criteria such as Plant, Batch, Storage location, Date, Transaction and Requirements Class. Collective
requirements can either be created daily or weekly. The source documents initiating the collective
requirements cannot be identified directly but can be determined from the list of orders for the material.
Control of TOR: The control features specific to Sales and Distribution need to be maintained in
Customizing:
Requirements Class: The requirements class contains all control features for planning. In
addition, it is specified at a global level whether an availability check is to take place for the
material in the sales and distribution documents on the basis of the ATP quantity (ATP =
available to promise) and whether requirements are to be passed on
Requirements type: The requirements are identified by the requirements type. The
requirements type refers to the requirements class and its control features
Schedule line category: Schedule line category controls whether an availability check and
transfer of requirements should be carried out in the sales documents
Checking group: It controls whether the system is to create individual or collective
requirements in sales and shipping processing.
Prerequisites for Availability Check:
1. The availability check must be switched on at the requirements class level
Menu Path: IMG Sales & Distribution Basic Functions Availability Check & TOR TOR
Define Requirement Classes

2. In order to have availability check in the sales document, the indicator must be set at the
schedule line category level.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

320
Menu Path: Display IMG Sales & Distribution Sales Sales Documents Schedule Lines
Define Schedule Line Categories

3. A requirements type must exist by which the requirements class can be found
Menu Path: Display IMG Sales & Distribution Basic Functions Availability Check & TOR TOR
Define Requirement Types

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

321

Availability Check - Configuration
1. Define Checking Groups:
Use standard SAP checking group 01 for daily requirements and 02 for individual
requirements. In order to create new group, copy an existing group, change the name (ensure
that the name starts with Z) and description to your preference
IMG Sales & Distribution Basic Functions Availability Check & TOR Availability
Check Availability Check with ATP Logic or Against Planning Define Checking Groups

2. Defining Material Block for other users
Tick the Block checkbox to block a particular material from being checked for availability if it is being
checked at the same time by another user. This ensures two users cannot confirm the same quantity
for the same material at the same time.
Check Availability Check with ATP Logic or Against Planning Define Material Block For
Other Users
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

322

3. Control of Availability Check
We indicate what stock in hand, which inward and outward stock movements should be taken into
consideration while carrying out availability check.
The Control group specifies in combination with the checking rule the scope of availability check
Check Availability Check with ATP Logic or Against Planning Carry Out Control For
Availability Check

4. Determining the Procedure for Each Delivery Item Category
Here we have the option for switching off availability check. This option is used for return items.
Check Availability Check with ATP Logic or Against Planning Determine Procedure For
Each Delivery Item Category
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

323

5. Defining the Default Settings
Here we define default setting for each sales area.
Check Availability Check with ATP Logic or Against Planning Define Default Settings

Prerequisites for Availability Check:
1. A checking group must be defined in the Availability Check field in the MRP 3 screen of
the material master.
SAP Menu Sales & Distribution Master Data Products Material Trading Goods MM01
Create
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

324

2. A plant must be determined in the sales order for the line item. It can either be proposed from
the customer material info or customer master or material master or can be proposed manually
in the document
SAP Menu -> Logistics -> Sales & Distribution -> Sales ->Order -> VA01 -Create

Availability Check Order Processing
In the sales menu you select Environment -> Availability Ovw to display availability status for a
material with reference to the plant and checking rule
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

325

During order creation, availability check can be carried out by clicking on the button as shown
in the screenshot. We can also display item availability as shown in the screen shot

Availability Check Delivery Processing:
In the delivery document, we can go to the availability overview screen by using the path: Environment
Availability. The availability overview screen is shown as the second screenshot in the previous slide.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

326

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

327

TOR Configuration
1. Defining the Requirements Classes
Requirements class is the key factor in the TOR. It is based on the requirement types of the sales
document. These requirement classes are also used in PP, so be sure to involve PP and MM in any
changes you envisage in the SD module.
IMG Sales & Distribution Basic Functions Availability Check & TOR TOR Define
Requirement Classes

2. Defining the Requirements Type
The relationship between requirement type and requirements class is many to one.
Requirement Types
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

328

3. Assign Requirements Type
Assign requirement type to the relevant item category in the sales order and the MRP type found on
the material Master Record
IMG Sales & Distribution Basic Functions Availability Check & TOR TOR
Determination of requirement types using transaction

4. Defining Procedure for Each Schedule Line Category
We deactivate a setting at the schedule line level only if it is already set at the requirements
class level.
Procedure For Each Schedule Line Category
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

329

5. Block quantity confirmation in delivery blocks
This enables us to unreserve or not reserves any quantity that has been confirmed for an order for
which a delivery is blocked.
We have the provision of setting this for different reasons and at different transactions
IMG Sales & Distribution Basic Functions Availability Check & TOR TOR Block
quantity confirmation in delivery blocks

6. Maintain Requirements for Transfer of Requirements
In the same way as the requirements used in access sequence, that is, a number of preconditions must
exists of the transaction to be carried out, requirements can be used to determine that the TOR to MRP
is not carried out unless a number of condition are met.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

330
IMG Sales & Distribution Basic Functions Availability Check & TOR TOR Maintain
Requirements for Transfer of Requirements

Create a new checking group by copying 01 and/or 02.
Create a new material by copying C-4000.
Assign the checking group to the new material.
Create sales orders with the data provided in the exercise data slide.
Alter the controls provided in the checking group and other controls as described in the earlier
slides to see how availability check is affected.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

331
Read the information on RLT provided in the Help Me section and through configuration see
its effect on material availability date.
Additional Info:
To check the availability over follow menu path Logistics ->Materials Management ->
Environment -> Stock -> Availability Overview (CO09)An advantage of this availability overview
will show sales order quantity, sales order number, an line item number, and requirement class
for each schedule line for which demand is created.
In case of maintaining requirements (preconditions ) for TOR - the Standard SAP requirement
102 prevents reservations from being carried out in the event of credit block
Replenishment lead time (RLT) is the time that is needed to order or produce the requested
material. Depending on the material type, replenishment lead time can be calculated according
to various time periods. RLT is only included in the check performed on the basis of the ATP
quantity

Availability is only checked up to the end of RLT. If the material availability date (ready for
packing and transporting) is calculated on the basis of the current date to lie after the RLT for
the item, the item itself can be confirmed despite insufficient stock being available.

In this case, the system assumes that any quantity requested by the customer can be procured
by the material availability date and considers the goods to be available.

Availability Check with RLT:
The customer wants 20 units delivered in full by the requested delivery date. Using backward
scheduling, the system determines a material availability date. But no goods are available as the inward
movement of 100 pieces is used up by an outward stock movement. Therefore no stock is available for
the material availability date determined by the system. But since RLT is taken into account, the
material availability date is proposed at the end of RLT

Availability Check without RLT:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

332
If RLT is not to be taken into account in the availability check, the system conducts an unrestricted
availability check. Please see the figure below for illustration. The customer wants 20 units delivered in
full by the requested delivery date.

Backorder Processing: is the processing of a backorder, which in itself is a sales order that has not
been confirmed in full or not confirmed at a certain delivery date.
Rescheduling: is a proposal of how confirmed quantities already assigned to sales orders can be
reassigned to other orders that have a higher priority, such as an earlier delivery date.
ATP: stands for Available to Promise. It is the process of checking the available quantities of a material.
The ATP quantity is equal to warehouse stock plus the planned receipts (incoming stocks). ATP takes
in to account all movements into and out of the warehouse. If selected, it can check the stock examined
for ATP that can be safety stock, stock in transfer, stock in quality inspection, & blocked stock, although
the planned receipts & planned issues of the stock associated with ATP may be purchase orders,
purchase requisition, planned orders, prodn orders, reservations, dependent reservations, dependent
requirements, sales requirements & delivery requirements.
Replenishment Lead Time: (RLT): is the time needed to produce the requested stock. It can be the
time taken by the business to produce a material or the time taken to externally procure the mat from
vendor. This includes goods receipting time. RLT is only used when doing an ATP check. The value of
the RLT for a material is specified on the MMR record.
The RLT for an externally procured material. This is determined based on the total of the
processing time for purchasing, the planned delivery time & the goods receipt processing time.
These setting can be made on the Purchasing & MRP 2 view of the MMR.
The RLT for an internally procured material. This is based on the in house prodn time, found in
the MRP 2 view, & the goods receipt processing time or alternatively on the total replenishment
lead time, which is found in the MMR on the MRP 3 view.
If a sales order is created, there is no available stock, and the ATP check is set to include RLT,
the system will automatically confirm the desired quantity for the end of the RLT based on
whether the material is externally or internally procured. It will still give a confirmed date
according to the end of the lead-time. Should there be partial stock available, the system will
confirm this partial stock available, the system will confirm this partial qty and move the
remaining qty to the end of RLT. Thus it does not do an availability check outside RLT. If the
RLT is three days for a specific material, it will not do an availability check outside of those three
days, as it automatically thinks that it will definitely have the stock on the fourth day.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

333

31. CROSSING SELLING

1. Define Cross-selling Determination Procedure:
IMG > SD > Basic Functions > Cross selling > Define determination procedure for cross selling
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

334

2. Maintain Customer / Document Procedure:
IMG > SD > Basic Functions > Cross selling > Maintain customer/document procedures for
cross selling

3. Define / Assign Cross Selling Profile:
IMG > SD > Basic Functions > Cross selling > Define and assign cross selling profiles
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

335

4. Customer Master data for Cross Selling:
The field, 'PP cust Proc' in Customer Master Data needs to be updated in if the Cross-Selling is to be
active
T Code: VD02

5. Condition Master Data:
You can set up the system so that if a customer orders a specific article, a list of other suggested
articles appears as well.
VB41 Create Cross Selling
VB42 Change Cross Selling
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

336
VB43 Display Cross Selling

32. Batch Management
A batch in the Materials Management system is defined as a subset or partial quantity of a material that
is managed separately from other subsets of the same material. Each batch is identified not only by its
material identification but also by a separate batch number. Typical examples of batches include
different production lots (such as paints, dyes, wallpapers, and pharmaceutical products), delivery lots,
or quality grades of a material.
In Sales and Distribution (SD), it is possible to determine batches that match customer specifications.
Batch determination can be triggered at two points in the process, either when the sales order is
entered, or when the delivery is created.
If you enter a batch number directly into the sales document, the system checks whether its availability
and expiration dates are valid. When you copy a pre-sales document to a sales order, any existing
batch numbers are also automatically copied but cannot be changed in the sales order. If you create a
sales order with materials to be managed in batches that does not have a preceding document, you
can change the batch numbers until subsequent documents, such as the delivery, have also been
created. If, when creating a delivery, the system discovers that the copied batch is not valid, a warning
is issued by the system. In this case, the batch specification must be changed in the sales document
source.
Maintaining Master Data for Batches
If a material is managed in batches, you indicate this fact in the material master record in either the
Purchasing or Plant data/storage 1 views. You can also create and maintain master data for individual
batches, specifying such information as the expiration date, valuation type, and the country of origin. If
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

337
you are planning to use batch split at delivery time, you must also maintain the relevant customer
master records for those customers who permit batches to be split.
Entering Batch Number in Sales Document
Before you can enter a batch number in a sales document, a delivering plant must be entered for the
item. If no delivering plant is entered, the Batch field remains inactive.
You can find the Batch field on the Item overview tab page in the table with the items.
If you do not know the batch number, you can display all the available batches in the delivering plant for
your material, by using the input help.
An availability check is carried out for the batch, which you have entered, and the quantity available is
confirmed.
If no batch number is proposed in the sales order for an item with material to be handled in batches,
automatic batch determination can be carried out in the delivery.
There are four points at which you should use batch determination in Sales & Distribution. These are:
Quotations
Quantity contracts
Sales orders (or scheduling agreement)
Delivery
SPRO- IMG- Logistics General- Batch Management- Batch Determination & Batch Check- Activate
automatic batch det for SD.
In various industry sectors, particularly the process industry, we have to work with homogeneous partial
quantities of a material or product throughout the entire quantity and value chain.
In the SAP system, a batch is the quantity or partial quantity of a particular material or product that is
manufactured according to the same recipe.
A batch is a quantity of any drug produced during a given cycle of manufacture.
The essence of a manufacturing batch is therefore its homogeneity.
Federal Drug Administration in their Good Manufacturing Practice (GMP)
Sap Batch Management process is utilized for Manufacturing Visibility & Execution & Collaboration
In simple terms SAP Batch Handling means an additional keys fields for users to identify the
same materials.
For e.g. Normal Control : Plant + Material + Storage Location
Batch Handling : Plant + Material + Storage Location + Batch Number
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

338

Batch management is a functionality used in EVERY area of industry. It is used mainly in the following
sectors:
Chemicals
Pharmaceuticals
Cosmetics
Hygiene and Sanitation
Food
Retail

Batch functions provide you with the possibility of managing and processing a non- reproducible
production unit in all areas of logistics.
One can follow the batch through the entire logistics chain, from its point of entry into the
manufacturing process through Purchasing, until it leaves the production plant through Sales.
Integration of Batch Management:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

339

Batch is structured under the LO area in the R/3 System which stands for General Logistics.
However it will still require Customizing settings in the respective Logistics area. These are:
Inventory management
Sales and distribution
Process industry
Production
Warehouse management

Batch Management in Logistics:
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

340

Implications to the Inventory:

The batch is a sub set of the inventory quantity.
A batch, by definition is unique and can not be reproduced with the same unique properties.
It is linked to the classification system and can only be used if the classification system has been set up
for Batch Management and prepared properly.
Validity of a Batch Overview:
Batch number assignment is critical for the tracking of a batch material. This unique number is
set (valid) at one of three levels: material/plant; material; or client level. Changes to batch
number validity level require batch reorganization.

Objective: Understand batch number assignment and batch reorganization.
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

341
Validity of the Batch:

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

342

Customizing:

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

343
Batch Number Assignment:
Batch numbers can be assigned manually or allow the system to generate one.
Internal (system generated) number assignment is activated in Customizing for Batch
Management. It is activated at the Client level
A need to generate a batch number can occur due to:
Manual creation of a batch master record.
Goods receipts.
Creation of a process or production order.
Usage decision in Quality Management.
Quality analysis.
Transfer postings (including batch splits)
Classification & Batch Mgmt:
Classification Overview
The SAP Classification system is used to: Find suitable objects, find similar objects, or
find out that no suitable objects exist.
The three main activities within the Classification system are:
Maintaining characteristics and classes
Linking objects to classes and assigning
characteristic values
Finding objects
Characteristics are defined for a specific format either characteristic, numeric, a date, a
currency or a time.
Reference characteristics pull their values automatically from master record fields. No
user maintenance is required
Classes are defined for a specific class type. The class type controls:
the functionality for which the class is intended
the type of objects that it can be used to classify

Objects can be classified via classification transactions or directly through their master
record. (I.e. the classification view of the material master)
In order to do a search a user must know the class to search within. It can be found by:
placing an * in the class field
using search help
exploding the hierarchy graphically
via the characteristics to be used

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

344
Modules That Use the Classification System

Classification & Batch Mgmt:
Material Master and Batch Master:
Batch master records are dependent upon their material master records.
Batch functionality is actuated via the material master record.
Batch classes are assigned to the material master record.
Anytime a batch of that material is posted, the class will be used for capturing
specifications
Batch master records can be created ahead of time or automatically at the time of
posting the goods receipt.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

345
Structure of the Master Records

Material Master and Batch Master

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

346
Integration

Classification of a Batch

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

347
Customizing

Classification & Batch Mgmt
Batch determination is based on the condition technique.
Agreements regarding specifications customers accept are captured in strategy records.
During batch determination the system compares batch specifications to those in the
strategy record.
Two lists can be use to track batches:
The Batch where used list
The Pick-up list
Pricing can be done at either the batch or material level.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

348
The Principle of Batch Determination

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

349

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

350

Lists for Tracking Batches
SAP provides reports for tracking the movement of batches into a company, through
production and ultimately to the customer.
The Where-used List
This report tracks batches by material documents.
The material can be tracked from procurement, through production and ultimately to the goods
issue to a customer.
Information can be displayed in top down (what batches were used in the production of this
material) or bottom-up (what materials used this batch.)
One can select the following documents based on a batch number:
Billing document
Sales order
Scheduling agreement
Delivery note.

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

351
Use of Batch Determination in Sales and Distribution
There are four points at which you should use batch determination in Sales & Distribution.
These are:
Quotations
Quantity contracts
Sales orders (or scheduling agreement)
Delivery
Batch Determination in Sales Orders
One should choose batch determination in sales orders when customer requirements take
precedence over all other factors (such as stock removal strategies, for example). Use batch
determination here, if a customer, for instance, requires a material with certain set
specifications.
One should use batch determination for the sales order to find batches for set specifications.
You can also reserve batches, as requirements are transmitted via the sales order in the same
way as they are via the quotation.
Batch Determination in Delivery
One should choose batch determination in deliveries, if
dealing with materials that are constantly available (mass production)
You want to minimize capital lockup
The specifications are not very detailed (e.g. if you require batches that may not be sold
in the USA but in Asia, or batches that are suitable for whole customer groups)
The expiration date, or the remaining shelf life are the most important criteria
Batch splits are necessary
Transactions
A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

352

A
p
p
s
T
w
o
_
S
A
P
_
O
2
C
_
R
P

SD Study Material Part 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SD Study Material Part 1

Uploaded by

Copyright:

Available Formats

1

You might also like