Hierarchy
BBPCRM (Software Component) BBPCRM⤷
CRM (Application Component) Customer Relationship Management⤷
CRM_APPLICATION (Package) All CRM Components Without Special Structure Packages⤷
KPLA (Package) Cost Accounting, planning RK-S
Basic Data
| Data Element | CO_RATMP |
| Short Description | Plan price calculation: Determination method |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CO_RATMP | |
| Data Type | NUMC | Character string with only digits |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | Plan |
| Medium | 15 | Method |
| Long | 20 | Plan price calc. |
| Heading | 2 | PP |
Documentation
Definition
Indicator controlling which price calculation method is used for an activity type.
There are three methods by which prices can be calculated:
1 Price per period
The costs incurred in one period are divided by the activities for the period. This may result in different prices for each period. Given identical fixed costs but different activity quantities, a relatively high price is therefore used to value the activity quantities in periods with a low activity quantity. By contrast, in those periods with low activity input, the activity input is valuated at a relatively low price, because the fixed costs relate to a higher activity quantity.
Example
Per.| Var. Costs | Fixed Costs | Activity | Period. Price
1 | 1.000 EUR | 1.000 EUR | 1.000 h | 2.000 EUR/1.000 h = 2 EUR/h
1 | 1.000 EUR | 1.000 EUR | 1.000 h | 2.000 EUR/1.000 h = 2 EUR/h
2 | 100 EUR | 1.000 EUR | 100 h | 1.100 EUR/100 h = 11 EUR/h
The activity receivers in period 2 are charged more than the receivers in period 1. The price per period is higher in period 2 than in period 1 due to the lower variable costs in period 2. In this period (2), the fixed costs are distributed among a lower activity quantity. Accordingly, the price in period 2 contains a higher fixed percentage than that in period 1.
2 Average price
All receivers are charged the same price irrespective of the period in which they receive the activity.
The total costs of all periods are divided by the total activities (for one activity type) for all periods.
Example
Per.| Var. Costs | Fixed Costs | Activity | Average Price
1 | 1.000 EUR | 1.000 EUR | 1.000 h | not determined
2 | 100 EUR | 1.000 EUR | 100 h | not determined
Total| 1.100 EUR | 2.000 EUR | 1.100 h | 3.100 EUR/1.100 h = 2 ,82 EUR/h
Under this method, the balance for the individual periods does not equal zero, meaning that either:
- Too much (see period 1 where 1000 h x 2.82 EUR/h = 2820 EUR ) or
- Too little (see period 2 where 100 h x 2.82 EUR/h = 282 EUR)
is charged.
3 Cumulative price (only possible in the actual)
Under cumulative calculation, the price for a period is the total of the costs and activities for all periods up to the period under consideration (your entry in the To Period field). This method smoothes out cost fluctuations between periods.
During revaluation under the cumulative method, all those sender objects (in those periods that you specified under period selection for actual price calculation) are credited in full. The activity inputs are valuated with the new price in each selected period. The system makes the necessary additional postings in these periods to ensure this equal valuation.
The cumulative procedure is only possible where all activity receivers in all periods of the interval entered can be posted to. In other words, the period lock must not be active for these objects. You must ensure that this is the case because receivers in the first period can contain equalization postings in the final period.
Example 1: Differences between prices per period and cumulated price
Prices per period: The costs of each period are divided by the activities in question - the prices can vary markedly.
Per.| Costs per. | Activity per. | Price per per.
1 | 1.000 EUR | 100 h | 10 EUR/h
2 | 2.000 EUR | 50 h | 40 EUR/h
3 | 1.000 EUR | 250 h | 4 EUR/h
Cumulative price: The price is determined from the total of the current periods and of the previous periods. For example, the price of period 2 is calculated by adding the costs in periods 1 and 2 (1,000 + 2,000 EUR) and dividing them by the activities for this period (100 + 50). The prices do not fluctuate as much.
Per.| Cum. Costs | Cum. Activity. | Cum.price
1 | 1.000 EUR | 100 h | 10 EUR/h
2 | 3.000 EUR | 150 h | 20 EUR/h
3 | 4.000 EUR | 400 h | 10 EUR/h
Example 2: Revaluation at actual prices
Under revaluation, activity allocations are valuated at actual prices and the difference as against the values already posted is allocated subsequently.
If, under actual price calculation, you enter a range of periods, the system carries out revaluation for every period. The sender objects are fully credited in each period.
If you enter one period only, the subsequent allocation is carried out in this period only, meaning that only this period is fully credited.
Entry: Periods 1 through 3
Per.| Act.costs | Activity | Cum.Actual Price | Plan Costs | Plan Price
1 | 1.000 EUR | 100 h | 10 EUR/h | 500 EUR | 5 EUR/h
2 | 3.000 EUR | 150 h | 20 EUR/h | 750 EUR | 5 EUR/h
3 | 4.000 EUR | 400 h | 10 EUR/h | 2.000 EUR | 5 EUR/h
Per.| Difference Plan/Actual Costs| Revaluation
1 | 500 EUR | + 500 EUR
2 | 2.250 EUR | + 1.250 EUR
3 | 2.000 EUR | - 1.000 EUR
Period 1:
The difference between actual and planned costs is 500 EUR. All receivers are charged this amount - the sender objects in period 1 are credited in full.
Period 2:
The difference between plan and actual costs amounts to 2,250 EUR. Since cumulative values are used in calculation here, the receiver objects are charged 1,250 EUR. The sender objects are still fully credited because 1,000 EUR from the first period have already been allocated to the receiver.
Period 3:
The revaluation results in the receivers being charged 1,000 EUR too much. This amount is credited to the receivers - the sender objects are then credited correctly and in full. How is this total arrived at? The difference between planned and actual costs is 2,000 EUR. In periods 1 and 2, the receivers were charged 1,250 EUR planned costs and 1,750 EUR revaluation, making a total of 3,000 EUR. The difference between plan and actual, however, is only 2,000 EUR - the receivers have been charged 1,000 EUR too much.
Entry: Periods 3 to 3
If, under actual price calculation, you enter period 3 only, the system allocates correctly, but senders are fully credited only in this period. The price calculation program posts only to the period(s) that you enter under From/To Period. 750 EUR is revaluated because although plan costs of periods 1 to 3 are included in the calculation (3,250 EUR), no revaluation took place in periods 1 and 2.
Per.| Actual Costs | Activity | Cum.Actual Price | Plan Costs | Plan Price
3 | 4.000 EUR | 400 h | 10 EUR/h | 2.000 EUR | 5 EUR/h
Per.| Difference Plan/Actual Costs | Revaluation
3 | 2.000 EUR | + 750 EUR
Unlike an average price, which can be defined for either single cost centers/activity types or for a business process, cumulative calculation can be selected for all sender objects (under version settings).
The cumulative method is advantageous where costs incurred or the activity output are subject to large fluctuations. This applies in particular&#
History
| Last changed by/on | SAP | 19960506 |
| SAP Release Created in |
