Fixed Asset

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 three ways: created by hand on the Asset Register screen, uploaded through the Import Fixed Asset CSV screen, or converted automatically from a finalised Purchase Invoice (Internal) line whose item is flagged as a fixed-asset item.

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. What it does with them 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, Default Location and Default Company. The first two are rendered as drop-downs on Default Selection and saved; DEFAULT_COMPANY has no control but is filled in when you choose a branch, so it is saved too, and choosing a branch also fills DEFAULT_LOCATION with that branch’s main location. All three do nothing 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 shows the applet’s own groups plus the shared ones:

Conversely, three screens have no menu link: Feature Visibility, Webhook and Team Permission. Opening Settings lands on the Feature Visibility screen (“Teams — Manage Team Access”) even though nothing in the menu points there, and that screen’s SAVE button does nothing.

Settings in other applets that control this applet

Feature visibility and permissions

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 data-consistency object rejects a null in every one of them (FIXED_ASSET_HDR_PURCHASE_DATE_IS_NULL_OR_EMPTY, FIXED_ASSET_HDR_DEPRECIATION_METHOD_IS_NULL_OR_EMPTY, and so on for 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, but the screen offers only Draft and Registered.

The Save button on the edit screen is enabled when the status is DRAFT and the Details form is valid, or when the status is REGISTERED and both the Details form and the Depreciation Configuration form are valid. Whether an existing Transactions row is also required depends on which of the two forms you edited last, because each one recomputes the flag with a different rule and the Configuration handler is the stricter of the two — see the callout under Depreciation → Configuration. Treat “a complete configuration and at least one transaction” as the intent, and do not rely on the button to enforce it.

Nothing on the edit screen writes DISPOSED. The handler computes it when the last transaction type was a disposal and then overwrites it with the Details form’s own status value on the next line, so the value never leaves the browser. A disposed asset stays REGISTERED (or DEPRECIATED); the disposal is visible only as a journal.

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”), and then posts the journal:

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 deletes every existing line on that run and permanently deletes the journals those lines produced, then rebuilds.
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.
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 all earlier run lines for the asset, 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 every run line for that asset dated on or after this month, together with their journals. 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

The conversion 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:

• code and name from the item; quantity = the line’s base quantity
• purchase price = line amount ÷ base quantity — the unit price
• company, branch, location, segment, dimension, project, profit centre and transaction date from the document header
• 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 code, creating a GL code named “Fixed Asset Register” and the company default if it is missing
• the asset’s subledger found (or created) for that GL code and company
• status DRAFT, and the same "DRAFT" / zero placeholders for the depreciation fields

On success it marks the invoice’s fixed-asset posting as POSTED, which is also what stops the conversion running twice (POSTED or VOID are both skipped).

The conversion runs as a follow-on job of finalising the purchase invoice — only where your tenant’s trigger configuration switches it on. Without that, finalising a purchase invoice creates no assets.

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
• Ledger and Journal
• Chart of Account
• Financial Report