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.