Author Archives: jiteshdua

Consignment Process

Scenario

1. Client creates a consignment order for their distributor.

2. The consignment stock sits at the distributor location. The distributor sells some of this stock to end customer.

3. Client creates an issue order for this quantity, this order has end customer as the ship to as well as bill to parties.

4. When the goods are delivered against this order, the consignment stock is reduced.

5. Client then creates an invoice for the end customer.

SAP Solution

1. Create Cosignment fill up order of type KB with distributor as sold-to, ship-to and bill-to and payer.

2. Create delivery for this order and do PGI, which shifts this stock to ‘customer consignment stock” (special stock w).

3. Assumption – the master data for the end customer exists in the system and has all mandatory partner functions defined.

4. Create a consignment issue order of type KE, which has sold-to as the distributor and ship-to, bill-to as the end customer.

5. Create delivery and do the PGI, which reduces the consignment stock.

6. Create invoice, which has the end customer as bill-to and the distributor as ‘payer’.

Pricing – Alternate Calculation type, Alt Condition base value and Requirements

The alternate condition base value (Alt CBV) is used as the calculation basis only, while the alternate calculation is used to modify the final value.

For example, imagine you have a condition type ZPR1, with a condition record maintained (master data) for $10. Now, condition ZPR2 also exists lower in the schema, but with a rate of 10%. The standard calculation would result in a final value of $11.

The alternate base value could say, “don’t use $10 as the basis — use the original price PR00 only, which was $9.” Then, the final value would be $10 + (10% of $9) = $10.9.

The alternate calculation routine says, “ignore the 10% altogether. Instead, use an externally calculated 20%.” Then, you end up with a final value of $10 + (20% of $10) = $12.

Put them both together, and you could end up with $10 + (20% of $9) = $11.8.

Alternative Calculation Type:

Normally if you want to calculate a value you have to use a calculation type for determining the value. This calculation type is either addition, subtraction or multiplication. Similarly SAP also has got a default calculation type in the control data of the condition type. There you have the options of either Qty based , Fixed Amount Based or Percentage based.

Here suppose if you define your condition type that calculates the base price of a material on Qty based. Then the calculation will be done based on the quantity of the material. If the customer orders 10 Nos and you have maintained a unit price of $10,- for each material then the value determined is $100,-. Similarly if the discount condition type , you maintain the calculation type as %. This means if you maintain the value of 10% in the condition record. Then this percentage is taken as the calculation type and the condition value is determined.

In some cases you have to forego the default calculation types and use the customer specific method for calculating a value. For ex if you are calculating the Freight charges for a Material . it depends on so many criteria like, the weight, volume and also the minimum amount etc etc, in those cases, you forego the default value and then use the alternative calculation type in calculating the condition value against the particular condition.

Alternative Condition Base value :

If you have to calculate any value then you have to have a base value for it. For ex if you want to calculate the discount of 10 % for a material then you have to have a base value on which this 10% is calculated. Normally you take the condition value of the base price of the material to calculate the value.

Now you don’t want to take the base value and take other values as base value which are derived on some formula. So you create a routine which will do the mathematical operations in the routine and derive you a value which is now used as the base value for calculating the condition value for a particular condition type.

Requirement:
A factor in the condition technique that restricts access to a condition table. The system only accesses a condition table to determine the price if the requirement specified has been met.

Example:
The system uses an access sequence to determine the price of a material. One of the accesses in the sequence contains the requirement “in foreign currency.” The system only uses the table behind this access if the sales order for which the price must be calculated is in a foreign currency.

Set Material Master Price of a material as sales price

The first method – Do not set the pricing condition VPRS as a statistical condition type. Simply remove PR00 and it will work fine if you always use VPRS as your pricing base inside the pricing procedure. VPRS will read both prices based on the price control in the material master. 

Price control S for standard price. 
Price control V for moving average price.   

However, if you are using one pricing procedure where for some items you price using VPRS and some others using PR00, then you should use requirement routines to enable the correct price condition type at the right time. 

The second method involves more work as you need to write a formula ( VOFM) to get that information. 

This is how it goes :- 

1. Set VPRS to be the first step in the pricing procedure and to be subtotal B (as standard). 

2. Set PR00 with alt. calc. type formula, which sets the value of PR00 to be equal to the subtotal B. 
    The routine (created with transaction VOFM) is: 

RV64A901
FORM FRM_KONDI_WERT_600. 
    XKWERT = KOMP-WAVWR.
ENDFORM.

The pricing procedure than looks like that: 

Step 1 VPRS statistical, subtotal B, reqt 4 
Step 2 PR00 Altcty 600 

Pricing Reports

You may use V/LD – Execute Pricing Report to check the prices entered into the Pricing Master.

Normally Pricing Report – “07 Cust.-specific Prices with Scale Display” will do.

Other Pricing Reports you may try are as follows:
|LR|Report title                                                         

|01|Comparison of Price Lists Without Scale Display                      
|02|Comparison of Price Groups Without Scale Display                     
|03|Incoterms with Scale Display                                         
|04|Incoterms Without Scale Display                                      
|05|Price List Types Without Scale Display                               
|06|Price List Types with Scale Display                                  
|07|Cust.-specific Prices with Scale Display                           
|08|Cust.-specific Prices W/out Scale Display               

|09|Material List/Material Pricing Group with Scale Display              
|10|List Mat./Mat.Pricing Groups Without Scale Display                   
|11|Price Groups With Scale Display                                      
|14|Taxes                                                                
|15|Material Price                                                       
|16|Individual Prices                                                    
|17|Discounts and Surcharges by Customer                                 
|18|Discounts and Surcharges by Material                                 
|19|Discounts and Surcharges by Price Group                              
|20|Discounts and Surcharges by Material Group                           
|21|Discounts and Surcharges by Customer/Material                        
|22|Discounts and Surcharges by Customer/Material Group                  
|23|Discounts and Surcharges by Price Group/Material                     
|24|Discounts and Surcharges by Price Group/Material Group               
|25|VAT/ATX1                                                             
|26|Canada/USA                                                           
|27|I.E.P.S Mexico                                                       
|28|Conditions by Customer                                               
|30|Conditions by Customer Hierarchy                                     
|31|Price List with Release Status                                       
|AC|                                                                     
|AD|                                                                     

Difference between Condition Type Ek01 ( Actual Cost) and EK02 Calculated Cost

These are the condition type that will display the results of the unit costing for certain  type of sales document. 

EK01 : 
If you use this condition type, the result of unit costing is issued to the first position on the conditions screen for the item. The value can be used as a basis for price determination. 

EK02: 
If you use this condition type, the result of unit costing is simply a statistical value which you can compare with the price. 

Please note the following points  :

1) The condition type must have condition category ‘Q’ (costing). 

2) The condition type must agree with the condition type defined for unit costing in the pricing procedure. 

Billing quantity

You can make the settings for the billing quantity in the copy control. You have the options of keeping the billing quantity equal to order quantity or delivery quantity or delivered quantity minus the quantity already invoiced. The billing quantity indicator specifies which quantity the system copies from the source document (a sales order, for example) into the target billing document (an invoice, for example).

Make sure that control of the amount to be billed is directly related to the item category billing relevance. (e.g. K – delivery related invoice for partial quantity, G – Order related billing of the delivery quantity etc.)

Suppressing Fields in Sales Order

The fields in a sales order can be made optional / mandatory by following this menu path – IMG – S&D-> Basic > Functions-> Log of incomplete Procedures =>  select the fields > from the tables and the system will check for them (OVA2/VUA2)

To make a filed entry enabled or grey (non-entry allowed):

User exits in the program MV45AFZZ-USEREXIT_FIELD_MODIFICATION

This user exit can be used to modify the attributes of the screen  fields. To do this, the screen fields are allocated to so-called modification groups 1 – 4 and can be edited together during a modification in ABAP.

If a field has no field name, it cannot be allocated to a group. The usage of the field groups (modification group 1-4) is as follows:

Modification group 1: Automatic modification with transaction MFAW

Modification group 2: It contains ‘LOO’ for step loop fields

Modification group 3: For modifications which depend on check tables or on other fixed information

Modification group 4: is not used
The FORM routine is called up for every field of a screen. If you require changes to be made, you must make them in this user exit. This FORM routine is called up by the module FELDAUSWAHL.

Actually suppressing fielding sales orders userwise is quite easy. We are doing it in our company. For this we use userexit FORM USEREXIT_FIELD_MODIFICATION in MV45AFZZ.

Below is the sample code

IF SCREEN-NAME = ‘VBKD-ABSSC’.

AUTHORITY-CHECK OBJECT ‘ZMV45AFZZ’ ID ‘SCRFNAME’ FIELD SCREEN-NAME.

  IF sy-subrc = 0.
    SCREEN-INPUT = 1.
  else.
    SCREEN-INPUT = 0.
  ENDIF.
endif.

You place the authority check object in authorization profile in the role of the users, who should have access to the field (in this case it is VBKD-ABSSC), and there assign the corresponding fields that are to be accessed via this userexit.

Finding User Exits

Need to find user exits module-wise? Suppose we want to see the available sales module user exits. Go to transaction SE81. Click on SD, then click “edit” on the menu bar and choose select subtree. Click on “information system,” Open Environment node, customer exits, and enhancements. Press F8 to get all the user exits for that module. In brief: SE81->SD->Select subtree->Information System->Envir->Exit Techniques->Customers exits->enhancements->Execute(F8)