Inventory Tracking

​

Definition

TWICE Commerce supports two distinct inventory tracking methods. You choose the mode when registering stock: the Track individually toggle (trackIndividually in the create request) decides whether each physical unit gets its own Stock Item record or whether one record covers the whole quantity.

1. Serialized inventory — each physical unit is tracked individually. Every unit gets its own Stock Item record with its own codes, condition, income and expense records, and event timeline.
2. Pooled inventory — multiple identical units are grouped under a single Stock Item. Tracking is aggregated — you know the pool’s total income, expenses, and utilisation, but not per unit.

The choice you make has direct consequences for how granular your operational data will be.

​

Where do I use it?

You set the tracking method when creating a Stock Item — in the Register stock items dialog (the Track individually checkbox) or via the API (trackIndividually on the create request body; defaults to true).

• Track individually checked + quantity N → creates N serialized Stock Items, one per unit.
• Track individually unchecked + quantity N → creates one pooled Stock Item covering N units.

trackIndividually exists only on the create request — it controls how many records are inserted. It is not stored and does not appear on Article responses. On responses, quantity is an object with total and a byLocation breakdown; a serialized item reports quantity.total = 1, a pool reports quantity.total = N. Read more: Register stock items.

​

Quick comparison

​

When to use each method

​

Use Serialized (Qty = 1) when

​

Use Pooled (Qty > 1) when

​

Data implications

​

What you gain with serialized

• Precise attribution — know exactly which unit produced specific income or incurred specific costs via its Income & Expenses records.
• Individual lifecycles — full audit log per unit: when it was bought, where it has been, who has used it, when it was serviced.
• Detailed timeline — every order, reservation, and note attaches to a specific unit.
• Item-level ROI — pull per-unit profitability and identify under-performers to retire or refurbish.
• Maintenance history — service events tied to the unit they describe.
• Recommerce ready — when you eventually sell the unit, the full provenance is attached.

​

What you lose with pooled

• No individual attribution — cannot say which helmet in the pool earned which revenue or needed which repair.
• Aggregated timeline — events log count changes (“3 units handed out”) not identity changes.
• Pool-level ROI only — you can calculate average ROI per unit but not per-instance.
• No per-unit condition tracking — one condition value for the whole pool.

​

Example side-by-side

Serialized. Stock Item art_bike_1234 (qty 1):

• Codes: BIKE-1234, SN240501234.
• Income & Expenses: +€500 rental income; -€150 repair on Jan 10.
• Activity log: 15 handed_out and 15 returned events.
• profitability: €350. You know it earned this specifically.

Pooled. Stock Item art_helmet_pool (qty 50):

• Codes: HELMET-POOL.
• Income & Expenses: +€5,000 total helmet rental income; -€300 for replacement helmets purchased.
• Activity log: count deltas (e.g. “10 units out”, “9 units returned, 1 lost”).
• profitability: €4,700 for the whole pool. You know what the pool did, not what helmet #17 did.

​

Choosing the right mode at creation

The mode is decided at creation. In-place conversion between modes is not supported — if you need to change, create new records in the desired mode and migrate. That makes the choice important up front. Use this checklist:

• Is this item rentable? → Serialized.
• Does it have a serial number you care about? → Serialized.
• Does it depreciate or need maintenance individually? → Serialized.
• Is it one of 50 identical low-value consumables? → Pooled.
• Are you fine with pool-level ROI? → Pooled.

Most TWICE merchants run a mix: serialized for the rental fleet, pooled for accessories and consumables.

​

Migration between modes

There is no in-place conversion. To switch:

• Serialized → Pooled. Create a new pooled Stock Item with the desired quantity, retire the existing serialized items by setting their status to Inactive. Historical income and expense entries stay attached to the retired records and continue to count in reports.
• Pooled → Serialized. Create new serialized Stock Items (one per physical unit) using the same SKU. Reduce the pool quantity via POST /articles/:id/decrease-quantity once the new records exist.

In both directions, the existing income and expense records and events on the old records are preserved. Reporting tools sum across all records sharing a SKU, so historical data continues to count toward SKU-level performance.

​

Impact on availability calculations

Both modes feed the same ATS engine, but differently.

• Serialized. ATS counts the number of individual Stock Items at a location whose status is Active and that are not committed (via order or reservation) to overlapping ranges.
• Pooled. ATS reads the pool’s total quantity (quantity.total), subtracts the count of units currently committed (via orders consuming from the pool or reservations applied to the pool), and the remainder is available.

Reservations on serialized items pin a specific unit; reservations on pooled items pin a number of units. Use serialized items if the operator workflow requires guaranteeing a specific physical item — pooled items can be substituted within the pool freely.

​

Impact on reporting

Reports that group by Stock Item show one row per serialized unit but only one row per pool. To compare apples to apples across modes:

• Group by SKU — both serialized items and pools roll up under their SKU.
• Filter on the quantity field when you specifically need one mode — pools have a quantity greater than 1.
• For per-unit insights on pooled stock, you generally need to convert to serialized first.

​

Relationships

​

FAQs

​

Developer Reference

Tracking mode is set on creation via trackIndividually on the articles endpoints.

​

Related Concepts