Q1.We have a situation wherein, during the maintenance of the conditions of an inforecord a new period is inserted into an existing period.

The existing period is split into two records. In this case, the same condition record isassigned to both 'old' partial records. As a result, changes to the conditions in one ofthese 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 shouldnotsplit the condition validity periodsautomatically.It is better to reset the original end of the period, into which the insertion is supposed tobe carried out, to the necessary value and add the new and the remaining period of theoriginal.

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 withreference'.

- Click the conditions in the info record or the purchasing documentpress '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 OverlappingValidity 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 MMstock 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 inMM. It must be present in MM pricing procedure of the purchase order and in SD pricingprocedure 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 orderintercompany 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,13EUR (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 beforeor after the multiplication, depending on the flag 'Currency conv.' in customizing ofcondition 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, thenmultiplies 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 * 11PC =107,14 EUR

This is the calculation made in the example above.

When flag 'Currency conv.' = [x] the system multiplies by the quantity, then convertsto 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,13EUR

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 anaccess sequence.

In what kind of business scenario is this field used?

Answer;Depending on the situation, the field 'Initial Value Allowed' (T682Z-KZINI) has thefollowing meaning:

Case 1Access type: ' ' (Field in fixed key part)Document structure and document field are filledSpecific value is initial

In this case, the indicator means that the condition access is to be carried out with thecontents of the document field also, if the relevant document field (in the documentstructure) 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 customergroups. The field KDRG5 is used for this.

The customers in group 01 receive 1%, and those in group 02 receive 2%. Thecustomers that do not belong to any group are to receive 0.5 %. The customers thatbelong to another group (03, for example), do not receive any discount.Condition records:KDRG5 Amount ValidityZ001 01 1.000 % 01.01.2010 - 31.01.2010Z001 02 2.000 % 01.01.2010 - 31.01.2010Z001 (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 (forexample, 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 thedocument field to the document structure (KOMPAZD for pricing, for example) is to takeplace 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 shouldbe able to specify another price list for individual customers. In individual cases, for somecustomers, none of the price lists should be used.

In the case of customers for which a price list has been determined, a price isdetermined with a further price list-specific access.

In the case of customers for which no price list-specific price has been determined, aprice 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 ValidityZ002 01 01 01.01.2010 - 31.01.2010Z002 02 01 01.01.2010 - 31.01.2010Z002 03 02 01.01.2010 - 31.01.2010

Customer Price list ValidityZ002 CUST_01 99 01.01.2010 - 31.01.2010Z002 CUST_02 98 01.01.2010 - 31.01.2010Z002 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 accessto be overridden by the second access for specific customers.

By setting the indicator 'Initial Value Allowed', it is even possible to suppress a previouslydetermined price list again by maintaining a relevant condition record (such as in theexample for the customer CUST_03).

Case 3

Access type: ' 'Document structure and document field are initialSpecific value is initial

In this case, the indicator means that the condition access is always to take place withthe 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 selectedcustomers, or temporarily for all customers. The condition table that you are usingcontains the material as well as the customers.Condition records:Customer Material Amount ValidityZ003 CUST_01 MAT_01 2.000 % 01.01.2010 - 31.01.2010Z003 CUST_02 MAT_01 3.000 % 01.01.2010 - 31.01.2010Z003 (initial) MAT_01 1.000 % 01.01.2010 - 31.01.2010

This Customizing means that, for customers with an explicit condition record, thecustomer-specific condition record is found first, as there is already a result from the firstaccess.

In the case of all other customers, for which the first access was unsuccessful, the systemsearches for a general non customer-specific condition record via the second access.

This procedure can be used to maintain customer-specific condition records and noncustomer-specific condition records together in one condition table.

As a result, the maintenance of the condition records can be structured more clearly, andthe 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 thesalesperson, receives an invoice as documentation for the transaction and pays itdirectly if necessary.

Posting the sales order initiates a delivery. If the customer has already received thegoods, this delivery should not be relevant for picking.

If the customer goes to a warehouse to pick up the goods, the delivery should be relevantfor 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, thatis, where the customer receives the goods and is satisfied with them, the transaction canbe seen as completed.

The goods issue of the delivery should now be carried out in batch, and billing andtransfer 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 deliveryquantity should be changed.

If the customer is later dissatisfied with the price because for example, the goods arescratched but the customer still wants them, then the price can be changed in the salesorder.

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 damagedduring pickup and replacement stock is not available, but the customer has already paidfor the total quantity.

If changes are made, a new invoice can be created by repeated printout from the salesorder.

The complete transaction, consisting of the sales order and one or more deliveries, canbe adapted to the current requirements either by changing the sales order or thedeliveries.

Only with complete goods issue of the deliveries - which reflects the goods movementreally carried out - can the sales order be billed if the order quantity corresponds to thegoods issue quantity.

Otherwise, the sales order must be adapted so that the delivered and the billedquantities agree.

Q6.We have recently gone live and our logistics modules (especially SD) processesare 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 thatare relevant to the corresponding project. The use of standardprocedures leads to unnessecary access when the condition typesdefined in them are not used and can be accessed automatically.

Group conditions should be used only when there are no otherpossibilities. It is absolutely necessary to check the parametercontrol of each condition type in use, in particular the "groupcondition" indicator.

1.2 Formulas and ConditionsIf possible, use the formulas and conditions provided by the standardeven when you use your own new condition types and procedures. Newprocedures that do not contain formulas and conditions given by thestandard may produce incorrect results. When new requirements make newformulas or conditions necessary you can set them up via thetransaction "VOFM".

By skilfully defining conditions you can avoid unnecessary access.Example: For one condition type, you use access via "Price groupCustomer" and you know that out of ten defined price groups conditionrecords are only maintained for groups 01 and 02.

Condition amounts for the remaining eight groups are always added tothe 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 thecharacteristics "01" or "02" should be stored in the procedure.

1.3 Access SequenceReduce the number of tables defined in an access sequence to theminimum necessary.

Example:A customer exclusively uses price lists for administrationpurposes and for fixing sales prices.Thus the tables designed for purely material oriented as well as thosefor both customer and material oriented pricing can be deleted fromthe access sequence for "PR00", even though these options weresupplied.The best solution would be to set up your own new access sequence inorder to prevent SAP standards from being changed.

As long as cascading access is necessary please use the"Exclusiveaccess"option. It ends the search in additional price tables as soonas a valid record has been found.

When combining header and item conditions, you can also reduce thesearch process by using "Pre-step".

Example:Condition types that are not indicated in the conditionheader of an order need not be checked on the following items.

1.4 Condition types and price tablesOnly activate and use project relevant condition types. Types that arealways 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 thusthe number of condition records by reducing key combinations (forexample, 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 customerprice group can be derived from the customer master record and a"customer number/material number" key would have the same effect.

2. Buffering price tablesWhen the customer has sufficient resources at his disposal the pricetables used most often can be maintained in the memory as "100%resident".In doing so, you should pay attention to the frequency ofchanges 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 documentraises doubts about an efficient organisation of this customerproject.

4. Message control.Processing in the "Print immediately" mode should be regarded as acomputer and database intensive procedure. In order to put less strainon 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, fortechnical reasons it is not very useful to set up new sales areas andto 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 recordsDeactivate this option if not used.

11. Availability checkDeactivate this option if not used. For performance reasons, youshould choose processing of summarized requirements rather thanprocessing of individual requirements.

Do you use different checking strategies for different material groupswhich lead to simplification and load reduction?

Do you really need block mechanisms for material masters in a concreteproject situation or may specific materials or groups of materials beprocessed 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-2posting as much as possible.

13. Reporting.Use "fast displays" as much as possible.Increasing depth of access requires more processing capacity than apurely 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 notused.If possible, reports should be processed in offline mode and notnecessarily in daily operation.

14. Collective processing transactions 'VLO4' and 'VF04'.If used, both the creation of deliveries and the creation of billingdocuments should be transferred to offline mode.

15. Individual ABAP developments.The performance of individual developments must be checked with themonitor tools available.

Programs which are used frequently should beoptimized as far as possible.

15.1 Data transfer programs.To transfer data, please use the standard programs available. As longas you have several servers/CPUs at your disposal you can use loadmodules in parallel to each server/CPU, provided that an underlyingsource file has been usefully pre-sorted and/or usefully split intoseveral files.

Example:100 000 customer masters have to be loaded from an externalsystem. Two servers are available, the data has been extracted from anexisting 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 eachand 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 beaccessed via original document tables.