Hello,

Is the cost element connected to account or to another code part in your case? 
 

I think you can use control type C90 - Cost source - to set-up your M40 posting control on code part connected with Project cost element, to achieve the distribution expected. Different cost elements require different postings created.

Hello,

Thank you very much. The cost element is connected to account. I will try mapping M40 with C90 and will update you.

Thanks again.

Kind regards
Rutuja

It means you will need 3 accounts for work in progress - to separate labour, materials and overheads.

@Adam Bereda i really have the same issue when mapping M40 to Material, Labor, Overhead. when use LOV to select cost source, my system shows nothing. Wondering how to set up cost source to map the above 3 cost elements? Thank you.

Hi,

Example of the solution using M91 control type - posting cost group:

Posting cost groups are defined per company:

and associated with cost bucket in costing:

@Adam Bereda You are awesome.

Hi ​@Adam Bereda,

Looking for some help on similar scenario. I did the same setup as you mentioned above in IFSCloud 25R1 environment and got the cost breakup correctly in Project monitoring window until I receive the shop order. Once it is received cost got shifted to one cost element. Did I miss any setup? Adding few screens preview for easy reference. 

1. Create Materia request connecting to project and shop order created

2. Release the shop order 

3. Receive shop order and close

4. Update vouchers into GL

Best Regards

Narmada

Hi, 

I see a good number of views / comments.

For that reason, it’s probably helpful to add comments to this.  

By default, IFS uses the GL account number as the project cost / revenue driver.   For example, if account 11111 (assume inventory) this would be mapped to a material cost element.   This is a default, but any other code part can be used rather than the account. 

So, when / why would we use a different code part and why would we use a GL account. 

Account works best as a driver when shop orders are not used with projects. Account may also be useful if (from a project cost perspective) we see shop order costs as “manufacturing cost” rather than labor, material, OH and other. If all those shop order cost were seen as manufacturing cost then account is a good driver.   I say this because before apps 8 (I believe) we only had the account as a driver. That limitation caused difficulties as we needed many different flavors of GL accounts simply to keep the cost flowing to the correct element.   It was less than Ideal as our clients typically do not want WIP material, WIP labor, WIP OH, WIP outside process and similar, then we also would not want Inventory Material, Inventory Labor, Inventory OH etc.  We needed all those accounts just to keep the correct cost elements as the material flows through a manufacturing process.  

For some clients we have viewed all shop order cost simply as Manufacturing cost - not in the detailed elements.   You still need to map the appropriate GL accounts such as M40 WIP account to a cost element “manufacturing cost” but it’s cleaner than having multiple M40 accounts.  Similarly, the M1 would need to point manufactured parts to a GL account connected to the manufacturing cost element.  

The option that is usually best when using shop orders with a project (when we can’t use a single manufacturing cost as an element) is to have a separate code part.  Maybe call it cost element, and posting control will then be used to drive the type of cost to the correct element.  

Hope this helps to explain the different options, and the reason why - when using account, things get messy with shop orders and projects. 

If this topic is fully answered it would be good to set it as answered so we don’t keep adding on. Just my opinion. 

Best regards, 

Thomas