1.

Pricing - Technical Information and Aproach for Pricing Problems

190742599

Add Comment Tools View Comments Notify Moderator Request Points Attachments (4) Page History Restrictions Favourite Watch Stop Watching Watch Page Family Info Link to this Page View Wiki Markup

Pricing - Technical Information and Aproach for Pricing Problems

Link to this Page Link Tiny Link OK Wiki Markup Cancel Close Click to select the Move Page Pric Search Error reading the

Set Page Location Move Recently View ed

There w ere no re Know n Location You must make a

The specified pag Brow se Failed to retrieve

You could try relo HTTP Status Move failed. Ther ERP SCM Unknow n user or 189891721

There w ere no pa Show ing <b>{0}< ERPSCM Reorder Close Move Save

You cannot move Pricing - Technica Pricing in MM-PUR You cannot move Page Ordering Page Restrictions Editing restricted Back Cancel

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

view

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 KOMP Item communication structure, filled by Function Module ME_FILL_KOMP_PO ME_FILL_KOMP_IN KNUMV KONV Annn KONH KONP KONM KOMW Field in the PO Header (EKKO), link to KONV table All item conditions, Datebase table Conditions tables Conditions (Header) Conditions (Item) Conditions (1 Dimensional Quantity Scales) 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. -> number ranges for display of the ranges and the current number. Transaction

SNRO Maintenance of number range object (KONH, KONV), display the number range object, use -> goto

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

Master Conditions

Master conditions have the following properties: a. b. c. d. Have validity periods Have access sequence Can have scales 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. b. c. d. e. Only 1 gross price condition along with the supplemental conditions defined in the pricing Only 1 header condition along with the supplemental conditions defined in the pricing procedure, Can have different validity periods Pricing can only handle one validity period at a time. This is why you must exit a contract or When copying RFQs with multiple validity periods only one period can be copied. procedure, which is assigned in this condition, may be used for item conditions. which is assigned in this condition, may be used for header conditions.

inforecord to process or view a second validity period.

How item condition and header condition are determined for Contracts and Schedule agreements using master conditions: a. b. c. Item condition condition table 016 or 068 is used to determine which condition type should be used for the gross table 016 is Contract Item, table 068 is Outline Agreement Item: Plant-Dependent (plant conditions in standard PB00 is used with supplemental pricing procedure RM0002. Header condition Condition table 019 is used to determine which condition type should be used for header table 019 is Contract Header in standard RA01 is used with supplemental pricing procedure RM0001. The pricing procedure to be initially searched is found the same as Purchase Orders from the

price item condition. for central contract).

condition.

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. on. b. c. d. e. No update from the PO. Only the PO history and last PO are updated to the inforecord from the PO. If no inforecord is entered then no last PO data can be obtained. If pricing conditions are in the inforecord then pricing is taken from the inforecord. If no pricing conditions are in the inforecord then pricing conditions from last PO are brought over. If freight is stored in the previous PO the freight value for that PO is brought over for the current If new conditions have been entered in the pricing procedure since the last PO you may see the (see note 13127). Conditions in inforecords are entered manually or updated from a quote if the update inforec flag is

A new pricing must be performed to get the correct condition values for the current PO. PO. The correct price will be determined when the new pricing is performed. 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 In configuration transaction OMED & OMEA (define document type) the field T161-STAKO should 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. conditions). be flagged if the user what to use master 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 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. GAU2 Access sequence Need condition record Uses unit conversion from GAU1 to calculate price of Gold. Example If Gold price included PB00 GAU1 GAU2 $100.00 - 10.00 + 10.00 -----$100.00 + 10.00 -------$110.00 If Gold price excluded $100.00 Ex: 1 KG = 1 GAU

changed in the inforecord.

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. 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 If no Group condition routine is specified in the condition type then the material number becomes Example of how a group condition works: In condition PB00 the exclusive flag is set. If a condition record is found from PB00 then a flag is

inforecord can be used to group the materials. the group used.

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

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

Statistical flag in Pricing Procedure 1. 2. 3. There are 3 prices in the pricing procedure Basic price Net price - Basis price [- Rebates/+ Surcharges] - non-statistical conditions only Effective price - Net price [+/-] Delivery cost - contains statistical conditions as well as nonStatistical conditions post in Material Document (FI) to accounts specified by the ActKey in the Freight conditions should be flagged as accrued in the condition type. This makes these statistical statistical conditions pricing procedure. 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 If a manual Condition type (no access sequence) but not flagged manual in Pricing procedure, it in the Purchase Order. Must be entered manually. 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 filled

call function 'rv_condition_maintenance' Popup is generated, if there are more then one validity period form 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 record The 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 info_kond_erzeugen_kont info_kond_erzeugen_angb kont_kond_erzeugen_man kont_kond_erzeugen_beleg of document conditions (RFQ) of conditions of a contract of a RFQ with master conditions of manually entered price of conditions of a RFQ

Master conditions in a contract are generated by the programs

The conditions are copied by form call_condition_copy and the function module rv_condition_copy. kont_kond_erzeugen_kont kont_kond_erzeugen_info kont_kond_erzeugen_kont_kopf of contract of inforecord of contract for header

The 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 Function module pricing is called. preisfindung_vorbereiten function module pricing

preisfindung

Program is called with parameter prf_calct (B = for new pricing, A= pricing after e.g. change of quantity).

The communication structures KOMK and KOMP are filled, which are exported to 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 into TKOMV (using the value KOMK-KNUMV) xkomv_aufbauen_aus_komt1 Builds XKOMV from KOMT1 derived from T683S (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 --> 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 header conditions 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_uebernahme preisfindung_complete The data of structure KOMP and table TKOMV are taken into table EKPO. is 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_best Copys 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 determines the FI tax conditions

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_taxes condition 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 RM06E-SKONDI document conditions master conditions

From these modules, the programs of MM06EFSK and MM06EFKO are called for condition maintenance

Communications structure for export to pricing: KOMK KOMP KOMG for header data for item data (allowed fields for condition structures)

Funktion group MEKO: Key fields of KOMG, KOMK, KOMP are filled by... LMEKOU37 LMEKOU26 LMEKOU27 LMEKOU36 LMEKOU24 LMEKOU25 ME_FILL_KOMG_IN ME_FILL_KOMK_IN ME_FILL_KOMP_IN ME_FILL_KOMG_PO ME_FILL_KOMK_PO ME_FILL_KOMP_PO ... for purch. document ...for inforecord

Some more important function groups: MMPR MEPR EINR Dynamic Price Determination Price Computations Read Purchasing Document and

The function modules MM_CURRENT_PRICE_DOCUMENT

MM_CURRENT_PRICE_INFORECORD of function group MMPR are called for 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 be I_KOMK = E_KOMK (for the header) resp. I_KOMP = E_KOM{*}P (*for the item) There are 2 User-Exits: ZXM06U14 for KOMK ZXM06U15 for KOMP Key fields for reading table A017 (example): KOMK-LIFNR KOMK-EKORG KOMP-MATNR 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: SAPMV13A MV13AF0K (breakpoint at konditionen_ordnen for some analysis, determines net price) SAPLV14A SD document conditions: SAPLV61A LV61AU14 SAPMV61A Important notes: 17338 ME21 ME31 'Please enter net price'

29661 20269 28437 41119 156230 94443

E06669/E06658 No condition types found Condition type NAVS: non-deductible input tax 06658 Not possible to determine a condition type Q&A - Explanation of req. & formulas for pricing Requirements: What is permitted, what is not? 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Check which pricing procedure is used (Header > Statistics > General) Condition Analysis (Item > Conditions > Analysis > Details) Check for 2 condition types for prices (PB00 and PBXX in procedure) Check for subtotals 1 & 2 (in procedure) A lot of condition checks in access seq. and formulas reduce performance Order inside a step is important (in procedure) Check statistical flag (in procedure) After PUT -> check access sequences inforecord flagged for deletion? Inconsistencies after client copy (contents of Axxx transported, but no KONxx) Changing of old conditions in inforecord (conditions of inforecord) Standard quantity in inforecord/contract (rounding errors) Conversion factors in inforecord (Conditions > Details > Extras > Conversion factors) Check for first scale to start at 0 Check for freight conditions on header changed after goods receipt User-exit empty User-exit (move import-par to export-par) Check for procedure maintained for condition type PB00 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 daily fluctuations in ruling rates. It causes the price for the material to be redetermined according to the days ruling price at the time a purchase order is created or a goods receipt posted. In the case of the 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 of measurement) _ Set up two new condition types (Purchasing _ Conditions _ Define price determination process _ Define condition types) _ Make new entries in the calculation schemas Purchasing _ Condition _ Define price determination process _ Define calculation schema) The settings for one precious metal are supplied in the standard system. If further precious metals are to be taken into account in the price determination process, they must be set up beforehand in Customizing. You can use the settings supplied in the standard system as a reference for copying purposes. Non-Dimensional Unit of Measurement You must create a unit of measurement that links the precious metal with the unit of measurement. (E.g. GAU for gram of gold). (G stands for gram and AU is the symbol for the chemical element gold.) The proportion of the precious metal is specified for this unit of measurement 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 Schema The two new condition types must be included in the document schema. Document schema RM0000 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 Price Document schema RM0002 is available in the standard system. Here you must enter the first condition type (GAU1). The Statistical indicator must be set.