110 SAP SD Interview Questions with Answers & Explanations – eBook
Sample SAP SD (SCM – Order Fulfilment) Interview Questions with Answers
SAP SD interview questions can cover a very wide range.
Here is a sample of questions that a typical SD functional Consultant can be expected to face.
Q1. We have a situation wherein, during the maintenance of the conditions of an info record a new period is inserted into an existing period.
The existing period is split into two records. In this case, the same condition record is assigned to both ‘old’ partial records. As a result, changes to the conditions in one of these periods also immediately affects the other one.
How do we resolve this issue?
Answer:
There is no technical solution!
In order to avoid the system response, you should not split the condition validity periods automatically.
It is better to reset the original end of the period, into which the insertion is supposed to be carried out, to the necessary value and add the new and the remaining period of the original.
Existing defective condition validity periods can be repaired manually with simple means:
– Select a period in the dialog box and choose ‘New validity period’ or ‘New with reference’.
– Click the conditions in the info record or the purchasing document press ‘New with template’,
If you choose ‘New with reference’, all the values are transferred
– entering the old start and end date and possible new conditions,
– Save
– If necessary, check and confirm the data on the ‘Errors as a Result of Overlapping Validity Periods’ dialog box.
Check the data and, where necessary, confirm.
Both periods should be separated from now on.
Q2. We use several intercompany processes & need to copy the price from the MM stock transfer purchase order into the SD intercompany billing. How can we do this?
Answer;
The following settings are required;
1. The same condition type, for example PB00, must be defined both in SD and in MM. It must be present in MM pricing procedure of the purchase order and in SD pricing procedure of the intercompany billing
2. In customizing copy control replenishment delivery > intercompany billing (transaction VTFL) the following settings are necessary at item level:
– field Pricing type (TVCPF-KNPRS) should not re-determine the price condition
– field Price source (TVCPF-PRSQU) must be ‘A’ or ‘B’
Notice that purchase order can be used as price source only in stock transfer order intercompany process. It cannot be used in other kind of processes (example third-party).
Q3. We have a situation of a ‘rounding’ issue due to currency conversion.
A sales document has a pricing condition with currency different than document currency.
The following example illustrates the issue;
– Run VA01 to create a sales order with currency EUR
– Insert an item with quantity 11 PC, goto item pricing screen, insert the price PR00 = 12,00 CHF per 1 PC
– The exchange rate is 1 CHF = 0,81158 EUR
– The system calculates PR00 value 107,14 EUR, whilst the expected value is 107,13 EUR (12,00 * 11 * 0,81158 = 107,12856)
What setting may be used to fix this?
Answer;
The conversion from condition currency to document currency can be performed before or after the multiplication, depending on the flag ‘Currency conv.’ in customizing of condition type (field T685A-GANZZ in transaction V/06).
With reference to the example above.
• When flag ‘Currency conv.’ is blank the system converts to document currency, then multiplies by the quantity:
– The system converts 12 CHF per 1 PC = 9,74 EUR per 1 PC
– Then it calculates the condition value in document currency 9,74 EUR / 1 PC * 11 PC = 107,14 EUR
This is the calculation made in the example above.
• When flag ‘Currency conv.’ = [x] the system multiplies by the quantity, then converts to document currency:
– The system calculates the condition value in condition currency 12,00 CHF / 1 PC * 11 PC = 132,00 CHF
– Then it converts the condition value to document currency 132,00 CHF = 107,13 EUR
The flag ‘Currency conv.’ should be set according to the business requirement.
Q4. In a pricing, you use the field ‘Initial Value Allowed’ (T682Z-KZINI) in the access to an access sequence.
In what kind of business scenario is this field used?
Answer;
Depending on the situation, the field ‘Initial Value Allowed’ (T682Z-KZINI) has the following meaning:
Case 1
Access type: ‘ ‘ (Field in fixed key part)
Document structure and document field are filled
Specific value is initial
In this case, the indicator means that the condition access is to be carried out with the contents of the document field also, if the relevant document field (in the document structure) is initial.
As a result, condition records with initial key fields can also be determined.
Example:
You are using a discount condition type that you want to apply for specific customer groups. The field KDRG5 is used for this.
The customers in group 01 receive 1%, and those in group 02 receive 2%. The customers that do not belong to any group are to receive 0.5 %. The customers that belong to another group (03, for example), do not receive any discount.
Condition records:
KDRG5 Amount Validity
Z001 01 1.000 % 01.01.2010 – 31.01.2010
Z001 02 2.000 % 01.01.2010 – 31.01.2010
Z001 (initial) 0.500 % 01.01.2010 – 31.01.2010
Case 2
Access type: ‘C’ (Data field from condition table)
The document structure and document field are filled; a data field is involved (for example, pricing uses the structure ‘KOMPAZD’ for this)
Specific value is not maintained, as the field is inactive anyway
In this case, the indicator means that the automatic return transport of the contents of the document field to the document structure (KOMPAZD for pricing, for example) is to take place even if the relevant data field is initial in the condition record that is determined.
As a result, the field in the document structure (KOMPAZD, for example) is initialized.
Example:
You use price lists for selected materials, which should override a standard price. Depending on the customer group, you can use another price list. In addition, you should be able to specify another price list for individual customers. In individual cases, for some customers, none of the price lists should be used.
In the case of customers for which a price list has been determined, a price is determined with a further price list-specific access.
In the case of customers for which no price list-specific price has been determined, a price can be determined with a further non price list-specific access.
To determine the price list, the data determination in the access is used:
Condition records:
KDRG5 Price list Validity
Z002 01 01 01.01.2010 – 31.01.2010
Z002 02 01 01.01.2010 – 31.01.2010
Z002 03 02 01.01.2010 – 31.01.2010
Customer Price list Validity
Z002 CUST_01 99 01.01.2010 – 31.01.2010
Z002 CUST_02 98 01.01.2010 – 31.01.2010
Z002 CUST_03 (initial) 01.01.2010 – 31.01.2010
The customer CUST_03 belongs to the customer group 02.
This Customizing allows a price list that was determined on the basis of the first access to be overridden by the second access for specific customers.
By setting the indicator ‘Initial Value Allowed’, it is even possible to suppress a previously determined price list again by maintaining a relevant condition record (such as in the example for the customer CUST_03).
Case 3
Access type: ‘ ‘
Document structure and document field are initial
Specific value is initial
In this case, the indicator means that the condition access is always to take place with the initial specific value.
As a result, condition records with initial key fields can also be determined.
Example:
You are using a discount condition type that you can choose to apply for selected customers, or temporarily for all customers. The condition table that you are using contains the material as well as the customers.
Condition records:
Customer Material Amount Validity
Z003 CUST_01 MAT_01 2.000 % 01.01.2010 – 31.01.2010
Z003 CUST_02 MAT_01 3.000 % 01.01.2010 – 31.01.2010
Z003 (initial) MAT_01 1.000 % 01.01.2010 – 31.01.2010
This Customizing means that, for customers with an explicit condition record, the customer-specific condition record is found first, as there is already a result from the first access.
In the case of all other customers, for which the first access was unsuccessful, the system searches for a general non customer-specific condition record via the second access.
This procedure can be used to maintain customer-specific condition records and non customer-specific condition records together in one condition table.
As a result, the maintenance of the condition records can be structured more clearly, and the number of condition tables required is reduced.
Q5. Please describe how cash sales work. Is ‘Picking’ relevant to cash sales? What kind of options are available to manually fix a cash sales if things go wrong e.g. goods are damaged or sufficient stock is unavailable?
Answer;
By cash sale, we mean a business transaction where the customer deals directly with the salesperson, receives an invoice as documentation for the transaction and pays it directly if necessary.
Posting the sales order initiates a delivery. If the customer has already received the goods, this delivery should not be relevant for picking.
If the customer goes to a warehouse to pick up the goods, the delivery should be relevant for picking.
Even the sending of the goods can be supported via normal delivery processing.
In cases where the transaction goes as expected by the salesperson and the buyer, that is, where the customer receives the goods and is satisfied with them, the transaction can be seen as completed.
The goods issue of the delivery should now be carried out in batch, and billing and transfer to FI is carried out by the billing collective processing.
If the transaction does not run quite so smoothly, then a manual intervention is necessary. If the goods, for example cannot be found in the full amount in the warehouse, the delivery quantity should be changed.
If the customer is later dissatisfied with the price because for example, the goods are scratched but the customer still wants them, then the price can be changed in the sales order.
In extreme cases, the entire transaction starting with the delivery can be deleted.
It is also possible to initiate a subsequent delivery if a part of the delivery is damaged during pickup and replacement stock is not available, but the customer has already paid for the total quantity.
If changes are made, a new invoice can be created by repeated printout from the sales order.
The complete transaction, consisting of the sales order and one or more deliveries, can be adapted to the current requirements either by changing the sales order or the deliveries.
Only with complete goods issue of the deliveries – which reflects the goods movement really carried out – can the sales order be billed if the order quantity corresponds to the goods issue quantity.
Otherwise, the sales order must be adapted so that the delivered and the billed quantities agree.
Q6. We have recently gone live and our logistics modules (especially SD) processes are experiencing poor response times.
What are the areas you would look at in view of addressing this problem?
Answer;
From a Sales & Distribution perspective, the following areas should be looked at;
1. Pricing Procedures.
1.1 Condition types in a procedure.
The procedures in use should contain only those condition types that are relevant to the corresponding project. The use of standard procedures leads to unnessecary access when the condition types defined in them are not used and can be accessed automatically.
Group conditions should be used only when there are no other possibilities. It is absolutely necessary to check the parameter control of each condition type in use, in particular the “group condition” indicator.
1.2 Formulas and Conditions
If possible, use the formulas and conditions provided by the standard even when you use your own new condition types and procedures. New procedures that do not contain formulas and conditions given by the standard may produce incorrect results. When new requirements make new formulas or conditions necessary you can set them up via the transaction “VOFM”.
By skilfully defining conditions you can avoid unnecessary access. Example: For one condition type, you use access via “Price group Customer” and you know that out of ten defined price groups condition records are only maintained for groups 01 and 02.
Condition amounts for the remaining eight groups are always added to the document by hand or they are not considered at all. In this case, a condition which has the effect that access can only be made for the characteristics “01” or “02” should be stored in the procedure.
1.3 Access Sequence
Reduce the number of tables defined in an access sequence to the minimum necessary.
Example: A customer exclusively uses price lists for administration purposes and for fixing sales prices.
Thus the tables designed for purely material oriented as well as those for both customer and material oriented pricing can be deleted from the access sequence for “PR00”, even though these options were supplied.
The best solution would be to set up your own new access sequence in order to prevent SAP standards from being changed.
As long as cascading access is necessary please use the “Exclusive access” option. It ends the search in additional price tables as soon as a valid record has been found.
When combining header and item conditions, you can also reduce the search process by using “Pre-step”.
Example: Condition types that are not indicated in the condition header of an order need not be checked on the following items.
1.4 Condition types and price tables
Only activate and use project relevant condition types. Types that are always allocated by hand do not need an access sequence. If possible, you should use the “Condition supplements” technique.
Try to minimize the number of tables, the content of tables and thus the number of condition records by reducing key combinations (for example, customer/material price group).
Prevent the use of redundant keys or key elements.
Example: The key of a condition table is set up in the following way: customer price group/customer number/material number.
This combination does not necessarily make sense since the customer price group can be derived from the customer master record and a “customer number/material number” key would have the same effect.
2. Buffering price tables
When the customer has sufficient resources at his disposal the price tables used most often can be maintained in the memory as “100% resident”.
In doing so, you should pay attention to the frequency of changes and buffer behaviour.
3. Partner determination.
For the processing of partners please refer to the Chapter “Pricing”. For example, the use of more than ten partner roles in one document raises doubts about an efficient organisation of this customer project.
4. Message control.
Processing in the “Print immediately” mode should be regarded as a computer and database intensive procedure. In order to put less strain on the online mode we recommend that you transfer all message types, as far as possible, to the offline mode and to process them as “collective printing”.
5. Organizational units and “common master data”.
Try to reduce your setup to the minimum necessary. For example, for technical reasons it is not very useful to set up new sales areas and to maintain condition tables for each area separately.
6. Dispatch scheduling.
Deactivate this option if not used.
7. Transport scheduling.
Deactivate this option if not used.
8. Routes.
Deactivate this option if not used.
9. Credit limit check.
Deactivate this option if not used.
10. Processing customer information records
Deactivate this option if not used.
11. Availability check
Deactivate this option if not used. For performance reasons, you should choose processing of summarized requirements rather than processing of individual requirements.
Do you use different checking strategies for different material groups which lead to simplification and load reduction?
Do you really need block mechanisms for material masters in a concrete project situation or may specific materials or groups of materials be processed without being blocked?
12. Statistics update (SIS).
The update of SIS tables should be reduced to the minimum necessary. To shorten the processing time you should use the asynchronous V-2 posting as much as possible.
13. Reporting.
Use “fast displays” as much as possible.
Increasing depth of access requires more processing capacity than a purely index oriented evaluation, the case “Index -> Document header -> Document item -> Schedule line” is an extreme example.
You can delete the additional display “partner name” if it is not used.
If possible, reports should be processed in offline mode and not necessarily in daily operation.
14. Collective processing transactions ‘VLO4’ and ‘VF04’.
If used, both the creation of deliveries and the creation of billing documents should be transferred to offline mode.
15. Individual ABAP developments.
The performance of individual developments must be checked with the monitor tools available.
Programs which are used frequently should be optimized as far as possible.
15.1 Data transfer programs.
To transfer data, please use the standard programs available. As long as you have several servers/CPUs at your disposal you can use load modules in parallel to each server/CPU, provided that an underlying source file has been usefully pre-sorted and/or usefully split into several files.
Example: 100 000 customer masters have to be loaded from an external system. Two servers are available, the data has been extracted from an existing system and is in a sequential dataset “A”. File “B” is created.
Then file “A” is sorted, and the data distributed to the two files. Then the two files are imported by the load module to one server each and hence imported into SAP.
15.2 Programs with access to document flow (table “VBFA”).
May only be used in exceptional cases, since all necessary data can be accessed via original document tables
More Interview Questions? Have a look at:
110 SAP SD Interview Questions with Answers & Explanations – eBook