The main takeaway from category 2 type activities in previous blogs is that the quantity of activity posted is calculated based on information derived from receiver cost objects.
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.
With category 3 activity types, you make a “one-way” activity posting. The determination of the receiver cost objects and the allocations is performed with the indirect activity allocation cycle transaction KSC5, just like with category 2 activities. Our category 3 activity type is CATEG3 as shown in Figure 1.
Figure 1 Activity Type CATEG 3
To help understand the differences between category 3 and category 2 allocations, I've used the same planning 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
120,000 units of CATEG3 are allocated from cost center SND3 to these three cost centers. Let's create the indirect activity allocation cycle using transaction KSC1. This cycle has one segment which calculates the 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 as shown in Figure 2. 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.
Figure 2 Segment Header Tab
As before, the sender/receiver relationship is defined in the Senders/Receivers tab as shown in Figure 3.
Figure 3 Segment Senders/Receivers Tab
The receiving activity type is defined on the Receiver Tracing Factor tab as shown in Figure 4. 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.
Figure 4 Segment Receiver Tracing Factor Tab
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 as shown in Figure 5.
Figure 5 Segment Receiver Weighting Factors Tab
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).