Full Form's: SAP-SD Notes

SAP-SD Notes
1. Full Form’s
SAP - Systems, Applications, Products in data processing
ERP - Enterprise Resource Planning
ECC – ERP Central Component
SPRO – SAP Project Reference Object.
LSMW –Legacy System Migration Workbench
EDI - Electronic Data Interchange
IDOC - Intermediate Document
2. SAP Use
SAP (System Application and Product) is the name of the company as well as the
software itself. SAP is the ERP (Enterprise Resource Planning) system that aims to
integrate all the different modules in the company. Also for products allow
businesses to track customer and business interactions.
3. Enterprise structure
Definition >
Sales and Distribution

Define, copy, delete, check sales organization
Define, copy, delete, check distribution channel
Maintain sales office
Maintain sales group
Logistics – General
Define, copy, delete, check plant
Define, copy, delete, check division
Materials Management
Maintain storage location
Logistics Execution
Define, copy, delete, check shipping point
Maintain loading point
Maintain transportation planning point
Assignment >
Sales and Distribution
Assign sales organization to company code
Assign distribution channel to sales organization
Assign division to sales organization
Set up sales area
Assign sales office to sales area
Assign sales group to sales office
Assign sales organization - distribution channel – plant
Assign sales area to credit control area
Business Area Account Assignment

Define Rules By Sales Area
Assign Business Area To Plant And Division
Assign Business Area by Sales Area
Logistics – General
Assign plant to company code
Assign Business Area to Plant/Valuation Area and Division
Logistics Execution
Assign shipping point to plant
4. Sales document type (VOV8) –

SPRO - SD – Sales – Sales doc--Sales doc header--Define Sales Document Types
1) SD document category
The document category controls how the system behaves & it is pre-determined
in SAP and cannot be added to.
A classification for the different types of documents that you can
Process in the sales and distribution system (for example: quotations,
sales orders, deliveries, and invoices).
A Inquiry
B Quotation
C Order
D Item proposal
2) Number range assignment

3) Doc.pricing procedure: A
4) Delivery type assignment /delivery block
5) Billing type assignment /billing block
6) Reference Mandatory
5. Item Category Sales & Determination (VOV7)
SPRO—SD—Sales---sales document---sales document item—define item category
–customize screen
Item cat. Determination for Sales:- Sales document type+ item category group +
usage +Higher level Item category + default Item category + manual item category
Use of- Item category it control how the item is to behave in the document type.
Item category (VOV7) - Item categories are defined to provide additional control
functions for the Sales Documents Flow. For example, the functions of a standard
item are completely different from those of a free-of-charge item or a text item.
how the material behaves from the sales quotation right through to the invoice
TAN – for standard

TAS – for Third party
Item Category control for following -

Schedule line allowed
Item is relevant for delivery
Relevant for weight/volume
Item with active credit function / relevant for credit
Billing relevance: A: delivery related billing
Pricing: X: Standard pricing
ITEM category group (which is define in material master)

NORM – for standard
0002- for configuration
DIEN – for service
BANS – Third party
a) General Item category group-- is mainly used for Inbound Delivery; it is

maintained at the client level.
b)Item category group: A grouping of materials that the system uses to determine
item categories during the processing of sales documents.
Item category group" is valid for respective Sales organisation and Distribution channel
combination only. That means, for different combination of Sales organisation and Distribution
channel(Distribution chain), you can have different "Item category group".
Item category group determines how a material is processed in the sales order.
When processing sales and distribution
documents, the system uses the item category group to determine the item
category and proposes it in the respective document. Item category group is
defined in the Sales Org View 2 of Material Master Record.
Example, in the standard SAP System, the item category group NORM is defined
for materials kept in stock and the group DIEN for services and non-stock material.
6. Delivery Item Category & Determination (0184)
SPRO- IMG- Logistic Execution-Shipping-Delivery- Define Item Category
Determination in Deliveries
Delivery Item Catg. Controls delivery doc.type

It is relevant for picking.
Item cat. Determination for Delivery:- Delivery type+ item category group +
usage +Higher level Item category + default Item category + manual item category
7. Schedule lines (VOV6)

SPRO—SD—Sales---sales document---Schedule Lines
Schedule line determination

Item category and MRP type
Use of - It determines the delivery date and delivery qty.
CP – for MRP
CN – No Material Planning
Schedule line control for following

Delivery block
Movement type
Item relevant for delivery
Delivery scheduling for purchasing requisition
Availability check
Incompletion procedure – 30 Gen. Schedule line, 31 Schedule line with PR.
8. Shipping Point Determination(VL02)
Shipping condition (Sales doc.type & customer master)-Loading Group (Material
Master) – Plant--Default Shipping Point & Manual Shipping Point
9. Plant Determination
St
1 Preference - Customer material Info record
2nd Preference- Customer master
3rd Preference - Material Master
10. Route Determination

a. Departure zone or country of the Delivering plant.
b. Destination zone or country of the Ship to Party.
c. Shipping condition from the customer master (Sold To)/Sales document type
d. Transportation group from the material master.
e. With Weight Group or Without Weight Group
CONFIGURATION
Step: 1
Define Modes of Transport
Path: SPRO - Logistics Execution - Transportation - Basic Transportation Function - Routes -
Define Routes - Define Modes of Transport.
Step: 2
Define Shipping Types
Define Routes - Define Shipping Types
There select New Entries and Assign the Shipping Type (e.g. Road or Train) and Assign Mode of
Transport (Mdtr) and Assign Shipping type Procedure group.
Step: 3
Define Transportation Connection Point
Define Routes - Define Transportation Connection Point.
Step: 4
Define Routes and Stages
Define Routes - Define Routes and Stages.
Select the New Entries and Enter the Details
Then Select the Routes stages and define
Step: 5
Maintain Stages for all Routes.
Define Routes - Maintain Stages for all Routes.
Step: 6
Define Transportation Zone
Route Determination - Define Transportation Zone.
Step: 7
Maintain County and Transportation Zone for Shipping Point
Route Determination - Maintain County and Transportation Zone for Shipping Point.
Select the Shipping point and enter the Country and Transportation Zone
Step: 8
Define Transportation Groups.
Route Determination - Define Transportation Groups
Step: 9
Maintain Route Determination
Route Determination - Maintain Route Determination.
Go to Customer master data.
In Address of General data. Enter the Transportation Zone id. and save
Step: 10
Maintain Weight Group
Route Determination – Define Weight Groups.
11. Storage location Determination

OVL3 Transaction
SPRO/ Logistic Execution / shipping / assign picking location then it will determine
automatically
The shipping point,
The delivering plant,
The storage condition.
Storage location determination check must be activated for the relevant

delivery item category in transaction 0VLP
Configuration at Log.Execution-shipping level & Logistic Gen- Material master
12. Pick –Pack Time & Loading Time
SPRO--Logistics Execution--Shipping--Basic Shipping Functions--Scheduling-Delivery
scheduling and Transportation scheduling---Maintain Durations.
Pick –Pack Time → Shipping Point , Route and Weight Group- Pick pack time
workday & Hours.
Loading Time→ Shipping Point, Route and Loading Group – Gross Loading time & Hours
13. Partner Determination & Setup

SPRO- Logistic General- Business Partner-Customer- Account Group & Number
range
SPRO-Financial Accounting (New)- Accounts Receivable and Accounts Payable-
Customer Accounts-Master Data-Preparations for Creating Customer Master Data-
Define Screen Layout.
SPRO –SD-BF-Partner determination
Account group
SPRO- Logistic General- Business Partner-Customer –Account Group.
Use of - It controls:
i) Number range ( we can give separate number range based on Account
group)
ii) Whether the account is a one-time account
iii) Which fields are displayed when you enter or change customer master data
and whether or not an entry must be made in these fields (field status)
Note: Partner Determination Configuration

B) Partner Determination Set up & configuration
SPRO –SD-BF-Partner determination
Business transactions may have one or more partners involved in the transaction.
For example,
Sold to party (SP) - Customer that placing the order
Ship to party (SH) – Responsible for receiving the delivery of material, Goods.
Bill to party (BP) – Customer that receive the Invoice copy.
Payer (PY)– Customer responsible for payment of invoice amount
Account Group Partner det.proc. Partner function
0001 AG- sold to party SP
0002 WE-Ship to party SH
0004 RE- bill to party BP
0003 RG- Payer PY
Partner determination may be defined for the following activities

Set Up Partner Determination for Customer Master
1. Partner det.proce.- AG,WE,RE,RG
2. Assign partner det. Proc (AG) to Partner Function(SP)
3. Assign partner det. Proc (AG) to Account Group (0001)
4. Assign Partner Function (SP) to Partner type (KU-customer)
5. Assign Partner Function (SP) to Account Group (0001)
6. Partner function conversion (LanguageEN,Partner Function, partner des)
Set Up Partner Determination for Sales Document HEADER

1. Partner det.proce.- TA ( Standard order)
2. Assign partner det. Proc (TA) to Partner Function(SP)
3. Assign partner det. Proc (TA) to Sales document (ZAMO)
Set Up Partner Determination for Sales Document ITEM

1. Partner det.proce.- N (Standard Item)
2. Assign partner det. Proc (N) to Partner Function (SP)
3. Assign partner det. Proc (N) to Item Category (ZATN)
Set Up Partner Determination for DELIVERY

1. Partner det.proce.- LF (Delivery note)
2. Assign partner det. Proc (LF) to Partner Function (SP)
3. Assign partner det. Proc (LF) to Delivery Type (LF)
Set Up Partner Determination for SHIPMENT

1. Partner det.proce.- TR (Shipment header gen.)
2. Assign partner det. Proc (TR) to Partner Function (TR)
3. Assign partner det. Proc (TR) to Shipment Type (ZNSK)
Set Up Partner Determination for Billing Document HEADER

1. Partner det.proce.- FK (Header Item)
2. Assign partner det. Proc (FK) to Partner Function (SP)
3. Assign partner det. Proc (FK) to Billing Type (ZAMO)
6. Partner function conversion (Language EN,Partner Function, partner des)
Set Up Partner Determination for Billing Document ITEM

1. Partner det.proce.- FP (Billing Item)
2. Assign partner det. Proc (FP) to Partner Function (SP)
3. Assign partner det. Proc (FP) to Billing Type (ZAMO)
Deactivate Multi ship to Pop up at sales order level.

SPRO->CRM->Basic functions->Partner processing->partner determination procedure-
>choose your partner procedure and then select partner function ship to party and add changes
as shown below screen shot.
14. Output determination
An output is a form of media from the business to one of the business partners.
Some output media forms are printouts, faxes and telexes, e-mails, electronic data
interchange (EDI), or
even XML or HTML. The output can be sent to any of the partners defined in the
document.
Outputs are usually media in the form of order confirmations, delivery notes,
invoices,and shipping notifications.
SPRO>Sales and Distribution>Basic Functions>Output Control>Output

Determination
Maintain Output Determination for Billing Documents
Maintain Output Types
Assign Output Types To Partner Functions

Maintain Output Determination Procedure and assign output condition type in it.
Assign Output Determination Procedures to billing type
VV11 – Default output master for Sales

VV21- Default output master for Delivery/Shipping
VV31- Default output master for Billing
15. Material Determination – Tr. code - VB11

Material determination uses the condition technique to substitute one material in
the sales order for another when certain conditions are met
Activate Material det. in Sales Order →Environment→Analysis→Material

determination→On/Off
SPRO → Sales and Distribution → Basic Functions→Material Determination
Following steps follow for configuration.

a. Put the fields you will need into the field catalog.
b. Create the condition tables you will need.
c. Create the access sequence you will need.
d. Assign the condition tables to the access sequence.
e. Create the condition types.
f. Assign the access sequence to the condition types.
g. Create the determination procedure (if necessary) and assign the condition types
to it.
h. Assign the determination procedure to sales document type.
i. Lastly create your condition record thru T-code VB11.
16. Availability Check and Transfer of Requirements

RLT – Replenishment lead time (means consider the i.GR processing time
(purchasing tab), ii –planned delivery time (MRP1) ,iii- GR processing time MRP-2)
This check available in Availability check control/checking rule OVZ9 tcode
i) Daily requirement means the system will carry out availability check for the
orders created at the end of the day and confirm the quantities.
ii) Individual requirement means for each sales order you create, system will
carry out Availibility check and proposal of quantities will happen
accordingly.
It depends on the basis of:

- Checking group
- Checking rule
- Requirement type and requirement class.
- Settings at SLC level.
While carrying out AvC, the system first checks the Latest receipts, then Purchase Orders and
then to Stock availaible (if not reserved to any other SO) and then it'll confirm the Quantities.
SPRO→ SD→ BF→Availability Check and Transfer of Requirements→Avai.Check
There are three types of availability check:

Check on the basis of the ATP quantities
Check against product allocation
Check against planning
Availability Check Criteria

When SAP SD Availability Check is executed, it checks material’s availability on
certain parameters. Following are the parameters on which the SAP system checks
whether the desired date of delivery of the customer can be met:
i) Order Date – the date on which the customer orders the goods to be
delivered on a certain date
ii) Material Staging – the lead time required to prepare the goods for
dispatching; also includes the picking and packing time
iii) Transportation Planning – lead time required to arrange logistics and time
required to deliver the goods at the customer’s premises
iv) Loading – the lead time required for making final arrangements to dispatch
the product to the customer including the time required to complete
picking and packing
v) Goods Issue – the date on which the goods should leave the plant and the
lead time required for dispatching the goods to the customer and the
transit time when the product reaches the customer at his premises
vi) Required Delivery Date – the date requested by customer for the ordered
goods
Check on the Basis of the ATP Quantities

The ATP quantity (ATP = Available To Promise) 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 is performed dynamically for each transaction, taking into
account the relevant stock and planned goods movements with or without
replenishment lead time. Planned independent requirements are not taken into
account here.
Check against Product Allocation
Product allocation facilitates period-based distribution of products for certain
customers or regions. As of Release 3.0F, you can carry out an availability check
against product allocation. This ensures, for example, that when production is low,
the first customer does not get the full amount, resulting in following sales orders
not being confirmed or being confirmed far too late.
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
(for example, in the strategy ‘Planning without assembly’, when production occurs
only up to the stocking level). The planned independent requirements result from
demand program planning and are used for planning expected sales quantities
independent of orders
Configuration steps →SPRO→SD→Basic Functions→Availability Check and

Transfer of Requirements → Availability Check
Define Checking Groups
Define Material Block For Other Users

Block means :Block indicator for availability and requirements Indicates whether,
during the availability check, the material is blocked for other users. The block
remains until the transaction responsible has been saved. It is set at material-plant
level.
Define Checking Groups Default Value
Carry Out Control For Availability Check ( OVZ9 Tr. Code)
Define Procedure By Requirements Class
Define Procedure For Each Schedule Line Category

Determine Procedure For Each Delivery Item Category
Availabilty check rule A- sales order , B- deliveries .

Define Default Settings
# MRP & TOR → During sales order creation, a line item in the sales order may
create a schedule line. The schedule line represents the customer’s requested
delivery date and quantity to be delivered. This information is transferred (transfer
of requirements) to materials requirements planning (MRP). MRP is then able to
determine if there is enough quantity of stock available for the scheduled delivery
date. The transfer of requirements aims to ensure that the materials ordered are
ready for the requested delivery date.
Transfer of Requirements (TOR)

Essentially, the same control elements are used for the transfer of requirements as
are used for the availability check.
The transfer of requirements is dependent on the following data:

• The requirements class
• The requirements type
• The checking group
• The schedule line category
The Requirements Class →The requirements class is the controlling factor for the
availability check and transfer of requirements for all sales documents types. The
system uses the entries at requirements class level as a default and brings the data
into the sales order. The schedule line category is used to fine-tune the settings at
requirements class level.
The Requirements Type→(In sales order – under procurement tab at item level)
Once the requirements class has been created, you need to define requirements
types. A requirements type is allocated to a single requirements class; however, a
requirements class may be allocated to more than one requirements type. The
requirements type is displayed in the sales order. It is based on the item category
and the MRP type of the material. It is possible to change the requirements type at
the time of creating the sales order.
Determination of requirement types

There is a pre-defined search strategy that the system uses to determine the
requirements type as follows for Availability check
I. First, an attempt is made to find a requirements type using the strategy
group in the material master.
II. Then if the strategy group has not been maintained, the system will
determine it using the MRP group.
III. If, however, the MRP group has not been defined, the system uses the
material type
IV. instead of the MRP group when accessing the corresponding control tables.
V. d. If no requirements type is found, the system assumes a special rule and
attempts to find a requirements type by the item category and the MRP
type.
VI. e. If this is not possible, a final attempt is made to find a requirements type
with the item category only.
VII. If the final attempt fails, the system declares the transaction as not relevant
for the availability check or transfer of requirements.
The Schedule Line Category → The transfer of requirements and the availability
check can be fine-tuned at the schedule line category level. Note that this allows
you to deactivate a setting at the schedule line level only if already set at the
requirements class level.
17. Backward & forward scheduling

• Backward Scheduling : The system calculates requested delivery date
• Forward Scheduling: The system calculates the earliest possible date based on the
material available date
The system calculates backward scheduling as follows:

Formula to calculate date:
Requested delivery date minus transit time = Goods issue date
Goods issue date minus loading time = Loading date
Loading date minus transportation lead time = Transportation scheduling date
Loading date minus pick/pack time = Material availability date
The system will check first backward scheduling, and when confirm date found in
calculation backdated then Forward scheduling logic start.
Backward scheduling is the calculation of deadline dates: the arrival time at the
customer site is calculated as the earliest possible goods receipt time at the
customers unloading point on the requested delivery date. All four of the delivery
and transportation scheduling lead times are subtracted from the customer's
requested delivery date to determine if this date can be met.
The transit time, loading time, and pick/pack time are subtracted from the
customer’s requested delivery date to calculate the required material availability
date.
The system calculates backward scheduling as follows:
Requested delivery date minus transit time = Goods issue date
Goods issue date minus loading time = Loading date
Loading date minus transportation lead time = Transportation scheduling date
Loading date minus pick/pack time = Material availability date
Backward scheduling is always carried out first. If the material availability date or
transportation scheduling date is calculated to be in the past, the system must then
use forward scheduling.
Forward scheduling is also done if no product is available on the material
availability date calculated by backward scheduling. The system does an
availability check to determine the first possible date when product will be available.
This new material availability date forms the starting point for scheduling the
remaining activities. The loading time, pick/pack time, transit time, and
transportation lead time are added to the new material availability date to calculate
the confirmed delivery date.
18. Routines –Control over conditions

Routine nothing but requirement it is developed by abaper. If you want some
condition deactivate in order level order activate in billing level. Or for calculation
formula set through routine.
-Pricing – related to pricing procedures
-Conditions-
-Copy controls
Prcing proc: reqt – pricing routines
Caltype- condition value routines
Bastype- condition base value routines
19. PRICING
Pricing procedure determination →based on combination of Sales area-
Document procedure-Customer pricing procedure- Pricing procedure
SPRO – SD – Basic Function – Pricing - Pricing Control
Elements Used in the Condition Technique

Condition Tables → The condition tables that enable you to store and retrieve
condition records for each of the different condition types.
Access Sequences→ The access sequences that enable the system to find valid
condition records.
Condition Types → Condition types for each of the price elements (prices,
discounts, and surcharges) that occur in your daily business transactions. (You
determine the calculation type for a condition type in Customizing. This determines
how the system calculates prices, discounts and surcharges for a condition)
Condition types are used to define pricing elements such as prices,
discounts,surcharges, or taxes.
Pricing procedures → Group condition types and establish their sequence in pricing
procedures.
Condition table:
i) We can create condition table and select the required fields from field
catalog and if field does not exist then we can add also.
ii) Under technical view tab we can set condition Header or Item wise.
Condition type:
i) If we select Header condition and keep Item condition blank, system will not allow
to assign access sequence. Then you know this condition specially Header
condition.
ii) Based on condition class , the condition type category decide, whether, B basic,D
tax or A discount
Access sequence:
i) Exclusive indicator - in condition technique controls whether the system
stops searching for a record after the first successful access for
a condition type within an access sequence
ii) Requirement routine – whether specific sequence valid only for
domestic-7 or export-8.
Pricing procedure details: there are 16 steps in Pricing Procedure.

i) STEP -This indicates the number of step-in the procedure
ii) COUNTER -This is used to show a second ministep
iii) CONDITION TYPE- This is the most important component in the pricing
procedure. The rates are picked up from this element, on the basis of the
properties described.
iv) DESCRIPTION- This forms the description of the condition type.
v) FROM-This is used to define the progression of the calculation and range of
subtotals
vi) TO- This is used to define the progression of the calculation and range of
subtotals
vii) MANUAL-This function enables to allow the condition type to be entered
manually also apart from automatic pickup.
viii) MANDATORY-This function identifies the conditions that are mandatory
in the pricing procedure. The sales price is a mandatory condition type.
ix) STATISTICS -This can be used to represent the cost price of the material
sold, Not relevant for Accounting.
x) PRINT -The activation of this function will enable the printing of the values
and conditions to the document.
X Printing at item level ( Means Condition type will print at item level)
S Printing at totals level ( Means condition Type will print only at Total)
A Printing at totals level
xi) SUBTOTAL - A key is assigned from the drop down menu; this can be used
by the system in other area like Sis for reporting purpose also
xii) REQUIRMENT Routine – whether the condition type is applicable only for
domestic sale, not export that time we create a routine,
we can deactivate condition for order or some sales area.
xiii) ALTERNATE CALCULATION TYPE Routine– Define formula for
calculation the value base on condition. Final value change alternative
routine. Calculate on the base whether Fix amount /Percentage etc.
xiv) ALTERNATE CONDITION BASE VALUE Routine.-Base value
modification The alternative condition base value is a formula assigned to
a condition type in order to promote an alternative base value for the
calculation of a value.
Create the base and calculate the value
xv) ACCOUNTS KEY
The account keys form part of account determination. These keys are
used here to define the posting of the revenue generated to respective
account heads& to subsequent assignment to GL accounts. Link in
VKOA for revenue
PR00- ERL
K007/KA00- ERS.
KF00- ERF………….& so On.
xvi) ACCRUAL KEY. – For provision account to create Liability.
We can create provision and we can pay that amount once actual bill
received from customer/vendor.
Pricing related Question:

1) How many pricing procedures did you create and why ?
A) Two pricing procedures 1. Standard Pricing procedure 2. Scrap material pricing procedure.
2) What are the conditions used
A) PR00,k004,k0005,R100,KF00,VPRS
3) Any special routines/requirements/formulas developed with Abapers. If yes what was the
business requirement.
A) NO
4) How were the taxes calculated?
A) Tax determination: OVK1
5) Any third party tools like tax wares used for the purposes of tax calculation.
A) No
6) Particularly what discount conditions were used.
A) K004,K005
7) How was the configuration done with FI for account posting.
A) Revenue account determination.ERL key
8) Any new G/L account required if yes how the integration with FI took place.
A) We have to assaign G/L Account in the combination of following
Application(V),Condition type(KOFI),Chart of Accounts, Sales org, Account assignment group
of customer, AAG of material and Account key.
Basis price (Base price) –
20. Account Determination ( VKOA)

i) VKOA – For revenue GL mapping against ERL account key
Access sequence →Cust.Grp/MaterialGrp/AcctKey, Cust.Grp/Account Key,
Material Grp/Acct Key, General and Acct Key
ii) GST tax GL mapped with OB40 against Transaction, Chart of account –
dummy GL maintained against tax code and actual GL triggered from
J_1IT030K_V with combination of tax code- Business area- Actual GL
iii) KOFI → is used for accounting & KOFK – Controlling accounting.
21. Group Condition

Transaction code V/06 – Create new condition type for Group condition with
below mention details .(a) Access Sequence is mandatory (b) Active Group
condition (c) Active Item Condition (d) Maintain Quantity Scale C- it is required
for maintain discount parameter in condition records.
The Group Condition is used to calculate the basis for the scale value for more than
one item in the document
For a group condition to be effective, the items must belong to a group. You can
freely define the group to meet the needs of your own organization. The items can,
for example, all belong to the same material group.
Example
A sales order contains two items. Both items belong to the material group 01.
Material Quantity Material group
A 150 01
B 100 01
In sales order line 10 Qty is 80 & line item 20 Qty is 90, and overall orders Quantity total is
170, hence 2nd condition match & in order Rs.20 discount capture.
22. Condition Exclusion
During pricing in 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-SD-BF-PRICING- Condition Exclusion- Condition Exclusion For Groups Of
Conditions –
I. Define Condition Type ( Discount-Z003)
II. Define Condition Exclusion Groups - e.g. A001
III. Assign Condition types to the exclusion groups –for e.g. A001 to Z003
IV. Maintain condition exclusion for pricing procedures – Condition
exclusion group.
a) Best condition between condition types
b) Best condition within the condition type
c) Best condition between the two exclusion groups
d) Exclusive
e) Least favorable between conditions types
f) Least favorable within the condition type
g) Least favorable between the two exclusion groups
V. Then maintain condition record thru VK11 for that condition type
23. Credit Management
To improve revenues and profit by facilitating sales and reducing financial
risks. ... Controlling bad debt exposure and expenses, through the
direct management of credit terms on the company's ledgers.
a) SPRO - Financial Accounting (New) - Accounts Receivable and Accounts
Payable-Credit Management -Credit Control Account -Define Risk Categories
b) SPRO – SD - BF -Credit Management/Risk Management - Credit Management -

Define Automatic Credit Control
VKM3 – Release sales order from Credit block
Credit Exposure = Total of receivables, special G/L transactions relevant to the

credit limit and outstanding order value.
Credit check happen on Payer (Partner Function)
a. Simple credit check

→ During the simple credit limit check, you can only configure one system reaction
('A' warning, 'B' error, 'C' delivery block) when the credit limit is exceeded. You
cannot use the remaining credit management functions.
SPRO – SD - BF - Credit Management/Risk Management- Simple Credit Limit
Check
b. Automatic credit control

a) Static: Static credit check
The customer's credit exposure may not exceed the established credit
limit. The credit exposure is the total combined value of the following
o Open sales documents

o Open delivery documents
o Open billing documents
o Open items (accounts receivable)
b) Dynamic check
The customer's credit exposure is split into a static part - open items,
open billing, and delivery values - and a dynamic part, the open order
value. The open order value includes all not yet or only partially
delivered orders. The value is calculated based on the shipping date and
the credit horizon you specify in the adjacent field. For the purposes
of evaluating credit, you want the system to ignore all open orders that
are due for delivery after the horizon date. The sum of the static and
dynamic parts of the check may not exceed the credit limit.
c) Credit check against maximum document value
The sales order or delivery value may not exceed the maximum value that
you specify in the adjacent field. The value is stored in the currency
of the credit control area. This type of credit check makes sense, for
example, if you process orders for new customers whose credit limits
have not yet been defined. The check can be initiated by a risk category
which is defined specifically for new customers.
d) Credit check against critical fields (fixed value dates)

If a check is carried out, the following fields are relevant:
o Payment terms
o Additional value days
Fixed value date
e) Credit check against next customer review date

The next credit review date is stored in the credit data in the customer
master record.
When you process a document, the next credit review date must not be
beyond the current date.
f) Credit check against overdue open items

This type of credit check works in conjunction with two values that you
specify in the adjacent fields:
o Maximum % of overdue items in open items
o Number of days which the open items are overdue
The proportion of overdue open items (that exceed the specified number
of days) in the total of open items should not exceed the percentage specified.
g) Credit check against oldest open item

The oldest open item must not be older than the number of days
specified.
h) Credit check against highest dunning level allowed

With this type of credit check, you specify the highest dunning level
you want to allow in the adjacent field. The dunning level is tracked
and stored in the credit data in the customer master record. If this
level is exceeded during order or delivery processing, the system
carries out a credit check.
i) Credit check for customer reserve 1 ( customize Routine)

This field is inactive in the standard system, but can be used for a
credit check you define yourself.
24. Copy control

SPRO-SD- Sales- Maintain Copy Control for Sales Documents
SPRO- Logistics Execution- Shipping- Copying Control
SPRO-SD- Billing- Billing Documents- Maintain Copying Control For Billing
Documents
Copy Control is basically meant so that Data is copied from preceding Document to subsequent
one. What subsequent Document is required is to some extent determined by Customer
Requirements as well as Document Types. e.g. In general case of Standard Order, it will be
Copy Control (Order to Delivery) from OR to LF
As we know there are three types of data in Sales Documents
1. Header Level Data
2. Item Level Data
3. Schedule line Data
And for Delivery and Billing Documents, it will be
1. Header Level Data
2. Item Level Data.
Copy Control Note:

Make sure to maintain copy control for the following areas:
Sales documents / Deliveries / Billing documents
If you cannot find an entry, check the copy controls in other chapters.
Complete overview of copy control:
In the chapter on sales, you can find copy controls for:
Sales document by sales document (VTAA Transaction)
Billing document by sales document (VTAF Transaction)
In the chapter on deliveries, you can find copy controls for:
Sales document by delivery (VTLA Transaction)
In the chapter on billing, you can find copy controls for:
Sales document by billing document (VTFA Transaction)
Delivery by billing document (VTFL Transaction)
Billing document by billing document (VTFF Transaction)
25. Listing & Exclusion (Tr.code- VB01)

Listing means: Specify only the materials which are applicable to the customer.
Exclusion means: The restrict materials which are not applicable to the customer.
SPRO→SD→BF→Listing/Exclusion
If you have specific requirement, then create New Z table.
i)Maintain Access sequence for Listing & Exclusion assign table for this sequence
i.e. table-1 (Customer/Material),
ii)Create Z table as per requirement & assigned to it.
ii)Maintain condition type for Listing & Exclusion and assigned access sequence for
the same.
iv)Define pricing procedure Listing & Exclusion then that condition type assign in
pricing procedure for Listing & Exclusion
v)And after that assign Listing & Exclusion pricing procedure to sales
Document Type.
vi)Create Listing & Exclusion through T-code -VB01
Sales order – Environment-Analysis-Listing /Exclusion –On/OFF
26. Item Proposal Type (Tr.code -VA51)

Item proposal means: regular customer by same palet of material so then you
create Item proposal
If a customer routinely orders the same Material & Quantity, then you can create a
product proposal and enter it in the customer master record. During sales order
processing, the system automatically proposes items from this product proposal.
Menu path→SPRO→SD→Master Data →Item Proposal
1) Define sales document type (PV)
2) Define Number Range
3) Menu path→SPRO→SD→Sales →Sales Document→Sales Document
header→Assign Sales Area to Sales Document Types
4) Create Item Proposal through T-code VA51
5) Then item proposal number assign customer master in sale area data—sales—
item proposal.
6)While creation of sales order enter organizational data→then enter →enter
customer code→then go to EDIT tab→Additional Function→select Propose item→
then select the selection list.
27. Customer Hierarchy

SPRO – SD - Master Data - Business Partners – Customers - Customer Hierarchy-
Define Hierarchy Types
Customer hierarchies represent complex customer structures in the system and
are used for the organizational structures of buying groups or chains of retail
outlets, for example.
Cutomer Hierarchy define → then assign to Assign Account Groups & Assign
Hierarchy Type For Pricing By Sales Document Type
28. Incompletion Procedure
The incompletion procedure identifies which fields are considered incomplete if the
Values are null. (It is the use for which are fields required mandatory)
First define status group & then assign to fields in incompletion Procedure.
Define Status Group – The Status group determines which fields are mandatory for
further processing.
SAP Customizing Implementation Guide→ SD→BF→ Log of Incomplete

Items→
I) Define Incompleteness Procedures
II) Assign Incompleteness Procedures to sales document types/ item
categories/ schedule line categories/ partner functions/ sales activities/
delivery types/ delivery item cate.types.
III) Define Status Groups
29. Rebate Agreement
Rebate means given discount to customer of his completed target total
turnover of sales.
Type of Rebate- & condition standard

i- Group Rebate – B001
ii- Material rebate – B002
iii- Customer rebate – B003
iv- Hierarchy rebate – B004
v- Hierarchy rebate/material – B005
vi- Sales independent rebate
Transaction code:
VBO1 – Create rebate agreement
VBO2– Change rebate Agreement
B – Status is Agreement release for settlement

C – Once you click on Create final settlement button, change will change C
24 is the standard routine, which helps activate condition only at billing level
Steps to be followed to set up a rebate agreement:

1.VBO1-Create a rebate agreement.
2.VA01-Create a Sales Order
3.VL01-Create a Delivery
4.Create Billing document
5.VBO2-Settle rebate agreement
6.Approve settlement- Credit memo request is created
7.VF01-Create Credit note
SPRO - SD - BILLING - REBATE PROCESSING

Define Rebate Sales Document Types (Rebate Credit Memo) Mention A- for
Rebate in block column, Automatic sales order allowed
Define Number Ranges for Sales Documents
Assign sales order types permitted for sales areas
Define Billing Types (Rebate Credit Memo)
Define Number Range for Billing Documents
Maintain Copying Control for Billing Documents (Copying control: Sales document
to billing document)
Define Rebate Agreement Types

Define Number Ranges for Sales Deals (Rebate Agreement)
Condition Technique for Rebate Processing
Field catalog for rebates
Maintain condition tables for rebate
Maintain Access Sequences
Define Condition Types
Maintain Pricing Procedures ( standard routine -24 –Account key ERB & ERU)
Condition Type Groups
Define Condition Type Groups
Assign Condition Types/Tables to Condition Type Groups
Assign condition type groups to rebate agreement types
Account Determination for Rebates
Define Account Key
Assign G/L accounts
Activate Rebate Processing
Select billing documents type for rebate processing
Activate rebate processing for sales organizations
Activate rebate in sales area data for Customer master (Payer)
30. LSMW STEPs

SHDB – Transaction for BDC recording.
There are 14 steps for creating LSMW

31. Sales Processes
a. Consignment Stock Process:

With consignment the business allows stock or materials to sit at the customer’s
site or
allows stock to sit at its own site reserved for the customer. This is done on an
agreement
that the customer will sell or consume as many of these materials as he can.
1- Consignment Fill Up -When the business delivers stock to a customer on

consignment, it is called consignment fill-up -
Order & Delivery, no billing
Order type KB or CF – item cate.KBN, movement 631.
2- Consignment Issue – Order ,Delivery, Billing -- Order type KE or CI – item
cate.KEN, movement 633.
3- Consignment Pick Up – Create order with reference to order Consignment Fill
up. Order type KA or CP – item cate.KAN, movement 632.
4- Consignment Return – Return against Consignment issue billing doc. Order
type KR or CR – item cate.KRN, movement 634.
b. Intra Company STO Process

TYPE of STO Process
a) One Step -- Simple STO plant to plant in MB1B using mvt type 301
b) Two Step-
INTRA STO Process

i) Movement type 641
ii) If Stock transfer within GSTN plant , then material sale through Delivery
Challan, NO GST applicable , SAP provided routine logic
Customer GSTN & Vendor GSTN is same then GST will not capture.
iii) If Stock transfer between different GSTN plant, but in same state, then
material sales through Tax Invoice with GST applicable
iv) Within state CGST & SGST tax is applicable
c. Inter Company STO Process
INTER STO Process
i) Movement type - 641

ii) If Stock transfer between different GSTN plant , then material sales through
Tax Invoice with GST applicable
iii) Inter-state – IGST tax applicable.
STO Process steps

a. STO creation
b. Sending plant create OBD with ref. to STPO ( 641 Movement)
c. Sending Plant create STO Invoice ( delivery challan or Tax invoice)
Intra Customer A/c ----------Dr
To STO clearing A/c------Cr
GST A/c ----------------Cr
d. Receiving plant create GRN (without accounting)
e. Receiving plant run J_1IG_INV for input GST Transfer.
STO Clearing A/c------------Dr
GST A/c-----------------------Dr
To Receiving Plant----Cr
Configuration
a. Both plant create as customer code and Vendor code respectively
b. Customer code assigned in vendor master and vendor code assigned
in customer master
c. In vendor code plant to be assigned (path –vendor code XD03-
Purchasing data-- Extra—Add. Purchasing data – assign plant.
d. Single Sales area to be assign against each plant ( Cannot define
multiple sales area
SPRO—MM--Purchase Order-- Set up Stock Transport Order--Define
Shipping Data for Plants
e. Material master to be extended to sales area
f. Customer master to be extended to sales area
g. Shipping point determination
h. Delivery Item Category determination ( Delivery Type NL & Item
category -NLN
Movement Type –
641 – Transfer stock In Transit
642 – Transfer stock In Transit reversal
d. Intercompany Sale (sales between 2 different

company code)
Movement type 643
i)If “A” company having customer but do not have material in own plant then they
can take material from “B” company.
“A” company will create Intercompany PO and ask material from “B” company
“B” Company will create sales order against PO the material which was asked.
Then create OBD for “A” company and Intercompany Invoice(IV).
“A” company will create GRN and receive the stock against PO.
Then if they want to sell this stock to other customer, then “A” company will create new
sales order / OBD and Tax Invoice.
ii)”A” company having customer but do not have material in A plant, then they ask for B
company
Process
a. A company create sales order & assigned delivery plant of B company
b. OBD ( material out from B company plant)
c. Customer Invoice ( A to customer)
d. Intercompany Invoice – From B to A against same OBD.
Movement Type –
643 – Transfer to cross company
644 – Transfer to cross company reversal
Delivery Item Category determination (Delivery Type NLCC & Item category -
NLC
Intercompany Process steps

a. Intercompany PO creation
b. Sending company create OBD – VL10D
c. Sending Plant create Intercompany Invoice ( IV billing type)
d. Receiving company plant create GRN (with accounting)
Configuration – Inter Company :

1. Intercompany Billing Type – IV
2. Pricing procedure determination while invoicing-OVKK.
3. Copy control – IV (billing Type) to NLCC ( delivery type) to NLC ( Item cat)
4. Enterprise Structure- Assignment – SD—Sales org/ dist.ch/Plant ( cross
company)
5. SPRO- SD-Billing-Intercompany- Define sales Order types for Intercompany
billing
6. Assign organizational units by plant ( Plant /sales org & Dist Cha.)
7. Define Internal Customer Number By Sales Organization ( sales org / Int. Cust)
8. Material to extend both plant and sales area
e. Third Party Process
i- “A” company will create sales order for third party customer; once sales order gets
saved, automatic PR will be create.
ii- With reference to PR - PO will be create ( vendor will be manufacturer)
iii- “B” company will create sales order with reference to PO.( sold to “A” and ship to
customer)
iv- Then “B” company creates OBD against sales order and Invoicing.
v- A company will do the GRN ( Non valuated – stock will not hit)
vi- MIRO ( payment release to B company)
vii- Then “A” company will create Invoice against sales order.
(Received payment from customer)
Billing relevance “F” order related billing status according to Invoice Qty in Item category
Item category – TAS,
Item category Group - BANS
f. Subcontracting Process- (MM_SD)

Process
You can run Subcontracting process in one of the following ways:
With Challan
Without Challan(Invoice)
With Challan or Without Challan

1. Create the subcontracting PO using the transaction ME21N, with item category ‘L’
2. Create the material document with 541 movement type using the transaction
‘MIGO’.
4. Execute the transaction ‘J1IGSUBCON’ against MIGO 541 document
5. In the Processing tab, you can either ‘create challan’ or ‘display’ existing challans.
6. In the next screen, you can select the material document (541 movement type) and
choose the ‘With Challan’ button to create the billing document (Performa invoice).
7. Kindly note user has to take care of create two codes, one is for vendor & another
is for Customer for same party & same needs to assign vice versa before creating
challan.
8. For delivery challan/Invoice print kindly use output type “ZGDL” -Custom
9. Create the goods receipt for the subcontracting purchase order, using transaction
‘MIGO’.
10. Execute MIRO for the invoice verification for the service charges paid to
the subcontractor.
11. For the reconciliation of challans created, execute the transaction ‘J1IGRECON’.
12. There are two options provided for reconciliation:
First In, First Out (FIFO) – It will automatically assign the existing challans to the goods
receipt document
Manual – Enter the GRN number to reconcile the challan for the material document.
11. Once the data is verified, click ‘Save’ to update the reconciliation table.
GR Open Quantity – Goods receipt open

quantity Challan Quantity – Quantity available
in challan
Reconciled Quantity – Challan quantity reconciled against the Goods receipt quantity
GR Remaining Quantity – Remaining quantity of goods receipt after challan
reconciliation Sub. status – Status of the subcontracting challan (F- Fully Reconciled,
P- Partially Reconciled)
CONFIGURATION:
Set up STO -Assign Sales Area to the Supplying Plant
Create Customer and assign customer pricing procedure
Maintain Customer for a Vendor
Maintain this customer number in the Vendor (Subcontractor) master details.
New Billing Document Type
A sales organization, a distribution channel and a division must be assigned to the plant from which the
components are to be delivered
Create New Billing Type ZSP (Invoice) & ZSN ( Challan)
Number range for billing type
Maintain Copy control
Maintain the view J_1IG_V_SUBINV
Pricing procedure
Pricing procedure determination
g. FOC process ( VBN1)
FREE GOODS:
It can be configure in SAP by following two methods
A) Manually B) Automatically
A) Manually:
By specifying higher level item category for a line item, we can determine free goods as a
free of charge items during sale order processing.
B) Automatically:
System proposes free of goods items automatically in the sale order. In automatic free goods
configuration system follows two methods
a) Exclusive b) Inclusive
Exclusive:
System configures free goods in exclusive option by free goods quantity is going to be
excluded in order quantity ex: 10 items, 1 line item is free, then system configures free goods
as a “ten plus one”.
Inclusive:
System configures free goods in inclusive option by free goods quantity is going to be
included in order quantity ex: for 10 items, one item is free, and then system configures free
goods as “Nine plus one”
Note: In exclusive method, other items can be given as a free of charge items for order item
SPRO->SD->Basic Function->Free Goods-> (T-code -VBN1)

i)Condition Technique for Free Goods
1) Number Ranges for Free Goods
2) Maintain Field Catalog
3) Maintain Condition Tables
4) Maintain Access Sequences
5) Maintain Condition Types
6) Maintain Pricing Procedures
7) Activate Free Goods Determination
iii)Determination Item Category -- For Free Goods Item ( TANN)

iv) Pricing Procedure determination
v) Control Free Goods Pricing
1) Control Pricing For Free Goods Item Category
2) Maintain Condition Type For 100% Discount
3) Maintain Pricing Procedure for Pricing ( 55 Requirement & 28 Cond
value base routine)
4) Set Transfer Of Costs To Main Item
iv) Pricing For Inclusive Free Goods Without Item Generation
v) Maintain Copying Control
# - Create Free Goods Determination

VBN1 - Transaction
In Sales Order → go to Environment →Analysis→ Free Goods→click on ON
Item Category TANN.

h. EDI /IDOC’s
EDI, stands for Electronic Data Interchange, is the electronic exchange of

structured business data between different applications.
IDOC (Intermediate Document)

IDoc is an acronym for Intermediate Document. The purpose of an IDoc is to
transfer data or information from SAP to other systems and vice versa. The
transfer from SAP to non-SAP system is done via EDI (Electronic Data
Interchange) subsystems whereas for transfer between two SAP systems, ALE is
used
Middle ware software - If the data is transfer from SAP system to another system, then
middleware software use for data security.
Data management, application services, messaging, authentication, and API

management are all commonly handled by middleware.
For e.g. PIPO (Middleware used for data security)
TRANSACTION CODE LIST

WE30 Used to create the Basic Idoc type
WE20 For creating partner profile
WE81 To create message type
WE82 Used to associate the message type and the idoc type
WE21 To create the port
SM59 To give the name of the logical destination
WE41 To create Outbound Process Code
WE02 To check the status of IDOC, Error we can check
WE05 To check the status of IDOC
WE42 To create Inbound Process Code
BD51 To define the function module characteristics
WE19 Reprocess existing IDOC, new IDOC number will generate
BD87 Reprocess existing IDOC

i. Sales Contract (VA41)
A sales contract is a formal agreement between a buyer and seller for the
exchange of goods, services, or property for payment or promise of payment of a
certain value. A sales contract will spell out certain terms and conditions such
as price and delivery. ... With that said, what should be included in a sales
contract?
A value contract is a legal agreement with a customer that contains the

materials and services that the customer receives within a specified time period,
and for a value up to a specified target value. A value contract can contain
certain materials or a group of materials (product hierarchy, assortment module).
A quantity contract (sales document type CQ) is basically an agreement stating

that the customer will buy a certain quantity of a product in a certain time period.
The contract contains general quantity and price information but no
specifications of the delivery dates and quantities.
j. Sales Scheduling Agreement (VA31)
A scheduling agreement is an outline agreement between Company and a

sold-to party that is valid for a certain period of time. The scheduling
agreement contains fixed delivery dates and quantities. ...
Standard SAP SD scheduling agreements
What is the difference between purchase order and scheduling agreement?

scheduling agreement means long term purchase order. In case u has a
vendor that vendor supplies the material for one year. In scheduling
agreement u give the Delivery schedule for that vendor. ... Purchase
order means we simply procure the material from vendor
32. Text Determination
Text Determination for Sales Document: SAP VOTXN. Text can be used to
exchange the information via documents with a partner and end users. Text can
be created for objects like customer master, sales document header and item,
billing document header and item as well as condition records.
Defining Text Types - SAP Customizing Implementation Guide | Sales and
Distribution | Basic Functions | Text Control | Define Text Types
Text Determination assign at

Sales document Item Category Level / Delivery Type Level / Billing Type Level
The Sales and Distribution module is used in the text determination for the
following
text objects:
Customer - Info Record - Pricing conds - Sales document – Delivery – Billing doc
- Sales Activity –Shipment - Financial Doc – Legal Control – Agency Business –
Trading Contract
We can copy text from customer Master to sales invoice. To copy text from
source Text (customer master) to Target Text (Sales doc Header) object,
then you have to assigned Source text Object & text ID under Target text
object / Text ID and Partner function-SP.
Configuration – (VOTXN)
Create Text ID under text Object VBBK
Create Text determination procedure
Assign text ID in Text Determination
Assign Access sequence in text determination
Assign Text determination to Sales Doc Type/Delivery Type/Billing Type
33. Batch Management

SPRO – SD- Logistic General- Batch management
Always set at client level

SPRO – SD- Logistic General- Batch management-- Batch Determination and
Batch Check—
Condition Tables
Define Sales and Distribution Condition Tables → Create Condition Table
Access Sequences
Define Sales and Distribution Access Sequences→ Create Access sequence and Assign
the table
Strategy Types
Define Sales and Distribution Strategy Types →
a. Create Strategy Type and assign Access Sequence to the Strategy type,
b. Class under Class type 023.
c. Assign Sort Sequence
d. Number of split.
Batch Search Procedure Definition

a. Define Sales and Distribution Search Procedure and assign condition type
(strategy type).
Batch Search Procedure Allocation and Check Activation--

a. Allocate SD Search Procedure/Activate Check
Maintain search procedure by combination of – Sales area / Sales Document
/Search procedure & activate check box for Batch
Activate Automatic Batch Determination in SD

a. Activate Automatic Batch Determination for Delivery Item Categories
Define Selection Classes –023.

Define Sort Rules -
Transaction steps:
a. Transaction - MM01 →Maintain batch class in material master
under classification tab and batch tick activation(purchase tab)
b. Transaction - VCH1 → Maintain condition record to capture batch
automatic while OBD creation.
This will help you for config setting:

Logistics general - Batch Management
1. 1.1. Specify Batch Level

Menu Path Enterprise Structure--> Logistics General--> Batch Management -->
Specify batch level and activate batch status management Transaction OMCT
2. 1.2. Batch Number - Activate Internal Number Assignment
Batch Number Assignment --> Activate internal batch number assignment
Transaction OMCZ
3. 1.3. Batch Creation - for Goods Movements
Creation of new batches --> Define batch creation for goods movements Transaction
4. 1.4. Characteristic Value Assignment -- Update Standard Characteristics
Characteristic Value Assignment --> Update Standard Characteristics Transaction
5. 1.5. Activate Batch Classification for Goods Movements in Inventory Management
Characteristic Value Assignment --> Valuation for goods movements --> Activate
Batch Classification for goods movements in Inventory Management Transaction
OMCV
6. 1.6. Batch Determination – Condition Table(Cross Client)
Batch Determination & Batch Check --> Condition Tables --> Define production order
condition tables Transaction OPLB
7. 1.7. Batch Determination – Condition Table(Cross Client)
Batch Determination & Batch Check --> Condition Tables --> Define SD condition
Tables Transaction V/C7
8. 1.8. Batch Determination – Access Sequence(Cross Client)
Batch Determination & Batch Check --> Access Sequences --> Define Production
Order Access Sequences Transaction OPLF
9. 1.9. Batch Determination – Access Sequence(Cross Client)
Batch Determination & Batch Check --> Access Sequences --> Define SD Access
Sequences Transaction V/C2
10. 1.10. Batch Determination – Strategy Types
Batch Determination & Batch Check --> Define Production Order Strategy Types
Transaction OPLE
11. 1.11. Batch Determination – Strategy Types
Batch Determination & Batch Check --> Define SD Strategy Types Transaction V/C1
12. 1.12. Batch Determination – Batch Search Procedure
Batch Determination & Batch Check --> Define IM Search Procedure Transaction
OMCY
Batch Determination & Batch Check --> Define Production order Search Procedure
Transaction OPLG
Batch Determination & Batch Check --> Define SD Search Procedure Transaction
V/C3
15. 1.15. Batch Determination – Batch Search Procedure Allocation
Batch Determination & Batch Check --> Allocate IM search procedure/activate check
Transaction OMCG
16. 1.16. Batch Determination – Batch Search Procedure Allocation
Batch Determination & Batch Check --> Assign Search procedure to production order
Transaction OPL8
17. 1.17. Batch Determination – Batch Search Procedure Allocation(SD)
Batch Determination & Batch Check --> Allocate SD Search procedure Transaction
V/C5
18. 1.18. Batch Determination – Activate Automatic Batch Determination(SD)
Batch Determination & Batch Check --> Activate Automatic Batch Determination in
SD -->For delivery item categories Transaction V/CL
19. 1.19. Batch Determination – Batch Selection Class
Batch Determination & Batch Check --> Define Selection Classes Transaction CL01
20. 1.20. Batch Determination – Sort Rule
Batch Determination & Batch Check --> Define Sort Rules Transaction CU70
21. 1.21. Batch Determination – Make Settings for Batch Where-used list
Menu Path Enterprise Structure--> Logistics General--> Batch Management --> Make
Settings for Batch Where-used list Transaction OMBB
34. SD_FI_MM INTEGRATION
The link between SD and MM :-
1. When you create sales order in SD, all the details of the items are copied
from Material master of MM.
2. MRP and availibility check related data is also taken from MM although you
control this data in SD also.
3. While you create inbound/outbound delivery with reference to a sales

order,the shipping point determination takes place with the help of the loading
group, plant data, shipping conditions etc. This also refers to Material Master.
4. The material which you are entering in a sales order must be extended to the
sales area of your sales order/customer otherwise you cannot transact with this
material.
There are many such links between SD and MM.
Now the link between SD and FI :-
1. Whenever you create a delivery with reference to a sales order, goods

movement takes place in the bacgground. eg. In case of standard sales order,
you create an outbound goods delivery to the customer.
Here movement 601 takes place. This movement is configured in MM. Also,
this movement hits some G/L account in FI. Every such movement of good s
hits some G/L account.
2. The accounts posting in FI is done with reference to the billing documents

(invoice, debit note, credit note etc) created in SD. Thus this is a link between
SD and FI
3. Tax determination: In case of a tax determination also, there is a direct link

between SD and MM
SD-FI
1. Sales order – No Accounting entry
2. Credit check at sales order level
3. OBD- COGS entry (OBYC - GBB key)
4. Invoice - revenue posting accounting entry( VKOA – Account key)
SD-MM
1. Material determine in sales order
2. Availability check
3. Stock reduce at the time OBD , 601 movement
SD module is highly integrated with the other modules in SAP.
Sales Order – Integration Points Module

•Availability Check - MM
•Credit Check - FI
•Costing - CO/ MM
•Tax Determination - FI
•Transfer of Requirements - PP/ MM
Delivery & Goods Issue – Integration Points Module

•Availability Check - MM
•Credit Check - FI
•Reduces stock - MM
•Reduces Inventory $ - FI/ CO
•Requirement Eliminated - PP/ MM
Billing -Integration Points Module

•Debit A/R - FI/ CO
•Credit Revenue - FI/ CO
•Updates G/ L - FI/ CO
(Tax, discounts, surcharges, etc.)
•Milestone Billing - PS
Return Delivery & Credit Memo -

Integration Points Module
•Increases Inventory - MM
•Updates G/ L - FI
•Credit Memo - FI
•Adjustment to A/R - FI
•Reduces Revenue - FI
35. SHIPMENT Process/ Transportation

Purpose – To generate Transport Vendor liability automatic through service PO.
If we implement shipment process then Service PO and service entry will be

generate automatically at the time shipment cost (VI01) (transfer tab click)
Pricing condition maintain through TK11 for automation.
VT01N – Shipment creation with reference to OBD

VI01 – Shipment cost with reference to Shipment document.
Once shipment cost released in VI02, then system will create auto service PO
and service entry in background, through Service entry the vendor liability will be
generate.
i- Shipment Route to be defined.

ii- Shipment type to be create
iii- Create Shipping condition table
iv- Create shipping access sequence
v- Create Pricing condition type.
vi- Create shipping pricing procedure
vii- Assign pricing condition type into the shipping pricing.
viii-GL will be picked up from tax code with provision ( for liability)
SAP Standard setting for auto service PO & service entry creation
36. GST taxes & Norms.
Benefit of GST Implementation
a. One tax concept in India
b. One tax structure which is helpful to reduce the compliance.
c. Centralize or state wise GST payment according to sales &
purchase.
d. Limited Tax codes based on GST tax percentage.
e. Easy to return file.
Rebate & LUT case for export scenario

a. Rebate –NO BOND/ NO LUT – (Paying GST to Govt.)
b. LUT – Zero rated export (with LUT & with BOND)
Export of goods & services if we have LUT number from Govt.
In case old case (Issue & tax to be paid) then we will pay GST tax
against that old tax amount.
GST Taxes
IGST – Export or Inter state
CGST – Intra state
SGST – Intra State
UGST- Intra state (Union territories)
Tax percentage will be divided in to equal parts.

CGST (9%) +SGST (9%)
CGST (9%) +UGST (9%)
IGST (18%)
Union territories state define by govt. – (9 states include)

Daman / Delhi /Goa / Chandigarh, Dadra and Nagar Haveli –
Silvassa / Pondicherry / Andaman and Nicobar Islands/
Lakshadweep / Jammu and Kashmir/ Ladakh.
37. SAP Project steps
a.ROLLOUT
1. Configuration copied based on standard template.
2. Test data create in Development system.
3. UAT at Quality server
4. All request transfer on Production server.
5. Prepared Legacy data (customer, Material, Open order, delivery, billing) & take
cutoff in system and upload same in SAP system.
b.Upgration ECC 5.0 to ECC 6.0

1. Technical update patch /TAO in sandbox server.
2. End to end business scenario testing.
3. Integration testing.
4. Z table will get inactive, and abaper/basis will do the changes in SPAU
(Program) and SPDD (table)
c. Implementation ASAP methodology
ASAP Implementation Phases
The individual phases of the ASAP Implementation Methodology are:
Phase 1: Project Preparation

During this phase the team goes through initial planning and preparation for SAP
project.
Phase 2: Business Blueprint
The purpose of this phase is to achieve a common understanding of how the
company intends to run SAP to support their business. In Standard ASAP 8 the
result is the Business Blueprint, a detailed documentation of the results gathered
during requirements workshops. In Agile ASAP 8 the result is a Baseline Build
and Project Backlog
reflecting the solution requirements prioritized by business value.
Phase 3: Realization
The purpose of this phase is to implement all the business process
requirements based on the Business Blueprint or Project Backlog. The system
configuration in Standard ASAP is done in two work packages: Baseline
configuration (major scope); and Final configuration (remaining scope). In Agile
ASAP project team splits Realization phase into multiple releases with number of
time-boxed iterations focused on building up the functionality.
Phase 4: Final Preparation
The purpose of this phase is to complete the final preparation (including testing,
end user training, system management and cutover activities) to finalize your
readiness to go live. The Final Preparation phase also serves to resolve all
critical open issues. On successful completion of this phase, you are ready to run
your business in your live SAP System.
Phase 5: Go Live Support
The purpose of this phase is to move from a project-oriented, pre-production
environment to live production operation.
Phase 6: Operate
The primary goal of this phase is to ensure the operability of the solution.
d. Implementation Type
Green Implementation→ Fresh /New SAP implementation against Other ERP
system.
Brawn Implementaion → Up gradation and Reimplementation against existing

SAP.
38. Master Views

Customer Mater
i- General Data
ii- Company Code Data
iii- Sales Area Data
Material Master
i- Basic Data 1
ii- Basic Data 2
iii- Classification
iv- Sales Org.data1
v- Sales Org.data 2
vi- Sales general/Plant data
vii- Foreign Trade Export
viii- Sales & Distribution Text
ix- Purchasing
x- Foreign Trade Import
xi- Purchase Order Text
xii- MRP1
xiii- MRP2
xiv- MRP3
xv- MRP4
xvi- Forecast
xvii- Work Scheduling
xviii- General Plant data 1
xix- General Plant data 2
xx- Quality Management
xxi- Accounting 1
xxii- Accounting 2
xxiii- Costing 1
xxiv- Costing 2
39. SAP Major Issues & Enhancement
1. There are various options at which condition type is considered as Inactive

INACTIVE : A
if Condition is inactive with message as A , then there would be another condition added in the
condition Exclusion ( best condition within two condition types)
INACTIVE : K:
This value is set only in shipment cost document. if there are two condition types for freight in sales
order in which both shared same combination, system will set one of the condition as Inactive with K
INACTIVE : L
condition is set to inactive as L , if the Header condition is not active or set as Header condition
exclusion
INACTIVE :M:
one condition type determined in sales order using Condition record and you also tried to enter manual
price for the same condition type which will inactive condition value triggered with condition record,
in that case , condition type will set as inactive with M
INACTIVE : X
this will result, if any of the routines such as Requirements, alternative calculation type and conditon
base formulas are set correctly or not
INACTIVE: Y
if two or more condition types is determined in the sales order which is valid which have same
properties, then automatically one valid record will be active and all other lower conditions will set as
inactive with Y
for example, if you have one Price with 100$ and other has been enteed manually with 110$, then
system will set price with 100$ to inactive with status Y
So if you want PR00 to be active then set deletion indicator for all other price
condition record in VK12 if it is determined automatically. If manual then dont use
multiple price condition types in your PP.
2. Can we give intercompany billing and customer invoice without manual?
3. Ship to party default if many ship to exist
Deactivate Multi ship to Pop up at sales order level.

SPRO->CRM->Basic functions->Partner processing->partner determination procedure-
>choose your partner procedure and then select partner function ship to party and add
changes as shown below screen shot.
Q. Standard SAP checks forget and not remember.

Right now I am forget the small checks and details, since this are not regularly using.and
I am having 10+ experience and worked with multiple project and multiple organization
with best performance and I feel this type of issues I will slove at the time system will be
in my hand.
Q.Travell continous in the project

If business urgency and critical situation I will manage for short term and ready to travel,
but frequently cannot. Since I am family oriented and I have family responsibility that
will almost my first priority.
Q.Are you ready to Join in short term period?

Sorry to ask you, can you tell me what is your organization notice Period.
If 90days and your organization will not allow employee for early release then how my
current organization will allow me. But still I will try my best.
Q. Ticking Tool- Service Now, BMC remedy

PQR – PRCD
I know what you are asking the question, but actually I worked on these tools for
ticketing resolution, but not aware about details.
I am studying ITIL, these all details coming under ITIL once I will done the study I am
able to give the Answer of your Question.
Change Management
Change Request
Service Request
Q. Can you explain the differences between rush order and

cash sales?
In the case of rush orders, delivery of the order will be done on the
same day while billing will be done on a later date.
Whereas, in the case of cash sales, both billing, as well as delivery or
order, will be carried out on the same day itself.
Q.Can you point out some of the predefined condition types in SAP SD
system?
PR00 – basic / MWST-Output Tax / B002 to B005 – Rebate / K004/K005 - Discount
Q.Can you point out how many types of sales document exist?
There are three distinct types of sales documents which are as under:
• Sales Document Header (VBAK)
• Sales Document Item (VBAP)
• Sales Document Schedule line (VBEP)
Q.Can you explain the five features which can be used to
control the sale document type?
The features you can use to control a sale document type are listed
below:
• Partner• Delivery • Text• Pricing• Taxes• Output
40. Movement Type

601 – Good Issue – Normal Sales
641 – Goods in transit –STO
643 – Intercompany sale
101 – Goods Receipt
201 - GI for cost center
301- TF trfr plnt to plnt
311- TF trfr within plant
321- Quality to unrestricted
453 – return to own
455 – return to own return
457 – return to own QI
501 – without PO
541 - Subcontracting
551/552 – GI/RE scrapping
641 TF to stck in trans.
642 TR to stck in trans.
643 TF to cross company
644 TR to cross company
561- stock upload
701 – stock uploadGR phys.inv.: whse
41. Accounting Entries

Sales and Distribution Accounting Entries
a) At the time of delivery of goods (PGI)
Cost of goods sold account -----------Dr

To Inventory account ----------------Cr
(This entry is passed by the cost of the item delivered)
b) During generation of Invoice
Customer / Debtors account -----------------------Dr

To Sales/Revenue account Cr ----------Cr
GST Taxes -------------------------------Cr
(This entry is passed by the selling price)
EXPORT
Customer A/c----------------Dr
Customer rabate A/c------Dr
To Sales A/c --------------Cr
GST A/c----------------Cr
c) During collection of Payment
Bank account -----------------------------------Dr

Discount -----------------------------------------Dr
To Customer/ Debtors account -----Cr
STO Accounting Entry

a) OBD Level
Stock - RM-Local (Receiving Plant) ----------------Dr

To Stock - RM-Local(Sending Plant)------Cr
GR/IR Clg- Freight--------------------------Cr
b) STO Invoice
Intra Customer A/c ---------------Dr
To STO-CLEARING---------Cr
GST A/c ---------------------Cr
c) J_1IG_INV – Transaction (Receiving Plant after GRN Run this--GST credit

transfer from sending plant to receiving plant.)
STO –Clearing A/c ----------Dr.
Input GST A/c-----------------Dr
To Receiving Plant --------------Cr
42. Transaction codes

SD- Standard Transaction start with V
FI – Standard Transaction start with F
MM – Standard Transaction Start with M
01 create / 02 change /03 display
Useful Transaction
VA11 – Create Inquiry
VA21 – Create Quotation
VA31- Scheduling Agreement
VA41 – Create Contract
VA01 – Create Sales order
VL01N – Create outbound delivery
VT01N - Create Shipment
VI01 – Create Shipment cost
VF01 – Create Invoice
VK11 – Create sales pricing condition record
VV11 – Create Output master Sales
VV21 – Create Output master shipping
VV31 – Create output master billing
SD Transaction Code Flow:
Inquiry / Document type IN

Tcode for creation VA11,VA12,VA13. tables VBAK, VBAP
Quotation / QT
Purchase Order PO
Tcode for creation ME21,ME22,ME23. tables EKKO, EKPO.
Sales Order OR
Delivery LF
Tcode for creation VL01,VL02,VL03. tables LIKP, LIPS
Billing MN
Tcode for creation VF01,VF02,VF03. tables VBRK, VBRP
To create a sales order we need purchase order number and custmer number.
Before that, to create a purchase order we need to have material no, vendor no.
To create vendor tcode is

xk01(create), xk02(change) , xk03(display)
Tables are lfa1.
To create custmer tcode is xd01, xd02, xd03.Table is kna1
43. Stock tables
Table Description SOBKZ
MARC Plant Data for Material
MARD Storage Location Data for Material
MCHB Batch Stocks
MSSL Total Special Stocks with Vendor O
MSLB Special Stocks with Vendor O
MSKU Special Stocks with Customer V,W
MSSA Total Customer Orders on Hand E
MSKA Sales Order Stock E
MSSQ Project Stock Total Q
MSPR Project Stock Q
MKOL Special Stocks from Vendor K,M

29.Valuation Tables
Table Description
MBEW Material Valuation
EBEW Sales Order Stock Valuation
QBEW Project Stock Valuation
OBEW Valuated Stock with Subcontractor (only for Japan)

30.Document Tables
Table Meaning Key fields
MKPF Header: Material Document Document number (MBLNR),

year (MJAHR)
MSEG Material Document - segments/ lines Document number (MBLNR),
year (MJAHR), line number
(ZEILE)
BSIM Index for material to the FI- Material (MATNR), Valuation

documents Area (BWKEY)...
CKMI1 Material ledger index, used to KALNR, use mbew-kaln1

document changes in MBEW for
each movement
31.All Stocks
Table Field Meaning Valuated Total in History Posted

in table table with
MARC Plant Data for

Material
MARC UMLMC Stock in transfer MBEW MARCH Transfer

(plant to plant) without
PO, 303 /
305
MARC TRAME Stock in transit MBEW MARCH Transfer

with PO,
351 / 101,
641
MARC GLGMG Tied empties MBEW MARCH

stock
MARC VKUMC Stock transfer MBEW MARCH

sales value
(plant to plant)
for VO material
MARC VKTRW Transit value at MBEW MARCH

sales price for
value-only
material
MARC BWESB Valuated Goods MBEW MARCH

Receipt Blocked
Stock
MARD Storage
Location Data
for Material
MARD LABST Valuated stock MBEW MARDH

with unrestricted
use
MARD UMLME Stock in transfer MBEW MARDH 313 / 315

(from one
storage location
to another)
MARD INSME Stock in quality MBEW MARDH

inspection
MARD EINME Total Stock of MBEW MARDH

All Restricted
Batches
MARD SPEME Blocked stock MBEW MARDH
MARD RETME Blocked Stock MARDH

Returns
MARD KLABS Unrestricted-use

consignment
stock
MARD KINSM Consignment

stock in quality
inspection
MARD KEINM Restricted-use

consignment
stock
MARD KSPEM Blocked

consignment
stock
MCHB Batch Stocks
MCHB CLABS Valuated stock MBEW MARD- MCHBH

with unrestricted LABST
use
MCHB CUMLM Stock in transfer MBEW MARD- MCHBH

(from one UMLME
storage location
to another)
MCHB CINSM Stock in quality MBEW MARD- MCHBH
inspection INSME
MCHB CEINM Total Stock of MBEW MARD- MCHBH

All Restricted EINME
Batches
MCHB CSPEM Blocked stock MBEW MARD- MCHBH

SPEME
MCHB CRETM Blocked Stock MARD- MCHBH

Returns RETME
MSSL Total Special

Stocks with
Vendor
MSSL SLLB Valuated stock MBEW**

with unrestricted
use
MSSL SLINS Stock in quality MBEW**

inspection
MSSL SLEIN Total Stock of MBEW**

All Restricted
Batches
MSLB Special Stocks

with Vendor
MSLB LBLAB Valuated stock MBEW MSSL- MSLBH

with unrestricted SLLAB
use
MSLB LBINS Stock in quality MBEW MSSL- MSLBH

inspection SLINS
MSLB LBEIN Total Stock of MBEW MSSL- MSLBH

All Restricted SLEIN
Batches
MSKU Special Stocks

with Customer
MSKU KULAB Valuated stock MBEW MSKUH

with unrestricted
use
MSKU KUINS Stock in quality MBEW MSKUH
inspection
MSKU KUEIN Total Stock of MBEW MSKUH

All Restricted
Batches
MSSA Total Customer

Orders on Hand
MSSA SALAB Total Customer EBEW*

Orders on Hand MBEW+
MSSA SAINS Stock in quality EBEW*

inspection MBEW+
MSSA SASPE Blocked stock EBEW*

MBEW+
MSSA SAEIN Total Stock of EBEW*

All Restricted MBEW+
Batches
MSSA SATRA Stock in transit EBEW* MSSAH

MBEW+
MSKA Sales Order

Stock
MSKA KALAB Total Customer EBEW* MSSA- MSKAH

Orders on Hand MBEW+ SALAB
MSKA KAINS Stock in quality EBEW* MSSA- MSKAH

inspection MBEW+ SAINS
MSKA KASPE Blocked stock EBEW* MSSA- MSKAH

MBEW+ SASPE
MSKA KAEIN Total Stock of EBEW* MSSA- MSKAH

All Restricted MBEW+ SAEIN
Batches
MSSQ Project Stock

Total
MSSQ SQLAB Total Customer QBEW*

Orders on Hand MBEW+
MSSQ SQINS Stock in quality QBEW*

inspection MBEW+
MSSQ SQSPE Blocked stock QBEW*

MBEW+
MSSQ SQEIN Total Stock of QBEW*

All Restricted MBEW+
Batches
MSSQ SQTRA Stock in transit QBEW* MSSQH

MBEW+
MSPR Project Stock
MSPR PRLAB Total Customer QBEW* MSSQ- MSPRH

Orders on Hand MBEW+ SQLAB
MSPR PRINS Stock in quality QBEW* MSSQ- MSPRH

inspection MBEW+ SQINS
MSPR PRSPE Blocked stock QBEW* MSSQ- MSPRH

MBEW+ SQSPE
MSPR PREIN Total Stock of QBEW* MSSQ- MSPRH

All Restricted MBEW+ SQEIN
Batches
MKOL Special Stocks

from Vendor
MKOL SLABS Unrestricted-use MARD- MKOLH

consignment KLABS
stock
MKOL SINSM Consignment MARD- MKOLH

stock in quality KINSM
inspection
MKOL SEINM Restricted-use MARD- MKOLH

consignment KEINM
stock
MKOL SSPEM Blocked MARD- MKOLH

consignment KSPEM
stock
only if MSSA/MSSQ - KZBWS = 'M'
+ only if MSSA/MSSQ - KZBWS = 'A'
** if MSSL-XOBEW = 'X' valuated in table OBEW (only for Japan from 4.6 on)
: Handling Unit Item (Contents)
Billing 32.SD /MM Tables
Sales Document
VBAK Sales Document - Header Data
VBAP Sales Document - Item Data
VBKD Sales Document - Business Data
VBPA Partners
VBFA Document Flow
VBEP Sales Document Schedule Line
VBAKUK Sales Document Header and Status Data
VBUK Header Status and Administrative DataVBUP Item Status
VBBE Sales Requirements: Individual Records
SD Delivery Documemt
LIPS Delivery Document item data
LIKP Delivery Document Header data
Shipping
VTTK Shipment header
VTTP Shipment item
VTTS Stage in transport
VTSP Stage in transport per shipment item
VTPA Shipment partners
VEKP Handling Unit - Header Table
VEPO Packing Document
VBRK Billing:Header data
VBRP Billing:Item data
Customer Master
KNA1 General Data
KNB1 Customer Master (Company Code)
KNB4 Customer Payment History
KNB5 Customer master (dunning data)
KNBK Customer Master (Bank Details)
KNBW Customer master record (withholding tax types)
KNKA Customer Master Credit Mgmt.
KNKK Customer Master Credit Control Area Data (credit limits)
KNVA Customer Master Loading Points
KNVD Customer master record sales request form
KNVH Customer Hierarchies
KNVI Customer Master Tax Indicator
KNVK Customer Master Contact Partner
KNVL Customer Master Licenses
KNVP Customer Master Partner Functions
KNVS Customer Master Shipping Data
KNVT Customer Master Record Texts for Sales
KNVV Customer Master Sales Data
KLPA Customer/Vendor Link
Pricing
KOMK Pricing Communications-Header - Structure
KOMP Pricing Communication Item - Structure
KONV Conditions (Transaction Data)
KONP Conditions (Item)
KONH Conditions header
KOND contracts
VEDA Contract data
Output
NAST Message Status
SD Shipping Unit
VEKP Shipping unit item (Content)
VEPO Shipping Unit Header
Delivery Due Index - item
VBUP: Item status
VBAP: Sales document: Item data
VBKD: Sales document: Business Data
VEBA: Contract
VBLB: Forecast delivery schedules
VBEP: Sales document: Schedule line
VBBE: Individual requirements
VBBS: Summarized requirements
VBUV: Incompletion log
VBFA: SD document flows
VBPA: Partner
JSTO: PP status
NAST: Output
STXH: Texts: Header
STXL: Texts: Lines
KONV: Conditions
Sales activities
VBKA Sales activity
VBUV: Incompletion log
VBPA: SD document: Partner
SADR: Address
VBFA: SD document flows
NAST: Output
STXH: Texts: Header
STXL: Texts: Lines
Logical database:
AK V: Sales documents
Material
MARA General material data
MAKT Short texts
MARM Conversion factors
MVKE Sales data (for each sales organization and distribution channel)
MLAN Sales data (for each country)
MAEX Export licenses
MARC Plant data
MBEW Valuation data
MLGN Warehouse management inventory data
MLGT Warehouse management inventory type data
MVER Consumption data
MAPR Pointers for forecast data
MARD Storage location data
MCH1 Cross-plant batches
MCHA Batches
MCHB Batch stocks
KNMTK Header table
for increased performance
KNMT Data table
Logical databank for material master
CKM Material master
MSM Material master
Bill of Material (BOM)
MAST Material assignment to BOM
EQST Equipment assignment to BOM
KDST Sales order assignment to BOM
DOST Document assignment to BOM
STST Standard object assignment to BOM
TPST Functional location assignment to BOM
STKO BOM header data
STZU Time-independent STL data
STAS BOM item selection
STPO BOM item data
STPU BOM sub-item data
MMBE - Stock Overview

MD04 - Stock/Requirements List
MB53 - Plant Stock Availability
CO09 - Availability Overview
MB52 - Warehouse Stock
MB5M - Expiration Date List
MB5B - Stock for Posting Date
MB5T - Stock in Transit
MBBS - Valuated Special Stock
MBLB- Stock with Subcontractor

Full Form's: SAP-SD Notes

Uploaded by

Document Information

Original Title

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

Full Form's: SAP-SD Notes

Uploaded by

Copyright:

Available Formats

SAP-SD Notes

Sales and Distribution

Business Area Account Assignment

4. Sales document type (VOV8) –

2) Number range assignment

TAN – for standard

Item Category control for following -

ITEM category group (which is define in material master)

a) General Item category group-- is mainly used for Inbound Delivery; it is

Delivery Item Catg. Controls delivery doc.type

7. Schedule lines (VOV6)

Schedule line determination

Use of - It determines the delivery date and delivery qty.

Schedule line control for following

10. Route Determination

11. Storage location Determination

Storage location determination check must be activated for the relevant

13. Partner Determination & Setup

Note: Partner Determination Configuration

Partner determination may be defined for the following activities

Set Up Partner Determination for Sales Document HEADER

Set Up Partner Determination for Sales Document ITEM

Set Up Partner Determination for DELIVERY

Set Up Partner Determination for SHIPMENT

Set Up Partner Determination for Billing Document HEADER

Set Up Partner Determination for Billing Document ITEM

Deactivate Multi ship to Pop up at sales order level.

SPRO>Sales and Distribution>Basic Functions>Output Control>Output

Maintain Output Determination for Billing Documents

Maintain Output Types

Assign Output Types To Partner Functions

Assign Output Determination Procedures to billing type

VV11 – Default output master for Sales

15. Material Determination – Tr. code - VB11

Activate Material det. in Sales Order →Environment→Analysis→Material

SPRO → Sales and Distribution → Basic Functions→Material Determination

Following steps follow for configuration.

16. Availability Check and Transfer of Requirements

It depends on the basis of:

SPRO→ SD→ BF→Availability Check and Transfer of Requirements→Avai.Check

There are three types of availability check:

Availability Check Criteria

Check on the Basis of the ATP Quantities

Configuration steps →SPRO→SD→Basic Functions→Availability Check and

Define Material Block For Other Users

Define Checking Groups Default Value

Carry Out Control For Availability Check ( OVZ9 Tr. Code)

Define Procedure By Requirements Class

Define Procedure For Each Schedule Line Category

Availabilty check rule A- sales order , B- deliveries .

Transfer of Requirements (TOR)

The transfer of requirements is dependent on the following data:

Determination of requirement types

17. Backward & forward scheduling

The system calculates backward scheduling as follows:

18. Routines –Control over conditions

SPRO – SD – Basic Function – Pricing - Pricing Control

Elements Used in the Condition Technique

Pricing procedure details: there are 16 steps in Pricing Procedure.

Pricing related Question:

20. Account Determination ( VKOA)

iii) KOFI → is used for accounting & KOFK – Controlling accounting.

21. Group Condition