The Asset That Does Not Exist Yet
Turning stock into a tracked asset does not produce an asset. It produces an adjustment and a pending record holding what the asset would be — and the asset is created when that adjustment is approved, at the quantity the approver settled on rather than the one that was asked for.
Five laptops leave the stock room as inventory and arrive on the asset register as three, because that is what was approved, and nothing anywhere had to be corrected.
There is a moment in most organisations where a thing stops being stock and starts being a possession. A laptop in a box on a shelf is inventory: interchangeable, counted, valued in bulk. The same laptop issued to a member of staff is an asset: individual, assigned to somebody, depreciated, and eventually returned or written off.
Nothing physical changes. What changes is which register it belongs to, and that is a decision somebody makes.
What the conversion actually returns
The most informative thing about this feature is the type of the value it hands back. Ask it to create an asset from inventory and it returns an adjustment.
An adjustment is this product's record of a proposed change to stock — the same mechanism a count variance goes through rather than writing stock directly. So conversion is not an operation that happens; it is a request that is raised.
Alongside it sits a conversion record holding everything the asset would be: its name, its barcode, its description and category, its purchase cost, the warehouse it sits in. Stored as a block of data, waiting. And the column that would point at the asset is empty, because there is no asset.
The schema says the same thing the return type says. The asset reference is nullable because the asset does not exist yet.
What is decided at request time
Quite a lot, and all of it inherited so the requester does not retype what the system already knows.
| Attribute of the future asset | Where it comes from |
|---|---|
| Name | The item's name, unless one is supplied |
| Description and category | Inherited from the item |
| Purchase cost | The item's weighted average cost, falling back to its buying price |
| Warehouse | Wherever the stock being converted is sitting |
| Barcode | Generated with the workspace's asset prefix, checked for collision, unless one is given |
| Tracking mode | Chosen at request: one individual asset, or a pool of a quantity |
The cost inheritance is the one worth noticing. An asset's purchase cost is taken from the item's weighted average cost where there is one, and only falls back to the buying price otherwise. That is the right order: what the organisation actually paid on average is a better opening book value than the most recent purchase price, and getting this backwards is a common way for an asset register to start out wrong.
Two refusals happen at request time as well. There must be enough stock at the specific location being converted from — checked while holding a lock on that stock row, so two simultaneous requests cannot both pass. And the item must belong to the workspace making the request.
What is decided at approval time
Here is the part that makes this design worth writing about.
When the adjustment is finalised, the quantity used to create the asset is not the quantity that was requested. It is the quantity that was approved.
Ask to convert five units into a pool asset, and an approver who reduces it to three produces a pool of three. The requested figure sits in the stored payload as a fallback and is simply not what wins.
Why that is worth more than it looks
The common alternative is that an approver can only accept or reject. Faced with a request for five where three is right, they reject it, tell the requester, and the requester raises it again — two more steps, a day, and a rejection on the record for a request that was mostly correct. Letting the approval carry a number turns a rejection into a decision, and the asset then records what was approved rather than what was asked for.
The asset carries that history: the adjustment it came from, the checkout it came from, and the approved quantity, written into its metadata. So an asset pool of three can be traced back to a request for five and the decision that changed it.
One refusal at approval, and it is a good one
An asset tracked individually is one thing with one identity. An asset tracked as a pool is a quantity of interchangeable things sharing one record.
If a request was raised for an individual asset and the approved quantity comes back as anything other than one, the conversion refuses — and says why, naming pool tracking as what to use instead.
It would be easy to be helpful here: approve two individual assets, create two records. That would be wrong, because the payload describes one asset with one barcode and one identity, and duplicating it produces two assets that are indistinguishable to a scanner. Refusing with an instruction is the better failure, and the instruction is the part that makes it acceptable to the person it stops.
Two structural details
One conversion per adjustment, enforced by the database rather than by convention. An adjustment cannot accumulate two conversion records and produce two assets from one approval.
Finalising twice does nothing the second time. The finalisation looks for a conversion whose asset reference is still empty. Once the asset exists, that search finds nothing and the call returns without doing anything. A retried approval, a double-clicked button or a re-queued job cannot mint a second asset from the same stock — which matters, because the stock has already been consumed.
What AWRA OpsHub does today
- Conversion of inventory stock into a tracked asset, raised as an adjustment for approval rather than executed on request.
- The future asset's attributes held as a stored payload until approval, so nothing exists on the asset register before the decision is made.
- The asset created at the approved quantity rather than the requested one, so an approver can reduce a request instead of rejecting it.
- Purchase cost inherited from the item's weighted average cost, falling back to its buying price, so an asset opens at what was actually paid on average.
- Name, description, category and warehouse inherited from the item and the stock location, with the name overridable at request.
- A barcode generated using the workspace's asset prefix and checked for collision, unless one is supplied.
- Available stock checked at the specific location while holding a lock on that row, so two simultaneous requests cannot both succeed against the same stock.
- The item confirmed as belonging to the requesting workspace before anything is written.
- Individual and pooled tracking both supported, with an individual conversion refused if the approved quantity is anything other than one, and the message naming pool tracking as the alternative.
- A pooled asset opening as assigned when a custodian is named and available otherwise.
- The originating adjustment, the checkout and the approved quantity recorded in the asset's metadata, so a pool can be traced back to the decision that sized it.
- One conversion per adjustment enforced by the database, and finalisation that does nothing on a second call, so a retry cannot mint a second asset from consumed stock.
More we can add to your workspace
- A preview of the asset before the request is raised, showing the inherited name, cost, barcode and warehouse so a requester can correct them before an approver sees them.
- A reason recorded when an approver changes the quantity, so the difference between five requested and three approved carries an explanation rather than only a number.
- Conversion of several stock lines in one request, for the delivery that becomes twenty assets at once.
- A notice to the requester when the approved quantity differs from what was asked for, so a reduction is communicated rather than discovered on the register.
- Depreciation settings chosen at conversion, so an asset arrives on the register with its schedule rather than needing a second visit.
- A view of pending conversions as a queue, so requests waiting on approval are visible as a list rather than found through the adjustments they are attached to.
Where we point you to a specialist
- We would decline to create an individual asset in multiples from one payload. The payload describes one identity with one barcode, and duplicating it produces assets a scanner cannot tell apart — which is worse than refusing, and much harder to unpick afterwards.
- We hold that conversion stays an approved action rather than an immediate one. Moving a thing from stock to the asset register changes how it is valued, who is accountable for it and when it is next looked at, and that is a decision rather than a data entry step.
- Where an accounting standard or a tax rule governs when an item must be capitalised rather than expensed, that rule governs and we point you to your own advisers on where the threshold sits. Our part is to record the decision and what it was based on.
A preview at request time and a notice when the approved quantity differs are the two that remove most of the surprise from this flow, and neither disturbs the approval structure. Converting several lines at once is the larger one, and it is what a goods-in team asks for first.
Making the request and the decision visible to each other
The mechanism is complete and correct. What would improve it is communication between the two ends of it, and a way to do twenty at once.
A preview before submitting
The inherited name, cost, barcode and warehouse shown to the requester, so corrections happen before an approver is involved.
A notice when the quantity changes
So a request for five approved at three tells the person who asked, rather than leaving them to notice on the register.
Several lines in one request
The delivery that becomes twenty assets is currently twenty requests and twenty approvals.
We publish scope, not dates.
Scope asset conversionOur take
This is one of the better-shaped pieces of the inventory module and the reason is that it declined the obvious design. Converting stock to an asset could have been a button that creates an asset, and it is instead a request that carries a proposal, an approval that can amend it, and a creation step that happens once and cannot happen twice. The detail that repays study is the approved quantity: letting the approver settle the number turns a rejection into a decision and keeps a mostly-correct request from bouncing back and forth for a day. The refusal on individual assets is equally deliberate, and the message naming pool tracking is what makes a refusal acceptable to the person it stops. What is thin is the conversation around it — a requester finds out what was approved by looking at the register, and twenty assets from one delivery is twenty trips through the same flow.
Four questions for any system converting stock to assets
Does converting create the asset immediately?
A good answer sounds like
It raises a request that is approved.
What ours actually is
It raises an adjustment; the asset is created on approval. Ask it plainly — capitalising something is a decision, and a button that does it immediately has skipped one.
Can an approver change the quantity, or only accept and reject?
A good answer sounds like
Change it, and the record shows both figures.
What ours actually is
Change it. The asset is created at the approved quantity and records it. Accept-or-reject sends every mostly-correct request round again.
What opening cost does the asset get?
A good answer sounds like
Weighted average cost, not the last price paid.
What ours actually is
Weighted average cost, falling back to the buying price. The order matters and getting it backwards starts an asset register out wrong.
What happens if the approval is processed twice?
A good answer sounds like
Nothing the second time.
What ours actually is
Nothing — the finalisation looks for a conversion with no asset attached and finds none. Worth asking wherever an approval consumes something, because the stock has already gone.
Decide where your capitalisation line sits, first
The mechanism handles the movement well. What it cannot decide is which items should cross from stock to the asset register at all, and that threshold is an accounting judgement rather than a system setting. Agree it once, write it down, and the flow described here does the rest reliably.
Talk through asset conversionFrequently asked questions
Does converting stock create the asset straight away?
No. The conversion raises an adjustment and a pending record holding everything the asset would be — its name, barcode, cost, category and warehouse — stored as data. The asset is created only when that adjustment is finalised. The clearest evidence of this shape is that the operation returns an adjustment rather than an asset, and the column that would point at the asset is empty until approval.
What quantity does the asset end up with?
The approved one. If a request to convert five units is approved at three, a pool of three is created, and the requested figure is only a fallback where no approved quantity is present. The asset records the originating adjustment, the checkout and the approved quantity in its metadata, so the difference between what was asked and what was granted is traceable.
Why does an individual conversion refuse a quantity other than one?
Because the stored payload describes one asset with one identity and one barcode. Creating two from it would produce two assets a scanner cannot tell apart, which is considerably worse than a refusal and much harder to unpick later. The refusal names pool tracking as the alternative, which is what makes it a usable failure rather than a dead end.
What cost does the new asset open at?
The item's weighted average cost where there is one, falling back to its buying price. The order is deliberate: what the organisation has actually paid on average across purchases is a better opening book value than whatever the most recent purchase happened to cost, and taking them the other way round is a common way for an asset register to start out with wrong numbers.
Can the same approval create two assets by accident?
No, by two independent mechanisms. The database enforces one conversion record per adjustment, so an adjustment cannot accumulate two. And finalisation searches for a conversion that has no asset attached yet, so once the asset exists a second call finds nothing and returns without acting. This matters because the stock has already been consumed by the time the asset is created.
What happens if two people try to convert the same stock at once?
One of them is refused. The available quantity is checked at the specific stock location while holding a lock on that row, so the two requests are serialised rather than both reading the same figure and both passing. The refusal says the location does not have enough available stock for the conversion.
