Administration

Inventory Costing Methods

How the cost of a Part or Product is tracked as inventory moves in and out — and the one place FIFO doesn't behave quite the way the settings page implies.

The three methods

Every org picks one costing method, applied uniformly across both CMMS Parts and Purchasing Products — they always share one cost, never two separate figures for the same physical item.

Method	What it actually does	Best for
Manual	Cost stored on a Part or Product is whatever you last typed in — receiving a PO line simply overwrites it with that line's unit cost.	You want full control and don't trust an average to reflect real replacement cost.
WAC (Weighted Average Cost)	Every receipt is folded into a running quantity-weighted average across all cost layers still on hand.	Prices fluctuate but you want one smooth number for reporting and margin math.
FIFO (First In, First Out)	New Requisition/PO line pre-fills use the unit cost of the oldest layer with quantity remaining. The stored catalog cost, however, still updates to the last-received price — see the Gotchas section below.	You want new orders priced off what's physically oldest in stock.

Configuring it

Go to Settings > Equipt Settings (labeled Purchasing Settings for Landscapt-only orgs without the CMMS module) and open the Costing tab, under “Inventory Costing Method.” Only admin and manager roles can see this tab — anyone else gets an access-denied screen.

Selecting an option takes effect immediately, org-wide — the page says so directly: “Changing the costing method takes effect immediately for new line items. Existing Requisitions, Purchase Orders, and Work Orders are not modified.” Nothing about historical records is recalculated retroactively; only the cost pre-filled on new lines going forward changes.

Cost layers, and what receiving actually does

Both parts and product_items keep a cost_layers column — a running list of every receipt that's still (partially) on hand, each layer recording its own quantity, unit cost, receipt date, and originating PO number. Recording a Goods Receipt runs one atomic database function per line (receive_part_quantity / the equivalent product-side RPC) that does all of the following in a single row-locked transaction:

Increments quantity_on_hand by the received quantity.
Appends a new cost layer for this receipt.
Recomputes the stored unit_cost:
- WAC — recalculated as the quantity-weighted average across every layer that still has quantity remaining.
- Manual and FIFO — both simply set unit_cost to this receipt's own line price (the last-received cost). See the Gotchas note below — this is the one place FIFO doesn't do what the name implies.
If the part is linked to a Products catalog entry (or vice versa), propagates the new unit_cost to that linked row so Parts and Products never disagree.
Writes an audit log entry, including the old → new cost when it changed.

Cost vs. price. Receiving only ever touches a Product's unit_cost (what you paid). Its sell price — what a client is charged — is a separate field and is never modified by a receipt.

Work Order parts consumption

Adding a part to a Work Order's Costs tab snapshots the part's currently stored unit_cost onto that WO line — a flat copy, not a live link. Editing the catalog cost later never changes a WO line that was already added; the WO line can also be hand-edited afterward, independent of the catalog. Adding the part also decrements quantity_on_hand immediately (mirrored onto the linked Product), the same way removing/adjusting it moves the number back.

There is no variance or write-off concept anywhere in this flow — a WO parts line is simply a frozen snapshot at the moment it was added or last edited, with no reconciliation against later cost changes.

Project cost tracking

A Project's Materials cost (Purchasing > Projects) is built entirely from actual transaction-line costs — the real unit cost recorded on each PO line, requisition line, direct materials line, or subcontract cost tied to that project. It never pulls a dynamically recomputed catalog WAC or FIFO figure; once a line is saved, its cost is fixed, the same “snapshot, not live-linked” pattern as Work Order parts above.

Not to be confused with: Budget Method

Two unrelated things share the word “costing.” Everything on this page is about physical inventory cost — organizations.cost_method. Landscapt's CRM estimating engine has a completely separate crm_services.budget_method setting (‘manual’ vs. ‘production_rate’) that controls how labor hours are budgeted on an estimate — see the Estimates & the Budget Engine guide. They're both casually called “costing” but are different settings on different tables, with no connection to each other.

Gotchas

FIFO's stored cost isn't always the true FIFO cost. New Requisition and PO lines pre-fill from the oldest layer with quantity remaining, as expected. But the catalog's stored unit_cost — and therefore what a Work Order parts line snapshots — is always the last-received price under FIFO, not the oldest-layer price. In practice this means a Work Order's FIFO parts cost can differ from a Requisition/PO's FIFO pre-fill for the same part, even though the Settings page describes FIFO as applying uniformly across Requisitions, Purchase Orders, and Work Orders.
Switching methods doesn't rewrite history. Only new line-item pre-fills change; every Requisition, PO, and Work Order line already saved keeps whatever cost it recorded at the time.
Decimal quantities are allowed on Products, not Parts. Product quantity-on-hand supports two decimal places (e.g. partial yards or units); Parts quantity-on-hand is a whole integer — attempting a fractional receipt against a maintenance part is rejected.