Buying in Boxes, Selling by the Piece: What Units Should Your Business App Store?

If your team buys a product in boxes but uses or sells individual pieces, specify the quantity and its unit together. Choose a stock unit for each product, define the allowed purchase and sales units, and agree how the app converts between them. A field labelled only “Quantity” leaves an important business decision unanswered.

This is a planning guide for a small stock, ordering or job-materials app. It is not a recommendation to commission an inventory system when your existing tool already handles the workflow. First ask the current supplier to demonstrate the cases below.

Follow one product through the business

Begin with a real workflow, using invented product data for the demonstration. What does the supplier sell, what arrives at your premises, what do staff count, and what does a customer order? Those quantities may describe the same goods in different ways.

Odoo's units-of-measure documentation gives buying a large pack and selling individual units as a reason for conversion. Its inventory unit determines how stock and internal transfers are measured. It also describes conversion from purchase units into inventory units. These are documented Odoo capabilities, not a promise that any stock screen will do this automatically.

For your brief, name the unit at every step. “Receive boxes, hold stock in pieces, sell pieces” is more useful than “support quantities”. Ask for the stock effect to be visible before staff confirm a receipt.

A box needs a product-specific meaning

In a hypothetical supplies business, one box of clips contains twelve pieces. Another product's box contains a different quantity. “Box” by itself is not a universal conversion rule.

Record the pack definition against the relevant product or supplier arrangement. If several pack sizes are offered, make them distinguishable in the order form. Do not ask staff to remember which supplier's “box” is meant.

Also distinguish a fixed pack from a variable measurement. If a carton's actual weight varies, a fixed pieces-per-carton rule does not establish its weight. Decide whether receipt requires a measured quantity as well as a carton count. Do not let the app invent a conversion between pieces and weight without a defined product relationship.

Make the price basis explicit

A quantity unit and a price unit must be understandable together. Is the quoted price for one box, one piece or one length of material? Show that basis beside the amount and preserve it in the order confirmation.

Agree how the app handles a supplier quote that uses a different unit from the stock screen. Staff should not have to infer the basis from the size of the price. Currency display and decimal separators are separate presentation choices; they do not define how many pieces a box contains.

Ask the developer to identify where conversion happens and where the original entered quantity remains available. A receipt showing only a converted stock quantity can be hard to reconcile with a supplier document written in boxes.

Decide whether fractions are allowed

For each unit, state whether users may enter fractions and what happens when a conversion does not produce an allowed quantity. A business may permit a partial length of cable but prohibit a fraction of an indivisible spare part. That is your product rule, not something a generic number field can decide.

Choose whether the app rejects an invalid quantity, requests another unit or applies an explicitly agreed rounding rule. Silent rounding is a poor default when it changes what will be ordered or delivered. Keep display precision separate from the quantity used for stock movements.

Changing a pack must not rewrite the past

If a supplier changes its pack size, decide when the new definition takes effect. Recommend preserving the unit and conversion used on a confirmed transaction, rather than making an old delivery appear to contain today's pack size.

Ask what happens to an open purchase order created before the change. It may need explicit review rather than an automatic update. Returns should refer to the original transaction and its units, so staff can explain what is being reversed. These are proposed requirements to agree with your developer, not claims about Odoo's historical-data behaviour.

Demonstrate the complete quantity trail

Use an isolated test copy and agree the expected results before the demonstration:

• Receive a known pack and show the corresponding stock movement in the chosen inventory unit.
• Order the same product using a different allowed pack size without confusing the two.
• Reject or explicitly handle a fractional quantity that the business does not permit.
• Show the price basis on the order, confirmation and relevant export.
• Change a pack definition and verify the agreed treatment of old and open transactions.
• Return part of a receipt and explain the remaining quantity in both relevant units.

Write the outcomes as acceptance criteria, including the unit names rather than bare numbers. If this workflow genuinely needs a custom tool, include the quantity trail when discussing the application scope. The useful deliverable is an explainable movement of goods, not just a dropdown of unit labels.

Source and boundaries

Odoo 19 documentation, Units of measure: https://www.odoo.com/documentation/19.0/applications/inventory_and_mrp/inventory/product_management/configure/uom.html

The source supports the Odoo examples of inventory units, purchase units and conversion. Pack-change history, price-basis presentation, fraction rules and the demonstration checklist are practical requirements proposed for your own workflow. This guide does not specify accounting, tax or legally required product labelling.