Showing posts with label CMK3N. Show all posts
Showing posts with label CMK3N. Show all posts

Jun 27, 2025

Creating a Mass report for Actual Costing CKM3n beloved transaction

For those of you that work or have worked with Actual Costing, I am sure that you have used, and continue using every day, Transaction CKM3n - Material Price Analysis. This is the go-to report / transaction to analyze the costs and actual costs of a given material during an accounting period. This is "the bible" for Actual Costing information on Materials.

The transaction is really nice, it gives you a lot of information on Receipts, Production, Consumptions, Deliveries, Revaluations on a Standard basis as well as including Actual Costs. There is "almost" nothing better out there in standard SAP Actual Costing than this transaction. But ... it has a very big limitation, you can only display 1 Material at a time in 1 Plant and for 1 Accounting period at a time. There is no other good transaction for many Materials. If you are dealing with multiple plants and multiple materials, then it is going to be hard to do multiple analysis. (some would mention KKML0 as an alternative, will there shortly ...)

Another good piece of information that this report provides you, is the breakdown of the figures by Cost Component (considering you have activated Actual Cost Component Split in your system).

As you can see above, you get a lot of valuable information like Beginning Inventory, Revaluation, Receipts, Consumption and finally Ending Inventory; which is also something really nice that many Cost Accountants would need (All the In's & Out's during the period).

Note: To be able to obtain all these calculations in CKM3n, you need to be using Actual Costing and running it on a monthly basis. Otherwise, this transaction will show you only "Price History" information which is line by line each transaction, the standard cost, quantity, etc. Only with actual costing you will have calculated beginning and ending inventory and their corresponding "price difference" (Actual costing).

Now if you want to do a Mass report for the information in CKM3n, you will have to build a custom report for it; which I will explain you what will be your source tables for this information.

In the picture below you will have a more detailed and exploded view of the different categories in CKM3n


You can easily reproduce these with the 3 Tables below, which I will explain each of them:

FCML_MAT_V  
FCML_REP_V
FCML_CCS_REP_V

Will start with the 1st Table FCML_MAT_V

This table has the "Master Data" type of information (Ex. Plant, Material #, Description, Valuation Class, Profit Center, Company Code and the most important one "Cost Estimate number", among some.


If you are also dealing with Customer Stock or Project Stock, you also have the Stock Type, Sales Document and line item number as well. Same as you would need to enter in CKM3n.  


Next Table FCML_REP_V

The link between the 2 Tables is the "Cost Estimate Number". Here you also have a way to restrict by Posting Period, Fiscal Year and Currency Type (10 for Company Code, 30 for Group this will depend on your Material Ledger currency setup). If you do not restrict the data, you will get for that same material all accounting periods out there for all your ML currencies.
These should be part of the available selection criteria in your future query.



Once you restrict your data, you will see that this table shows the different Categories that you get in CKM3n (Ex. Category AB will represent your Beginning Inventory, ZU - Receipts, ... and EB - Ending Inventory). 

Note: Unfortunately there is no check table for the Category list of values as this is a Domain with a list of values. These are the different values


Each Material / Plant combination will have many records for a given period because of the multiple categories. (so eventually they need to be aggregated)

In the example below, you will see side-by-side CKM3n and the corresponding FCML_REP_V record.
You could clearly see the "Total Stock BUn" column representing the Quantity for Beginning Inventory (Category = AB), and the "Total Val" representing the $ amount. Then you can continue with the other Categories like VN - Consumption and EB - for Ending Inventory.



For Ending Inventory (EB) you will need to aggregate (sum) multiple EB records to obtain the Total Value, Quantity and in this case the CKM3n Settlement line (Actual Costing) for ending inventory value, is represented by column "1LvLPrDif". Which it will apply for Beginning inventory for next period. (In my records, I did not have a settlement for beginning as it was my 1st data period).



For Consumption (VN), you will also need to aggregate more than 1 VN record. Again, the Price Difference column or in this case what would show in CKM3n as a revaluation line, will be represented in column "1LvLPrDif".



Finally, the 3rd and last Table FCML_CCS_REP_V
This table represents a deeper level in our CKM3n information. This will give you each of the prior  inventory movements categories broken down by Cost Component.

Same as before, the link is Cost Estimate Number. Of course, this table also needs to be filtered by Posting Period, Fiscal Year, Currency type, etc.
You most likely need to aggregate records as you might have several for the same Cost Component and category.
Here you will have in the field "Cost Component" the component code and then you will also have the Cost Component text description already. 


This Component breakdown is what you will normally see in the far right of your screen within CKM3n transaction.

In the image below, you will see how in this example the records in Table FCML_CCS_REP_V match the consumption line of the Cost Component 20 (see Table and CKM3n side by side and highlighted).
The Cost component amount is the sum of either PRCDIF_VAR Crcy field or PRCDIF_VAR_S field.



In the case of another Cost Component like 110, is the sum of 2 fields, so you need to include Fxd Value as well. So, at the end, it is better to aggregate and sum both fields for any of the scenarios. This one has a value for Fxd Value (because this component is about fix costs, and the prior example CC 20 was about variable costs).


Now that you have all the necessary Tables that provide CKM3n equivalent numbers, you are ready to build your query. With the help of a good Abaper, he can easily join these 3 Tables and turn them into a new CDS view that ultimately can be turned into an Analysis for Office (AfO) query or he can even encapsulate this into a Fiori App using SAP Web Dynpro. I personally prefer AfO or the old Design Studio that would be easier to drag & drop on a pivot table like navigation. Web Dynpro has replaced it, but I prefer the old one that uses less square footage in your screen.

Not sure if you realize, but all these 3 FCML* tables are also standard CDS views that SAP has built. I just don't understand why SAP has not turned them into a proper report and/or Fiori App yet for Material Ledger reporting. They should do it already ! 


Note: I said before that one alternative to this could be to use Transaction KKML0. In my personal opinion, should not be something to be used now a days in S/4 HANA (but there is nothing better yet). This uses a really old SAP technology, "Drill-down reporting" which also uses Report Painter behind the scenes (even older ... 😠 ). You could obtain part of the same information, but not with Cost Component. Then when you will try to export it, it results in a tremendous amount of columns because every combination of CKM3n (row & column intersection) will end up as a column. Not really nice at the end. 


What needs to be activated for the FCML* tables to work ?

Oss Note "2441212 - ML Drilldown Reporting - use CDS views FCML_MAT_V, FCML_REP_V" explains it. It also mentions that this is only available on S/4 HANA versions 1610 and higher for Plants with Activated Material Ledger Actual Costing.

What the Note also says, is that once that in place, KKML0 (Material Ledger drill-down reporting) will be using these series of CDS views. So at the end, my solution is tapping into the same set of Tables. But, if we encapsulate or expose these CDS views to be used in AfO or in a Fiori App, you end up having a way better front-end than the classic Drill-down reporting.

There are quite a few Oss Notes talking about these series of ML tables too.



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