0% found this document useful (1 vote)
603 views8 pages

How SAP Pricing Works

1. SAP pricing works by calling subroutines that retrieve reference data from master tables and execute pricing procedures step-by-step. 2. It first obtains plant, company code, rounding rules and other header data. It then checks for transaction-specific pricing and loads pricing procedure details. 3. The pricing procedure is then executed line-by-line, checking conditions, requirements, and condition types to determine pricing logic. Conditions are evaluated based on document type, customer, and other attributes.

Uploaded by

juan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (1 vote)
603 views8 pages

How SAP Pricing Works

1. SAP pricing works by calling subroutines that retrieve reference data from master tables and execute pricing procedures step-by-step. 2. It first obtains plant, company code, rounding rules and other header data. It then checks for transaction-specific pricing and loads pricing procedure details. 3. The pricing procedure is then executed line-by-line, checking conditions, requirements, and condition types to determine pricing logic. Conditions are evaluated based on document type, customer, and other attributes.

Uploaded by

juan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

How SAP Pricing Works.

Glossary

Table Field Descrption Values


T685A KOAID Condition Class A Discount or surcharge
(Conditions: B Prices
Types: C Expense reimbursement
Additional D Taxes
Price E Extra pay
Element F Reserved (IS-OIL)
Data ) G Tax Classification
H Determining sales deal
Q Reserved (IS-OIL)
W Wage Withholding Tax

When you enter Material and Quantity and trigger enter, Include SAPLV61A contains FM – PRICING
is called internally.

It fills KOMK , KOMP structures .

As pricing should not get executed in display mode, system check if it’s not display mode and then
proceed.

Next, below Subroutine is called with below format : -

Get you following details: -

1. Read table T001W (Plants) - T001w-WERKS


2. Read table T001K (Valuation area) - T001K-BWKEY using T001W-BWKEY from 1st step .
3. Read table T001 (Company Codes) - using T001K-BUKRS from 2nd Step .
4. Read table T001R (rounding rules for company codes and currencies) – using komk-bukrs
AND KOMK-WAERK.
5. If T001-KUBRS is not same as KOMK_BUKRS  Read table T001 (company codes)– using
KOMK_BUKRS .
6. Read table T604S (preference) using komk-aland_werk (Country From), komk-land1_we
(Country To). Use country information linked to the shipping plant and ship-to partner to
determine the preference zone.
7. Read table TVFK (billing document types) using komk-fkart.
8. Read table T005 (countries) , using T001-land1
9. Read table TTXD (tax jurisdiction codes) , using T005-kalsm .
10. Read Pricing procedure Name.

11. Store the value of T683-BONSM (Transaction-specific pricing procedure ) in variable -


IV_PROCEDURE
12. Load Pricing procedure Details (KOMK-KAPPL = A ) ?? whats the use of 682V table .

13. Set exchange rate type from KOMK-KURST , or default with M .


14. Create internal control table of pricing types for different Pricing Type.
Internal Table - STEU , once filled , looks like below .

15. Calls User Exit – USEREXIT_PRICING_RULE, it can be used if Pricing Rules requires any
change. Internal table – STEU can be changed here. Changing that will change the behaviour
of standard pricing , depending on business needs

16. Now , system get the pricing procedure details like steps , conditions , requirements & etc.

17. Field T683-BONSM (Transaction-specific pricing procedure) is stored in variable –


‘REBATE_PROCEDURE’. This would be used in next LOOP.

18. Loop on table XT683S line by line. This is like moving row by row of pricing procedure.

I. Check the record for Print indicator (field - DRUKZ), if it contains any ‘ABCDS’, assign
the value to KOMK-DRUKS_Z.
II. Check if the condition has any Requirement (T683S-KOBED ).Suppose T683S-KOBED
= 002
 It will field to call the subroutine will be populated as
Bedingung_vorstep = “KOBEV_ + T683S-KOBED”

 And then dynamically called as - KOBEV_002, Prestep would executed.


III. SAP does that as it doesn’t allow subtotals for invoice list and rebate settlement kind
of documents. System checks if the document type is invoice List or Rebate
settlement. Check is made on fields –
 KOMK-VBTYP
 KOMK -KNUMA
 REBATE_PROCEDURE
If yes, check for condition type field value (T683S-KSCHL).
IV. If condition type value exists (T683S-KSCHL), get the data for the condition from
table T685, T685A.

V. Check if its invoice list (KOMK-VBTYPE = ‘34’ ),


 if yes ,
 Check if condition type for invoice list (T685A-KRELI = ‘X’).
 Else
 If condition type is for invoice list (T685A-KRELI = ‘X’).
o Raise Error.
VI. If document order type ( KOMK-VBTYP ) is not orders, credit , memos, debit memos
and invoices , they are not relevant for Condition update , technically , clear the
T685A-KOUPD ( Condition Update ) .
VII. If document order type ( KOMK-VBTYP ) is Intercompany invoice ( 5) or
Intercompany credit memo (6 ) and (Condition Category (t685a-kntyp) is ‘I’ or its
Condition for inter-company billing (T685A-KFKIV )), then condition cant be
statistical , technically , clear the T683S-KSTAT .
VIII. If condition is Rebate condition (T685A-KOAID = ‘C’),
 Check if Rebate Agreement number is empty ( KOMK- KNUMA )
 If it’s not relevant for rebate ( KOMK – BOREL is empty )
o If is SD Application ( KOMK-KAPPL <> 'M ')
 If Rebate processing active in the sales organization
( KOMK-BOAVO )
 If Customer ( Payer ) is to receive rebates (KOMK-
BOAVO )
 If Billing document is relevant for rebate processing
(KOMK-BORVF )
 Flag the fields relevant for rebates -
 T685A-GANZZ (Indicator: Currency
Conversion after Multiplication ) ,
 T685A-KRUEK (Condition is Relevant for
Accrual (e.g. Freight),
 T683S-KSTAT ( Condition is used for
statistics )
 If not any of above, give error.
IX. If reference condition (T685A-RKSCHL) is empty, transfer the condition type to
reference condition, technically, T685A-RKSCHL = T685A-KSCHL.
X. Check Tax Exemption licence with help of field
 Condition Category - T685A-KNTYP is M, 1, 2, 3 & 4 ( KOMT1-KNTYP CA
'M1234' )
 Application is V ( KOMK-KAPPL = 'V ' )
 Ship to Party is maintained ( KOMK-KUNWE )
 Country is maintained ( KOMK-ALAND )
 Condition is not determined manually ( T683S-KAUTO is empty )
 Fill PREISDATUM with date on which services rendered ( KOMK-FBUDA )

XI. If it has access sequence (KOMT1-KOZGF ) and condition is not added manually , Get
the Access Sequence in internal table - XT682I

 Get the tax jurisdiction code.


 Select the condition tables via access sequence (KOMT1-KOXGF).

 Records will look like below.

Loop on XT628I -
 If service rendered date is filled, cond. category in CD, pricing date
characteristic is empty.
o Pricing date = Service Rendered Date (KOMK-PRSDT = KOMK-
FBUDA).
 If pricing date characteristic is A, service rendered date is empty.
o Pricing date = Service Rendered Date (KOMK-PRSDT = KOMK-
FBUDA).
 If pricing date characteristic is C, Billing date for billing index and printout
is empty
o Pricing date = Billing date for billing index and
printout Date (KOMK-PRSDT = KOMK-FKDAT).
 If pricing date characteristic is D, Order Creation date is not empty.
o Pricing date = Order Creation Date (KOMK-PRSDT = KOMK-
ERDAT).
 If pricing date characteristic is E, Document date is not empty.
o Pricing date = Document Date KOMK-PRSDT = KOMK-AUDAT).

 Check if it’s not header condition (T682I-KKOPF is empty)


o Check if value exist in Table XT682V for following fields

XII. If condition is relevant for accrual, make it statistical.

XIII. If Rebate agreement is not maintained ,


 Since Scales are only relevant for rebate conditions in case of rebate
settlement. If Condition Class is not C, clear scales (KOMT1-STFKZ).
XIV. If Rebate agreement is maintained ,
 If Condition Category is either ‘CDG’ - Rebate, Tax, Tax Code or
REBATE_PROCEDURE is flagged.

Now, below subroutine will get execute:-

1. Don’t execute if document condition Number is not available - KOMK-KNUMV.

Now, below subroutine will get execute: -

1. Get the Product Hierarchy.


2. If KOMP translation date is empty, get from KOMK pricing date.
3. - Get the details where from STEU where pricing type = C
4. Loop pricing Procedure for all entries in it.
a. Check requirement assigned to a condition in pricing procedure. If 002 is the
requirement maintained in PP, KOBED_002 should be called.
b. If sy-subrc = 0, all good, else update the error.
c. Collect conditions marked as mandatory for further checks in Table – TOBLI. This is
by checking KOBLI field.
d. Loop on access sequence and checks on “Requirement”.
e. If condition is without access sequence, execute some separate steps.

XKOMV_BEWERTEN

1. Check if condition is inactive, if not do following.


2. If pricing type is not F, do following: -

3. Calculate condition basis -


a) If Calculation type for condition is 'CMNOP' ,
 Get the Quantity.
 Convert quantity from sales UoM into condition UoM
4. Execute condition basis formula if exist.
5. Execute condition update for condition basis
1)

Subroutine – “xkomv_aufbauen_aus_komt1” will perform the condition records fetch. XKOMV is


already filled by now. But the calculation on subtotals has not happened.

Subroutine - XKOMV_BEWERTEN is called to calculate the prices and fetching the condition records
based on few tables – KOMP (containing Item details),

This subroutine, also calls User Exit -“userexit_xkomv_bewerten_init” to change

Check – FM - PRICING_COMPLETE

Glossary

KOAID - Condition class

You might also like