 Business Area determination?

1.Plant and Item division

2.Sales area

3.Sales org, dist channel and item division

 Consignment order type & process?

In consignment orders you are allowing the stock to sit in your customer location. Once he informs that he used
the stock you will invoice him. If he returns the stock you will accept the stock to take it back.

Transaction Sales order type Movement Type Pricing Procedure Availability Check Item category Schedule category

Consignment fill-up KB 631 NA Yes KBN E1

Consignment issue KE 633 Applied Consignment Stock KEN C0/C1

Consignment pick-up KA 632 NA No KAN F0/F1

Consignment return KR 634 Applied No KRN DO

Consignment fillup (send materials to customer consignment).

Here you have a consignment fill up order and a consignment fill up delivery.
Sales document type is KB
Item category KBN
Schedule line category E1

In this step, you are not invoicing the customer. document flow is sales order - delivery item category. It will not be
relevent for billing and pricing because you are not charging money for these goods in this step.

In schedule line category, you will set movement type 631 & set for availability check and TOR.

Consignment issue (issue materials from customer consignment to the customer).

Here you have a consignment issue order, consignment issue delivery and a consignment issue invoice. (the flow is
very similar to a normal OR flow, but the materials are issued from the consignment stock instead of plant stock
unrestricted).
Once the customer informed you that he used all the goods or partial goods then you will create consignment issue
for used goods.

Sales document: KE
Item category: KEN
shedule line category: C0 or C1
Here you are invoicing the customer(because he used the goods). you are assigning the delivery document and
billing document to the sales document.

In item category, you are setting relevant for billing, pricing, special stock.

In schedule line category, your setting is 633 movement type, relevent for availability check & TOR.

Consignment return (return materials from customer ownership to customer consignment).

Here you have a consignment return order, consignment return delivery and a consignment return invoice. (the flow is
very similar to a normal RE flow, but the materials are returned to the consignment stock instead of plant stock
returns).
Customer found that some goods are damaged or he not able to sold the goods he want to send it back. that you are
creating this document.

Sales document type: KR

Item category: KRN
Shedule line category: D0

You will assign delivery document and billing to sales document. you will create return order, return delivery, return
billing.

Your setting item category relevent for billing, returns, pricing, special stock.
Your setting schedule line item category: 634 movement type, NO availability NO TOR.

Consignment pickup (pickup consignment stock and move it to plant stock).

Here you have a consignment pickup order and a consignment pickup delivery.

Note that in consignment fillup and consignment pickup there are no invoices since there is no change of ownership
for the materials.

Even if you create the consignment return the goods are not come to direct to your plant. For that you need to create
consignment pick up. here the owner ship is not changing so you do not need to create billing.
Assign retrun delivery to sales document type.

Sales document: KA
Item category: KAN
schedule line category: F0 & F1

Your setting item category relevent for returns. any shedule line category relevent for 632 movement type, MRP,
availability check, delivery.

Now you check your plant stock. Stock will increase

 Shipping point?  Shipping cond (sold to/order), loading group (plant), plant (order- item)
 Availability check?
 Update group? - 12, 15 & 18

Update Group
The credit update controls when the values of open sales orders, deliveries, and billing documents are updated.
The open order value is only updated for schedule lines that are relevant for delivery.

Update group 000012

When a Sales order is created, system increases open order value from delivery-relevant schedule lines. S066-
OEIKW (S066 information structure, OEIKW- Open sales order credit value (schedule lines) ) goes up.
When order is delivered, system reduces open order value from delivery-relevant schedule
lines and increases open delivery value. S066-OEIKW decreases and S067-
OLIKW (Open delivery credit value) increases
When delivery document is billed system reduces open delivery value and increases open billing document
value. S067-OLIKW decreases and S067-OFAKW (Open billing document credit value) increases
When billing document is released for financial accounting, system reduces open billing document value and
Increases open items (S067-OFAKW decreases)

In Brief when order is created, value of S066 information structure is increased by the open order value. When
order is delivered, value of S066 information structure gets decreased decreasing the open order value and
value of S067 information structure gets increased increasing the open delivery value. When delivery is invoiced,
value of open delivery gets decreased and value of open billing documents gets increased again S067
information structure gets affected. When billing documents are released for accounting value of open invoices
gets decreased and value of open items gets increased. S067 information structure value gets decreased.

Update group 000015

When delivery is created, system increases open delivery value and open billing document value
When billing document is released for financial accounting system reduces open billing document value and
increases open items.
Update group 000015 does not use open sales order value, but uses only open delivery, open invoice and
accounts receivable. 000015 will be used with customers who orders high value sales orders over a long time
frame in the future. You donu2019t wish to stop them placing orders, even though you wonu2019t deliver
anytime soon, so you only check your companies risk that is u2013 the open delivery, billing and open items
value. The open sales order value is not checked, as these orders could be cancelled or by the time. At delivery
these become values we need to check.

Update group 000018

If sales order is not relevant for delivery system determines Update group 000018. This update group will be
always used by order items which are billed order-related (VBAP-FKREL = B for example).
When sales order is created S067-OLIKW goes up.
When invoice is created S067-OFAKW goes up, S067-OLIKW goes down
When account posting is done u2013> S067-OFAKW goes down and A/R goes up.
When sales order is created system increases open delivery value
When billing document is created for the order, open delivery value decreases and open billing documents value
increases.
When billing documents are posted for accounting open billing documents value decreases and accounts
receivables increases.

Note
 If a document cannot be processed with the update group we specify, the system determines the next possible
update it can carry out. For example, if we select Update group 000012 which, at delivery, reduces the open
order value and increases the open delivery value. Assume that one item in the order is not relevant for delivery.
In this case, the system automatically determines Update group 000018 for this item. Update group 000018
increases the open delivery value for the order item. The system uses the confirmed quantity of delivery-relevant
schedule lines to update the order value

 general data of customer master?  address, control data, marketing, comm, payment transact,
unloading points, contact person, foreign trade
 combining several order to delivery ?

1.Shipping point
2.Ship to party
3.Delivery due date
4.Route &
5.Incoterm

 combining delivery in one billing?

Payer
Payment terms
Billing date or billing due date
Destination country
Billing doc type
Incoterms
Actual GI date

 scale type?

A - Base scale
B - To-scale
C - Not used
D - Guaranted-to interval scale

billing +/- ?

 header cond?  manual, no access seq, It will be copied to each item by default, In the Pricing Procedure
mark the condition types as "Mannual". Cond recod cant be created as there is no access seq.

 Movement type of 3rd party order?  No

 GI is required for billing?  Billing before PGI is possible in standard SAP.Use standard routine 11 in
delivery to billing copy control at header level.This routine allows you to to billing before PGI. For
standard scenario like PGI before billing routine 3 is used in delivery to billing copy control at header level.
This routine ensures that PGI is done before billing.
Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on
billing is available at every stage of order processing and delivery processing.
This component includes the following functions:
1. Creation of:
a. Invoices based on deliveries or services
b. Issue credit and debit memos
c. Pro forma invoices
2. Cancel billing transactions
3. Comprehensive pricing functions
4. Issue rebates
5. Transfer billing data to Financial Accounting (FI)

 Pricing procedure based on Sold to ?  Yes then (Sales Area+ customer pricing Procedure+ Document PP)
 Can be Sold to change during sales order creation ?  yes, but if delivery is created then NO
 Pricing procedure for delivery ?  Yes can be there.
 2 items in 1 sales order but 2 delivery ?  split invoice or ..??  Partial Delivery

Split Delivery criteria:

1. Different delivery dates for line items.

2. Different ship to parties for line items.
3. Different routes for line items.

 Condition indices ?  You can create and use condition indices. You can use these indices to display,
change and create condition records with reference. This transaction can include condition records with
several condition types and tables. For example, you can use a condition index if you want to see all
condition records that apply to a particular product regardless of whether the records are prices or
discounts. In this case, you can use one of the standard condition indexes. Or you may want to see a list of
condition records that contain a particular sales deal and a material from a user-specified list of products.

 Release status in condition table ? Condition tables are created for 3 types of scenarios:
-Planning
-Simulation
-Pricing
In case of the use of condition tables in pricing we check both the boxes
-with validity Period
-With release Status.

 Billing vs accounting ?
 Pricing type ?  can be changed via Copy Control

 Billing header contains ? output type, partner etc ?

Header
In the header, you find general data valid for the entire billing document. For example,
 1. Identification number of the payer
2. Billing date
3. Net value of the entire billing document
4. Document currency
5. Terms of payment and Incoterms
6. Partner numbers, such as the identification number of the sold-to party
7. Pricing elements
Items
In the items, you find data that applies to one particular item. For example,
1. Material number
2. Billing quantity
3. Net value of the individual items
4. Weight and volume
5. Number of the reference document for the billing document (for example, the number of the delivery on
which the billing document is based)
6. Pricing elements relevant for the individual items
The billing document is controlled via the billing type.

 Rebate is processed for Sold to/payer/ Ship to…? Payer

 Rebate require check at ship to/billing type..?  Sales Org, Payer and Billing type
 Copy control b/w delivery and billing ?  Header: Requirement, copy no. item, assignment no, , Item :
Item Category,
 After Inquiry Contract/scheduling Ag/OTC ?  OTC

Customer contracts are outline customer agreements that display when sales materials or services are sold within
a certain time period.

A customer scheduling agreement is an outline agreement with the customer containing delivery quantities and
dates. These are then entered as schedule lines in a delivery schedule.

Cash Sales and Rush Order:

1) Cash sale : in this delivery automatically happen when you save the sales order. After that you have to give an
invoice to the customer.

2) Rush order. Here also delivery automatically happen when you save the sales order. But the difference is you
can send invoice after some time but the delivery should happen immediately.

If you goto any super market first, you pick up the item and then pay the bill and then you will get the bill, this
process is cash sales.

Cash sales is order related billing whereas RO is delivery related.

Cash sales is not relevant for availability check as you will be picking the goods whereas RO is relevant for
availability check.

Cash sales is also not relevant for credit management whereas RO is relevant credit management.

Cash sales uses RD03 as output which immediately prints the invoice whereas RO uses standard output RD00.

Cash sales has one time customer account group where as RO normally doesn't.

For cash sales order type is BV or CS and for RO it is RO

Cash sales triggers petty cash a/c where as in RO customers account is debited.

Delivery and settlement will be done immediately in cash sales where as in RO only delivery will be done
immediatrly.

Rush Order/Cash Sales –

Rush orders and Cash sales are sales document types that are used in the sales from plant process or when the
customer needs to pick their goods immediately from the warehouse.

In the sales document type, the following changes have to be made for rush order/cash sales –

a. order type – RO/CS

b. shipping conditions – immediately

c. immediate delivery – X

d. lead time in days – not to be specified

e. delivery type – LF/BV

f. billing type – F2/BV

g. item category – TAN/BVN

h. schedule line category – CP/CP

i. movement type - /601

In case of rush orders and cash sales once the goods have been withdrawn from the warehouse, picking and
posting goods issue can begin.

In case of rush orders, when you create the billing documents the system prints the invoice papers and sends them
to the customer.
But in case of cash sales, an order related billing index is generated automatically. This updates the billing due list.
Billing type BV is created, while the billing due list is being processed and the system does not print invoices during
billing for a cash sale.

In cash sales when you save the order, the system automatically generates a cash receipt that can be given to the
customer as an invoice and the goods are picked up from the warehouse immediately by the customer. You
control the output with output type RD03, contained in the output determination procedure for order type CS.

Movement Type:

601 Goods issue for delivery (Shipping)

In Shipping, this movement type is created automatically with the Goods issue for delivery function.
The quantity is taken from unrestricted-use stock.
Possible special stock indicators:
E, K, Q
603 Goods issue for stock transport order (Shipping) with additional
item
If you issue goods for a stock transport order in Shipping using movement type 641, you can use this movement
type to assign an extra item to the order.
The ordered material is transferred to the stock in transit of the receiving plant. The material for the additional
item is transferred from unrestricted-use stock in the issuing plant to stock in transfer in the receiving plant.
You can also use this movement type without referencing a purchase order.
Possible special stock indicators:
None
See also: 303, 641
605 Goods receipt for a stock transport order (Shipping) with
additional item
You can use this movement type to transfer into unrestricted-use stock the material you posted into stock in
transfer in the receiving plant using movement type 603. You post the goods movement with reference to the
purchase order (if available) or the delivery.
Possible special stock indicators:
None
See also: 305 and 641
621 Transfer posting unrestricted-use - returnable packaging (Shipping)
The quantity is transferred from unrestricted-use stock to the returnable packaging stock at customer.
Possible special stock indicators:
none
623 Goods issue from returnable packaging stock at customer (Shipping)
This quantity is withdrawn from unrestricted-use returnable packaging stock at the customer.
Possible special stock indicators:
V
631 Transfer posting unrestricted use - customer consignment stock (Shipping)
The quantity is transferred from unrestricted-use stock to consignment stock at customer.
Possible special stock indicators:
E, Q
633 Goods issue from customer consignment (Shipping)
The quantity is withdrawn from unrestricted-use consignment stock at the customer.
Possible special stock indicators:
W
641 Goods issue for a stock transport order (Shipping)
The quantity is transferred using a delivery in Shipping from unrestricted-use stock of the issuing plant to stock in
transit of the receiving plant.
The goods receipt for the stock transport order takes place using movement type 101 and can, if required, refer to
the purchase order or to the delivery. If a purchase order item is flagged as a returns item in the stock transport
order, you can post the goods receipt of the returns in the issuing plant with movment type 671.
Possible special stock indicators:
E, Q
For the special stock indicators E and Q and for purchase orders assigned to an account, you must ensure that the
quantity is not posted to the stock in transit of the receiving plant.
See also: 351, 643, 671
643 Goods issue for a cross-company
stock transport order (Shipping)
It is used only for cross-company stock transport orders with SD billing and invoice. The quantity is withdrawn from
the unrestricted-use stock of the issuing plant. No stock in transit is created here. In the second step, the goods
receipt must be entered in the receiving plant. If a purchase order item is flagged as a returns item in the stock
transport order, you can post the goods receipt of the returns in the issuing plant with movment type 673.
Possible special stock indicators:
E
See also: 351, 641, 673
645 Goods issue for a cross-company
stock transport order in one step (Shipping)
Unlike movement type 643 when a goods issue is posted using movement type 645, a goods receipt line is
generated automatically 101). If a purchase order item is flagged as a returns item in the stock transport order, you
can post the goods receipt of the returns in the issuing plant with movment type 675.
Possible special stock indicators:
E
See also: 675
647 Goods issue for a stock transport order in one step
(Shipping)
Unlike movement type 641 when a goods issue is posted using movement type 647, a goods receipt line
(movement type 101) is generated automatically in the receiving plant. If a purchase order item is flagged as a
returns item in the stock transport order, you can post the goods receipt of the returns in the issuing plant with
movement type 677.
Possible special stock indicators:
E, Q
See also: 677
651 Returns from customer (Shipping)
Using movement type 651, you post returns from a customer with a return delivery in Shipping to blocked stock
returns.
Possible special stock indicators:
None
See also: 451, 453, 653
653 Returns from customer (Shipping) to unrestricted-use stock
With this movement type you post returns from the customer with returns delivery via Shipping directly to the
valuated stock.
Possible special stock indicators:
E
See also: 451, 453, 651
655 Returns from customer (Shipping) to stock in quality inspection
With this movement type you post returns from the customer with returns delivery via Shipping directly to the
valuated stock.
Possible special stock indicators:
E
See also: 451, 453, 651
657 Returns from customer (Shipping) to blocked stock
With this movement type you post returns from the customer with returns delivery via Shipping directly to the
valuated stock.
Possible special stock indicators:
E
See also: 451, 453, 651
661 Returns to vendor via Shipping
As with movement type 502, a return delivery to the vendor is entered without reference to the purchase order,
but the goods issue is posted via a delivery in Shipping.
Possible special stock indicators:
E
671 Returns for stock transport order via Shipping
If a purchase order item is marked as a returns item in a stock transport order using movement type 641 when a
goods receipt for a stock transport order ( 101) is posted, the return is posted to stock in transit using movement
type 161. When the return arrives, the issuing plant posts the goods receipt for the return using movement type
671. Movement type 671 (like movement types 352 and 642) reduces the receiving plant's stock in transit and
increases the issuing plant's unrestricted-use stock.
Possible special stock indicators:
E, Q
673 Returns for cross-company stock transport order
(Shipping)
673.
Possible special stock indicators:
675 Returns for cross-company stock transport order
(Shipping) in one step
677 Returns for stock transport order in one step (Shipping)

Route Determination:

Route is determined automatically in the sales order based on:

1. Departure zone or country of the delivering plant.
2. Destination zone or country of the Ship to Party.
3. Shipping condition from the customer master.
4. Transportation group from the material master.
5. Weight Group.

Sl.no Determination Object Rules for determination

1 Sales document Sales Area
+ Document Type

2 Item category Document type

determination for Sales + Item category Group
document + Usage
+ High level Item Category

3 Schedule line category Item category of the corresponding item

determination + MRP type of the Material

4 Delivery document Delivery document default type attached to Sales document type
determination

5 Item category Copy form Sales document

determination for Delivery or
document Delivery Document type
+ Item category Group
+ Usage
+ High level Item Category

6 Shipping Determination Delivery Plant

+ Shipping condition (Customer Master - Sold-to Party) OR Sales
Document Type
+ Loading group(Material Master)

7 Route determination Departure zone of the shipping point (Customizing)

+ shipping condition(SP)
+ Transport group(MM)
+ Transportation zone of the Ship to party(General Data)

8 Storage location Shipping point

determination + Delivery plant
+ storage condition

9 Picking determination On bases of MALA rule

Delivery Plant
+ Loading Group
+ Storage condition(MM)
(storage rule also assignment to Delivery type)

10 Packing determination Package usage

11 POD This object use for confirmation of delivery, based on which billing
document can create

12 Billing document Sales document type is maintained as default type

determination For Billing plan, Billing Type maintain under Billing Plan Type of
Maintain Date Category for Billing Plan Type

13 Account determination Chart of Accounts

 + Sales Org
+ Customer Account grp (Customer Master - Payer)
+ Material Account grp (Material Master)
+ Account key

14 Business area Plant/Valutaion Area

determination OR
Sales area
OR
Item division + Plant

15 Company code Sales organization uniquely attached to Company code

determination

16 Partner determination At -Account group level, sales document header level, item level, sales
document delivery level, Shipment level, Billing document level and
item level

17 Delivery Plant The system will determine Plant details at following in given
determination sequence
Customer - Material info record
From customer master Ship-to Party
From Material Master

18 Output determination Output determination at Sales document level, Delivery level, Billing
level

19 Price determination Pricing procedure

Sales Area
+ Document Pricing Procedure indicator from Sale/Billing Document
type
+ Pricing Procedure indicator from Customer Master (Sold-to Party)

20 Text determination 1)Customer Material Information Record

2) Customer Master (General text, Accounting text, Sales text)
3) Material master text (Sales text or PO text)

21 Warehouse determination Ware house number

+ Plant
+ Storage location

22 Lean Warehouse Lean ware house activate,

determination Plant
+ Storage Location
+ Ware house number

23 Tax determination Destination Country of Ship-to Party

+ Departure Country of Shipping Point
+ Tax Classification for Customer from Customer Master (from Sold
To)
+ Tax Classification for Material Master(Sales Org1)
24 Routing determination Shipping point
+ Delivery plant
+ Loading condition
+ Shipping condition

25 Material determination Create condition record

Maintain Customer Material record

26 Product substitute Create condition record

27 Product Exclusion Create condition record(Not to sale any particular product)

28 Product listing Create condition record (Sale of one particular product)

29 Credit check Credit check at Sales document level OR at Delivery OR at Good issue
Risk group at Sales document level and Risk category from Customer
Master, Item category credit check should be activate

30 Incomplete log Incomplete log assign to Status group, which is assign to Sales
document, Item category or Schedule line level

31 Rebate condition setup customer master billing info checked, Sales organization activate,
Billing document activate

Material Listing/Exclusion :

Listing: By creating a material listing for a specific customer allows that customer to order ONLY the materials that
are maintained in the list.

Exclusion: By maintaining an exclusion record for a particular customer, the customer is NOT allowed to order
these materials.

Condition Exclusion :

Condition exclusion is created at condition type and condition record level with the help of Condition Indicator.

Condition Indicator is configured in “Control Data 2” as “Exclusion” in the condition type. It Indicates whether the
system automatically excludes the discounts that are proposed during pricing. You can set this indicator in two
ways:

 For a particular condition record (the field appears on the Details screen).
 For all records of a particular condition type (the field appears on the screen where you define the
condition type).

Condition Exclusion Group Procedure:

A Best condition between condition types

B Best condition within the condition type

C Best condition between the two exclusion groups

D Exclusive

E Least favorable within the condition type

F Least favorable betweent the two exclusion groups

L Least favorable between conditions types

Implementation Project… ?

- Project preparation (team member, kickoff, procedure, tilemlines)

- Business blue prints (requirement gathering, org str, )
- Fit gap analysis (AS IS process and To Be  filling the gaps) now example 
- Realization (Implementation in quality sys as per documented blueprint, config, program, documentation, UAT)
- Golive (sys mangamnt, cutover stragedies, end user training)
- Support (continuous improvmnt, sys performance, quick fix)

-----------------------------------------------------------------------------------------------******------------------------------------------------

. What is transfer order?

ANS: Transfer order is created for picking the goods in warehouse management. Transfer order contain
1. Material Number
2. Quantity to be moved
3. Source storage bin to destination storage bin .
Through this transfer order picking list generated.

2. What are the fields in pricing procedure?

There are 16 fields that are given below:

ANS. 1. Step 2.Counter 3 Condition type 4. Description 5. From 6. To 7. Mannual
8. Mandatory 9. Statistic 10. Print 11. Subtotal 12. Requirement 13 alternative calculation type
14. Alternative condition base value 15. Account key 16 Accrual

3. What are the Standard output types in SD?

ANS. BA00 for order LD00 for delivery RD00 for billing and RD03 for Cash sales.

4. What is Condition type?

ANS. Condition type is a pricing element such as discount,freight,surcharge.This are used in pricing procedure to represent
condition record.

5. What is difference between delivery document & scheduling?

ANS. Delivery document is an electronic document where store when how much quantity of materials and where the
materials should go ? on the other side, scheduling represent when materials will be delivered in that case backward
scheduling and forward scheduling is used.

6 How is item category determined?

ANS .In general item category determination is happened through sales document type+item usage+item category
group+higher level item category +default item category
In the creating from reference document item category determination is happened from copy control where source
item category to target item category.if it is not maintained ,item category determination is happened though normal
determination like sales document type+ item usage+item category group + higher level item category+default item
category.

7. What is Extract used in condition tech. in pricing?

ANS. Condition table+Access sequence+Condition type+pricing procedure=condition technique.

The above extract is used to find suitable condition record.

8. What is the difference between plant and storage location?

ANS .A plant may be delivering plant and production plant and storage plant.
In Sales and Distribution, since plant is assigned with sales organization and distribution channel, it is
called delivering plant.
Storage location, where the materials are stored, that is called storage location. storage location is located in plant.
Many storage locations can be located in one plant.

9. What is Lean Warehouse Management?

ANS. Lean warehouse management is a small part of function provided by warehouse management structure.
It only includes fixed bin storage. it switch off some functions of warehouse management activities that are given
below : storage section
Reserve storage bin
Strategy to put away and picking
Replenishment
Inventory of storage bin level.

10. What is the purpose of sales document type?

ANS. Sales document will determine whether the process will be cash sales or rush order
It will determine the process whether the order will be normal order or release order.
It will determine what will be the delivery type of a order.
It will determine what will be the billing type of a order.

11. What is an integration point between SD AND MM?

ANS. When order is created availability check and transfer of requirement is happened, that is one SD and MM integration
point.
In the case of delivery picking is happened and after that PGI is happened that is another integration point of SD and
MM.

12. What are MRP types?

ANS. MRP Means How the material is planned-such as Automatic reorder point planning, annual reorder point planning,
Forecast Planning.
MRP type - Key that determines whether and how the material is planned. You have the following options:
Manual reorder point planning
Automatic reorder point planning
Forecast-based planning
Material requirements planning with forecasts for unplanned consumption
Master production scheduling (MPS)

MRP (Material Required Planning) type controls which mrp procedure can be used to plan a material and which mrp
parameters can be entered when maintaining material master. you have to enter this mrp type on MRP 1 view of material
master record.
ND - No planning
PD - Planning
MRP in brief :
MRP is the planning tool in SAP which will look at all aspects of a material and is highly based upon the master data of the
material. MRP looks at current inventory, current requirements, open purchase req/orders and so on. So if a material is
required to satisfy a sales order and there is no inventory, MRP will create a planned order if the item is to be produced in
house. This planned order can then be converted to a production order by the master scheduler. If the item is to be
procured, then MRP will create a purchase req which the Buyer will convert to a purchase order. This is just one scenario,
the system is highly configurable and will do pretty much whatever you tell based on config and master data.
Consumption based planning
- Reorder planning
- Forecast based planning
- Time phased planning
Details of re-order planning
Our motive is to maintain optimum stock level of all the material included in the resource planning. so in this user or system
sets a particular quantity of stock as reorder point . Whenever stock quantity fall below this point(reorder point) mrp comes
into action and generates procurement proposals according to the settings done in implementation guide
MRP run procedure
1. Create requirement or demand in MD61
2. MRP run by MD02 for a single material
3. See the result in stock requirement list in MD04.
MRP run we can carry out by
1. MD02 - single item multi level
2 .MD03 - single item single level
3 .MD01 - Total planning
4. MD04 Check MRP
5. MD05 MRP lists

13. What is use of customer Account group?

ANS. Customer Account group control the master data of customer

It help to determine customer number assignment
It help to determine which field should be optional and which field should be mandatory and hide.
It control transaction of a customer master
14. What is the difference between incomplete order and backorder processing?

ANS. In the case of creating sales order, when mandatory fields are missing, it is called incomplete order and it is decided
by incompletion procedure.
Backorder processing when material quantity is not confirmed or delivery confirmation date cannot be kept.
There are two types of back order processing 1) manual back order processing
2) Automatic via rescheduling
Backorder Processing - Backorder processing is the processing of a backorder. Now, a backorder means a sales
order which has not been confirmed in full or has not been confirmed at a certain delivery date.
For instance, you receive an order from a very important customer for material "A" but the entire quantity of A is
committed to another customer "B" via earlier sales orders and this is where BACKORDER processing helps you to
change the commitment and shift stock due for B to A. This is the benefit of this functionality.

Rescheduling - Rescheduling on the other hand is a proposal which can enable confirmed quantities already
assigned to sales orders might be reassigned to other orders. This reassignment may be required due to an order of
higher priority which may require an earlier delivery date.
For Instance, the entire quantity can be delivered in one delivery but at a later date, as a comparison of quantities for
this line reveals an increase.

Use: - If an order item is backdated

1. Order quantity not complete or
2. Required delivery date has not been confirmed in time.

Scenario:-

Backorder processing is functionality in SAP where we can change the commitments and over-ride the
blockage of stocks marked against sales documents/deliveries.

For e.g.
1. You receive an order from a very important customer for material "A" but the entire
quantity of A is committed to another customer "B" via earlier sales orders and this is
where BACKORDER processing helps you to change the commitment and shift stock
due for B to A.
2. While doing sales order the material is not available sometimes at that time we give the
delivery date whenever we expect goods. if the goods available earlier than delivery
date we can go back with sales order and deliver the goods before first delivery date

Types of Backorder

There are two types of Back order processing

1. Manual Backorder
2. Reschedule Backorder
1. Manual Backorder Processing

In this process we can reduce the confirmed quantity of line item of one sales order and reallocate
that quantity to item of another sales order.

This process can be done through two ways

SD Document: - [V_RA]

Material: - [CO06]

T.Code: - [V_RA]
Here we have to fill either Material date or Customer Data along with Organizational Data

Select all open sales order for which you want to do Backorder processing.

Then click or “Backorders” button.

1st row tell us on dated 12.08.2012 plant 1000 (summation of all storage locations) received total
stock of 10pcs.

2nd row tell us, sales order number 12100 required of 10pcs and confirmed also 10pcs which is
available on dated 17.08.2012

3rd row tell us, another sales order number 12101 created which required quantity is 5pcs but not able
to confirmed on material available date.

4th row tell us, mobile material is available 10pcs in only storage location 0001 of plant 1000 from
dated 12.08.2012.

Because of few reasons business wants to do delivery on basis of high priority of sales order 12101.

For this we have to deallocate the 5pcs from sales order 12100 and reallocate to the sales order
12101.
Select the 2nd row which represent to sales order 12100 and clicks on “Change confirmation” button.

Change committed field from 10 to 5.

Click on “Copy” button.

Now you can see the 2nd row sales order number 12100 confirmed quantity changed from 10to 5.

And for that deallocated quantity 5pcs from sales order 12100 can reassign to sales order 12101 and
confirm on dated 17.08.2012

For this select 3rd row sales order 12101 and click on “change Confirmation” button
Now change the committed field from 0 to 5 and press enter then you will find above screen.

Then Click Copy Button

 Now you can see for sales order 12101 is available on dated 17.08.2012 with confirmed quantity 5.

2. Rescheduling Process.
When it should use:-
a. When we reduce the confirmed quantity of one sales order and want to allot to another
sales order automatically on basis of delivery priority rule.
b. Or for one few sales orders created during non availability of stock that time system will
provide delivery date to in future date on basis of delivery scheduling calculation after
that stock is available before Delivery confirmation date then we wants to redetermine
the available date and delivery date on basis of delivery priority rule.

The Delivery priority is taken from the customer master in sales order and can be used as a sort
criterion for orders during rescheduling process.
T. Code [V_V2]
Fill material and plant deselect Simulation and execute.
 Click on YES button in pop up box of “Updating Backorders in sales”

Here system shows that for sales order 12100 get new confirm quantity is 10pcs before that it was
only 5pcs.

The backorder reschedule does the job that your users are doing manually i.e. "re-allocating" the
available stock to the open orders.

V_RA:- backorder list and V_V2:- backorder reschedule for online processing.

V.15 – Backorder List

We can set up a regular batch job with programs SDV03V02 and/or RVV50R10C.

15. Why does the customer master have different views?

ANS: there are three views in customer master data that are given below:
a) General Data: general data is applicable for accounting and sales and distribution purpose
 Address,Control data,payment transaction,marketing,unloading point,export data,contact person
b) Company Code Data: Company code data is applicable only accounting purpose.
Account management,payment transaction,correspondence,insurance
c) Sales area Data: sales area data is applicable only sales and distribution purpose.
Sales,shipping,billing,partner function.

16. What is t-code for listing the blocked documents?

ANS.T-code of listing blocked VKM1.

17. What is batch split?

ANS. When products are coming from different batch and it’s batch number are different, batch split are happened.

18. What is Product attributes?

ANS. By defining product attributes, you take customer preferences for product substitution into account. For example,
you may have customers who refuse products produced abroad, or products that contain a coupon. When you define
product attributes, the system checks them in product selection, ignoring any material with a product attribute that the
customer has explicitly rejected.

19. What is difference between SD account key and FI account key?

ANS. As far as account key concern both are the same to find the right G/L Account through condition technique.SD
account key will be from pricing procedure. On the other hand, FI account key will be from tax procedure.

20. How is credit control determined?

ANS . Credit control area determined by credit control area+Credit Risk Category+Credit group.

21. What are the parameters in FD32?

ANS.you can see overview of the customer, address of the customer, central data of customer, status and payment history
of the customer.

22. What is the difference between routine and requirements?

ANS. routines define which field should copy from reference document to target document.
Requirement should meet when is being copied from source document to target document. If requirement is not met,
a warning message is displayed or process may be terminated.

23. What is condition supplement and why is it used?

ANS. Condition supplement don’t have any access sequence. They found together underlying one condition record.
You set allowed condition supplement in customizing for the main condition type by assigning different pricing procedure. In
the case of creation of sales order, when pricing procedure is taken into account, condition supplement is applied.

24. What is the difference between milestone and periodic billing?

ANS. Milestone billing is used in Plant engineering and construction, full amount of money are spreading over several dates
within billing plan.
Periodic billing is used in Rental contract. Full amount of money are billed over certain period of time.

25. What is the landscape?

ANS. They system landscape basically is the set-up or arrangement of your SAP servers. Ideally, in an SAP
environment, a three-system landscape exists. A three-system landscape consists of the Development Server-DEV,
Quality Assurance Server-QAS and the Production Server-PROD. This kind of set-up is not primarily designed to
serve as server clusters in case of system failure, the objective to enhance "configuration pipeline management".

26. What is variant in reporting?

ANS. Variant is a variation of report which delivered either R/3 system or save it. Each variant contains different fields that
are populated when you call up the report.

27. What is the difference between Static and Dynamic Credit Check?

ANS. Static credit check is a check which is comparing the credit limit assign to the customer to the total value of open
sales order, plus total value of open delivery that are not yet to invoiced plus total amount billing document that are yet to
be passed on accounting plus total value of billing amount that are yet to be paid by customer.
Dyanamic credit is a check which is comparing the credit limit assign to the customer to the total value of open sales
order, plus total value of open delivery that are not yet to invoiced plus total amount billing document that are yet to be
passed on accounting plus total value of billing amount that are yet to be paid by customer.
But, difference is that time period (credit horizon) is attached with dynamic credit states that the system is not calculated all
open item and all open value after credit horizon. On the other hand, there is not time period is not attached with static
credit limit. For this reason, all open items and all open values is taken into account.

28. What is difference between the item proposal and dynamic proposal?

ANS.In item proposal,when you enter details in sales document and click the propose items to get item list of the customer
regularly purchases
On the other hand,once you specify the sold-to-party and press enter,system automatically gives the list of materials
for the customer regularly in a faster way than item proposal.

29. What is a field catalog?

ANS. A field catalog is a list of newly added field. If you want to create table, you have to create field that is added to field
catalogue. After that you can create table.

30. What is the difference between condition type EK01 and EK02?

ANS. EK01 is used as actual cost and EK02 is used as calculated cost. Both are used in make-to-order production. In the
case of EK01, unit cost is issued first position on the conditions screen for the items. The value can be used for the basis of
price determination.

On the other hand, in the case of EK02, the result of unit costing is simply a statistical value which is compared with price.
Please note the following points :
1) The condition type must have condition category 'Q' (costing).
2) The condition type must agree with the condition type defined for unit costing in the pricing procedure.

31. What are the user exits?

ANS . User Exit is the place where you can enhance sap documents and you can activate and deactivate some fields and
create some fields through coding.Even,you can create new routine and formula through coding.But,you cannot change
standard sap document. This is can be done by ABAP (Advance Business Application Programming)

32. What is the Function of item category group? Material Master Sales Org 2

ANS. Item category group will determine the item category of an item in a sales document. It is maintained material master
sales organization 2.Suppose,in the case BOM,if item category group is ‘ERLA’,higher level item category ‘TAQ’ and sub-
item category is ‘TAE’.On the other hand, if item category group is ‘LUMF’,higher level item category is TAP’ and sub-item
item category is ‘TAN’. Item category depends on sales organization and distribution channel. it is only outbound delivery.

33. What is pricing procedure?

ANS. Pricing procedure will determine how pricing take place in sales order and billing. In Pricing procedure there are
condition types and there are 16 columns which control the condition types to determine how the condition type will behave
in a pricing procedure.

34. What is condition exclusion?

ANS. Condition exclusion indicator can be set in condition type and condition record.
If it is set in condition record, condition type is excluded from being accessing and requirement function is ignored.
On the other hand, condition exclusion in condition record help to compare condition record between two condition
exclusion groups or between two condition types to determine best price .All other condition types will be deactivated.

35. Which delivery document type for STO process?

ANS .There are two STO (Stock Transfer Order) that is 1) intra company stock transport order which delivery document
type is ‘UB’ and 2) inter company stock transport order which delivery document type is “NB”.

36. What is difference between the header level condition and item level condition?
ANS. Header level condition is maintained in header level pricing procedure in sales order. This condition does not have
any access sequence.So; you have to maintain condition record manually. This condition record distributed proportionately
between items in whole documents .if you assign formula of alternative condition base value with condition type, condition
type will distribute between items in whole document on the basis alternative condition base value.
Item level condition is applicable only for that item. it has access sequence .So, condition record can be fetched
automatically from condition table.

37. What is the link between credit management and subtotals?

ANS. In pricing procedure pricing value plus tax is stored in a subtotal field that is A) VBAP-CMPRE which is used for credit
check in order and delivery through credit group which is assigned with sales document type and delivery document type.

38. What is Delivery group and what is its purpose?

ANS. Delivery group is used for credit check. Because credit group is assigned with delivery group.
Automatic credit control is happened in delivery group.

39. What is main purpose of maintaining the master data?

ANS. Master data provides important sources of data for creating documents.
Master data help to run business transaction smoothly.
Master data help to define which field is important and which field is important

40. What is line item?

ANS. Line item is an individual item in a sales document which has a item detail such as shipping point, division and route.

41. What is difference between listing and exclusion?

ANS. If company want to give certain products to particular customer, company need to create listing through tcode
VB01.On the other hand, if customer doesn’t want to purchase one product among the other products .You can exclude this
product from the list. Through tcode VB02.Listing and Exclusion follow condition technique.

42. What are the functions performed in a support client?

ANS.the function is to solve day to day issue sent by the end user and sometimes enhancement too.
What is the access sequence for header conditions?

43. What is Header Condition

ANS.In Header condition doesn’t have any access sequence .For this reason, it has to be maintained manually in header
level pricing procedure in sales order.So, it’s value is divided among different items in a sales order proportionately such as
HM00, AMIW condition type.
44. What are the highest organizational units in SD, MM, PP and FICO?

ANS .Highest Organizational unit in SD is Sales Organisation.Highest organization unit in MM is Plant and Highest
Organization in PP is Plant. Highest organization unit FI is Company code and CO is controlling area.

45. What is the functionality of negative posting in billing document?

ANS.In standard system, credit memo and cancellations document is posted opposite side of account as compared to
customer receivable account. Customer requested that credit memo and cancellations should be posted same side of
customer account, this allow the account to have zero balance. The totals line in the account can also be zero, in other
word, a sales does not take place.Therefore,you have activate negative posting option in billing doc type.

46. How is shipping point determined?

ANS. Shipping condition from sales document type, if it is not maintained, it takes from sol-to-party customer master sales
area shipping tab page.
Delivering plant from customer material info record, if it not maintained, it takes from ship-to-party customer master
record .if it is not maintained, it takes from material master sales-org1.
Loading group from material master record plant/storage 1 tab page

47. What is difference between transport and task?

ANS.The transport request contains transport no and task no. Task no contains activities. When the request is released,
task no released first then request no is released.

48. What is the client specific data?

ANS .Client specific data means when data is maintained within same client suppose client 500, and under 500 client you
create company structure and under this company structure you create customer master data and material master data and
under this company structure all business transactions is happened .Thus, all business transactions which is happened in the
same 500(client) that is called client specific data.

49. What is ABAP debugging?

ANS. Debugging is a process to understand program behavior in runtime. SAP has a inbuilt debugger which is part of the
ABAP workbench.

50. What is the difference between discount and rebate?

ANS. Discount is given on individual purchase whatever customer purchase suppose customer want to purchase 2 two soft
drink bottle each 2 ltr and after purchase customer will get discount on two bottle purchase .On the hand ,Rebate is given
total volume of a sales in particular customer
on yearly or monthly and retrospectively.
51. What are the routines?

ANS. Routines are formula which is hard corded and prepared by ABAPer.As a functional consultant, you can only do
system modification.But, you cannot create routines.

52. What is meant by Variant Configuration?

Ans: Attribute of materials are not predefined and there are many possible variations, you can define them in the sales
order in the context of a variant. You can define in a sales order on the context of a variation configure.

53. What is the relation ship between sales organization and Company code?

ANS: Sales organization is highest organization unit in sales and distribution and company code is highest organization
element in FI.

54. What are the influencing factors for account determination?

ANS: Account determination is depended on Application +Condition type+ Chart of Account + Sales organization+Account
assignment group of payer master +Account assignment group of material +Account key .

55. What are dependencies in variant configuration?

ANS. Configurable Material, Configurable profile, Class, and value that is depended on variant configuration.

56. How is alternate condition base value?

ANS. Alternate condition base value is used in pricing procedure to calculate a value on the basis of base value of a
material such as you want to give 10 % discount to material on the basis of material base value .For this reason, you have
to assign certain routine that is called alternate condition base value.

57. What is the use of POD?

ANS. POD means proof of delivery. When delivery is being done, at the time of receiving, ship-to-party verifies whether any
discrepancy is there, if discrepancy is there, delivery is not confirmed. If the quantity is ok, ship-to-party transfer proof of
delivery through IDOC to R/3 system.
Proof of delivery is the confirmation sent by the Ship to party upon the reciept of goods. Once you configure the POD
in your system, means it wont let you
create the billing unless you have confirmatiion of POD.

To configure the POD :

--------------Step 1--------------------------------------------------------------

check the POD in Customer Master - sales area - Shipping data tab.
- Enter the time limit to recieve the POD from Ship to party in "Time Frame" as No: of days which is permited in
numbers and as I have entered as 3 days.
If the Ship to party fails to send the POD within the stipulated time, which is mentioned in the time frame, the system
will automatically create the Billing.

---------------Step 2------------------------------------------------------------

- Select the relavent Item category and assign "X" (Relavent for POD) you can use the following path to assign as
mentioned.

(SPRO - Logistic Execution - Delivery - Proof of Deliveries - set POD-Relevance depending on delivery item
category)

- If you intend to create the new reasons for the Quantity difference then you can do Under the previous step in
customizing.
 (Define Reasons for Quantity Differences)

--------------step 3------------------------------------------------------------------------

- Now create the Sales Order, delivery, PGI, and lastly when you will attempt to create the billing you would see the
error message. In the log if you
observe the POD is not confirmed. Which means is you need to get the POD .

- To get the POD there are 2 scenarios.

Scenario 1-

If the quantity has difference " it could be overdelivery or Underdelivery" for this:

A) Use the Transaction code VLPOD then enter the delivery document number: , enter the reasons for the qty
variation (Positive or Negative) and finally
Enter the qty of variation under the "Qty difference sales Unit" which changes the POD status as "B"(Difference
Reported). and save the document.
B) After the above step now you need to do VLPODQ transaction code for the final confirmation of POD- Automatic
Confirmation.
In VLPODQ selection criteria, you need to input your delivery document no:, and make sure to select "radio button
of "Verified with difference"
and tick mark the "Display selected documents" under the worklist tab & Execute.

You can also do VLPODQ directly if there is no discripencies in the item which customers has recieved.

c) Select the line item and hit the "CONFIRM" button .

If you want to make sure you have the quantity difference recorded properly, for that go to VL02n, select the line
item go to "Processing tab" and look in the
"POD Difference button" which will show up the delivery quantity and POD quantity.

D) Now you are ready for the billing... Go to VF01 and do the billing.
 Scenario 2-

If there is no difference in quantity in suc case follow the step B (select the radio button "Not yet processed" instead
of "verify with difference".),
Step C, and D from above.

58. When will you combine deliveries into one invoice?

ANS. When delivery due date, destination country, bill-to-party is same ,deliveries are combined into one
invoice

Pricing Procedure

1. Step:

 Number that determines the sequence of the conditions with in a procedure.

 It indicates the position of the condition type in pricing procedure.
 Ex.: 10, 15 etc.
 2. Counter:

 System uses the counter to count the steps and also it can be used to count mini steps of same condition types. So
that number of steps can be reduced in the pricing procedure and hence enhancing the system performance.
 Access number of the conditions with in a step in the pricing procedure.
 During automatic pricing, the system takes into account the sequence specified by the counter.

3. Condition Type:

 It represents pricing element in pricing procedure as a base price, discount, freight and tax.
 The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate
between different kinds of discount; in output determination, between different output types such as order
confirmation or delivery note; in batch determination, between different strategy types.
 Ex.: PR00 - Price, K004 - Material Discount, K005 - Customer/Material Discount, K007 - Customer Discount.

4. Description:

 System copies description of condition type from its description (V/06).

5. From and 6. To:

1. From: This can be used as a base to the condition type for calculating further value.

2. From and To: The range between the steps from and to can be used to specify the range between same
condition types. So that depending upon the condition type, the system deducts or adds the total value of those
condition types from specific common source.

7. Manual:

 This indicator specifies whether the specific condition type can be determined manually during sales order
processing.
 If we check the box then the entry is going to be manual, if we uncheck it, it is going to be automatic.
 For Base Price and Taxes, the entry should be automatic.
 For Discounts and Freights, The entry should be manual.
 If we check the box, in VA01 when we go to conditions at the header/item level, the condition type will not be
listed. If we require we will have to manually enter it.
 If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition type will be
listed.

8. Mandatory:

 This indicator specifies that particular condition type is mandatory in the pricing procedure.
 If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the
condition type and try to save the document then system will not allow us to do it and throws an error.
 If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the
condition type and try to save the document then system will allow us to save it, without giving any error.
 Mandatory check box should be checked in condition types which are compulsorily required in pricing procedure.
Ex.: PR00, MWST.
 If the condition type is checked with mandatory option, then value should be maintained for that condition type,
otherwise the system will not allow the user to process the document.

9. Statistical:

 This indicator if it is activated will not allow the value of the condition type to be taken into net value calculation.
 It is used only for information purposes only.
 This indicator causes a surcharge or discount to be set in the document statistically (that is, without altering the
value).
 This is commonly used for condition types
 SKTO - Cash Discount
 VPRS - Cost (Moving average price/Standard Price).

10. Print:

 The value of this field specifies whether line item can be printed or not in the sales document and at what level it is
to be printed.

11. Subtotal:

 The value of this field determines where the values of subtotals to be captured i.e. in which table and which field.
 Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost
of a material) are stored.
 If the same fields are used to store different condition amounts, the system totals the individual amounts.
 These condition amounts or subtotals are used as a starting point for further calculations. You may, for example,
want a subtotal of all the discounts included in the pricing of a sales order.

12. Requirement:

 It is a routine that is written by an ABAP consultant according to the business requirement.

 By defining Requirement in condition technique we can restrict the access of condition type.
 To understand the concept, we will take the example of the Rebates. Rebates are to be included during the billing
document processing and not in the sales document processing. As rebates are given on the delivered quantity and
not on the ordered quantity (in case of cut-off period for rebates).
 For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the value 24 which
is "Only in Billing Document".
 This Requirement will ensure that these condition types will appear only during the billing document processing.
 If new Requirements are to be defined we follow the procedure given below.
 Go to T.Code: VOFM. - Maintain Requirements & Formulas
 Click on the "Requirements" in the top menu and then click on "pricing".
 We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client
requests.
 And we assign the application type like V - Sales/Distribution etc.
 14. AltCty - Condition formula for alternative calculation type:

 It is again a Routine that is written by ABAP Consultant.

 It is an alternative formula for the condition type that can be used instead of standard formulas.
 For example, let us take the Profit Margin which can be both + / - , so here this routine will help us in generating
the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in
the V/06.
 Ex.: 950 0 Profit Margin 11.
 So we assign 11 - Profit Margin.
 If new routines are to be defined we follow the procedure given below.
 Go to T.Code: VOFM. - Maintain Requirements & Formulas.
 Click on the "Formulas" and then on the "Condition Values".
 We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
 And we assign the application type.

15. AltCBV - Alternative formula for condition base value:

 Formula for determining the condition basis as an alternative to the standard.

 It is again a Routine that is written by ABAP Consultant.
 It is used as a basis to calculate value of the condition type instead of using it from the "FROM" column.
 Ex.: Freight - KF00.
 Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no entry of weight
from which the value can be referred like we do for discounts using base price. We have to get the value from the
Material master.
 In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.
 During pricing, the system will consider the value that is mentioned in this column and determine the freight based
on this value.
 Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this column then the
Freight condition KF00 will be calculated using the weight as 100 kgs.

16. AcyKy - Account Key/ Accrls - Accruals:

 The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate Accruals etc. are
going to be posted in the respective G/L accounts in Fi Module.
 In order to do this we assign account keys/ accruals to the different condition types based on their classification.
The classification shown below.
 ERB Rebate sales deduct.
 ERF Freight revenue
 ERL Revenue
 ERS Sales deductions
 ERU Rebate accruals
 For Ex.,
 For all Price condition types like PR00 etc. we assign ERL - Revenue.
 For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
 For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
 For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales deductions and for
Accruals ERU - Rebate Accruals.
 This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts respective
values in respective G/L accounts in Fi-Co Module.
 This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi Consultants assign
the respective G/L accounts in T.Code:VKOA.

Routines

Routines are short sub-programs that carry out various checks during document processing. In theSD module, you can create and process
routines for copying requirements, data transfer,requirements and formulas using transaction VOFM. Besides the routines delivered to you
with thesystem, you can create your own individual routines.Transaction VOFM allows you to follow a standardized procedure for creating
routines. The nameranges are predefined for routines delivered to you with the system and for routines created by thecustomer. This name
convention guarantees that your own routines are not overwritten during aRelease upgrade.
Copying requirements and data transfer
The routines for coying requirements and data transfer are defined for the document types salesorders, deliveries, billing documents, sales
activities, as well as for texts. You specify copyingrequirements and the data transfers when defining the document flow for each document
type. Youenter the routines for texts in the
access sequences
for texts.o Copying requirements determine which data is copied during the copying of documents. A copyingrequirement could define, for
example, that the same customer must appear in the document header when you copy an inquiry to a quotation.o Routines for data
transfer make a detailed control of the copying of fields possible. A data transfer could define, for example, that particular item fields can only
be copied in combination with other particular fields and can only be copied into contracts or credit and debit memos.
Requirements and formulas
Routines for requirements and formulas are used for functions using the
condition technique
. Youenter these routines in the
pricing procedure
or the
condition types
. Requirements are also usedfor statistics.o A requirement in pricing can determine that an access is dependent on a particular precondition.
Itcan carry out a check of the document currency, for example, and, depending on whether it is aforeign or the local currency, allow or deny
the access.o Formulas are used in pricing to define various factors for pricing. Formulas are defined for
scalebase value, condition base value
, condition amount, group key, and rounding rules. The formula for a rounding rule could define, for example, that all calculated amounts are
rounded to two placesbehind the decimal point during a price change of the condition record. The formula for a conditionbase value could
define, that the header discount is distributed among the order items according tovolume an not value of the item, as is the case in the
standard SAP R/3 System.

IDOC (Intermediate Document):

ABSTRACT
Today IDocs are used in most SAP applications for transfer of message(information) from SAP system to other
systems and vice versa. Though lot of documentation is available on IDocs it is difficult for a functional consultant
to understand such documents due to their technical nature. While a functional consultant is not expected to
know the IDoc concepts in its entirety, an effort has been made to capture the minimum necessary information
that one needs to be aware of in order to handle project/support issues on IDocs.

OVERVIEW
IDoc is an SAP object that carries data of a business transaction from one system to another in the form of
electronic message. IDoc is an acronym forIntermediate Document. The purpose of an IDoc is to transfer data or
information
from SAP to other systems and vice versa. The transfer from SAP to non-SAP system is done via EDI (Electronic
Data Interchange) subsystems whereas for transfer between two SAP systems, ALE is used.

IDoc can be triggered in SAP system or in EDI subsystem. This depends on the direction in which IDoc is sent and is
called as Inbound IDoc and Outbound IDoc accordingly. In case of outbound flow, IDoc is triggered in SAP through
document message control which is then sent to EDI subsystem. EDI converts the data from IDoc into XML or
equivalent format and then sends the data to partner system through Internet.
For inbound flow, EDI converts partner data and IDoc is created in SAP. After successful processing of this IDoc,
Application Document is posted in SAP.
EDI STANDARDS AND IDOC
“EDI is electronic exchange of business document between the computer systems of business partners, using a
standard format over a communication network”. EDI stands for Electronic Data Interchange.

For transmission of information electronically, two widely used standards are ANSI ASC X12 and EDIFACT. ANSI ASC
X12 is a committee formed by representatives of major organizations, government bodies and EDI software
companies which defines standards and guidelines for information interchange over EDI. UN/EDIFACT stands for
United Nations EDI for Administration, commerce and Transport and was formed in 1985 using ANSI X12 and
UNTDI (United Nations Trade Data interchange) as base standards. ANSI X12 describes business document as
transactions and each transaction is represented by three digit number e.g. 850 – Purchase Order, 855 - Purchase
Order Acknowledgement. EDIFACT describes business document as messages, represented by standard names e.g.
ORDERS for purchase order.

IDOC TERMINOLOGIES
IDOC (BASIC) TYPE
IDoc Types are based on the EDI standards and mostly on EDIFACT standards.
Basic Types (or IDoc Type) defines the structure of an IDoc. Each basic type describes standard IDoc segments,
format of data fields and their size. Basic Type also defines number of segments and fields in an IDoc. All the fields
that are necessary for transmission of message for a particular business transaction are mapped in different
segments. It also defines the structure and relationship of IDoc segments along with mandatory and optional
segments.
IDOC EXTENSION
Basic type contains all the standard fields that are necessary for carrying out a business transaction. However, if
any additional values are to be sent to the partner then we can make use of the IDoc Extension feature. IDoc
extension is extension of basic type and contains additional custom IDoc segments and fields that are not available
in standard basic type.

IDOC SEGMENTS
IDoc segments contain the actual data that is sent to or received from a partner. These segments contain the
actual values that are sent as part of IDoc transmission.

PARENT AND CHILD SEGMENTS

IDoc segment is termed as Parent segment if it contains its own segments. The dependent segments are called as
child segments.
INBOUND/OUTBOUND IDOCS
IDocs sent outside the system are termed as Outbound IDocs and the ones that are received into the system, are
called as Inbound IDocs.

IDOC DIRECTION
This signifies the direction is which information is sent and is similar to terminology used in mails. If information is
sent outside the system then the direction is outbox when it is received into the system then direction is inbox. In
SAP Outbox direction is represent by “1” i.e. outbox and Inbox direction is represented by “2”.

PARTNER
Partner is the Business Partner with which the exchange of information is to take place using IDoc. It can be a
vendor or customer or any other system. Depending on the direction of information in which the information is
sent it plays a role of either a “sending partner” or a “receiving partner”.
PARTNER TYPE
Partner type/role is used to identify partners within the sap systems. Partner type is KU for customer, LI for vendor
and LS for Logical System.

MESSAGE TYPE
IDoc processing involves transmission or receipt of document in the form of a message, each of which represents a
document in SAP. These documents can be Order, Shipment Confirmation, Advance Shipping Notification, Goods
Receipt, or Invoice. Message type is associated with Basic IDoc Type (Basic Type) and defines the kind of data or
document that is exchanged with the partner.

PROCESS CODE
The process code contains the details of the Function Module that are used for IDoc processing. Message Type can
be linked to the Process code.

PORT
IDoc Port contains the information about the way data is sent between the source or target system. The type of
port defines the information contained within the port. For port type “Internet” Port will contain IP address of the
target system. For port type “file”, directory or file name information is maintained. “tRFC” port contains
information about the RFC destination of the target system. For IDoc transmission using ALE “tRFC” ports are used.

PARTNER PROFILE MAINTENANCE

PARTNER PROFILE (WE20)
Partner profile must be maintained for all the business partners to whom we want to send or receive the IDocs.
The TCODE for maintaining the partner profile is WE20.

Double clicking on the Partner will show the following screen:

Partner profile contains parameters for Inbound and Outbound processing of IDocs. For each message type we can
maintain, inbound/outbound options, message control, post processing options and contact information within
Inbound and outbound parameters.
OUTBOUND OPTIONS (OUTBOUND PARAMETERS)
This involves sender/receiver port, Output mode and relation to IDoc type i.e. Basic Type and extension.

MESSAGE CONTROL (OUTBOUND PARAMETERS)

This contains application for which IDoc will be created e.g. EF for Purchase order, the message type of the
application that will trigger the IDoc and Process Code that will convert SAP document to an IDoc. For example, if
PO is to be sent to the Vendor AXXXXZ, then in the outbound option of the partner AXXXXZ we need to maintain
the message type ZXX1 and link it to the Process Code ME10. So when message type ZXX1 is triggered in the PO
then an IDoc will be created for the partner vendor AXXXXZ.

Process Code is linked to the Function Module in SAP that converts application data into an IDoc. Standard
function modules are provided by SAP for this conversion however these can also be customized as per business
needs.
Change Message Indicator indicates whether the IDoc is sent as a notification of change. For example, Purchase
Order change messages are sent to vendor using EDI standard message type 860.

Separate message type should be triggered in the purchase order for PO change. Additional line with change
message type must be added in the Message control tab with change message indicator on.
INBOUND OPTIONS (INBOUND PARAMETERS)

For inbound options process code is maintained in the Inbound screen only. IDoc processing can be triggered by
background program and triggered immediately.

POST PROCESSING (INBOUND/OUTBOUND PARAMETERS)

In the post processing option we can maintain the workflow details of the users or positions to which an error
notification will be sent if an IDoc processing fails.
TELEPHONY (INBOUND/OUTBOUND PARAMETERS)
We can also maintain the contact details in the telephony option.

EDI STANDARD (OUTBOUND PARAMETERS)

EDI standard screen contains the details of the Standard EDI terminology used for the IDoc transmission.

For example, Message Type 850 is an EDI standard for Purchase Order IDoc and is linked to IDoc Message
Type Orders.

IDOC STRUCTURE AND RECORDS

STRUCTURE
IDoc structure is divided into Control Record, Data Records and Status records.

These records are stored in the transparent tables in SAP. These are EDIDC, EDID4 and EDIDS.
CONTROL RECORD (EDIDC)
It contains information such as IDoc number, direction, IDoc Status, Basic Type, Message Type, Partner
(Sender/Receiver), date and time of creation/update, Interchange File or ISA number,etc.
DATA RECORD (EDID4)
It contains the details of the IDoc segments.
IDoc segment has fields that contain the data necessary for posting the documents.
STATUS RECORDS (EDIDS)
IDoc Status defines the processing status of the IDoc. IDoc statuses are used to track the IDoc and its various
processing states. Status Numbers represents IDoc status. Current status of the IDoc is present in Control record.

Initial Status numbers are 64 for inbound and 03 for outbound. Successful status is 53 for inbound and 16 for
outbound IDocs.

SENDING AND RECEIVING IDOCS

TRIGGERING AN OUTBOUND IDOC
Outbound IDocs can be triggered from the output message types of Purchase Orders, deliveries, Material
Documents, invoices, etc. The following figure shows that once the output ZXX1 of PO XXXXXXX1 is processed an
IDoc “000000XXXXXXXXX1” is added/created.
The relationship between the IDoc and the application document can be found in two ways:
1. Relationship tab of IDoc

2. Relationship tab of Application Document, e.g. PO, SO, Material Document, etc.
The initial status of this IDoc will be 30, which after successful processing will convert into status 16.

A successful outbound IDoc will pass through all the above statuses in reverse order (01-03-18-06-12-16). Each
status represents an IDoc validation step. If an IDoc passes all the validations it would reach status 16. These
different validation steps for outbound IDocs are explained below:

01: IDoc generation successful

30: IDoc is ready to be processed by IDoc Processing job
03: IDoc data is passed to the Port
18: IDoc successfully triggered EDI subsystem
06: IDoc data translated to EDI format
12: IDoc is dispatched successfully to the partner
16: Partner has received the IDoc successfully

IDoc can possibly fail at any of the above steps during validation.

RECEIVING AN INBOUND IDOC

The initial status of an inbound IDoc is 64 and successful status is 53.

Different validation steps for inbound IDocs are explained below:

50: IDoc received successfully in the system
64: IDoc is ready to be processed by IDoc processing job
53: Application document created and saved successfully. The document number can be found by expanding the
status node 53
An inbound IDoc goes through all the above statuses in reverse order (50-64-53).

IDOC PROCESSING
AUTOMATIC/IMMEDIATE PROCESSING
In this case, IDoc are processed immediately as they generated or added in the system. The check “Transfer IDoc
immediately” is selected in Outbound Options and “Trigger Immediately” is selected in Inbound Option. These
checks are generally used when the real time information exchange is necessary between two systems.

MANUAL PROCESSING
IDocs can also be manually processed using the TCODE BD87 in SAP.

PROCESSING VIA BACKGROUND JOB

IDoc processing by background is the most preferred way of processing the IDocs. Following Programs are used
from processing the IDocs using background job:
RBDAPP01 - Inbound IDocs
RSEOUT00 - Outbound IDocs

REPROCESSING IDOCS

On the basis of IDoc statuses different programs can be used for reprocessing of failed IDocs. These are given
below:

TESTING AND EDITING IDOCS

If an IDoc contains error in the data then such IDocs can be edited using TCode WE02 or WE05. When an IDoc is
edited the original IDoc information(backup) is saved in a New IDoc under status 70 (for inbound) / 33 (for
outbound). These IDoc stays in the system for reference only and cannot be processed. The status of the edited
IDoc becomes 69 (inbound) and 32 (outbound). These IDocs can then be processed using BD87 transaction or
batch jobs.

Debugging of IDocs can be done using by copying the IDocs using TCodeWE19. WE19 is a test tool for Idocs
processing. WE19 copies the existing idoc and creates a new IDoc which can then be modified as per testing needs.
The newly generated IDoc can also be processed using BD87.

CONVERTING IDOC STATUS

Report RC1_IDOC_SET_STATUS can be used to change the status of IDoc. Status changes are generally needed to
move an IDoc to status 68 – no further processing
SEARCHING IDOCS IN SAP
TCODE WE02/WE05: GENERAL SEARCH
IDocs can be displayed in system via TCODE WE02 and WE05. If IDoc number is not known then search can be
made on the basis of IDoc Date, Direction, BASIC TYPE, MESSAGE TYPE, and PARTNER NUMBER.Partner number
can be found in the Output Messages of the documents.
IDoc search can also be made on the basis of ISA or Transfer file Reference.

TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

If we are looking for specific information within the IDocs Segments then this can be found using TCODE WE09.
This is useful if you are searching for a particular information in similar kind of IDoc within IDoc segments. For
example, if you want to search a particular Purchase Order number e.g. 100000001 in multiple IDocs which lies in
Segment E1EDK01 of an IDoc under field BELNR. Then the search can be executed in the following manner.

IDOC VALIDATIONS, COMMON IDOC ERRORS AND SOLUTION

Though, the IDoc failure may not be related to any of the above mentioned reasons, the best way to find the IDoc
error is to compare the existing IDoc with the good example. Good example IDoc can be easily searched with any
of the IDoc search methods as described above.

DOCUMENTATION FOR IDOC TYPES

IDoc documentation can be found using TCODE WE60 and can be helpful to obtain information of the IDoc Type or
its particular segment. It also provides information such as mandatory and optional segments, minimum and
maximum number of segments, etc.
GENERAL INFORMATION FOR COMMON IDOC MESSAGE TYPES
The following list gives the Basic Type and Message Type combination for common idocs

Transaction code Function

WE30 Used to create the Basic Idoc type

WE20 For creating partner profile

WE81 To create message type

WE82 Used to associate the message type and the idoc type

WE21 To create the port

SM59 To give the name of the logical destination

WE41 To create Outbound Process Code

WE02 To check the status of IDOC

WE05 To check the status of IDOC

WE42 To create Inbound Process Code

BD51 To define the function module characteristics

ARCHIVING/DELETION OF IDOCS FROM DATABASE

As IDocs grow older they are archived and deleted from the database. Archived IDocs can be viewed using TCODE
SARI in Achieve Explorer using archiving object as IDoc. Following are the few programs that are used for archiving
and deletion of IDocs from database.
Contracts:

Value Contracts: It should be possible to capture in the system the following key parameters of the actual contract:

o Actual number
o Customer
o Validity period
o Target value
item category group VCIT “Value contract item” is maintained

Material group = ‘03’ (Auxiliary materials)

In order to have the flow from Value Contract to Order Type then :

Update configuration of document types ZOR and ZEX to check for existing contracts at the header level and to
propose the relevant one(s) to the user. For this set parameter “Outline agreement messaging” for these
document types as follows:
 Third Party Process:
Item Category – TAS and Item Category Group : BANS

In third-party process the delivery of the goods required by the customer is not done by sales organization where
customer orders. Instead, the request of the goods is forwarded to an external vendor who sends the material
directly to the customer.

Here is what happens in third-party process:

1. Customer orders goods and a sales order is created in a sales organization
2. Purchase requisition is created automatically when sales order is saved.
3. Purchase order is created at the vendor in the MM purchasing application (manually or automatically)
4. If the vendor does the outbound delivery to the customer, the goods receipt can be posted in the system
5. Invoice receipt is created (invoice from vendor)
6. Invoice to customer is created (order based invoice)

SALES ORDER
Third-party process is triggered when the sales order with third-party item is created. Depending on settings done
in customization third-party item categories can be automatically determined by the system (automatic third-party
processing) or they can be changed from standard item to third-party item category in sales order (manual third-
party processing).

Sales order type used for third-party – OR (standard order)

Item category for third-party – TAS
Schedule line category for third-party – CS

Let’s look deeper into the settings in the system done for automatic and standard third-party process:

ITEM CATEGORY TAS:

Create PO Automatic indicator is not marked in TAS. ALES is an item category for third-party processing where this
indicator is marked.

ITEM CATEGORY DETERMINATION

Item category TAS will be determined automatically for standard order (OR) and item category group BANS (third-
party item). Item category group can be found in material master, Sales: Sales org.2 view.

SCHEDULE LINE CATEGORY CS

Data: Order type = NB, Item Category = 5 and Acct.AssgntCat = X is the data for Purchase requisition. If it is filled
like above the purchasing requisition will be created automatically as standard purchasing requisition (NB), with
item category S and acc.assign cat X. The mapping of item category (from 5 to S) can be found in IMG: MM-
>Purchasing->Define External Representation of item categories. The definition of account assignment category
can be found inIMG: MM->Purchasing->Account assignment->Maintain acc.***. categories

SCHEDULE LINE CATEGORY DETERMINATION

THIRD-PARTY PURCHASE REQUISITION

After saving sales order with item category TAS the purchase requisition is automatically created. In order to see
the document go to: Environment -> Status overview and expand data for item, then expand data for purchase
requisition as well:

Double click on the requisition number and you will be taken to the purchase requisition document. The other way
is to go to schedule line where you can find the purchase requisition number.
If third-party item has more than one schedule line with confirmed quantity > 0, then purchase requisition is
created for each schedule line.
It is wise to have the vendor determined in source of supply at this stage of the process (i.e. source list)

MANUAL PURCHASE ORDER

The purchase requisition needs to be converted into purchase order in MM (t-code me21n). The purchase order
document type is NB (standard order), item category S, that must be assigned to account. Thus account
assignment category needs to be given. In this example it is X (automatically taken during conversion from
purchase requisition, as it was defined in item category CS).
The definition of acct assignment category can be found in IMG: MM->Purchasing->Account assignment->Maintain
acc.***. categories:

Note: There is also a third-party account assignment category created in the system and its definition looks as
follows:

The mapping of item categories: IMG: MM->Purchasing->Define External Representation of item categories:
 ou
AUTOMATIC PURCHASE ORDER
As it was written before – the purchase requisition is created automatically when sales order is saved. It is possible
to automatize the next step, the creation of purchase order, as well. The ALE function is used for that purpose.
The indicator for the automatic creation of purchase order is not set for TAS item category. However, there is a
special item category – ALES which can be used instead in third-party process. The indicator for the automatic
creation of purchase order is marked in ALES by default.

Prerequisites for the automatic creation of purchase order are as follows:

 The indicator automatic purchase order needs to be marked in item category definition (item category ALES has it
by default)
 Unique source of supply needs to exist for third-party item
 At least the document type for the purchase order must be assigned for Sales organization in customizing
underEnterprise structure->Definition->SD->Define, copy, delete, check sales organization
 If all above prerequisites are set up correctly, purchase order will be created when sales order is saved. Then, it can
be found in document flow in sales order.

GOODS RECEIPT
Since during third-party processing goods are moved directly from the vendor to the customer, inventory
management is not affected by this event. However, if sales department would like to document and enter
delivery to the customer in the system it is possible depending on settings in customization. If account assignment
category 1 is used in item category definition, goods receipt is not possible, as the goods receipt indicator is not set
for this account assignment cat. If account assignment category X is used, goods receipt is possible.

The goods receipt posting (t-code migo) would have the following effects:
 The warehouse stock is not updated
 The goods receipt is posted directly to consumption and the consumption quantity is updated
 The order value is posted to a GR/IR clearing account for invoice verification purposes
 The goods receipt can be traced in the purchase order history

The goods receipt posting should happen when the vendor reports that outbound delivery was executed or
customer confirms that delivery arrives.
Since no flow of goods occurs in the enterprise, the goods receipt posting results in updates on value basis.

INVOICE RECEIPT
The invoice verification with reference to purchase order needs to be created when invoice from vendor arrives to
enterprise (t-code miro). The value and, if goods receipt was done earlier, the quantity are proposed by the
system. When the incoming invoice is posted following are updated:
 Purchase order history
 G/L accounts
 The vendor account in subledger accounting, as well as the liabilities account (general ledger)

CUSTOMER BILLING DOCUMENT

Once invoice receipt has been entered, the customer can be billed as well (t-code vf01). Since an outbound
delivery doesn’t exist for the third-party the invoicing will be order based. In the item category TAS definition, the
billing relevance indicator is set to F by default. That means: relevant for order-related billing document: status
according to invoice receipt quantity. That is, the system allows invoicing the order only when vendor’s invoice has
been processed in invoice verification.
The customer invoice is created for the quantity specified in the vendor invoice. The setting in the copy control for
the third-party item category from sales document to billing document specifies that the quantity from the invoice
receipt is transferred to the billing document instead of the order quantity (billing quantity indicator in copy
control is F)

Standard Reports of SD

Reports Name Description

VA15N Inquiries List
VA25N Quotations List
SDQ1 Expiring Quotations
SDQ2 Expired Quotations
SDQ3 Completed Quotations
VA05N List of Sales Orders
SDO1 Orders Within Time Period
V.02 Incomplete Orders
VA35N List of Scheduling Agreements
VA45N List of Contracts
SDV1 Expiring Contracts
SDV2 Expired Contracts
SDV3 Completed Contracts
VA14L Sales Documents Blocked for Delivery
V.23 Sales Documents Blocked for Billing
VL06O Outbound Delivery Monitor
VF05N List of Billing Documents
VB(8 List Rebate Agreements
S_ALR_87012218 Credit master sheet
F.31 Credit Management Overview
FCV3 Credit Management Early warning list
MCTA SIS: Customer Analysis
MCTC SIS: Material Analysis
MCTE SIS: Sales organization
MCTK SIS: Shipping point
MCTI SIS: Sales employee
MCTG SIS: Sales office
MC(A SIS: Incoming orders
MC+A SIS: Returns
MC+E SIS: Customer Analysis: Invoiced Sales
MC+I SIS: Customer Analysis: Credit memos
F.35 SIS: Credit master sheet
MC(E SIS: Material Analysis: Incoming orders
MC+M SIS: Material Analysis: Returns
MC+Q SIS: Material Analysis: Invoiced Sales
MC+U SIS: Material Analysis: Credit memos
MC(I SIS: Sales Orgn Analysis: Incoming orders
MC+Y SIS: Sales Orgn Analysis: Returns
MC+2 SIS: Sales Orgn Analysis: Sales
MC+6 SIS: Sales Orgn Analysis: Credit memos
MC(M SIS: Sales Office Analysis: Incoming orders
MC-A SIS: Sales Office Analysis: Returns
MC-E SIS: Sales Office Analysis: Sales
MC-I SIS: Sales Office Analysis: Credit memos
MC(Q SIS: Sales Employee Analysis: Incoming orders
MC-M SIS: Sales Employee Analysis: Returns
MC-Q SIS: Sales Employee Analysis: Sales
MC-U SIS: Sales Employee Analysis: Credit memos
VC/2 Sales Summary (Customer Fact Sheet)
V/LD Pricing Reports
VD59 List Customer Material Info
VB35 Promotion List
VB25 List of Sales Deals
VC05 List of Sales Activities
VB25 List of Sales Deals
VCUST Customer List

Make To Order:
You have to have a material with item category group as 0001- Normal item
checking group for availability check should be - 02 ( individual requirement) in sales -general /plant, because it is
not a normal requirement or regularly made product so you have given 02.

create a standard sales order - OR or whatever is your order type.

for which you would see the item category for the material in SO is TAK. Billing relavence is A and pricing is X.
schedule line will be CP movement type as 601
KE is the requirement type for individuat customer order without consumption

save the order and go for MB1C to initialize the stock which you recieved it once it is made in your plant with the
movement type 561 and specify the special stock E in indicator as because this is specially created for the
customer who ordered.

Check the stock in your storage locatiion using MMBE if the stock has been posted or not after MB1C.

Now do the delivery for the customer using VL01N.

once the goods which you have specially made for the customer the special stock, for which do the billing VF01.

Intercompany Process:
A company arranges direct delivery of the goods to the customer from the stocks of another company belonging to
the same corporate group. To put in simple terms, Company code A orders goods through its sales organization A
from Plant B belonging to Company code B. It is imperative that both Plants A & B should have the material. In
other words, the material is created for both the Plants A & B + their respective storage locations.

Sales Organizations and Plants are uniquely assigned to Company codes. It is not possible to assign either a plant or
a sales organization to more than one company code.

Sales organizations and plants assigned to each other need not belong to the same company code.

In other terms, a plant belonging to Company code A & assigned to Sales Organization A can also be assigned to
Sales Organization B of Company Code B. This enables cross company sales.

PARTIES INVOLVED
1) End Customer 2) Ordering Company code 3) Supplying Company Code.

End customer:
Customer who orders goods from the ordering company code.

Ordering Company Code:

Which orders goods from Plant belonging to Supplying Company code through its sales organization and bills the
end customer.

Supplying Company Code: Supplies goods from its plant to the end customer specified by the ordering company
code and bill the ordering company code.

CONFIGURATION SETTINGS
Assign Delivery Plant of the supplying company code to Sales Org + Distribution channel of the Ordering company
code in the Enterprise Structure.

DEFINE ORDER TYPES FOR INTERCOMPNY BILLING:

Menu path: IMG/ SD/Billing/Intercompany Billing/Define Order Types for Intercompany billing

Assign Organizational units by Plant:

Menu Path: IMG/ SD/Billing/Intercompany Billing/Assign Organizational units by Plant.

Define Internal Customer Number By Sales Organization:

Menu Path: IMG/ SD / Billing/ Intercompany Billing/ Define Internal Customer Number By Sales Organization:

Creating / Showing Ordering Sales Organization as Internal Customer for Supplying Company code:

Transaction Code: XD01

The ordering sales organization is represented as Internal customer of Supplying company code.

We need to create customer master in Account Group – Sold to Party and maintain minimum required financial &
Sales Area data.

This internal customer number has to be assigned to the ordering sales organization. Hence, the system
automatically picks up this Internal customer number whenever there is Intercompany billing.
PRICING:

We need to maintain two pricing procedures RVAA01 & ICAA01. Pricing procedure RVAA01 represents condition
type PR00 & any other discounts or surcharges that are meant for end customer.
We assign Pricing procedure RVAA01 to combination of Sales area (Of Ordering company code) + Customer Pricing
Procedure + Document Pricing Procedure of Sales document type.

This pricing Procedure (RVAA01) is determined both at Sales Order level & Billing processing for the end customer.

We maintain PR00 condition type to represent the ordering company code’s price to the end customer.
Condition records for PR00 are maintained using organizational elements of Ordering company code, end
customer & the Material.
Eg: Sales Org. of Ordering company code + End customer + Material.
We also need to maintain PI01 condition type to represent costs to Ordering company code (in other words
revenue to supplying company code). It is statistical condition type & meant for information purpose only.

Condition records for PI01 are created with the following key combination:
Ordering sales Org + Supplying Plant + Material

Pricing Procedure ICAA01is determined at Intercompany billing processing level.

Pricing Procedure ICAA01 – Pricing Procedure for Inter company billing is assigned to the combination of:
1) Sales Area (of supplying company code) + Document pricing Procedure of Billing document type IV + Customer
Pricing Procedure of the Internal customer.
Pricing Procedure ICAA01 has condition type IV01 that represents revenues for Supplying company code in the
intercompany billing.
PR00 condition type also appears in Intercompany billing document. It is for information purposes only and does
not have bearing on the value of the document.
PI01 represented under pricing procedure RVAA01 is reference condition type for IV01 and the same is defined in
the condition type IV01. Due to this these two condition types represent same value.
The condition type IV01 in intercompany billing document represents revenue to the Supplying Company. But its
corresponding condition type PI01 in the billing document to the end customer is shown as a statistical item meant
for information purposes.
Condition Type VPRS in the intercompany-billing document indicates cost to the supplying company code.
The use of two different condition types in Intercompany billing is necessary to ensure that data is transmitted
correctly to the financial statement (Component CO-PA).

VPRS:

VPRS is the cost of the material which is capturing from the Material Master Accounting Tab. Against
the VPRS condition in the pricing procedre you need to put 4 in the alternate conditionvalue.which is used to
calclate the cost. If you mark the VPRS as the Statistical then it wont be added to the NET PRICE of the sales order.
You can deactivate the VPRS (hide) by nchecking the DETERMINE THE COST in teh item category VOV7. VPRS
condition type is used to calculate the profit margin for that particular line item.It takes into account Moving
average price/Standard price from material master and compares with price in the document for that line item.

ERP SD Revenue Recognition

Purpose

The purpose of this page is to provide an overview about ERP SD Revenue Recognition functionality.
 Overview

In the following sections you will find information about the available documentation, customizing, description
of core business processes and handling of revenue recognition data.

Description

Many companies require that revenues are posted according to a time period. This means that the revenues must
be realized in the posting period in which the service was carried out, and not in the posting period in which the
billing document was set up.

The revenue recognition function in the SAP ERP system helps you to fulfill these requirements and separates the
revenue recognition process from the billing process. The ERP system offers a flexible solution to companies using
various methods of revenue recognition.

Revenue Recognition assessment

If customers want to use the revenue recognition functionality in their productive environment, the
implementation must be subject to a pre go-live assessment to avoid a negative impact on the financial statement.
This assessment is completely free of charge. In other words, the customer will have to ask explicit permission
from SAP in order to use this functionality (detailed information is provided in SAP-notes 768561 and 779366).

Documentation

The latest version of the Revenue Recognition Best Practices document is attached to SAP-note 1172799.

 Necessary Customizing settings

 Supported processes and scenarios
 Limitations and restrictions placed on the solutions offered
 Recommendations for monitoring the revenue recognition process
 A guide for implementation

In addition to the 'Best Practice' document, an eLearning course for the SAP ERP SD Revenue Recognition function
is available with the following title:

 SCM653: Sales and Distribution Revenue Recognition

 SCM654: Advanced Revenue Recognition

These eLearning courses can be found under www.sap.com/education.

 Available methods

 Revenue recognition at the point of billing (standard method)

 Time-related revenue recognition (the revenues are realized between specific set dates)
 Service-related revenue recognition (the revenues are realized on the basis of a specific event, e.g. the goods issue
for a delivery)
 Credit/Debit memo request with reference to preceding document
 Service based revenue recognition, billing related (only for IS-M solution)

Customizing

For the setup of revenue recognition processes you have to customize:

 FI accounts and their settings

 SD item categories and their settings
 Revenue recognition category on item category level
 Account determination

The following accounts are needed for the representation of the revenue recognition process:

 Revenue account (recognized revenues)

 Receivables account (customer account)
 Revenues to be deferred (deferred revenue account or D/R account)
 Unbilled receivables (unbilled receivables account or U/R account)

Revenue recognition category on item category level

Transaction: OVEP

Set Revenue Recognition category for Item Categories:

Possible entries for the field “Rev. recognition” are:

 Account determination

Transaction: VKOA

Assign G/L accounts for revenues and deferred revenues:

 G/L account no. (SAKN1): revenue account

 Provision acc. (SAKN2): D/R account

Transaction: OVUR

Account for unbilled receivables (U/R account) has to be maintained depending on the reconciliation account and
the associated chart of accounts:

 NonBldRec.: U /R account

Description of Core Businesss Processes

Process 1: Standard Revenue Recognition at time of billing
Process 2: Time based with VF44 as first
Process 3: Time based with invoice as first
Process 4: Service based with VF44 as first
Process 8: Time based & billing related (‘D’)
Process 9 – time based / service based with VF44 as first
Process 10 – time based / service based with VF44 as first
 For a detailed explanation of all available processes, please refer to Revenue Recognition Best Practices document
attached to SAP-note 1172799.

Handling of revenue recognition data

Revenue realization processes

 Revenue recognition run (transaction VF44). With transaction VF44 the revenues are posted and financial
accounting documents are created.
 The posted revenues can be cancelled by using transaction VF46, e.g. if revenues have been realized in error.
 In certain cases - for example, when you change condition values - revenue lines of the related sales document
have to be updated. Transaction VF42 can be used to update revenue recognition data.
 Transaction VF45 shows deferred revenues, unbilled receivables, billed and realized amounts on the level of a sales
document item.
 The report of VF47 shows inconsistencies between the revenue recognition tables VBREVK, VBREVE and VBREVR
and the appropriate sales documents. Only development support may run it in update mode.

Credit/Debit Memo Processing

What is Debit note and Credit note? What is the purpose? How we create?

 1. A transaction that reduces Amounts Receivable from a customer is a credit memo. For eg. The
customer could return damaged goods. A debit memo is a transaction that reduces Amounts Payable to a
vendor because; you send damaged goods back to your vendor.

2. Credit memo request is a sales document used in complaints processing to request a credit memo for a
customer. If the price calculated for the customer is too high, for example, because the wrong scale prices
were used or a discount was forgotten, you can create a credit memo request. The credit memo request is
blocked for further processing so that it can be checked. If the request is approved, you can remove the
block. The system uses the credit memo request to create a credit memo.

You can use credit memos in Sales and Distribution (SD) for assigning credit memo requests to the open
invoices and in Financial Accounting (FI) for assigning credit memos and payments to the open invoices
and carry out clearing with them. If you use both Financial Accounting (FI) and Sales and Distribution
(SD), there is a 1:1 relationship between the credit memo request and the credit memo item posted in
Financial Accounting (FI). As soon as you bill the credit memo request together with other sales orders, or
distribute the items of one credit memo request to several billing documents, the assignment is no longer
valid and the system will not process it.
 For credit memos, credit memo requests, and payments, you have the following assignment options:
- Assignment to a single invoice
- Assignment of a partial amount to an invoice
- Assignment to several invoices

When you post credit memos, the payment programme processes them automatically. If the credit
memo is specifically related to a particular open invoice item, the payment program automatically
attempts to offset the credit memo against the open item. If it is not possible to completely offset the
credit memo against an invoice, you can post a debit memo to the vendor, who is to reimburse the
amount. Then you can apply a multilevel dunning program.

3. Debit memo request is a sales document used in complaints processing to request a debit memo for a
customer. If the prices calculated for the customer were too low, for example, calculated with the wrong
scaled prices, you can create a debit memo request. The debit memo request can be blocked so that it can
be checked. When it has been approved, you can remove the block. It is like a standard order. The system
uses the debit memo request to create a debit memo.

4. As mentioned above, creating a credit or debit memo request enables you to create credit or debit
memos based on a complaint. For this first create a sales document with the order type for a credit or
debit memo request. You can create the debit or credit memo requests in the following ways:
- Without reference to an order
- With reference to an existing order
Here you enter which order the complaint refers to.
- With reference to an invoice
Here you enter which invoice the complaint refers to.
 In all cases, you specify the value or quantity that should be in the credit or debit memo

5. You can block the credit or debit memo request from being billed in Customizing. Go to Sales -> Sales
Documents -> Sales document header -> Define sales document type and select the billing block field in
the billing section. This request can later be reviewed along with similar ones, - if necessary, by another
department. The request for a credit or debit memo can then be approved or rejected.

RETURN SALES:

Return material From customer

You need to receipt the rejected goods through SD Module (VA01 - Sales Order type RE).

The steps are as follows :

1. Create a return request. (Using Sales Order in SD)

2. Create outbound delivery according to return request.

3. If the setting is correct in the outbound delivery screen SAP will automatically switch post goods issue button into
post goods receipt. The setting is in sales order item category and delivery type.

4. In the standard system the movement type used is 651.

5. After post goods issues receipt is done using outbound delivery, the quantity is placed in blocked stock without
value updating.

6. You will then decide if the return quantity are indeed bad stock or not.

7. Transfer Posting from block stock to unrestricted stock (mvt type 453), this will have accounting effect (Debit
Inventory, Credit COGS)

8. Goods Issue to scrap account how to create new titles which can be used in creating the "address" view on the
Vendor master.{T-Code: XK01}
In config go to Basis Components --> basis services --> Address Management --> Maintain title texts
 Like (0

RETURNS PROCESS IN SAP

Sales Returns: Sales Returns is a process where in a customer sends the material back to the supplier, generally when
the material is found to be defective.
Returns Document: In SAP a Sales Returns Document is created either with respect to Invoice or the actual Sales Order.
Transaction Flow: Invoice / Sales Order ® Returns Order ® Returns Delivery ® Post Goods Receipt [PGR].
DOCUMENT TYPE SETTINGS - IMG
Path: IMG ® SD ® Sales ® Sales Documents ® Sales Document Header ® Define Sales Document Type
T-Code: VOV8
Standard Document Type: RE -Returns Sales Document
Table: TVAK : Document Type - AUART [Field]
RE document Settings
SD Document Category : H - Returns
Transaction Group : 0 - Order
Screen Sequence Group : RE - Returns
Incompletion Procedure : 14 - Credit Memo
Delivery Type : LR - Returns Delivery
Delivery Related Billing Type : RE - Credit for Returns
Order Related Billing Type: RE - Credit for Returns
Billing Block : 08 - Check Credit Memo
Propose Delivery Date : Activated
ITEM CATEGORY - IMG
Path: IMG ® SD ® Sales ® Sales Documents ® Sales Document Item ® Define Item Categories
Transaction Code: VOV7
Standard Item Category: REN - Returns Item Category
Table : TVAP : Item Category - PSTYV [Field]
REN item category settings:

Pricing : X - Pricing StandardBilling : B - Order related Billing, status according to order quantity.
Returns : Activated
Credit : De-activated
Schedule Lines : Activated
Wt/Vol : Activated
Determine Cost : Activated
Business Item : De-activated
SCHEDULE LINE CATEGORY - IMG
Path : IMG ® SD ® Sales ® Sales Documents ® Schedule Lines ® Define Schedule Line Categories
T-Code : VOV6
Standard Schedule Line Category : DN - Returns Item Category
Table : TVEP : Schedule Line Category - ETTYP [Field]
DN Settings
Movement Type : 651 - Goods Return Delivery. This will enable the stock value and quantity to go up in Inventory
Accounting.
Item Rel. for Delivery : Activated

Incomp. Procedure : 30 - Delivery Relevant Schedule Line.

Incase of Return Sales Order:

T.Code for copy control: VTAF
Source Document: F2
Target Document: RE
Item category REN

Considering the above settings are done:

Create return sales order RE (with Reference to Billing Document) and the data will be copied as it is in Return Sales Order
- RE. For Eg: here you require to change to quantity from 10 to 2, as you want to take back into Inventory of only 2.

Incase of Return Delivery:

T.Code for copy control: VTLA
Source Document: RE
Target Document: LR
Item category REN

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

Considering the above settings are done:

Create Return Delivery through T.Code VL01N and do PGR (Post Goods Receipt). This will add the stock to blocked stock.
This will take care of Inventory.

In the case of India for capturing credit for Excise, use T.Code: J1IH --> other Adjustment and based on the credit to be
taken, make the necessary entry.

Incase of Credit Memo:

T.Code for copy control: VTFA
Source Document: RE
Target Document: Credit Memo
Item category G2N (Check in System)

First in VA02, remove the Billing Block in Return Sales Order - RE and save the document. Now in T.Code: VF01, enter
Return Sales Order Number and select the appropriate Billing Type (Credit Memo) and Enter and Save. This will create
Credit Memo.

What is a Return?

If a customer is not satisfied with the product or the deliverable , Businesses need to create a return, based on
customer return request.

What is Free of Charge Delivery ?

In this case , customer is not charged for shipping. This order type is generally used for sending free sample to
customers.

What is Subsequent Delivery?

When a customer receives lesser no.of goods than that ordered ,or if the goods have been damaged in the
shipment,businesses provide free-of-charge subsequent delivery of goods.

REBATE

Rebates: Rebate agreement is a special agreement granted to the customer on

a specific volume of sales over a specific period of time.

Configuration Path:

IMG>SD>Billing>Rebate Processing>Rebate Agreements>Define Agreement

Types>
Step 1: Define Agreement Type
Select"Define Agreement type " from choose activity,double click on it

Select an Agreement click on copy button and rename it

here I selected standard and renamed “0002-Material Rebate” to “Z002- Material Rebate-AA11”
Step 2: Condition Type Groups

2.1: Click on Define condition Type groups

Click on New Entries
Enter your Copied Condition Type group which you created and Maintain “Blank” for Category of the
condition type group

Step 2.2: Assign Condition Types /tables to Condition Type groups

Click on New Entries
Assign Condition Type “Bo02” and Condition Table “1”to your Condition Type Group”Z002”

Step 2.3: Assign Condition Type groups to rebate agreement types

Click on it, Assign Condition Type group to Agreement Type

Step 3: Condition Technique for Rebate Processing

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

Account Key - ERB

Accruals - ERU

Step 4: Account Determination for Rebates

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

Step 4.1: Define A/C keys

(Standard keys available in SAP)
ERB -Rebate Sales deduction
ERU –Rebate accruals
Step 4.2: Assign Account Keys to our Pricing Procedure
In standard pricing procedure it’s available
Steps 901 to 905
Step 4.3: Maintain Access Sequence
(standard already created like Accounting Determination Procedure)
Step 4.4: Define Account Determination Types
Assign access sequence to Condition type
Step 4.5: Assign G/L Account

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

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

Step 5: Activate Rebate Processing

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

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

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

(Or) T-code: VOFA

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

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

Step5.2: Activate Rebate processing for sales organization

Click on Choose
(Or) Go to Enterprise structure

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

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

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

Choose created one (Ex: Z002)

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

If we click on scales button

Here I maintained for each product 1 rupee
go back

save it.
With this configuration part is completed
Step7: create sales order
T-code: VA01
Specify Organizational details
Press F8(document Complete)
Check item conditions
Save it
Step 8: Create Delivery
T-code: VL01n
Step 9: create Billing document
Check ITEM conditions BO02 will display in conditions tab because we maintained requirement ‘24’ in our pricing
procedure

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

Check agreement status to ‘B’

On the menu bar choose “Rebate Payment”
Here Customer is eligible for 50 Rs rebate accruals amount
If we observe Verification Levels
Will get details of payer customer master total rebate accruals amount

We can settle the rebate amount by manual or automatic

Manually we can select the customer eligible amount

Then we can save it

It will create automatically credit memo request
Here I have chosen 5Rs/- and save it

We will get the message like this bottom of the screen.

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

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

General ledger view

With this Rebate agreement process is completed.

 VBOF:

If you create a new Rebate agreement with a Start Date in the past, (this is called a "Retroactive"
agreement) then transaction VBOF must be run to check for any existing invoice (created since the
start date of the agreement) to which the newly created rebate should have applied.
Before you run VBOF you will get a message like this: "The sales volume for agreement 233 is not
current."
Also, if you make changes to a Rebate Agreement condition records, you can get this same
message, because the previously determined rebate values may now be incorrect. In this case you
must also run VBOF.

When you run this transaction it finds any invoices for the customer that contain the relevant
materials. For each Invoice, a special new pricing is carried out (with a pricing type which ONLY re-
determines rebate conditions). If the program produces a different result with regard to the rebate
conditions, the rebate conditions are updated. If these changes affect accruals, an additional
accounting document is created. These changes WILL NOT affect the NET VALUE of existing billing
documents.

To update the billing documents it is necessary to run report SDBONT06 (transaction VBOF).

 If you set flag "Test", the report is run in Simulation mode.

 If you set flag "Changed agreements", the system only process retroactive rebate agreements (KONP-KSPAE = "X").

Steps made by the report SDBONT06 :

 It reads the table VBOX to retrieve the potential billing documents to be updated.
 It performs PRICING_COMPLETE for the billing documents with CALCULATION_TYPE= "I".
 For every updated billing document:
 Update S060
 Update S136
 Create the accounting document to post the accrual in FI
 If all the billing documents are processed error free, field KONP-KSPAE is cleared in the rebate agreement.


_______________________________________________________________________

The VBOX table is always built when these criteria below are met. This is regardless if a rebate agreement or rebate
condition exists at all.


 Sales Organization (OVB1) Billing type (VOFA) Payer (VD02)

 If all 3 of these settings are flagged as rebate relevant a VBOX entry is written when an invoice of this type is
posted to accounting.

  If you have activated the new rebate procedure in omo1, then SDBONT06 is relevant if you have
 activate the new rebate procedure at the same time the invoice is posted to accounting the
 stucture S136 is also updated with the billing document number and condition record number of the
agreement "if one exists". So SDBONT06 uses VBOX and/or S136 to make sure all invoices within an
agreement validity period are correctly updated in retrospect. Only after this is done could the agreement be
settled, when the retroactive flag is removed form the agreemtn (KONP-KSPAE)

Yes all invoices within the validity period of the agreement will be updated, if required. So if it is a document that was
created before the agreement but is in the validity period it will be updated and you will see a second FI document for
it in VF03 posted by SDBONT06.

2) RV15B002 or transaction VOB3 - Comparison: Bill. Docs and Stats

This is the official documentation:
The report RV15B002 gives you the option of comparing statistics from the rebate
settlements with the values from the billing documents. These values can differ
if you start rebate processing later and want to take into account old billing
documents. The report also allows you to post a rebate correction agreement,
which corrects accruals.

This report is relevant for the old rebate procedure where S136 is NOT activated, it gave you the option to post
accruals for invoices that were created before the agreement which in the old procedure could not be updated.

Using the new rebate procedure you do not need this report SDBONT06 does this for you.

3) RV15B003 or transaction OVG1 - Redetermine subtotal

Sub totals are not held in any table but calculated dynamically according to the customsing of the pricing procedure
steps etc. Whaen a billing document is saved the sub totals are saved into VBRP fields dynamically. In rebate
processing the important sub total value is taken form the step with sub total '7' this value is passed into the VBRP-
BONBA field. So if you had made changes to a productive pricing procedure (which you should never do, always
make a copy and re-assign the new copy) if you run OVG1 it simulates a new pricing and the sub totals ' VBRP-
BONBA ' will be recalculated according to the new configuration in the pricing proccedure.