Products

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 type — Consumable or Returnable (see below). Required, and deliberately not pre-answered: only a Returnable Product can be checked out, loaned or rented, so a default would decide that for you on every Product you create and only show up much later, as a catalogue nothing can be lent from. Once a category holds Products, picking that category prefills the usage type those Products mostly use — that is inferred from your own catalogue, so you can still change it.
• 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).
• Backorderable — Yes, 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.

Importing a catalogue from a spreadsheet #

Inventory → Products → Import CSV brings an existing catalogue in from a file, which is usually the first thing you do on a new account. Upload the file, check the column mapping the app guesses from your headers, and start the import. Download example CSV file in the same dialog gives you a file with the right headers to work from.

Only Name is required. Everything else is optional, because a real export from another system is always missing something. Money goes in as dollars (24.99, or $1,234.50 — both work) and is stored in cents; a Category is matched by name and created if it is new; Usage type accepts consumable / returnable as well as plain English like equipment.

A file is matched by SKU. A row whose SKU is already on a Product updates that Product; a row with a new or blank SKU adds one. That is deliberate — it means re-importing a corrected file fixes the first import instead of duplicating it.

While it runs #

Large files are processed in the background, so the page comes straight back and tells you how many rows were accepted. The result arrives as a notification in the bell menu when the run finishes — you do not have to stay on the page. It says how many Products were imported, how many rows were not, and offers a download of the failed rows with the reason against each one.

A single import takes up to 20,000 rows. A bigger file is refused whole, with nothing half-written: split it and import the parts one after another. Because rows are matched by SKU, importing the same file in pieces is safe.

What your role lets you import #

Importing is a write, and it needs one of the two Product permissions:

You hold	What the import does
Add a new Product only	Adds the Products that are new to you. Any row whose SKU matches a Product you already have is refused and reported — that Product is left exactly as it was.
Change a Product only	Updates the Products the file matches. Any row that would add a new Product is refused and reported.
Both	The whole file.
Neither	The button is padlocked and nothing can be imported.

Refused rows are never silent: they are counted separately from the successes, and each one comes back in the failed-rows download with the permission it needed. Setting Price or Cost is a third, separate permission — see Users, Roles & Permissions — and a priced row from someone who does not hold it is refused the same way, rather than imported with the price quietly dropped.

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 a Qty per unit and a unit of measure — how much of that material one finished unit takes, in the measure the material is stocked and sold in. A work order multiplies it by the quantity planned, so a line reading 100 lb on an order for ten units needs 1,000 lb. Note that this is a measure, not a count of packs: 1,000 lb of a product stocked in 50 lb bags is twenty bags, and twenty bags is what a work order takes off the shelf. The unit of measure auto-fills from the material Product when you pick it, and it is worth leaving it there unless you mean something else.

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 column reads Low for anything below its reorder min and OK for everything else. 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.