My question is whether there is a user-friendly way of updating BOM prices in a volatile component environment. I think the answer is no, and that I will need to create a custom program to do so. The details...
We have several customers which manufacture fairly complex products, involving multiple levels of BOMs. Because of the volatility of component prices, and for tax purposes, FIFO costing is utilized. Thus, component costs will be changing on a daily basis. While I understand that the actual postings for a Production Order (PdO) will use the correct costs at the time of issue and FG receipt based on the item's costing method, these companies need to have reasonably accurate rollup costs in order to manage their selling prices. These rollup prices would be considered "reference" values, and it's understood that actual production costs would vary.
I've read dozens of posts and viewed an expert session on maintaining rolled BOM costs:
[https://websmp109.sap-ag.de/~sapidb/011000358700000185812008E/LOG_CW07_How_to_update.wrf]. If I've properly understood and consolidated the information, maintaining prices must be done manually or with the Update Parent Item Prices Globally function. Manual updates would be incredibly time consuming, and frankly, unacceptable. The UPIPG function will yield correct results only if it is performed from the lowest level subassembly BOM's first and finishing with the top-level finished goods. As far as I know, SBO has no "low-level code" in the item master to indicate the lowest BOM level in which it appears. Therefore, using the UPIPG function would still be a manual process and there is insufficient information to guide a user through the correct sequence.
The only solution I can see would involve creating an external program, which could be run periodically (e.g., nightly or on-demand). The output of this program would be an updated price list for all items, reflecting current costs. The program would first dynamically create a temporary table containing each item and its low-level code. Then, it would explode and cost BOMs starting from the lowest level, and progressing up the levels. Each higher level would use the newly-updated prices for the lower levels. The only SBO table updated would be the price list.
I've already scoped and prototyped this program, but wanted to check if there are other alternatives. Any feedback would be much appreciated.