 |
|
Topic: Monitoring the cost of a BOM over time?
|
| By: Simone | Posted on: Mar 2 2025 at 11:33:45 AM | Dear Support,
I would suggest, if it is not too expensive, to integrate a function into the program to track the cost of an assembly on a specific date. This would make it possible to monitor the progress of the increases suffered by suppliers and to easily make comparisons between different dates, so as to promptly update the selling price to the customer. I don't think it's impossible, drawing the purchase prices from the purchase order archive of each component ("Components" > bookmark "Purchase orders" > "All orders").
At the moment I don't think there is any other way to collect this information other than "photographing" the cost of a BOM (for example at the end of the year) and archiving it for future reference. Given that supplier prices are then continuously updated in the program as purchases are made, the problem is that if it is not extracted at the pre-established time, the information is no longer recoverable afterwards. Furthermore, this way of proceeding is extremely impractical, especially if there are so many assemblies to monitor.
Thanks in advance
| |
| By: Ken at DTS | Posted on: Mar 2 2025 at 04:21:50 PM | At present, one can track a Component's over time on the "Purchase Orders" tab. We do this often to monitor the cost increases of components. Tracking the cost of an Assembly over time is equally useful.
Suggested user interface for implementing this:
1. Add a new tab to the Item Detail screen for ASSY (and CSAS?) for "Cost History". Each line in this tab contains a YYYY/MM/DD and the Assembly's cost on that date.
2. To populate the above, on the "Reports" menu item add a "Assembly Cost Capture" button. When clicked, each Assembly's "Build Cost" ("xCost") field is used to create another record in the Assembly's "Cost History".
Details:
1. This might be a lengthy operation. Perhaps place this function under "Setup/Tools" instead of "Reports".
2. Would require adding a new table to store this "Cost History" data.
3. Add a UAC permission to limit the use of this feature?
| |
| By: IanAtMinimrpDotCom | Posted on: Mar 3 2025 at 11:58:59 AM | It might be possible to store the build cost along with each new work order. Then when looking at a list of work orders, as well as work order number, order/build date, order quantity etc. there'd also be a column showing the build cost on that date.
This would not be difficult to do and could be rolled out in a minor update at any time. But it would only be able to show build costs that occurred after that update was rolled out. I don't know how useful that would be.
In the Database Utils/Tools area there's a 'Check/Resync' button. It 'could' be possible to add a fix up process in there that goes back through historic purchase orders to generate the build costs for each past work order ie at the time of that work order. But, TBH, I have no idea how long that process would take. A standard version of MiniMRP running over a slow network you'd probably need to go out for a lunch - or two. With an SQL server doing the leg work it would be MUCH quicker but still . . . . [shrug emoji] I suppose the good thing about this is that you'd only need to run this historic thing once just to get previous work orders. All future ones would be done automatically.
Leave this with me. I'll have a think. | |
| By: Support | Posted on: Mar 15 2025 at 12:15:02 PM | It's not a big job to have the build cost stored along with the Work Order at the time it goes into WIP. This will likely be done in the next update. Sorry. Can't say when that will be. But this would only be visibe when looking at the list of completed work orders and only for work orders completed after that update is installed.
A bigger update where it goes back and looks at historic work orders and calculates the build costs based off of historic purchase orders is unlikely to happen at all. Just too big a job. Sorry. | |
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.
|
|
|
