SD Billing

The following are functions of the billing document in the SD process. Mark the incorrect answer.
1 Billing create billing documents for orders and deliveries
2 Billing update the document flow and billing status
3 Billing do not update the credit account
4 Billing create documents in FI and forward data to Profitability analysis

Posted by Faraz - Sapdude at 9:21 PM 3 comments:

Labels: Billing

Friday, December 21, 2007

What skills can take you to become a Project Manager
What skills can take you to become a Project Manager ? Its just your personal opinion, I need to
know how do you rate the following in your priority list
1 Communication Skills
2 Relevant Expereince
3 Technical ability
4 Convincing ability
5 Team Managment skills
Its obvious that all of the above are important but how would your rank it.
Posted by Faraz - Sapdude at 4:46 AM 5 comments:

Tuesday, November 27, 2007

Which of the following about Pricing Procedure Determination is correct
(a) Prices can be changed in the condition procedure of a sales document and these changes will be marked as
changed manually
(b) Prices cannot be changed in the condition procedure of a sales document but you can add prices manually to a
sales document
(c) You cannot prevent manual changes to condition types in the condition procedure of a sales document
(d) Header conditions can be entered manually at header level and is valid for all items
(e) Header conditions will be automatically distributed proportionally across the items based on net value. The basis
of the distribution cannot be changed in the pricing procedure.
Answer thru your comments.

Posted by Faraz - Sapdude at 2:56 AM 4 comments:

Saturday, November 17, 2007

SD Jobs in UK

Posted by Faraz - Sapdude at 9:01 PM 3 comments:

Tuesday, November 13, 2007

Release Strategy-Pricing
When we enter PR00 in the condition record VK11 , one of the options that we see is Material with Release strategy.
What is this release strategy?

Posted by Faraz - Sapdude at 8:32 AM 2 comments:

Labels: Pricing

Monday, November 12, 2007

Pricing: Real Time Scenario
We need to create a custom table.
Field contents :
Routes, delivery priorities, transportation zones, and transportation planning point.
We have to create a table ZCustom with the above fields and add this field into the Field catalog.
Access Sequence would be
0001: Routes/deliverypriority
0002: tzone/Tpoint/route/delivery priority
Pricing Routine Requirements
A pricing routine is required to calculate the pricing condition value.
Routine -911: If a condition type Pr00 = 0 then move the condition value of PR01 into Pro0 . Both these condition
types will use the above access sequence and both are Basic Prices.
Questions:
1 How would you proceed to add fields in the field catalog after creating the custom table
2 Where would you encapsulate the above routine i.e. in Alctype, Req or Cndbase value and against which condition
type Proo or Pro1
Its a real time case scenario, please assist .

Posted by Faraz - Sapdude at 6:26 AM 2 comments:

Wednesday, November 7, 2007

GAP Analysis
Gap analysis is the study of the differences between two different information systems or applications (ex; existing
system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one
state to a new state. A gap is sometimes spoken of as "the space between where we are and where we want to be."
Gap analysis is undertaken as a means of bridging that space.
Actual gap analysis is time consuming and it plays vital role in blue print stage.
The Gaps can differ from company to company. Most commonly, however, missing functionality is industryspecific.
Examples
In customer master data the client requirement needs legacy customer number which can be solved with User exit.
In sales order we need customer Phone number, we can use user exit
If client want new field in customer master like nearest fire station.
GAP analysis is done in Blue Print stage. It aims to understand what can be done with the standard SAP and how
the client actually wants a particular scenario to be processed.
Its an understanding of the GAP between the actual & required scenarios.
Tthe difference between agreed work and completed work is GAP Analysis.
E.g.: To Fill This Gap, We Use The Enhancements,These Enhancements Divided Into Exits, Like User exits, Field
Exits Screen Exits & Menu Exits.These Enhancements are used to update the standard program in its Respective
Business Transactions, Used as a Gateway to Meet the Client Requirements.

Posted by Faraz - Sapdude at 6:53 PM 2 comments:

User Exits
Ways to find Enhancements/User exits
In SMOD find options of screen, menu, function exits.
Go to SE81 and select the relevant module find the enhancement.
Go to the program or transaction and search for CALL CUSTOMER-FUCTION or EXIT__nnn
For screen exits go to screen in SE51/SE80 search for- CALL CUSTOMER-SUBSCREEN..
User Exits & Customer Exits :
User Exits: These are subroutines used in the SAP namespace 'hard-coded' at various points within SAP Repository
objects.
Customer Exits :
1. Menu Exits: Menu exits add items to the pull down menus in standard SAP applications. You can use these menu
items to call up your own screens or to trigger entire add-on applications. These special entries have function codes
that begin with "+" (a plus sign).
2. Screen Exits: Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing special
sub screen areas on a standard R/3 screen and calling a customer sub screen from the standard screens flow logic. It
is called by call customer- sub screen
3.Function Module Exits :Function module exits add functions to R/3 applications. Function module exits play a
role in both menu and screen exits. When you add a new menu item to a standard pulldown menu, you use a

function module exit to define the actions that should take place once your menu is activated. Function module exits
also control the data flow between standard programs and screen exit fields.
It is called by Call Customer- function

Posted by Faraz - Sapdude at 6:26 PM 2 comments:

Tuesday, November 6, 2007

Some basic questions
1 In SO/Del/Billing we can enter material with different divisions (Config in VoV8), but can we
enter materials with different distribution channels in a sales order and why we dont have this
option ?
2 What is the difference between itemcatgory group and general item category group?
3 Under what business scenarios do we have to use condition types for both header and item
level.
Posted by Faraz - Sapdude at 4:46 AM 3 comments:

Thursday, September 27, 2007

Meaning of "FORM KOBED_002" and "FORM KOBEV_002
Hi Jennifer...Here's is the Functional Perspective of your question.
FORM KOBED and FORM KOBEV are just the two FORMs under which the formula is encapsulated for picking
the price which I have already explained in http://sapdude-sapsd.blogspot.com/2007/06/pricing-procedure-under-requiremnt.html
Whenever a coding is done or a formula is written we do it by using FORMS. The purpose of encapsulating the code under a FORM is
because we should have an option to call the same Form in the some other requirement. So instead of writing the program all over again
we justcall the Form with its name.
KOBED_002 and KOBEV_002 are just the name given under which the Formula is written.
Being a Functional consultant we do not have to worry about the coding part but these FORMand ENDFORM contains the relevant
formulaes for the specific business requirement.
In the above case FORM KOBED_002 the formula written under 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.
Do not bother about FORM KOBEV_002 as it does not holdany meaning particularly for this program.
Do revert for further clarifications.

Posted by Faraz - Sapdude at 11:35 PM 2 comments:

Labels: Pricing

Friday, September 21, 2007

Alternative Calcultation Type
Hi Burning Soul : Here's the explanation to AltCalType
Alternative Calculation Type, Requirement, Cond Base values are used in Pricing to meet the not so common
business requirement. The normal prcing requirements can be mapped without using them .

Coming to the AltCalType, we have to use routines which stores the business logic and can be used against the
relevant condition type as per the business requirment. The routines , in other words are the formulas that are
defined in Tcode- VOFM by the abapers based on the logic given by the functional consultants.
Remember: The routine is applied against a condition type in the pricing procedure
Some of the standard Altcaltype routines are as below
Routine /Formula :- 15
A company has defined minimum prices for materials.
When a material is sold, it should not be sold for a price below the predefined minimum price. When pricing is done
for a sales document line item, if the net price of the item falls below the minimum, the system should automatically
compute a surcharge to bring the price up to the minimum price. To accomplish this, the user would define the
minimum prices using the condition type PMIN. PMIN would be defined in the pricing procedure and condition
value formula '15' would be assigned. Using the formula, the system compares the minimum price with the net price
calculated to that point in the pricing procedure. If the minimum price is not met, the system computes the necessary
surcharge and assigns it to the PMIN condition line.
Routine /Formula :- 48
Formula '48' was delivered to ensure that the down payment amount the user offsets in a billing document does not
exceed the actual down payment value. Condition value formula '48' is assigned to the condition type in the pricing
procedure representing down payments (R/3 delivered condition type AZWR).
Let me know for any further clarifications.
Note: All, please do not copy and paste my posts into your blogs to avoid blog frauds and legal actions.

Posted by Faraz - Sapdude at 10:59 PM 3 comments:

Labels: Pricing

Friday, September 14, 2007

Interview Question (Pricing)
Guyz. ..Here are some interesting pricing questions often asked in interviews.
1. What is condition supplement and why is it used , also how is it configured.
2. If there are two customers, for one customer 10 condition types are mandatory and for the other only two. How
would we configure this if we have to map it with one pricing procedure.
3. Order types, why do we need to create our order types and not use the standard ones during implementation.
4. What is group conditions used in condition type/s
5. What is the pricing header and item table name
If you know the answers post them through the form of comments.

Posted by Faraz - Sapdude at 7:35 AM 5 comments:

Labels: Pricing

Saturday, September 8, 2007

Picking option in display

Question
I am trying to create delivery but the picking option is in display" why?
Hi Mandeep,
The probablity says that you must be trying to create the delivery with standard data, the picking option is greyed
out because the delivery needs shipment and picking would happen through creation of shipments (VT01N) or
through transfer order (LT01). The standalone delivery document would not allow you to create picking.
IF you do not have idea bout shipments and transfer order let me know , will post it later.

Posted by Faraz - Sapdude at 3:05 AM 5 comments:

Thursday, August 23, 2007

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.

.
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.
http://spreadsheets.google.com/pub?key=phixAHJ6iFNOBn91F1vkFHg

Posted by Faraz - Sapdude at 6:38 PM 2 comments:

Labels: Pricing
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 Group10

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
2
3
4
KP No Check

Rep-

Daily
Individual
Current

Lead

Requirement
Requirement
Time
Stock

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

Posted by Faraz - Sapdude at 6:32 PM 10 comments:

Friday, July 27, 2007

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
Posted by Faraz - Sapdude at 7:22 AM 7 comments:

Thursday, July 26, 2007

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.

Posted by Faraz - Sapdude at 3:21 AM 10 comments:

Tuesday, July 24, 2007

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.
Posted by Faraz - Sapdude at 1:55 AM 2 comments:
Labels: Source : http://www.itjobswatch.co.uk

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.

Posted by Faraz - Sapdude at 12:24 AM 2 comments:

Wednesday, July 18, 2007

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

Posted by Faraz - Sapdude at 10:37 PM 4 comments:

Wednesday, July 11, 2007

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.

Posted by Faraz - Sapdude at 6:59 AM 6 comments:

Tuesday, July 10, 2007

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
Posted by Faraz - Sapdude at 2:24 PM 10 comments:

Sunday, July 8, 2007

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.
Posted by Faraz - Sapdude at 11:38 AM 12 comments:
Labels: Delivery Group

Friday, June 29, 2007

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

Posted by Faraz - Sapdude at 7:32 AM 2 comments:

Thursday, June 28, 2007

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 techis 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

Posted by Faraz - Sapdude at 4:37 AM 4 comments:

Labels: Pricing

you have any query.

Friday, June 22, 2007

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.

Posted by Faraz - Sapdude at 8:12 AM 6 comments:

Tuesday, June 19, 2007

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
Posted by Faraz - Sapdude at 7:20 AM 26 comments:
Labels: SAP SD question

Wednesday, June 13, 2007

Master Data and Transaction Data
whats the difference between Master Data and Transaction Data