Skip to content
Knowledge ERP Docs
API Reference ↗
Inventory

Products

The catalogue definition of a thing — name, SKU, price, cost, unit of measure, usage type, components, vendors, and reorder points — shared by every physical unit of that kind.

Product vs. Unit, in one line: a Product is the catalogue entry; a Unit is one tracked item of it. You sell, check out, and count Units; you price, categorise, and reorder Products.

A Product is the definition of a thing you stock — what it is, not any one physical copy of it. "Cordless Drill, 18V" is a Product; the three actual drills on the shelf are Units. The Product holds everything the copies share — name, SKU, price, cost, unit of measure, whether it's consumed or returned — so you define it once and every Unit inherits it.

Naming note: SKU — stock-keeping unit — is an identifier code, not a record type: it's the code you put on a Product, and the supplier's own code on a Vendor SKU link. The record itself is a Product, in the app and in the REST API alike: the endpoint is /api/v1/inventory/products and other resources reference it as product_id — see the API reference.

Creating a Product #

New Products are created from Inventory → Products → New Product. The form is short on purpose — most of the depth comes from the category and from the Units you add later.

  • Name — what the thing is called. Required.
  • Category — places the Product in your category tree (e.g. Tools → Power Tools). The category drives custom fields, lot/ expiration tracking, and reorder defaults, so set it thoughtfully. When you pick a category, the form pre-selects the usage type most common among the Products already in it.
  • Usage typeConsumable or Returnable (see below). Required, and starts on Consumable; picking a category still overrides that with whatever the category mostly holds.
  • Unit Size + Unit of Measure — how much one stocked unit holds, e.g. 1 each, 500 ml, 50 ft. Unit Size defaults to 1 and the unit of measure to item if you leave them blank, which is right for anything you simply count. See Units of Measure.
  • Price and Cost — what you sell it for and what it costs you, entered in dollars. These are the defaults every Unit inherits unless a Unit overrides them.
  • Weight — an amount and unit (e.g. 2.5 lb), used for shipping.
  • SKU — the Product's unique code. Type your own (TARP-6X4-BLU) or leave it blank and one is generated with an S prefix. It must be unique within your account, and it is what a scan resolves to. See Barcodes & Labels for printing it on a label.
  • Has Bill of Materials — turn this on for a composite Product assembled from other Products (see Composite Products).
  • BackorderableYes, No, or Use location default — whether the Product can be sold or committed when no stock is on hand.
  • Custom fields — any extra attributes defined on the category appear at the bottom of the form. See Custom Fields.

Usage type: Consumable vs. Returnable #

Every Product is one of two kinds, and this choice changes what you can do with its units:

  • Consumable — sold or drawn down and not expected back: parts, materials, retail goods, supplies. Its units are used, sold, or consumed, and their remaining quantity ticks down.
  • Returnable (Equipment) — reusable gear that goes out and comes back: tools, AV kit, instruments, fleet equipment. Only Returnable units can be checked out, loaned, or rented.

You can't check out a Consumable or "use up" a piece of Returnable equipment — the actions available on a unit are gated by its Product's usage type.

Categories and inherited fields #

A Product's category is more than a label. Categories are hierarchical (with a full path like Tools → Power Tools → Drills) and they decide:

  • which custom fields the Product and its units carry,
  • whether units track a lot number and/or an expiration date,
  • default reorder points that apply to every Product in the category.

Custom fields inherit down the chain category → Product → unit, so you can set a value once on the category and override it only where it differs.

Composite Products (bills of materials) #

Turning on Has Bill of Materials makes a Product composite — something you build from other Products. On the Product's page, the Components tab is where you list what goes in. A component can be:

  • a specific Product — only units of that exact Product can be consumed, or
  • a category — any unit from a Product in that category qualifies.

Each component records an amount and a unit of measure. Composite Products power both manufacturing work orders and the "build from existing inventory" path when you create units, which consumes the source units automatically. The Used In tab shows the reverse — which other Products list this one as a component.

Vendors and purchasing #

The Vendors tab links a Product to the suppliers you buy it from. Each vendor link can carry the vendor's own SKU number, catalog price, lead time, minimum order quantity, units per pack, and a preferred flag. This is what purchasing and reorder suggestions draw on to put the right quantity on the right purchase order.

Reorder points and stock health #

The Reorder Points tab sets a min and max quantity for the Product, optionally per location (a point with no location applies everywhere). When on-hand stock drops below the min, the Product shows a red low-stock indicator in the list and becomes a candidate for reorder suggestions. Reorder points can also be defined on a whole category and inherited by its Products.

The Product list #

The Product list (Inventory → Products) shows each Product with its category path, SKU, price, unit count, and total inventory (the summed on-hand quantity in each Product's unit of measure). A stock icon flags anything below its reorder min. Filter by category, location, stock status (below/above min), or backorderable, and toggle In stock only to base the counts on available stock rather than everything on the books.

What lives on the Product page #

Open a Product to find its definition plus tabs for everything attached to it:

  • Units — every physical unit of this Product and its current status.
  • Components / Used In — its bill of materials, and where it's used.
  • Operations — manufacturing steps, if any.
  • Vendors — suppliers and their pricing.
  • Reorder Points — min/max thresholds by location.
  • Change history — a full audit trail of edits.

Doing it from the API #

# List Products
curl "https://your-domain.com/api/v1/inventory/products" \
  -H "Authorization: Bearer $TOKEN"

# Create a Product
curl -X POST "https://your-domain.com/api/v1/inventory/products" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Cordless Drill, 18V", "price": 19900, "usage_type": "checkout"}'

Prices and costs are sent and returned in cents over the API (19900 = $199.00), even though the UI shows dollars. The usage_type field accepts "use" (Consumable) or "checkout" (Returnable equipment) and is also returned on every Product response.