My clients’ pricing procedures come in all shapes and sizes — from the bizarrely complex to Spartan simplicity. I also find a huge variance in the number of procedures. I was in a system the other day whose procedures numbered in the DOZENS. All of this got me to thinking about the standard SAP pricing procedures and how their structure and rationale may help with inspiration to stick with the standard structure.
Being a US-based SAP consultant, it makes the most sense to look deeper into standard pricing procedure RVAJUS — “Standard – USA /With Jur.Code”. This is the procedure intended for the US
market which utilizes the Jurisdiction Code customer attribute to determine taxes on Sales and Billing Documents. But, don’t worry: many of the other pricing procedures use a similar approach.
SAP Pricing Procedures Structure
If you look carefully, you’ll notice that the procedure is divided into several blocks of “Steps”. Each block is punctuated with a sub-total — a line which does not contain a Condition type, but rather only a text description of the sub-total. In many cases, these sub-totals also have what’s called a Condition Subtotal in the ‘SuTot’ field. The values in the SuTot column correspond to particular fields in the KOMP structure and are subsequently used in other functions and calculations.
The table below walks you through the different sections and the rationale for each:
| From Step | To Step | Description | Sub-total | Sub-total Description |
| 1 | 100 | This is where you define your main price — a.k.a. your base price. | 1 | Line 100 contains the ‘Gross Price’ sub-total which is stored in field KOMP-KZWI1. |
| 101 | 300 | In this block of steps you define the discount that are to be included in your net price calculation. These can also be considered your pre-rebate discounts since these will be taken into consideration for the rebate calculation. | None | None |
| 301 | 400 | This section contains a few random conditions: NETP is used to handle rounding differences, PN00 is a manual condition allowing a user to overwrite a system-derived Net Price, and PMIN validates that the Net Price does not fall below the specified minimum for an item. | 7 | ‘Carry over value to KOMP_BONBA (rebate basis 1)’. The amount in this subtotal is what your rebates will be keying off of. It is important to consider which discounts and surcharges should be included in the Rebate calculation and which should be excluded. Those EXCLUDED should come after this subtotal. |
| 401 | 800 | This section does not contain any conditions. Instead it contains a single Subtotal. | 2 | ‘Carry over value to KOMP-KZWI2’. This subtotal becomes the Net Value for the item. |
| 801 | 900 | This group includes additional discounts and surcharges which occur after your rebate calculation and customer/material discounts are taken (post-rebate). Many of the standard conditions in here are related to shipping. | 3 | ‘Carry over value to KOMP-KZWI3’. The ‘Net Value 2’ subtotal consists of the previous ‘Net Value’ calculation with those additional discounts and surcharges placed on top. |
| 901 | 920 | This block includes mostly Rebate Calculations (based on the Rebate Basis) and Taxes. Intercompany prices are also determined in this group. | A | ‘Carry over price to KOMP-CMPRE (credit price)’. The amount stored in this subtotal field is considered when performing the credit check on the customer. |
| 921 | 950 | Consisting entirely of statistical conditions you’ll find ones relating to Cost and Discounts relating to customer payment terms. | None | None |
| 951 | 999 | The final group does not contain a subtotal. It is only the EDI-related conditions. These are also statistical. | None | None |
You should begin seeing how the standard procedure is engineered. In short, you see the following emerge:
- Establish your base price.
- Define customer/material discounts.
- Set your Rebate value.
- Define additional discounts relating to shipping.
- Calculate Rebates and Taxes.
- Lastly, consider all other supporting conditions and validations.
TWEAKING
Though this process makes sense on a general level, it may not always jive with business processes. Certainly, rebate calculations vary greatly by company. Perhaps you are a service-based company with little need for freight-related conditions. That’s ok. I would still recommend making use of these standard procedures as a guide for your custom ones. Here’s why.
- Just because you have conditions in your pricing procedure doesn’t mean you have to use them. Don’t need those freight conditions? Just leave them in. It doesn’t hurt anything by doing so.
- Besides, you may need those conditions (or similar ones) in the future. Just because you don’t issue rebates now doesn’t mean you won’t want to down the road. In fact, it will be quickly to implement such processes with those conditions already in place.
- At a bare minimum, it helps those familiar with the standard layout (read: guys and gals such as myself) quickly understand your processes and relate your pricing procedures to the baseline.
And if you’re afraid that your Pricing Procedure will look a little too crowded, don’t fret. In addition to the “Steps” in the procedure, you also have the “Counter” column which gives you a second layer of sequencing. This makes the procedure scalable to fit a slew of new pricing conditions. 999 steps multiplied by up to 99 counters equals a maximum of 98,901 rows in your pricing procedure. PLENTY of room!
CONCLUSION
So, fear not! Copy existing SAP Pricing Procedures into your new procedures and tweak as needed. Use those ‘counters’ to shoehorn new conditions in where needed. And feel good about utilizing best practices.
Great job Michael!! I learned something new from your post!!!
Thanks, Karen! I hope all is well up there.
Question: Do you consider “attribute-based” pricing as a sub-case of the standard pricing (with the attributes being modelled accordingly in the condition tables), or as something different altogether (which may then require BRIM/Hybris or other components)? Thank you.
Thanks for commenting, hc. Interesting question. If you are referring to the material product attribute fields (i.e. MVKE-PRAT1), then I would argue that it’s standard. I believe those fields are already included in standard pricing structures. If you’re referring to characteristics and classifications, then I would say that’s less standard due to the fact that you have some work ahead of you.