Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split beesdoo_purchase into sale_suggested_price #355

Open
carmenbianca opened this issue Apr 5, 2022 · 7 comments
Open

Split beesdoo_purchase into sale_suggested_price #355

carmenbianca opened this issue Apr 5, 2022 · 7 comments
Assignees

Comments

@carmenbianca
Copy link
Collaborator

According to coopiteasy/vertical-cooperative#204, 'depends on product_main_supplier'

@victor-champonnois
Copy link
Member

@robinkeunen @remytms I am wondering wether it should be split to sale_adapt_price_wizard rather than sale_suggested_price. The functionality to split is "- Allows adapting a product's purchase and/or selling price from a PO." What's your opinion ?

@victor-champonnois victor-champonnois self-assigned this Nov 2, 2022
@robinkeunen
Copy link
Member

I see no wizard in beesdoo_purchase. My suggestion: purchase_order_push_price.

@victor-champonnois
Copy link
Member

victor-champonnois commented Nov 2, 2022

Looking closely to the code, it's confusing to me because I have the impression it does partly the same thing as sale_suggested_price. Both compute a suggested price. The difference is sale_suggested_price includes taxes :

suggested_price = (
price
* uom_factor
* supplier_taxes_factor
* sale_taxes_factor
* profit_margin_factor
)

suggested_price = (price * product_tmpl_id.uom_po_id.factor) * (
1 + product_tmpl_id.categ_id.profit_margin / 100
)

Should we refactor to use the suggested price from sale_suggested_price ? Or am I wrong to say they are the same ?

@victor-champonnois
Copy link
Member

@robinkeunen up :)

@robinkeunen
Copy link
Member

@victor-champonnois the difference I see :

  • sale_suggested_price computes a ratio between the purchase unit and the selling units
  • sale_suggested_price also includes sales and supplier taxes
  • button_adapt_price takes the price from the PO rather than the supplier info

I think for consistency and simplicity, it would be good to use the the price of sale_suggested_price as you suggest.

=> add a dependency and compute with calculate_suggested_price(self, price=<new-price-from-po>)

Good catch 👍

@robinkeunen
Copy link
Member

@victor-champonnois I also think you should warn Yo from Oufticoop when it's in test so he can take a look.

@victor-champonnois
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

3 participants