Valuation via Pricing Procedure in SD or CO-PA
Valuation via a Pricing
You can also create valuations via pricing procedures that are created in other modules such as SD or directly in CO-PA. Normally, you do not have to include an SD pricing procedure in your valuation strategy if you have maintained the SD interface to CO-PA. However, this may be useful in some cases. Have a look of it, at the Planning in CO-PA. The SD module calculates values itself in its pricing procedure. Via the SD interface, we can access these values and transfer them to CO-PA.
In our simplified contribution margin structure, for two lines we assume that they are filled by valuation: cash discount and rebate.
You grant customers cash discount via the payment terms. If the customer pays quickly, they receive a cash discount. When you enter a sales order, create an invoice, or settle a sales order to CO-PA, you usually only know from experience, whether the customer pays quickly and deducts the cash discount or not. You should create a contribution margin accounting in CO-PA as a worst case invoice, that is, you must assume the worst possible scenario. Specifically, this means that your customer, to whom you grant cash discount, actually deducts cash discount. Usually, in the SD pricing procedure, you create a condition type Cash discount that receives a “statistical” check mark. Here, statistical means that at the time the SD pricing procedure is executed, nothing is posted in FI for cash discount — but the cash discount amount calculated is adopted in CO-PA.
The situation is different for rebates. Let us assume that rebates are granted based on sales quantities or percentages if the customer fulfills specific requirements. Again, you only know whether the customer has earned the rebate once you have issued the invoice to the customer. The worst case principle also applies here (worst case because we have to bear all possible costs). You assume that the customer receives all rebates. We include these in the REBATE value field in CO-PA. These are completely normal calculations of imputed costs that we used to post manually before IT. Correct. In the case of the rebate, you can calculate imputed costs with every invoice if you have entered rebate agreements in SD, have created condition types for them, and have customized revenue account determination in SD. At some point, your customer gets in touch and wants his rebate because he has fulfilled the requirements. The SD rebate agreement is then settled and the customer receives his money. Is the settlement, then transferred to CO-PA? If so, the rebate would be deducted twice in CO-PA — once for the calculation of imputed costs, and once for the settlement. Naturally, you have to avoid this error, but this is not difficult in the costing-based form of Profitability Analysis. You simply transfer the calculation of imputed costs but not the settlement.
How many rebates were granted in period XY in the kind of product PA2 overall, or only in customer hierarchy KH12? You are just one press of a button away from the answer…
If you use the SAP module SD (Sales and Distribution), pricing procedures and condition types are defined there for pricing. SD usually uses these to find the valid prices and conditions for an incoming sales order or for an invoice; in the case of revenues, discounts, or freight, these are usually also posted to corresponding FI accounts automatically.
For our example customizing, we want to show the valuation via SD once for a condition type ZSKT that is indicated as statistical in the SD pricing procedure. This means that the value determined is not posted automatically. However, we still want to display this value in CO-PA.
In the Figure below, we see a relevant extract from the SD pricing procedure that was customized for our example. Note the condition type ZSKT. Do you see the statistical flag?
Presentation of the condition type ZSKT in the SD pricing procedure
Condition type ZSKT is assigned to value field VV070 (Cash Discount) via the SD interface. You make this assignment in customizing for CO-PA (transaction ORKE) via FLOWS OF ACTUAL VALUES • TRANSFER OF BILLING DOCUMENTS • ASSIGN VALUE FIELDS — see Figure below.
In SD, via transaction VK11, you create condition records for condition type ZSKT. For our example, cash discount is granted to three customers (see Figure below).
Cash discount condition records
For a CO-PA-relevant posting, in the Figure, for customer A6 we see that for gross sales of EUR 124 , after deduction of discounts in the amount of EUR 4.99 , the net sales are EUR 119.01. The cash discount amount calculated is EUR 1.20, which is exactly 1% cash discount
Evidence of the valuation of cash discount via SD
Valuation via User Exits As explained in Characteristic Derivation, CO-PA also contains SAP enhancements for the valuation. Again, with your own programming, you can enable valuations that are not available in the SAP standard system. The important thing is that you name the exits in your ABAP coding (for example, U01, U02, etc.) and include these user exit codes in the valuation strategy.
For our simplified Profitability Analysis, we will fill the additional quantity field ALTERNATIVE QUANTITY via user exit. It often makes sense to compare your data with an alternative quantity reference. Examples of quantity references can be hectoliter for breweries, 0.7 liters for spirits, liters for manufacturers of alcohol-free drinks, etc.
You should also consider an alternative quantity factor for your company. Why is that? This is so that when comparing contribution margin accounting later, you can consider contribution margin 1 per HL (or E07 or L or kg, and so on). This enables you to assess precisely how you are doing with your products, customers, or other derived characteristics with reference to an alternative quantity factor, both with regard to actual as well as planned figures, in comparison to previous years, forecasts, etc. Amongst other things, this helps you to find errors in the actual or planning data quickly if at some point you think that your contribution margin accounting is not right…
In our example, we will concentrate on the alternative quantity unit kilogram (kg). You can see the example customizing in Section 0. There, we have seen you to use user exits for characteristic derivation to add the quantity unit of our quantity field ALTERNATIVE QUANTITY. You may also be interested in seeing not only the quantity unit, but also the alternative sales quantity itself.
First, you have to enhance the valuation strategy in order to tell the system that you want to process a user exit (see Figure below).
Valuation strategy with access to user exit U01
To evaluate a CO-PA user exit, you also proceed via the customizing for CO-PA, via TOOLS • SAP ENHANCEMENTS. Create a project and assign component COPA0002. By double-clicking the component, navigate to the Include ZXKKEU03. If you have a developer key in your system, you can fill this Include. You can see the example coding in Figure below.
Actual user exit for valuation of the value field VVAMG
After coding, save, check and activate the include. User exit U01 now has the effect that at the time valuation strategy Z01 is found, the coding of the user exit U01 is processed. In the simple example coding, the SAP system searches in table MARM for the alternative quantity unit KG (kilogram) that you have maintained for each product, as described in Section 0. For example, one unit of the product A1 weighs 100 kg. If you then sell eight units, 800 kg should be visible as alternative sales quantity (see Figure below) (marm-umren = 100/ marm-umrez = 1 * 8).
Evidence of valuation via user exit U01
In the next fields, let us look at how actual and planning data can get into CO-PA.