1. Pricing - Technical Information and Aproach for Pricing Problems

Add Comment

Tools View Comments Notify Moderator Request Points Attachments (4) Page History Restrictions Favourite Watch

Watch Page Family Info Link to this Page… View Wiki Markup

Pricing - Technical Information and Aproach for Pricing

Problems

Page restrictions apply Attachments:4 Added by Arminda Jack, last edited by Arminda Jack on May 24, 2010  (view change)

PRICING PROCEDURES 

Content:    

-         Tables used -         Flow chart -         Master Conditions and Document Conditions -         Precious Metals -         Miscellaneous -         Analysis approach for pricing problems   

Tables used for pricing -         KOMK           Header communication structure,  filled by Function                                Module ME_FILL_KOMK_PO                                Module ME_FILL_KOMK_IN

190742599

Link to this Page Link Tiny Link Wiki Markup Close Move Page – ‘Pric

Set Page Location Move OK Cancel Click to select the Search

Recently View ed There w ere no re Know n Location The specified pag Brow se Error reading the

You could try relo HTTP Status You must make a Failed to retrieve There w ere no pa Show ing <b>{0}<

Move failed. Ther You cannot move Pricing - Technica Pricing in MM-PUR ERPSCM

ERP SCM You cannot move Page Ordering Back Reorder Move

Unknow n user or Page Restrictions Editing restricted Cancel Close Save

189891721

view

 -         KOMP           Item communication structure, filled by Function Module                                ME_FILL_KOMP_PO                                ME_FILL_KOMP_IN -         KNUMV          Field in the PO Header (EKKO), link to KONV table -         KONV            All item conditions, Datebase table -         Annn             Conditions tables -         KONH            Conditions (Header) -         KONP             Conditions (Item) -         KONM            Conditions (1 Dimensional Quantity Scales) -         KOMW           Conditions (1 Dimensional Value Scales)

 Tables KOMK and KOMP are the communications structures for the Access Sequences. Condition tables are linked to time dependent condition records by field KNUMH in condition table.          The field KMUNV in the header of the Purchase Order links conditions in table KONV to the PO.     

                                                                

Flow chart for pricing configuration (OMER)                                                               

                                                                                                             

Flow chart for condition tables (Master conditions)

            

Flow chart for Document Conditions

                                                             

KONV-KPOSN corresponds EKPO-EBELP,KONV-KPOSN = 000000 means a header condition Possible Problems:

Copy of a client: table KONV has been copied, but not the status of the number range.         Transaction  SNRO Maintenance of number range object (KONH, KONV), display the number range object, use -> goto -> number ranges for display of the ranges and the current number.  

Link for Document Pricing Procedure and Supplemental conditions for Gross price 1.       RM0000 - standard Pricing Procedure for Document pricing 2.       RM0002 - standard Supplemental Pricing Procedure   

        

                                        

Master Conditions

Master conditions have the following properties:a.     Have validity periodsb.     Have access sequencec.      Can have scalesd.     Do not have subtotals on pricing screen

Contracts are considered master conditions; therefore, no automatic pricing.  Must enter conditions to be used in the contract.a.     Only 1 gross price condition along with the supplemental conditions defined in the pricing procedure, which is assigned in this condition, may be used for item conditions.b.     Only 1 header condition along with the supplemental conditions defined in the pricing procedure, which is assigned in this condition, may be used for header conditions.c.      Can have different validity periodsd.     Pricing can only handle one validity period at a time.  This is why you must exit a contract or inforecord to process or view a second validity period.e.      When copying RFQs with multiple validity periods only one period can be copied.

How item condition and header condition are determined for Contracts and Schedule agreements using master conditions:a.     Item condition-         condition table 016 or 068 is used to determine which condition type should be used for the gross price item condition.-         table 016 is Contract Item, table 068 is Outline Agreement Item: Plant-Dependent (plant conditions for central contract).-         in standard PB00 is used with supplemental pricing procedure RM0002. b.     Header condition-         Condition table 019 is used to determine which condition type should be used for header condition.-         table 019 is Contract Header-         in standard RA01 is used with supplemental pricing procedure RM0001. c.      The pricing procedure to be initially searched is found the same as  Purchase Orders from the Vendor/Purchase Org combination in transaction OMFO: Define schema determination -> Determine Calculation Schema.  The pricing procedure is searched for an item condition with an access sequence that uses table 016 or 068, depending on the type of contract, and for a header condition that has as access sequence that used table 019.  These two conditions are then used as the item and header conditions for the contract.  Within the condition type a supplemental pricing procedure is stored.  Only

conditions in these supplemental pricing procedures may be used in the Contract.Program MM06EFSK form Kopf_konditionen is where the header condition routine can be found.

Inforecords are Master conditions.a.     Conditions in inforecords are entered manually or updated from a quote if the update inforec flag is on.b.     No update from the PO.  Only the PO history and last PO are updated to the inforecord from the PO.  (see note 13127).c.      If no inforecord is entered then no last PO data can be obtained.d.     If pricing conditions are in the inforecord then pricing is taken from the inforecord.e.      If no pricing conditions are in the inforecord then pricing conditions from last PO are brought over.  A new pricing must be performed to get the correct condition values for the current PO. -         If freight is stored in the previous PO the freight value for that PO is brought over for the current PO.  The correct price will be determined when the new pricing is performed.  -         If new conditions have been entered in the pricing procedure since the last PO you may see the message on the condition analysis screen; V1008  Condition record exists (removed manually).   Note 27636, an SD note, may help to explain this.   A new pricing must be performed to get the condition into the current PO.  When the PO is saved with this condition the PO will now be the last PO  and since is now contains the condition the error message will not occur the next time.f.       As with the contracts only 1 gross price condition and the supplemental pricing procedure defined in that condition type may be used.  Table 018, 067, 066, 025, 028, and 017 are the condition table used for inforecords. -         In 4.5 there is some configuration for copying from the last PO.  There is also a flag in customizing to use the Manual price as the gross price when getting pricing from inforecord or last PO yet. Path: Material Management -> Purchasing -> Environment Data -> Define default values for buyers -> Set default values  (OMFI)   

Document Conditions

 -         Document conditions have no validity periods. -         Can have subtotals on the pricing screen. -         Pricing conditions in Purchase Orders are considered document conditions.    The conditions are only valid for this document. -         Schedule agreements and RFQ can have Document or Master conditions (time dependent conditions).-         In configuration transaction OMED  & OMEA (define document type) the field T161-STAKO should be flagged if the user what to use master conditions.-         When this flag is set now the schedule agreement  and/or RFQ can have multiple validity periods.-         If this flag is not set then the conditions are consider document conditions.       Precious Metals -         GAU1 & GAU2 are used together for gold.-         If other precious metals are used you need to setup 2 different conditions for each precious metal.-         In condition type you need to flag the condition category with a 'U'.  System is looking for the 'U'. -         In Material and Inforecord store the unit conversion of amount of gold in unit of measure.-         GAU is the gold unit of measure (no dimension)-         EX:  1 KG  =  1 GAU   -  for every Kilogram this is 1 GAU of gold contained.-         When an inforecord is created this conversion from the material master comes over.   It can be changed in the inforecord. -         GAU1-         No access sequence-         Used to carry quantity conversion factor-         If the price of Gold is included in PB00 then the Gold value should be entered in this condition.

-         Make sure the conversion is entered using GAU as the unit of measure.    Ex:  1 KG = 1 GAU -         GAU2-         Access sequence-         Need condition record-         Uses unit conversion from GAU1 to calculate price of Gold. -         Example                      If Gold price included                   If Gold price excluded    PB00       $100.00                                  $100.00   GAU1     -   10.00                                    GAU2     +  10.00                                  +  10.00                   ------                                   --------                   $100.00                                  $110.00 -         Note 24738 "Precious metal surcharges in Purchasing"

 Miscellaneous Information

Condition Category and Gross Price (PB00)-         Important for Basic Price to be flagged as an 'H'.  This is hardcoded.  Can only have 1 Basic price in pricing.-         In condition PB00 the exclusive flag is set.  If a condition record is found from PB00 then a flag is set.-         Condition PBXX should have requirement 5 or 6 set in the pricing procedure.  Requirement 5 and 6 check KOMP-KZNEP.  This field is set by condition type PB00 if a condition record is found.  An 'X' is entered.  Requirement 5 checks if this field is equal to a space.  Requirement 6 checks if this field is equal to an 'X'.  Requirement is probably a better program to use because it checks for the exact data entered by PB00.

Group Conditions-         Conditions can be flagged as a group condition-         In the condition type if a Group condition routine is specified then a condition group defined in the inforecord can be used to group the materials.-         If no Group condition routine is specified in the condition type then the material number becomes the group used.-         Example of how a group condition works:

Header freight with group condition   Header value                           $100.00      Item price      $200.00              25.00      Item price        600.00              75.00

 Header freight with no group condition    Header value                         $100.00       Item price     $200.00           100.00       Item price       600.00           100.00

Statistical flag in Pricing Procedure-         There are 3 prices in the pricing procedure1.     Basic price2.     Net price -  Basis price [- Rebates/+ Surcharges]                           -  non-statistical conditions only3.     Effective price - Net price [+/-] Delivery cost  -  contains statistical conditions as well as non-statistical conditions -         Statistical conditions post in Material Document (FI) to accounts specified by the ActKey in the pricing procedure.-         Freight conditions should be flagged as accrued in the condition type.  This makes these statistical as well.  Freight can be posted in invoice verification under Delivery cost pull downs.

Manual conditions-         In the pricing procedure if a condition is flagged Manual - this condition is not proposed in pricing in the Purchase Order.  Must be entered manually.-         If a manual Condition type (no access sequence) but not flagged manual in Pricing procedure, it will be proposed in the Purchase Order.

Calculation Type-         This is a hardcoded flag in the programs.          B is used for new items & new pricing (new price button)         A is used for changes (e.g. Change of quantity)

-         When the Purchase order is created with reference or the last Purchase order data is used then the conditions from that PO are brought into the new PO.  A new pricing must be performed before the current values for some of the condition types will be realized.

MM-Programs 

Inforecords (Master Conditions): MM06IFKO  form call_condition

KOMK and KOMP get filledcall function 'rv_condition_maintenance'Popup is generated, if there are more then one validity periodform call condition is called again, if there's a valid entry on the  condition screen Master conditions in the inforecord are generated by§  form info_kond_erzeugen_in       Copy of the info recordThe conditions are copied by form call_kond_to_kond_copy and the function module rv_cond_to_cond_copy, called within this routine. The function module imports the value new_record, which is the base for the generation of a new condition record.Within form info_kond_preis_uebernahme the values of KOMP and KOMK are copied into table EINE.    -          form info_kond_erzeugen_man        manually entry of the price The conditions are copied by form call_condition_copy and the function module rv_condition_copy, called within this program. The function module imports the value new_record, which is the base for the generation of a new condition record.

  Purchasing Documents with master conditions: MM06EFSK     Inforecord conditions (e.g. via the indicator 'update info record') are generated by the programs-          info_kond_erzeugen                               of document conditions (RFQ)-          info_kond_erzeugen_kont        of conditions of a contract-          info_kond_erzeugen_angb               of a RFQ with master conditions Master conditions in a contract are generated by the programs-          kont_kond_erzeugen_man                                 of manually entered price-          kont_kond_erzeugen_beleg                of conditions of a RFQ The conditions are copied by form call_condition_copy and the function module rv_condition_copy.                       -          kont_kond_erzeugen_kont                   of contract-          kont_kond_erzeugen_info                   of inforecord-          kont_kond_erzeugen_kont_kopf      of contract for headerThe conditions are copied by form call_kond_to_kond_copy and the function module rv_cond_to_cond_copy. In program kont_kond_preis_uebernahme,the data of KOMP are taken over into the fields EKPO-NETPR,...

 If there are more than one condition type with an access sequence, program kondart_suchen and the function module me_get_conditions_to_search are used, and a popup for the selection of a condition type is generated within the function module.    

      Purchasing Documents with document conditions: MM06EFKO  -          preisfindungProgram is called with parameter prf_calct (B = for new pricing, A= pricing after e.g. change of quantity). Function module pricing is called.-          preisfindung_vorbereitenThe communication structures KOMK and KOMP are filled, which are exported to function module pricing.-          function module pricing

The condition records found within pricing are contained in the internal table TKOMV. This table should be checked first, if there are any problems in pricing.

The communication structures KOMK and KOMP are import parameters as well.

Field KOMP-PRSOK is filled, if no error has been detected within pricing. Programs called from function module pricing:KONDITIONSVORSTEP Import            -->  KOMK   header communication structure                                                                       Export             <-- KOMT1  table of pricing procedure                                                                                       <--  KOMT2  table of condition access sequences                   konv_einlesen reads condition records form KONV and transfer them intoTKOMV (using the value KOMK-KNUMV)xkomv_aufbauen_aus_komt1 Builds XKOMV from KOMT1 derived fromT683S (table for pricing scheme)                                                           -->  KOMK   header communication structure                                                                                   -->  KOMP   item   communication structure                                                                                   -->  KOMT1  pricing procedure                                                                                                -->  KOMT2  accesses                                                                                                         <--  XKOMV  internal table of conditions                            XKOMV_AUFBAUEN_STEUERN    determines the FI tax conditions  -->  TXKOMV conditions for tax                         <--  XKOMV internal table of conditions       XKOMV_AUFBAUEN_AUS_TKOMV builds XKOMV from TKOMV-->  KOMT1  pricing procedure                                     -->  TKOMV  complete table of conditions                          <--  XKOMV  internal table of conditions               XKOMV_AUFBAUEN_KOPFRABATTE builds part of XKOMV from headerconditions in TKOMV                                             -->  KOMT1  pricing procedure                                     -->  TKOMV  complete table of cond. (KPOSN=0)               <--  XKOMV  internal table of conditions                               XKOMV_UEBERTRAGEN_NACH_TKOMV builds TKOMV from XKOMV-->  XKOMV internal table of conditions<--  TKOMV internal table of conditions-          preisfindung_uebernahmeThe data of structure KOMP and table TKOMV are taken into table EKPO. -          preisfindung_completeis called when checking or saving a purchase order. The header conditions are distributed between the positions and a new distribution of the group conditions is done.-          kond_copy_bestCopys the conditions from the last document of an inforecord.The function module rv_konv_select provides the condition records in table rkomv. The program

preisfindung is called again at the end of kond_copy.-          preisfindung_aend

After changes on the item detailed screen, the change_flag is set and the program

preisfindung is called again with parameter 'A' and program preisfindung_staffel_pruefen as well. If there are problems with the update of net price, set a breakpoint in here.§  kond_taxescondition type NAVS; in TKOMV-MWSK1 contains the tax code for field EKPO-MWSKZ.Function modele calculate_tax_item calculates the tax values, provides table taxcom and field HWERT with the value of the non-deductible tax(ekpo-navnw = hwert).Table A003 contains the tax code.

 Program SAPMM06E, PAI-modules (transaction SE80):RM06E-KONDI        document conditionsRM06E-SKONDI      master conditionsFrom these modules, the programs of MM06EFSK and MM06EFKO are called for condition maintenance

 Communications structure for export to pricing:KOMK           for header data          KOMP            for item data  KOMG           (allowed fields for condition structures) Funktion group MEKO:Key fields of KOMG, KOMK, KOMP are filled by...LMEKOU37              ME_FILL_KOMG_IN        LMEKOU26              ME_FILL_KOMK_INLMEKOU27              ME_FILL_KOMP_IN    ...for inforecord LMEKOU36              ME_FILL_KOMG_POLMEKOU24              ME_FILL_KOMK_POLMEKOU25              ME_FILL_KOMP_PO   ... for purch. document

   Some more important function groups:   MMPR            Dynamic Price DeterminationMEPR             Price ComputationsEINR              Read Purchasing Document The function modules MM_CURRENT_PRICE_DOCUMENT     andMM_CURRENT_PRICE_INFORECORD  of function group MMPR  are calledfor display of the current price in e.g. all transactions for display if there several validity periods.

Determination of pricing scheme:ME_GET_PRICING_SCHEME (table TMKS)ME_GET_PRICING_SCHEME_TRANS (table TMKSU) for STO

Some problems with user-exits:The first line of the user-exits have to beI_KOMK = E_KOMK (for the header) resp. I_KOMP = E_KOM{*}P (*for the item) There are 2 User-Exits:ZXM06U14 for KOMKZXM06U15 for KOMP Key fields for reading table A017 (example):            KOMK-LIFNR          KOMP-MATNR            KOMK-EKORG       KOMP-WERKS                                               KOMP-ESOKZ

These fields have to be checked before and after passing the user-exit. If these fields are filled incorrectly within the user-exit, pricing will not work!!!

 Problem, that the net price in a purchasing document gets a negative value - but why??§  Select the document with transaction ME3N, goto -> edit -> price simulation§  transaction MEKA, to see all conditions, can also be maintained directly.

SD master conditions:SAPMV13AMV13AF0K (breakpoint at konditionen_ordnen for some analysis, determines net price)SAPLV14A

SD document conditions:SAPLV61ALV61AU14SAPMV61A

Important notes:17338              ME21 ME31 'Please enter net price'29661              E06669/E06658 No condition types found20269              Condition type NAVS: non-deductible input tax28437              06658 Not possible to determine a condition type41119              Q&A - Explanation of req. & formulas for pricing156230            Requirements: What is permitted, what is not?94443              Inconsistencies in condition master data         Calculation Schema:Column "Condition formula for alternative calculation type"Can be specified if it has been stipulated for the calculation rule for a condition type that the value is to be determined using a formula (transaction VOFM -> Formulas -> Condition value, Source text can be seen/maintained here).In general, calculation formulas are only used in connection with precious metals. Note that large calculation formulas can impose a burden upon system performance.

Column "Alternative formula for condition base value"Can be maintained with transaction VOFM, as well ( -> Formulas -> Condition base value)

If there's a problem with formulas, at first, the formula should be removed and it should be tested, if the problem works fine, without such a formula. A breakpoint can be within the source text of the formula to see, what the program does. (formula are SD-Programs)

      Analysis approach for Pricing problems 1.     Check which pricing procedure is used (Header > Statistics > General)2.     Condition Analysis (Item > Conditions > Analysis > Details)3.     Check for 2 condition types for prices (PB00 and PBXX in procedure)4.     Check for subtotals 1 & 2 (in procedure)5.     A lot of condition checks in access seq. and formulas reduce performance6.     Order inside a step is important (in procedure)7.     Check statistical flag (in procedure)8.     After PUT -> check access sequences9.      inforecord flagged for deletion?10.           Inconsistencies after client copy (contents of Axxx transported, but no KONxx)11.           Changing of old conditions in inforecord (conditions of inforecord)12.           Standard quantity in inforecord/contract (rounding errors)13.           Conversion factors in inforecord (Conditions > Details > Extras > Conversion factors)14.           Check for first scale to start at 0

15.           Check for freight conditions on header changed after goods receipt16.           User-exit empty17.           User-exit (move import-par to export-par)18.           Check for procedure maintained for condition type PB0019.           Negative freight conditions (enter subtotal 3 as from reference step for freight  (value) conditions)                          

Solution is actually very simple. You need to copy the conditions for Gold and use that in your condition types in your PIR. You have to maintain the the price for GAU2 (Actual Price of Gold...in your case steel) everyday with the price of metal whether it is by automation or manually. Some notes below.

Daily Ruling Prices for Precious Metals

There is a separate condition category for pricing components that vary according to dailyfluctuations in ruling rates. It causes the price for the material to be redetermined according to theday’s ruling price at the time a purchase order is created or a goods receipt posted. In the case ofthe PO, the date chosen by you is taken. In the case of a GR, the key date is the posting date.Prerequisites

You must make the following settings for each precious metal in Customizing:

_ Define a non-dimensional unit of measurement (Global settings _ Check units ofmeasurement)_ Set up two new condition types (Purchasing _ Conditions _ Define price determinationprocess _ Define condition types)_ Make new entries in the calculation schemas Purchasing _ Condition _ Define pricedetermination process _ Define calculation schema)

The settings for one precious metal are supplied in the standard system. If further preciousmetals are to be taken into account in the price determination process, they must be set upbeforehand in Customizing. You can use the settings supplied in the standard system as areference for copying purposes.

Non-Dimensional Unit of Measurement

You must create a unit of measurement that links the precious metal with the unit ofmeasurement. (E.g. GAU for “gram of gold”). (“G” stands for “gram” and “AU” is the symbol forthe chemical element “gold”.) The proportion of the precious metal is specified for this unit ofmeasurement in the material master record (e.g. 1 piece of wire = 3 GAU).

Two New Condition Types

1. For the precious metal price portion (GAU1) included in the material price.2. For the current ruling price of the precious metal (GAU2).Both condition types have condition class A, condition category U, and calculation rule C(quantity-dependent), and the same unit of measurement (e.g. GAU) must be assigned to each.An access sequence must be assigned to the condition type for the current daily ruling price(GAU2). In the standard system, access sequence 0001 is defined for this purpose.New Entries in Calculation Schemas

Document SchemaThe two new condition types must be included in the document schema. Document schemaRM0000 is available in the standard system.

The two condition types must be entered in the document schema in the above sequence.Different but directly consecutive steps must be assigned for both. The Statistical indicator may

not be set for either.

The first condition type must be flagged as “manual” and have the calculation formula “31”.The second condition type may not be flagged as “manual”. It must have the calculation formula“32” and the requirement “31”.Supplementary Calculation Schema for PriceDocument schema RM0002 is available in the standard system.Here you must enter the first condition type (GAU1). The Statistical indicator must be set.