Using S/4 COGS Split when shipping to customers out of non-Manufacturing Plants

Starting from S/4 HANA version 1709 and upwards, SAP introduced a new functionality for COGS (Cost of Goods Sold) split when posting your a PGI (Post Goods Issue) automatic journal entry.

Up until this version and traditionally in SAP ECC version, we would post a 1 liner COGS entry for the total standard cost of the material (* Qty) of the product being delivered to the customer. This was the standard in SAP and has been like that since SAP existed. Many other ERP systems do the same, posting of the Cost of Good Sold entry is done with just 1 line to represent the COGS. Also, when we were using Costing based COPA, we would create as many Value Fields as Cost Components we had and when performing the Billing the system will post into COPA this sort of COGS Split among the different value fields. But from a pure GL posting perspective, this was not yet possible.

Our Journal Entry used to be like below:

Debit - Cost of Good sold (PL)

Credit - Inventory (BS)

Now a days, the recommended approach with S/4 is to use Account based COPA and not Costing based COPA anymore. Account based is the way to go today.

(Note: you can still use Costing based, but it is not the recommended approach anymore for new S/4 greenfield implementations. For the old SAP guys, like me, we grew some grey hair trying to explain the "unbalanced" situations of FI vs. COPA. So, we don't want go back to those days anymore). 

By using this new functionality, the system would create a 2nd Accounting Document right after your PGI posting that would offset the original COGS account and Debit your different COGS Splitting accounts that you would have configured to show your different Cost Components that you defined in Product Costing configuration (OKTZ).

Example:

Debit - COGS Cost Component 1

Debit - COGS Cost Component 2

Debit - COGS Cost Component 3

Debit - COGS Cost Component nn

Credit - Cost of Good sold (PL)

Now, the purpose of my posting it not to talk about how to configure this specific functionality. For this, you can find other nice posts that have been written on this topic by colleagues of mine.

I can recommend this one from SAP Press

https://blog.sap-press.com/how-to-split-cost-of-goods-sold-cogs-with-sap-s/4hana-finance

The purpose of this post is how to make COGS Split happen when you ship to your customers out of downstream Distribution Centers and/or 3PLs Plants / Warehouses.

When you ship to your customer from your Manufacturing Plant, and you activated COGS Split, it will naturally post your COGS Split.

But, many companies, have a downstream series of Warehouses, Distribution Centers and/or 3PLs that receive their goods from the Manufacturing Plants via Intra Company STO's (Stock Transfer Orders). And, only from there they ship to their customers.

Since these Warehouses were not the ones that manufactured the goods, you would normally don't have Cost Estimates there that would allow you the possibility of having calculated Cost Components to eventually derive that. In that case, you will have to use another Product Costing functionality that will be used when setting up your materials at these Warehouses. This functionality is called "Special Procurement Key for Costing".

With the setup of these key/s, you will specify, from which Manufacturing Plant the Warehouse will pull his costs and with that, it will also inherit the Cost Components Split. So then, when doing the PGI from the Warehouse, the system will have a Cost Component Split in that warehouse and will be able to post accordingly.

This is how you would configure this Special Procurement Key:

IMG > Controlling > Product Cost Controlling > Material Cost Estimate with Quantity Structure > Settings for Quantity Structure Control > Material Data > Check Special Procurement Types (Tcode OMD9)

    

Here you will define a new "Key" where you will specify: 

Procurement Type = "F" for External Procurement (Plant P001 will get its cost externally from another Plant. By externally, it does not meant from an outside Vendor).

Special Procurement = "U" for Stock Transfer (via STO).

Plant = Ex "CD00" the Plant that it will be getting its cost passed from. 

Note: that 1 Special Procurement key will be needed per Plant. So if you have 10/20 Plants retrieving its costs from CD00, you have to configurate this 10x/20x. The good thing is that since it is Plant specific, you can name them all with the same code / key. Ex. each of the 20 Plants will have its own Z1, easier for organization purposes.

One Material, can have its costs derived like this from 1 Plant at a time since this key is assigned in the Material Master at the Plant level. In our case at P001 we will assign ZD.

Once you have this, you will be able to create / assign to your Material Master record this Special Procurement Key in the Costing 1 Tab.

After setting up your Material Master record, the last step you will have to do from now on, is to include in your Costing Run all the downstream Plants for which you configured and assigned Materials to this Special Procurement Costing keys.

When you calculate your Cost Estimate for a Material, you will clearly see (below in yellow) that Plant P001 is deriving its cost from Plant CD00 (same Material number).

Note 1: You do not need to setup BOM and/or Routings in these downstream Plants to achieve this, just the Special Procurement Key for Costing. BOM and Routing remain necessary only for Manufacturing Plants.

Note 2: In this model, we are not considering any value added like Freight and/or Customs to the inventory value when moving from one Plant to the other, we are staying at the same cost. This can be achieved with other functionalities that are not part of this post.

Now when posting a PGI from Plant P00, you will have exactly the same effect and type of postings that you would achieve as if you were PGI'ing from a Manufacturing Plant and will show the Cost Component Split posting

Material Document for Movement Type 601 - Delivery to Customer will create 2 Accounting Documents.

First Document, posts the traditional COGS posting.

Second Document, posts the COGS Split posting as you defined in your COGS Split configuration but in this case from Plant P001 which is Distribution Plant and not a Manufacturing Plant.

Note: the COGS split configuration is done at the Company Code level, no configuration is required on a per Plant basis. Once done, it will apply to all Plants within that Company Code.

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.

www.dnabusinessconsulting.com

SAP Inventory valuation - Working with MTO but valuating as MTS

 Glossary acronyms :
MTO - Make to Order
MTS - Make to Stock
SO - Sales Order
BOM - Bill of Materials

When working with MTO -Sales Order stock, the inventory is held specifically for that Sales Order and valuated as per the original Sales Order costing that happened when you created the Sales Order and Costed it.

Now, if you are working with MTS materials that can become MTO and vice versa all the time indistinctively, this could create a challenge. Why ?

Imagine a Sales Order created 3 months ago in September with certain costing (Ex. $100 /tn) , now you are getting into a new Fiscal Year and preparing your Standard Costing for the next year to come. The result of your new Costing calculation (CK11N/CK40N) gives you $105/tn for the same material.

Once you finish your Mass Costing run and you "release" the new standard, it will revalue your Inventory. But this will only apply to your MTS stock and will not revalue your MTO Inventory "held" inside the Sales Order.

Many of you will tell me that CK55 - Mass Sales Order Cost and CK51N - Sales Order Cost exist, yes indeed they do. But, they will ONLY cost your Sales Order (the document) and you will only see the update after doing the costing in the condition type EK02 of your pricing procedure for that SO line item. But what none of these 2 transactions will do is re-cost the inventory on-hand that you have for that specific Sales Order.

In standard SAP, MTO inventory is supposed to last for a "finite" amount of time and the assumption is that as soon as you produce it you ship it (or shortly after). That way you are not supposed to have on-hand inventory for too long that would require to re-cost this in the event of a Mass recosting exercise (Ex. for a new Fiscal Year to come). So SAP, does not contemplate the possibility of revaluing MTO inventory on hand. 

*** This solution will not be applicable for all types of MTO situations, only to customers that move around their products between MTS to MTO and viceversa constantly, which we know it is not the true spirit of an MTO ***

Standard SAP MTO configuration uses Requirement Calss 046 - MMTO config value.

This Requirement class uses Account assignment category M  and Valuation M - Separate valuation with ref. to sales document/project. This Valuation M is the key one here that indicates that the valuation is in reference to a Sales Document (Sales Order) or a Project. It also uses Costing ID = B - Automatic costing and marking which makes that your Sales order gets costed and marked automatically behind the scenes when you save it. Costing Variant, specify your specific Sales Order costing variant that you use or configured for Sales Order costing (not the object of this post to talk about Costing variants). In case you use Costing Sheet in your design, you will put it here too .

Finally Costing Method = 1 is for Product costing (based on a BOM) in contrast to 2 Unit Costing.

The rest of the fields are not really relevant for my example and scenario.

Now, with a few tweaks and changes, we can create a new Requirement Class that will make the system behave and valuate your MTO inventory as if you were in MTS. (Needless to say that you will not modify the standard delivered 046 Req Class and you will create a Z or Y one. Golden rule in SAP that you should never break).

This will be the new Req Class for MTO as MTS. (see below in next image)

As you can clearly see, it has been decluttered quite a bit and we do not need many of the prior options.

The key field change here is the Valuation that went from M (Separate valuation with ref. to sales document/project) to A (Valuation without reference to sales document).

Without Val. Strategy also needs to be flagged which will also make the valuation work as MTS.

The rest of the fields are not needed Costing ID, will not cost within the Sales Order anymore as you are using MTS Materials. Costing method, not needed too, can be left blank. Costing Sheet and Costing Variant, either 

Now that you have that configured, all your Logistics processes will still behave as if you were in MTO. Your Inventory movements will still need to be done at Material, Sales Order and Sales Order line item as before. But, from a Financial valuation point of view, these will be handled from now on as MTS.

When you will display your Material Price Analysis (CKM3), in case you are using Actual Costing it is more relevant this Tcode, you will not have to enter the Sales Order stock option to display your inventory value, as the inventory is all handled as if it were an MTS from the Accounting point of view. Logistics wise you will still see it as MTO (Ex. in Material Documents and MM related reports).

Material valuated as MTO with Special Sales Order stock (before)

Material valuated as MTS but for MTO Sales Order (after)

Below you will see the line item of the Sales Order displaying my new Requirement Type ZKEM on the line item of the "Procurement" tab.

Remember, your Material Documents and movements will still need to be done and reference a Sales Order Line Item, but Financially it will not and all the inventory is going to be bundled together with your MTS stock from a Finance valuation point of view.

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.

www.dnabusinessconsulting.com

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.

Execution

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.

www.dnabusinessconsulting.com