Standard Pricing Procedure

Following is the link to the Standard Pricing Procedure used in SAP, just check out if you have worked on each condition type and do you understand the formulas attached to each condition type.

http://spreadsheets.google.com/pub?key=phixAHJ6iFNOBn91F1vkFHg .

In addition to this we tend to lack concept and fall apart when we go into detail. Do we really know how pricing works: Let us discuss the following points, each one of them, just to know do we understand the concept used behind pricing in SAP:

1 What is the concept behind condition technique, why do we have a determination concept, what benefit do we get using this concept?

2 Why do we determine pricing be assigning it to the Sales Area , OR type and CPP

3 Can one pricing procedure control the pricing of an entire enterprise , if yes/no why ?

These are just the basic conceptual questions which many of us might be knowing, but whats more important here is how we express , do we know how to express what we know , if u do pl let all of us know through your comments.

Availability Check

Availability Check

AC is determined by checking group and checking rule

Checking Group = A check+ Total Sales + Total Dlv Requirement + Block QtyRq + No Check + Accum
Av Check is defined in MRP3 in Material Master (Discussed below)
Total Sales = Single Records or Total Records per day or Total records per week
Total Dlv Rqs = Single Records or Total Records per day or Total records per week
Block QtyRq = This block is used if several users are able to process the material simultaneously in different transactions without blocking each other.
No Check = This indicator switches off the availability check according to ATP logic for the checking group concerned

Schedule Line and Requirement Type is determined by Item category and MRP Type

Following are the relevant fields required from Material Master to run Availability Check.

MRP1

MRP Type –PD

VB - We have to define, re-order point, safety stock etc. In manual reorder point, you must define the reorder point (and eventually the safety stock) according to your criteria. For automatic, these values are estimated by SAP as a function of the forecast (coming from historical data), so the base-quantities for the calculation of the reorder are not fixed but dynamic.

Lot Size – 10

MRP 3

Strategy Group-

10 – Make to Stock
20 – Make to Order
70 – Planning at Assembly Level
30 – Production only with Sales order (Demand Management entry ignored during MRP run)

Availability Check

1 Daily Requirement
2 Individual Requirement
3 Rep- Lead Time
4 Current Stock
KP No Check

Sales/General Plant

A/Check Availability check field (on the MRP screen and the Sales: General/Plant screen) so that you can perform an availability check with replenishment lead times (01 in the standard system).Item category group (for example, NORM) on the Sales organization screen

Accounting Entries generated during Sales cycle

a) At the time of delivery of goods (PGI)
Cost of goods sold account Dr
Inventory account Cr
(This entry is passed by the cost of the item delivered)

b) During generation of Invoice
Customer / Debtors account Dr
Sales/Revenue account Cr
Taxes Cr
(This entry is passed by the selling price)

c) During collection of Payment
Bank account Dr
Discount Dr
Customer/ Debtors account Cr

(This entry is passed by the amount collected and discount given to customer)
If we are using the clearing system then istead of bank account, clearing account will be debited.

Thanks Rajesh for letting us know the absolute accounting entries

Deletion of Sales Documents

Question
Is it possible to delete the sales orders, if no subsequent document is created. I have tried it, but unable to delete it. Again for the delivery document, if there is no subsequent document, then can we delete the delivery document ?

Hi Bala,
You can no doubt delete the sales order using transaction VA02, but there should not be any subsequent document is created against it. Please let me know the error message you are still getting unable to delete so.

Deletion /cancellation can only happen even if the subsequent documents are NOT created. As sudhir might have rightly said Sales Order with subsequent documents cannot be deleted. After cancelling the invoice and deleting the delivery document, we can set the reason for rejection at the Sales Order Header Level.

Steps:

1. Cancel the invoice through T code VF11
2. Reverse the Goods Issue using VL09, turn the pick quantity ‘zero’ in the delivery document
3. Delete the delivery document using VL02n.
4. Finally set the reason for rejection at the Sales Order Header Level. (So Bala, just check the SO you want to delete ever had any subsequent document? )

Note: An Invoice cannot be deleted but canceled. It can only be canceled with (VF11) only if the relevant accounting document is not generated. Generation of accounting document means the value is posted into accounts and G/L accounts are hit.
SAP FI department needs to reverse the accounting doc on a real-time scenario. Only after the accounting doc is reversed invoice can be canceled. Tax documents generated through the Invoice (Tax is maintained on a separate account) also need to be reversed but this is a part of FI so an SD consultant just needs to request the FICO guy to do the reversal.
Let me know through your valuable comment/s if the question is still left unanswered. Thanks Sudhir for your inputs.

SAP SD demand graph in UK

The chart provides the 3 month moving total of permanent IT jobs ads citing SAP SD Consultant across the UK as a proportion of the total demand within the Job Titles category.

Credit/Debit Memo Request

Credit Memo Request

Definition: A credit memo request is a sales document used in complaints processing to request credit for a customer.
Use: If the price calculated for the customer was too high (for example, with the wrong scaled prices or because a discount was forgotten), you can create a credit memo request. The credit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block.
The system uses the credit memo request to create a credit memo.
Structure: A credit memo request is another type of sales document like a standard order. For more information on sales documents, see Working with Sales Documents.
A credit memo request starts the billing process.

Debit Memo Request

Definition: A debit memo request is a sales document used in complaints processing to request debit for a customer.
Use: You can create a debit memo request if the prices calculated for the customer were too low (for example, if the wrong scale prices were calculated). The debit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block.
The system uses the debit memo request to create a debit memo.
Structure: A debit memo request is another type of sales document like a standard order. For more information on sales documents, see Working With Documents.
Integration: A debit memo request starts the billing process.
Creating Credit or Debit Memo Requests
Purpose: Creating a credit or debit memo request enables you to create credit or debit memos based on a complaint.

Process Flow:

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.
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.
The following graphic shows the document flow for creating a credit memo or debit memo request. The broken line means that the request does not necessarily have to refer to a preceding document.

Result: Once the credit or debit memo request has been approved, you can create a credit or debit memo.
Creating Credit and Debit Memo Requests
Prerequisites: You can enter a credit or debit memo request in one of the following ways:
Without reference to a preceding document
With reference to a preceding document, such as:
Sales orders
Contracts
Contract release orders

Billing documents
CR for credit memo requests
DR for debit memo request
The following entries are important for creating a request:
Customer number of the business partner who requests a credit memo or to whom a debit memo is to be forwarded
Order reason (why the request is necessary)
Material and the quantity in the request
If the credit memo request refers only to part of the billed or ordered quantity, you can adjust the target quantity in the credit memo request accordingly. If you enter another credit memo request with reference to the billing document or the underlying sales order, the system informs you of the quantity which has already been credited.

Result: After you have released a credit or memo debit request, you can create a credit or debit memo.

Partner Determination

Question:

On creating a customer in ship to party account group, we have shipping and billing partner function tab pages, if my client wants to shift all important fields in billing like payment terms, incoterms, and tax classification into shipping tab page , and if he wants only shipping partner function how to customize?

Answer

Hi Safeer,

The account group as you already know can be configured based on different tabs for e.g. you can hide, make a field mandatory under a tab, but standard SAP would not allow to shift the fields from one tab to another, if at all it is required we have to make use of user exits.

Regarding, having only the shipping partner function we can set in Partner Determination, do not assign Partner Functions viz. Sold to Party, BP to your partner procedure and further to the shipping account group.

Using this you can have only one Partner(Ship to Party) in the customer master.

For any further question on this let me know by posting comment/s

Questions July'07

Hey Guyz n gals,
Please post the questions under this link for the month of July in the form of comments. My aim here is to answer a question in a single response via separate topic at the left of the blog, covering all the aspects of the question asked.

e.g. Under 'Delivery Group' title my reply was via comments to the question asked.

Thanks for posting questions.

Payment Terms

Question:

We raise invoice to a customer. Now if customer pays with in 21 days he gets 10 % disc and if he pays with in 30 days he gets 5% disc, How do we configure thisscenario?

Answer
In the above scenario, we can choose payment terms as one of the fields in the condition table: Payment terms can be defined as follows:

NT21 Within 21 days Due net (For NT21 the customer would get 10% discount)
NT30 Within 30 days Due net (For NT25 the customer would get 5% discount)

Upon selecting the relevant payment terms system would determine the percentage discount in the document.
------------------------------------------------------------------------------------------------

Now If the scenario is 'unless the customer pays the amount, payment date is not known hence we don't know which payment term to use and which discount to apply' as u mentioned. e.g.

e.g. payment terms => 21 days 10% cash discount; 30 days 5% cash discount

Then we have to use the condition type SKTO , it is a special condition type used strictly for this scenario i.e based on which payment term discount should be applicable. This condition type is not passed to accounting and generally not to COPA either (as you can see no Act keys for this condition type is not maintained in the Pricing Procedure)
The condition category E cash (in V/06) discount tells the system to go get the payment terms and calculate the potential/actual value i.e. 10% within 21 days and 5% within 30 days.

Based on the differing payment terms while payment, Invoice value will not change and would be the same, but SKTO will correct the value and discount is calculated in A/R instead.

The discount is applied on posting of the invoice and an error will be raised if the payment amount does not equal the net - the calculated cash discount. In the above case, if the payment is within 30 days, then system will throw an error if the customer takes 10 % instead of 5%.

Hope I am able to explain: Post your doubt/s via comment/s

Delivery Group (Complete delivery)

Question
Complete delivery: e.g SO has two lines, for first item 'ABC' delivery date is 01-Jul and for sec item 'DEF' delivery date is 11-Jul. And del job VL04 runs daily. So my req is when VL04 runs on 01-Jul, del should not be created, but it should create a complete delivery on 11-Jul.

Hi Deepak,

In the above question we have to use the logic of delivery group under shipping tab in the sales order. The system uses delivery groups to check the availability of items that should be delivered together. The delivery date of the latest schedule line in the delivery group is taken as the general date for the whole group.

So in your case if you give a common delivery goup e.g. '01' to both of your line items system will deliver them together on 11-July. As far as my knowledge goes there is no automatic determination of delivery group, we have to enter the delivery group manually in the sales order. In case you find any alternative solution please do let me know.

Note
If an item has more than one schedule line with a confirmed quantity, then the system deletes all undelivered schedule lines up to the last one. The system automatically carries over the quantities from the deleted schedule lines into the last one. If necessary, the system changes the delivery date of the last schedule line to that of the delivery group.

Storage Location Determination

Referreing to the Question asked by Deepak
Mat 'ABC' is stored in plant 'PLA' in two different storage locations 'STR1' and 'STR2'. On creating a SO which storage location, will it pick and why??

Hi Deepak,
Let me explain you first how the storage location is determined

Storage location is determined at the delivery document by storage location rules viz MALA, RETA or MARE
The most commonly used one is MALA.
One rule is defined against a Delivery type (ref: check in TC : 0VLK - Delivery type LF)
MALA is determined as below:
STORAGE LOCATION = SHIPPING POINT + PLANT + STORAGE CONDITION
RETA = PLANT + SITUATION + STORAGE CONDITION
MARE = MALA then RETA (First MALA will be applicable failing to find this rule, system will trace for RETA)
Check which rule is applied to the delivery type.
So if MALA is used for storage location determination then based on the parameters defined for shipping point, plant and storage condition system will pick the storage location.
We set Storage location determination under Shipping -->Picking-->Determine Picking Location-->Assign Picking Locations
But COPY CONTROL also plays its role in copying the storage location in the delivery document if it is created w.r.t. the SO. (Ref: TC: VTLA under Item data one routine is defined viz. “101”)
Please have look at the below portion of “Routine 101”
IF CVBAP-LGORT NE SPACE. (LGORT = Storage location)
LIPS-LGORT = CVBAP-LGORT.
ENDIF
IF NOT CVBAP-CHARG IS INITIAL.
LIPS-CHARG = CVBAP-CHARG.
ENDIF.
Coming back to your question, above portion of SAP standard routine 101, explains us if in a SO, storage location is blank, storage location will be picked determining the rule e.g. MALA, and if SO has a value for storage location then LIPS-LGORT = CVBAP-LGORT. (LIPS is delivery at item level and VBAP is SO at item level)
* SO = Sales Order

Routine "2" : Requiremnt colum in Pricing Procedure

Hey Deepak...Here's your answer

Requirement: Denoted by numbers and maintained in VOFM, this is a condition required for a particular condition type.
E.g. PR00: req. 2 i.e. item relevant for pricing or not.
* Pricing is turned on in item category configuration

FORM KOBED_002.
SY-SUBRC = 4.
IF KOMP-KPOSN NE 0 (KOMP- Pricing Communication Item KPOSN -Condition item no. in SO)
CHECK: KOMP-PRSFD CA 'BX'. (PRSFD - PRSFD Carry out pricing)
CHECK: KOMP-KZNEP = SPACE. (KZNEP -Condition exclusion indicator)
ENDIF
SY-SUBRC = 0.
ENDFORM.
* Prestep
FORM KOBEV_002.
SY-SUBRC = 0.
ENDFORM.
For techi’s above program is self explanatory
Explanation:
The above routine “2” is included under Req column in Pricing Procedure. It means that system would first check whether the item category attached for an item in that condition item number in SO is relevant for pricing or not.
If the Item category is pricing relevant only then system will go to VK11 and fetch the price. On the contrary if req. column does not contain 2 as routine against a condition type system will not consider this parameter and would directly jump to VK11.
This routine improves system performance
Note: If an item category marked as NOT relevant for pricing system will not fetch price in the Sales order even if the condition records for the condition types are maintained.

Please let me know in the form of comments should you have any query.

Support Environment

Following are the four major things in support environment, issues fall in the form of tickets.

• Taking Ownership of the call coming in the form of ticket
• Resolving a call
• How to reassign a logged call to the next support level
• Interaction with the next Level support.

Please post your questions here

Hi Guyz n gals,

Pl post your questions in SAP SD in the form of comments under this subtitle and I'll get back with an answer as a different post asap.

Faraz

Master Data and Transaction Data

whats the difference between Master Data and Transaction Data