We have gone into a lot of detail on how indirect activity allocation cycles work with category 2 (indirect determination, indirect allocation) are used. The main takeaway from category 2 type activities is that the quantity of activity posted is calculated based on information derived from the receiver cost objects. You either don’t know or find it difficult to determine how much activity should be posted. What if you do know how much activity should be posted, but don’t want to manually determine how to allocate the posting to other cost objects? That is where category 3 (manual entry, indirect allocation) activity types come in.
To continue on with my dessert analogy, this is more like vanilla ice cream with chocolate sauce: still good, but not quite the same thing as a sundae! With category 3 activity types, you have to make a “one-way” activity posting. The determination of the receiver cost objects and the allocations is performed using the indirect activity allocation cycle (KSC5), just like with category 2 activities. Our category 3 activity type is CATEG3.
To help understand the differences between category 3 and category 2 allocations, I have used the same planning setup for both. 120,000 units of CATEG3 is planned for cost center SND3, with $900,000 planned for the year. The three receiving cost centers are RCV3A, RCV3B, and RCV3C. The activity plan and allocation of CATEG3 from the support cost center SND3 is as follows:
• RCV3A: MACHHR – 8,000 HR and 50,000 units of CATEG3 allocated
• RCV3B: MACHHR – 16,000 HR and 30,000 units of CATEG3 allocated
• RCV3C: MACHHR – 24,000 HR and 40,000 units of CATEG3 allocated
This means that all 120,000 units of CATEG3 have been allocated from cost center SND3 to these three cost centers. Now that the above planning is complete, we will turn to the creation of the indirect activity allocation cycle using transaction KSC1. This cycle has one segment which is defined to calculate amount of the posted sender activity to allocate to each of the receiver cost centers. The quantity of MACHHR activity posted in each of the receiver cost centers is the determining factor for the allocation. Posted Quantities is selected as the sender rule. Note that when Posted Quantities is selected, there is no Sender Values tab. This is because the sender activity quantity will be manually posted using transaction KB51N and will not be calculated when running the cycle.
As before, the sender/receiver relationship is defined in the Senders/Receivers tab.
The receiving activity type is defined on the Receiver Tracing Factor tab. However, in this case the quantity of the MACHHR activity will be used to calculated the relative quantity of CATEG3 to allocate to each of the receiving cost centers based on the weighting factors assigned to each receiver.
The weighting factors for this allocation will again be calculated based on the rate of consumption of the planned allocation of the sender activity (CATEG3) for each receiver activity type.
• RCV3A: 50,000 CATEG3 / 8,000 MACHHR = 6.25
• RCV3B: 30,000 CATEG3 / 16,000 MACHHR = 1.875
• RCV3C: 40,000 CATEG3 / 24,000 MACHHR = 1.666667
If we look at the calculation for RCV3A, this would mean that we are planning to use 6.25 units of CATEG3 from cost center SND3 for each hour of MACHHR that is posted in RCV3A. This time, however, these factors will only be used to determine how the manually posted quantity of CATEG3 will be allocated when all three receiver cost centers have been taken into account. As before, the weighting factors in the cycle must be whole numbers and the divisor is set to 1,000,000 to avoid rounding.
During period 4 (April), 500 hours of MACHHR was posted in RCV3A, 700 in RCV3B, and 1,200 in RCV3C. The Cost Center Actual/Target/Variance report looks like this for each of the four cost centers (including SND3). In addition, 8,500 units of CATEG3 activity have occurred in cost center SND3. First, it is necessary to post the CATEG3 activity in SND3. This is done using transaction KB51N. KB51N acts like KB21N, except that it is not possible to assign a receiving cost object. Category 3 activity types are indirectly allocated using the indirect activity allocation.
Now that the activity has been reported, it’s time to look at the cost center target/actual/variance report for the four cost centers. Note that targets are generated for SND3 because the activity has been posted. However, the cost for CATEG3 has not been credited, because the allocation has not been executed yet.
The behavior of the one-way posting aspect of category 3 activity types is demonstrated here. Looking at the 3 receiver cost centers, we can see that the targets generated by the posting of the MACHHR activity type are the exact same as we saw in the category 2 example of the receiver cost centers. Compare the pre-allocation RCV3A with the pre-allocation RCV2D in the previous category 2 example.
RCV3B looks like RCV2E
and RCV3C looks like RCV2F.
The allocation of the costs from the sender cost center is accomplished using the indirect activity allocation cycle ACT3.
The report that is generated shows that a total of 8,500 units of CATEG3 has been allocated to the three receiving cost centers. This is the amount that was posted with KB51N.
Before we look at the results of the allocation, let’s understand how the calculation was done for the amount of activity allocated to each receiver. We first need to calculate the actual weighting factors for each cost center. We will use the weighting factors from the allocation and multiply by the amount of receiver activity in each cost center.
• RCV3A – 6.25 x 500 = 3,125
• RCV3B – 1.875 x 700 = 1,312.5
• RCV3C – 1.666667 x 1,200 = 2,000
Adding the three weights together gives a value of 6,437.5. The 8,500 units of activity CATEG3 will then be allocated based on the above calculated portions.
• RCV3A – 3,125 / 6,437.5 x 8,500 = 4,126.214
• RCV3B – 1,312.5 / 6,437.5 x 8,500 = 1,733.01
• RCV3C – 2,000 / 6,437.5 x 8,500 = 2,640.776
After running the cycle, we now see that the sender cost center SND3 now has the credit for the activity posting assigned to cost element 943903.
In the previous category 2 allocation example, the secondary cost element posts in the receiver cost centers matched the target costs. That is because the quantity of activity was calculated to match the target. Since we are independently posting the quantity of sender activity in this example, the targets won’t likely match up. We can see this is RCV3A,
Since we previously demonstrated the effect of running KSII for activity types that allow revaluation to actual, we will not demonstrate this here. A good question at this point would be why use category 3 activities for allocation? For category 2 activity types, we either didn’t care that the exact amount of sender activity was posted or there was no good way to determine how much activity to post. The indirect activity allocation cycle calculated that for us. With category 3 activity types, we explicitly know and can post the amount of sender activity and we want to have the system do the allocation instead of us having to manually determine how much activity would go to each receiver. In my next post, I will be switching gears away from the indirect activity allocation postings to look at category 4 activity types (manual posting, no allocation).