Appearance
Cycles
A cycle is a process whose stages are separate documents: something is requested, then authorised, then delivered, then consumed — and the figure everybody actually argues about is what is left.
Trackapt can record each of those documents individually without any of this. What a cycle adds is the connection between them, and the balance that falls out of it.
Nothing here is specific to stock. The same pieces track litres in a tank, tonnes on a stockpile, tools still out, or incidents still open. The worked example below is a store because it is the one most people recognise.
The pieces
| Piece | Where | Answers |
|---|---|---|
| Item properties | Tracker group → Item properties | What do we record about an item besides its name? |
| Item values | An item → Properties | What are this item's? |
| Reference field | A field's editor → type Reference | Which machine, or which requisition, is this document about? |
| Approval order | Form builder → shield icon in the header | Who signs, in what order? |
| One entry per item per period | Form builder → beside the recording interval | Can the same job card be opened twice? |
| Balance | Tracker group → Balances | What is left? |
Build them in this order
The order is not a preference. Each piece names something the one before it creates, and a picker only ever offers what already exists.
1. Tracker group + its items ← everything hangs off this
2. Item properties, then values ← a per-item threshold needs these first
3. The forms themselves ← with a section linked to the group
4. Reference fields ← can only point at a form that exists
5. Approval order ← per form
6. Balances, then alerts on them ← can only name forms that existAn empty picker is usually a sequencing problem
Do it backwards and the pickers are empty. A screen never offers a choice that cannot work, so it reads as a broken screen if you arrive at it too early.
Reference fields
A dropdown offers a fixed list the author typed in. That is fine for a handful of constants and wrong for anything the operation maintains: a list of machines retyped into every form drifts the moment one is bought or sold.
A reference field takes its options from the system instead. Two sources:
- A tracker group's items — which machine is this job card for.
- Another form's entries — which approved requisition does this delivery fulfil.
What is stored is the id, so the link survives a rename and can be followed later.
The second source is what makes a cycle possible at all. Without it every stage is an island, joined only by a reference number somebody typed twice.
Narrow a reference by status
A reference to another form's entries can be limited to approved ones. That is the control that stops a delivery being filed against a requisition nobody authorised. Do not skip it because everything looks fine in testing — in testing, every entry you made was approved.
If the thing a reference points at is later deleted, the field goes inert rather than rendering an empty dropdown the filler cannot explain.
See Reference sources for the full field-level detail.
Approval order
A flat count — this form needs 2 approvals — cannot express "site admin, then procurement, then finance". It counts heads and calls it a process.
An approval order names each desk in turn. Stage N+1 opens only once stage N is complete. Use Move up and Move down; the order is the whole feature.
Three defaults:
- An unnamed stage can only be approved by the account holder. The screen says so rather than leaving it to be discovered.
- The account holder may approve any stage, unless you turn that off. Turn it off for a stage that must be a named person — a finance release the owner should not be able to self-serve.
- Somebody who signed an earlier stage cannot sign a later one, unless you allow it. A chain exists to separate duties; if one person can clear site, procurement and finance in turn, the chain is decoration.
An approval order replaces the approval count
You do not set both.
One entry per item per period
Off by default.
Turn it on where a second document against the same item for the same period is the first one entered twice. A job card is the clearest case: two open against one machine for one shift means everything issued against it is counted twice, and the balance is then wrong in a way nobody can see by looking at it.
Balances
Open the group, then Balances. You need Level 3 clearance, the group must already be saved, and it cannot be a Global Metrics group (which has no items).
A balance nets movements recorded on different forms. You name the forms and say which part each plays:
Goods received adds · Goods issued takes
That is the whole model, stated the way somebody describes their own operation rather than the way the data is shaped.
Only forms that could actually feed the group are offered — one with a section linked to this group and a numeric field to hold the quantity.
What the screen refuses, and why
| It refuses | Because |
|---|---|
| A balance with no forms | It would net nothing. |
| A balance where every form adds | It can only ever go up, which is a total rather than a balance — almost always a half-finished setup. |
| Forms measured in different units | Drums less litres subtracts perfectly and means nothing. Give both fields the same unit first. A field with no unit is unknown rather than different, and does not clash. |
The forms do not need matching fields
Each names its own section and its own quantity field — Quantity received on one, Qty issued on the other. What ties them together is the item, not the field name: a balance may only count a section linked to this group, so every row already names one of its items, and the figures are netted per item. A section not linked to a group is skipped rather than counted against a phantom.
Only approved entries count, by default
A movement that has not been signed off has not happened: an unapproved delivery has brought nothing in, and an unauthorised issue has taken nothing out.
You can widen this per form, but it is an explicit choice rather than the default, because a figure that counts unapproved paperwork cannot be reconciled against the physical thing.
A balance is worked out on demand
It is not stored as a running total, so a correction anywhere in the history is reflected immediately. Large histories are folded on each read.
Where the stock is
Opening an item on the balances screen shows every form that moved it, and — for a balance that records a place — Where it is: how the figure breaks down across the places it is held.
These add up to the balance. They do not add to it.
A quantity whose place is not known is shown as No place recorded rather than being folded into the largest holding. It is real stock that is genuinely somewhere: movements filed before the balance named its place field, or rows where the filler left it blank.
Stocktakes: starting a balance from what is actually there
A balance nets every movement ever recorded, which means a voucher lost in 2019 is still poisoning the figure today. Take a stocktake on the balances screen to count what is physically there and start the balance from your figures.
From then on the balance reads your count, plus everything that has moved since. The Counting history action shows every stocktake taken on the group and what each one found.
Each item carries its own starting line
Cycle counting means two rows of one balance can honestly begin at two different dates, so the starting line is shown per item rather than for the screen.
Counting a place, or counting the whole group
Counting at decides which of two different claims you are making, and they behave differently on purpose.
| What you count | What it anchors |
|---|---|
| One place | That place's own starting figure. Counting the depot says nothing about the site, and the item's total is the sum of its places — so the Where it is breakdown survives. |
| The whole group, across every place | One figure for the item. It is true and unattributable to a shelf, so the breakdown is given up. |
Cycle counting works because of the first row: you count one store this week and another next week, and neither disturbs the other.
A per-place count needs a place on every source
If any form feeding the balance does not record a place, its quantities are of unknown place — some from before the shelf was counted — and adding them on top of the count would count the same stock twice. There is no way to tell which, so the per-place counts are set aside and the items are named back to you.
The fix is to name a place field on every source form.
Alerts on a balance
Each balance can carry rules, read as a sentence:
Alert when the balance falls below Reorder level
The threshold defaults to each item's own property rather than one number for the whole group — which is what a reorder level means, and why item properties come first in the build order.
- Tell people by in-app chat, push, or email. At least one.
- Who hears it is filtered by who may see the item, exactly as a field alert is.
- The on-form marker is not offered: it paints on a form field, and a balance has no form.
Two behaviours to expect:
An item with no threshold set stays silent. A rule whose threshold resolves to nothing reads as cannot say, not as zero. It will not fire on the zero nobody entered.
One alert per crossing, not one per movement. A balance sitting below its level for a month raises one alert, not one per delivery. It re-arms once the figure recovers.
Alerts are worked out when an entry on a feeding form is submitted, edited or approved, and they are best-effort by design: nothing about an alert can fail the entry that triggered it.
Balance alerts fire from movements only
Lowering an item's reorder level does not itself raise an alert. The next movement on a feeding form will.
A worked cycle
A store that requisitions, receives and issues.
- Group Consumables, with its items.
- Item properties:
Category(dropdown),Unit of issue(text),Reorder level(number). Fill them in per item. - Requisition form. Approval order: Site admin → Procurement.
- Delivery note form, with a reference field pointing at Requisition entries, narrowed to approved. One entry per item per period, on.
- Issue note form.
- Balance On hand: Delivery note adds, Issue note takes. Rule: falls below
Reorder level→ email Procurement.
What that buys: a delivery cannot be filed against an unauthorised requisition, a job card cannot be opened twice against one machine, the figure on hand is netted from documents that were actually signed, and the person who can do something about it hears once when an item drops below its own level.

