[BUG?] Purchase Price on StockItems seems to not been used in pricing calculations

[simonkuehling]

Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find a similar issue

Describe the bug*

When adding a StockItem to a Part manually (not derived from a purchase order), I can add the "Purchase Price" of this StockItem. This is not used for pricing calculations in the Part view, though. Could it be that manual purchase price values are skipped during pricing calculations since there is no PurchaseOrder linked to it?

I am running the Docker Dev setup - but confirmed the same in the demo instance.

Steps to Reproduce

1. Open a part view of a part that has no stock.
2. Add a StockItem (through [Stock] --> [New Stock Item]) and enter a "Purchase Price" in the form.
3. View the [Pricing] overview tab.

There is still a "No purchase history data available" in the graph. The purchase pricing information is also not used for calculating the price-range in BOMs.

Expected behaviour

I would expect that this price tag would be used like those that are linked to purchase orders.

The main reason that I have a lot of parts without purchase orders is that I am currently adding a huge existing inventory of parts to my system that have already been purchased, but I have the purchase price information available and would love to use it in pricing calculations of BOMs and such.

Deployment Method

• [X] Docker
• [ ] Bare metal

Version Information

Version Information:

InvenTree-Version: 0.10.0 dev Django Version: 3.2.16 Commit Hash: e730b5c24 Commit Date: 2023-01-10 Database: postgresql Debug-Mode: True Deployed using Docker: True Active plugins: [{'name': 'IPNAutoGenerator', 'slug': 'ipnautogenerator', 'version': None}, {'name': 'Brother Labels', 'slug': 'brother', 'version': '0.6.0'}]

Relevant log output

No response

[SchrodingersGat]

Your observation of current behaviour is correct - purchase pricing "range" data are calculated only from purchase orders, not individual stock items. I can see the value especially if you are entering large amounts of stock data manually.

[simonkuehling]

Ah ok, understood... do you think it is possible to add these values in the current calculation system without too much work? I am unsure how to treat the purchase price date-wise, though... I think the date of creating the StockItem could be good enough here. The need to add the price manually like this should only be necessary during setup of InvenTree with existing stock data, after all...

[simonkuehling]

Your observation of current behaviour is correct - purchase pricing "range" data are calculated only from purchase orders, not individual stock items. I can see the value especially if you are entering large amounts of stock data manually.

I had a quick search through /part/models.py and found that both get_price_range() and get_bom_price_range() look like they can already calculate the price range based on StockItem.purchase_price values (by the purchase argument).

Unless I am missing something, couldn‘t we use this as a fallback if no other pricing is available for the part?

[cabottech]

I've just discovered this same issue after importing a ton of parts data from PartKeepr during our migration to InvenTree.

I really want this pricing information in BOMs, etc. Falling back to StockItem Purchase Price if no Purchase Order Unit Price is available would be a good solution for us. Perhaps this could be an option if not useful for all users in general?

Update: I just noticed if I click the 'Pricing' ($) icon at the top of an 'Assembly' Part page, it shows a modal with the full BOM price that seems to use the StockItem Purchase Price. This is the only useful price for me, so I'm relieved I found that! The Part Pricing Overview page (with the nice charts, etc) and BOM table seems to only use Purchase Order Unit Price. So I'm thinking the StockItem Purchase Price could be used to fill all the gaps and provide complete pricing for users like me with lots of imported parts data without purchase orders.

Whatever the solution, I'm happy to help fund this with a $500 one time sponsorship on the project. Please let me know.

[SchrodingersGat]

@simonkuehling yes it is possible, just need to write the code to make it happen :)

@cabottech thanks for the input. If you are willing to sponsor this feature I'll make sure it's in by the next stable release :)

[cabottech]

@cabottech thanks for the input. If you are willing to sponsor this feature I'll make sure it's in by the next stable release :)

Done, and thank you. We're really enjoying using InvenTree :)

[SchrodingersGat]

@cabottech thanks for your kind feedback. It is very rewarding to see our users benefiting from our work (and it helps make the project better too) :)

[SchrodingersGat]

@cabottech @simonkuehling this has now been merged, but we are looking into some docker issues before it will be available :)

[simonkuehling]

@SchrodingersGat that is awesome - also thanks towards @cabottech for sponsoring this! I will test as soon as the docker issues are fixed, already really looking forward to it.

[cabottech]

@SchrodingersGat thank you! :)

[simonkuehling]

@SchrodingersGat is there possibly a way to manually run the daily check_missing_pricing() task? Would be nice for checking if it works on all entries since it is limited to 250 entries per run (if I am not mistaken). Also, does the DAILY schedule count from server start time or is it a fixed time in the day?

[SchrodingersGat]

There's not an easy way to run that, and I don't think it would actually do what you expected it to - as pricing has already been calculated for those parts, the check_missing_pricing function would actually just skip right over them. Probably the "simplest" solution is to delete all the pricing cache data (via the admin interface ) and then wait for the next day and pricing will be updated.

If you have command line access to the server, it is possible to run check_missing_pricing manually (if you are interested)

[simonkuehling]

[...] as pricing has already been calculated for those parts, the check_missing_pricing function would actually just skip right over them.

oh, sure - that would not make a difference then..

Probably the "simplest" solution is to delete all the pricing cache data (via the admin interface ) and then wait for the next day and pricing will be updated.

If you have command line access to the server, it is possible to run check_missing_pricing manually (if you are interested)

I will try deleting the cache, seems like a good-enough solution to me for now - thanks for the tip!