Tuesday, June 3, 2014

Same Material For Third Party and Regular Business

Business Case: When the material is available in company they can fulfill the customers order else the order will be routed to the vendor.For the same material , same customer and same order type the material should behave in both third party and normal sales process.

Config and Master Data Change

To address this business case please do the below settings

1. Make Item Cat Group in MMR as NORM.
2. Procurement in MRP2 in MMR as X-External and Internal.
3. Assign the NORM to TAN as default Item Category and TAS as Manual Item Category in Item category assignment VOV4.


Process Flow:

Create a sales order (order type OR) for the material , the item category will determine as TAN due to default item category. Which will determine the Schedule Line category for regular materials.

Change the item category as TAS which will allow you to change it manually as we have made the configuration changes , once the item category is changed system will determine the 3rd party schedule line category which will create a PR.


Tuesday, January 8, 2013

Subsequent Free Of Charge Of Delivery & Free Of Charge Delivery


Subsequent Free Of Charge Of Delivery & Free Of Charge Delivery are used in different business scenario although both sounds almost same apart from the name description, but in SAP both of them are separate and uses in different business scenarios.

Subsequent Free Of Charge Of Delivery

When we sent a material to customer and that material got damaged or can not used for one or another reason in normal scenario we issue a credit note to the customer but in some business the customer don't need a credit note and instant of that they need the material to be replaced.

To face these type of business cases SAP has provided Subsequent Free Of Charge Of Delivery. So through Subsequent Free Of Charge Of Delivery we can replace the material to the customer instant of issuing a credit note.

Till SAP 4.7 the Document type was KN but in ECC6 its changes to SD.

As a normal business when we are replacing  a material to customer we should keep a record of the original document. For that SAP has made Reference document as mandatory for Subsequent Free Of Charge Of Delivery document type KN/SD.


Delivery & Free Of Charge Delivery

Delivery & Free Of Charge Delivery is used when we are sending a sample to customer may be for promotion for a particular material.

SAP document type is FD which is used for Delivery & Free Of Charge Delivery.


Please do comment on the post. Feel free to ask any question.

Thursday, August 16, 2012

SAP ALE , EDI and Idoc....

Hello All
This Post is to give some idea about ALE , EDI and Idoc. Before starting the post I would like to clear some of the idea about the above topics. As ALE , EDI and Idoc is not a very small topic which can cover in one post of can explain in one documentation.

The purpose of this document is to give the idea of these 3 which may help you start and may be to understand how these works.

Day by day the business process is getting very complicated which makes bit difficult to design the org structure. In almost all the company's e respective of the size they are connected with one or another SAP or Non SAP system. To connect you SAP to another SAP or Non SAP system you need to make a link on that or "commonly used to interface them". When the work " Interface" comes in to picture then one of the choice is  ALE or EDI for data transferring.

ALE which stands for Application Link Enabling and EDI which stands for Electronic Data Interface.
and Idoc stands for Intermediate Document.

Before standing with the configuration we have to understand what is the use of both of them and why they are different.

ALE is basically used to transfer data between 2 SAP system where as EDI is used to transfer data between SAP and Non SAP system. EDI is commonly recognized in all the language and can used to interface with all most all the platform.

Idoc is a container which just contain the data from one place to another , as this is a container so this is used  in both the places.

Hope till now its being clear that why and where we use ALE and EDI and also what is use of Idoc.

I will not get in depth of the technical part of that which may confuse in this initial stage.

Now I will explain how to configure a Idoc and what all are the steps associate with that.


     Consider we have to exchange data between two different clients.  Following are the configuration steps common for Interchange Documents in both the clients.

   3.1. Create segment

a.   Go to transaction WE31 -> Give your segment name -> Press Create.



b.   Type your field name and data element and press save then segment definition will be created automatically.
         

  3.2 Create Idoc Type

        Go to Transaction WE30
a.    For new IDOC type select the radio button Basic type and press Create button.
           
b.    Then select the IDOC option to create and press Enter. Give segment name, minimum and maximum number for and save it. Check if this is mandatory segment.    

c.     If you want Header and Item create the segment tree according to that, you can view as follows then press Save.    

d.    Then go back and set release the IDOC type for using it further. Idoc type will be created successfully once we release that status. We have to release the segments (in WE31) and IDOC type as well.

  3.3   Create Message Type

Go to transaction WE81 for new message type. Go to change mode and click New Entries for creating our own message type.


  3.4   Associate Message Type with Basic Idoc Type

Go to transaction WE82 for associating the message type with basic IDOC type.





  3.5 Create Logical System

Go to transaction SPRO and press SAP Reference IMG for creating the logical system for source and destination.     
Click the node define logical system from SPRO -> SAP Reference IMG -> SAP customizing Implementation Guide -> SAP xApp Resource and Portfolio Management (SAP xRPM) -> Base system Interfaces -> SAP Human Capital Management Integration -> Common system configuration and SAP HCM ALE setup -> Application link enabling (ALE) -> Basic Settings -> Logical Systems -> Define Logical System   


 Else go to transaction SALE then go to Basic settings-> logical system then Define logical system. We can create the same.


   3.6 Create Logical Connection

a.     Go to transaction SM59 for creating Logical Destination. SM59 -> logical connections -> Create


         b. Then Click Connection test  icon after marking the current user checkbox in logon and security tab.
          
c. Then Destination client will automatically open  



3.7 Create Ports

      Go to transaction WE21 for creating ports. WE21 -> Transactional IR -> Create                                  

4. Steps to be done in Source client

1. Go to transaction SE11 -> create a table with entries.
2. Go to transaction WE31 -> create segments as shown before. Here you have to mention all the fields mentioned in the database table.
3. Go to transaction WE30 -> create basic IDOC type and release the segments and basic type.
4. Go to transaction WE81 -> create message type.
5. Go to transaction WE82 -> assign message type to basic Idoc type.
6. Go to transaction BD64 -> Click on Display/change button           
7.     Click on Edit menu -> model view -> create                  

8. Specify description and technical name and press continue.
                     
9. Select your model view -> click edit -> Add message type
                   
        10. In dialog box specify sender, receiver, and message type and continue. Now the model view looks
             Like

       11. Click on environment menu -> generate partner profile      

          
         12. It will show the following screen. Select your model view and click on execute.      

        13. It will show the partner profile log in next screen.
        14. Click on back button 2 times it will take to distribution model screen.
        15. Click on Edit -> Model view -> Distribute
        16. In displayed dialog box select the partner system and continue.
        17. Then it will show the log of model view distribution.
        18. To check partner profile go to transaction WE20.
        19. Then write the report program in SE38 to create IDOC control records and transfer it to destination   partner system.
        20. Go to Transaction WE02 to check the generated IDOC control records.

5. Steps to be done in Destination client

1.     Go to transaction SE37 to create the function module for updating the table from IDOC segments.
2.     Specify import, export and table parameters.
3.     Go to transaction WE57 for assigning the FM to logical system. Click on Display/ change button.

            4. Specify FM name, function type, basic type(IDOC ), message type and direction then save it.
            5. Go to transaction BD51 to define input method for inbound function module and click on Display      change button
                 
             6. Specify your function module and input type by clicking the new entries.
            7. Go to transaction WE42 and  create process code.
            8. Go to transaction BD64 and generate the partner profile again.
            9. Got o transaction SE 38 and execute the transaction in source system (client100).
10. Check in destination system (client 800). Go to Transaction WE02 and check your table in SE11. (You can get the transferred entries in that table).

Monday, August 13, 2012

SAP SD All Determination

I always feel difficult to remember all the determination related to SAP SD. That always takes time for me to go to the SPRO and find out.

So I thought to share the same with all of you , which may help you ....

Always like to get comments and suggestion 



Sales document
Sales Area 
+ Document Type

Item category determination for Sales document
Document type 
+ Item category Group 
+ Usage 
+ High level Item Category 

Schedule line category determination
Item category of the corresponding item 
+ MRP type of the Material 

Delivery document determination
Delivery document default type attached to  Sales document type

Item category determination for Delivery document
Copy form Sales document 
or 
Delivery Document type 
+ Item category Group 
+ Usage 
+ High level Item Category

Shipping Determination
Delivery Plant 
+ Shipping condition (Customer Master - Sold-to Party) 
+ Loading group(Matrial Master)

Route determination
Departure zone of the shipping pt(Customizing) 
+ shipping condition(SP) 
+ Transport group(MM) 
+ Transportation zone of the Ship to party(General Data)

Storage location determination
Shipping point 
+ Delivery plant 
+ storage condition

Picking determination
On bases of MALA rule  
Delivery Plant 
+ Loading Group 
+ Storage condition(MM) 
(storage rule also assignment to Delivery type)

Packing determination
Package usage

POD
This object use for confirmation of delivery, based on which billing document can create

Billing document determination
Sales document type is maintained as default type 
For Billing plan, Billing Type maintain under Billing Plan Type of Maintain Date Category for Billing Plan Type

Account determination
Chart of Accounts 
+ Sales Org 
+ Customer Account grp (Customer Master - Payer) 
+ Material Account grp (Material Master) 
+ Account key

Business area determination
Plant/Valutaion Area 
OR 
Sales area 
OR 
Item division + Plant 

Company code determination
Sales organization uniquely attached to Company code

Partner determination
At -Account group level, sales document header level, item level, sales document delivery level, Shipment level, Billing document level and item level
Delivery Plant determination
The system will determine Plant details at following in given sequence 
Customer - Material info record 
From customer master Ship-to Party 
From Material Master

Output determination
Output determination at Sales document level, Delivery level, Billing level

Price determination
Pricing procedure 
Sales Area
+ Document Pricing Procedure indicator from Sale/Billing Document type 
+ Pricing Pricing Procedure indicator from Customer Master (Sold-to Party)

Text determination
1)Customer Material Information Record 
2) Customer Master (General text, Accounting text, Sales text) 
3) Material master text (Sales text or PO text) 

Warehouse determination
Ware house number 
+ Plant 
+ Storage location

Lean Warehouse determination
Lean ware house activate, 
Plant 
+ Storage Location 
+ Ware house number

Tax determination
Destination Country of Ship-to Party 
+ Departure Country of Shipping Point 
+ Tax Classification for Customer from Customer Master 
+ Tax Classification for Material Master

Routing determination
Shipping point 
+ Delivery plant 
+ Loading condition 
+ Shipping condition

Material determination
Create condition record 
Maintain Customer Material record

Product substitute
Create condition record

Product Exclusion
Create condition record(Not to sale any particular product)

Product listing
Create condition record (Sale of one particular product)

Credit check
Credit check at Sales document level OR at Delivery OR at Good issue Risk group at Sales document level and Risk category from Customer Master, Item category credit check should be activate


Incomplete log
Incomplete log assign to Status group, which is assign to Sales document, Item category or Schedule line level

Rebate condition setup
customer master billing info checked, Sales organization activate, Billing document activate

Wednesday, April 4, 2012

There are two type of Pricing in Materiel Master
1. Standard Price .. In MMR Accounting Tab1 mentioned as "S"
2. Moving Average Price --- In MMR Accounting tab 1 mentioned as "V".

In very higher lever we can say that if the material price is fixed then we can use as Standard Price in MMR and if the Material price can change or differ from time to time the we can use Moving average price.

Generally all raw materials (ROH), spare parts (ERSA), traded goods (HAWA) etc. are assigned as moving average price (MAP) because of the accounting practice of accurately valuating the inventory of such materials. These materials are subject to the purchase price fluctuations on a regular basis. 

Company generally use moving average on purchased materials with small cost fluctuations. It is most appropriate when the item is easily obtainable. The impact on margins are minimized which reduces the need for variance analysis. Furthermore, the administrative effort is low as there are no cost estimates to maintain. The cost reflects variances, which are closer to actual costs. 

The semi-finished goods (HALB) and finished products (FERT) are valuated with standard price because of the product costing angle. If these were to be MAP controlled, then finished/semi-finished product valuation would fluctuate due to data entry errors during backflushing of material and labour, production inefficiencies (higher cost) or efficiencies (lower cost). This is not a standard accounting and costing practice. 

Refer to OSS note 81682 - Pr.Contr.V for semi-finished and finished products. 
SAP recommends that standard price to be used for FERT and HALB. If actual price is required for valuation, make used of the functions of material ledger where a periodic actual price is created which is more realistic. 
e.g. how SAP calcualte the moving average price 
Goods Receipt for Purchase Order 
Balance on hand quantity + Goods Receipts quantity 
Balance on hand value + Goods Receipts value 
New Moving Average Price = Total Value / Total Quantity 

Invoice Receipt for Purchase Order 
Invoice price more than Purchase Order price 

additional value add to Balance on hand value then divided by Balance on hand quantity 
Invoice price less than Purchase Order price 
difference is deducted from the Balance on hand value (up to 0). The rest of the amount will becomes price variance. This will result in Balance on hand value is zero while there are Balance on hand quantity. If the Balance on hand value is enough to deduct, then the remaining value will be divided by Balance on hand quantity. 
When your Goods Issue price is constantly greater than your Goods Receipt price, it will result into zero value moving average price. 
OSS note 
185961 - Moving Average Price Calculation. 
88320 - Strong variances when creating moving average price. 

Never allow negative stocks for materials carried at the moving average.

Labels:

Wednesday, February 1, 2012


Access Sequence:
Access Sequence is a searching strategy for pricing to find the valid date for a  particular condition type. In the Access Sequence we can assign more than 1 condition table in a particular sequence. As I earlier that Access Sequence is a searching strategy so to make the right search we have to careful when assigning the Condition Table in Access Sequence.
For example if we assign a Access Sequence say ABC with Condition Table A and B where A is Customer and B is Material. So if my organization is giving the priority for any condition type  for Material rather than Customer then in the Access Sequence we have to assign Table B 1st flowed by table A.

To create Pricing Access Sequence the menu path as under Sales and Distribution > Basic Function > Pricing > Price Control > Define Access Sequence..

We can use any existing Access Sequence or can copy the exisiting and create a new starts with Z.
To differentiate the Rebate Access Sequence and the Pricing Access Sequence the field Ty (Relevant For Rebate)  used. Use 1 to make the Access Sequence Relevant for Rebate.
ü  Create a new Access Sequence Starts with Z and give a description.
ü  Always use any existing Access Sequence and copy to create a new access sequence.
ü  Assign the Condition table in a sequential order. The Tab NO. is like as step.
ü  Use the Requirement field if we want to use any routine.
ü  Exclusive tab is used if we want to stop the searching for a once the 1st requirement is meet.
ü  Select the line and click on table and save.



Condition Type :

The pricing elements are define in SAP as condition type. Elements means Price, Discount , Fright etc….
In the Condition Type we define all the characteristic of a Pricing element. So its became very important to understand the needs and use of the Condition Type before we configure any new condition type.
Before start configuring any new condition type make sure the below points or the questions are clear…
ü  Can we make use of any existing Condition Type.
ü  What type of Condition it is i.e price , surcharge , fright etc…
ü  What will be the calculation type for this condition
ü  Will we maintain it manually or automatic
ü  Is that a header condition or item.


The above questions will make you more confident to start the configuration of a new condition type.
As always create a new condition type starts with Z.

The Configuration Of Pricing Condition Type  can be found under Sales and Distribution > Basic Function > Pricing > Price Control > Define Condition Type….

We will take an example of PR00 which is Price condition type and will see all the fields on it.
If you want to create a new Condition Type  copy the existing and create a new.


The above screen is the details screen of PR00.

1.       1. Next to the name of the condition type and self explanatory description there is a filed named as Access Sequence which is the same Access Sequence which we created in the above step and will assign the same here.

1.   2.       Condition Class is differentiate the class of the condition like Price , Discount etc.. use this filed to differentiate what pricing element this is..


1.       Plus / Minus filed controls the amount of this condition will have a positive (for price ) , negative (for discount)  or both the effect it has.
Make use of this filed carefully , if you use Positive (+) then that will effect  an positive in amount or other way around.

 Controls whether the condition results in an amount, that is negative (a discount), positive (a surcharge), or whether both positive and negative amounts are possible.

Calculation Type


Determines how the system calculates prices, discounts, or surcharges in a condition. For example, the system can calculate a price as a fixed amount or as a percentage based on quantity, volume, or weight.

Condition Category






Classification of conditions based on predefined categories.
Eg: Tax, freight etc.

Structure Condition


Ø  Controls whether the condition type should be a duplicated condition or a cumulated condition.
Ø  This control is only helpful when you use bill of materials or configurable materials.
Ø  A duplicated condition is duplicated into all assigned items.
Ø  A cumulated condition contains the net value of all assigned items.

Group Condition


Group condition
Indicates whether the system calculates the basis for the scale value from more than one item in the document.
Use
For a group condition to be effective, the items must belong to a group. You can freely define the group to meet the needs of your own organization. The items can, for example, all belong to the same material group.
Example
A sales order contains two items. Both items belong to the material group 01.


The group condition indicator is set in the definition of the condition type for material group discounts.
The condition record for material group 01 includes the following pricing scale:
Neither item alone qualifies for the 2% discount. However, when the items are combined as part of a group condition, the combined quantity creates a basis of 250 pieces. This basis then exceeds the scale value of 200 pieces, which is necessary to qualify for the higher discount.

Group Condition Routine








Ø  Indicator that controls whether rounding difference is settled for group conditions with a group key routine.
Ø  If the indicator is set, the system compares the condition value at header level with the total of the condition values at item level. The difference is then added to the largest item.


Changes which can be made

Entries Priorities

Making manual entries
Indicator which controls the priority within a condition type between a condition entered manually and a condition automatically determined by the system.
Make the following entries according to your requirements:
_: No limitations
A: Freely definable
B: The automatic entry has priority. If a condition record exists, the     condition cannot be entered manually.
C: The manual entry has priority. When you enter the condition    manually, the system does not check whether a condition record     exists.
D: Cannot be processed manually


Header Condition

Condition applies to header
If this condition is marked as a header condition, it is possible to enter the condition type in the header condition screen. Checks for changing the condition manually are unaffected by this.



Condition rate of change for amount/percentage

Specifies whether the amount or percentage for the condition type can be changed during document processing.

Quantity Relation
Specifies whether the conversion factors for the units of measure in conditions of this type can be changed during document processing

Item Condition
Condition applies to items
Procedure
Mark this field if the conditions of this type are allowed to be entered in the document items. The condition is then only valid for the particular item in which it is entered.

Delete
Indicator that controls whether the condition type can be deleted from the document.


Value & calculation Type
Value
Specifies whether the value of the condition type can be changed during document processing.

Calculation Type
Specifies whether the calculation type for the condition type can be changed during document processing.



Master Data
Valid From
Ø  Proposed starting date for the rebate validity period
Ø  Specifies the beginning validity date that the system automatically proposes when you create a rebate agreement of this type.
Ø  Example
Ø  You can, for example, specify that the system proposes the first day of the current week, month, or year.
Ø  Procedure
Ø  If you want the system to propose the current date, leave the field blank. Otherwise, enter one of the values predefined for your system.

Valid To
Ø  Date proposed as valid-to date
Ø  Proposed value for how long a condition should remain valid.
Ø  Use
Ø  The system proposes this value for the Valid to date when you create condition records.






Pricing procedure
Ø  Sales and Distribution: Pricing Procedure in Pricing
Ø  Determines which condition types can be used in a document and in which sequence they appear.
Use
Ø  The system uses the pricing procedure that you enter here to control the use of condition supplements in records of this condition type. You can apply the discounts that are defined in the pricing procedure as condition supplements during pricing.
Procedure
Ø  Enter one of the predefined pricing procedures that control condition supplements. If you leave the field blank, the condition supplement function in the screens where you maintain the corresponding condition records is inactive.
Example
Ø  You define a pricing procedure to control a condition supplement for a material price. The condition supplement specifies discounts that you want the system to apply every time the system accesses a material price condition record. When you define the condition type for a material price, you enter the pricing procedure that you defined for the condition supplement.

Delete from database
Ø  Condition records should be deleted from the database
Ø  You can use this indicator to control how the system operates when deleting condition records.
Ø  You have the following options:
Ø  SPACE: You can set an indicator so that the condition record is no longer used in pricing. The condition record is then archived in the archiving run.
Ø  A: You can delete the condition records from the database. You then receive a popup, asking whether the condition record should actually be deleted or whether the deletion indicator should simply be set.
Ø  B: You delete the condition records from the database. You only receive a popup if there are condition supplements available.


Reference Condition Type
Ø  Reference condition type
Ø  A condition type which can be used as a reference so that you only have to create condition records once for condition types that are very similar.
Ø  Use
Ø  You may need to use different condition types for the same condition. These can differ in the access sequence, the description, the reference stage of the pricing procedure or the calculation type, for example.
Ø  You can enter the condition type under which the condition records are created.
Ø  Example
Ø  Condition type MWSI only differs with condition type MWST in the calculation type. For this reason and entry is made in field Reference Cond Type MWST for condition type MWSI. Now, condition records only need be created for condition type MWST and not additionally for MWSI.
Ø  Dependencies
Ø  Field Ref Application is used to refer to condition records from other applications.













You only have to create condition records once for condition types that are very similar. You can also refer to condition records from other applications.

Access Sequence

Ø  Define Access Sequences
Ø  You define access sequences in this IMG step.
Ø  The access sequence is a search strategy which the SAP System uses to search for condition records valid for a condition type.
Ø  For example, you can define for a price that the SAP System first searches for a customer-specific price and then for a price list price.
Ø  Recommendation
Ø  If you define your own access sequences, the key should start with the letter Z since SAP reserves this letter for the standard system.
Ø  Do not change access sequences contained in the standard SAP R/3 System.
Ø  Actions
1.   Check to what extent you can use the access sequences contained in the standard SAP R/3 System.
2.   Create new access sequences by copying a similar access sequence and changing it according to your needs. Specify an alphanumeric key which may have up to 4 digits and a textual description
Access sequence - Access number
Indicates the number of the access within the access sequence.
Condition table
A combination of fields that defines the key of a condition record.
Use
For each condition type in a pricing procedure, you define an access sequence. The access sequence tells the system where to look for relevant condition records for a particular condition type (a rebate for a specific customer, for example). Each access in the access sequence refers to a condition table. The fields defined in the table (the key) help the system to locate valid condition records.
Ø  Procedure
Ø  When you create a condition table, you specify one or more target fields as the table key. You must also tell the system where to find the value for each target field. You do this by specifying source fields. The source fields are usually the same as the target fields, but they can differ. For example, if the target field "Customer" is part of the key, you can specify that the system uses "Ship-to party" as the source field and takes the value from there.
Ø  Requirement
Ø  Use
Ø  If the requirement is fulfilled (SY-SUBRC = 0), then output determination also takes into consideration output type or the access sequence, for which the requirement has been specified.
Ø  Examples
Ø  A possible requirement would be, for example, that a difference should be made between document currency and local currency.
Ø  Indicator: Exclusive condition access
Ø  Controls whether the system stops searching for a record after the first successful access for a condition type within an access sequence.
Fields in Access Sequence

Field for condition table
Name of the field from the condition record.
Definition
The symbols are used to display how the document data is used in the condition access and how the data determined in the access is transferred back to the document. Arrows indicate the direction of the data transfer, the equal sign stands for an access with a direct value. The tools indicate that the data transfer must be ensured when setting up pricing by adapting the system using formulas and requirements. The green LED indicates automatic processing and a red LED marks a line, where data for correct processing is missing. 
Table name of the document structure
Specifies an internal table in which condition information about documents is stored

Fields in Access Sequence
Table field for document structure
Ø  Determines the data dictionary characteristics for new fields in data dictionary structures.
Use
Ø  Reference fields are necessary for the generation of data dictionary structures for conditions and information structures. A reference structure and a reference field must always be entered.
Long Field Label
Definition
Ø  One of the following:
- Short field label
- Medium field label
- Long field label
Can be assigned as prefixed text to a screen field referring to the ABAP Dictionary. The text is displayed on the screen in the logon language of the user (if the text was translated into this language).
Ø  A heading can be defined to output the field values in lists. This heading is automatically included in the list header row, in the logon language.
Source of constant
Ø  Value which the system automatically assigns to a field when it accesses the condition record.
Dependencies
Ø  A field can contain either the value of the source field or the value of a constant (a direct value).
Characteristic: Initial value allowed
Ø  The initial indicator has two functions within Customizing for access sequences. Firstly, it controls that the system does not access the condition if the field in the document header/item is blank or 0. Secondly, during automatic return transfer of data that were determined in the access, it allows an initial value to be returned
Processing type in access
Definition
Ø  The processing type determines how the corresponding field is used for the access. The field can be marked as belonging to the fixed/free key part or else as not relevant for the access.
Ø  Fields that are defined as data fields for the definition of condition tables are automatically marked with an access type.

Define and assign pricing procedure

Ø  Define And Assign Pricing Procedures
Ø  You define the pricing procedures in this step. In addition, you assign the pricing procedures to the transactions by defining the following dependencies:
Ø  Customer
Ø  Sales document type
Ø  Sales area
Ø  In the pricing procedure, you define which condition types should be taken into account and in which sequence. During pricing, the SAP System automatically determines which pricing procedure is valid for a business transaction and it takes the condition types contained in it into account one after the other.
Ø  The determination of the procedure depends on the following factors:
Ø  Customer determination procedure
Ø  You specify the customer determination procedure in the customer master record for each sales area.
Ø  Document pricing procedure
Ø  You specify the document pricing procedure for each sales document type and billing type.
Ø  To determine the procedure, you allocate the customer determination procedure and the document pricing procedure to a pricing procedure within a sales area.
Ø  SAP Recommendation
Ø  Define your own pricing procedures which contain only those condition types which you use. Otherwise, the system makes unnecessary accesses to conditions.
Ø  Do not change the pricing procedures contained in the standard SAP R/3 System.
Actions
Ø  Create new pricing procedures by copying a similar pricing procedure.
Ø  Specify a key with up to 6 characters and a description.
Ø  For a procedure, specify the condition types in the sequence of their usage.
Ø  Maintain the lines of the pricing procedure
Ø  Afterwards define the customer determination procedures for determining the procedure.
Ø  Define the document pricing procedures for determining the procedure.
Ø  Assign the procedure to the sales document types and billing types.
Ø  To determine the procedure, define the allowed combinations of:
Ø  Sales area
Ø  Customer determination procedure
Ø  Document pricing procedure
Ø  Pricing procedure
Check settings
Ø  You can check the settings for your pricing procedures. This is not a complete check. It mainly checks the requirements and calculation formulas for standard condition types. Refer to the report documentation for more information.

Maintaining Pricing Procedure

Procedure (pricing, output control, acct. det., costing,...)
Specifies the conditions that are allowed for a document and defines the sequence in which they are used.
Example
Procedures are used, for example, in the following applications:
         Pricing in sales and distribution
         Applying overhead in Product Costing (costing sheets) and for CO internal orders
         Calculating accrued costs in Profitability Analysis
         Output control (printed confirmations, EDI messages, electronic mail)
         Account determination
         Calculating taxes on sales/purchases
         Calculating accruals in Cost Center Accounting
         Pricing for resource planning
Pricing type
         Specifies how the system treats pricing data when copying documents.
         At the time of billing, the following pricing types are possible:
         A: Copy pricing elements and update according to scale. The system
         does not determine any new condition types
         predetermines the scale prices for changed delivery quantities
         B: Carry out completely new pricing. The system
         carries out a completely new pricing (manually entered pricing elements are not copied from the reference document)
         redetermines the taxes
         C: Copy manual pricing elements and carry out a new pricing for the others.
         The system carries out a new pricing, copies the manually entered pricing elements, Redetermine the taxes

16 Steps in Pricing Procedure


Step number
Number that determines the sequence of the conditions within a procedure.
Condition counter
Access number of the conditions within a step in the pricing procedure.
Use
During automatic pricing, the system takes into account the sequence specified by the counter.


Condition type
The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate between different kinds of discount; in output determination, between different output types such as order confirmation or delivery note; in batch determination, between different strategy types.
From reference step (for percentage conditions)
Condition step, the value of which is the basis for percentage surcharges.
If you specify a to reference step at the same time, the condition values of the two steps specified and the conditions values of the steps in between are totalled. In this case, percentage surcharges are calculated on the basis of the total.
Example:
Level CType Description FromSt ToSt ActKy
10 A-B1 Wages
20 A-B2 Salaries
30 A-B3 Overtime/Wages
40 A-Z1 Vacation bonus 10 30 E11
The surcharge for step 40 is added to the total of steps 10 to 30.
To reference step (for percentages)
Condition step up to which the condition values of the previous steps are totalled. Percentage surcharges are calculated on the basis of the total.
If you specify a from reference step at the same time, the condition values of the two steps specified and the condition values of the steps in between are totalled.
Example:
Step CType Description FromSt ToStep AcctKey
10 A-B1 Wages
20 A-B2 Salaries
30 A-B3 Overtime/Wages
40 A-Z1 Vacation bonus 10 30 E11
The surcharge for step 40 is added to the total of steps 10 to 30.
Condition determined manually
Use
Conditions, that are given this indicator in the pricing procedure, are only included in determination (price determination, output determination, batch determination) either if they are entered manually, for example, on the condition overview screen in Pricing or if they are transferred from an external process, such as costing.
Condition is mandatory
Indicates whether the condition is mandatory when the system carries out pricing using this pricing procedure.
Example
If, for example, you always want to include a tax condition (VAT or sales tax) during pricing, you can set this indicator for the appropriate tax condition type.
Condition is used for statistics
This indicator causes a surchage or discount to be set in the document statistically (that is, without altering the value).
Print ID for condition lines
Controls issue of condition lines when printing documents such as order confirmations or invoices.
Use
In releases previous to 4.0, the following print indicators are available :
' ' : Condition line is not printed
'X' : Condition line is printed at item level
'S' : Condition line is printed in totals block
The following standard logic is set out for these printing indicators:
Item POS of the last condition line is determined with 'X'.
All condition lines that contain an item smaller than POS in the pricing procedure are only printed if print indicators 'X' or 'S' are set.
All condition lines that contain an item larger than POS in the pricing procedure, that come before the first tax condition line and which have a non-statistical VAT condition, receive printing indicator 'S'. The same applies for condition lines that contain an item larger than POS in the pricing procedure, that come after the first tax condition line and an active non-statistical VAT condition.
Condition lines that represent a tax condition type are always printed in totals blocks with print indicator 'S' (set internally or externally).
Condition lines that represent a condition type that is not a tax condition type are only printed with print indicator 'S' (set externally or internally) if the condition value of the condition line is not zero. Condition lines that do not represent a condition type (i.e. subtotals) are only printed with print indicator 'S' or 'X' (set externally or internally) if the condition value of the condition line is different from the condition value of the previous condition line in the pricing procedure.
To provide a better overview of this process, 8 more print parameters are available as of Release 4.0. These print indicators cannot, however be mixed with the three previous print indicators ' ', 'X' and 'S' in the pricing procedure. This means that the new indicators are only taken into account if a no condition lines in the pricing procedure contain printing indicators 'X' or 'S'.
The new printing indicators have the following settings, and corresponding influence on processing.
'A' : in total: general
'B' : in total: if value <> zero
'C' : in total: if value <> value of predecessor
'D' : in total: if value <> zero and value <> value of predecessor
'a' : at item : general
'b' : at item : if value <> zero
'c' : at item : if value <> value of predecessor
'd' : at item : if value <> zero and value <> value of predecessor
Condition subtotal
Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.
Use
If the same fields are used to store different condition amounts, the system totals the individual amounts.
Example
These condition amounts or subtotals are used as a starting point for further calculations. You may, for example, want a subtotal of all the discounts included in the pricing of a sales order.
Requirement
Use
If the requirement is fulfilled (SY-SUBRC = 0), then output determination also takes into consideration output type or the access sequence, for which the requirement has been specified.
Examples
A possible requirement would be, for example, that a difference should be made between document currency and local currency.
Condition formula for alternative calculation type
Alternative formula to the formula in the standard system that determines a condition.
Alternative formula for condition base value
Formula for determining the condition basis as an alternative to the standard.
Example
An absolute header discount is, for example, distributed in the standard system according to the cumulative value of the items.
If the system, however, distributes the absolute header discount according to volume, a header discount of $30 results in the following discounts:

Item       Value               Volume                          Discount
                                                                  Stand. disc.   Volume disc.
  1          $1000              2 cbm                            $20             $10
  2          $500                4 cbm                            $10             $20
Account key
Key that identifies different types of G/L account.
Use
The account key enables the system to post amounts to certain types of revenue account. For example, the system can post freight charges (generated by the freight pricing condition) to the relevant freight revenue account.
Account key - accruals / provisions
Key which identifies various types of G/L accounts for accruals or provisions.
Use
With the aid of the account key, the system can post amounts to certain types of accruals accounts. For example, rebate accruals which are calculated from pricing conditions can be posted to the corresponding account for rebate accruals.

Define Customer Pricing Procedure

Pricing procedure assigned to this customer
Determines which pricing procedure the system should apply when you create a sales document for the customer.

Use
You can define different pricing procedures for your system. A pricing procedure determines the type and sequence of conditions that the system uses for pricing in, for example, a sales order.






Document Pricing Procedure



The key that specifies the pricing procedure for this type of sales document.
Use
During pricing, the system determines the pricing procedure by taking into account
          The sales area
          The pricing procedure key in the header of the sales document type
          The pricing procedure key in the customer master record
The pricing procedure determines how the system carries out pricing for a particular sales document (for example, which pricing condition records it accesses and in which sequence).

Pricing procedure determination


















Labels: