Automatic BOM price roll-ups

[Former Member]

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.

Dave

[Former Member]

Hi Dave,

Your solution should work. I don't think there is any other simpler ways for this task.

Thanks,

Gordon

[Former Member]

Thanks for considering my question, Gordon.

I pretty much finished the program and initial tests are looking good. In case you're interested, the following is how I approached the problem.

The custom program is an external (DI-API) VB.net program, written as a console application (ie, no UI, command-line startup with parameters, can be initiated via Windows Scheduler). I added a UDF to the PriceList table, and the program updates only those price lists with a value in the UDF. The UDF value is a comma-separated list of warehouses whose inventory should be used to formulate the "current cost". For each PriceList, there are two passes. The first pass processes only BUY items, and computes a "current cost", depending on the cost method and whether costing is global or by warehouse. For FIFO items, an average FIFO cost is calculated across the designated warehouses. For Moving Average, a weighted average of the Moving Averages is determined. For standard cost items, the standard costs are averaged. The PriceList is updated to reflect this "current cost" (which is only a reference value). The second pass processes only MAKE items. Rather than updating a static low-level code each time, I simply flatten each BOM down to it's BUY or non-inventory parts, and use the newly-updated prices for the BUY items. Each make item's price is updated in the PriceList, if there's been a change. A bit of recursive programming made the BOM explosion fairly easy.

The result is one (or more) PriceLists that reflect an averaged cost for non-make items, and essentially a BOM rollup cost using the updated component costs. We'll be running it nightly, which should provide fairly good reference values. I'm still hoping that SAP will, at some point, add some kind of automated BOM rollup functionality that responds to changing component costs.

Dave