Skip to content

Implementation and migration

Where the inventory value actually is

One question drove the whole design: where is the inventory value now. The answer required a state machine, an audit trail on every movement, and an honest note about two parallel ledgers.

Built for
SMT Research, Vancouver
Service line
Implementation and migration
Window
Jun to Sep 2026
The headline number$6.99MOf inventory value made visible for the first time395 priced SKUs in the warehouse, plus stock on job sites. Priced stock only.

01Key numbers

What we measured

395Inventory value at launchPriced SKUs only. 395 in the warehouse, plus stock counted on job sites.
101Orders of production coverageUp from 25 and then 62 as the parser was rewritten. 10,600 rows, 32 materials, 3.41M square feet.
79 / 79Purchase order header totals corrected16 disagreed with the sum of their own lines. All backfilled to zero mismatches.
14Hand-entered forecast rows the loader never touchesThe load is idempotent on a synthetic external ID, so re-running it cannot overwrite human work.

02The situation

What was true before

Stock lived in a separate system and in spreadsheets. The value of what sat in the warehouse, what was in transit and what had been consumed on a job site could not be stated at a point in time.

The production forecast was parsed from workbooks with a fixed cell map, which covered 25 orders. One workbook template shifts a key cell down by one row, and that was enough to break it.

Contact us to find out more

Recognise this in your own org?

03What we built

The mechanism

A state machine from purchase order placed, to warehouse, to in transit, to on site, to consumed, to invoiced.

The transfer is the costing event

Material leaving the warehouse is a cost to that project whether or not the field crew uses it. Field consumption is a progress signal, not a cost signal. That rule came from the controller verbatim, and every rollup in the system follows it.

An audit trigger on every stock write

Universal stock audit triggers log every insert and update with who, which field, the old value, the new value and the delta. Bulk edits sit behind a mandatory why-note. A count you cannot explain later is a count nobody will trust.

Flows own stock movement, and nothing else writes to it

Stock is never written directly in code or by import, because the flows own the movement. Writing in both places double-counts. The rule is enforced by convention and by the audit log that would show it.

A parser rewritten to read labels, not cells

The production forecast parser moved from a fixed cell map to anchor-and-label lookup after one workbook template was found to shift a key cell by one row. Coverage went from 25 orders to 62 to 101.

Sales and Forecasting
CountProductsBulk editSpot checkHistoryAudit log

Start a physical inventory count

412 products selected. Only ticked items on the Products tab are pulled in.

Start count
Depiction · A physical stock count hub: count, bulk edit, spot check, history and a full audit log, built as one component instead of five reports.Every adjustment requires a reason before it will save. An unexplained stock correction is how a discrepancy becomes permanent, so the field is mandatory rather than encouraged.

Surfaces built

We will demonstrate any of these live, on the real org,.

  • Inventory Count Hub with count, spot check and historyImage withheld
  • Stock audit log showing field, old value, new value and deltaImage withheld
  • Production forecast by material and square footageImage withheld
The finding

The org carries two parallel stock ledgers, and we wrote that down rather than hiding it.

One ledger is a legacy of the migration and one arrives with the Field Service install. Both are real and both are audited. The documentation says so plainly, because an architecture note that pretends a known duplication does not exist is the thing that costs the next engineer a week.

04Outcome

What changed, verified

Inventory value is now answerable at a point in time, with the movement that produced it attached.

  • A 1,552-line controller and a 1,290-line component behind count, bulk edit, spot check, history and audit.
  • Purchase order receiving, auto-assemblies with full cost maths, and min or max threshold replenishment.
  • Replenishment raises a buy or assemble task automatically rather than emailing a person.
  • 3,033 segments backfilled, surfacing quote discounts that had been invisible.
How it was verified

Purchase order and kanban totals were confirmed by logging in as the named end users who work those records, not by an administrator query.

Sources
  • docs/research/01-salesforce-platform.md §2.2 · Inventory and production
  • docs/research/01-salesforce-platform.md §2.3 · Rollup and data-integrity repair
  • docs/research/01-salesforce-platform.md §5 · Pull quotes

Keep reading

Two more

All case studies
  • Implementation and migration
    0Failed records across 16 archive objects1,553 sales orders, 8,478 order lines, 3,438 purchase orders, 2,862 invoices and 14,889 stock movements loaded.

    An ERP retired without losing a transaction

    Sixteen archive objects populated with zero failures, and two phantom invoices caught and removed before they touched a live record.

  • Implementation and migration
    16%Of live invoice lines carried unsafe decimal precision21 of 135 lines replayed. Caught at the accounting boundary, with no Salesforce field narrowed.

    A two-way accounting sync that refuses to guess

    Receivables, payables and timesheets sync both ways on a fifteen-minute cycle. Every rule that could round, merge or classify a dollar is written down and refuses to guess.

Next step

Bring us your hardest Salesforce problem

Tell us what is broken. You get a written read on it within one business day, before any money changes hands.

  • Reply within one business day
  • Live walkthrough of the org itself
  • Vancouver, British Columbia