Using packages on sale lines

When using EAN14 barcodes there are two quantities two manage on order lines:

  • The number of packages.
  • The number of units to be sold. (Which can be computed with: quantity of packages * package size).

In such case it is quite common that the user sets the quantity using the package size, and the final quantity (which determines the unit_price) is updated acordingly.

I tought using secundary units for this, but the problem is that we may have multiple secondary units. Let me explain:

A pencil can be sold in the following packages:

  • A package of 6 units
  • A box of 10 packages, so 60 units.
  • A pallet of 120 box, 7200 units.

But a pen can be sold with:

  • A package of 9 units
  • A box of 8 packages, so 80 units.
  • A pallet of 100 boxes, 8000 units.

For each product the rate of package, box, and pallet conversion it is different which forces the user to create a different units for each product, which makes nearly unmanegable when the number of products starts to grow.

Packaging should not be managed with unit of measure.

I would rather use a new model for such case. Create the product for just one unit and then add several ‘pacakges’ with the name and quantity. Maybe something like GitHub - NaN-tic/trytond-product_package can help you. The barcode then should also live on that level and searching the product should also search the new model.

Personally I’m using GitHub - NaN-tic/trytond-product_barcode to add several barcode types to the same product.

So how should be managed?

I’ve seen that but I do not like the fact that package is just a name that is defined on each product instead of a realted table.

This sounds like what I proposed in Handle EAN14 Codes (#13107) · Issues · Tryton / Tryton · GitLab but reusing the identifiers instead of a new table for setting codes. This seems a duplicat esource of information.