 |
|
Topic: Inconsistent Costing of Assemblies
|
| By: Guest | Posted on: Nov 25 2019 at 04:51:53 PM | | I am seeing my cost change for no reason. I have gone through and update component costs. These roll-up into assembly cost as you would think they should, but as soon as I do a re-sync the costing changes. I have done a backup before and after a re-sync and the costing on assemblies change when a re-sync is done. I have one specific assembly that this consistently happens on and i know what component is causing the change. But I seen some assembly cost change by more than 60% from one day to the next. I have done extracts that show the issue but cannot seem to determine why they change in the first place let alone why they change back. If you provide a way for me to upload the backup files to you can see for yourself the one that consistently changes. As far as the random changes, I only have extracts done on different days that show the problem. Is there something I am doing that could cause the symptoms I am see? This issue makes it very difficult for me to trust the assembly costing roll-ups. I forced to verify each and every time the cost of an assembly. | |
| By: Guest | Posted on: Nov 25 2019 at 05:06:03 PM | | Also when I export a BOM for an assembly and sum the cost in the spread sheet, it does not always match what is showing for the assembly cost in minimrp??????? | |
| By: Support | Posted on: Nov 26 2019 at 10:21:58 AM | Recent versions of the software have setup options which enables automatic calculation of cost of components based of FIFO (ie recent purchase orders) rather than the old Default supplier's cost. It may be that something has gone wrong in that area.
But also costing of sub assemblies might give strange results if you have the ability to build a sub assembly in house or buy/contract it from outside at a different cost.
As you said; the best thing is if we can see your data then we can discuss exactly what's happening.
| |
| By: Guest | Posted on: Dec 5 2019 at 06:00:50 PM | | any update on the dB files i sent in? | |
| By: Support | Posted on: Dec 7 2019 at 05:29:25 AM | I'm sure an update was released at the end of November which changed the way BOM costs are calculated.
But please don't install previous updates now. We're due to release another on Monday 9th December. We'll email you on Monday once we've tested your Datafiles with that new release. | |
| By: Guest | Posted on: Dec 7 2019 at 12:39:29 PM | | Where do I get the update and how do i install the update? | |
| By: Guest | Posted on: Dec 9 2019 at 02:57:53 AM | | There's no specific 'update' per se. Just download the program from the downloads page. If the download is newer than your current version it'll update it. | |
| By: Support | Posted on: Dec 9 2019 at 03:05:11 AM | To the 'Guest' who posted the first question at the top of this page - Thanks for sending in your database.
The problem you're seing is because some of your CSAS sub assemblies have a supplier price; in other words they can be bought from outside instead of building them yourself. The two different total build costs you're seeing is because one of them is the true build cost (build everything) and the other is buying the sub assemblies at the vendor's price which obviously affects the total build cost.
The error in MniMRP is that it isn't consistent. It's showing different build costs in different parts of the program without proper explanation.
So. In the latest update MiniMRP only shows the true build cost of everything - ignores the vendor's cost of sub assemblies. This will make it consistent so you should see the same build cost in all windows/areas of the software.
But we need to have a think about what to do about cases where you do wish to always buy the sub assemblies so the vendor's price should be used instead. Maybe we need a different 'TYPE' or some flag/option in the detail of the sub assembly indicating that it should always be bought, never built.
How would you like to do it? | |
| By: Ken at DTS | Posted on: Dec 9 2019 at 06:02:46 AM | We would use a new 'TYPE' (or option) that allows a purchased assembly to contain a BOM (like an 'ASSY') but would present a supplier cost to a higher-level assembly (like a 'PART'). At present, we toggle a purchased assembly's record back and forth between 'PART' and 'ASSY' when we need to update its BOM.
If making the purchased assembly a CSAS is the proper way to achieve this functionality, then let us know. | |
| By: Support | Posted on: Dec 10 2019 at 05:43:35 AM | | One idea we had is that if a CSAS sub assembly had a supplier and price etc then we would automatically use that instead of the sub assembly's actual build cost. That might work for some users but would it work for all? | |
| By: Guest | Posted on: Dec 14 2019 at 11:43:17 AM | | Maybe an embedded drop down list with “buy” or “build” on the inventory item you can then filter and search in the table view for bought items or manufactured items. | |
| By: Guest | Posted on: Dec 15 2019 at 05:20:48 AM | In my opinion, there is two main issues with the way the items are costed first the cost price should not be linked to the first supplier in the suppliers list. Second is how the cost is calculated.
Every ERP/MRP program that I have used keeps the cost price separated from the suppliers. The problem comes in when the default supplier is number one because he is the cheapest but when you want to order there’s never stock so you order from supplier 2 who’s price could be 20% more, now your cost price is out. Most packages provide you with an editable cost field for you to type in a determined cost, which could be the highest priced supplier or average or what ever figure you want. The better packages also provide a calculated cost price which is user defined cost + percentage = calculated cost. Most companies price there assemblies on a cost plus model that’s where this % comes in. labour May be cost plus 120% raw material might be cost plus 20% and other categories might be cost plus 40%. Ideally MiniMRP should consider this way of calculating the items cost and not the suppliers cost. The item could auto update if you use the purchase orders section to push the purchase order price into the item, regardless of which supplier is used. The purchase price would update the items editable cost field and the % previously applied would remain as it was creating a new calculated cost. | |
| By: Guest | Posted on: Dec 26 2019 at 08:39:33 PM | I posted the original issue.
Thanks for explaining the issue and for making the system more consistent. I outsource all my PCBA CSAS. I do this by kitting all the material and delivering it to my subcontractor. The subcontractor only provides labor to build the product. So, based on what you have explained I am adjusting my BOMs for these CSAS to include the subcontractor's labor cost. That will eliminate having a Supplier and BOM cost in the system. Now the only issue I see is that I have to Kit a work order to get the raw parts out of inventory. Then I have to open a PO for the subcontractor. Closing both doubles the inventory on the CSAS. Is it possible to have PO that includes the ability to issue parts to to cover this scenario?
Some thoughts on inventory costing and purchase price.
Typically I use a "standard cost" method of valuing inventory. Basically every year you review costs and update the cost for the coming year. At the same time you set your pricing for your products for the year based on that cost. This is how most major manufacturer's handle inventory evaluation and the basis of their pricing model. What is missing from this program is what is termed "Purchase Price Variance or (PPV). This the difference between the standard cost in the system and what was actually paid when purchased, it could be positive (unfavorable PPV) or negative (favorable PPV) and could be different every time you buy a part. The value of PPV is the cost different times the quantity purchased. If inventory is valued by the purchase price every time a PO is received implies you are revaluing inventory of whatever quantity you have on hand of that part at the time of receipt. In a standard cost model, the value of inventory only fluctuates by POs received at the standard cost and not by changes in the price paid, That is captured in PPV. Having the ability to determine PPV on a monthly basis (actually being able to select the report period would be best) in report form by part number would be a big plus. That gives you the ability to adjust COGS (cost of goods sold) by PPV every month to keep your books more accurately. It also gives you a great place to start when adjusting standards the next time around because you can quickly see which parts are costing more or less than what you planned the last time around. When material prices are very volatile you could adjust standards every quarter. | |
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.
|
|
|
