Acumatica business scenario validation: pass/fail process paths from a Git seed

TLDR

Config looks complete until someone runs the real path — order, receipt, invoice, payment — and a missing preference, tax zone, or workflow stops the post. A named scenario suite on non-prod current configuration is pass/fail with the failing step named: seed the company from Git, fund the books, then buy, build, sell, and collect. That is the land path under business scenario validation — complements certified UAT; does not replace it; same suite feeds major-release and integration checks later.

Config looks complete until the real path runs

Screens and masters can look finished while a critical process still cannot post end to end — and nobody has an automated answer for “does this company still run the process?”

An Acumatica company can show warehouses, items, vendors, customers, and order types all present. The failure shows up only when a linked chain runs: purchase order to receipt to bill, kit assembly that consumes those parts, sales order to shipment to invoice, payment applied to that invoice. A missing preference, tax zone, payment method link, or workflow stop is invisible until that chain posts.

Manual click-through UAT is the usual answer — or no automated proof at all. A green UAT day does not re-run itself after the next preference edit, tax update, or customization publish. When something fails mid-path, the evidence often lives in a screenshot thread rather than a durable report you can re-run and hand to a practice lead.

Search terms this post answers: Acumatica business scenario validation, Acumatica process path testing, Acumatica UAT automation, pass/fail ERP scenarios.

Click-through UAT and scenario validation do different jobs

Human UAT finds judgment calls, training gaps, and process exceptions; scenario validation answers whether named critical paths still post on current config — repeatably, with step-level failure.

	Click-through UAT	Business scenario validation
Strength	UX, training, exceptions humans notice	Repeatable pass/fail on named paths
After the next change	Someone clicks again	Re-run the suite
Failure evidence	Memory, screenshots, tickets	Step id and expect miss in the run report
Reuse on next major	Rebuild the walkthrough	Same suite on the new build (matrix later)
Scope	Often broad and informal	Explicit SOW paths — not “all of Acumatica”

Use human UAT for judgment and training. Use business scenario validation when you need a repeatable gate on current configuration that major-release regression and external integration checks can reuse.

This is not a multi-release matrix across Acumatica major releases — that is a separate engagement that prefers an existing suite. It is not controller recon of production books. Production is not the test surface; non-prod write only.

Named company plus suite on non-prod current config

Name one company and a non-prod surface, record the process suite in Git, run it against current configuration, and treat exit zero as “these paths still post.”

Preferred surface is rebuild-from-tree (live company → rebuildable UAT); an agreed UAT or sandbox that matches current config also works. Work product stays in a repository the buyer owns — not a one-off click checklist locked in a consultant laptop.

Nothing installs inside Acumatica as a product license. The engagement records scenarios and runs them; the single-tenant GitOps gate is the engine (apply / run / diff) when the tree is under configuration-as-code.

Git seed then four multi-step legs

The filmed proof for LAB5 Electronics starts from empty UAT, applies company and masters from config/, funds the books once, then runs buy → build → sell → collect — each leg one command, pass or fail.

The sample manufacturer assembles IoT gateway kits. Process paths need foundation; they do not invent company, COA, warehouse, parts, kits, vendors, or customers. Those come from the Git seed:

acu apply config/
acu run scenario/10-seed-capital.yaml   # owner capital — funded books
acu run scenario/20-buy.yaml            # PO → receipt → bill → AP pay
acu run scenario/30-build.yaml          # kit assembly
acu run scenario/40-sell.yaml           # SO → ship → invoice
acu run scenario/45-collect.yaml        # mixed AR policy

Leg	File	What must hold
Apply	`config/`	Company, masters, preferences in dependency order
Seed capital	`10-seed-capital.yaml`	Checking funded so payables can clear (once-class on warm re-run)
Buy	`20-buy.yaml`	Four vendors: PO → receipt → bill → AP WIRE; parts on hand
Build	`30-build.yaml`	Kit assemblies released; finished goods on shelf
Sell	`40-sell.yaml`	Three customers: order → ship → invoice; open AR
Collect	`45-collect.yaml`	Full / partial / open policy — intentional open balances

Live shapes live under scenario/ in the data repo. The film script that walks apply through collect with UI proof is the service walkthrough — not a slide deck.

Failure names the step, not a vague UAT note

Each leg is a linked document graph with server-assigned numbers captured at runtime; when a step fails, the report names that step — preference, workflow, or document action — not “something broke in UAT.”

A purchase receipt must reference the purchase order Acumatica just numbered. A payment must apply to the invoice the sell leg released. Generators that invent document numbers fail on a clean tenant; scenarios that capture and ${var} re-run as numbers change.

From the buy leg shape:

- id: po-shenzhen
  put: PurchaseOrder
  record:
    VendorID: SHENZHEN
    Hold: false
    Details:
    - {InventoryID: MB-CM4, OrderQty: 25, UnitCost: 69.00}
    - {InventoryID: MOD-LTE, OrderQty: 8, UnitCost: 40.00}
  capture: {OrderNbr: po_shenzhen}

- id: rcpt-shenzhen
  put: PurchaseReceipt
  record:
    Type: Receipt
    VendorID: SHENZHEN
    Hold: false
    CreateBill: true
    VendorRef: "PO-${po_shenzhen}"
    Details:
    - {POOrderType: Normal, POOrderNbr: "${po_shenzhen}", POLineNbr: 1, ReceiptQty: 25}
    - {POOrderType: Normal, POOrderNbr: "${po_shenzhen}", POLineNbr: 2, ReceiptQty: 8}
  capture: {ReceiptNbr: rcpt_shenzhen}

UI proof after a green buy leg is inventory on hand that was bought, received, and billed — not an opening balance typed by hand — and AP bills closed on every vendor chain. A failure on shipment would name shipment; a miss on kit release would name that assembly step.

Expectations use document status absolutes for this run’s captures and inventory/GL deltas for balances so additive legs re-run on a warm tenant without a wipe. The regression gate post covers delta vs absolute in depth; here the point is business: the suite asserts outcomes, it does not only execute clicks.

Mixed AR is intentional policy, not a miss

Collection is a separate policy leg: one customer pays in full, one wires a partial, one stays open — so open AR is a designed ending state, not a silent incomplete path.

In the LAB5 film:

ACMEMFG — COD, paid in full (invoice Closed)
NORTHGRID — partial WIRE; remainder still Open
AGRISENSE — no payment step; stays Open on terms

Two invoices remain open on purpose. Accounts receivable ends non-zero; cash and AR deltas still match the steps that ran. That is the difference between a process contract and “make every balance zero so the demo looks tidy.”

Optional books proof closes the loop

When the SOW includes it, Account Summary shows checking, receivables, inventory, and capital where the suite expects — process path and books agree.

After collect, optional GL proof is a UI or inquiry check on the same non-prod company — for example cold ending cash and AR that match the seed capital, buy cash-out, and mixed collect. Scenarios must leave configuration unchanged so acu diff config/ stays clean after a green run; dirtying config mid-path is a bug by definition.

Same suite feeds the next engagements

Business scenario validation is the substrate: major-release regression expands the same paths across locked major releases; integration checks extend them; cutover day-one paths reuse them.

Always Current and free upgrade sandboxes handle platform cadence. They do not replace a recorded process suite you own and re-run. The major-release matrix post is the multi-host expansion; this post is the current-version land proof those cells prefer to start from.

Scope the suite; do not claim all of Acumatica

Order-to-cash, procure-to-pay, inventory, or SOW-scoped paths — explicit — not an unbounded promise that every screen is covered.

In scope for this engagement	Out of scope here
Named paths on one non-prod company	Production as the test surface
Pass/fail with step-level failure	Multi-major matrix (separate offer)
Optional GL/books assertions	Controller recon of production books
Suite ownership in Git	Replacing certified UAT sign-off
Current Acumatica version	“All of Acumatica”

The film company is a sample manufacturer. Customer engagements name their critical paths on their non-prod current configuration — same method, different SOW.