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.

“Exclusive access” option. It ends the search

As long as cascading access is necessary please use the

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