---
title: "Track serialized pieces and tools"
description: "An item stocked as pieces holds no stock of its own: each physical bar, roll, sheet, tube or container is tracked as its own record, with its own id, its own unit, its own amount and the one location it sits at. This page covers deciding when to serialize an item, adding a piece with its opening receipt, reading and adjusting per-piece stock, the capacity-1 conflict a piece raises on the scheduler when two work orders hold it at once, deleting a piece, and why a reusable tool cannot be stocked as pieces. Pieces take an Owner or Administrator role, and they exist on the web, iOS and Android."
category: "Manage stock"
source_url: "https://www.iotflows.com/docs/inventory/serialized-pieces/"
---
# Track serialized pieces and tools

Track stock as individually identified objects, each with its own size and its own shelf.

---

Most stock is a pooled quantity: 40 M8 bolts on Shelf B, and any one of them will do. Some stock is not.

A *piece* is one physical object of an item, told apart from every other one: this 6 m bar, that 250 kg roll, this numbered container. An item whose stock is held that way is *serialized*, which the interface calls **stocked as pieces**.

Adding, adjusting and deleting pieces takes an [Owner or Administrator role](/docs/admin/roles-reference/). Every other member can read the pieces and their amounts. You also need an item that was created with the pieces box ticked: see [Create and edit items](/docs/inventory/manage-items/).

## When to serialize
Serialize when the answer to "where is *that* one" matters, or when each unit holds a different amount. A shop that buys steel in bars needs to know that bar `SB-3` is the one with 1.2 m left on it, not that it owns 14 m of steel spread across four bars nobody can tell apart.

Do not serialize consumables. A thousand pieces of the same bolt is a thousand records nobody will maintain, and the pooled count already answers every question you have about them. **You do not need pieces if the units are interchangeable**, however expensive they are.

The choice is permanent. **This item is stocked as pieces** is posted only when the item is created, and neither the Edit Item modal nor the item detail renders a control for it.

> **Warning:**
> **Can this be changed later?** No. An item created as pooled stock can never be re-stocked as pieces, and an item created as pieces can never be pooled. The only way out is to delete the item and create it again, which costs you its stock history. Decide before you create it.

### Item versus piece
| | Item | Piece |
|---|---|---|
| What it is | A catalog line: `Steel Bar, 1045, 50 mm` | One physical object of it: bar `SB-3` |
| Identified by | Its name | Its **Piece ID**, stored as the piece's SKU. Every piece carries the parent item's name, so the id is the only thing telling two apart |
| Unit | What one piece *is*: `Bars`, `Rolls` | What is *on* this piece: `meters`, `kg`, `ft` |
| Holds stock | No. A piece-stocked item never moves stock itself | Yes, at exactly one location |
| **On hand** reads | **Pieces on hand**: how many pieces exist, in the item's unit | The amount on this piece, in the piece's unit |
| Reorder point | Counts pieces, so "keep 2 bars spare" is the threshold that means something | Not used |
| Transaction history | Every piece's ledger merged, with the **Item** column on to say which piece each row belongs to | Its own rows only |

The catalog list marks a serialized item with a blue **Pieces** badge, and its **On hand**, **Reserved** and **Available** columns all count pieces rather than material. Pieces are never listed there on their own; they belong to their item. [Low Stock](/docs/inventory/low-stock/) judges a serialized item on how many of its pieces no work order is holding, against the item's reorder point.

## Add a piece with a receipt
1. Open the item from the **Items** tab of Inventory, at `/inventory?select=items`.
2. In the **Pieces** card, select **Add a piece**.
3. Enter a **Piece ID**. IoTFlows suggests the next free `SKU-n`, for example `SB-3`, and skips any suffix already taken. Overwrite it with whatever actually identifies the piece on the floor: a bin tag, a lot number, a heat number.
4. Enter the **Unit** the amount is measured in, for example `meters`. This is the piece's own unit, not the item's.
5. Pick the **Location** where the piece physically sits. A piece is one object, so it gets exactly one.
6. Enter the **Amount** on the piece, using the **+** and **−** tiles or the number field.
7. Select **Add piece**.

**Add piece** stays disabled until the id, the unit, the location and an amount above zero are all set.

IoTFlows then does two things. It creates the piece as a part in its own right, pointing back at its parent item, and it posts an opening *receipt*, the transaction that records stock arriving, for that amount at that location, noted `Piece added`. A **Piece added** toast confirms both.

The item's picture is copied onto the piece so it looks like the material it came from. The piece keeps its own copy, so you can change it later.

![The Add a piece modal for a serialized item, showing the Piece ID, Unit, Location and Amount fields](/images/inventory/inv-piece-01.webp)

*The Add a piece modal, with the piece ID, the unit the amount is measured in, the one location the piece sits at, and the opening amount posted as a receipt.*

Those are two requests, and the second can fail on its own. When it does, the piece exists with no stock and no location, and IoTFlows says so by name: `Piece SB-3 was created but its stock was not recorded. Set it with Adjust stock.`

The piece then appears in the list reading **Not placed**. Fix it with that row's **Adjust** button rather than deleting it and starting again.

A failed create raises the reason IoTFlows gave, or `Could not add the piece.` when the response carries none, and nothing is created. The commonest cause is a **Piece ID** already in use.

## Read per-piece stock
On a serialized item, the **Pieces** card sits where **Stock by location** would be, because the pieces *are* the stock. Each row carries the **Piece Id**, the **Location** it sits at, and the **Amount** on it in the piece's own unit.

![The Pieces card on an item's detail, listing four pieces with their ids, locations and amounts, each with an Adjust button](/images/inventory/inv-piece-02.webp)

*The Pieces card on an item's detail, listing each piece with its id, its location and the amount left on it. On a serialized item this card replaces Stock by location.*

Three things you can do from it:

- **Select a row** to open that piece as an item of its own, with a blue **Piece** badge and a back button carrying the item's name. Its SKU is editable there; its name is not, since the name belongs to the item.
- **Select Adjust** on a row to open the [Adjust stock](/docs/inventory/adjust-stock/) modal against that piece, with its location already selected. This is how you record material consumed off a bar or a roll.
- **Select the trash icon** to delete the piece.

There is no **Adjust** button on the item itself, and no way to post a transaction against it. Stock lands on a piece or it lands nowhere.

The item's **Reserved by open work orders** and **Incoming** cards group by piece too, so you see which specific bar a job is holding rather than a quantity.

**On mobile.** Pieces ship on iOS and Android with the same model: the item detail lists its pieces, each piece carries its own amount and location, and adjusting is per piece. Reading a piece id off a tag while standing at the rack is the common case, so the phone matters here.

![An item's pieces on the iOS app, each row showing the piece id and the amount on it](/images/inventory/inv-piece-04.webp)

*Per-piece tracking in the mobile app. Each piece carries its own stock and its parent item name.*

## Pieces on the scheduler
Serializing has a consequence outside the storeroom. A piece is one object, so it cannot be in two places at once, and IoTFlows treats every piece as a resource of capacity 1 without anyone authoring a rule.

When two work orders hold the same piece over overlapping times, the [Schedule issues](/docs/production/schedule-issues/) panel raises a violation naming it: `Piece SB-3 of Steel Bar is held by 2 work orders at the same time. A piece can only be in one place at a time.` Work orders that are not on the board count as holders too, so a maintenance job that took the bar still conflicts with a production job planning to use it.

A piece held by one work order, or by none, raises nothing. Pooled stock raises nothing either, whatever the quantity: two jobs each pulling 5 m from a pooled 8 m is a shortage question, not a conflict. **Serialize the materials your jobs fight over**, and this warning arrives for free.

## Delete a piece
Select the trash icon on a piece's row and confirm. The dialog is titled **Delete Item** rather than Delete Piece, and names the piece by its id.

![The delete confirmation dialog for a piece, titled Delete Item and naming the piece by its id](/images/inventory/inv-piece-03.webp)

*The delete confirmation for a piece. It is titled Delete Item, names the piece by its id, and states that the stock history is retained while the record leaves the catalog.*

IoTFlows confirms with **Item deleted**. The piece leaves the item's **Pieces** card and its rows leave the item's merged **Transaction history**, because that history is the union of the pieces that still exist. The piece's own transaction history is retained on the server, but it is no longer reachable from the item.

Delete a piece when the physical object is gone: the bar was used up, the container was returned to the supplier. Do not delete one to correct its amount. Use **Adjust** for that, so the correction is a transaction somebody can read later.

A failed delete raises the reason IoTFlows gave and changes nothing. If the piece is still listed after the dialog closes, the delete did not happen.

## Pieces and reusable tools
A *reusable tool* is equipment a job takes and gives back: a rack, a tube, a basket, a fixture. **A tool cannot be stocked as pieces.** In the Add Item modal, ticking **This is a reusable tool** disables the pieces box and clears it, with the reason stated in place: a tool is already one object that comes back whole, while pieces divide a quantity of material into separately tracked objects.

So the two answer different questions, and you pick one:

- **To track an individual tool**, create it as its own item and mark it a reusable tool. One item per physical fixture, each with its own name and SKU. A work order that requires it reserves it, and a work order that creates it hands it back. See [Create and edit items](/docs/inventory/manage-items/).
- **To track material held in separate physical lots**, stock the item as pieces. One item for the material, one piece per bar, roll or container.

Pieces are created as **Purchased** whatever their item's type, and never as tools. That is why a piece's delete dialog says Item, and why pieces never appear under the **Tools** segment of the catalog.

## See also
- [Create and edit items](/docs/inventory/manage-items/)
- [Adjust stock and track locations](/docs/inventory/adjust-stock/)
- [Schedule issues](/docs/production/schedule-issues/)
- [How work orders move stock](/docs/inventory/how-work-orders-move-stock/)
- [Monitor low stock and reorder points](/docs/inventory/low-stock/)