Skip to content

Conversation

@edescalona
Copy link

@edescalona edescalona commented Dec 19, 2025

@BinhexTeam

It is advisable to display a price on the product label in a different unit of measurement. This module allows you to define that unit of measurement through configuration, calculate its price based on the ratio, and display it on the product labels.

Example:
* Price based on initial unit of measure (kg): $100 per kg
* Price based on reference unit of measure (lb): $50 per lb

report_print_labels

@edescalona edescalona marked this pull request as ready for review December 19, 2025 17:03
Copy link
Contributor

@legalsylvain legalsylvain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi. Thanks for sharing this interesting feature.

I have some design question about the current implementation.
Why did you created a product.uom.reference model. (Why not just add uom_reference_id on product.template).
I see it more simple, and it avoid to force user to compute ratio that can be deduced from ratio of the both uoms.

thanks !

@rrebollo
Copy link

@edescalona please consider @legalsylvain suggestion, then tag me to review.

@edescalona
Copy link
Author

Hi @legalsylvain @rrebollo , the goal is for the reference unit to be any value and with a ratio defined by the user. Hypothetical examples:

20 apples at €25
3 lbs of apples at €6

Any suggestions are welcome, thanks.

@rrebollo
Copy link

@edescalona from a reviewer perspective, and based on what is currently described, this looks closer to the existing price rules flow than to the units of measure flow.

If the behavior you are modeling matches concepts that already exist (or could naturally exist) as price rules in the system, then that might be the more appropriate mechanism to build on, rather than introducing it under UoM logic.

In that case, the addon name should be adjusted accordingly, as it should already indicate that the outcome of this feature is the ability to reflect alternative prices on product labels when label reports are printed. Along the same line, the documentation should be updated to make this explicit and avoid misunderstandings like the ones the other reviewer and I initially had.

Additionally, if this implies a change in the base workflow (as suggested above), it may also be worth reconsidering whether this PR belongs in this repository at all, and if it would fit better in another one more closely related to sales or reporting concerns.

@rrebollo
Copy link

That said, @edescalona you are the one who has the full context — requirements, constraints, and target use case — so our role here is simply to provide feedback and raise these considerations, leaving the final design and implementation decisions to you.

@arielbarreiros96
Copy link

@rrebollo @legalsylvain @edescalona I'm bringing some context to the discussion. This module comes to solve the requirements posted on EU laws for unfair pricing (the easy comparison one, which only affects labeling), please see links below for context.

Take this example for instance:

Sarah was shopping for pasta and tomato sauce. She found a 500g pack of pasta priced at €2.50 in one store and a 1kg pack at €4.50 in another. At first glance, the smaller pack seemed cheaper, but when Sarah checked the unit price (€/kg), she realized that the 500g pack was €5.00 per kg, while the 1kg pack was €4.50 per kg.
Thanks to the unit price comparison, Sarah saw the 1kg pack was the better deal and decided to buy it instead.

In order to actually see the price per reference unit, I think is better to define a ratio, that could be re-used for other products (different flavours, colours, etc. most like not for different sizes or packages). Notice that the ratio depends on the product, two almost exact products may have totally different ratios.

Notice as well that the actual unit of measure of the product may have nothing to do with the original unit, we could set the referenced unit as kg for products sold by unit. Or even by very unusual unit of measure, for example in Spain some supermarkets selling detergent by bottles, show the referent unit of measure to "dose", representing how much each cost to do each laundry. Again, this is only for the labeling.

Given that this is indeed a very niche feature, it's arguable if it belongs to this repo, but I don't know if there is actually a repo for product labeling 😅

https://europa.eu/youreurope/citizens/consumers/unfair-treatment/unfair-pricing/index_en.htm
https://eur-lex.europa.eu/legal-content/ES/ALL/?uri=CELEX:31998L0006

@epieters
Copy link

Yes, makes sense, since this is label only.

Maybe some overlap with the website module?
image

@edescalona
Copy link
Author

Hi @epieters , I'll check with the option you mentioned to see if there's any overlap, thanks.

Copy link

@epieters epieters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to have this on the product.
Need to make sure that there is no overlap with the website module.

@edescalona
Copy link
Author

edescalona commented Dec 22, 2025

Hi @epieters , I've reviewed the option you mentioned and it doesn't overlap with the functionality of this module. Let me explain.

The "Product Reference Price" option enables the "UOM Price Display for eCommerce" group, which allows you to display the following fields in the product template:

image

8.20: The value by which to divide the selling price.
Value X: Any name defined in a website.base.unit model.
($12.20/Value X): Selling price (100)/8.20

When you configure these values, ($12.20/Value X) is displayed as the reference price in the product view on the eCommerce site. Keep in mind that it assumes they are in the same unit of measure and is not displayed in the product labels.

image

I believe these are distinct functionalities and they can coexist.

Copy link

@rrebollo rrebollo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review. LGTM! Even so, I suggest you change some names to better fit addon's goal. You got my approval. Good work.

@epieters
Copy link

Hi @epieters , I've reviewed the option you mentioned and it doesn't overlap with the functionality of this module. Let me explain.

The "Product Reference Price" option enables the "UOM Price Display for eCommerce" group, which allows you to display the following fields in the product template:

image 8.20: The value by which to divide the selling price. Value X: Any name defined in a `website.base.unit `model. ($12.20/Value X): Selling price (100)/8.20

When you configure these values, ($12.20/Value X) is displayed as the reference price in the product view on the eCommerce site. Keep in mind that it assumes they are in the same unit of measure and is not displayed in the product labels.

image I believe these are distinct functionalities and they can coexist.

Since this property achieves the same as the one implemented on the product level, could this field not be used on the product label as well?

@edescalona
Copy link
Author

edescalona commented Dec 22, 2025

@epieters For what you suggest, another module should be created, since this one does not depend on the website_sale module, which is responsible for displaying the fields mentioned above.

@legalsylvain
Copy link
Contributor

Hi @edescalona. I have no clear point of view regarding the design.
So no blocking point for me. If all is OK, we can merge it and move on.

@edescalona
Copy link
Author

ping @epieters

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants