Fixed Asset

The register of a company’s capitalised assets — what it cost, who holds it and where, how it depreciates and which GL codes the depreciation posts to. Assets are entered by hand on the Asset Register screen, or by CSV import. It is not a document applet: it writes its journals directly, every one posted the moment it is written, and every acquisition, disposal and depreciation run lands in Ledger and Journal. Nothing depreciates on its own — each month is a run somebody has to trigger, and a month nobody runs is simply not depreciated — and the run’s journal is not yet usable (see the note below), so plan to post depreciation as a journal.

Your job, and the screen for it

Overview

The Fixed Asset applet keeps the register of a tenant’s capitalised assets — what was bought, which company, branch and location holds it, which employee is responsible for it, what it cost, how it depreciates and which GL codes its depreciation posts to. It is opened by the finance team that owns the fixed-asset ledger, usually after a purchase invoice has been finalised.

It is not a document applet. It has no document type, no FINAL status and no numbering series. It keeps its own records — assets, their depreciation configuration and schedule, depreciation runs, categories, attachments and imports — and writes journals directly.

Assets reach the register by hand on the Asset Register screen or through the Import Fixed Asset CSV screen. The backend can also convert a finalised Purchase Invoice (Internal) line whose item is flagged as a fixed-asset item, but nothing starts that conversion today: no screen offers it, and it is not connected to the purchase invoice’s finalise in BigLedger’s product configuration — see Asset creation from a purchase invoice.

What it will not do. It will not depreciate on a schedule — every month is a run somebody opens and presses RUN on, and a month nobody runs is simply not depreciated. It will not generate a depreciation schedule: the months an asset is eligible for are added one at a time by hand. It will not inherit depreciation settings from the asset’s category. It will not revalue, impair, transfer between companies, or reverse accumulated depreciation when an asset is disposed of. And the depreciation run has enough sharp edges — set out under Lifecycle and effects — that a first month should be run on a copy of the data and reconciled line by line in Ledger and Journal before it is trusted with a period close.

Where it fits

Screens and menus

The applet mounts at applet/tnt/wavelet/erp/asset-register-applet and its sidebar has five entries.

Asset Register

The listing columns are Asset Code, Asset Name, Category, Company, Location, Purchase Date, Purchase Price, Depreciation Method and Asset Status. It is an ag-Grid server-side grid with an advanced-search panel over company, branch, location, purchase-date range and asset-code range.

The create screen has a single Details tab. Two further tabs — Depreciation (Configuration and Schedule) and Transactions — exist in the template but are commented out, so depreciation cannot be configured until after the asset has been created.

The edit screen has six tabs — Details, Transactions, Depreciation (with Configuration and Schedule sub-tabs), Attachment, Related Doc and Other Journal — and their order is controlled by the Default Selection setting (see Configuration).

Two of them carry more weight than their names suggest. Transactions is the only screen on which an asset’s purchase price, disposal price and gain or loss are ever decided, and every row added there posts a journal straight to the ledger — there is no draft and no approval step. Depreciation → Schedule is not a generated plan: it is a hand-kept list of the individual months this asset is allowed to depreciate in, added one month at a time, and a month with no row here is a month the depreciation run will not touch.

There is no delete button on the edit screen — the markup is commented out.

The Add Depreciation panel adds one month at a time: it takes a single month/year and adds one schedule row with that month’s first and last day. There is no “generate the whole schedule” action.

Asset Category

Categories carry a code, a name, a description and a status of ACTIVE or INACTIVE. Code, name and status are required. A category groups assets on the register listing and on the report, and that is all it does — it carries no depreciation defaults that an asset inherits.

The platform does have a category-level depreciation configuration — a method, an averaging method, a rate, a useful life, a residual value and both depreciation GL codes, reachable through the API with its own permission family (API_TNT_DM_FA_CATEGORY_DEPRECIATION_CONFIG_*) — but nothing in the fixed-asset path uses it: the depreciation run uses the per-asset configuration only, and no screen reads or writes the category’s. Configure depreciation on each asset.

Depreciation Run

A run header holds only Company (required), Branch (optional) and a month/year picker. Opening a run shows a read-only Main tab and a Lines tab; the + button on the Lines tab opens the Registered Assets listing, and the RUN button lives there — not on the run header. That is the only place the run is triggered from.

Import Fixed Asset

Columns are File Name, File Size, Format, Status, Process Status, User Error Message, Created Date and Updated Date. A blank template can be downloaded from the screen.

Reports

The report is a grouped ag-Grid (Company → Category Code) over Asset Code, Asset Name, Asset Status, Depreciation Method, Averaging Method, Purchase Date, Disposal Date, Useful Life, Purchase Price, Residual Value, Depreciation Month, Depreciation Year and Depreciation Amount, with PDF and XLS export.

The screen sends only two things — a company (it refuses to search without one, with “Please select the company”) and a month range. The search panel also offers Category and Asset Status, but the screen never sends them, so choosing either changes nothing. What it does with the two it sends is not obvious from the result:

• An asset that has never been through a depreciation run does not appear at all. The report filters on the run’s month and year, so an asset with no run is left out. Together with the configuration and the schedule it also requires, an asset needs a configuration, a schedule row and a completed run inside the range before the report will show it. The report is a record of depreciation that happened, not a register of assets.
• Rows multiply. The run-line join is on the asset alone, with no month condition, so each asset contributes one row per (schedule month × run line) pair inside the range. The Depreciation Amount column is filled only where the run month equals the schedule month; every other row of the pair carries a blank amount. Twelve months of schedule and twelve runs means 144 rows for that asset, twelve of them with a number.
• The endpoint behind the screen (POST fa/fixed-asset-registers/reports) accepts more filters than the screen sends — branch, category, depreciation method, averaging method, asset status and a keyword. Two of them, depreciation method and averaging method, name columns that do not exist on the configuration table (depreciation_method and averaging_method, where the columns are depr_method and depr_ave_method), so a request that sets either fails in the database. The rest — and the month range itself — are built inside a conditional on the company list, so a request with no company applies none of them and returns every asset for every month.

Configuration

Before you can use it

Applet settings

The applet has its own settings screens. They are tenant-wide, not per user — see How settings are stored and who they apply to.

One setting in this applet does anything at all.

On the screen and doing nothing

• Field Settings (Settings → System Configuration → Field Settings) renders eight toggles — Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project — and a SAVE button. Nothing on that screen is saved or used, and SAVE does nothing; the same eight-toggle placeholder appears in several other master-data applets. Four of the eight — Unit Discount, SST/VAT/GST, WHT and Blanket Order — name concepts the fixed-asset form does not have at all.
• Default Branch and Default Location. Both are rendered as drop-downs on Default Selection and saved, and choosing a branch also fills Default Location with that branch’s main location. The screen also tries to record the branch’s company, but there is no field for it on the form, so no default company is ever saved. Neither saved value does anything in this applet: creating an asset still starts with Branch, Location and Company empty. (They are live settings in other applets, which is why they look as though they should work.)
• Every other setting of the document applets — the INCLUDE_* and ENABLE_* families, PRINTABLE, and fifty custom-status settings — is not shown, not saved and not used here. There is no custom-status feature on the fixed-asset screens.

Personalization

The Personalization menu lists Field Settings and Default Selection. Two problems, both in the applet’s own code:

• personalizationItems points its first entry at field-settings, but the personalization route has no such child (its children are personal-default-selection and sidebar), so the link falls through to the applet’s 404 page.
• The Personal Default Selection screen never assigns appletContainer — the subscription that would populate it is commented out — so its branch and location value-change handlers dereference undefined the moment you touch either drop-down, and its SAVE emits undefined. No personal default is ever stored.

The sidebar route is wired but is not listed in the Personalization menu.

The settings menu is partly unroutable

The settings menu in the build you are served (016ca9d0) has three groups. Three of its links lead nowhere, and two working screens have no link at all:

Opening Settings lands on the Feature Visibility screen (“Teams — Manage Team Access”), which no menu item points to; its SAVE button has no action, so nothing on it is stored. Team Permission and the Triggers (webhook) screen are still declared in the applet but have no menu entry — they open only by adding team-permission-listing or webhook to the settings address.

Settings in other applets that control this applet

Who can change what

No client-side permission definitions are seeded for this applet, and the applet contains no SHOW_*/HIDE_* permission constants. All access control is server-side, through the permission families below. Each endpoint accepts the OWNER and ADMIN variants in addition to the one named.

Fields

Details tab (create)

The create form takes the identification you would expect — Asset Status, Asset Code, Asset Name, Type (PROPERTY_PLANT_EQUIPMENT, LONG_TERM_INVESTMENT or INTANGIBLE_ASSET), Category, Company, Branch, Location, Employee (person in charge), Currency, GL Code, the four analysis dimensions (Segment, Dimension, Project, Profit Center), Serial Number, Warranty Expiry and Description. Name, Type, Category, Company, Branch, Location and Currency carry Validators.required; nothing else does. Five of them behave in ways the screen does not show:

Purchase Date and Purchase Price are not on the create form, and they are readonly on the edit form. The applet sends purchase_date = today and purchase_price = 0 — together with depr_method = "DRAFT", depr_ave_method = "DRAFT", depr_start = now, depr_rate = 0 and useful_life = 0 — because the backend rejects an empty value in every one of them — the purchase date, the depreciation method and so on, all seven. "DRAFT" is not a valid depreciation method; it is a placeholder that keeps the create call from failing, and it is what a brand-new asset carries until somebody completes the Configuration sub-tab. A real purchase price arrives by one of three routes only — an Acquisition transaction followed by Save, the CSV import, or the purchase-invoice conversion.

Depreciation → Configuration

The sub-tab takes a depreciation start date, a method, an averaging method, a residual value, a rate, a useful life and the two depreciation GL codes. Start date, method, averaging method and both GL codes are required; residual value, rate and useful life are not. What the screen cannot show you is which of them the processor will actually look at, and in what units:

Saving the edit screen writes these values to both the asset and its depreciation configuration, as two independent saves with no error handling — if the configuration save fails the asset change is still saved. The run then reads the rate and the residual value from the configuration and the GL codes from the asset, so the two copies are not interchangeable.

Transactions tab

Every entry asks for a transaction type, a date, a GL code and a description, plus the amounts that type needs: Purchase Price for an Acquisition, Recoverable Amount and a computed Adjusted Amount for an Adjustment, Asset Value for Asset Held for Sale, Disposal Price for a Disposal. Gain/Loss is read-only on the last two. Only Type and Date carry Validators.required — the GL code does not, and a journal line without one is rejected by the backend rather than by the form.

Import Fixed Asset (CSV columns)

code, name, type, category_code, company_code, branch_code, location_code, currency, gl_code, purchase_date, purchase_price, serial_number, warranty_expiry, employee_name, description.

Only code and name are checked for emptiness up front. Every code column is resolved by lookup and throws a specific message on failure — <INVALID CATEGORY CODE>, <INVALID COMPANY CODE>, <INVALID HDR BRANCH CODE>, <INVALID LOCATION CODE>, <INVALID GL CODE>, <INVALID EMPLOYEE NAME>, <INVALID LEDGER CODE>. The employee is matched on name, not code. The GL code is matched on gl_code_1. If no subledger exists for the resolved GL code and company, the import creates one.

There are no depreciation columns in the import. Imported assets carry the same "DRAFT" and zero placeholders a hand-created asset gets, have no depreciation configuration row and no schedule, and so will not be picked up by a depreciation run or appear in the report until both are added by hand — one asset at a time, one schedule month at a time.

Two more things the template does not say. The description column is parsed and thrown away: the column is declared on the staging row and the row builder never calls setDescr on the asset, so the import is not a way round the Description field having no input control. And an imported asset gets an employee_guid but no pic_name, where an asset created on screen gets both — so the person-in-charge name is blank on imported rows even when the employee resolved.

Lifecycle and effects

Asset statuses

DRAFT → REGISTERED → (DEPRECIATED, set by a depreciation run). An asset’s status can also be ACTIVE or INACTIVE through the API. The screen offers Draft and Registered, and shows Disposed once a disposal has been posted — after which the status drop-down offers Disposed alone. A depreciation run does not respect it: the run selects by schedule month, not by status, and marks every asset it processes DEPRECIATED, so a month scheduled after the disposal is still depreciated and the asset stops showing as Disposed. Add schedule months no further ahead than you need, and check a disposed asset’s status after each run.

The Save rule is the one in the callout under Depreciation → Configuration: a valid Details form for a Draft asset, valid Details and Configuration forms for a Registered one, and an acquisition transaction before a Registered asset saves.

Posting a disposal marks the asset Disposed. When a Disposal transaction is posted on the Transactions tab, the open asset’s status becomes DISPOSED with the transaction’s date as its disposal date, and the screen says Asset marked as Disposed. Press Save to keep the change. The status is stored only when you then press Save; leave without saving and the asset keeps its old status while the disposal journal stands.

What creates a journal

Nothing here goes through the ordinary document posting. Every journal is assembled and sent by the applet or by the depreciation run.

Transactions tab — the browser builds the journal lines, sums them, refuses to send if debits do not equal credits (a toast in the browser, “Journal Transaction is not balanced” — the balance check is the screen’s job; the journal endpoint does not repeat it), and then posts the journal. Every journal this applet writes is posted the moment it is written, on the company’s primary ledger — there is no draft to review. None of them reads a company default GL link: each one posts to the GL codes on the asset and the GL codes you pick on the form:

Disposal does not reverse accumulated depreciation; the entry is written against the acquisition amount, not the net book value.

Other Journal tab — a free-form journal of transaction type TXN: one “main” line plus any number of Payment Breakdown rows, each line debited if its amount is positive and credited if negative, with the same client-side balance check.

None of these lines names a subledger. That is fine: the journal finds the subledger from the line’s GL code and company, and creates one if none exists.

Depreciation run — see below.

The depreciation run, step by step

1. You create a run header: company (required), branch (optional), month and year.
2. You open the run, go to the Lines tab, press +, and press RUN on the Registered Assets screen. That needs API_TNT_DM_FA_DEPRECIATION_RUN_LINE_CREATE.
3. The backend permanently deletes every existing line on that run, and the journals of those lines that it can find, then rebuilds. It can only find a journal that has at least one line for the asset — and the depreciation journal usually has none (see The depreciation journal), so a re-run normally leaves the earlier empty journal in place and adds another one. Count the DEPRECIATION journals for the month in Ledger and Journal after a re-run.
4. It selects the assets that have both a depreciation configuration and a schedule row for that month and year. An asset with no configuration, or no schedule row for the month, is silently skipped. The asset’s own status is not a condition: a DRAFT asset with a configuration and a schedule row is depreciated exactly like a REGISTERED one, even though the screen that lists them is called Registered Assets.
5. One run line is created per selected asset, copying the method, averaging method, rate, useful life, residual value, purchase price, purchase date and disposal date onto the line, and each line is depreciated at once, inside the same request, rather than left for a background worker.

Nothing runs depreciation on a timetable. Pressing RUN is the only thing that creates a line, and depreciation only ever acts on a line that already exists. There is nothing for a schedule to trigger. A month in which nobody opens a run and presses RUN is simply not depreciated, and nothing reports its absence.

Two more things about the selection that the screen cannot show:

• The Advanced Search panel on Registered Assets changes nothing. It sends company, branch, location, a purchase-date range and an asset-code range, and the screen’s query uses only the company, branch, location and the schedule month and year. The rest are accepted and dropped. The same filters do work on the Asset Register listing.
• A month added twice is depreciated twice. The Add Depreciation panel has no duplicate check, and the selection takes every schedule row, so two schedule rows for the same month yield two run lines for that asset in that month. Each one sums only the lines dated strictly before the month it is processing, so neither sees the other: both compute the same amount, both write the same accumulated depreciation onto the asset, and both post a journal. The ledger moves twice; the asset’s accumulated depreciation moves once.

What the depreciation run computes

ACTUAL_DAY is only worked out for straight line; for any other method it gives zero. NO_DEPRECIATION gives zero under both averaging methods, as intended.

The rate is applied as written: book value × rate, once per month, with no division by 12 and no division by 100. A rate captured as an annual percentage will depreciate far too fast.

Several of the inputs are not read from the database at the moment of calculation. The whole asset — its purchase price, its accumulated depreciation and its depreciation configuration — is copied when the run line is created and read back from that copy. The purchase price and accumulated depreciation the declining-balance formulas divide by are therefore the values as they stood when RUN was pressed, not as they stand when the line runs. That is why two lines for the same asset and month (above) produce the same number rather than a diminishing one.

The stop condition, and the status flip

After computing the month’s amount the run sums the earlier run lines, adds the new amount, and then branches on

new accumulated depreciation ≤ residual value

• True — it saves the amount, the new accumulated depreciation and the net book value (purchase price − accumulated depreciation) on the run line, writes the accumulated depreciation back onto the asset header, sets the asset’s status to DEPRECIATED, and creates the journal.
• False — it sets the asset’s status to DEPRECIATED and then permanently deletes this asset’s run lines from this month to the end of this year, together with the journals it can find for them — and every later year’s lines, as the callout below explains. No journal is created for this month.

With the usual residual value of zero, any positive depreciation amount makes the comparison false on the very first run. The asset is marked DEPRECIATED and no depreciation journal is written.

The order of the writes matters if the journal fails. On the true branch the run updates the run line, then writes the accumulated depreciation and the DEPRECIATED status onto the asset, and only then builds and posts the journal, separately. If the journal fails, the run line and the asset keep the values already written. The visible result is an asset whose accumulated depreciation has moved with no journal behind it. Re-running the month is the recovery — it deletes the line and rebuilds — but nothing on any screen tells you the month needs re-running: the failure is recorded in a job error log that no applet shows.

The depreciation journal

The journal is written directly by the run, not through the ordinary document posting. It carries transaction type DEPRECIATION, is marked automatic and is posted from the moment it is created — there is no draft to review — and both the header and the two lines are described as AUTO CREATED FROM FIXED ASSET DEPRECIATION PROCESSOR. To find these in Ledger and Journal, filter on that transaction type; each one also records the asset and the run line that produced it.

Four of its properties are worth knowing because they come from somewhere other than where you would look:

Asset creation from a purchase invoice

Nothing starts this conversion today. It is written as a follow-on job of finalising a purchase invoice, but in BigLedger’s product configuration it is linked to no finalise, so finalising a Purchase Invoice (Internal) creates no asset on any tenant, and no screen in this applet or the purchase invoice offers to run it. If you buy fixed assets on a purchase invoice, create each asset by hand (or by CSV import) and record its acquisition on the Transactions tab. What follows is what the conversion does when it runs, so you can recognise its records if it is switched on.

It reads a purchase invoice and picks the lines whose item is a fixed-asset item (item type FIXED_ASSET_REGISTER) — on an INTERNAL_PURCHASE_INVOICE only. For each such line it creates one asset (not one per unit) with:

• the code from a running number (not the item code), and the name from the line’s item name; quantity = the line’s base quantity
• purchase price = line amount ÷ base quantity — the unit price
• company, branch, location and transaction date from the document header — only those: segment, dimension, project and profit centre are not copied
• serial numbers from the line, joined into one comma-separated string
• asset type and category from the item’s fixed-asset settings
• GL code from the company’s FIXED_ASSET_REGISTER default GL link. If the company has none, it first reuses any GL code in the tenant named exactly “Fixed Asset” — whichever company’s chart it belongs to — and only if there is none creates a GL code named “Fixed Asset Register” (under the GL category inventory); either way it then writes the company’s default link
• the asset’s subledger found (or created) for that GL code and company
• asset status DRAFT, and the same "DRAFT" / zero placeholders for the depreciation fields

It posts no journal. On success it marks the invoice’s fixed-asset posting flag as POSTED — a flag of its own, separate from the invoice’s record status and from its posting status (Draft / Final / Void) — which is also what stops the conversion running twice (POSTED or VOID are both skipped). A line that fails is only logged.

Related applets

• Purchase Invoice (Internal) — the document whose fixed-asset lines can become asset records.
• Inventory Item Maintenance — where an item is marked as a fixed-asset item and given its default asset type and category.
• Chart of Account — supplies all three GL codes and the primary ledger the journals are stamped with.
• Ledger and Journal — where every journal this applet writes can be found; filter on transaction type DEPRECIATION or TXN, or on the acquisition, adjustment and disposal types.
• Organization — company, branch, location and the company default GL link used by the purchase conversion.
• Employee — the person-in-charge drop-down.
• Financial Report — where depreciation reaches the statements.

Troubleshooting

Related documentation

• Financial Accounting module
• Clone, correct or remove a manual journal › Step 6 — the guide for posting each month’s depreciation as a journal, from the asset’s Depreciation Schedule.
• Ledger and Journal
• Chart of Account
• Financial Report