[WIP] Pricing plugin

[SchrodingersGat]

This PR implements a plugin system for pricing integration.

• The default plugin provides a base pricing structure which matches the previous code for backwards compatibility.
• Custom plugins can be implemented to override or extend part (or all) of the pricing functionality
• This is an initial implementation that can be extended in the future
• The scope of this PR is just to implement the plugin structure for pricing

Breaking Change

This PR introduces a breaking change - the existing global settings for adjusting pricing behavior have been moved to the (newly introduced) default pricing plugin. This means that if you have adjusted the default values of the pricing configuration settings, these settings will need to be re-adjusted against the new plugin.

Tasks

• Documentation for new plugin mixin
• Documentation for custom pricing functions via plugins
• Move pricing configuration settings to the default plugin
• Remove duplicated pricing settings from the global settings list
• Move all pricing functions to a plugin-driven code structure
• Document the default pricing plugin
• Document each setting for the default pricing plugin
• Reimplement functionality for calculating cost of "stock on hand"
• Migrate update_bom_cost
• Migrate update_purchase_cost
• Migrate update_internal_cost
• Migrate update_supplier_cost
• Migrate update_variant_cost
• Migrate update_overall_cost
• Migrate update_sale_cost
• Add plugin hooks for calculating the quantity purchase pricing for a part
• Add plugin hooks for calculating the quantity sale pricing for a part

Talking Points

1. Can we (or should we) support having multiple pricing plugins operating, allowing a custom plugin to implement only a part of the functionality?

2. If not 1) then how to we support a custom plugin which only wants to make a "small" change. Does the plugin need to re-implement all functionality?

[netlify]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	a4b7f12
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/68fc51d89a93020008f70508

[codecov]

Codecov Report

❌ Patch coverage is 76.80000% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.64%. Comparing base (8e1d621) to head (52d32c4).

❌ Your patch check has failed because the patch coverage (73.33%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10669      +/-   ##
==========================================
- Coverage   87.84%   87.64%   -0.20%     
==========================================
  Files        1276     1279       +3     
  Lines       57478    57556      +78     
  Branches     2031     2031              
==========================================
- Hits        50490    50446      -44     
- Misses       6488     6610     +122     
  Partials      500      500              

Flag	Coverage Δ
backend	89.33% <76.80%> (-0.25%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Backend Apps	91.63% <80.00%> (-0.32%)	⬇️
Backend General	93.51% <73.33%> (-0.16%)	⬇️
Frontend	70.05% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[matmair]

Interesting approach; Regarding your questions:

1. Can we (or should we) support having multiple pricing plugins operating, allowing a custom plugin to implement only a part of the functionality?

For now, I think only having 1 plugin active will make things simpler

2. If not 1) then how to we support a custom plugin which only wants to make a "small" change. Does the plugin need to re-implement all functionality?

Maybe - this is mainly a thought experiment - developers could use inheritance? If the default plugin is split up enough in their function that should be reasonable

On a more general note: I think this is a good step, but still not a stable footing that satisfied the request we are getting. Looking at #8607 . We definitely should think about changing calculations and changing the data structure we use to save prices and price calculations. We ignore time for example right now - time can be very important for price and cross-currency pricing

[SchrodingersGat]

Do you have any suggestions for specific changes to the data structure?

[matmair]

I have not looked deeply into it as I am currently working on #4022, but I thought about it a bunch of the RFQ request.

Currently, in my mind, the following fields would make sense in the DB; not all needed in the API:

• Calculation meta: plugin, plugin version, calculation date
• if the value was calculated or set manually
• money value in decimal and currency (already there)
• maybe some correlation to the calculation run
• maybe some references to the data that was used (currency exchange rates come to mind)

These would ensure that faulty calculations can be identified and re-run and that we can try to get calculation stability