In short
quantity_base). Purchase order lines are in purchase units; bill lines you send are in the product's inventory unit.quantity_base / (uom_qty * uom_base_conversion).quantity_base by a purchase cost. The result has no meaning.A NutraSoft product is counted in more than one unit: a base unit for stock, the unit people see, the unit it is sold in and the unit it is bought in. The API never makes you guess which one a number is in. A partner who assumes one unit throughout computes numbers that are wrong by a conversion factor and still look plausible.
| Unit | Where you see it | What it is |
|---|---|---|
| Base | quantity_base, order_qty_base, step quantity_base | The product's base unit, the canonical stock unit. |
| Inventory | price, cost, operations_cost, minimum_on_hand and maximum_on_hand on products | One packaging unit of the product: uom_qty * uom_base_conversion base units. |
| Display | production_qty_display_units, produced_qty_display_units | The unit a person sees for that product in NutraSoft. |
| Line unit | order_qty on sales order lines | The unit the line's uom_type names. |
| Purchase | quantity and cost on purchase order and bill lines | The unit you buy the product in, often a case or a drum. |
| Grams | portion_in_grams, recipe_grams_yield | Grams. |
quantity_base, with no conversion in either direction: what you send is what is stored.price, cost and operations_cost are per inventory unit, and minimum_on_hand and maximum_on_hand count inventory units, so divide a lot's quantity_base by uom_qty * uom_base_conversion before comparing it with them.quantity and cost are per purchase unit, which follows the supplier's packaging where one is recorded for the product, and lines also return quantity_base. Multiplying quantity_base by cost gives a number with no meaning; this is the most common unit error.quantity and cost on POST /bills are per inventory unit, uom_qty * uom_base_conversion base units, never a supplier's packaging. If a product's inventory unit is a 25 kg bag, "quantity": 4 receives 100 kg and cost is the price per bag. A bill you read back gives each line in the unit it was received in, which for a bill entered in NutraSoft can be the supplier's packaging, so use quantity_base when you need one unit throughout.production_qty_display_units is in display units, while planned_steps and consumed_steps quantities are in each component's base unit, and output.quantity_base is in the finished product's base unit.order_qty is in the line's uom_type and order_qty_base is the same quantity in base units. A line's price is per unit of its uom_type.Products and lots carry two conversion factors, uom_qty and uom_base_conversion. How many base units one unit holds depends on uom_type:
uom_type | Base units in one unit |
|---|---|
BASE_UOM | 1 |
INVENTORY_UNIT | uom_qty * uom_base_conversion |
PACKAGING_SIZE | uom_base_conversion |
base_quantity = quantity * base_units_in_one_unit
inventory_quantity = quantity_base / (uom_qty * uom_base_conversion)uom_qty is often 1 in test data and something else in production, so a converter that uses only uom_base_conversion looks correct until it meets a real catalog. A missing factor counts as 1.Send order_qty in the unit uom_type names; it defaults to BASE_UOM. NutraSoft converts it to base units with the product's factors at the moment the line is written, exactly as the NutraSoft order form does, and the response returns both order_qty and order_qty_base. A later change to the product's factors does not rewrite existing lines.
Money follows the same rule as quantities: a price or cost is per the unit next to it. Scales, rounding and currency are in Conventions.