Category 2 activity types are for indirect determination and indirect allocation. If category 1 activity types are vanilla ice cream, category 2 activities are more like hot fudge sundaes. There is a lot of power built in to how postings are made with these activity types.
Direct postings cannot be made for these activity types using KB21N. That transaction is reserved for use by category 1 activity types. Instead, an indirect activity allocation cycle must be set up, which will calculate the quantities of the activities to post and various receivers that can accept the allocations from the activity postings.
In our example, planning for this activity type is performed using the same method as was used the category 1 activity. This is because we used planning category 1 when creating CATEG2. Activity quantity is planned using KP26, costs are assigned using KP06, and the activity price is calculated using KSPI. In our example, we are planning $900,000 in variable costs for cost element 550000 for CATEG2 in cost center SND2. The resulting activity price is $7.50 per activity unit.
Here is where the fun starts. In order to post category 2 activities, you must create an indirect activity allocation cycle using transaction KSC1. The indirect activity allocation cycle defines rules for calculating the quantity of activity that is posted and also defines the receivers that are used for those activity postings. Once the cycle is created, it can be reused throughout the fiscal year to process multiple activity postings at a time without having to manually determine the quantities to post to each receiver. I have two examples which should help to show the power of indirect activity allocation.
The first example will use statistical key figure postings in the receiver cost centers to help calculate the quantity of activity to post in the sender. The transactions used for maintaining actual indirect activity allocation cycles are KSC1 (create), KSC2 (modify), KSC3 (view), and KSC4 (delete). Cycles are run for a given fiscal period.
Cycles are made up of segments. Each segment defines a separate allocation method with different senders and receivers.
I now need to go into some more technical explanation of defining a segment so that we can begin to get an understanding of how the calculations are made.
The Segment Header tab defines how the sender values are determined and what receiver types will be used to determine the quantities to be posted. Three rules are supported for senders. These are Posted Quantities, Fixed Quantities, and Quantities Calculated Inversely. Posted Quantities means that the sender activity type must first have a quantity posted and then the allocation will be done based on the receiver definitions. This will be discussed when I cover the category 3 activity type. Fixed Quantities means that the quantities to be posted are maintained directly in the cycle and then allocated based on the receiver definitions. This is likely to require cycle maintenance each time the cycle is run. The final rule, Quantities Calculated Inversely, is what would normally be used for category 2 activity type postings. For this rule, the quantity of activity is calculated from postings made at the receiver cost object and this is the rule we will be discussing.
There are four allocation rules for receivers – Variable Portions, Fixed Amounts, Fixed Percentages, and Fixed Portions. I am going to concentrate only on the first rule: Variable Portions. With this rule, the quantity of sender activity to be allocated to the receiver cost object is calculated by the weighting factor times the quantity of the “tracing factor” that is posted. The “tracing factor” could be a specific statistical key figure or activity type that is posted to the receiver cost object. For example, if we used a statistical key figure as our tracing factor, then the quantity of sender activity to be allocated to the receiver would be the statistical key figure amount times the weighting factor. To make it easier, if there were 15 units of a statistical key figure posted to cost center B with a weighting factor of 5, then that would equate to 75 units of activity type posted to cost center A with the costs allocated to B. The quantities allocated to all of the receivers defined in the segment would then be added together and that would be the total of activity units posted in the sender cost center. This will become clearer when we look at the example.
The Variable Portion Type define which type of posting will be used to calculate the allocations. These can be actual or planned costs by cost element, actual or planned consumption, actual or planned statistical key figure postings, actual or planned activity type postings, or actual or planned statistical costs. This first example will use actual statistical key figure postings.
The scaling option determines how negative postings will be treated in the calculation of the activity allocations. For the sake of simplicity (!), we will assume that there will be no negative postings, and therefore, no scaling is required.
The Senders/Receivers tab is used to define the sender cost center/activity type and the receiver cost objects. My examples will always assume that the receivers are cost centers.
The Sender Values tab is used to adjust the quantity of sender that is calculated. In normal circumstances this should be left as 1 to 1.
You define the actual tracing factor used on the Receiver Tracing Factor tab. Since the cycle has selected Actual Statistical Key Figures as the variable portion type, a specific statistical key figure or set of statistical key figures needs to be defined here.
Finally, the Receiver Weighting Factors tab is used to define the multiplier that will be applied to the quantity of “tracing factor” posted to calculate the quantity of activity to be posted to the sender for allocation to each receiver.
Additional segments can be added to the cycle at this time to cover other types of allocations that would be required. When complete, save the cycle.
Since we have set this cycle to use statistical key figures posted at the receivers to determine our sender postings and allocations, we first need to use KB31N to post the statistical key figures.
Now, let’s look at the Cost Center Actual/Target/Variance report prior to running the allocation cycle. As you can see, there are no costs or activities posted in cost center SND2.
You also see that in RCV2A, 500 Units Produced have been posted, but again no costs are posted.
RCV2B also has 500 Units Produced posted but no costs.
Finally cost center RCV2C has 1000 Units Produced posted.
Now, let’s run KSC5 to execute the indirect activity allocation cycle. We will be running it for period 4 (April), using cycle SKF1 which is set up for fiscal year 2017.
A report is generated when running the cycle which will show the results of the postings. The result is that a total of 15,000 units of CATEG2 was posted in cost center SND2 and was allocated to the three receiver cost centers: 1,500 to RCV2A, 7,500 to RCV2B, and 6,000 to RCV2C.
Looking at the cost center report for the four cost centers, we can see that these postings were actually made. How did the cycle determine that these were the quantities to be posted? Since the receiver rule was set to Variable Portions, the calculation was based on the receiver quantities posting along with the weighting factors. The quantity calculation is (500 x 3) + (500 x 15) + (1,000 x 6) = 15,000. That is what we see posted in cost center SND2.
Note that cost centers RCV2A and RCV2B both had 500 Units Produced posted, but the amounts posted to each are different. That is because the weighting factor in the cycle was different for each cost center. Cost center RCV2A had a weighting factor of 3, which would translate to 1,500 activity units posted in SND2 with RCV2A as the receiver. If we think of our statistical key figure as representing units of production, and CATEG2 as representing energy consumption, that would mean it would take 3 units of energy consumption to make each production unit. The value posted for cost element 943902 is then CATEG2 price of $7.50 times 1,500 or $11,250.
Using our energy analogy from cost center RCV2A, the expected energy consumption for each production unit in RCV2B is 15. The weighting factor in the cycle represents this. Consequently, 7,500 units of CATEG2 were posted in SND2 and allocated to RCV2B, resulting in $56,250 posted to 943902.
To round out the receiving cost centers, 1,000 units of production with a weighting factor of 6 results in 6,000 units of CATEG2 being posted.
The cycle as defined can be used again and again to calculate the activity quantities to be posted each fiscal period. All that is needed is that the statistical key figures be posted for the receiver cost centers each period.
I promised that I would provide two examples of how the indirect activity allocation cycle works. The second example is coming up in the next blog post, and it will cover using receiver activity types as the method for calculating and allocating the sender quantities.
Thank you! But you got me lost because you suddenly introduce "weighing factor" but you don't define it nor is shown in the SAP GUI.
What is it?