We use the Part Cost Group to indicate the site (typically the primary supplier) that should be used to derive the cost basis for each part in the chain.  For us, we have a similar relationship, but have 25 sites to keep in sync, some of which are in the same company and use the same base currency, others which are in different companies and buy the parts using an intercompany markup.

We always start with the originating manufactured site, make sure that is calculated to the top and then that cost is used as the estimate for the purchased part setup in the next site and then to the next.  The Part cost group then tells us which site to pull the cost from.

We end up using migration jobs to extract the cost from the first site to upload to the estimate for the second site and so on to the cross-company sites along with a currency change and IC markup.  There isn’t a method to fully automate all of this, we’ve got closer with migration jobs, quick reports, and some automation, but still requires manual intervention and checking.

@ShawnBerk I agree. I also don't see a way to fully automate this. I also put a thought on the Part cost group. If the same part of a given site is connected in different structures of different sites, we might not be able to identify this exact sequence using the part cost group. But I believe your answer helped me a lot.

Thanks,

Regards,

Pasan

we might not be able to identify this exact sequence using the part cost group

This is why we force the identification of the chain using the primary supplier as well.  There can be only one primary supplier, so at the time that the calculation is done, that is the indicator used to tell us what to use.  If it is an external supplier, the Part Cost Group is LPP (Last Purchase Price) and then we know to use the last purchase as the basis.  If it is another site, then the site number is the Part Cost Group for the buying site.  It isn’t 100% foolproof, but as long as all of the buyers and planners follow the rules and keep things updated according to the set rules, the cost is much more accurate between sites.  

When it isn’t right, then I can almost always trace it out to the PCG not set right, the primary supplier not set as expected, or that someone switched the inventory part type at some point.  It is a tricky process to keep clean, but making rigid rules has been the only way for us to force control and accuracy.

Understand. But if there are other lower levels within the structure to be supplied from another site, we will again identify that through the PCG & Primary supplier. This also means we have to identify the site to do the 1st calculation on, based on the multi-site structure chain, by connecting the PCG to match that & then come back using the bottom-up approach. Once again, this would be a part-by-part case & is less likely to be automated entirely. But we could mitigate the errors through the steps you have currently done. I can imagine the complexity of 25 sites.

To go the full loop on the longest chain of parts across all of our sites, it takes running the full process about 7 days in a row to get everything up through all of the levels and settled out.  We have another migration job that runs on a daily basis when we’re doing costing to show the discrepancies between sites where the PCG says it should match the cost on that other site.

New product introductions can take weeks for each of the sites to get their portion of the costing done so it can roll up to primary site where the finished product is produced and sold.  The parts in the top level manufacturing site are often configured which adds an additional layer of complexity at the catalog number level.

Got it. Thanks a lot for the response. This helps a lot