Feb 3, 2024

Actual activity rate calculation with Cost Splitting

I decided to publish this Blog post because I could not find anywhere else on the Internet any other post for a scenario like the one that I will describe here.

There are several posts on Activity rate Actual calculation out there, but none of them is using an "Splitting Structure" for multiple activity types withing the same Cost Center. All of them are based on the assumption that 100% of the Cost (rate) of the Activity type covers 100% of the Costs incurred in the Cost Center.

This post is going to describe how you setup an Splitting Structure when the incurred costs of a Cost Center are represented by several Activity Types at the same time.

Ex. If you look at the "T" Account or a Cost Center report for a given Cost Center and you have 30 different Cost Elements (GLs) expenses being posted in that Cost Center.

Normally, you would have 1 Activity Type (& rate) that will represent the entire 30 expense accounts and that will offset 100% of those costs when doing Activity confirmation. That Cost Center will receive credits from it that should offset the entire Cost Center costs.

But ... in certain cases, business do not want to have 1 Activity Type (rate) to offset those 30 different expenses, they want several ones 2, 3, or even more Activity Types within the same Cost Center. In that case, the usage of the Activity rate actual calculation, would require you to setup a "Splitting Structure" to be able to achieve this and have the actual activity rate calculated properly within that Cost Center.

You will start by defining a "Splitting Structure", follow the IMG path above.

First, create "Splitting rules" where in this case we will split based on "Activity quantity".

Then create a "Splitting Structure", Ex. Z1 too.

Note: Part of the descriptions are masked for confidentiality reasons.

Then create 1 line per Activity Type that you will have within that Cost Center. In my example above, I had up to 7 Activity Types within the same Cost Center that I needed to split and take into consideration for my Actual Activity rate calculation.

When you create each line, you assign them the Splitting rule that we created before that was based on Activity Quantity.

Once the line created, you go one level deep and create the "Selection for assignment". 
This is where you will establish which Cost Element/s range or group will represent a given Activity Type. You also need to specify which Activity Type goes with for this assignment combination. 
In this example, I had a CE group ZS_LUNLAB that goes with LUNLAB Activity Type.

By doing this, when running the calculation, the system will "pair up" the Actual expenses of those CE's in that group with the total costs posted / offset of that Activity Type to be able to later calculate the actual.

Once you have this configuration completed for the several Activity Types, your Splitting Structure configuration is completed.

Activity Type Setup

The Activity Type needs to be setup in a specific way for actual calculation

Tcode KL1, 2, 3

The Activity Type needs to be setup with "5" to be able to calculate the price automatically.

Version configuration

You need to configure your CO - Version accordingly per Fiscal Year (FY) to be able to have the Actual Activity price working as well.

"Revaluation" fields needs to be setup with either 1 or 2 option, 0 will not revalue.

1 - The differences between allocations valuated with plan and actual prices are posted under a separate transaction (actual price calculation).  - Like a Delta posting

2 - All actual activities revaluated with the actual price; original allocation changed. The differences between allocations valuated with actual and plan prices are not shown with this option.


We will start by running a Cost Center report to understand what Actual debit expenses where posted during the month at my specific Cost Center and what were the Activity Type credits that were posted as a result of the Activity confirmations derived from my Production execution.

Because of given business reason, we had 1 Cost Center that "concentrated" all the expenses and with allocations from many different Cost Centers we were posting the Debits into this one Concentration Cost Center. All the Activity Types were also assigned to these 1 Cost Center too. Thus, 1:1 relationship that you can easily see here in my Cost Center report. This is only an example, and it is not always that straight. In many cases, you will have 5/6/7 Cost Elements, for a given Activity Type offset.

As per the Cost Center report, you could see that the total expenses posted were $34,273.33 while the Absorption Credits posted by the Activity Types confirmations, where $33,623.33 and were not able to 100% offset the actuals (by $650).

For this, we will calculate Actual Activity rate calculation that will recalculate all the Activity rates to be able to fully offset those actuals and end up with the Debits equal to Credits on the Cost Center report.

1st step before doing the calculation, we need to do a 1 time (per Fiscal Year) setup to assign the previously configured Splitting Structure to my CN599 Cost Center, so the system knows to which Cost Center this Splitting Structure will apply (it can be more than 1 Cost Center too if it applies).

Execute Tcode OKEW and assign it.

It says "All versions" but we are only doing it for version 0

Once done, SAVE and the assignment is completed. You need to repeat this every FY.

The Actual Activity Type calculation is a 2 step process. First, you calculate and second you post the newly calculated transactions with the new rates.

1st step - Tcode KSS2

Enter the Cost Center that you want to split & recalculate, period, fiscal year for calculation and execute.

If you look at the total results, you will easily recognize those numbers from the previously executed Cost Center report. 

Control Cost & Actual Costs  columns represent all my Cost Center Debits. 

The Actual Cost Balance column, represents the Total Credits done by the activity type postings.

Allocated Actual column, represents the difference that I still need to allocate.

Then within the lines of this report, you will find all the different Activity Types that were posted during the month with their corresponding actual quantities. If your Splitting Structure was properly mounted, your Allocated Costs will properly reflect the right proportional amounts on each line.

Make sure your Structure covers 100% of Cost Elements involved in the Cost Center and 100% of the Activity Types that credited that Cost Center. If for any reason, the structure has a "hole" and does not covers 100% of any of these 2, then your numbers are not going to be properly calculated for all the Activity Types, not just 1. So this is really important.

As a suggestion, in the Splitting Structure when doing the assignment configuration, I strongly recommend you to work with a CE group. This way, you can easily add new CE's in the group without the need of a configuration, transport, testing and the whole bureaucracy of changing configuration on a Production system.

Once this step executed (without test mode), you are ready for the next step which is the Posting.

2nd step - Tcode: KSII

Actual Cost Center postings showing that during the month we only had 0.144 Qty for this LUNLAB Activity Type.

Note: If you are using Actual Costing, the allocation cost element from an Assessment like 9042119 needs to be added to the corresponding Cost Components Structure (OKTZ) even if they are not being used for Costing. (This is only applicable in case you are using Actual Cost Component Split, like in my case)

Calculation Result of KSII (done in test mode in my case)

New determined rate for LUNLAB is $ 73,321.74

Total Costs in the Cost Center to offset $ 10,558.33 (show in prior reports)

Total Activity Qty occurred in period  0.144 hr.

10,558.33 / 0.144 = 73,321.74 is (will be) the new rate calculated by the system for LUNLAB 

Note: My numbers are really odd because I did not a lot of activity type quantities posted to be able to end up having a rate that would make sense, but you have to follow the math.

Now If I were to remove the "test mode" the system will go back to every single Production Order that had this LUNLAB (and other Activity Types too) and repost everything at the new rate instead of the standard rate that I had from KP06.

To be able to properly determine Actual Activity Type rates, having 7 different Activity Types within the same Cost Center and them being covered by a series of different Cost Elements, is only possible by setting up the Splitting Structure in the way that I described before; otherwise it will not be able to "split" your costs properly among the different activity types.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Sep 11, 2023

Fiori App "Production Cost Analysis" status mismatch versus SAP GUI


I recently run into this while testing the new Fiori App "Production Cost Analysis" and wanted to share it with the community.

This new Fiori App, has a somewhat "weird" or new way to deal with Order statuses as we were used to in the past when we would display them in GUI (Ex. CO03).

If you see my 1st screen capture, my Production Order 10004582, shows with status "Closed" in the Fiori App. Which for me it was an issue right away when I saw it, because I knew I did not Closed (CLSD) this Order yet.

If you display this same Order number in GUI Tcode CO03 (2nd screen capture), you can clearly see the highlighted Order statuses as being REL - Released and DLV for Delivered. But nowhere in the Order statuses you will see CLSD - Closed.

Is the Fiori App working properly ? YES

Is this some sort of bug in the App that needs to be reported and fix ? NO

Is there any OSS Note that fixes this issue ? NO

No, this is not a bug and the Fiori App is working properly (as per SAP design). 

According to OSS Note 3295371 ( APP F1780 "production cost analysis" doesn’t show correct order status ), this works as intended. It considers the status DLV - Delivered that the order has been completed and therefore is Closed as in the Fiori App.

Being used to the traditional Order statuses, this makes me a lot of noise and is a bit misleading as in the backend the order is not even TECO - Technically Complete yet, and the Fiori App already shows it as Closed.

This could lead to several issues and impacts if not understood properly.

No TECO in the orders. Orders could remain in those statuses for ever. You will need to use other reports to make sure the shop floor people TECO them. (I know you should not use this report to analyze order statuses, but still the mismatch is what bugs me ...)

Same case for real CLSD - Close that should be put in the Orders after a period of time.

I find it weird, but I guess that only for the purpose of analyzing "Production Variances" a DLV status means no more work on the order. But from a technical point of view, this status will not prevent the shop floor from continuing using the order and book costs against it if they want.

Below is the OSS Note and an extract of it where it explains this situation.

OSS Note 3295371 - APP F1780 "production cost analysis" doesn’t show correct order status


    Please compare order number XXXXXX (Status ID = REL) in the system. In SAP GUI (t-code COOIS, CO02/3, COR2/3, etc.), the manufacturing order has more statuses which some are relevant and others aren't relevant for the FIORI app (usually CRTD->REL->PCNF->CNF->DLV->TECO->CLSD etc.).

    In the Fiori app, the manufacturing orders with the 'Released' status [REL] (or partially released [PREL]) but not 'Delivered' [DLV] or 'Technically Completed' [TECO] or 'Closed' [CLSD] statuses are considered as 'OPEN.' The orders with DLV, TECO, and CLSD statuses are considered CLOSED in the Fiori apps.

The order gets OPEN since it's released, and later it gets status CLOSED once TECO, DLV or CLSD status is set. These two statuses: OPEN and CLOSED, are available for selection in the smart filter dropdown box (Open, Closed, Open and Closed).

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Jul 29, 2023

Practical use case of SE16H with a quick Query to understand Material account determination (FI-MM)


The days of using SE16N (or even the old SE16) should be over now and you should now embrace the new evolution of it. The new SE16H !!! "H" for the HANA database era and capabilities.

This new version (SE16H) offers grouping capabilities, sorting, aggregation (like COUNT for counting records) and one of the most important one, JOIN capabilities. Now you can JOIN other tables to retrieve the content or descriptions that you can find in other satellite tables or Header to Line items relationships in one big Query / Result instead of jumping from one to another.

In the past we used to execute several Queries with SE16N (or SE16 for the old folks), download to Excel and then VLOOKUP those values to join them and or get descriptions. Now you can do all of that directly in SAP with SE16H in one step.


This Query will allow you to quickly understand and give you more information about all your FI-MM account determination from your system by providing GL account descriptions and Valuation Classes names,

FI-MM Account determination configuration can be found in Table T030.

Once in SE16H, go to "Outer Join Definition" and create a new one. Provide a Name and a Name / Description. 

Then add Table SKAT - GL Account Master record descriptions by clicking the green add icon with the "+" on the 1st table for "Definition of Secondary Tables". 

Once added click on the "Output" icon (same as the Multiple selection icon for reports). This will allow you to select which fields you want to output from your "joined" SKAT table in your final query results. Accept and you will go back to the prior screen.

Then on the 2nd part of the screen (Selected Secondary Table) you have to enter the different fields that you need to join both tables. In our case, I am looking to display the GL accounts descriptions / names that I have in Table T030 as there is no way that I would know them by hard by just looking at T030 directly, and there are quite a few of them.

Enter SAKNR on Table field, select Method "Reference" (as you will reference / join it with the value of table T030), Reference field KONTS (GL account) from Table T030 then Table T030.

Add 2 other lines for KTOPL (Chart of accounts code), but in this case it will be as a "Constant" and value 0001 as my Chart of Accounts is 0001. Note: don't put this value as '0001' or you will get an error in your query, you do not need the colons for a constant as you would do while writing code.

Then add SPRAS (Language) as you are bring Text descriptions from a Table (SKAT) that is language dependent. In this case E for English and not EN. E for the technical unconverted value for English language. If you are not sure of your language technical value, display SKAT first in a separate SE16H window to know yours.

Finally, I want to add a 2nd table that will show me the Valuation Classes descriptions, as there are several and you do not always know them all by hard. Follow the same process but in this case for Table T025T (T for Text table for original table T025 Valuation classes).

Save your "Join Conditions" and then go back to SE16H main screen and select your "Outer Join Definition" name that you just created and Execute.
You can also select which fields you want to output from T030 in this main screen too. Then you can save your "layout" and re-use it next time in conjunction with your Outer Join definition.

At the end, after adding the 2 tables for GL account and Valuation Classes descriptions, your end result will show you all the T030 records with their corresponding descriptions for GL and Valuation classes. This will help you understand your FI-MM Account determination in a better way.

PS.: It is a shame that we do not have a table to get the descriptions for the field "Transactions" / KTOSL that would tell us what BSX, GBB, PRD, WRX, etc mean that we could add here too. But as an SAP Consultant, we need to know them or have proper notes / documentation with their meaning and usage.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.