Skip to content
ERPNext Data Model
Esc
navigateopen⌘Jpreview
On this page

Asset Capitalization & Component Consumption

A design reference for turning consumed stock, components, and services into a capitalized asset

1. Requirements

1.1 Functional requirements

  • Consume any mix of three source types into a single capitalization event: stock items drawn from a warehouse, existing assets (including purpose-built components), and service items (non-stock, non-asset expense lines).
  • Produce one of two outcomes from that consumption: create the acquisition value for a brand-new target asset, or add further value onto an already-existing, not-yet-submitted target asset (built up across more than one capitalization event over time).
  • Gate submission of a composite target asset on at least one capitalization event having already been posted against it — a composite asset cannot be submitted “empty.”
  • On cancellation, symmetrically reverse everything the capitalization did: restore consumed assets to their prior status, release their disposal date, rebuild their depreciation schedule, and reverse the stock and ledger postings.

1.2 Non-functional requirements

  • No double consumption: a consumed asset must not already be disposed, cancelled, in draft, or itself the target — and a stock line already claimed by an earlier capitalization against the same source purchase receipt must not be offered again.
  • Depreciation continuity for consumed assets: a depreciating asset that is consumed must be depreciated up to the capitalization’s posting date before its disposal value is calculated, so no depreciation is skipped or double-counted at the seam.

1.3 Constraints

  • All three source lists (stock items, asset items, service items) are child tables on the capitalization document, not independent records — there is exactly one document type here, not four.
  • The target asset is never auto-submitted by a capitalization event; the document only raises its cost figures and leaves it in draft for a person to review, set depreciation details on, and submit.

2. High-Level Design

2.1 Component diagram

2.2 Data flow — consumption to target cost

This is a short procedure, not a branching graph:

  1. Totals are computed independently per source: stock items total quantity × valuation rate; asset items total each consumed asset’s book value as of the capitalization’s posting date; service items total quantity × rate.
  2. Every consumed asset item is marked Capitalized and given a disposal date equal to the capitalization’s posting date, regardless of its type.
  3. Only consumed assets that are not purpose-built components get an actual disposal ledger posting generated here (crediting the fixed-asset account, debiting accumulated depreciation, and recognizing any gain/loss) — a consumed component’s value is carved out of this document’s own bookkeeping entirely; nothing in this document posts it (see § Deliberately not asserted in the executor’s notes to the reviewer — its origin was not traced).
  4. One lump debit for everything else (stock cost + non-component asset disposal value + service cost) lands in the target’s fixed-asset or CWIP account, against whichever accounts were credited above.
  5. The target asset’s cost fields are incremented by the total, and it is left in draft.

3. Deep Dive

3.1 Data model

Asset Capitalization The submittable document itself: a target item code, an optional target asset (set only when adding to an already-existing draft asset rather than creating a new one), a posting date/time, and the three child tables below. A target that is set must already be a Composite Asset not yet submitted, matching the target item code, and belonging to the same company.

Asset Capitalization Stock Item One row per consumed stock line: item, warehouse, quantity, valuation rate, and serial/batch allocation where the item requires it.

Asset Capitalization Asset Item One row per consumed existing asset: the asset, its book value as of the capitalization’s posting date, the finance book that value was read from, and the fixed-asset account it will be credited from.

Asset Capitalization Service Item One row per non-stock, non-fixed-asset expense line: item, quantity, rate, and the expense account it is credited from.

3.2 Error handling

  • Ineligible target: a target asset that is already submitted, cancelled, or in a disposed/capitalized status is rejected, as is one whose item code does not match the capitalization’s target item.
  • Ineligible consumed asset: a draft, cancelled, already-disposed, or already-capitalized asset cannot be consumed, and an asset cannot consume itself.
  • Empty submission: a capitalization with no stock, asset, or service lines at all cannot be submitted.
  • Cancellation ordering: cancelling restores every consumed asset’s status and depreciation schedule before the stock and ledger postings are reversed, mirroring the submit path rather than reversing it in arbitrary order.

4. Scale and Reliability

This is a low-volume, human-triggered event — one capitalization per acquisition or assembly milestone, not a recurring or batch workload. The only reliability property worth calling out is that submission and cancellation each touch stock, several other assets’ schedules, and the ledger in one transaction, so a partial failure rolls the whole event back rather than leaving the target asset’s cost figures out of step with what was actually consumed.


5. Trade-off Analysis

Decision Trade-off
One document type covering three unrelated source kinds (stock, asset, service) A single audit record for “how this asset’s value was assembled” — at the cost of the document’s own validation and GL-building logic branching three ways internally for almost every step.
Target asset never auto-submitted Forces a human review point (depreciation setup) before a composite asset enters service — at the cost of an extra manual step every time, even for a straightforward single-event capitalization.
Purpose-built components excluded from this document’s own disposal posting Avoids re-booking a value that was already recognized elsewhere — at the cost of this document’s own ledger picture being incomplete for that source type unless the reader already knows where the component’s value was booked.

6. What to Revisit as the System Grows

  • Make the component value carve-out self-explanatory. Today a reader of one capitalization event cannot tell, from this document alone, where a consumed component’s value was booked — a reference field pointing at whatever transaction did book it would close that gap.
  • Multi-event assembly visibility. When a composite asset is built from several capitalization events over time, there is no single view listing all of them together; a rollup would help reconcile a composite asset’s final cost against everything that went into it.

Was this page helpful?