Sap SD Config
Sap SD Config
Sap SD Config
Sales
document type
Ex: OR
Item category
group
Ex: NORM
Usage
Higher level
item category
Item category
73
Schedule line category determination
Every line item of sales order must have one or more than schedule lines. Schedule line category determine by the
system automatically by taking two factors into consideration:
Item category (of line item) plus
MRP type (in the material master)
Item category MRP type = Default schedule line category
TAN
TAN
PD (MRP)
ND (No MRP)
CP
CN
Sales documents are the core components of SAPs selling process and Sales and Distribution module. A
sales document defines how the data is to function, how it is to be displayed, the pricing that happens during the
output, and so on. It is the heartbeat of the sales environment.
Define sales document type: Transaction code: VOV8
Path:
IMG
Sales and distribution
Sales
Sales documents
Sales document header
Define sales document types
Click on position button
Choose sales document type OR from position button
Click on details icon
Sales document type: OR [AVART] Standard order
Sales document category: [C] = Order
A classification of different types of documents Ex: IN, QT, OR.
Use: The document category determines how the system stores and keeps track of document data. It enables the
system to provide status information about delivery processing, billing processing and about the documents that
were used as a reference documents for this sales document type. Ex: IN, QT.
Indicator: [] = No classification.
This indicator again, to classifies document type. It is only for to display in TVAK table. TVAK is the table where
all the sales document types going to be stored.
Sales document block: [] = No block
If we want to block this sales document for processing at client level.
Item category
MRP type
Schedule line category
74
Section number systems
Number range internal assignment: [01]
Number range external assignment: [02]
We can define number ranges in IMG and we can assign those number range keys in number range system
section. System gives the priority for internal assignment if we assign the value otherwise end user has to assign a
value externally form the specified number range. As soon as, the end user saves the document system assigns the
number.
Item number increment: [10]: We can assign a number in this field. So that system generates numbers for all
items in the sales order by incrementing specified number.
Sub item increment: []: We can assign a number for sub item. So that system generates accordingly.
General control Section
Reference mandatory: [] = No reference required.
We can specify the reference document as a mandatory for this document processing. The document does not have
a mandatory reference before an order can be created, such as reference to a quotation is mandatory.
Check division: [] = No dialog.
If the division differs with header division how system should respond like, system should not respond, it has to
show the message or error.
Probability: [100]: The probability of the customer confirming the inquiry or quotation as a part of sales order.
Use: The system uses the probability and net value of each item to calculate total expected order value for the sales
document.
Ex: A quotation contains two items. Item 1 has a value of 100/- Rs and the probability is 100%. Item 2 have a
value of 200/- and the probability is 25%. Then the system calculates that probability as follows:
(Rs 100 X 100% + Rs 200 X 25%)/300 = 50%. That means the probability of this quotation resulting in sales order
is 50%.
Check credit limit: [D] = Credit management: Automatic credit control.
In SAP we have an option to configure credit management features for particular customer. As in every business,
credit sales are more or less mandatory. When the credit sales exist it is essential to monitor credit risk of particular
customer. We can configure two kinds of credit checks. Those are:
(A) Simple credit check
(B) Automatic credit check
Simple credit check: In simple credit check, credit exposure of customer comes with
Total document value PLUS
Customer master (payer) credit limit.
System compares these two factors for credit exposure and reacts according to the value that we set here.
Values: [ ] No credit limit check
[A] Run simple credit limit check and warning
[B] Run simple credit limit check and error message
75
[C] Run simple credit limit check and delivery block
Automatic credit check: System can automatically checks credit limit of the customer by following
methods: Dynamic,
Static, and
Check based on total document value
In static and dynamic credit check credit exposure results from the total of open orders, open deliveries,
open receivables and open items. Depending upon the credit exposure system responds according to the value that
we set here that is [D] = Credit management: Automatic credit control. Consequently system blocks the delivery
document from processing. An authorized should release the document.
The difference between dynamic and static is, dynamic contains time/horizon/attachment period. This
time period used by the system where we specify time in months Ex: 2 months. System will use this period to take
open orders, open deliveries, etc (all open documents) to get credit exposure.
NOTE: Credit management can be configured at order, delivery, PGI level not at billing level
Credit group: [01] = Credit group for sales order
It specifies the document credit group for a particular sales document.
Use: The document credit group enables us to combine different sales document types for the purpose of credit
management for credit exposure.
Output application: [V1] = Sales.
Output determination: In SAP by using condition technique we can configure output for a particular
document for which SAP follows output determination procedure. We can generate and send output of
document by e mail, fax, and telex or by local printer.
Material entry type: [] = Enter with material number.
It enables the user to enter material in the sales document by its number or if you configure product catalog, then
the material to be entered with order number and product catalog determination. The material can be entering with
its number and product catalog determination.
Item division: This indicator enables the system to go to material master of line item and it copies its division and
proposed into sales order. If you do not check it then system treats all items in the sales order as a header division
item.
Read Info record: [Customer Material Info record]: We can create customer material info record master data to
maintain the customers own description for the particular material. The customer can place the order by specifying
his own description. Then system copies the material description from customer material info record and places the
relevant material in the sales order. In addition to customer own description we can maintain plant delivery priority
etc. System gives the top priority for customer material info record.
If you maintained customer material info record, then this indicator enables the system to read that
customer material info record, while raising sales order of this sales document type.
Purchase order number: [] No check.
System checks whether the purchase order number existed or not for this sales document type.
Enter purchase order number: This indicator checks for the purchase order number and if the purchase order
number not existed then system takes sales order number as a purchase order number.
Commitment date: [] Do not maintain commitment date.
It is a key that controls how the commitment quantities should be calculated for sales document type.
Use: The commitment date is calculated using the delivery time for releases to contracts with delivery times (OR)
sales order that refers to quotations containing delivery times. The committed quantity results from the agreed
delivery time or confirmed quantity according to the calculation rule that we set here.
Calculation rules:
[A] Consider agreed delivery time: Here all required schedule lines are committed for the date that lies at
the agreed distance from the delivery time, according to the date on which the order was placed. If the
customer requests a letter date that can be confirmed, the confirmation does not effect the calculation. If
we do not enter delivery time system does not calculate a committed quantity.
[B] First confirmation date: The committed quantity is calculated according to the first confirmed
quantity. If the delivery time exists for the item, system takes it into consideration as in rule A and
confirms the earlier date. The commitment date is recalculated if the material, quantity, first date or
delivery time changes. The quantities confirmed they are valid once the document has been saved.
76
[C] First confirmation date: Rule C is the same as a calculation rule is B. But it applies for new
items.
No entry: If it is blank, no calculation rule is applied.
Transaction flow Section
Screen sequence group: [AU] = Sales Order
This screen sequence group specifies the system to display the screens for this sales document type and specify the
sequence in which they have to be displayed.
Incompletion procedure: [11] = Sales order
SAP has provided a feature that is called incompletion procedure by which system reminds the end user about the
fields in which the values has not been maintained, while saving the document as these fields will have a influence
eon proceeding documents that are deliveries and billing documents. If the end user does not maintained the values
in those important fields then it cannot process subsequent documents that are dependent on the values of these
fields. So that system reminds the end user about the missing of the data subsequently end user can maintain the
data in those fields before saving this document. SAP follows incompletion procedure to which incompletion log
has been assigned. So system logs the important fields into separate area and shows those fields to the end user.
Transaction group: [0] = Sales order
A group that allows us to control certain characteristics of a transaction according to the sales documents type.
Use: The transaction group controls the types of sales documents that we can process with certain system
transactions in sales processing. The transaction group controls for which sales, shipping, billing documents should
update reporting indices.
Document pricing procedure: [A] = Standard
System takes the value of this field into consideration to determine pricing procedure for this sales document type
by considering another two factors that are sales area and customer pricing procedure (VD01).
FAQ: How system determines pricing procedure?
ANS: System determines pricing procedure by taking three factors into consideration:
(A) Sales area (that the end user enters) plus
(B) Document pricing procedure (Ex: VOV8 of OR) plus
(C) Customer pricing procedure (VD01)
Status profile: It is a key that identifies a status profile. It is a cross application component it is used to control
user statuses. In status profile we can define the sequence in which the user statuses can be activated. We can
define initial statuses we can allow or prohibit certain business transactions.
Cross applications: SAP has provided cross applications to transport the data from one instance to another
instance, from one system to another system means R/3 to non R/3 in the form of IDOCS (intermediately
documents) and ALE (application link enabling). IDOCS are used for holding or carrying the data. ALE used for to
line the R/3 system with EDI (electronic data interchange) or any other non-R/3 system.
Alternative sales document type 1 and Alternative sales document type 2: We can assign alternative sales
documents types for this sales document types Ex: Cash sales and Rush orders. So that the end user will have a
chance to switch over into those documents while processing these sales document type.
Note: Number ranges should be same for these document types.
77
Transaction variant: We can specify the transaction variant to link this document to work flow object.
Display range: [UALL] = All items
We can control the display of line items.
Function code for overview screen: [UER1] = Press ENTER to go to general overview.
The value of this field determines the system to take the end user into a particular screen (tab) as soon as he pressed
enter after providing document type and sales area.
Quotation messages: [B] = Check at item level.
We can switch off or switch on messages about open quotations at header level or item level.
Outline agreement messages: [B] [] Check at item level.
We can switch on or switch off messages about outline agreements.
Message: Master contract: [] = do not check.
We can switch on or switch off messages about master contracts.
Product attribute messages: [] = No message.
If the user wants to change the properties of products manually how system should respond like no message,
dialogue or error message.
Incomplete messages: This indicator if we check it does not allow the end user to save the document if he forgets
to maintain the data in certain field.
Scheduling agreement section
This section deals with scheduling agreement document type.
Correction delivery type: [] We can assign delivery document type Ex: LFKO for correction deliveries.
Use: [] Specify the use of the material how it is going to be used in the scheduling agreements. The usage defines
the conditions under which a material is sold. It can be entered at item or header level.
The same material but with different uses can be sold to the same customer in separate items or orders.
We can enter the material as a spare or replacement part, as a sample, part of series in a repetitive manufacturing. It
is useful for automobile industry.
MRP for delivery schedule type: [] = Delivery schedules are not used.
We can specify MRP type for delivery scheduling document types.
Ex: No MRP, just in time, etc.
Delivery block: [] We can set a delivery block for scheduling delivery document types when the tolerance check in
the scheduling agreement is not successful. That means tolerance limit in days, week or percentage was not met or
exceeded Ex: Change in quantity.
78
Shipping section
Delivery type: [LF] = Delivery
Delivery document type LF has been assign to sales document type OR. So system automatically proposes
these delivery document type LF when we raise the sales order document type OR.
Delivery block: [] It indicates if an entire sales document is blocked for delivery.
Process: System proposes delivery block at header level. This block applies to whole items in the sales
order. We can propose header level delivery block for sales document type like free of charge deliveries
where it is important that someone should check before shipping.
If we use credit limit check, the system can automatically block the delivery.
Shipping conditions: [] We can maintain shipping conditions for this sales document type Ex: 01, 10, etc. We
maintain the shipping conditions in the customer master as well as sales document type. If we maintain in the both
areas system gives the priority for sales document type.
For sales document type CS shipping condition 10 is must.
Shipping cost info profile: [STANDARD] = Standard freight information.
We can assign shipping cost information profile that contains proposal values for the shipment cost
information in the sales order. Ex: Transportation planning point, shipment type, shipment cost pricing procedure.
System automatically proposes this shipping cost information profile.
Immediate delivery: [] = Create delivery separately.
We can specify the value in this field by which system automatically creates delivery document for the sales
document as soon as the end. User saves the document value X is most relevant for sales document type CS as
cash sales document should create delivery document as soon as the end user saves the document type CS.
Billing section
Delivery related billing type: [F2] = Invoice
Order related billing type: [F2] = Invoice
Billing document type F2 has been assigned to this sales document type. So that system automatically proposes the
billing document for this sales document type.
Intercompany billing type: [IV] = Inter company billing.
We assign the inter company billing type to the sales document type. So that when the inter company billing
process takes place for this order so that the system automatically proposes this inter company billing document
type IV.
Intercompany billing process: If the company has two company codes and each company has two plants,
then one plant may get the material from another plant for its customer. Then the delivering plant
sends/delivers the material to the end customer of ordering plant, delivering plant bill the ordering plant
(inter company billing) and ordering plant bills the end customer.
Billing block: [] It indicates if the item is blocked for billing. System automatically proposes a billing block for
sales documents that must be checked before billing Ex: RE, G2, and L2. System proposes the block for all items.
If one item has two schedule lines then block applies to each item.
79
Condition type line items: [EK02] = Calculated costs.
It is a condition type for copying cost from line items. This is the condition type that we want to use to determine
the results of the sales order pricing for SD document item.
If we enter this condition type in requirements class then it applies to all sales document items that
containing requirement type which indicates requirement class. If we enter the condition type into the sales
document type this condition type is used for all items in the sales documents of this sales document type. EK01
and EK02 have been provided for cost transfer of line items.
EK01: If we choose it the result of the sales order costing (integration with controlling) is first printed to
the pricing screen for the item. The value can be used as a basis for price calculation.
EK02: System simply takes the result of the sales order costing as a statistical value (only for information
purpose).
Billing plan type: [] We can assign billing plan type for this sales document type as an Ex: Standard billing,
periodic billing (for rented or maintenance contract). The entire value to be billed is billed in each billing plane
date.
Milestone billing (for) projects: The total value to be billed is distributed between the individual billing
planned dates (that can be amount or percentage wise).
Payment guarantee procedure: [01] = Standard
The key identifies the document payment guarantee procedure for this sales document type. It defines which
payment guarantee procedure system automatically uses for this sales document type. With in receivable risk
management system determines payment guarantee procedure by taking following factors into consideration.
(A) Key of document payment guarantee procedure from the header of the sales document type.
(B) Key of customer payment guarantees procedure from customer master.
The payment guarantee procedure defines the type and sequence forms of payment guarantee that the system
assigns to sales document types.
Payment card plan type: [03] = Payment card
It specifies the payment plan type for payment cards. The payment card plan type specifies how the sales document
to which it is assigned will be settled for payment in this case one or more payment cards.
Checking group: [01] = Standard
It specifies how the system carries out checks on payment card data in different SD documents. It is done on the
basis of checking group assignment to different sales document types.
Requested delivery date/Pricing date/Purchase order date Section
This section deals with default dates for delivery pricing and purchase order date.
Lead-time in days: [7]
It specifies the number of days after the current date that the proposal for requested delivery date in the sales
document should be.
Date type: [] It identifies the date type internally in the system. When we create schedule lines for the sales
document types we can specify different formats for the delivery date.
Proposal for pricing date: [] = Proposal based on todays date.
Proposal for pricing date is based on the requested delivery date. We can enter the date, which we want the system
to propose for the pricing date when sales document is created.
Ex: We want the date on which the contract becomes valid to be the date, which is proposed, has the pricing date in
the sales document. So that value B can be set here.
Proposed valid from date: [] No proposal
Specify the ID for the date which, the system proposes for valid from date.
Ex: When we enter a quotation.
80
Propose delivery date: It indicates whether the system automatically proposes the current date as the delivery date.
Propose PO date: System proposes current date as a purchase order date.
Contract section
This section deals with contracts documents.
Pricing procedure condition Header: [] Pricing procedure for conditions at header level Ex: PABR01. We can
assign a procedure for contract document header level that applies to all items in the contract document. This
procedure can be assigned for service items.
Pricing procedure condition Item: [] Pricing procedure for contract conditions at item level Ex: PABR02. We
can assign a pricing procedure for contract documents at item level. This procedure applies to only item.
Contract profile: [] For contract documents we can define contract profile in which we can specify contract
validity periods and cancellation rules that system automatically uses.
Billing request: [L2] = Debit memo request
We can assign billing request L2 (debit memo request) for business compensations.
Group reference procedure: [SDGK]: We can assign a reference in procedure to which master contracts and
lower level contracts can be linked with each other.
Contract data allowed: [] = No contract data allowed for order type.
The value of this field determines:
(A) Whether the contract data allowed for this sales document type that we enter.
(B) How the changes affect that we made to header level.
Values: X or Y
If it is X: If we set X the change that we made to the header level will not be copied to the items, it
applies even the header data is identical with item level data.
If it is Y: If we set Y the changes that we made to header level copied automatically into items.
Follow up activity type: [] Ex: 0003 = Sales letter
We can specify the follow up activity type that is to be created when sales activity is defined as the follow up action
for this kind of contract sales document type.
Ex: Follow up activity type 0003 can be assigned with contract document type MV (rental contract). We can
create follow up activity work list by choosing outline agreements contract subsequent functions follow up
actions, then enter selection criteria, select all contracts with follow up action that is created sales activity and
choose edit follow up actions. Then system automatically proposes follow up activity type 0003.
Subsequent order type: [] Its a proposal for order type for the subsequent functions. We can assign an order type
that system proposes automatically with in subsequent processing.
Ex: For maintenance contract (that has a validity period one year) we can create follow up action that is create
quotation that is to be carried out before the contract end date. We can assign order type AG as a follow up
action.
81
To create follow up actions:
Path:
IMG
Outline agreement
Contract
Subsequent functions
Follow up actions
The system proposes follow up action document type AG that we specified in this field.
Check partner authorization: [A] = Check partner authorized to release in contract.
[B] = Check partner authorized to release in customer.
In addition to normal partner functions we can assign another partner function that is AA (partner to release
contracts) in the customer master or in the contract document header while determining partner determination
procedure.
Partner determination procedure: We can determine relevant mandatory partner (functions) for objects
Ex: Customer, sales document header item, delivery/billing documents header level and item level. In contracts in
addition to these four partner functions we can assign another partner (function) whose responsibility to release this
contract.
Update lower level contracts: This indicator enables the system to update lower level contracts that are assigned to
master contracts if any changes are made to the master contract.
Availability checks Section
Business transaction: [OR]: We can specify rule based availability check for sales document types. As this sales
document types (OR) business transaction it is relevant for availability check. So that we can assign document type
to carryout availability check.
It is meaningless to specify business transaction is relevant for availability check for sales document types cash
sales CS and rush order RO.
Define number ranges for sales documents:
Path:
IMG
Sales and distribution
Sales
Sales documents
Sales document header
Define sales document
Define number range for sales document
Click on change intervals icon
Click on intervals icon
Click on intervals icon
Define number ranges with or without external option
Save and Exit
Go to VOV8 of OR and assign number ranges keys in: Internal
External
Number range fields in number system section
82
Define order Reasons: Transaction code: OVAU
We can define our own order reasons for sales documents.
Path:
IMG
Sales and distribution
Sales
Sales documents
Sales document header
Define order reasons
Go to new entries
Define your order reasons
Save and Exit
Save the sales document header data and Exit
83
Stand Order (OR)
84
Define item categories: Transaction code: VOV7
Path:
IMG
Sales and distribution
Sales
Sales documents
Sales document item
Define item category
Choose stand item category Ex: Item category = [TAN] from position button
Select it, and go to details button.
Business data section
Item type: [] Standard item
System process item that refer to a specific material differently then items that dont refer to a material Ex: TEXT
items. As text items does not require processing pricing, taxes, and weight and volume calculations.
Completion rule: [] Not relevant for completion
(It is for quotations and contract items). We can specify that a quotation is complete only after its quantity has been
fully referenced by subsequent document.
Dependencies: In copy control sales document to sales document, check update document flow option at
item category level.
Ex: If the item category for quotations is AGN, then the value will be 8.
Special stock: [] We can specify a separate stock Ex: consignment stock of material. In inventory management
stock of materials must be managed separately for reasons of ownership or location. Specify W for item category
KEN (consignment issue)
Billing relevance: [A] = Delivery related billing document.
The value determines what kind of billing document it has to generate for this item. That is order related billing
document or delivery related billing document.
Billing plan type: [] We can assign billing plan type for this particular item that is standard billing, periodic billing
and milestone billing.
Billing block: [] The billing block indicator is used to block each item of this category for billing.
Pricing: [X] = Pricing standard
It indicates whether the system automatically carried out pricing for this item.
Ex: For text item it is grade out.
Statistical value: [] = System will copy item to header totals.
It indicates whether the system takes the value of an item into account when it determines the total value of
document.
85
Business item: It allows the business data at header level differs with item level business data.
Business data: Business data is nothing but sales, shipping and billing data that is called as a business
data. Ex: We maintain payment terms in customer master. When we raise the sales order for this
customer the payment terms are copied into the sales document header from customer master. If we do not
maintain payment terms in the customer and we maintain payment terms in the sales document header
manually then those payment terms applies whole item in the sales order. If we have number of items in
the sales order and if we want to change payment terms for particular line item, system allows us to do so,
if business item field has been checked. Otherwise system will not allow changing the payment terms at
item level.
Schedule line allowed: It indicates whether we can create schedule lines for the item. Sales order items always
will have a schedule lines. The items like credit memo request and contracts do not have any schedule lines.
The items that have a schedule lines will be copied into the delivery document. The only one item
category that is text item has an exemption. For text items with or without schedule lines we can create delivery
documents.
Item relevant for delivery: It indicates whether a text or value item is relevant during delivery processing. The
item itself is not delivered. But it serves only for information purpose in delivery documents.
Returns: It indicates the item is return itemEx: REN
Weight/volume relevant: This indicator enables the system to calculate weight and volume of materials.
Credit active: This indicator enables to configure credit management functions for this item.
Determine cost: This indicator enables the system to calculate cost of the material of this item category (condition
type VPRS is used to calculate the cost price).
General control section
Automatic batch determination: This indicator enables the system to determine batch automatically of this item
category.
Rounding permitted: If you check it system rounds of the quantity of the material for this item category type.
Order quantity = 1: If you check it system enables one quantity for line item. it does not accept more than one
quantity.
Transaction flow section
Incompletion procedure: [20]: Incompletion procedure has been defined in IMG and assign to item category of
this type. System follows this incompletion procedure and remains the end user if he does not maintain any values
at item category level in the sales document.
Partner determination procedure: [N]: Partner determination procedure N has been defined and assigned to
item category. So that system follows this partner determination procedure at item level and decides itself sold to
party, ship to party, bill to party and payer for this item.
86
Text determination procedure: [01]: Text determination procedure 01 has been defined and assigned to item
category of this type (TAN). So system follows this text procedure to determine output.
Item category statistics group: [1]: It specifies a statistics group for this item category and helps to determine
which data the system should update in LIS.
Screen sequence group: [N] = Item
It controls which screens we see during the particular transaction and in which sequence they appear. Ex: We can
differentiate sequence of screens in inquires and quotations with sales order.
Status profile: [] status profile can be defined and assigned to the item category that defines use status by which we
can restrict the user to access the item.
Create PO automatically: This indicator used in third party and individual purchase order items where the system
has to generate purchase orders automatically when R/3 is connected to ALE (application link enabling).
Bill of material configuration section
Configuration strategy: [] It controls checks and processes that are run automatically or are allowed during
configuration. System takes this value while we configure of material of item category of configuration material.
Ex: Item category TAC = Variant configuration.
Material variant action: [] It controls how the system reacts when it determines that an existing configuration is
already used as a stock able type.
ATP Material variant: [] = No ATP check
We can specify ATP check for material variants in the variant configuration.
Structure scope: [] = Do not explode material structure.
This field will be used for BOM items.
BOM: When specific material consists of number of items and those items can be sold as a individual
items, then that particular item is called as a BOM.
Ex: [Computer]: As computer consist of header item (monitor) as well as sub items (keyboard, mouse, hard disk,
etc). Business treats this item as a single item and sells the item to the customer as one. When we raise the sales
order we have to specify only header item that is monitor. Then system automatically explodes remaining items as
a BOM. The BOM can be single level or multi level. The value of this field determines whether the item is a BOM
item. If it is so, how it should be exploded.
Application: [] As the BOM can take place in production planning, materials management, sales and marketing
areas. System should know where it is to be applied. As it is a sales area we have to specify as SD01 that is for
sales and distribution.
Variant matching: This will activate variant determinations during variant configuration of the material.
Create delivery group: [Delivery group]: In the sales order if there are items with different schedule lines then we
can create delivery group for all items into a single delivery with latest schedule line confirmed quantity of line
item.
Ex: If we have three items with delivery dates that is today, tomorrow and day after tomorrow. Then we have to
specify in the sales order in overview screen shipping tab specify the delivery group number in delivery group field.
Then system confirms latest delivery date for all items in the sales order.
As the BOM contains number of items, the sub items may not be confirmed by the system on a single
day. Then system reschedules all items confirmed quantity dates with same or latest schedule line and creates
delivery group.
87
Manual alternative: It allows choosing alternatives for BOM items manually.
Check parameter affectivity: Parameter affectivity is a concept through which we can change the property of
material or product.
Ex: Seasonal changes (color) to a certain period. It is integrated with engineering changes management cross
functionality function.
Value contract section:
Value contract material: [] The system copies value contract item that we specified here into the value contract, if
it has not already been maintained in contract.
Contract release control: [B]: Here we can specify the system responses when the target value of value contract
has been reached while releasing the contract.
Service management section
Repair procedure: [] We can assign repair procedure for service items.
Control of resource related billing and creation of quotations section
Billing form: [] The billing form specifies whether a flat rate or the dynamic items are invoiced individually when
performing billing using a resource related billing document (it is for service items).
DIP profile [Dynamic Item Processor]: We can assign dynamic item processor profile for dynamic item.
Dynamic item processor is a toll that the system uses to summaries data into dynamic items in sales price
calculation, resource related billing or data determination.
Dynamic items: Customer service items are called as dynamic items.
Save the Item category and Exit
88
Stand Item (TAN)
89
Define schedule line category: Transaction code: VOV6
Path:
IMG
Sales and distribution
Sales
Sales documents
Schedule lines
Define schedule line categories
Click on position button
Choose schedule line category Ex: CP = Deterministic MRP
Select it
Click on details button
Business data section
Delivery block: We can specify delivery block that the system applies automatically during processing.
Ex: We can specify delivery block for all free of charge deliveries as these documents have to be approved before
processing.
Movement type: [601] = GD goods issue: delivery.
Inventory management for goods movement into different purposes uses this movement. Goods movement is
nothing but a physical or logical movement of materials leading to a change in stock levels is resulting in the
consumption of the material.
Movement type 1 step: [] It is used for inter company billing movement type.
Order type: [] It is a purchase order type. Ex: Document type NB can be assigned. In individual purchase order
and third party sales order system automatically creates purchase requisition. So as to create it automatically
purchase requisition document type should be assigned here.
Item category: [] We can specify the item category for purchase requisition documents.
Ex: 0 for individual purchase orders and 5 for third party orders.
Account assignment category: [] We can assign account assignment category for third party and individual
purchase order transactions. So that respective accounts get updated.
Check item relevant for delivery: It indicates the document item is relevant for delivery and it causes to create
delivery document.
Purchase requisition delivery schedule: In third party and individual purchase orders the vendor supplies
materials to the end customer through the company or directly. When the vendor has to send the materials the
business requires certain time for goods receiving process. The time can be specified as a delivery schedule lines in
purchasing documents. This indicator creates those schedule lines in purchase requisition documents.
90
Transaction flow section
Incompletion procedure: [30] = Delivery relevant schedule line.
Incompletion procedure has been defined and assigned to the schedule line category CP. System follows this
incompletion procedure and remains the end user if do not maintain any values in schedule line category fields
before saving the document.
Check transfer of requirements (Req. / Assembly): Requirements of sales document whether individual or
summarized should be transfer to MRP by system automatically to create demand.
Check availability check: If the system has to carryout availability check for materials and quantities in the sales
order it should be checked.
Product allocation: Through product allocation we can allocate products for customers evenly.
Save the Schedule line category and Exit
Stand Schedule line category (CP)
91
Pricing
Pricing is the combination of creating correct pricing procedures that map the business needs and processes such as
correct pricing and discounting, and keeping to the legal requirements placed on the business, such as adhering to
the tax laws of the respective country.
A pricing procedure consists of a list of condition types in defined orders, such as price, less () discount, plus (+)
tax. Some controls exist in the pricing procedure.
Pricing is the calculation of costs (for internal purpose) and revenues (for external purpose) by following tax class
of a particular country.
The pricing procedure is also used in account determinations. This determines the general ledger (GL) accounts to
which type prices, discounts, and taxes must be posted. The condition types in the pricing procedure are linked to an
account key. This key in turn is linked to the GL Accounts. This shows the integration between the pricing in the
invoice and the Financial Accounting (FI) Module.
Pricing Procedure
Availability check/TOR
Free of charge goods
Material determination
Material
Pricing
Route determination
Output determination
Partner determination
Text determination
Customer
Account determination
Credit management
Sales document
IN OR
Header
+
Item
+
Schedule line
Condition record
Condition table
Value
Combination
Access sequence
Base price [PR00] xxx
() Discounts (KF00) xxx
(=) Net value per item xxx
(+) Freight (KF00) xxx
(+) Taxes [MWST] xxx
Net price xxx
Optional pricing elements
Condition types
Mandatory
Input tax = MM
Output tax = SD
92
1 Pricing procedure PR00 , etc like
2 Pricing elements Base price, etc like
Condition type Access sequence
3 Combination of data Condition tables
4 Access sequence
Condition records
FAQ: How system determines pricing procedure?
ANS: Sales area (that the end user enters) plus
Document pricing procedure (Ex: OR Pricing procedure = PR00) plus
Customer pricing procedure (Ex: Whole seller, etc).
Define pricing procedure: Transaction code: V/08
Path:
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define and assign pricing procedure
Maintain pricing procedures
Click on position button
Choose standard pricing procedure RVAA01 form position button
Select it and click on copy iconon the application tool bar
Rename it and press ENTER till we get a message that is 72 entries has been copied
Save and select our pricing procedure
Click on control data icon under dialog structure
Select all conditions types by clicking on select all icon
Click on delete icon and save it (do not forget to save it)
Go to new entries and maintain values like below:
Step Cntr Ctyp Description From To Man Mdt Stat Print Subto Reqt Altcty Altcbv Actkey Accrls
10 0 PR00 ERL
20 0 Gross value 10 X 1
30 0 K004 20 ERS
40 0 K005 20 ERS
50 0 K007 20 ERS
60 0 Tot.
discount
21 59 X 2
Sales organization
Customer
pricing
procedure
Division
Distribution
channel
Document
pricing
procedure
Pricing Procedure
93
70 0 KF00 12 ERF
75 0 Net value 2
94
Step: It indicates the step number of condition type in pricing procedure. Ex: 10, 20, 30, and etc. It is possible to
number the steps in intervals of 1, but this can make changing the procedure in the future very difficult.
Counter: System uses the counter while accessing the condition types in our pricing procedure. This is used to
show a second mini step within an actual step. For example, you may have all your freight surcharges assigned to
step 100; however, there may be three condition types, each representing a different freight surcharge. Thus, you8
can assign a freight condition type to step 100, counter 1; another to step 100, counter 2; another to step 100,
counter 3; and so on.
Condition type: The condition type is the link from the access sequence all the way to the actual condition record.
We specify condition types (pricing elements) that are participating to calculate net value in our pricing procedure.
Ex: PR00, K004, K005, K007, and etc.
Description: System copies the description of the condition type from definition of condition type (V/06).
From and To: These two columns serve two purposes.
(A) As a range between the condition types of some conditions we can specify the same condition type with in
one range. So that all values of condition types added together and deducted or added to the base value.
(B) As a base to calculate further value of condition type. We can specify the base for condition type. So that
system takes the base (step).
Manual: It determines how the condition type is going to be determining in our pricing procedure manually or
automatically. Ex: Some condition types that do not have any access sequence should/can be determined manually.
That means they do not directly come to the pricing procedure automatically. Ex: Condition type PR00 can be
determined automatically and condition type HA00 (header condition) should be defined manually.
Mandatory: Mandatory indicates that the particular condition type is mandatory in pricing procedure. So that the
end user should maintain the value of a particular condition type in condition records or at least during sales order
processing. Otherwise system will not allow the document to be process for further move. Ex: Condition types
PR00 and MWST are mandatory conditions.
95
Statistical: It indicates the purpose of condition type is only for information purpose. The value of condition type
will not be taken into consideration in the net value calculation.
Ex: Condition type VPRS (cost)
As this VPRS copies cost of the material from the material (master) and deducts the value from not value
for items to calculate profit margin. So the purpose of having VPRS is only to copy the cost of the material and it is
not at all participating in calculation of net value. So that it should be a statistical.
Print: It indicates the value of the condition type can be printed in a document. Ex: X
Sub total: The value of this field determines where the value of the sub totals is going to be stored in the
database. Sub total 1 = KOMP KZWI 1 and Sub total 2 = KOMP KZWI2
Requirement: Requirement is nothing but a routine that has been written by ABAPers according to the client
requirement. Requirement is used for condition type that excludes particular condition type while determining the
net value.
Ex: Routine No: 23 and 24 can be used only in billing document with condition type BI01, BI02, and BI03
(condition types for rebates) as these condition types should be activated only in the billing document level. We
include these condition types in our pricing procedure and system deactivates at sales order level and activates in
billing document level. System takes this requirement into consideration and activates or deactivates accordingly.
PR00: As it is quite possible some items are not relevant for pricing, it is advisable to assign a requirement
indicating this condition type is not necessary for items not relevant for pricing. Assigning the requirement 002 to
the requirement column can do this.
K004, K005, K007: These condition types are only valid should the item in the sales order be relevant for pricing;
thus assign requirement 002 to the tree new discounts.
Alternative formula for calculation type: We can specify the alternative formula instead of standard one as a
condition type in the form of routines. Ex: Routine No: 11 profit margins can be used as a alternative formula for
condition type to calculate profit margin as there is no standard condition type to calculate profit margin.
Alternative formula for condition base value: Instead of using from column as a basis to calculate further value
for particular condition type we can use a formula in the form of routine to use base.
Ex: Routine No: 12 or 13 gross weight or net weight can be used with condition type KF00 to calculate fright
charges. As for freight charges always weight of the material taken as a base.
Accounting keys and accruals: We can define and assign accounting keys for each and every pricing element
groups. So that, the values of the pricing elements (condition types) can be posted in the respective G/L accounts,
through this accounting keys.
Ex: ERL = Sales revenues (Ex: PR00)
ERS = Sales deductions (Ex: K004, K005, K007, and etc)
ERF = Freight revenues (Ex: KF00)
MWS = Tax revenues (Ex: MWST)
ERU = Rebate accruals (Ex: BI01, BI02, and BI03)
Save the pricing procedure and Exit
Define determination of pricing procedure: Transaction code: OVKK
Path:
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define and assign pricing procedure
Define pricing procedure determination
Go to new entries and maintain values like below:
96
Sales
organization
Distribution
channel Division
Customer pricing
procedure
Product pricing
procedure
Pricing
procedure
Condition
type
SREENU SRI CNU A 1 SRINU PR00
Save and Exit
Maintain condition record: Transaction code: VK11
Path:
Logistics
Sales and distribution
Master data
Conditions
Select using condition type
VK11 Create
Specify the condition type PR00 and click on key combination (access sequence)
Choose first condition table ( Customer/material with release status)
Click on continue button
Specify sales organization, distribution channel, and customer number.
Specify material number and pricing amount
Save and Exit
97
NOTE: Every condition record maintained with specific to sales organization and distribution channel.
Maintain condition records for remaining condition types K004, K005, K007, and KF00 etc by repeating the same
above process.
Go to VA01 and raise the sales order
Select line item and go to Go to Header Sales and
Check our pricing procedure determine or not
Select line item and go to Go to Item Conditions in the condition screen
In the condition screen ANALYSIS and UPDATE
ANALYSIS: By using this analysis option we can analyze our pricing procedure like how many base prices,
discounts freights and taxes are taken into consideration to determine net value for line item.
UPDATE: We can carryout new pricing procedure at sales order, delivery and billing level. System does not
change the old values in the condition master records. Eg: When we raise the billing with reference to delivery
document there may be a chance to change the tax rates. Then we have to carry out new pricing procedure by
re-determining taxes.
FAQ: How you can carry out new pricing within the validity periods of condition records?
ANS: By carrying out new pricing option in UPDATE in pricing condition screen at item level.
Define our own pricing procedure:
Pricing procedure
Condition tables
Condition type
OVKK
Access sequence
Sales area + Document pricing procedure + Customer pricing procedure
Condition records
VK11 V/03 Condition table
V/07 Access sequence key
V/08
Pricing procedure
PR00
K004
K005
K007
V/06 Condition type
PR02
Material
Customer/Material with release status
Price list category/Currency/Material with release status
20/307
10/306
30/308
100
300
200
Condition records
98
Creation of pricing procedure Steps:
(1) V/03 = Create condition table
(2) V/07 = Create access sequence
(3) V/06 = Define condition type
(4) V/08 = Define pricing procedure
(5) OVKK = Define pricing procedure determination
(6) VK11 = Maintain condition records
Create condition table: Transaction code: V/03
Condition table is a combination of fields that forms a key to assign to condition type (access sequence)
Path:
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define condition tables
Create condition tables
Specify the condition Table No: Ex: 567 (between 501 to 999)
Choose the fields from the field catalog Ex: Sales organization, distribution channel, customer, etc
Click on generate icon
Click on local object
Go back and create more tables with another combination if you want
Save and Exit
Create access sequence: Transaction code: V/07
Access sequence is a search strategy that SAP follows to find out suitable condition record for condition type with
specific to generic manner.
Path:
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define access sequence
Maintain access sequence
Go to new entries
Define the access sequence with description
Save it and select it
Click on access control button under dialog structure
Go to new entries
Specify the access sequence numbers, place our condition tables and check exclusive option
Save and Exit.
99
Exclusive: The exclusive indicator prevents the system from reading the condition records, if it found value for
existing condition table. It is a control for the system to access condition record from the database.
Ex: If you assign a exclusive option for a condition table in access sequence and if the system finds condition
records for condition tables in access sequence, then system does not go to the next condition table.
Define condition type: Transaction code: V/06
Condition type represents pricing element as a base price, taxes, discounts or freight charges. While defining
condition type we assign the attributes of condition type.
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define condition types
Maintain condition types
Click on position button
Choose PR00 condition type from position button and click on copy as icon
Rename the condition type Ex: PR00 = ZSRI
Click on details icon on the application tool bar
Condition type: [PR00] = Price
Access sequence: [Ex: PR02]: Access sequence PR02 has been defined and assigned to condition type PR00. As
every condition type is associated with one access sequence that access sequence should be assign here.
Control data one section:
Condition class: [B] = Prices
It is a classification of condition types as prices, taxes, discounts, etc. as PR00 is base price. So it has been
classified as B.
Calculation type: [C] = Quantity
Calculation type for condition that is, how the calculation should be done for this condition type based on quantity
or percentage or fixed amount.
Ex: If it is K004 and K005 [B] = Fixed amount
If it is K007 [A] = Percentage
If it is KF00 [D] = Gross weight
Condition category: [] A classification of conditions according to predefined categories. For example all
conditions that is related to freight cost.
Ex: KF00 = Freight
HD00 = Freight
100
Rounding rule: [] = Commercial
Rounding rule commercial, round up or round down can be assigned.
Structure condition: [] The condition type is used in BOM or configurable material, then that can be indicated by
structure condition.
Ex: KUMU = Cumulation condition [B]
DUPL = Duplicate condition [A]
Plus/Minus: [] Positive a
The value of this field determines the value of the condition type should be added or deducted.
Ex: PR00 Positive
K004, K005, etc. all discounts Negative
Group condition section:
Group condition: It indicates whether the system calculates the basis for the scale value for more than one item in
a document.
Ex: If a sales order contains two items and both items belongs to the material group 01. The group condition
indication typeset in the definition of condition type for material group discount. [Ex: K020]. Then the condition
record for material group 01 includes the following pricing scale like [From 1 PC 1% From 200 PC 2%].
Then the order has been placed for 150 and 100 quantities for each material. Then system takes the total quantity as
250 and applies discount 2% as both materials belongs to same material. If those materials not belong to one group,
then group condition cannot be applied and system cannot apply the discount value.
Rounding difference comparison: It is an indicator that controls whether rounding difference is settled for group
conditions with a group key routine. That means the system compares the condition value at header level with the
total of the condition values at item level. Then the difference is added to the largest item.
Group condition routine: [] We can specify the routine to the group condition type [Ex: 1 Total document] to
meet the business requirement like, if the total weight of the materials of order exceeds certain weight then only the
Sold to party eligible to have certain discount amount.
Changes, which can be made section:
Manual entries [C] = Manual entry has priority
The value of this field determines whether the condition type determined manually or not at sales order level.
Ex: AMIW has a value D not possible to process manually. The value of this field controls mandatory option
indirectly.
Header condition: The value of the header condition applies to whole items in the sales order. Header conditions
do not have any access sequence. The values should be entered manually in the sales order level. Ex: HA00, BH00,
HD00, etc.
101
Check item condition: The value of the item condition applies to only at item level. Item conditions must have
access sequence. Ex: PR00, K004, KF00, etc.
Delete: This indicator enables to delete the condition type at sales order level.
Amount/Percentage: It specifies whether the amount or percentage for the condition type can be changed during
document processing. These changes will not affect the condition master data.
Value: Scope for changing the value. It specifies whether the value of the condition type can be changed during
document processing.
Quantity relation: It specifies the scope of changing conversion factors. That means whether the conversion
factors for the unit of measure in conditions of this type can be changed during document processing.
Ex: Base unit of measure is EACH Selling unit of measure is BOX
Condition records unit of measure is BOX Sales order unit of measure is EACH
Calculation type: If you want to change calculation type this indicator should be set.
Ex: Normal calculation type is fixed amount and sales order level calculation type is percentage.
Master data section:
Valid from: [] = Todays date
It specifies the beginning validity date that the system automatically proposes when we create a rebate agreement of
this type. It is most relevant for condition type B001, B002, and B003.
Valid to: [] = 31-12-9999
The proposed value for how long a condition should remain valid. System proposes this value for the valid to date
when we create the condition records.
Reference condition type: [] In our pricing procedure if we have SAME condition types, then we can maintain
condition records for one condition type and we can specify another condition type as a reference condition type for
this condition type. So that, no need to create condition records for reference condition types.
Ex: MWSI can be specified as a reference condition type for condition type MWST. So that condition records can
be maintained for MWSI only. The same way for condition types AMIW and AMIZ.
Reference application: [] If you reference one condition type for another condition type, we should specify in
which application area this referencing procedure takes place. Ex: Sales, purchasing, etc [Sales = V]
Pricing procedure [PR00]: Condition supplement: When the business wants to give certain conditions.
Ex: Discounts for all the customers and materials till certain period, then the business can use the feature that is
condition supplement where we specify the discount condition types as a condition supplements along with base
price. To implement this condition supplement feature, one separate pricing procedure should be defined and
assigned to the particular condition type [Ex: PR00] and condition records should be maintained. Then whenever
system uses the PR00 condition type those discount condition types also accompanies PR00 condition type.
Deletion from database: [Do not delete (set the deletion flag only)]: We can set system responses when the
condition record is going o be deleted from the database like with popup or without popup messages.
Check condition index: We can create condition index for this condition type. So that by using the condition
index we can maintain the condition records of this condition type.
Ex: We can change, delete, etc.
102
Condition update: This field qualifies condition index. This indicator updates the condition type.
Ex: By value.
Scales section:
Scale basis: [C] = Quantity scale
Scale is nothing but the range of order quantity. According to the pricing element depending upon the range of
quantity prices may be increased or decreased, higher discounts, low freight charges can be offered.
Ex: When 1 item cost is 100/- Rs, and if the customer placed the order for:
1 10 = 100/- Rs.
11 20 = 95/- Rs.
21 30 = 90/- Rs.
Check value: [A] = Descending
We can specify the checking rule for scale rates as a ascending or descending.
Scale type: [] = Can be maintained in condition record
The indicator controls the validity of the scale value or percentage from a certain quantity or a value. Alternatively
it is possible to work with interval scales that must be stored in the condition type. That is the scale type the interval
scale cannot be changed in the condition record due to the technical reason.
Ex: Condition type PR02 graduated scales.
Scale formula: [] We can specify the formula for determining the scale base value we can provide formulas that
has not been provided in the standard system.
Ex: Condition type KP03 to support mixed pallet surcharges can be used.
Unit of measure: [] System uses unit of measure to determine scales when we use group conditions. System
proposes unit of measure when we maintain condition records for group conditions that are either weight or volume
dependent.
Ex: K029.
Control data 2 section:
Currency conversion: It controls the currency conversion where the currency in the condition record varies with
document currency.
Ex: Condition records currency = INR Document currency = USD
To calculate a condition value in a document the system multiplies the amount that results from the
condition record by the item quantity. This indicator controls whether the system carries our currency conversion
before or after the multiplication takes place. If you mark this field the system converts the condition value into the
document currency after multiplication. If you leave the field blank the system converts the condition value into the
document currency before multiplication.
Accruals: It indicates that the system posts the amount resulting from this condition to the financial accounting as a
accruals. If you mark this field the condition appears in the document as a statistical value.
103
Invoice list condition: If the condition type is relevant for internal costing, mark this field.
Inter-company billing condition: If the condition type is inter-company billing purpose, mark this field.
Ex: Condition type PI01.
Service charge settlement: It indicates that the trading contract conditions should be calculated using vendor-
billing document.
Variant condition: If the condition type is for variant pricing [Variant configuration] marks this field.
Ex: Condition type VA00
Quantity conversion: This field controls the quantity conversion during determination of the condition bases. This
field only relevant for calculation rule C quantity dependent condition types. If you deactivated it, then the
condition bases quantity is converted via the quantity to the stock-keeping unit. This means that the condition
quantity is determined for planned factors. That means the changes to the conversion factors in the delivery or the
order are not taken into consideration.
If you activated this field, then the quantity unit and the condition quantity unit are identical. Then the
quantity of the document item is used that is actual quantity.
Exclusion: [] In SAP we can offer best condition type among the same conditions to the customer by using
condition exclusion feature. If you want to use this feature we can set the control at the definition of the
condition type or maintaining condition record level.
Pricing date: [] = Standard (KOMK PRSDT, Tax and Rebate KOMK - FBUDA)
We can specify the pricing date at which this condition to be affected.
Relevant for account assignment: [] = Relevant for account assignment
We can indicate whether this condition type is relevant for account assignment or not. It is the main control to post
the values of condition type into the respective G/L accounts.
Text determination section:
Text determination procedure: [] and Text ID: []
We can define and assign text determination procedure and ID in the IMG to get the text output.
Specify our access sequence in the access sequence field.
Save and Exit.
104
Define Pricing procedure: Transaction code: V/08
Path:
IMG
Sales and distribution
Basic functions
Pricing
Pricing control
Define and assign pricing procedure
Maintain pricing procedure
Go to new entries
Define our pricing procedure
Select our pricing procedure
Click on control data icon under the dialog structure
Go to new entries
Specify our condition types Ex: ZSRI etc
Save and Exit
Define pricing procedure determination: Transaction code: OVKK
Path:
IMG
105
Sales and distribution
Basic functions
Pricing
Pricing control
Define and assign pricing procedure
Define pricing procedure determination
Go to new entries
Specify our sales area, document pricing procedure, customer pricing procedure, specify our pricing
procedure, and condition type like below:
Sales
organization
Distribution
channel
Division
Document
pricing
procedure
Customer
pricing
procedure
Pricing
procedure
Condition
type
0003 01 OC A 1 SREENU ZSRI
Save and Exit
Maintain condition records: Transaction code: VK11
Path:
Logistics
Sales and distribution
Master data
Conditions
Select using condition type
VK11 Create
Specify our condition type Ex: ZSRI
Click on key combination push button on application tool bar
Check our condition tables are existed or not
Click on continue button or press ENTER
Maintain the values in the condition record
Save and Exit
Go to VA01 and raise the sales order
Select line item and go to Go to Header Sales and check our pricing procedure has been determined
or not (In the pricing procedure field system shows our pricing procedure name)
Exit from the screen and go to Go to Items Conditions and check the condition type and price.
Condition Exclusion Groups
In pricing procedure it is quite common that to have common condition types Ex: Different types of discounts. If
we include these discounts in pricing procedure, then customer will receive all the discounts. So that the total
discount value became higher than the actual price. So consequently business incurs loss. So as to avoid this kind
of situation we can use the option that is condition exclusion groups by which we can offer best condition among
the condition types to the customer.
Configuration Settings
Define exclusion groups: Transaction code: OV31
Path:
IMG
Sales and distribution
Basic functions
Pricing
Condition exclusion
Condition exclusion for groups of conditions
Define condition exclusion groups
Go to new entries
Define our condition exclusion group Ex: S001
106
Save and Exit
Assign condition types to the exclusion group: Transaction code: OV32
Path:
IMG
Sales and distribution
Basic functions
Pricing
Condition exclusion
Condition exclusion for groups of conditions
Assign condition types to the exclusion groups
Go to new entries
Specify our condition exclusion group (Ex: S001) and assign condition types
Save and Exit
Maintain condition exclusion for pricing procedures: Transaction code: VOK8
Path:
IMG
Sales and distribution
Basic functions
Pricing
Condition exclusion
Condition exclusion for groups of conditions
Maintain condition exclusion for pricing procedures
Click on position button and choose our pricing procedure
Click on exclusion icon
Go to new entries
Specify the condition exclusion procedure
Ex: A = Best condition between the condition types
B = Best condition within the condition types
C = Best condition between the two exclusion groups
D = Exclusive
E = Least favorable within the condition type
F = Least favorable between the two exclusion groups
Assign our exclusion group S001
Save and Exit
Go to vk11 and maintain condition records for condition types that are included in condition exclusion
groups
Go to VA01 and raise the sales order
Select line item and go to Go to Item Conditions
Check whether our condition exclusion group is existed or not
Condition supplement
Business scenario
When the business wants to give certain discounts irrespective of the customer and material till certain period, then
we can map the business scenario with condition supplement feature.
Configuration settings:
Step 1: Define new pricing procedure in V/08 and include conditions that are going to participate as a
condition supplements for base price.
Ex: Step Counter Condition type
10 0 PR00
107
20 0 K004
30 0 K005
40 0 K007
Save and Exit
Step 2: Specify this new pricing procedure in the pricing procedure field of master data section at
definition of PR00 [V/06].
Save and Exit.
Step 3: Go to VK11
Specify condition type PR00
Maintain the condition record to the line item and select line item
Go to Go to Condition supplement
Maintain condition records for K004, K005, and K007
Save and Exit
Step 4: Go to VA01and raise the sales order.
Go to Go to ItemConditions
Check whether our condition supplement is existed or not
Free Goods
Free goods can be configured in SAP by following two methods.
(1) Manually
(2) Automatically
Manually: By specifying higher level item category for a line item we can determine free goods as a free of charge
items during sales order processing.
Automatically: System proposes free of goods automatically in the sales order. In automatic free goods
configuration system follows two methods.
(1) Exclusive
(2) Inclusive
Exclusive: System configures free goods in exclusive option like free goods quantity is going to be excluded in
order quantity. Ex: For 10 items 1 item is free. Then system configures free goods as 10 + 1.
Inclusive: System configures free goods in inclusive option like free goods quantity is going to be included in order
quantity. Ex: For 10 items 1 item is free. Then system configures free goods as 9 + 1.
NOTE: In exclusive method other items also can be given as a free of charge items for order item.
Configuration steps: INCLUSIVE
SAP follows condition technique to configure free goods automatically.
Maintain pricing procedure
Path:
IMG
Sales and distribution
Basic functions
Free goods
Condition technique for free goods
Maintain pricing procedures
Choose free goods procedure NA0001 and select it
Click on copy icon on application tool bar and rename it Ex: SRI001
Condition type is NA00 and Access sequence also NA00
Save it and Exit
108
Activate free goods determination
Path:
IMG
Sales and distribution
Basic functions
Free goods
Condition technique for free goods
Activate free goods determination
Go to new entries
Specify our sales area, document pricing procedure, customer pricing procedure and specify our free goods
procedure Ex: SRI001
Save and Exit
Control free goods pricing
Path:
IMG
Sales and distribution
Basic functions
Free goods
Control free goods pricing
Control pricing for free goods item category
Choose item category TAN from position button
Specify the pricing as X = Pricing standard
Choose item category TANN from position button
Specify pricing as B = Pricing for free goods (100% discount)
Save and Exit
Maintain condition type for 100% discount
Path:
IMG
Sales and distribution
Basic functions
Free goods
Control free goods pricing
Maintain condition type for 100% discount
Check whether condition type R100 is available or not (R100 = is 100% discount)
Exit
Maintain pricing procedure for pricing
Path:
IMG
Sales and distribution
Basic functions
Free goods
Control free goods pricing
Maintain pricing procedure for pricing
Choose our pricing procedure form position button and select it
109
Click on control data icon under dialog structure
Include condition type R100 between the steps of discounts.
Specify requirement = 55 and Routine No: 28 (100% discount) in Alt. CBV.
Save and Exit
Requirement 55: The Routine No. 55 is assigned to condition type R100. If the user wants to look both revenues
and sales deductions for the free items since the product that we are going to give as a free of charge item can be
sold separately in the same sales order. Then the item category of free goods TANN has the pricing value as B.
Then the system calculates value of the free goods as 100% discount as we discussed above the same material [that
is going to be given as a free of charge item]. Some times the same item is going to be given as a normal item.
Then system calculates price for normal item and system should not calculate price for same item [free of charge
item]. So as to perform this calculation we have to assign Requirement/Routine 55 is to assign condition type
R100.
Alt CBV = 28: [100% Discount] Condition type R100 should be taken as a ZERO value. The formula 28
calculates condition type R100 value as a ZERO.
Set Transfer of cost to Main item: [Copy control]: Transaction code: VTFL
Copy control is a concept by which the system copies the data from source document to target document.
Path:
IMG
Sales and Distribution
Basic functions
Pricing
Free goods
Control free goods pricing
Set transfer of cost to main item [copy control]
Choose Billing type F2 Delivery document type LF from position button
Select it and click on item icon under dialog structure
Choose item category Ex: TAN
Click on details icon
Click on display or change icon
Choose item category as TAN again
Select it and click on details icon
Check cumulative cost
Save and Exit
Cumulative cost controls whether the cost value (VPRS) is to be copied from relevant sub items into main items.
Sub items cost are not relevant for billing.
Maintain copying control: Transaction code: VTAA
Path:
IMG
Sales and Distribution
Basic functions
Free goods
Control free goods pricing
Maintain copying control
We maintain copy control at item level category for free goods. In this field we can control whether the
free goods should also be transferred when we copy from one document to another document.
Choose source document type as QT and target document type as OR from position button
Select it and click on item control button under dialog structure
Choose AGN item category from position button
Click on display or change button
110
Again click on AGN
Click on details icon
Check Re explode structure/Free goods
Save and Exit
This indicator controls whether the free goods are copied from source document to target document or re-
determined again.
Maintain condition records for Free goods [INCLUSIVE]: Transaction code: VBN1
Path:
Logistics
Sales and Distribution
Master data
Conditions
Free goods
VBN1 Create
Specify condition type NA00
Click on key combination
Specify all the data
Choose inclusive by clicking the INCLUSIVE/EXCLUSIVE push button
Specify the Material No., Minimum order quantity (Ex: 10), Specify [from] the free goods quantity (Ex:
10), Unit of measure EA (Each), Free goods (are free goods) as 1.
Calculation procedure: We can specify the Routines for calculation procedure as 1 or 2 or 3
1 = Pro Rata (Proportionate): Ex: If the customer places order for 100 cases of material X, then customer
receives 20 cases of same material as free. That means, the business can say that buy 100 and get 20. If the
customer orders for 162 cases, then system automatically grants 32 cases as a free of cost (162x20/100 = 32 Cases).
2 = Unit of reference: When customer orders for 100 cases of material X, then the customer receives an
additional 20 cases as a free of goods. That means business can say that buy 100 get 20 free by granting 200 free
for every full of 100 cases. The customer places order for 162, then system automatically grants only 20 cases
(100x20/100=20).
3 = Whole unit: When a customer places order for 100 cases of material X, then the customer receives additional
20 cases of material X as a free of goods item. The business can say that buy 100 and get 20 free of charge items.
If the customer orders for increment of 100 that means 200 (100 + 100) items, then he gets 40. If he placed the
order for 101 199 items he gets only ZERO.
Save and Exit
Condition record for EXCLUSIVE: Transaction code: VBN1
Path:
Logistics
Sales and Distribution
Master data
Conditions free goods
Specify the discount type NA00
Click on key combination
Click on Choose inclusive by clicking the INCLUSIVE/EXCLUSIVE push button
Specify the sales organization, distribution channel
Specify customer number and validity periods, material, minimum quantity, order quantity, unit of
measure, calculation procedure, free goods (3)
Specify additional material free goods (if other goods is going to be given as a free of charge item.
Save and Exit
Go to VA01 and raise the sales order for INCLUSIVE and EXCLUSIVE.
See the Free Goods effect.
111
Condition type NRAB = Free goods: Requirement = 59, Alt CBV = 29: [only for INCLUSIVE purpose]
Requirement 59: We have to assign requirement 59 to the condition type NRAB. If the customer buys 100 cases
of product X, then he receives 10 cases of the product free. If the user would not like the additional line item in
the sales order for free goods rather than the discount of the 10 cases is represent in the same line item as other 90
cases. If the free goods discount should not apply on credit for returns that do not make reference in the previous
document.
Alt CBV 29: The condition type NRAB is to be assigned with 29 formula to support inclusive free goods
agreement where the user would have to apply the discount to the order item rather than having a sub item
generated for the free quantity.
Ex: The customer orders for 100 cases of product X, 10 cases are free instead of having a free sub item generated
b the system to represent the free 10 cases, the user would like to have a discount applied to the 100 cases line item
equal to the value of the 10 cases.
NOTE: Free goods can only be configured on document category type C (OR). That means we cannot configure
free goods on Inquiry and Quotation.
Header Conditions
SAP has delivered two kinds of condition types: (1) Header conditions
(2) Item conditions
Header conditions: The value of the header condition applies to the whole items in the sales document.
Header conditions do not have any access sequence.
So that, value of the header conditions should be maintained manually.
Ex: HA00, HB00
Configuration settings:
Include condition types HA00, HB00 in V/08 in between the discount condition types.
Go to VA01 and raise the sales order
Select line item and go to Go to button
Header Conditions
Include condition type HA00 HB00 with values [HA00 is percentage discount and HB00 is absolute
discount]
If HA00 = 1%, then system applies 1% on base value on all items in the sales order.
If HB00 = 100/- Rupees, then system applies 100/- Rupees proportionately to all items in the sales order. If sales
order has two items, then system applies 50/- Rupees to each item.
Click on activate button
Go to item condition screen
Check how system applied header conditions for line items
NOTE: Make sure that sales order contains more than one item.
Condition Scales
We can maintain scales for each and every condition type. So that we can determine pricing conditions values
depending upon the range of the order quantity.
Ex: If you maintain condition record for PR00 for material one as a 100/- Rs. For 1 material, then we can maintain
scales for this material like below:
From Quantity Price
1 10 1000
11 20 999
21 30 998
31 40 997
Configuration settings:
112
Go to VK11
Maintain condition record for PR00
Select line item and click on scales icon on the application tool bar
Maintain scales and scale rates accordingly
Save and Exit
Go to VA01 and raise the sales order
Enter the order quantity according to the scale and see the scale effect
Pricing Scales:
You can maintain the condition records with graduated scales by using it. It allows us to price an item for each
level of pricing scale. By comparison when we use normal scales the system determines one price depending on.
Ex: On the item quantity, the same price applies to the each unit of item quantity. With graduated scales the
multiple prices can appear in the pricing screen for individual item.
NOTE: Graduated scales are used in prices, discounts and surcharges. However we cannot use it for group
conditions.
Configuration settings:
In pricing procedure V/08 maintain condition type PR02 instead of PR00
Go to V/06 and select PR02 and check condition type must be D [Scale type]
Go to VK11 and maintain condition records like below
Scales to Price
10 300
20 290
50 280
Save it
Go to VA01 and raise the sales order
Enter material with quantity = 25
Observe that in the condition screen gross value per item.
Average 292/- Rs. per item. For 25 items that comes to 7300/- Rupees. That means the system calculates
per item by averaging the price with order quantity according to scale.
1
st
10 pieces = 300 x 10 = 3000
2
nd
10 pieces = 290 x 10 = 2900
3
rd
5 pieces = 280 x 5 = 1400
25 7300
7300/25 = 292
HM00 = Manual order value
It allows us to enter order value manually the difference between the old and new order value is distributed between
the items (by taking into the account net item value) taxes are re-determined for each item.
Configuration settings:
In V/08 specify the header condition HM00 after freight condition type step
Check manual option
Go to VA01 and raise the sales order
Go to header conditions
Maintain value for HM00
Click on activate icon
Go to item condition screen
Check how system proportionately applied HM00 value
NOTE: Maintain condition records for two materials in the VK11. The purpose of HM00 is to determine the order
value manually.
113
PN00 = Net Price
The PN00 condition type in the standard system allows us to specify net price per item manually.
Configuration settings:
In V/08 specify the condition type PN00 in the prices section
Check manual option [Requirement = 2 and Alt CTyp = 6]
Go to VA01 and raise the sales order
Go to condition screen
Check system determines net value per item by following the pricing procedure
Enter PN00 value manually
Then system determines PN00 value as net value for line item and deactivates PR00 value.
PMIN = Minimum Price
It is a surcharge. PMIN can be used to charge as a surcharge, if the system determines the line item price less than
the predetermined price.
NOTE: This condition type has an access sequence.
Configuration settings:
Go to VK11 and maintain condition record for PMIN
Include PMIN in our pricing procedure (V/08) with requirement = 2 and Alt CTyp = 15
Go to VA01 and raise the sales order
Check whether system has taken PMIN value or not
Minimum order values: AMIW and AMIZ
We can create a minimum value for each order using condition type AMIW.
If the value in the order header falls shorter of this minimum order value during pricing, then the system will copy it
as the net order value automatically.
It is a statistical condition and group condition.
Calculation formula 13 is assigned to AMIZ.
That calculates minimum value surcharge by subtracting the net item value from minimum order value that is
AMIW.
Business scenario: If business would like to define minimum order value for their customers Ex: minimum order
value 200 is defined for customer A (that means he should place the order that should not be less than the 200).
Otherwise he may be charged the difference amount as a surcharge by the system by using the condition type AMIZ
and AMIW.
NOTE: AMIW condition type used as a reference condition type for AMIZ. So that condition record can be
maintained only for AMIW not for AMIZ.
SALES ORDER
CUSTOMER C1 PRICE GROUP 02
CONDITION RECORD AMIW
PRICE GROUP 02 Rs. 200
Item No. 10 Item No. 20
Net item value 100 Net item value 60
AMIW 125 AMIW 75
AMIZ 25 AMIZ 15
Total value 125 Total value 75
NET VALUE 160
AMIW 200
AMIZ 40
NET VALUE 200
114
Pallet Discount
Discounts can be given on pallets KP00, KP01, KP02, and KP03
KP00 = Discounts on full pallets
Formula = 2, Alt CBV = 22 should be assigned.
Maintain condition record as 5/- Rs. per pallet.
In material master maintain conversion factors as 50 cartons as one pallet.
Go to VA01 and raise the sales order like below:
Order 1 for 50 cartons KP00 = 5/- Base Unit = CAR
Order 2 for 100 cartons KP00 = 10/- Sales Unit = PAL
Order 3 for 70 cartons KP00 = 5/- 1 PAL = 50 CAR
KP01 = Incomplete pallet Surcharge
Condition record KP01 = 50/- per pallet
50 cartons = 1 pallet
Go to VA01 and raise the sales order like below:
Order 1 for 50 cartons = 50/- per pallet
For 70 cartons = 50/- per pallet
Assign formula as 24
KP02 = Mixed Pallet Discount on Full Pallets
It accumulates the quantities of the individual items calculates discounts for complete pallet only.
KP02 = Group condition
Maintain condition record for KP02 from 1 pallet 10/-
2 pallets 20/-
In material master M1 and M2 maintain 50 cartons = 1 pallet
Go to VA01 and raise the sales order: 1
Header KP02 = 10/- Material 1 = 20 Cartons, Material 2 = 30 Cartons
Raise the sales order: 2
Header KP02 = 10/- Material 1 = 20 Cartons, Material 2 = 40 Cartons
NOTE: After entering the items in the sales order with KP02 The condition screen Go to header condition
screen See the effect.
KP03 = Surcharge for incomplete mixed Pallets
It accumulates the quantities of the individual items. It then calculates the surcharge on any fractional portion of the
total quantity.
KP03 = Group condition
Unit of measure = PAL
Scale formula = 23 (that calculates the fractional portion of the total quantity)
SKTO = Cash Discounts
It is used to retrieve the cash discount rate. It is used as a statistical value by the pricing procedure. Table T052 is
accessed using condition category E and amount is calculated from the first percentage rate of the item payment
terms.
Configuration settings:
115
Include condition type SKTO in our pricing procedure
Requirement = 9, Alt CBV = 11, and Check statistical.
In VA01 specify the payment terms
In V/08 it should be before Net Value and after Tax [between Net value and Tax]
Maintain payment terms in the customer master or sales document header
Check cash discount in material master
Customer Expected Price
This price either entered manually in the order or retrieved from the incoming I DOC through EDI.
Condition type EDI1 is used to compare the net price for each item
Condition type EDI2 is used to compare the overall item value (Net price X Quantity)
For EDI1 Alt Ctyp = 9 and EDI2 Alt Ctyp = 8
Check both Manual and Statistical
In V/08 these two condition types should exist as last steps.
Customer expected price differs from the automatically determined price or value by more than the maximum
difference allowed. Then that will regard this order as incomplete when it is saved.
NOTE: The blocked sales orders should be release by concerned person through work list
Transaction code: V.25
Path:
Logistics
Sales and Distribution
Sales
Information system
Work list
V.25 Release customer expected price
Select the sales order
Click on Release
Save and Exit
VPRS = Cost
It is used to retrieve the standard cost of the material. It is a statistical value.
Profit margin is calculated using Formula 11 in V/08. This formula subtracts the cost form the net value
In V/08 it should be check Statistical
Sub total = 8 and Requirement = 4
In V/08 at last specify VPRS condition type with statistical, subtotal = 8, and Requirement = 4
Profit: Specify the condition type = Profit Margin and specify Alt CTyp = 11
Go to VA01 Raise the sales order check the condition
K029 = Group conditions
By defining a condition as a group condition we can maintain a single condition record for a number of materials.
So that the materials are linked to condition record via pricing group field in material master, then system
allocates the value from condition record according to its scale and applies to each item proportionately.
Business Scenario: If the business wants to give certain discount for a group of materials, we can implement this
requirement by using group conditions.
Configuration settings
Include K029 condition type in pricing procedure
Create two materials with same material pricing group
Ex: Material Price group Base unit
116
M1 01 KG
M2 01 KG
Go to VK11 and maintain values for K029 by specifying material pricing group that we maintain in the
material master
Maintain condition sales like below:
From 1 KG 10/-
From 10 KG 20/-
From 30 KG 30/-
Go to VA01 and raise the sales order for two materials by specifying quantity as 70 KGs and 60 KGs
respectively and check it.
Criteria for Tax Determination:
We can assign a value ([] Blank, [A], [B]) at the sales organization level to determine the sales tax identification
number in the order and billing document.
If blank []: Priority will be
1 (ONE): If payer has a sales tax ID and different Sold to Party, the tax no. and tax
classifications are taken from payer.
The Tax no. is determined according to the tax destination country.
2 (TWO): 1
st
point does not apply
If Sold to party has a Sales tax ID and ship to Party has no Sales tax ID. The Tax No. and
Tax classifications takes from Ship to party. IF
3 (Three): 2 points does not apply.
The Tax No. and Tax classifications are taken from Sold to Party.
If value [A]: The Tax No. the Tax classifications are generally transferred from Sod to Party. The Tax
No. is transferred according to the tax determination country.
If value [B]: Tax No. and Tax classification is transferred from same way in Value A.
Tax classification: The following factors place a role in tax determination.
1. Business transaction: Domestic or Import.
2. Tax liability of the Ship to Party.
3. Tax liability of the material
PRICING PROCEDURE TAX
PRICE PR00
VAT MWST
ACCESS SEQUENCE MWST
RECORD FOR MWST
(1). Country/Ship to Party
(2). Country/Customer ID/Material ID
(3). Country/Ship to Party/Customer ID/Material ID
Valid RECORD does not apply
GERMANY / FULL TAX / FULL TAX
FRANCE / FULL TAX / FULL TAX
CONDITION TYPE MWST
ACCESS SEQUENCE MWST
Accounting
16 %
TAX INDICATOR (By FI/CO)
A1
Check Mandatory
Requirement = 10
Alt CBV = 16
Accounting Key = MWS
117
DUPL = Duplicate condition
DUPL is copied during pricing to the entire sub items assign to the main item. It makes sense to use this condition
type only for BOM items and configurable material. Ex: Material 1 has 10% of condition type UDPL and it has sub
items Ex: M2 and M3 during sales order processing the duplicate condition of 10% is displayed in components M2
and M3.
Pre Requisite: In V/06 of condition type DUPL value A should be maintained in structure condition field.
Constraints: Duplicate conditions can only be percentage rate conditions. Duplicate conditions cannot be use as
header conditions. These conditions cannot be changed manually. When we copy sales document to billing
document the condition value of duplicate condition is FROZEN. That means the condition is not re-determined
when it is copied regardless of pricing type.
KUMU = Cumulative condition
It enables the end user to display the total of the net value of an item and the sub items that belongs to that item.
Cumulative conditions cannot be used as a header conditions.
Constraints: Cumulative conditions cannot be processed manually.
When we copy sales document to billing document the condition rate and condition value of cumulative condition is
FROZEN.
Gross Price
The gross price is relevant when selling goods to end customer.
The pricing procedure RVAB02 is available as a reference for this sales process.
The pricing procedure RVABB02 is flexible as it can be used for net price calculation.
Features: RVAB02 has following functions
Entry of the Gross price and Discounts.
Separate transfer of new prices and discounts into profitability analysis.
Determination of Net prices from gross prices for customer, not subject to Tax.
Structure of the pricing procedure: RVAB02
(1) Prices: Gross price determination [Condition type] = PR01.
(OR)
Gross price entry [Condition type] = PB00.
Displaying the gross price in sub totals.
(2) Discounts: Gross discount determination and entry
Displaying the cumulative discounts in a sub total.
(3) Taxes: Determination of tax contained in price [Condition type MWI1]
Determination of tax contained in discounts [Condition type MWI2].
(4) Net Prices and Discounts: Option of transferring net prices and discounts into the profitability analysis
separately.
118
(5) Rounding correction: The correction with the condition type NETD is necessary as there may be differences
between the total of MWI1 + MWI2 + MWIS.
Net Sales: RVABB02: In the case of net sales (customer not taxable or foreign business) the condition type MWIG
is used instead of MWIS and net goods value is determined. If we wish to we can calculate tax on the net value
VAT.
NOTE: Requirement 70 and 71 in the pricing procedure controls whether a sale is net or gross.
Condition Record maintenance
Changing condition records manually: Transaction code: VK12
Path:
Logistics
Sales and Distribution
Master data
Conditions
Select using condition type
VK12 Change
Enter condition type
Click on continue button
Select Record
Maintain data
Click on executive icon [F8]
Enter material, amount
Save and Exit
Maintaining changes automatically
If you want to apply the same price charges Ex: 5% increase to number of different condition records we can
change it automatically.
Go to VK12
Select condition record
Click on change amount icon
We can change the condition value by percentage, by absolute amount, by rounding rule
Click on copy
Go back (to deduct the value specify Minus)
Upper limit and Lower limit
We can specify the upper limit and lower limit to the condition record. So that the end user can manipulate the
condition record with that limits only.
Go to VK11 or VK12
Select condition record line item
Click on details icon [F6]
Specify the upper limit and lower limit
Save and Exit
Change document for condition record
We can display the reports of changed condition record.
Go to VK11
Change the price 2, 3 times
119
Save and Exit
Go to VK12 again
Choose environment Changes Per condition record
See the changes
Mass maintenance
We can maintain the condition records in mass VK31.
Path:
Logistics
Sales and Distribution
Master data
Conditions
VK31 Create
You can make changes for prices, discounts/surcharges, freights and taxes conditions.
Copying condition records
The copying function allows us to create multiple condition records at a time. We can copy either one or more
existing condition records into a new condition record or we can create a new condition record and use it as a base
for copying condition records all in one step. We can copy condition records even when source and target records
have different condition types condition tables key field values.
Pre Requisites: Only one table may differ between two condition fields. The condition table must contain same
number of fields.
Copying rules
There are rules are defined in IMG for sales and they must need the pre requisites listed above.
Path:
IMG
Sales and Distribution
Basic functions
Pricing
Copy control for conditions
Copying rule for condition type
Copying rule for condition
Examples of different scenarios:
Scenario 1: Same condition types and same condition tables:
Special discount to a particular price group.
(A group of customers in VD01) in this case condition type K020 Condition table 20 are identical for
both source and condition records.
Scenario 2: Same condition types and different condition tables
If PR00 has access sequence of PR02 to which number of tables are assigned.
It means condition records with same condition type can have different keys. We can copy condition
records where condition type is the same but condition tables are different.
120
Ex: Material specific discount to a particular price group (K032 is the condition type 32 is the condition
table) we can copy this condition record for a specific customer [K032 5] (K032 is the condition type 5
is the condition table).
Scenario 3: Different condition types different condition tables
Ex: K020 20 (K020 is the condition type 20 is the condition table) to another price group but to a new
customer specific discount K007 7.
Configuration steps:
In VD01 for two customers maintain the data like below:
Customer No. Customer group Price group: (for K020)
X 01 01
Y 02 02
Maintain the condition record for K020 for 01 01 combination in VK31
Go to VA01 and raise the sales order for customer X (01 01 combination) and
Go to item condition screen
Check whether K020 value has been accepted or not (system accepts because already we maintained the
condition record)
Go to VA01 and raise the sales order for customer Y for (02 02 combination)
Go to pricing condition screen and check K020 value has been taken or not
(System does not take it) because we did not maintain condition record
Go to VK32
Select discount/surcharges
By price group
Specify K020 and price group as 01
Click on copy condition/select rule button
Then system copies it to the new group
Save it
If you want to delete the condition
Go to VK12
Select the condition item
Click on delete row icon
Click on undo icon
Condition Index: We can create condition index to maintain the condition records for prices, surcharges and
discounts.
In SAP standard condition indexes are 0001 for Material
0002 for Customer
By using these two indexes we can select the condition record for a specific customer and specific material. We
can define our own condition indexes for each condition type and before using condition index must be activated in
IMG.
We can create the condition index by copying the existed condition index.
We can choose the fields from field catalog to create condition indexes and we can include new fields into the field
catalog.
Create condition indexes by using condition tables 501 to 999.
Generated condition index (system automatically activates it)
121
In the field condition index on the details screen of the respective condition type, select the condition types to be
taken into account for the condition index.
Re Organization of standard indexes
We must reorganize condition indexes in the following cases:
We must create a new condition index and we want to set it up for existing condition records. If we want to change
an existing condition index and we want to set it up with current condition records.
Steps: Enter a condition index or interval of indexes.
And then enter the date and time when the condition indexes are updated.
Pre Requisite: In V/06 condition type condition index option should be activated.
Transaction code: OV09
Path:
IMG
Sales and Distribution
Basic function
Pricing
Pricing control
Maintain condition index
Maintain condition tables for index
Choose condition tables from field catalog Ex: Sales organization, Distribution Channel, and Division
Click on generate icon
Click on local object
Come back
Save and Exit
Transaction code: V/I1
Click on activate of condition index
Check whether system has activated condition index or not
Save and Exit
Go to V/07
Choose access sequence Ex: K004
Go to new entries
Include our condition index
Save and Exit
Go to V/06
Choose K004
Check condition index and condition update has been activated or not
Go VK11
Choose our condition table
Maintain condition record
Save and Exit
Go to VK12
Click on select using index option
Select our condition table
Click on execute icon
Do the changes accordingly
122
Click on details icon
Maintain the lower limit and upper limit, if we want to maintain the limits
Go to button Additional data
Maintain limits for pricing like below:
Maximum condition value INR
Maximum number of orders
Maximum condition base value EA
We can specify the maximum condition value for this condition type. So that when system reaches that maximum
value, then automatically it terminates the condition type. If you specify maximum number of orders Ex: 3 system
will accept this condition type only for first 3 sales orders. 4
th
sales order onwards system world not take this
condition type.
Maximum condition base value: We can specify the maximum condition base value for the condition record.
Ex: If certain discount offer to the customer with a limited number of cases, then we can specify the number of
cases in this field. When the systems reach this, and then automatically terminate this condition type.
Cumulative values: When system updates the values according to the limits for pricing fields, we can see the status
of updating by going to Extras Cumulative values option Save and Exit.
Go to VA01 and raise the sales order for 3 times.
Check whether system has taken K004 or not
Go to VA01 4
th
time and check whether system has taken K004 or not.
Pricing condition report
We can generate report for prices, discounts, freights, and taxes.
Pre Requisites: For respective condition type, condition update and index should be activated in definition of
condition type. That means condition table for condition index should be defined and maintained.
Configuration steps: Transaction code: V/LA
Path:
IMG
Sales and Distribution
Basic functions
Pricing
Pricing control
Maintain pricing report
Create pricing report
Specify the name of List [] and Description []
Choose the fields that we have selected to create condition index
Ex: Sales organization, Distribution channel, Division, Material, Customer, etc.
Go to edit
Choose continue with AND
Select our condition table that we have created for condition index
Click on continue arrow
Choose report header level, item level layer
Select default values for the selection screen
Ex: Display scales and display validity period
Save and Exit
Run the pricing report: Transaction code: V/LD
123
Path:
Logistics
Sales and Distribution
Master data
Information systems
Condition & Pricing
Pricing reports
Specify pricing report [A1]
Click on execute icon
Again click on execute icon
Specify the values in the selection screen
Execute
Account determination (SD & FI Integration) FI settings for SD
Define company
Path:
IMG
Enterprise Structure
Definition
Financial Accounting
Define company
Go to New Entries
Define your Company
Save and Exit
Define company code
Path:
IMG
Enterprise Structure
Definition
Financial Accounting
Edit, Copy, Delete, Check Company code
Edit Company code data
124
Go to New Entries
Define your Company code
Save and Exit
Assign company code to company
IMG
Enterprise Structure
Assignment
Financial Accountancy
Assign Company code to Company
Choose our Company code from Position Button
Specify our Company in Company Field
Save and Exit
Define Business area
Path:
IMG
Enterprise structure
Definition
Financial accounting
Define business area
Go to new entries
Define your business are
Save and Exit
Define Consolidated Business Area
Path:
IMG
Business consolidation
Integration: Preparation for consolidation
Provide Information for transactional sending system
Define Consolidation Business Area
125
Business area account assignment (SD setting)
Path:
IMG
Enterprise structure
Assignment
Sales and Distribution
Business area account assignment
Define rules by sales area
Choose our sales area from position button
Assign the determination rule 001 or 002 or 003
Save and Exit
Assign Business area to Plant and Division
Path:
IMG
Enterprise structure
Assignment
Sales and Distribution
Business area account assignment
Assign business area to plant and division
Go to new entries
Choose our plant and division and assign sales are
Save and Exit
NOTE: Business area can be determined by sales area or by plant and division.
Assign Business area to Plant/Valuation area and Division: Transaction code: OMJ7
Path:
IMG
Enterprise structure
Assignment
Logistic general
Assign business area to plant/valuation area and division
Click on Plant Division
Go to new entries
Specify plant division and our business area
Click on Valuation area Division
Go to new entries
Specify valuation area as Plant, specify division and business area
Save and Exit
Define Purchase Organization
Path:
IMG
Definition
Material Management
Maintain Purchasing Organization
126
Go to New Entries
Define your Purchasing Organization
Save and Exit
Assign Purchase Organization to Company code: Transaction code: OX01
Path:
Partner control: Since in sales and Distribution processing in the R/3 system the right partner is automatically
setup with the required functions in document.
Process flow for partner determination:
1. Define partner functions for different tasks.
2. Combine these partner functions together into PARTNER PROCEDURE and assign these to the document
types.
3. Assign business partner functions on the debit side to customer group.
142
Partner functions: By assigning a partner function to a partner we can determine which functions partner fulfils in
the business processes.
A partner can have more than one function.
Ex: Sold to Party, Ship to Party, Bill to Party, Payer, Forwarding agent, Contract person, etc.
Among these, Sold to Party to Payer are mandatory partner functions.
Partner functions are classified using partner types.
Partner types enable general scheduling of partner function as in creditors, customer, personal and contact person.
Partner type Customer: Sold to party, Ship to party, Bill to party, and Payer.
Partner type Contact person: Contact persons are natural persons to whom we must contact at the customer for
business processing. We can create contact person in customer master record.
Partner type Vendor: Forwarding agent
Partner type Personal: Employee responsible, Sales person
Partner determination procedure: In the partner procedure we can determine whether partner functions
can/should occur in a partner object (customer master, sales document, item category, etc)
We can determine partner functions for the objects.
By assigning procedure we determine for which account group, which sales document type, for which item
categories this procedure is valid.
Customer Master
Sales Document Header
Possible partner functions
Partner determination
procedure for
Sales document
TA = Sales order
AS = Assortment
Partner determination
procedure for
Customer master
SP = Sold to party
SH = Ship to party
BP = Bill to party
PY = Payer
Sold to party
Ship to party
Bill to party
Payer
2 2
1 1
Assignment to
Document type
QT = Quotation
TA = Sales order
Assignment to
Account group
0001 = Sold to party
0002 = Ship to party
0003 = Bill to party
0004 = Payer
143
In partner determination procedure we can determine each partner function:
Whether the partner function is an obligatory partner function
Whether the partner function may be changed in the documents.
Partner determination is used in the sales and distribution processing in two ways:
1. Creating customer master
2. Creating sales documents
Authorized partner for release orders: When we create a release order for a contract, we enter the contract
number and the name of the partner who requesting goods. Then system checks if the business partner is authorized
to release contract.
Then system checks the:
Partner in the contract (Rule A).
If partner has partner functions (AG) (AA) Sold to party for releasing orders in the contract. Then system
accepts Sold to party for releasing order.
Partner in the hierarchy (Rule B)
After authorization check, the system also checks if more than one Ship to party is defined in the contract. If
system contains WE (Ship to party) and several AWS (Ship to party to release orders), then the system
lists the possible Ship to party in a dialog bin. We can define authorized Sold to parties (AA) and addition
Ship to parties (AW) in the customer master record. When we create contract for customer these partners are
proposed for selection.
Pre requisite:
Activate partner determination check in VOV8 of contract document type.
Partner determination procedure KAB (Partner in contract) contains the partner function AA/AW. We
must assign this procedure to the sales document types (contracts) for which the partner authorization
check is relevant. Make this assign in IMG.
Define and assign partner determination procedure.
Copy control we can determine only releasing partner should copy from contract to release order, and other
partners are copied from customer master of the Sold to party.
Configuration steps:
Define account groups: Transaction code: OBD2
Path:
IMG
Financial accounting
Accounts receivable and accounts payable
Customer accounts
Master data
Preparation for creating customer master data
Define account groups with screen layout (customer)
Go to new entries
Specify your account group and description
Save and Exit
NOTE: Select one time customer account if he belongs to one time account customer.
Specify output determination procedure: We can specify the output determination procedure in the customer
master from where system automatically proposes output type in the sales document.
144
Define number ranges: Transaction code: XDN1
Path:
IMG
Financial accounting
Accounts receivable and accounts payable
Customer accounts
Master data
Preparation for creating customer master data
Creating number ranges for customer accounts
Click on change intervals icon
Click on insert intervals icon
Define number range
Save and Exit
Assign number ranges to customer account groups: Transaction code: OBAR
Path:
IMG
Financial accounting
Accounts receivable and accounts payable
Customer accounts
Master data
Preparation for creating customer master data
Assign number ranges to customer account groups
Choose our account group from position button
Specify number range key that we defined previous
Save and Exit
Define partner functions
Path:
IMG
Sales and distribution
Basic functions
Partner determination
Setup partner determination
Setup partner determination for customer master
Click on partner functions control button
Go to new entries
Define your partner functions [OR]
Choose existed partner functions like below:
Partner function Name Partner type Unique in customer master
SP Sold to party KU
SH Ship to party KU
BP Bill to party KU
PY Payer KU
Save and Exit
145
Define partner determination procedure
Click on partner determination procedure under control button
Go to new entries
Define your own partner determination procedure
Save and Exit
Assign partner functions in the partner determination procedure
Select our partner determination procedure
Click on partner functions in procedure
Go to new entries
Specify partner functions like below:
Partner determination
procedure
Partner
function
Name Not
changeable
Mandatory
SP Sold to party
Ex: SREE SH Ship to - party
BP Bill to party
PY Payer
Save and Exit
Partner determination procedure assignment
Click on partner determination procedure under dialog structure
Choose our account group from position button that we defined in OBD2
Assign partner determination procedure that we created in the previous step
Save and Exit
Account groups Function assignment
Click on account groups function assignment button under dialog structure
Go to new entries
Specify partner functions
Partner function Name Account group
SP Sold to party 0001
SH Ship to party 0001
BP Bill to party 0001
PY Payer 0001
Save and Exit
Go to XD01 to create customer master Save Exit
Go to XD02 Extras Administrative data
Check our partner procedure existed or not
Partner determination procedure for sales document header
146
SAP uses condition technique to determine partner functions for sales document header and item. We can
determine partner functions to sales document header directly or we can propose partner functions from customer
master.
Configuration settings:
Define partner functions
Path:
IMG
Sales and distribution
Basic functions
Partner determination
Setup partner determination
Setup partner determination for sales document header
Go to partner functions under dialog structure
Go to new entries
Define partner functions [OR]
Choose existed partner functions like below:
Partner function Name Partner type Unique in customer master
SP Sold to party KU
SH Ship to party KU
BP Bill to party KU
PY Payer KU
Save and Exit
Define partner determination procedure
Click on partner determination procedure under dialog structure
Go to new entries
Define partner determination procedure
Save and Exit
Assign partner functions in the partner determination procedure
Select our partner determination procedure
Click on partner functions in procedure
Go to new entries
Specify partner functions like below:
Partner determination
procedure
Partner
function
Name Not
changeable
Mandatory
SP Sold to party
Ex: SREE SH Ship to - party
BP Bill to party
PY Payer
Specify [] blank in the [C] original table (as partner functions from KNVP or AG mandatory partner type KU).
Save and Exit
Partner determination procedure assignment
147
Click on partner determination procedure assignment under dialog structure
Choose our sales document type OR from position button
Assign our partner determination procedure that we defined previous step
Save and Exit
Assign partner functions to account group
Click on account groups function assignment under dialog structure
Check our account group has been assigned to our partner determination procedure by system
automatically.
(OR) Assign partner functions to our account group
Save and Exit
NOTE: Partner functions in the sales document header directly proposed into sales document header from customer
master.
Go to VA01 and raise the sales order with our newly created customer.
Go to go to button Header Partner and check our partner functions are proposed or not
Go to go to button Item Partner and check partner functions in shipping tab and billing tab
Save and Exit
Output determination
Output is a form of media from a business to one of its business partners. Ex: Printouts, Faxes, Telexes, E mails
and Electronic Data Interchange (EDI). The Output determination component offers output functions for Sales,
Shipping and Billing to help in manage sales transactions with our customers and within the organization.
Output can be sent to any of the partners defined in the document.
Outputs are usually in the form of order confirmations, delivery notes, invoices and shipping notifications.
The output determination component offers output functions for sales, shipping transportation and billing to help in
manage sales transactions with our customers and with in the organization.
We can create output.
We can group output.
Employers can send/receive output.
Output directly linked to the corresponding sales transaction Ex: Trough EDI.
System automatically proposes output for a sales and distribution document.
System uses condition technique to determine output.
We use output type to control how the output should be transmitted.
148
Ex: Via EDI, be printed.
We can determine output for all kinds of objects in SAP SD. Ex: For sales activities sales documents delivery
documents and billing documents.
We can determine output, we can process output, and we can send output.
SAP uses condition technique to determine output.
Output types can be Inquiry, Quotation, Order confirmation, Shipping document, Billing document, etc.
The output can be sent through transmission mediums.
Ex: Local printer, Fax, Telex, E mail, SAP inbox or even to SAP.
Output determination closely integrated with technical module as technical consultant prepares the output format in
SAP script or smart forms.
Configuration settings:
Output determination for sales documents: Transaction code: V/57
Path:
IMG
Sales and distribution
Basic functions
Output control
Output determination
Output determination using the condition technique
Maintain output determination for sales documents
Maintain condition tables
Maintain output condition table for sales documents
[ ]
[ ]
[ ] Open orders [ ] Open deliveries
Horizon [1] [M] (Dynamic only)
Maximum document value [ ]
Check by giving different values in above fields.
Check by giving maximum document value and without maximum document value.
[] Static: It indicates whether system has to carryout static credit check.
[] Reaction [A] = Warning: Specifying the reaction of ht system when system carries out the credit check.
Status/Block: System sets the credit status after carrying credit check.
[] Open orders: It takes the open order value.
[] Open deliveries: It takes the open deliveries value.
265
[] Dynamic: It indicates whether system has to carryout dynamic credit check.
Reaction [A] = warning
Check Status/Block
Horizon [1] [M] one month
[] Document value: It indicates whether system has to carryout credit check based on the document value.
Specify the Reaction, Status/Block and Maximum document value [ ]
It specifies the maximum document value for credit check based on the value of a sales order or delivery.
Use: It will be useful for new customers, for whom credit limits have not yet been established. That credit check
can be triggered by the risk category that we define especially for new customers.
[] Critical fields: It specifies whether system has to carryout credit check against critical fields (fixed value dates).
If you check this field the system checks whether critical fields have been changed.
Ex: Payment terms
Additional value dates
Fixed value dates
Specify the Reaction and Status/Block
NOTE: It is only useful for sales documents.
[] Next review date: It specifies whether system has to carryout credit check against next customer review date.
Use: 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.
NOTE: We can specify the time buffer for this type of credit check in the next field, and we can specify number of
days that are added to the next credit review date.
Specify the Reaction, Status/Block, and Number of days []
Open items: It specifies whether system has to carryout credit check based on the over due of open items.
Use: This type of credit check works in conjunction with two fields.
(A) Maximum percentage of over due items in open items.
(B) Number of days, which the open items are over due.
Specify the Reaction, Status/Block, Maximum open item % [] and Number of days for considering open
items [ ]
[] Oldest open item: It specifies whether system has to carryout credit check based on the age of the oldest open
item.
Use: The oldest open item must not be older than the number of days specified.
If you do not want to deliver to the customer even, when one invoice is over due.
Check the Oldest open item
Specify 1 in the field Days oldest [ ] (It is number of days that are allowed for overdue of payment
terms).
Use of this kind of check: If the user attempts to alter the order quantity of the released sales document that was
previously blocked, it would be re blocked again by the system.
Specify Reaction, Status/Block
[] Highest dunning level: It specifies whether system has to carryout credit check against highest dunning level
allowed.
266
Use: It specifies the highest dunning level that we want to use in the next field. The dunning process is recorded in
the customer master credit record.
The highest dunning level exceeds during order or delivery level this credit check can be carried out
Specify the Reaction, Status/Blocked, and Highest dunning level [ ]
[ ] User 1
[ ] User 2
[ ] User 3
This field is inactive in the standard system, but can be used for credit check that we defined.
Save and Exit
NOTE: In VOV8 of OR check credit limit field must be [D] = Automatic
System carryout automatic credit check based on the credit control area, risk category and credit group.
Automatic credit check steps
Customer master should have been created by using transaction code XD01
In VOV8 of OR check credit limit field must be [D] = Automatic
FD32 should have been created and credit limit should have been specified/maintain
(When we define the credit control area system automatically creates FD32)
In VOV8 of OR we should specify the credit checking method as: Simple, Static, Dynamic, Document
value, etc.
Go to VA01 and raise the sales order. Check the system statuses regarding credit check
Go to VL01N and check the system status, whether the system blocked the delivery or not
So as to release the blocked document go to VKM4
Maintain the selection criteria
Click on execute icon
Select the document
Click on release icon
Save and Exit
Go to VL01N and raise the delivery process
Go to VF01 raise the invoice
267
Transfer of Requirements and Availability check
Transfer of Requirements [SD + MM + PP]: As the end user specifies the customer material number in the sales
order system has to confirm the quantity in a particular day. So, as to confirm the quantity on a particular day
(customer requested delivery date) system should know the requirements of the particular material for sales order or
delivery.
System can get the requirements of the order/delivery of a material by a function called Transfer of Requirements
9TOR).
TOR carries out requirements of order to MRP and creates a demand. Once TOR creates a demand with MRP, then
system can carryout availability check for particular material for particular order? During carrying out the
availability check function system tries to determine ATP (Available to Promise) quantity.
System calculates ATP quantity by taking Warehouse stock plus Planned receipts minus Planned issues.
ATP quantity = Warehouse stock + planned receipts Planned issues.
Planned receipts: Planned orders, Production orders, Purchase requisitions, Purchase orders, Stock in transfer,
Stock in transit, Stock at inspection, etc.
Planned issues: Sales orders, Deliveries, etc.
System creates a demand with MRP by requirement type 041.
Path to see the requirement type is sales order overview screen (VA01) Procurement tab Requirement type
041.
At the same line system shows ATP quantity also.
The requirement type points to requirement class that defines requirement class:
Whether availability check is carried out for a transaction,
Whether the requirement is relevant for MRP,
The allocation indicator from the sales view, which controls the settlement of the customer requirements with a
planned independent requirement,
Whether the item is to be settled to an auxiliary account assignment, the settlement profile, and the result
analysis key.
NOTE: The TOR and Availability check are controlled globally using the requirement class for all sales
documents. Depending upon the transaction we can deactivate these functions in the schedule line category of sales
document.
Ex: For inquiry and quotation system need not to carryout TOR and availability check functions. So that we can
deactivate these two controls in the definition of the schedule line category, as these controls directly proposed from
the requirement class into schedule line category.
Requirement type: Requirement type is going to be determining by item category + MRP type as a one of the
factor.
Ex: Requirement type = Item category group + MRP type
041 = TAN + PD
System determines requirement type by following a search strategy like below:
(1) It first searches the strategy group from MRP3 view in material master.
(2) If strategy group has not been maintained, then it will go to the MRP group in the MRP1 view of material
master.
(3) If MRP group has not been maintained system uses material type instead of MR group (Ex: Finished
product, etc).
(4) If no requirement type is found here, then the system assumes a special rule that is Item category and
MRP type.
(5) If this is not possible, then system tries to find out the requirements only with item category.
(6) Finally system assumes that this transaction is not relevant for TOR and availability check.
268
Transfer of Requirements = Requirement + Requirement class
041 +
TOR
041 Availability check
Product allocation
Configuration settings: As SAP provided standard settings we need not to configure new settings.
Define requirements classes: Transaction code: OVZG
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of Requirements
Define requirements classes
Choose standard requirement class 041from position button
Select it and click on details icon
Check
Availability
Requirement transfer
Product allocation
Save and Exit
NOTE: These values will be proposed into definition of the schedule line category.
Define requirements types: Transaction code: OVZH
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of requirements
Define requirements types
Choose requirement type 041 from position button
Assign our requirement class
Save and Exit
Determination of requirements types using transactions
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of requirements
Determination of requirement types using transaction
Choose item category TAN and MRP type PD
Item category Requirement type
TAN
TAN
+
+
PD
=
=
041
041
Save and Exit
269
Define procedure for each schedule line category
Here we specify for the respective schedule line categories of the sales documents whether an availability check and
TOR functions should be carried out or not.
It offers a fine-tuning to TOR and availability check functions at schedule line category level.
We can only deactivate an option that we selected in the requirement class level. But we cannot activate it.
Ex: We activated TOR and availability check functions in the requirement class level, and we can deactivate at
schedule line category level. But this deactivation will not affect the requirement class.
NOTE: If we do not activate these functions in the requirements class level and you tried to activate in the schedule
line category, then system would not accept it (if will not effect).
Use: If we want to implement availability check function without TOR function at requirement class level, TOR
and availability check functions should be activated and TOR function should be deactivated at schedule line
category level.
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of requirements
Define procedure for each schedule line category
Case 1:
Case 2: It should carryout availability check function without transfer of requirements in schedule line CP.
NOTE: Here system follows 6 steps search strategy that we discussed previous.
Choose schedule line category CP from position button
Check availability check
Availability check
TOR
Product allocation
Save and Exit
Requirement
type
Sales order
041
It carries TOR and Availability check functions
041
Requirement class
OR
TOR
Availability check
Product allocation
Global settings
CP
TOR
Availability check
270
Block quantity confirmation in delivery blocks
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of requirements
Block quantity confirmation in delivery blocks
Deliveries: Blocking reasons/Criteria
When requirements transferred to MRP, the confirmed quantity is also reserved for confirmed sales documents. If
the transactions are blocked for delivery the required stock will be blocked. So it cannot be used elsewhere in the
system. To prevent this, we can block the TORs for delivery block in this step.
In this case the order quantity will still be transferred to MRP as a requirement. But it will not be reserved. We can
see this one by going to change mode of the sales document in the schedule lines that specifies zero (0) or
confirmed quantity.
When the block is removed the availability check is automatically carried out by the system, and also we may push
back the material staging date by number of days.
NOTE: We can carryout availability check at anytime in spite of these blocks if transaction permits. Then system
creates a temporary schedule lines with confirmed quantities, which are then removed when the document is saved.
Choose Blocking reasons/Criteria from position button
Ex: 01 = Credit limits
Check
Confirmation block
Picking block
Goods issue block
Save and Exit
Maintain requirements for Transfer of Requirements: Transaction code: OVB8
Here we can maintain our own requirements for TOR
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Transfer of Requirements
Maintain requirements for Transfer of requirements
Ex: Requirement 102 That prevents reservations from being created in the event of a credit block
Save and Exit
Maintain requirements for purchase and assembly orders: Transaction code: OVB5
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer or Requirements
Transfer of Requirements
Maintain requirements for purchase and assembly orders
271
Ex: 102 = Purchase requisition
105 = Assembly
106 = Block construction
Save and Exit
Availability check
In SAP availability check can be carried out in the sales orders and deliveries for an item, and also it creates MRP
records and passes them into materials requirement planning.
Availability check is carried out at plant level.
SD settings:
(1) Define requirement class:
(2) Define checking group:
That determines standard Replenishment Lead Time (RLT) [together with MRP group], and the type of
requirement records.
Ex: Individual records or summarized records to be created.
(3) Define checking rule: It determines the scope of the availability check and whether or not RLT should be
taken into consideration.
Material master record specifications: We should specify the below settings to carryout availability check and
TOR.
(1) Checking group: (Sales/Plant data view or MRP2)
(2) MRP group: (in MRP1 view) system uses this group to determine requirement type relevant for
transaction.
(3) Strategy group: It will be used as an alternative to MRP group.
Availability check can be carried out by:
(1) With ATP logic or against planning:
(2) Against product allocation: It will be used, when the shortage of the supply of the material. During sales
order processing an availability check can be carried out against product allocations. The result of this
check informs whether an order requirement can be confirmed according to product quantity allocated to
customer.
(3) Rules based availability check: With this check we can carryout availability check in several plants and
with several alternative materials. It will be useful in the APO (Advanced Planner and Optimizer).
Configuration settings:
Define checking groups: Transaction code: OVZ2
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Define checking groups
272
Define checking groups by which we specify the type of requirements that system has to create during
sales order or delivery document processing
Requirements can be individual requirements or summarized requirements
Individual requirements are created for each sales document
Summarized requirements are a group of requirements for a particular material. Summarized requirements
are again two types:
(1) Summarized requirements per each day.
(2) Summarized requirements per each week.
The value of this field will be proposed into material master in Sales/Plant view.
02 Individual requirements Total sales order requirements [A]
Total delivery requirements [A]
Block quantity required
System gives the message for blocked requirement for the user.
Save and Exit
Define material block for other users
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Define material block for other users.
Here we defined each checking group and initiator.
Whether the material master record should be blocked for other orders during availability check.
If it is blocked we cannot create two orders for the same material at the same time.
Specify 02 = Individual requirements
Initiator [A]
Block
Save and Exit
Define checking groups default values
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer or Requirements
Availability check
Availability check with ATP logic or against planning
Define checking groups default values
In this step we define the checking groups that the system proposes when we create a new material master record.
The default value depends on the material type and plant.
Go to new entries
Specify material type Ex: FERT, Plant and Requirement type [02]
Save and Exit
273
Carryout control for availability check: Transaction code: OVZ9
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer or Requirements
Availability check
Availability check with ATP logic or against planning
Carryout control for availability check
We define the checking rules for availability check and allocate them to the checking group.
The checking rule specifies the scope of the availability check for the respective transactions in SD by which we
can tell to the system, which kind of planned receipts and planned issues we should take into account during
availability check.
Every checking rule allocated to checking group. These two elements control the availability check.
Ex: Checking group 02 = Individual requirement.
Checking rule 01
Save and Exit
Define procedure by requirements class: Transaction code: OVZ0
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Define procedure by requirements class
The settings that we see in this step copied from globally specified settings that are (TOR) transfer of Requirements.
Ex: 041 check
Availability check
TOR
Product allocation
Save and Exit
Define procedure for each schedule line
Path:
IMG
Sales and Distribution
Basic function
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Define procedure for each schedule line category
These settings also proposed from TOR only.
Save and Exit
274
Determine procedure for each delivery item category
In this step we can Switch on or Switch off the availability check for particular items in the delivery.
Ex: For return orders we should switch off.
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Determine procedure for each delivery item category
Save and Exit
Checking rule for updating back orders
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Checking rule for updating back orders
We assign a checking rule to a plant. The checking rule that we entered here is used in the production planning.
During back order processing (CO06) and the availability overview (CO09) we should make sure that we are not
using any checking rules that deviate from the SD configurations.
Checking rule A for orders, and B for deliveries
Save and Exit
Define default settings
In this step we can propose the result of the availability check, and we can set the indicator for fixing the date,
quantity and rules.
Path:
IMG
Sales and Distribution
Basic functions
Availability check and Transfer of Requirements
Availability check
Availability check with ATP logic or against planning
Define default settings
(A) Fixed date and quantity: We specify for a sales area whether the delivery dates and quantities
confirmed after availability check should be set.
(B) Rules for transferring the availability results: Here we can specify the system response to shortage
for a sales area.
Ex: One time delivery or full delivery in the dialog box.
Choose our sales area
Fixed date and quantity
275
Specify the system responses in the case of the shortage of the material in availability checking rule [D] =
Dialog box for delivery (one time delivery).
When we have insufficient stock (Ex: 100 quantity in the storage location) and the system response is D (one time
delivery) and order quantity in VA01 is 200. Then system confirms only 100.
Save and Exit
276
Inter company sales
In the normal business process the end customer place the purchase order with ordering plant. Then the ordering
plant if the material is not available then the ordering plant will raise the purchase order with delivering plant, and
the delivering plant raises the sales order with reference to purchase order, subsequently it will deliver the foods
directly to the end customer, and issue on INTER COMPANY BILLING to ordering plant. Then the ordering plant
raises the standard invoice in favour of end customer. With this step inter company billing/sales process will
complete.
Pre requisites:
One customer existed to represent ordering plant, to place the purchase order with delivering plant.
Direct customer should exist to raise the sales order with ordering plant.
Material should be existed and extended in both plants.
In the pricing procedure to represent inter company billing condition type PI01 should be existed.
PI01 = Absolute amount
PI02 = Percentage
Customer Delivery
Company code 2200 Company code 1000
P.O
S.O
F2
Sales organization
Distribution channel
Division
Plant
Storage location
Shipping point
2200
10
00
2200
0001
2200
Purchase order
Sales order
Inter company billing [IV]
Inter company customer
Sales organization
Distribution channel
Division
Plant
Storage location
Shipping point
1000
12
00
1200
0001
1200
ERROR: For object RF_BELEG 1000, number range interval <50> does not exit FBN1
Go to FBN1 and create number range with Number key <50> and Current year
Save and Exit
Customer 123 Customer created in this sales
area to raise sales order
Company
Company code 2200 Company code 1000
FRANCE GERMANY
Sales organization 2200
Distribution channel 10
Division 00
Sales organization 1000
Distribution channel 12
Division 00
Purchase
Order
VF01
Plant 2200
Storage location 0001
Shipping point 2200
Inter company
Billing
Purchase
Plant 1200
Storage location 0001
Shipping point 1200
VF04
277
2200 orders for goods from 1000 for its customer 123
1000 raise invoice to 2200 and 2200 raise invoice to customer
Configuration steps:
Create customer by using Transaction code XD01 with the account group 0001 under Sales Area 2200
10 00 with France address.
Save and Exit
NOTE: Plant must be 2200
Create material master by using Transaction code MM01
Industry sector Mechanical engineering
Material type Finished product
Select the views and specify the organization level like below:
Plant = 2200, Storage location = 0001, Sales organization = 2200, and Distribution channel = 10
NOTE: Make sure that language as EN, DE, and FR in Additional data icon on the application tool bar.
Save and Exit
Extend the material to 1000 company code under plant 100
Go to MM01 and specify: Material number Ex: 888
Copy from material 888
Copy from
Plant 1200 Plant 2200
Storage location 0001 Storage location 0001
Sales organization 1000 Sales organization 2200
Distribution channel 12 Distribution channel 10
Shipping point 1200 Shipping point 1200
Change plant as 1200 in Sales: Sales organization 1 view
NOTE: As we are extending material from plant 2200 into 1200 plant, system copies all the data into the new plant.
So that we have to change the delivering plant in delivering plant field as 1200 in Sales: Sales organization data 1
view.
Create inter company customer
As ordering plant has to raise the purchase order with delivering plant, the delivering plant has to raise the sales
order with reference to this purchase order for the ordering plant. So that one customer should be existed (created)
under 1000 12 00 sales area, and should be assigned to 2200 10 00.
Go to XD01
Specify the account group ZAG2 Standard
Specify the sales area 1000 12 00
Save & Exit and note down the customer number
278
Define the internal customer number by sales organization
Path:
IMG
Sales and Distribution
Billing
Inter company billing
Define internal customer number by sales organization
Click on activate button
Go to position button
Specify sales organization 2200
Assign inter company customer that we created in 4
th
step
Save and Exit
Setup sales line with delivering plant
Path:
IMG
Enterprise structure
Assignment
Sales and Distribution
Assign Sales organization Distribution channel Plant
Choose our sales organization and distribution channel 2200 10
Click on assign icon
Select the 1200 plant and assign it
Save and Exit
Raise the sales order by using Transaction code VA01 under 2200 10 00 sales area and maintain all the
relevant data in the sales order, and check which plant system determined automatically for a line item.
System determines 2200 plant.
So as to process the inter company sales, we have to change the plant as 1200. Then we get an ERROR
mandatory condition PI01 is missing.
Then go to the condition screen and maintain the price for PI01.
NOTE: PI01 is the base price that charged by 1000 company code to the 2200 company code.
Specify the storage location 0001
Save & Exit and note down the sales document number
Go to MB1C to initialize the stock
Specify the plant = 1200 and storage location 0001
Save and Exit
Go to VL01N for outbound delivery
Specify shipping point = 1200
Go pick the quantity Go to Subsequent functions Create TOR
Go to change mode of VL02N and do the PGI
Save and Exit
Go to Vf01 and raise the invoice
This is the normal invoice that rose by 2200 company code to the end customer.
Go to VF04 to raise the inter company billing
Specify the billing (Document) type [IV]
Inter company billing option under Documents to be selected
Click on display billing list on the application tool bar
Select delivery document and click on Individual billing
Then system generates inter company billing
Save and Exit
279
Go to VA02 of sales order and see the document flow
Inter company customers (that is the customer), which represent the sales entity purchasing between company codes
with in the same client.
ERROR: To create version for fiscal year
Path:
IMG
Controlling
General settings
Organization
Maintain versions
Select our version Ex: 0
Click on setting for each fiscal year
Enter our controlling area Ex: 2200 Version 0
Go to new entries
Define our variant with fiscal year (which year we need)
Fiscal year [2006]
Check integrated planning
Copying allowed
Exchange rate [M] = Standard translation at average rate
Valuation date [ ]
Receivers version [0] (that we are defined)
Save and Exit
ERROR: Inter company sales process Version 0
Path:
IMG
Controlling
Cost controlling accounting
Planning
Basic settings for planning
Define version
Maintain settings of version in control area
Save and Exit
ERROR: Period <17-03-2006> is not opened for account type and G/L 799999.
Path:
IMG
Financial accounting
Financial accounting global settings
Document
Posting periods
Open and close posting periods
Change the periods for all accounts as current periods to our company code
For: +
A
D
K
M
S
V
Save and Exit
280
Third party sales order
In the third party order processing the business gets the orders from the customer and it passes to the third party
vendor who delivers the goods to the customer, and bills the business.
In the process of third party order is controlled via material types. Material types define whether a material is
produced only internally can be ordered only from third party vendors or from both possibilities.
Ex: Trading goods (HAWA) can only be ordered from third party vendors. Third party items can be created
automatically by the system or standard items can be changed manually by the end user by changing item category
during sales order processing.
Ex: MM01 Item category group Item category
BANS TAS
NORM TAS
If the Ship to party address changed in the sales order that changes passed on to the purchase
requisition and purchase order that are already created.
We can see the Ship to party address in purchase order in the attributes of the item category.
When we save the sales order that contains the third party item, then the system automatically creates
purchase requisition in purchasing (we can see the purchase requisition number in VA02 of sales order in
schedule lines).
During creation of the purchase requisition system automatically determine the vendor.
Purchase order created from purchase requisition usually.
During creation of purchase order system automatically copies the delivery orders from corresponding
sales order.
The number of the purchase order appears in the document flow of the sales order.
Customer PO
10 XYZ TAS PO 10 XYZ
Vendor
1
Sales order
2
Purchase requisition
PO 10 XYZ
MM
3
4
Vendor invoice
Goods issue
5
Sales order
OR
10 XYZ TAS
Invoice number
MM invoice
10 XYZ
6
7
Billing document
F2
10 XYZ
8
281
All changes made in the purchase order automatically affects in the sales order. But the changes that we
made in the sales order will not reflect in the purchase order.
Configuration steps:
Create customer master with XD01 by using account group 0001 under 2200 10 00 sales area.
Create a material master with MM01 with the material type Trading goods.
Maintain the data in all the views and make sure that general item category group BANS
Purchasing group [000] in purchasing view
Create a vendor using transaction code XK01
Specify vendor number [ ] Here it is external
Company code [2200]
Purchasing organization [2200]
Account group [0001] and press ENTER
Maintain the data in all the required fields
Go to Next screen option
Specify Reconciliation account number [ ] sort key [ ]
Cash management group [A1]
Order currency [EUR] (customer is from France)
Save and Exit
Go to VA01 and raise the sales order
Change the item category as TAS (from TAN to TAS)
Save the document and note down the sales order number and Exit
Go to (sales order) VA03 Schedule lines and note down the purchase requisition number that has been
displayed in purchase requisition field.
Raise the purchase order with reference to purchase requisition number by using Transaction code ME21
Specify the vendor number [ ]
Purchasing group [005] = Standard
Again purchasing group [000] and press ENTER
Click on with reference to purchase requisition
Select line item and click on Adopts + Details push button on application bar
In this section we have to specify the net price (cost that we maintained in the material master).
[] Un check GR (Goods Receipt)
If you uncheck GR, we can do the invoice verification based on the goods receipts.
Save the document and note down the number and Exit
Go to MIRO for invoice verification
Here we have to specify invoice date and purchase order number and specify purchase order number in
purchase order number [ ] field of PO reference tab and specify reference field and press ENTER
Then you can view balance amount from right side
The same amount should be specified in amount [ ] field and press ENTER
Then system makes balance amount 0 (zero). That means invoice verification has been done (completed).
Save the document and note down the number and Exit
Raise invoice to the customer [VF01]
Specify the standard order number and raise the invoice
Save and Exit
Go to VA02 (sales document) and observe the document flow
282
Make to Order
Make to order production is nothing but manufacturing the standard material by taking/changing characteristics
of the material that slightly changes the standard material. Customer will have a choice to choose this characteristic
depending on the requirements from the customer. This specific material is going to be produced and can be
maintained in the system as Make to order product (sales order item) by specifying a special stock indicator in
upper case E sales order requirements passed on to MRP through requirement type from the sales order and
subsequently the business produces this materials by adding this feature.
The cost and revenues that are involved in this product collectively assign to sales order item. The costs are
allocated to profitable analysis.
Make to order the requirement type controls production. The requirement type is determined on the basis of the
MRP group and strategy group in the material master.
When we save the sales order by specifying the Make to order item that initiates the production, and production
order created on the basis of these requirements.
Configuration steps:
Create material by specifying item category group as 0001 = Make to order (Normal item)
In MM01 Basic data tab, General item category field [0001] = Make to order, 0002 for configurable
material
Make to order checking group for availability check should be [02] = Individual requirements in Sales:
General/Plant tab.
Go to VA01 and raise the sales order by specifying this material that we created in the previous step
Item category is TAK
Schedule line category = CP
Requirement type = KE [Sales order Header Procurement Requirement field]
KE = Individual customer order without consumption
(For standard items item category group = NORM)
System determines requirement type 041-order/delivery requirements. This requirement type points requirement
class where we can control whether the system has to carryout TOR, Availability check, and Product allocation
functions.
NOTE: Make sure that controlling area and fiscal year defined and maintained.
Save and Exit
Go to MB1C to initialize the stock
Movement type [561]
Specify special stock [E]
E = Receipt without purchase order in unrestricted sales order stock
Specify the sales order number [ ] and item number [10]
Specify the material with quantity
Save and Exit
Go to MMBE and check the stock balance
Go to VL01N do the delivery
Go to VF01 and raise the invoice
VOV7 of TAK:
Billing relevance [A] = Delivery related document
Pricing [X]
VOV6 of CP:
Movement type: 601
283
Variant configuration
Manufacturing of complex products with large number of variants is always considered is a stringent task. The
business should be in a position to offer this kind of products according to customer requirements, as it is not a
standard item.
VARIANT CONFIGURATION is a tool that offers the flexibility of the configuration of the material during the
sales order processing by the end user according to the customer requirements.
Variant configuration has integration with following applications:
CA = Classification
LO = Material master
PP = BOM and routings
PP PI = Master receipts
SD = Sales, conditions
MM = Purchasing
CO = Costing
PP MRP production orders
Variant configuration offers a unique feature by which requirement of creating separate material for each variant of
product is eliminated by using configurable material, that contains all the components and operations for
production planning requirements.
Characteristics: Characteristics are used to define the features of configurable material. These characteristics are
assigned to CLASS TYPE 300. Customers can choose different options fro each characteristic, which are termed as
a VALUES.
The only limitations are combination of features that are not possible for either technical or marketing
reasons.
Variant configuration offers source code creation tool called DEPENDENCIES that prevents the
combination of options that are not allowed.
Dependencies select right BOM components and operations to produce a variant.
Each configurable material is assigned to a CLASS via CONFIGURATION PROFILE which controls
the configuration in the sales order.
Variant dependent PRICE can be calculated and maintained in VARIANT CONDITIONS.
Pre requisites: Maintain plant parameters
We have to specify all the plant parameters for MRP
Path:
IMG
Material Management
Consumption Based planning
Plant parameters
Carryout overall maintenance of plant parameters
Click on Create and specify our plant
Click on Create Create Save
Click on Maintain Maintain Number Ranges Planned Orders
Specify number range Ex: 01 Save
Click on RESV/Depend. Req. Mts. and specify number range Ex: 01 Save
Click on Purchase Requisition and specify number range Ex: 01 Save
Click on MRP LISTand specify 01 Save
Click on Sim. Dependent Reqt. and specify 01 Save
284
Master DATA
Click on MRP controllers Go to new entries and specify our plant, MRP controller Ex: 999 = SrinivaS
Business Area
Click on special procurement Go to new entries and specify our plant, SP type Ex: [SP] DCS [xxx],
Procurement type [E] and special procurement [E] Save
Click on Floats and go to new entries and specify our plant Save
Planned orders
Click on Cons. Pls. Ord & Purch. Req. Specify 10 Save
Click on Dep. Reqmt. Availability Specify check rule [01] = Checking rule 01
Planning Run
Click on External procurement and specify purchase procurement time [7]
Sub. Pur. Group [NIL]
Account assignment unknown [U]
Click on Rescheduling 2 Save
Click on planning horizon and specify [7]
Click on Avt. Stock and check all the options
Click on Err. Handling and specify maximum purchase orders Ex: [10] SMRPG [999]
Click on order start is past and check start is past allow
Performance
Click on Aggregation of MRP list check Transfer MRP
Save and Exit
Create MRP groups: It is an organizational object used to assign group of materials with special control
parameters for the planning run.
Path:
IMG
Material Management
Consumption Based planning
MRP groups
Carryout overall maintenance of MRP groups
Specify plant
Click on create Specify MRP group DESC create CREATE create Maintain
Maintain
External procurement
Scheduling DOC. Type check and specify [NB] [NB] [NB]
Planning intervals
Reschdu. Horizon and specify Reschedule Horizon [7]
Planning horizon and specify planning horizon [7]
Planning Run
Maximum MRP interval [10] days
Safety stock [100]
Creation indicator Create purchase requisition [3] planned orders
Create MRP list [3] No MRP list
Schedule lines [7] Schedule lines
Proj. plng. Reqmts. Grp. check group requirement
Save and Exit
285
Define MRP group for each material type
Path:
IMG
Material Management
Consumption Based planning
MRP groups
Define MRP group for each material type
Go to new entries and define:
Ex: Type Plant MRP group
KMAT 0003 999
Save and Exit
Number ranges for planning run
Path:
IMG
Material Management
Consumption Based planning
Number ranges
Define number ranges for planning run
Planned orders intervals [01] number ranges [01]
Dept. Requirement [01] [PLANT|01]
Purch. Req. [01] [PLATN|01]
No. Rg. MRP list [01] [PLANT|01]
Total MRP list [01]
Sim. Dept. Req. [01] [01]
Save and Exit
Define number ranges for manual processing
Path:
IMG
Material Management
Consumption Based planning
Number ranges
Define number ranges for manual processing
Depend Reqmt. [INTERVALS]
Purchase order [ ] Purchase Req. [ ]
Save and Exit
Master Data
It is a P.L step before maintaining plant parameters
Define MRP controllers, MRP types, Define special procurement types, MRP areas, and activate MRP for MRP
area.
Planning
Path:
IMG
Material Management
Consumption Based planning
Planning
286
Activate material requirements planning
[Material Requirements Planning]
[0003] Activate requirements planning
Save and Exit
Define scheduling margin key
Path:
IMG
Production
Material Requirement Planning
Planning
Scheduling and capacity parameters
Define floats (scheduling margin key)
Go to new entries and define Ex: 000
Save and Exit
287
Process flow
Create
Configuration material
Create
Characteristics
Create
Class
Create
Object dependencies
Simulate
Configuration
Create
Configuration profile
Create
Sales order
Assign
Object dependencies
Create
Variant condition records
Assign
Characteristics to class
288
Create configurable material
Go to MM01
Specify the Industry sector
Material type: Configurable Material
Select the Required views
Basic Data
Base unit of measure [EA]
Material group [02001]
General Item category group [0002] = Configuration
Make sure that [CM = Configuration management] CM relevance field contained [Relevant for configuration
management] as a value at the bottom of the Basic Data 1 tab.
Sales: Sales Organization 1
Maintain the conditions by checking on Conditions push button.
Specify the quantity and value
Sales: Sales Organization 2
General Item category group [0002]
Item category group [0002]
Sales: General/Plant
Checking group for Availability check [02]
MRP 1
Specify the MRP Group [0003]
MRP Type [PD]
MRP Controller [999]
Lot size [EX] = Lot for lot order quantity
MRP 2
Procurement type [E] = In house production (System proposes by default)
In house production [7] Days
Scheduling margin key [003]
MRP 1
Strategy group [25] = Make to order fore configurable material
Save and Exit
Create Characteristics: Transaction code: CT04
Path: 4.6
Logistics
Central functions
Classification
Master data
Characteristics
Create
289
Path: 4.7
Logistics
Central functions
Variant configuration
Environment
Classification
Master data
Characteristics
Enter characteristic name ENGINE_CAP and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
ENGINE_CA
P
Engine
capacity
Automatic Released Character
format
10 Single
Value
800
1000
1400
1800
800 CC
1000 CC
1400 CC
1800 CC
Save and Exit
Enter characteristic name TRANS and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
TRANS Transport
Capacity
Automatic Released Character
format
10 Single
Value
1
2
3
4
1 + 3
1 + 4
1 + 5
1 + 6
Save and Exit
Enter characteristic name FUEL and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
FUEL Fuel
System
Automatic Released Character
format
10 Single
Value
PET
DIES
GAS
Petrol
Diesel
Gas
Save and Exit
Enter characteristic name STEER and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
STEER Steering
System
Automatic Released Character
format
10 Single
Value
POW
CROS
Power
Cross ply
290
Save and Exit
Enter characteristic name TYRE and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
TYRE Tyres Automatic Released Character
format
10 Single
Value
RADI
NORM
Radial
Normal
Save and Exit
Enter characteristic name ACCE and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
ACCE Accessories Automatic Released Character
format
10 Single
Value
ADL
SM
CG
SC
SS
Automatic
Door Lock
Special
Mirrors
Crash
Guard
Special
Cushion
Stereo
System
Save and Exit
Enter characteristic name COMF and click on create icon
Click on Description tab Basic data Values tab
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
COMF Comforts Automatic Released Character
format
10 Single
Value
RR
PF
SB
Remote
Release
Perfume
Seat Belt
Save and Exit
Enter characteristic name SDCOM and click on create icon
Maintain data in Basic data, Description and Additional data Tabs
Save it
291
Go to change mode of same characteristic
Go to Additional data tab and maintain details
Table name [SDCOM] Field name [VKOND]
Save it
Again go to change mode of same characteristic
Go to Values Tab and maintain values for characteristic
Characteristi
c
Descriptio
n
Characte
r Group
Status Data
Type
No. of
Characte
rs
Value
Assignme
nt
Characte
r Values
Descriptio
n
SDCOM Variant
Condition
Automatic Released Character
format
10 Multiple
Value
ADL
SM
CG
SC
SS
Automatic
Door Lock
Special
Mirrors
Crash
Guard
Special
Cushion
Stereo
System
Go to Additional data tab
Uncheck Not Ready for Input
Save and Exit
NOTE: SDCOM is to be assigning to the CLASS if we want to carryout variant pricing.
Create class: Transaction code: CL01
Path:
Logistics
Central functions
Variant configuration
Environment
Classification
Master data
Characteristics
NOTE: Same transaction code CL02 for creation and change of CLASS
CLASS: In variant configuration, class is used to hold the characteristics that describe the material by linking the
class to the configurable material. We are allowing the material to be configured by using this characteristic class.
Specify the Class CAR_BENZ
Class type: 300 (Standard class)
NOTE: Use standard class type 300 = Variants
Click on create icon
292
Maintain the data in Basic data tab
Specify the description CLASS_CAR-BENZ
Check warning message
Maintain the data in Characteristic Tab
Characteristic Values
ENGINE_CAP
TRANS
FUEL
STEER
TYRE
ACCE
COMF
SDCOM
Save and Exit
NOTE: Assignment also takes place here only.
Create Configuration Profile: Transaction code: CU41
Path:
Logistics
Central functions
Variant configuration
Configuration profile
CU41 Create
Configuration profile used to define central settings for configuration objects. We can create several configuration
profiles with different settings for an object. We use the configuration profile to assign the configuration object to
one or more variant classes. This links the object to the characteristics of class for configuration.
Choose material that we created in first step
Select it and click on continue button
Specify our Material and press ENTER
Specify priority [01]
Specify configuration profile name [CONFIG_PROF_BENZ]
Specify the class [300]
Specify the organizational area [V] = Sales and Distribution
Click on Class Assignments push button
Specify our class [CAR_BENZ]
Save and Exit
Create Object Dependencies: Transaction code: CU01
Path:
Logistics
Central functions
Variant configuration
Dependency
293
Single dependency
Create
It allows us to create relations and restrictions between different characteristics and characteristics values.
Dependencies are: (A) Pre Condition
(B) Selection Condition
(C) Action Condition
(D) Procedure
Pre Condition: Pre Conditions are used to hide characteristics and a characteristic value that is not allowed, and
there by ensure that the configuration object is consistent.
Ex: Comforts like Remote Release, Perfume, Seat Belt cannot be given for 800 CC cars. That means if the user
selects a value 800 cc for characteristic ENGINE_CAP, then the characteristic COMF should to be displayed for
input values.
Specify the dependency name: [ENGINE_CAP_COMF_Pre - Condition] and press ENTER
Specify the description: ENGINE_CAP_COMF_Precondition
Check Pre Condition option in dependency type
Click on Dependency Editor and enter the source code like below:
ENGINE_CAP IN (1000, 1400, 1800).
Click on Check icon and check the status in the status bar
Save and Exit
Go to change mode of the same dependency
Change the status as 1 = Release
Save and Exit
Selection Condition: Selection conditions are used to ensure that all the objects are relevant to a variant is
specified. They define which variants required a specific component or operation. They determine when it is a
mandatory to assign a value to a characteristic.
EX: 800, 1000, and 1800 can only have fuel as petrol, where as 1400 can have fuel as either Petrol or Diesel. But
any one of it is mandatory.
Enter dependency name: ENGINE_CAP_FUEL_Selection Condition and press ENTER
Specify the description: ENGINE_CAP_FUEL Selection Condition
Check Selection Condition option in dependency type
Click on Dependency editor and enter the source code like below
ENGINE_CAP IN 1400.
Click on Check icon and check the status in the status bar
Save and Exit
Go to change mode of the same dependency
Change the status as 1 = Release
Save and Exit
Action Condition: Action condition is used to infer values for characteristics. Values that are set by an action
cannot be overwritten.
EX: 1000 CC can be supplied only with 1 + 4 transmission (TRANS) system. That means if the user selected 1000
CC for ENGINE_CAP characteristic, then 1 + 4 TRANS should get determined automatically.
Enter dependency name: ENGINE_CAP_TRANS_Action Condition and press ENTER
Specify the description: ENGINE_CAP_TRANS Action Condition
Check Action Condition option I dependency type
Click on Dependency Editor and enter source code like below:
294
$ SELF.TRANS = 1 IF ENGINE_CAP = 1000.
Click on check icon and check the status in the status bar
Save and Exit
Go to change mode of the same dependency
Change the status as 1 = Release
Save and Exit
Procedure: Procedure is used to infer values for characteristics. This condition is more or less action condition.
The difference is we can overwrite the values. We can set default values for characteristics. We can define
processing sequence also.
EX: Radial Tyres can be given for 1400 CC and 1800 CC with power steering. Normal Tyres can be given for 800
CC and 1000 CC with cross ply.
Enter dependency name: ENGINE_CAP_STEER_TYRE_Procedure and press ENTER
Specify the description: ENGINE_CAP_STEER_TYRE_Procedure
Check Procedures option in dependency type
Click on Dependency editor and enter the source code like below:
$SELF.TYRE = RADI IF ENGINE_CAP IN (1400, 1800) AND STEER = POW,
Click on Insert line icon on the menu bar to create new line, if the space is not sufficient.
$SELF.TYRE = NORM IF ENGINE_CAP IN (800, 1000) AND STEER = CROSSPLY.
Click on Check icon and check the status in the status bar
Save and Exit
Go to change mode of the same dependency
Change the status as 1 = Release
Save and Exit
Assign Object Dependencies: Transaction code: CT04
Path:
Logistics
Central functions
Variant configuration
Environment
Classification
Master data
CT04 Characteristics
We can assign the dependencies to the characteristics and configuration profiles via change mode of create
characteristics.
Go to CT04 of a characteristics and enter the dependency name COMF
Click on change icon
Click on values tab and select characteristic values
Go to Extras Object dependencies Assignments
Specify the 1
st
dependency type: ENGINE_CAP_COMF_Pre - Condition
Save and Exit
Enter the dependency name FUEL
Click on change icon
Click on values tab and select characteristic values
Go to Extras Object dependencies Assignments
295
Specify the 2
nd
dependency type: ENGINE_CAP_FUEL_Selection Condition
Save and Exit
Enter the dependency name TRANS
Click on change icon
Click on values tab and select characteristic values
Go to Extras Object dependencies Assignments
Specify the 3
rd
dependency type: ENGINE_CAP_STEER_TYRE_Action Condition
Save and Exit
Enter the dependency name TYRE
Click on change icon
Click on values tab and select characteristic values
Go to Extras Object dependencies Assignments
Specify the 4
th
dependency type: ENGINE_CAP_STEER_TYRE_Procedure
Save and Exit
Maintain Condition Records: Transaction code: VK11
Path:
Go to VK11 and specify condition type VA00
Click on key combination
Check variants and maintain the values for variants
ADL 4000 1
SM 5000 1
CG 8300 1
SC 10000 1
SS 30000 1
Save and Exit
So as to carryout variant pricing we have to create object dependency along with condition records.
Go to CU01 and specify the dependency name: VARIANT_PRICE_BENZ and press ENTER
Specify the description: Variant Pricing
Check Action Condition option in dependency type
Click on Dependency editor and enter the source code like below:
$SELF.SDCOM = ADL IF ACCE = ADL,
$SELF.SDCOM = SM IF ACCE = SM,
$SELF.SDCOM = CG IF ACCE = CG,
$SELF.SDCOM = SC IF ACCE = SC,
$SELF.SDCOM = SS IF ACCE = SS.
Click on check icon and check the status in the status bar
Save and exit
Go to change mode of the same dependency
Change the status as 1 = Release
Save and Exit
Simulate configuration: Transaction code: CU50
Path:
Logistics
Central functions
Variant configuration
Environment
296
CU50 Configuration simulation
Specify the material number and quantity (Variant configuration material)
Select Sales and Distribution
Select BOM
Click on configuration icon
Check the conditions whether it working properly or not
Save and Exit
Go to V/08 and include variant condition type VA00 in our pricing procedure
Go to VA01 and raise the sales order
Item category = TAC
Schedule line category = CP
Requirement type [KEK] = Make to Order configurable material
Save and Exit
297
Individual Purchase Order
The vendor ships/delivers the materials to the business and business in turn sends the goods to the customer. The
stock considers as a part of inventory and we manage them as a sales order stock.
Item Category Group Item Category
BANC
NORM
TAB
TAB
Display the current stock situation: Transaction code: MMBE
Path:
Logistics
Material management
Inventory management
Environment
Stock
Stock overview
MMBE Stock overview
Specify stock indicator as [E]
Select display levels:
Company code Batch
Plant
Storage Location Special Stock
Go to programs Execute (OR) Click on Execute icon
Select the stock line
Go to Edit Choose F2 and note down the stock status
298
Stock Transfer Order [STO]
When the stock is going to be moved between two plants or two storage locations that are under single company
code called as stock transfer order business process. Receiving plant raises the purchase order with supplying plant;
supplying plant delivers the goods to the receiving plant by raising sales order.
Configuration steps:
Create Vendor: Transaction code: XK01
Path:
Logistics
Material management
Purchasing
Master data
Vendor
Central
XK01 Create
Company code 1000
Purchase organization 1000
Account group 0001
Save and Exit
Assign Plant to Vendor
Go to change mode of Vendor [XK02]
Specify Vendor number that we created in the previous step
Company code 1000
Purchase organization 1000
Check purchasing data under purchasing organization data tab page and press ENTER
Go to Extras Add purchasing data
Here we assign supplying plant 1200 to vendor
Plant
1000
Plant
1200
Supplying Plant Receiving Plant
Stock
Transfer
Company Code
299
Save and Exit
Create customer master in XD01
Account group 0001
Company code 1000
Sales organization 1000
Distribution channel 12
Division 00
Plant in shipping data tab 1200
Save and Exit
Define shipping data for plants
Path:
IMG
Material management
Purchasing
Purchase order
Setup stock transfer orders
Define shipping data for plats
Choose our plant from position button
Click on details icon
Here we have to assign customer number to receiving plant [1000]
Save and Exit
Create material by maintaining Purchasing view: Transaction code: MM01
Plant 1000
Storage location 0001
Sales organization 1000
Distribution channel 12
Specify the delivering plant as 1000 in Sales: Sales organization 1 data tab
Purchasing group 005
Save and Exit
Extend the material from 1000 to 1200
Go to MM01 and specify the material number that we created in previous step Ex: 277412
Copy from material: 277412
Copy from
Plant 1200 Plant 1000
Storage location 0001 Storage location 0001
Sales organization 1000 Sales organization 1000
Distribution channel 12 Distribution channel 12
Change plant as 1200 in Sales: Sales organization 1 view
NOTE: As we are extending material from plant 1000 into 1200 plant, system copies all the data into the new plant.
So that we have to change the delivering plant in delivering plant field as 1200 in Sales: Sales organization data 1
view.
300
Save and Exit
Go to MB1C and initialize the stock
Movement type 561
Plant 1200
Storage location 0001
Save and Exit
Create Purchase order: Transaction code: ME21N
Path:
Logistics
Material management
Purchasing
Purchase order
Create
Select the transfer order
Document type is UB
Click on Header level icon
Specify vendor number
Supplying plant 1200
Purchasing organization 1000
Purchasing group 005
Company code 1000
Click on Item level icon
Maintain the material and purchase order quantity
Plant 1000
Storage location 0001
Save and Exit
Activities due for Shipping (Purchase order fast display): Transaction code: VL10B
Path:
Logistics
Logistics execution
Outbound process
Goods issue for outbound delivery
Outbound delivery
Create
Collective processing of documents due for delivery
VL10B
Shipping point 1200
Specify purchase order number and material
Click on add document data icon on the application tool bar
Select the line item
Click on background button from application tool bar
Click on next and note down the SD document number
301
Go to change mode of outbound deliveries (VL02N)
Now create transfer order by using transaction code LT03 and do the PGI
Go to MMBE and observe the stock in plant 1200
Stock is going to be reduced
Display stock in transit: Transaction code: MB5T
Path:
Logistics
Material management
Inventory management
Environment
Stock
MB5T Stock in Transit
Specify the material number
Receiving plant 1000
Click on execute icon
Here we can observe that stock is in transit
Goods receipt: Transaction code: MIGO
Path:
Logistics
Material management
Inventory management
Goods movement
MIGO Goods movement (MIGO)
Specify purchase order number and item number
Click on execute icon
Check item OK in the bottom of the page
Click on POSTicon on the application tool bar
Now stock is posted
Go to MMBE to see the stock overview and observe the stock in the plant 1000
Stock movement types: INTRAand INTER
INTRA
Stand order type (Document type) = UB
Delivery type = NL
Determination of document type:
Supplying plant + Receiving plant = UB
Supplying plant + UB = NL
302
Movement types:
Issuing plant Receiving plant
Single step 647 101
Two step 641 101
INTER
Standard order type (Document type) = NB
Delivery type = NLCC
Determination of document type:
Supplying plant + Receiving plant = NB
Supplying plant + NB = NLCC
Movement types:
Issuing plant Receiving plant
Single step 645 101
Two step
643 101
PBXX is the Gross price condition type for Stock Transfer Order
Vendor = Supplying plant
Customer = Receiving plant
NOTE: In single step method updations takes place in both plats simultaneously.
In two-step method updations should takes place manually.
303
Outbound Deliveries
Delivery Documents: So as to determine delivery process SAP has defined delivery documents. Like sales
documents we have different delivery documents so as to map different delivery business scenarios in that the
settings control how a delivery is to be carried out at the highest level.
EX: LF = Standard delivery
LR = Return delivery
LO = Delivery without Order Reference
NL = Replenishment delivery
NLCC = Replenishment delivery
Like sales documents, delivery documents has a common architecture.
Delivery document header data is going to be stored in the table LIKP
Delivery document item category is going to be stored in the table LIPS
Delivery document header can be proposed automatically from the sales document header or manually.
Delivery Document Item Category:
Delivery document type (+)
Item category group (+)
Usage (+)
Higher level item category
Transaction code to check this is: Q184
LF + NORM + NIL + NIL = DLN
LF + NORM + CHSP + NIL = TAN
LF + NORM + CHSP + KLN = KLN
LF + NORM + CHSP + TANN = TANN
LF + NORM + PACK + NIL = DLN
LF + VERP + PACK + NIL = DLN
Manually/Automatically
Item LIPS
Header LIKP
304
LF + NORM + PSEL + TAX = TAPS
Usage:
PACK = For generating Packaging item
CHSP = For Batch item
PSEL = For Product selection
Define Delivery Document: Transaction code: OVLK
Path:
IMG
Logistics execution
Shipping
Deliveries
Define delivery types
Choose delivery document LF from position button
Click on details icon
Document category [J] = Delivery
A classification for the different types of documents that you can process in the sales and distribution system
EX: Quotations, Sales orders, Deliveries and Invoices
NR internal assignment & NR external assignment: Number that determines how documents are to be
numbered by the user. It indicates which number range is relevant for a document type.
Item number increment: The increment by which you want the item numbers is a sales, delivery, or billing
document, to increase when the system automatically generates item numbers.
Order required [X] = Sales order required
Indicates whether a delivery that has no reference to an existing sales order is allowed. If it is LO order is not
required.
Default order type [DL] = Default order type for deliveries without reference to order
When you create delivery documents that do not refer to existing orders, you must provide some of the control
criteria that are normally copied from a sales document header into the delivery document.
Here we assign delivery order type for deliveries that are creating without reference to order. It is called as
PSEUDO document. We can define PSEUDO documents types in table TVAK.
305
Item requirement [202] = Requirement for item that does not refer to a sales order.
It identifies a requirements routine for a delivery item that does not refer to a sales document. The delivery item
must meet the requirements of the routine before it can be further processed.
Storage Location Rule [MARE]: It specifies how the system determines the picking location when you create a
delivery without entering a storage location for the items.
Text determination procedure [02]: It identifies a group of text types that you can use in, for example, standard
terms of delivery. The text procedure also determines the sequence in which the text types appear in the document.
Document statistic group []: It specifies a statistics group for this sales document type and helps determine which
data the system updates in the logistics information system.
We can assign statistics groups to:
Item category
Sales document type
Customer
Material
Route determination [A] = New route determination without check
It specifies whether, during delivery processing, the system uses the route that is determined during sales order
processing or whether it determines a new route.
Output determination procedure [V10000] = Header output
It defines the output categories that are allowed in a document and the sequence in which the output categories
appear in the document.
Output type [LD00] = Delivery note
If specifies the kind of output to be produced
Application [V2] = Shipping
It identifies the applications from which output can be sent. The output is divided according to output types and
assigned to these applications.
[] Delivery split Warehouse Number: It enables delivery spilt according to warehouse number
[] Delivery split Partner: This indicator controls the system is split behavior when delivering preceding documents
that are assigned to different partner functions. Set the indicator if different partner functions in the preceding items
to be delivered should always cause the system to perform a delivery.
306
[] Automatic packing: If this field is checked, the automatic packing proposal is retrieved when a delivery is
created. All items will be packed.
[] General packing material item: We can use this indicator to dictate whether you want to permit generation of
delivery items for packaging materials I deliveries of this delivery type.
Partner determination procedure [LF] = Delivery note
A grouping of partner functions. The procedure specifies which partner functions are allowed for a particular
business transaction and which of those partner functions are mandatory.
Rescheduling []: You can control whether a redetermination of shipping deadlines should be run for backlogged
deliveries using this indicator.
During rescheduling, it is assumed that the activities that are to be carried out for the backlog delivery can begin on
the current day at the earliest. The new shipping deadlines are redetermined from the current date using forward
scheduling.
Distribution mode [] = Distribution control by warehouse
We use this setting to specify the time at which an inbound/outbound delivery is distributed to the decentralized
WMS. The setting is valid for all inbound/outbound deliveries with the relevant delivery type.
Screen sequence group []: It controls which screens you see during a particular transaction and in which sequence
they appear.
Standard text []: Number of the standard text. This is not used at present.
Display range [UALL] = All items
It specifies the kinds of items that the system automatically displays during document processing.
Save and Exit
307
Define Item category for deliveries: Transaction code: OVLP
Path:
IMG
Logistics execution
Shipping
Deliveries
Define item categories for deliveries
Choose item category DLN from position button
Click on details icon
Document category [J] = Delivery
A classification for the different types of documents that you can process in the sales and distribution system
EX: Quotations, Sales orders, Deliveries and Invoices
308
[] Material number 0 allowed: It controls whether it makes sense to enter an item in the SD document with this
item category without specifying a material. It allows to create a delivery document for a line item with 0 quantity.
Use: It would make sense to set this indicator for text items.
Item category statistics group [1] = Order, debit memo
It specifies a statistics group for this item category and helps determine which data the system updates in the
Logistics Information System.
Stock determination rule []: Stock determination rule and stock determination group are combined into one key
for stock determination strategy. It will be used in the repetitive manufacturing process.
Check quantity 0 [A] = Note about the situation
It specifies when we create an item that has a 0 quantity. In this situation how system should give message. It is
useful for the items that are creating without order.
Check minimum quantity [A]: Note about the situation
It specifies whether system has to check minimum delivery quantity, and system reactions when the minimum
delivery quantity has been to yet reach. This field works according to the customer material info record, and
material master record. System gives warning or error message.
Check over delivery []: It specifies how the system reacts whether warning or error message during delivery
processing when original order quantity exceeds delivering order quantity.
It works according to customer material info record.
Availability check off []: It is the control to switch on/off availability check for delivery items.
Rounding []: This indicator specifies rounding rules for whole number unit of measure. It is useful for BOM items.
[] Relevant for picking or put away: It indicates whether item of this type are relevant for picking or put away. In
the outbound delivery process, only delivery items that are relevant for picking are transferred to the warehouse
management. Service items and text items are not transferred to the warehouse. In the case of inbound deliveries
this indicator controls whether the item is relevant for put away in the warehouse.
[] Storage location required: This indicator makes storage location as mandatory in the delivery document.
[] Determine storage location: It indicates whether system has to determine storage location automatically.
309
[] Do not check storage location: It indicates whether system should run a check for the storage location that was
determined.
[] No batch check: It specifies system checks the batch number that entered in the delivery document.
Packing control []: It indicates whether delivery items with this item category:
May be
Cannot be
Must be packed
[] Pack accumulated batch items: It specifies if for a batch material only the main item with accumulated batch
quantity is to be packed in the delivery, or if only items in which the batch is recognized can be packed.
[] Automatic batch determination: This indicator enables to determine batch automatically in the delivery
documents.
Text determination procedure [02]: It identifies a group of text types that you can use in, for example, standard
terms of delivery. The text procedure also determines the sequence in which the text types appear in the document.
Standard text []: Number of the standard text. This is not used at present.
Save and Exit
310
Shipping point determination: Transaction code: OVL2
Path:
IMG
Logistics
Execution
Shipping
Basic shipping functions
Shipping poi8nts and goods receiving point determination
Assign shipping points
Go to new entries
Specify Shipping Conditions + Loading Group + Delivering Plant = Proposed Shipping Point
Save and Exit
Route determination: Route can be redetermined in the deliveries. System redetermines the route by taking
weight group in to the consideration along with other factors that are required to determine route. Route
determination procedure is same as we defined earlier.
311
Incompletion control for deliveries: We can determine incompletion procedure for
Delivery Document Header [G]
Delivery Document Item [H]
Procedure is same to define incompletion control for deliveries as we defined earlier.
Availability check and TOR: procedure is same to configure Availability check and TOR for delivery documents
as we defined earlier.
Output control: We can determine output for outbound deliveries, inbound deliveries, and handling units and for
groups. Procedure is same to configure output for delivery.
Output types for outbound deliveries:
CANO = Forwarding notification
LALE = Shipping notification to Sold to party
LAVA = Outgoing shipping notification
LD00 = Delivery note
MAIL = Mail
PL00 = Packing list
Output determination procedures:
V10000
V20001
Partners: We can determine master data like delivery priorities, customer calendars, and goods receiving hours.
Partner determination procedure:
LF = Delivery note
LO = Delivery without order
EL = Shipping notification
Text control: We can determine text for delivery document header and item. Procedure is same as we define
earlier.
Pricing: We can define and assign pricing procedure for value contracts. We can define pricing procedure for
delivery and we can assign pricing procedure for deliveries.
Material determination: We can map the material determination as well as listing and exclusion also for
deliveries. Procedure is same as we defined earlier.
Proof of Delivery [POD]: We can map Proof of Delivery in deliveries section. We can release POD automatically
by using transaction code: VLPODQ.
Copy control: Transaction code: VTLA
Path:
312
We can maintain the copy control for sales document to delivery document.
Sales document to Delivery document Header
Order requirements [001] = Header
In order to form the basis of a delivery, a sales document must be a sales order and not for an inquiry or a quotation.
Combination requirement [051] = Combination
The sales orders you want to combine must have the same sales organization, the same billing type and the same
partial delivery agreement.
Header data [001] = Header
According to the routine, the system checks that certain sales document header fields I the source document meet
the right conditions. If they do, the system copies them into the target document.
[] Copy item number: It indicates whether the system copies the item numbers from the source document into the
target document. If you expand a document by copying in only partial item information from another document,
the system does not copy the item numbers.
313
Sales document to Delivery document Item
Order requirements [101] = Item
In order to form the basis of a delivery, a sales document must be a sales order and not for an inquiry or a quotation.
Item data [699] = IDES item
According to the routine you specify, the system checks that certain sales document item fields in the source
document meet the right conditions. If they do, the system copies them into the target document.
Business data [2] = Business Data
According to the routine you specify, the system checks that certain business data fields in the source document
meet the right conditions. If they do, the system copies them into the target document.
[] Update document flow: It indicates whether the system creates a document flow record when you copy one
sales document into another.
Use: The flow record includes information about how much of the quantities and values in the source document
have been copied into the target document.
Positive/Negative quantity [+]: Indicates whether, during copying, the quantity or value in the target document has
a negative effect, positive effect, or no effect at all on the quantity still to be completed in the source document.
314
Picking: Under picking we configure warehouse managements (Lean warehouse) for deliveries.
Picking
Without
MM WM
Print
Pick list
Picking on
Demand
Fixed bin
Picking
Picking via
Transfer Orders
With
MM WM
315
Ware House Management
Warehouse is a complete physical warehouse is defined under a single warehouse number. By using this warehouse
number we can manage several individual warehouse buildings that together form a complete warehouse complex.
Warehouse number encompasses (include) the organizational plan and physical aspect of warehouse complex in a
single concept. Warehouse can be used to kept finished products.
Warehouse can be:
Goods receipt area
Goods issue area
Hall with high rack shells
Bulk storage area
Picking area with fixed bins
Outside storage yard for special goods
Warehouse structure:
A complete physical warehouse is defined under a single warehouse number.
Storage type: Storage type is nothing but a storage area, warehouse facility. Warehouse zone that we defined for
warehouse number. It is a physical or logical sub division of a warehouse complex that characterized by its
warehouse technique, the space used, its organizational form or its function. A storage type consists of one or
several storage bins.
EX: Bulk storage, open storage, high rack storage, picking area, and shelf storage type.
We have to define important control indicators/parameters for storage type that determines material flow (put
away/picking activities).
EX: Put away, Picking, Blocking indicators, and Inventory procedure.
Storage section: It is an organizational subdivision of a storage type that groups together storage bins with similar
features for the purpose of putting away stock. We must create at least one storage section for each storage type.
Picking area: Picking area is a section within a storage type in which all picking activities are carried out in the
same way. It groups storage bins together from the view point of picking strategies and is a counter part to the
storage section which groups bins from the view point of put away strategies.
Warehouse Number
Storage Type
Storage Type Storage Type
Storage Section/
Picking Area
Storage Section/
Picking Area
QUANT 1 QUANT 2
Storage Bin
316
Storage bins: A storage type generally contains several storage spaces or straights. These are called storage bins in
the warehouse management. The storage bin is a smallest available unit of space in a warehouse. The storage bin
therefore describes the position in the warehouse where the goods can be stored since the address of the storage bin
derived from a co ordinate system.
EX: 01, 02, and 03
01 for Row
02 for Stack
03 for Level
We have to address storage bin with coordinate. We assign each storage bin to specific warehouse number and
storage type.
We must assign each storage bin to a storage section. We can define maximum weight, total capacity, fire continent
section, storage bin type, etc.
Create Storage Bins: Transaction code: LS01N
Path:
Logistics
Logistics execution
Master data
Warehouse
Storage bin
Create
LS01N Manually
Quant: It is a stock of any material with same features in one storage bin.
Door: Where the goods arrive at or leave the warehouse. It is an organizational unit that is assign to the warehouse
number. The doors are located in a close proximity to the respective staging area.
Staging area: It is an organization unit that is assigned hierarchy to the warehouse number. It is used to organize
the goods flows in the warehouse. It is used as an interim storage of goods in the warehouse. It is assigned to
doors.
EX: Goods receipts and Goods issues.
NOTE: Warehouse management configured by MM consultants.
Lean warehouse management configured by SD consultants.
Lean warehouse management: In warehouse management system, goods movements and stock changes takes
place at storage bin level. But with lean warehouse management, inventory management takes place at storage
location level.
We used to process goods receipts and goods issues. We have to create transfer orders for deliveries. Transfer
order serves as a picking list.
Pre Requisites: We can only implement it with fixed storage bin.
Assign a newly defined storage location to warehouse umber.
Setup at least two storage types.
1. Picking storage type as the source storage type.
2. In shipping area as a destination storage type for deliveries.
317
Configuration setting:
Define warehouse number
Path:
IMG
Enterprise structure
Definition
Logistics execution
Define, copy, delete, check warehouse number
Define warehouse number
Choose existing lean warehouse number
Click on copy as icon and rename
Save and Exit
Define new storage location
Path:
IMG
Enterprise structure
Definition
Material management
Maintain storage location
Enter plat in work area and press enter
Go to new entries
Define storage location
Save and Exit
Assign warehouse number to plant/storage location
Path:
IMG
Enterprise structure
Assignment
Logistics execution
Assign warehouse number to plant/storage location
Go to new entries
Specify the plant, storage location and warehouse number
Save and Exit
Define master data
Path:
IMG
Logistics execution
Warehouse management
Master data
Define control parameters for warehouse number
Choose our warehouse number from position button
Select it
Click on details icon
Maintain the details
Save and Exit
318
Define number ranges
Path:
IMG
Logistic execution
Warehouse management
Master data
Define number ranges
Click on number ranges push button [Transaction code: OMLW]
Choose our warehouse number
Assign NR - TO
01 [01] Number range for the assignment of Transfer order numbers
NR Group
01 [01] Number range for assignment of WM reference numbers
Click on For transfer requirements for our warehouse and maintain number ranges to it. [LN01]
Click on For transfer order for our warehouse and maintain number ranges. [LN02]
Click on For quant and maintain number ranges. [LN03]
Click on For post change notice and maintain number ranges. [LN04]
Click on For groups and maintain number ranges. [LN06]
Click on For storage unit and maintain number range to it. [LN08]
Save and Exit
Define storage types
Path:
IMG
Logistic execution
Warehouse management
Master data
Define storage types
Choose warehouse No. 001 and Storage type 005 from position button
Select it and click on copy icon
Change warehouse number with our warehouse number
Save and Exit
Define storage sections
Path:
IMG
Logistic execution
Warehouse management
Master data
Define storage sections
Choose existing storage section Warehouse No. 001, Storage type 001, and Storage section 001
Select it and click on copy icon and rename with our warehouse number and storage type
Save and Exit
319
Define picking areas
Path:
IMG
Logistic execution
Warehouse management
Master data
Define picking areas
Select Storage type 005 and Picking area 001 from position button
Click on copy icon
Rename with our warehouse number
Save and Exit
Define storage bins
Path:
IMG
Logistic execution
Warehouse management
Master data
Storage bins
Define storage bin types
Define storage bins
Choose existing storage bin EX: B1 and B2
Click on copy icon and rename with our warehouse number
Save and Exit
Define blocking reasons
Path:
IMG
Logistic execution
Warehouse management
Master data
Storage bins
Define blocking reasons
Choose existed blocking reason EX: 01 from position button
Click on copy icon and rename with our warehouse number
Save and Exit
Define storage bin structure for automatic creation: Transaction code: LS10
Path:
IMG
Logistic execution
Warehouse management
Master data
Storage bins
Define storage bin structure
Choose Warehouse No. 001, Storage type 005, and Sequence No. 001
Click on copy icon
Rename storage bin structure with our warehouse number
Save and Exit
320
Define storage type indicators
Path:
IMG
Logistic execution
Warehouse management
Master data
Materials
Define storage type indicators
Choose existing Warehouse No. 001, and Storage type indicator FIX
Click on copy icon and rename with our warehouse number
Save and Exit
Define storage unit types
Path:
IMG
Logistic execution
Warehouse management
Master data
Materials
Define storage unit types
Choose existing storage units Warehouse No. 001 and Storage unit type BX1, BX2, and BX3
Click on copy icon and rename with our warehouse number
Save and Exit
Define storage section indicators
Path:
IMG
Logistic execution
Warehouse management
Master data
Material
Define storage section indicators
Choose existing Warehouse No. 001 and Storage section indicator 001
Click on copy icon
Rename with our warehouse number
Save and Exit
Define special movement indicators
Path:
IMG
Logistic execution
Warehouse management
Master data
Material
Define special movement indicators
Choose Warehouse No. 001 and special movement indicator [A] from position button
Click on copy and rename with our warehouse number
Save and Exit
321
Activate storage type search: Transaction code: OMLY
Path:
IMG
Logistic execution
Warehouse management
Strategies
Activate storage type search
Click on define for storage type indicator
Check our warehouse number existed or not
Save and come back
Click on determine search sequence for storage type search
Choose Warehouse No. 001 and Storage type indicator FIX and Storage types 005 and 001
Click on copy and rename with our warehouse number and storage types
Save and come back
Click on define for movement type references
Check our warehouse number with movement types is existed or not
Save and come back
Click on storage type search for access optimization
Choose warehouse number 001
Click on copy icon
Rename with our warehouse number
Save and Exit
Activate storage section search: Transaction code: OMLZ
Path:
IMG
Logistic execution
Warehouse management
Strategies
Activate storage section search
Click on define for storage section indicator
Check our warehouse number is existed or not
Click on determine search sequence for storage section search
Go to new entries and maintain values like below:
Ware House No. Storage type Section indicator Class WPC
0003 001 001 5.1 B 0
0003 005 005 5.1B 0
Click on activate for storage section check
Choose our warehouse number and storage type from position button
Assign X[X = Storage section determination and check] for storage section check
Save and Exit
322
Activate storage bin type search: Transaction code: OMM1
Path:
IMG
Logistic execution
Warehouse management
Strategies
Activate storage bin type search
Click on storage bin types for definitions
Check our storage bins are existed or not
Click on storage unit type for definitions
Check our storage units are existed or not
Click on storage type for assignments storage unit types
Choose existing assignment and click on copy icon
Rename with our warehouse number and storage types
Save and come back
Click on storage bin types for assignments storage unit types
Choose existing assignment and click on copy icon
Rename with our warehouse number, storage unit types and storage bin types
Save and come back
Click on activate for storage unit type check
Check our warehouse with our storage types or existed or not
Save and exit
Put away strategies
Define strategy for fixed bins
Path:
IMG
Logistics execution
Warehouse management
Strategies
Put away strategies
Define strategy for fixed bins
Check our warehouse with fixed bins existed or not
Save and Exit
Define strategy for open storage
Path:
IMG
Logistic execution
Warehouse management
Strategies
Define strategy for open storage
Check our warehouse with storage types or existed or not
Save and Exit
323
Define strategy for addition to existing stock
Path:
IMG
Logistic execution
Warehouse management
Strategies
Define strategy for addition to existing stock
Check our warehouse with storage types existed or not
Save and Exit
Define strategy for empty storage bin
Path:
IMG
Logistic execution
Warehouse management
Strategies
Define strategy for empty storage bin
Check our warehouse with our storage type existed or not
Save and Exit
Lean Warehouse
Configuration settings:
Define control parameters and number ranges for warehouse number
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define control parameters and number ranges for warehouse number
Define control parameters and number ranges for warehouse number
Choose our warehouse number from position button
Go to details icon
Check Lean WM active
Save and Exit
Maintain umber range intervals for transfer order
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define control parameters and number ranges for warehouse number
Maintain number range intervals for transfer order
Specify our warehouse number
Use the warehouse number range interval that we defined earlier or define new number range
Save and Exit
324
Maintain number range intervals for reference number
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define control parameters and number ranges for warehouse number
Maintain number range intervals for reference number
Specify our warehouse number
Use the warehouse number range interval that we defined earlier or define new number range.
Save and Exit
Define storage types
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define storage types
Check our warehouse number and storage types existed or not
Select it and click on details icon
Uncheck for our both storage types
[] Stock placement requires confirmation
[] Stock removal requires confirmation
Save and Exit
Define doors
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define doors
Choose the existing doors from position button
Click on copy and rename with our warehouse number
Save and Exit
325
Define material staging areas
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define material staging areas
Choose existing staging areas from position button
Click on copy ad rename with our warehouse number
Save and Exit
Define picking areas
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define picking areas
Check our warehouse number with picking areas existed or not
Save and Exit
Define transfer types
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define transfer types
Choose existing one from position button
Select it and click on copy icon
Rename with our warehouse number
Save and Exit
Define movement types
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define movement types
Choose movement types 255, 601, and 930 from position button
Click on copy icon and rename with our warehouse number
Remove the destination value and paint code value
[] Uncheck manual transfer order creation not allowed
Save and Exit
326
Define difference indicators
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Define difference indicators
Choose existing difference indicator 010 from position button
Select it and click on copy icon and rename with our warehouse number
Save and Exit
Control Plant/Storage Location/Warehouse number assignment
Path:
IMG
Logistics execution
Shipping
Picking
Lean WM
Control Plant/Storage Location/Warehouse number assignment
Choose our Plant, Storage Location and Warehouse number
Assign degree of activation as 1 [1 = Lean warehouse management in connection with deliveries]
Specify storage type 005 fixed bins that we define
Save and Exit
Go to MM01 and create a material master with Warehouse management 1 and Warehouse management 2
at Plant, Storage Location, [that we created newly] Warehouse number and storage type.
Go to MB1C and maintain the stock under new storage location
Go to VA01 and raise the sales order
Go to VL01N and raise the delivery document. Save the delivery document without doing PGI + Picking.
Go to LT03 to create transfer order.
Transfer order is which acts as a picking order
Save the document.
Go to VL02N and click on picking tab and check picking quantity has been picked by transfer order.
Do the PGI and Save it
Go to VF01 and raise the Invoice
Other goods movement: Transaction code: MB1C
Path:
Logistics
Material management
Purchasing
Inventory management
Inventory management
Goods movement
Goods receipt
MB1C Other
327
Stock overview: Transaction code: MMBE
Path:
Logistics
Material management
Inventory management
Environment
Stock
MMBE Stock overview
328
Packing
Packing is carried out at item level. We can determine that a specific item is to be mandatory packed or will be
packed necessary. This packed item then in turn may be packed again into a shipping unit, which in turn may be
packed into another shipping point. Then it is called as multilevel packing.
Configuration settings:
Handling unit: Handling unit is the combination of
Vehicle +
Package material +
Material to be packed
The whole unit is called as a handling unit
Define number ranges for handling unit: Transaction code: VNKP
Path:
IMG
Logistic execution
Shipping
Packing
Define number ranges for handling units
Click on insert intervals icon define number ranges
Save and Exit
Packing control by item category
Path:
IMG
Logistic execution
Shipping
Packing
Packing control by item category
Choose item category TAN from position button
Assign value in packing control field
[] Can be packed
[A] Must be packed
[B] Can not be packed
Save and Exit
Define requirements for packing in the delivery: Transaction code: VPBD
Path:
IMG
Logistic execution
Shipping
Packing
Define requirements for packing in the delivery
We can specify the requirement for packing when there is credit block existed.
Routine [112] = Packing
Check whether this routine is existed or not
Save and Exit
329
Define packing material types: Transaction code: VHAR
Path:
IMG
Logistic execution
Shipping
Packing
Define packing material types
We define packing material types Ex: V010 by which we can control packing material output
determination
Procedure [V00001] shipping unit procedure 000001
Output type [0001] shipping unit
Plant determination [B] plant determined from the first item that was packed.
Packing material category [C] packing materials
Packing material has been categorized as [C]
Generate division items [A] item is going to be generated if the Ship to Party is same
Number assignment [A] SSCC 18 already created for handling unit
Handling unit type [5] unrestricted use
Choose existing one from position button
Click on copy icon and rename
Save and Exit
Define material group for packaging materials
Path:
IMG
Logistic execution
Shipping
Packing
Define material group for packaging materials
For packaging materials item category is VERP
We can then assign material group for the shipping material in the shipping field in MM01
The shipping material group also assigned to the standard item that are to be packed
It enables similar materials to be grouped together
Ex: Materials may all be to be packed into carton, then shipping material group = Carton is necessary for shipping
material.
Some standard items may be packed into cartons that are fragile. Thus there may be a need to call a group fragile.
Then the assignment of fragile would be on the basic data screen of standard item in the material master.
Choose standard packing material group G010 = Skeleton box
Click on copy icon and rename it
Save and Exit
330
Define allowed packaging material
Path:
IMG
Logistic execution
Shipping
Packing
Define allowed packaging material
Here we assign allowed packing material types for material group of packaging materials
Go to new entries
Choose our packing material group
Assign our packaging material type
Save and Exit
Go to MM01 create a material with material type packing [VERP]
Base unit of measure [BOX]
Material group [008]
Assign packaging material group [OURS]
Assign packing material type [008] in Sales: General/Plant tab
Save and Exit
Go to MM01 again and create material that is to be packed and assign our material group packing material
[OURS]
Make sure that in Sales: General/Plant tab material group for packing material [OURS] has been
maintained, and tax classification number also maintain
Save and Exit
Go to MB1C and initialize the stock
Go to VA01 and raise the sales order. Enter the material that is to be packed
Go to VL01N do the picking
Select the line item
Go to Edit Pack
Now the screen has been sub divided into two sections
Upper screen is for packing materials
Lower screen is for material to be packed
Specify the packing material in the packing materials field in the upper screen and press ENTER
Check system automatically created handling unit for this packaging material
Select two line items
Go to Edit Pack Pack
Note down the status on the status bar that is materials was packed
Given the storage location for two line items under the storage location field in the delivery document.
Back
Do the PGI
Save and Exit
Go to VF01 and raise the Invoice
331
Returnable Packaging
It is used in the process where by the business sells items to the customer. These items are packed into shipping
units such as Boxes and Crates. Then the customer can keep the boxes or crates up to a certain period of time and
then must return the item. Should the customer not have return the shipping units with in specified date or have
been destroyed, and then business may bill the customer for damage goods.
The stock we deliver as special packaging materials. We kept at customer site. It can be viewed in MMBE with
indicator V.
Item category group is VERP
General item category is LEIH
LAN for returnable packaging pickup
LNN for returnable packaging issue
Material group = 00804
If you proposed packaging material in the order (Edit Packaging proposal) then it will be copied into the
delivery. If we do not enter packaging material as a item in the sales document. Then we enter the item category in
the shipping point.
Path:
Edit Packing proposal screen
Select general header data button
Then SAP will create a delivery item for the shipping material from the packing proposal.
Ex: If we enter TAL (Item category for returnable packaging) in the shipping unit header, then when we create the
delivery, SAP will also create an item TAL for that shipping material in the delivery. For the goods issue SAP
records that shipping material has been issued to the customer and must be return. We have to price the returnable
packaging in the returnable packaging issue order document.
When the customer should return the packaging material, then we have to pick up the returnable packaging item
from the customer site.
When the customer return the packing material
Process Flow:
Returnable
packing
pick up
[LA]
LAB
If
customer
should
return the
packaging
item
Returnable
packaging
material
delivery
[LR]
LF
Packing - LF
Billing for
only
material
sold, not for
returnable
packing
material
[F2]
OR
332
When the customer does not return the packing item.
Process Flow:
Configuration steps:
Create a material with material type is returnable packing and make sure that general item category group
LEIH
Go to MB1C and initialize the stock
Specify stock indicator V
Go to VA01 and raise the sales order by specifying the material that is to be packed [Normal] by returnable
packaging material
Go to VL01N Picking
Select line item and Go to Edit Pack
Specify the returnable packaging item in upper screen
Select two line items
Go to Edit Pack Pack
Note down the status that is material was packed.
Go back and do the picking and PGI
Save and Exit
Go to MMBE and check the stock balance of packing item and returnable packing item. Notice that in the
returnable packing stock system shows the status as Returnable packaging at customer.
Go to VF01 and raise the Invoice.
Scenario 1: If the customer returns returnable packaging material, then business has to pick up returnable
packaging material from customer site.
Go to VA01 and raise the sales order [Document type AT]
Specify the returnable packaging stock quantity
Save and Exit
Go to VL01N and do the return delivery for returnable packaging quantity
Do the PGR and save the document
Returnable
packing
Issue
[LN]
If
customer
should not
return the
packaging
item
Billing to
returnable
packaging
material
F2
LF
Packing - LF
Billing for
only
material
sold, not for
returnable
packing
material
[F2]
OR
333
Scenario 2: If the customer does not return the returnable packaging items, then business has to bill the customer.
Go to VA01 [Document type LN] and raise the order
Specify the reason as goods damaged at customer place
Save and Exit
Go to VF01 and raise the Invoice with reference to LN document
The process flow in returnable packing:
Sales Order
TA
Delivery
and Packing
LF
Billing for
material
sold only,
not for
returnable
packaging
materials
F2
Returnable
packing
pick up
AT
Returns
Delivery
LR
Should the
customer
return the
packing items
Returnable
packing
issue
RPI
Should the
customer not
return the
packing items
Standard
Delivery
LF
Billing for
returnable
packaging
F2
334
Billing Documents
The header data of the billing document defines how the invoice is to behave. Billing document uses only internal
number range assignment.
Define Billing types: Transaction code: VOFA
Path:
IMG
Sales and Distribution
Billing
Billing documents
Define billing types
Define billing types
Choose billing document type F2 from position button
Click on details icon
Created by []: Name of the person who created the object.
Number range internal assignment [19]: Number that determines how documents are to be numbered by the user.
It indicates which number range is relevant for a document type. Here number range is only internal.
Item number increment: The increment by which you want the item numbers is a sales, delivery, or billing
document, to increase when the system automatically generates item numbers.
Item VBRP
Header VBRK
335
SD document category [M]: That defines what type of document the system is using.
Transaction group [7] = Billing document
A group that allows you to control certain features of transaction flows by sales, shipping and billing documents.
Use: The transaction group controls:
Which sales document types you can process with which system transactions during sales order
processing.
For which sales, shipping, and billing documents the system updates indexes for reporting
purposes.
Billing category []: It is used to differentiate the billing documents.
Document type []: The document type classifies accounting documents. As invoice generates FI document type
RV (Billing data transfer) we have to assign in the document type field under general control section.
Negative posting [A] = Negative posting for same period
This indicator causes the transaction figures to be reset for a document item. If the indicator is set, then the
transaction figure update is changed. A correspondingly set posting on the debit side reduces the credits side of the
account. A credit posting reduces the debit side of the account.
Use: The indicator can be entered in billing types for credit memos and cancellations. It only has the required effect
in FI, if the company code permits negative posting.
Branch/Head office []: The indicator controls, which partner functions of the billing document, can be forwarded
to financial accounting.
Credit memo with value date []: If the field is set, the reference billing document is not settled and the payment
deadline date for the base billing document comes after the billing date for the credit memo.
Invoice list [LR]: It is a classification that distinguishes between invoice li8st types that require different
processing by the system. To create invoice list, invoice document type LR proposed.
[] Posting block: If you check it billing document is going to be blocks automatic transfer of the data from invoice
to FI document. Manually the invoice has to be released.
[] Statistics: the value of the billing document is going to be updated in LIS. It indicates whether the system stores
information from billing documents of this type for the purposes of statistical analysis.
Rebate settlement []: If indicates whether the billing type is used exclusively during rebate processing.
Use: If you create a billing document of this type as the final settlement of a rebate agreement, the system indicates
in the agreement that the rebate has been completely paid.
336
[] Relevant for rebate: This indicator is one of the pre requisite to process rebates. This indicates whether billing
documents of this type are relevant during rebate processing.
Standard text []: Number of the standard text. This is not used at present.
Cancellation billing type [S1] = Invoice cancellation
It specifies the default cancellation for this billing type. For canceling the invoice the billing type [S1] can be
proposed for F2 and [SV] for BV.
Use: If you enter the number of an existing billing document in the document field on the initial screen for creating
a billing document, the system automatically creates a cancellation document of this billing type.
Copying requirements []: The routine checks that certain requirements are met when one document is copied into
another.
Ex: When you copy a quotation into a sales order, the system can check each item in the quotation to make sure that
it has not been rejected by the customer for some reason.
Reference number []: The reference number is a piece of additional information forwarded from SD and FI.
Ex: Customer purchase order, Sales order number, Delivery number, External delivery number, and Current invoice
number.
If you do not make an entry and the field is not filled in the order, the billing number is adopted automatically.
Allocation number []: You can find the allocation number under additional information in the (document) line
item that is forwarded from SD to FI.
Ex: Customer purchase order, Sales order number, Delivery number, External delivery number, and Actual invoice
number.
If you do not make an entry and the field is not filled in the order, the field remains empty.
Account determination procedure [KOFI00]: It specifies the condition types that the system uses for a particular
type of document (Ex: Invoice) to determine the G/L Accounts to which amounts should be posted. The values of
the invoice are going to be posted in respective G/L Accounts through this field assignment.
NOTE: For proforma invoices Ex: F5 and F8 do not contain any value. Due to this assignment, system can
understand whether it has to transfer the billing data from invoice to FI module. Proforma invoices only used for
information purpose. They do not carry the any information from invoice to FI.
Document pricing procedure [A] = Standard
The key that specifies the pricing procedure for this type of sales document. The pricing procedure determines how
the system carries out pricing for a particular sales document.
Ex: Which pricing condition records it accesses and in which sequence.
337
Account determination reconciliation account []: It determines the condition types that the system uses for
determining the reconciliation account that the system uses for a certain document type Ex: Invoice.
If a G/L Account is determined here, then the reconciliation account stored in the customer master record is
ignored.
Account determination cash settlement []: It determines the condition types that the system uses for a certain
document type (Ex: Invoice) during determination of the G/L Account for cash settlement.
If this field is filled, then the billing document is not posted on the debit side. In this case the G/L Account
determined is posted.
Account determination pay cards [A00001] = Standard
It specifies the condition types that the system uses to determine general ledger accounts for document types used in
payment card transactions.
Output determination procedure [V10000] = Billing output
It defines the output categories that are allowed in a document and the sequence in which the output categories
appear in the document
Item output procedure []: It is the combination of output categories that you are allowed to use when you process
output at the item level in a document
Ex: Output for a sales order item.
Output type [RD00] = Invoice
It specifies the kind of output to be produced
Header partners [FK] = Billing document
It specifies which group of partner functions the system automatically proposes at the header level in this type of
billing document.
You define partner determination procedures in table TPAER
Item partners [FP] = Billing item
It specifies which group of partner functions the system automatically proposes at the item level in this type of
billing document.
Text determination procedure [03] = Billing header
It identifies a group of text types that you can use for this document header
Ex: Standard terms of payment
Text determination procedure item [03] = Billing item
It specifies the procedure that determines which texts are automatically assigned to each item in a billing document.
Application [V3] = Billing
It identifies the applications from which output can be sent. The output is divided according to output types and
assigned to these applications.
[] Delivery text: If you check this field it enables to copy texts from delivery note.
Save and Exit
338
339
Billing document types:
F1 = Standard invoice
F2 = Standard invoice
F5 = Proforma invoice for sales order
F8 = Proforma invoice for delivery
G2 = Credit memo
L2 = Debit memo
RE = Credit for returns
S1 = Cancellation invoice
S2 = Cancellation credit memo
IV = Intercompany billing
340
Rebates
A rebate is a trade allowance, which is going to be paid retroactively to customers based on their accumulated sales
on sales volume over a defined period.
Rebate agreement types:
0001 = Group rebate
0002 = Material rebate
0003 = Customer rebate
0004 = Hierarchy rebate
0005 = Independent of sales volume
The rebate agreement has a separate condition record for each product that customer buys. These condition records
specify the rebate amount or percentage. Due to the customer for each product with sale a rebate agreement is
finally settled when a credit memo is issued to the customer for accumulated rebate total.
Define rebate agreement types: Transaction code: VB(2
Path:
IMG
Sales and distribution
Billing
Rebate processing
Rebate agreements
Define agreement types
Define agreement types
Choose material rebate agreement type 0002 from position button
Click on details icon
Agreement [0002] = Material Rebate
Proposed valid from [3] = First day of year
Proposed valid to [2] = End of the current year
Here we define the rebate agreement valid period. Usually rebate agreement valid for one year.
Payment method []: Here we specify the payment method for rebate settlement.
Ex: Cash, Cheque, DD, etc.
Default status []: It specify the status of the rebate agreement like:
Settlement is being checked for release
Released for settlement
Settlement has been created
Final settlement already created
341
Condition type group [0002] = Material
It specifies a grouping of condition types and condition tables for use during rebate processing. Generally one
condition type assign to this agreement type.
Use: As a rule, the condition type group consists of only our rebate condition type. However if your rebate
processing requires it, you have the following possibilities:
You can assign more than one condition type to a group
You can enter the save condition type in a group more than once and use different condition
tables, or key combinations, for each instance.
Verification levels [F] = Display totals by Payer/Material
It determines the level of the detail, one see when displaying total for a rebate agreement.
[] Different validity period: Rebate agreement and condition record have same validity. It indicates rebate
agreement and condition record of the same validity periods or not.
Manual accruals order type [R4] = Rebate request for manual accruals
It is a sales document type assigned to the rebate agreement and used in the manual accruals in a rebate agreement.
[] Manual accruals: It enables manual accruals. Activate this field if you want to be able to post manual accruals
for this agreement type.
Arrangement calendar []: Assign calendar for rebate agreement. The arrangement calendar defines the end of the
validity period of rebate arrangements and controls their extension.
Payment procedure [A] = Payment allowed up to the accruals value
When we allow manual payment of the rebate to the recipient we indicate that system has to create credit memo
request of the type specified in the partial settlement field for the specified amount then when the system carries out
final settlement system takes into account the amount that business paid and remaining amount is going to be paid.
SAP uses partial settlement document type R3 and associated order related billing type is B3.
Partial settlement [R3] = Partial rebate settlement request
It specifies the sales document type, which should be used when you perform partial settlement for an agreement.
SAP uses partial settlement document type R3.
[] Reverse accruals: It ensures the system that it has to reverse the accruals up to the amount specified in the
manual payment. Should the accruals not be as high as the payment to be made the system will reverse whatever
accruals it has.
342
Settlement periods []: The settlement periods define that periodic partial settlement is to be carried out for a rebate
agreement. This can be carried out at the relevant settlement dates.
Use: Rebate agreements with settlement periods are used in rebate agreements for which a certain, regular amount
is to be paid according to the payment procedure. Only the revenue up to the relevant settlement date is taken into
account for the partial settlement.
Final settlement [B1] = Rebate credit memo request
For final settlement system proposes credit memo request type B1.
Correction [B2] = Rebate correction request
Rebate correction request document type B2 has been assign. System proposes this document type for rebate
corrections that has been taken place in the settlement.
Minimum status [B] = Agreement released for settlement
We have to specify the rebate agreement document type [0002] for settling the rebates. It specifies the minimum
status that a rebate agreement must have before the settlement can be calculated. During the processing of a final
settlement, the system checks whether the rebate agreement is assigned the minimum status.
Ex: B Agreement released for settlement
C Credit memo request already created for settlement
D Final settlement of agreement already carried out
Text determination procedure []: It determines the sequence in which the text types appear in the document.
Text ID: It specifies which text ID appears in text edits control. The text ID defines the different types fo texts that
belong to a text object.
Save and Exit
343
Configuration settings:
Pre Requisites: So as to process rebates the main 3 control parameters are:
At definition of sales organization
At customer master payer
At definition of billing document
Should be activating in this 3 places.
Create condition record rebate agreements: Transaction code: VB01
Path:
Logistics
Sales and distribution
Master data
Rebate arrangements
Rebate arrangement
VB01 Create
Specify agreement type 0002 and press ENTER
Specify the rebate recipient [Customer master payer number]
Specify the validity period of the agreement
Specify the agreement status: Blank [] = Open
344
Specify the verification level [F] = Display totals by Payer/Material
Click on conditions
Specify the material number
Select condition line item
Click on scales and maintain the scales
Save it and exit
Go to V/08 and choose our pricing procedure from position button
Include the rebate condition type B002 in between the discount
Specify the requirement as 24
Assign ERB as accounting key ERU as accruals
Save and Exit
Go to VA01 VL01N VF01
Select line item
Go to Item Item conditions
Check rebate condition type BO02 has been activated or not
Save and Exit
Like this raise another VA01 VL01N VF01 and note down all document numbers.
Display the rebate agreement
Go to VB02
Specify the rebate agreement number and press ENTER
Note down the ERROR
ERROR: The sales volume for agreement <111> is not current
FB03 to see the document overview
Exit
Then go to:
Logistics
Sales and distribution
Billing
Rebates
Update billing document
In order to execute a report specify SDBONT06 in SE38
Then accruals and business volume are updated when the accounting document for billing is created.
Setting the rebates: For partial settlement
Go to VB02
Enter rebate agreement number
Change agreement status field as B
Choose create manual accruals and enter the amount to be paid
Save and Exit
Note down the credit memo request automatically by going to VB03
Enter agreement number
Choose rebate payment Rebate document Select partial settlement
345
Click choose button and note down the credit memo request number
Now go to create credit memo with reference to credit memo request
Now release the credit memo to the accounting [If it was blocked]
Logistics
Sales and distribution
Billing
Billing document
Change
Enter billing document number to release to accounting
Now check accruals in rebate agreement by going to VB03
Enter agreement number
Choose conditions
Select condition line item
Choose payment details
Steps for Rebate process:
(1) Create sales document type R3, R4, B1, and B2 [VOV8]
(2) Item category B1N [VOV7]
(3) Define rebate agreement type 0002 [VB(2]
(4) Define condition type group [VB(3]
(5) Assign condition type/tables to condition type group [VB(4]
(6) Assign condition type groups to rebate agreement type [VB(5]
(7) Activate account determination [VKOA]
(8) Activate rebate with reference to billing document [OVB0]
(9) Activate rebate with reference to sales organization [OVB1]
(10) Activate rebate with reference to payer master record [XD02]
(11) Maintain relevant rebate condition types in pricing procedure [V/08]
(12) Assign sales document to sales [OVAZ]
(13) Maintain condition record for rebate agreements [VB01]
346
Batch Management
In normal business process especially in the pharma business all the material may be processed batch wise. The
material movement from production to invoice can be processed through batch wise. SAP follows condition
technique to determine the batch number.
Configuration settings:
Create material master by specifying checking group of availability check in Sales: General/Plant data as
[CH]
[] Check approved batch record required
[] Check batch management
Save and Exit
Specify batch level and activate status management
Path:
IMG
Logistics general
Batch management
Specify batch level and activate status management
Click on batch level to determine batch level [OMCE]
As processing can be done plant level, material level, and client level
If it is client level the batch number with specifications are same in all areas and organizational levels.
If it is at plant level the batch number and specifications should be changed or different from plat to plant.
If it is at material level the batch has its own individuality. That means the specifications and batch number
never changed.
Check batch unique at material level
Save and go back
Click on batch status management [OMCS]
Activate Batch status management active
Save and Come back
Click on plants with batch status management [OMCU]
Choose our plant from position button
[] Activate batch status management
Save and go back
Click on initial status of new batch [OMAB]
Choose the material type FERT from position button
[] Check initial status
Save and Exit
Activate document management for batches: Transaction code: ODOC
Path:
IMG
Logistics general
Batch management
Batch master
Activate document management for batches
Activate document management for batches active
Save and Exit
347
Activate internal batch number assignment: Transaction code: OMCZ
Path:
IMG
Logistics general
Batch management
Batch number assignment
Activate internal batch number assignment
Internal batch number assignment for assigned goods receipts
Choose our plant from position button
[] Check batch number automatic for goods receipt with account assignment
Save and Exit
Maintain internal batch number assignment range: Transaction code: SNUM
Path:
IMG
Logistics general
Batch management
Batch number assignment
Maintain internal batch number assignment range
Click on number ranges
Click on insert intervals
Define number range
Save and Exit
Define batch search procedure allocation and check activation
Path:
IMG
Logistics general
Batch management
Batch determination and batch check
Batch search procedure allocation and check activation
Allocate SD search procedure/activate check
Go to new entries
Specify our sales area, document type [OR],
Assign search procedure [SD0001]
SD0001 = Standard SD search procedure
Save and Exit
Activate automatic batch determination in SD
Path:
IMG
Logistics general
Batch management
Batch determination and batch check
Activate automatic batch determination in SD
Click on automatic batch determination for sales order items
Choose item category TAN from position button
[] Check automatic batch determination
Save and Exit
23.
348
Activate automatic batch determination for delivery item categories
Path:
IMG
Logistics general
Batch management
Batch determination and batch check
Activate automatic batch determination for delivery item categories
Choose item category TAN, DLN from position button
[] Check automatic batch determination
Save and Exit
Create Batch: Transaction code: MSC1N
Path:
Logistics
Central functions
Batch management
Batch
MSC1N Create
Specify the material number, plant, and storage location and press ENTER
Basic data 1
Specify the production date, shelf life, expiration date, available from, and next inspection date
Basic data 2
Specify the short text
Save and Exit
Go to change mode of batch creation MSC2N
Check unrestricted use in basic data 1 field
Save and Exit
Create another batch by using same transaction code MSC1N
Save and Exit
Define batch determination: Transaction code: VCH1
Path:
Logistics
Central functions
Batch management
Batch determination
Batch search strategy
For sales and distribution
VCH1 Create
Specify strategy type SD04 = Customer/Material
Click on key combination and Select Customer/Material
Specify customer number, validity periods and materials
Save and Exit
349
Go to MB1C and initialize the stock along with batch
Go to MMBE to check the stock overview
Go to VA01 and raise the sales order
Specify batch material number and check the status on the status bar
Go to the line item put [*] in the batch field or press F4 and choose the batch number
Save and Exit
350
Logistics Information System [LIS]
So as to generate statistical report of transactions like sales, delivery, billing SAP has provided open data
warehouse.
Data warehousing:
OLAP = Online Analytical Processing
OLTP = Online Transactional Processing
ETL = Extraction Transformation Loading
I
SAP open data warehouse contains database and updating
Database: In database we define the characteristics and key figures and we built info structure.
Updating: In updating we define the updations rules to upload the data.
Configuration steps:
Define field catalog [Self]: Transaction code: MC18
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Databases
Field catalogs
Maintain self defined field catalogs
Create
Characteristics are nothing but the fields are which the values cannot be accumulated. The report is going to be
generated for these fields.
Ex: Customer number, Sales organization, Distribution channel, Division, Material, Material group
Specify the field catalog name Ex: ZSRI
Application [01] = Sales and Distribution
Choose Characteristic catalog [as catalog category] and press ENTER
Click on characteristics push button on the application tool bar
MS Office
IBM - Mainframes
R/3 OLTP System
Open Data Warehouse
Database Update
Data Clearing
Staging Area
ETL Informatica
Data warehouse
Marketing
MM
FI
PP
Sales
Data ware Marts
OLAP
351
Choose Sales document: Header data from right screen
Choose Sales document type, Sales organization, Distribution channel, Division, and Sold to Party
from left screen
Choose Sales document: Item data from right hand screen
Choose material group from left screen
Click on Copy + Close push button
Click on Copy button
Save and Exit
Create key figures catalog
Key figure is nothing but the value of the field accumulated.
Path:
IMG
Logistics general
Logistics Information System
Logistics data warehouse
Data basis
Field catalogs
Maintain self defined field catalogs
Create
Specify the field catalog name ZKEY
Application area [01] = Sales and Distribution
Choose Key figures field catalog and press ENTER
Click on key figures push button on the application tool bar
Choose Sales document: Header data from right screen
Choose net value for left screen
Click on Copy + Close push button
Click on Copy button
Save and Exit
Create Self Defined Info structure: Transaction code: MC21
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Data basis
Information structures
Maintain Self Defined Information structures
Create
Give the info structure number Ex: S501 [S501 to S999]
Application area [01] = Sales and Distribution
Click on choose characteristics
Choose our characteristics catalog from right screen
Select the fields we required to setup info structure by double click on the fields from the left screen
Click on Copy + Close push button
Click on Copy button
Click on choose key figures button
Choose our key figures field catalog from right screen
Select the fields from left screen that we required to setup info structure by double click on it
Click on Copy + Close push button
Click on Copy button
Click on Generate icon on the application tool bar
Click on local object
Come back
Save and Exit
352
Updating
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating definition
General definition using update groups
Maintain update groups
Check update group 1 is existed or not
Save and Exit
Specific definition using update rules: Transaction code: MC24
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating definition
Specific definition using update rules
Maintain update rules
Create
Specify our info structure Ex: S501and Update group status [1] and press ENTER
Click on rules for key figure push button
Specify the event [VA] = Sales order scheduling agreement
Update type [A] = Cumulative updating
Specify the source table [MCVBAK] = Sales document header data
Source field name [NETWR] = Net value
Table for date [MCVBAK]
Date field [ERDAT] = Date on which the record was created
Click on Copy button
Click on rules for characteristics push button
Click on Copy
Click on check icon on the application tool bar
Click on generate icon
Click on updating icon
Choose our info structure by double click on it
Select Day
Synchronous updating [1]
Save and Exit
Updating control: Transaction code: OM01
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Activate update
Sales and distribution
Choose our info structure by double click on it
Check update rules as earlier
353
Day
Synchronous updating [1]
Save and Exit
Settings: Sales and Distribution
Maintain statistics groups for customers: Transaction code: OVRA
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics group
Maintain statistics groups for customers
Check 1 = Relevant for statistics
2 = Not relevant for statistics existed or not
Save and Exit
Maintain statistics groups for material: Transaction code: OVRF
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Maintain statistics groups for material
Check 1 = Relevant for statistics
2 = Not relevant for statistics existed or not
Save and Exit
Maintain statistics groups for sales documents
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Maintain statistics groups for sales document
Check 1 = Relevant for statistics
2 = Not relevant for statistics existed or not
Save and Exit
354
Assign statistics groups for each sales document type
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Assign statistics groups for each sales document type
Select document type OR from position button
Check statistics group [1] = Order, debit memo is assigned or not
Save and Exit
Assign statistics groups for each sales document item type
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Assign statistics groups for each sales document item type
Select TAN from position button
Check statistics group [1] = Order, debit memo is assigned or not
Save and Exit
Assign statistics groups for each delivery type
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Assign statistics groups for each delivery type
Select document type LF from position button
Check statistics group [1] = Order, debit memo is assigned or not
Save and Exit
355
Assign statistics groups for each delivery item type: Transaction code: OVRL
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Statistics groups
Assign statistics groups for each delivery item type
Select item category DLN from position button
Check statistics group [1] = Order, debit memo is assigned or not
Save and Exit
Update group
Assign update group at item level: Transaction code: OVRP
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Update groups
Assign update group at item level
Go to new entries
Specify our sales area
Customer statistics group [1]
Customer group material [1]
Statistical group for sales document [1]
Statistics group sales document [1]
Statistics group document item [1]
Update group [1]
Save and Exit
Assign update group at header level: Transaction code: OVRO
Path:
IMG
Logistics general
Logistics Information System [LIS]
Logistics data warehouse
Updating
Updating control
Settings: Sales and Distribution
Update grou8ps
Assign update group at header level
Go to new entries
Specify sales area and specify all fields as [1]
Save and Exit
Go to Logistic screen/Easy access screen
System User profile Own data Go to parameters
356
Parameters Value
MCL X
POK X
WLC X
Press ENTER
Save and Exit
Go to XD02
Make sure that customer statistics group [1] under sales tab should be maintained.
Go to MM02
Make sure that material statistics group [1] under Sales: Sales organization 2 should be maintained.
Go to VA01 and raise the sales order
Save and exit
Go to MCS1
Choose our info structure
Maintain the data in the selection screen
Click on execute icon
Save and Exit
357
Maintenance and Supporting
Ticket: It is a problem, which can be called as issue that are facing by end user. User sends his problems in the
form of tickets through mails. Once we received the tickets [Ticket will be pop up/displayed in our desktop] within
30 minutes we have to give the reply to end user to confirm that we have started work on particular issue. It is
called as an initial response. After initial response, we have to start work in progress. In the next stage, if we have
to do any updations that we have to send to the user through mails.
Strategy support:
The next stage we closed the ticket but wails for the user response. Once user sends confirmation, we close the
ticket.
NOTE: In some cases project coordinator assigns tickets to the consultants. In some cases functional consultant
himself has to assign tickets
Ticket types:
Problem request tickets
Enhancement tickets
Tickets priority:
Critical tickets Priority 1
High priority Priority 2
Medium priority Priority 3
Low priority Priority 4
TICKET
INITIAL RESPONSE
With in 30 minutes
WORK IN - PROGRESS
AWAITING FOR USER RESPONCE
CLOSED/PENDING FOR USER CONFIRMATION
CLOSED
358
Priority Description Response time Resolution time
1 Emergency: System shutdown or severe restrictions in the
production system Business interruption in any critical
function.
100% within 30
minutes
100% within 4
hours
2 Urgent: Production system is up, but critical business
processes are not working and no workaround is available.
100% within 60
minutes
100% within 1
day
3 High priority [Default]: Production system is up, but Non
Critical business processes are not working or critical business
processes are not working but workarounds are available.
100% within 4
business hours
100% within in 2
working days
4 Medium Low priority: No disruption to business processes.
Required information can be easily obtained through alternative
methods.
Under
investigation
Under
investigation
Ticket management software:
Clarify
Remedy
Peregrine IBM
Service center, etc.
Internal mailing system:
Lotus domino
IP [Internet Protocol Message], etc.
User types:
Core user: Someone with or without good knowledge in SAP.
Super user: Who has lot of authorizations.
SLA = Service Level Agreement: So as to give support the agreement takes place between the client and
implementation partner. That agreement is called as Service Level Agreement.
Typical landscape
Types of projects:
Supporting
Implementation
Up gradation
Maintenance
Roll outs, etc.
QA
Server
Sand
Box
Development
Server
Production
Server
Mirror
Box
SBX DEV QA PRD MIR
359
Transportation
15 days of before going to the Go Live data should be send to the server from the legacy system.
Cut Over data: Stocks, pending vendor payments, block the materials, and sales orders information should be
provided to the system. Before 2 days of the Go Live support this information should be given to the system.
NOTE: If 5
th
of the month implementation work starts that is called as cut over data.
Go Live: Go Live is the day when the client starts his transaction with SAP.
Cut over strategy: Going to the production server ad cutting the legacy system process I percentage wise like
20% of the first day, 30% of the next day and 50% of the other day like that.
Cut over strategy depends upon the organizations how they design their data and strategy. In general we decide
the sequence of the data loads for configuration settings.
Ex: Transactional data, master data, which follows what and then, make the copy of the production system a day
before after checking the successful data loads. Then we Go Live with 100%.
Functional specifications: It is a document that contains day-to-day tools, inputs, and outputs. Client gives inputs
to the functional consultants and functional consultants in turn gives outputs.
BPR = Business Process Review
KT = Knowledge Transfer
Technical specifications [Specks]
Technical specks for ABAPers
Functional specks for functional consultants
Unit testing: It is usually carried out to test multiple objects in single module. Unit testing is done in QA server or
some times in development server.
Ex: Pricing, Output, Partner functions, Text, etc. in SD.
Integration testing: It usually carried out between two modules in QA server.
Ex: SD and MM
Test case [UAT= User Acceptance Testing]: Basis people usually refreshes Quality Assurance server which takes
place 4 to 10 hours. For every refresh we have a list of transports.
CATT Test System: The Computer Aided Test Tool [CATT] can be used to automate test sequences for key
business processes. The results are logged in details and then reviewed. CATT is also used for quality tests during
release changeovers and for simulating complete business process. System administration testing involves testing
the activities of a system administrator, such as managing job scheduling, administering corrections and transports,
reacting to R/3 system alerts and logs.
Login into SAP server:
IP address is a number Ex: 128.198.84.79
Click on logon pad
Go to the properties
Specify the description
Specify the application server [IP address]
Specify the system number Ex: 00
Then one user will be create
Sand Box Development Box Testing Production
360
Testing process with Implementation:
Transportation request: It is a 12 digit alphanumeric number
SE01 to transport the request for business user
SE10 to transport the request to the server
Click on create button
Select customizing request
Give the short description
Save it
Select/Place the cursor on the request number
Then click on add user icon
Specify your user name and press ENTER
Click on release directly
Basis people maintain connections between Development server and Quality Assurance server. In weekend all the
requests are send to the production server.
NOTE: Once the customization has been transported to the server that cannot be changed.
Requirement
Work Scope Analysis
Effort Estimation
Import Analysis
Test Data
Develop the Object
Functional consultant involvement
Unit Test
Hand over
Unit Test
Integrated Test
Kick off/Sign off
Go Live and Support
361
ASAP Methodology
Accelerated SAP [ASAP] is SAPs standard implementation methodology. It contains the roadmap, a step-by-step
guide that incorporates experience from many years of implementing R/3. The road map defines control
points/milestones and also specifies the major deliverables within each milestone. In road map we follo0w the
identities the activities within each phase and assign dates to these milestones. At the end of the each phase we
come up with deliverables/work packages. At the end of the each phase we perform quality check.
5 phases in ASAP Road Map:
Project preparation
Blue print
Realization
Final preparation
Go live and support
Phase 1: Project preparation: In this phase of the ASAP roadmap, decision makers define clear project objectives
and an efficient decision making process. We define our project goals and identify scope of project
Scope of the project: Identifying the business process that we want to map into SAP, which modules we
are going to use and what functionality we are going to use for each modules. Then we decide whether we
are going to go live by big bang implementation or phased implementation, which can be described in
EASD [Enterprise Area Scope Development].
We develop the structure of the project organization and identify the members to be included in the
steering committee for the project.
Assigning the resources to work on the project.
Identify the proper hardware to be able to support development work on SAP R/3.
Preparing the development server.
Planni9ng for giving training for project people.
Identifying the business and project measurements.
Establishing standards [For proper documentation, reporting frequency and hierarchy, communication
between team members].
Identifying the persons to give authorization to access OSS note, early watch and going live check.
Having a assistance from independent party to conduct Audit/Quality checks.
Developing landscape, that is defining client instance strategy.
Defining our system upgrade strategy.
Defining procedures to manage transport requests.
Organizing kick off meetings in which we declare the structure, roles and responsibilities.
Perform quality checks and sign off.
Concept check tool can be used in theses project.
Phase 2: Blue print: Its a document that specifies all requirements of our company within identified scope of the
ASAP project.
Conceptual design phase of the project in which project team defines current business process or the AS
IS process first.
Based on this AS IS business processes, project team develops SHOULD BE processes by using
business re engineering techniques.
Mainly in this phase where we identify the requirements, perform re engineering and record what our
SAP system to deliver.
In this phase we identify the BASELINE scope.
In order to determine business requirements we integrate with end users. We use SAP tool that is Q & A
database that is generated from the EASD. Q & A database includes issue database where issues relating
project can be logged and get the resolutions from project management. By Q & A database we can
generate reports.
When answering the Q & A database we also identify the base line scope [80% of requirements].
The entire realization phase can be divided baseline scope period, one to four unit test cycles and two
integration test cycles.
We could use two of the four unit test cycles to complete our 20% configurations.
362
Based on the transactions that we identify in scope, we can specify which transactions are applicable to
which cycle. This input is trigger point for generation of the business process master list [MS Excel file].
Based on the questions that we entered, team SAP members enter answers in the form of analysis of
requirements, and then we can generate business blue print itself.
Implementing the initial stages of the system landscape and development environment.
System administration work starts here. So that development environment is ready with necessary logins.
Finalize the technical design of hardware archi8techture.
Establishing transport request management and release strategy.
Remote connection to SAP, installing SAP GUIs.
Deciding the two/three tire architecture and setting up database and application layers accordingly.
Establishing SAP clients and their purposes.
Develop and finalize the training strategy.
Phase 3: Realization: Purpose of this phase is to implement all documented requirements in the business blue
print.
Performing integration testing.
Getting ready of SAP system to productive operation.
This phase is subdivided into:
(A) Base line phase [Configuration]
(B) Final configuration and
(C) Integration test
Base line phase [Configuration]: By considering business process transactions identified in the business
process master prints, team SAP members perform configuration. While they doing the system
configuration, developing necessary programs and interfaces, we can send project members to get the
training. In this configuration minor critical processes are implemented in R/3. They demonstrate the
functionality of system to team.
Final configuration: In this step team SAP will go back a little bit and allow the project team to complete
20% project.
The work that is done at base line configuration can be refined in this phase.
Unit/Cycle tests are developed processes.
Problems are fixed if they found any errors, before moving to realization phase.
The business master list contains the lists of transactions that need to be tested and that serve as a guideline
for unit tests.
These two phases can be used to develop customer-designed reports and transactions, test interfaces, test
and develop all forms and data conversion programs.
Developing quality assurance system where all integration tests would be performed.
Integration test: Performing tests on cross module processes or phase processes that involve more than
one module of SAP to complete.
Integration test phase 1 constraints on transactions, which involve a data flow from one module to another
module.
Integration test phase 2 is to execute back-to-back processes as if the entire process was entirely within one
module.
If any error finds that should be fixed and documented.
Technical team defines authorizations for end users.
Functional team creates user specific menus
Technical team procure/plan for productive environment and archiving strategy also should be defined.
Identifying the end users and impart training.
363
Phase 4: Final preparation: This phase is to finalize our entire system configuration and environment, including
tests, user training, productive system setup.
Developing a cut over plan.
Scheduling the going live check. It is a service provided by SAP in which SAP employed experts logon
into SAP and check for factors that could affect system performance by doing test on the scope of the
project, and they give advices in a report to improve fine tune system configuration.
Setting up the helpdesk facility [Single level/Two level].
Finally start the conversion of data from legacy system to R/3 productive system. This requires
downloading the data from legacy to proper format and then uploading the data into R/3. Data can be
uploaded by manually or data conversion programmes.
Phase 5: Go live and support: The purpose of this phase is to go productive with production system, dismantle
existing system.
End user starts their transactions in R/3.
Implementation steps: ASAP Methodology Five phases are considered
Project preparation: Requirements of the project in all aspects.
Identification of team members
Developing a high level plan
Estimation of cost of the project
Duration of the project
Business blue print:
To understand the business goals of the company.
To determine the business requirements needed to support the business goals.
Formulating the TO BE processes after through review of questionnaires sent to the key users/core users.
Realization:
Mainly to implement all the business and process requirements based on the business blue print.
The system is customized step by step in two work packages: Baseline and Final configuration.
The mapping done on how the system should get configured and tested.
Final preparation:
Main purpose is to complete testing, end user training, system management and cut over activities.
Critical open issues should be resolved here.
Upon successful completion of this phase the business transactions are ready to run in the SAP system.
Go live and Support:
Transition from a project oriented, pre productive environment to a successful and live productive
operation.
Post implementation support.
System monitoring and fine-tuning.