Topic: Purchasing doesn't update item price
|By: GaryM||Posted on: Aug 5 2019 at 12:04:34 AM|
|I'm seeing this... I create a purchase order, add the item required, quantity, and price per item. I then subsequently receive the order and use goods in the receipt them. I notice then that the price (which has changed since the last time the item was purchased) is not updated in the inventory item database. This has happened on multiple purchases.|
Is there anything I'm missing?
|By: Guest||Posted on: Aug 5 2019 at 12:25:09 AM|
|I wouldn't want minimrp to change the default price of an item based on the last PO price. (It doesn't, never has)|
If I have 100 of an item in my inventory and they cost me $1 each and I manage to buy another 5 on a special price of $0.50 then if minimrp changed the default price to 0.50 then that would reduce the build cost of my assembly.
Basically I want to be able to set my default price for the purpose of calculating build costs but when I come to buy more I want to be able to negotiate better prices if possible from my supplier without changing my default build costs.
Now if minimrp decided to add an option in setup that enabled/disabled price update then I would be able to disable it and you would be able to enable it and we'd both be happy.
|By: Guest||Posted on: Aug 5 2019 at 04:53:24 PM|
|This is a major flaw then. I need to know the value of my inventory. That means if I buy 100 of a part at 10c each I have $10 worth of inventory. If I later buy 200 at 8c each and have used none in the meantime (simplification) I now have $26 worth of inventory. It is now costing me $0.087 each time I consume one of these. This is where accounting meets production costing. Without this it is entirely useless to a business tracking their financial performance.|
|By: Guest||Posted on: Aug 6 2019 at 01:55:55 AM|
This is where MRP starts getting really complicated and beyond the scope of MiniMRP.
To do as you wish you need to track the cost every time you purchase an item then track where its was used, you then get a true cost of every individual build.
This is possible but not for $190, the last system I used could do this but cost $50,000!
|By: Guest||Posted on: Aug 6 2019 at 03:15:21 AM|
|Last MRP system I used that had this capability had a whole window full of options to set up the different ways to do this based on FIFO, LIFO, Average cost, current cost and even different values depending on whether it's producing a year end valuation report for an accountant or the future build cost of an assembly for the sales department.|
It also had a couple of training sessions showing us how to use that feature and, guess what, the most important thing we learned during the training session was where the Off switch was to disable it completely because none of the options actually matched the way we did things.
|By: Support||Posted on: Aug 6 2019 at 03:52:51 AM|
|Select an item in your inventory and look in the Item Detail window in the 'Suppliers' tab.|
In there you can add an unlimited number of different prices from an unlimited number of different suppliers in an unlimited number of different PRICE/UOM/QTY combinations.
Even though you can have many different prices for the same item we always use the price from the top row as the default. That's the price we use for inventory valuation and when calculating build costs.
It's likely that you'll often purchase items at one of the other prices. For example you'll buy a BAG or BOX of items at a lower price per item. If we automatically update the price based on that UOM/QTY then that would still not change the default price of the item.
What I've said so far is not really a problem and maybe we could add an option to setup which would make that happen (please tell us if you want us to do that)
But, as I said above, buying a box at one of the alternate prices would not update the main/default price.
So maybe we need to calculate build costs based on average cost. But then the cost shown in the column in the BOM would not be the same as 'ANY' of the costs shown in the item detail. We'd need another cell in the item detail window and a column in the all items grid to show the rolling average cost of the item so that users know where that BOM cost is comoing from. This I fear is too much for a "Mini" MRP.
Doing just a little opens up a can of worms. Doing a lot simply blows the the MINI out of MiniMRP.
|By: GaryM||Posted on: Aug 6 2019 at 07:11:44 PM|
|I've discussed this separately with minimrp support. I'll copy my perspective here... I come from a large accounting system and an embedded inventory module. Minimrp can do what is required and still be mini, the refinement is small. The bottom line is that as business people we want to track our profit and ensure our costing are accurate... What I've suggested below is how it is done correctly in an accounting environment.|
I'm fairly sure what I am looking for is simple to implement, and essential to allow minimrp to meet customer expectations. (Even if customers don't know what they actually need)
Essentially minimrp is an inventory system. A fundamental requirement of an inventory system is to be able to reliably and accurately track inventory value. At the end of each financial year it should be able to create an inventory report that matches the movement in stock value during the year. It needs to have recorded the prices paid for items, their changed value and the numbers consumed. This report is an important element in measuring business performance and profitability. It impacts on taxation records that by law must be accurate.
(I'm coming from a stock system that was an integrated component of a larger accounting system)
Minimrp tracks stock numbers as they are consumed and purchased, but not, it seems stock value.
What I would suggest are these additions...
A switch to turn on or off "update item supplier purchase price from purchase orders"
This would allow the purchase price entered on a purchase order to update the cost field for the item for the appropriate supplier when the goods are receipted. As it is now you have to manually transfer that in an awkward process.
A switch to choose between "item price is that of default supplier or is a running average"
This again is a simple option. The current situation is that the item price is that of the default supplier which has to be manually maintained. The running average is easily calculated at the time a purchase order is receipted. Its just the current item total stock value + the value just purchased divided by the total now in stock. The running average accurately tracks what you have actually spent and how much that item costs when consumed.
With this second option turned on the system begins to accurately record the real stock value held and becomes an important business tool by being able to correctly track the cost of manufacture and report actual inventory total value. It will show exactly what has been spent by the business and can integrate into the businesses accounting system. It will allow you to see in real time exactly what your build costs are when using assemblies...
I can't see how anyone would not want this. As business people we need to know from day to day, week to week, and year to year how our costs are changing so that we can maintain our profitability. A tool like minimrp can easily ensure this information is maintained without undue effort. At present it requires a lot of manual data manipulation to ensure the stock values are accurate and leaves a lot of room for error.
Modified as suggested minimrp can deliver by user choice, either the questionable status quo, or a more accurate accounting oriented approach that is more fully automated.
I hope this is helpful.
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.