Acumatica ERP Glossary — Every Term You Need

Acumatica has its own vocabulary, and most of it is invisible in the manuals until someone in a code review assumes you already know it. This glossary defines the terms a developer actually trips over in the first few weeks — the framework classes, the query language, the integration surfaces, and the acronyms that fill screen IDs and Git commits.

Framework core

DAC (Data Access Class). A C# class that maps to a database table (or a projection over several). Each public property is a field, decorated with attributes like [PXDBString], [PXUIField], and [PXDefault] that describe its storage, UI, and defaulting behaviour. The DAC is the model layer; you almost never write raw SQL against the table.

Graph (PXGraph). The business-logic controller behind a screen. It holds data views, action buttons, and event handlers. One graph typically backs one screen — SOOrderEntry backs the Sales Orders screen, ARInvoiceEntry backs the AR invoice screen. When people say "the entry graph", they mean this class.

Graph extension (PXGraphExtension). The supported way to add or override behaviour on a stock graph without editing Acumatica's source. Your extension declares PXGraphExtension<SOOrderEntry> and overrides event handlers or wraps actions with [PXOverride]. Extensions survive product upgrades; base modifications do not.

DAC extension (PXCacheExtension). The equivalent for data: it adds fields to a stock DAC. Custom fields on a base DAC must be prefixed Usr, which is how the upgrade tooling tells your columns from Acumatica's.

BQL and data views

BQL (Business Query Language). Acumatica's strongly-typed query language, written as nested C# generics instead of a query string. It compiles to parameterised SQL and gives you compile-time checking against the DAC. Fluent BQL is the newer, more readable syntax layered on top.

// Classic BQL: open AR invoices for a customer
PXSelect<ARInvoice,
    Where<ARInvoice.customerID, Equal<Required<ARInvoice.customerID>>,
        And<ARInvoice.status, Equal<ARDocStatus.open>>>>
    .Select(this, customerID);

// Fluent BQL, same query
SelectFrom<ARInvoice>
    .Where<ARInvoice.customerID.IsEqual<@P.AsInt>
        .And<ARInvoice.status.IsEqual<ARDocStatus.open>>>
    .View.Select(this, customerID);

Data view (PXSelect field on a graph). A declared query the graph exposes to the UI. Grids and forms bind to views. The view name in the graph maps to a data member in the ASPX/screen definition.

Cache (PXCache). The in-memory buffer of DAC records a graph is working with. It tracks inserts, updates, and deletes until you persist. A key gotcha: the cache is per graph instance, so two graphs do not share uncommitted state.

Events

Business logic hangs off cache events. The ones you meet first: FieldDefaulting (supply a default value), FieldVerifying (validate a value as it enters the cache), FieldUpdated (react after a value changes), RowSelected (set UI state like enabled/required per row), RowInserting/RowInserted, and RowPersisting (last-chance validation before the row is written to the database). Knowing which event fires when is most of what separates a working customisation from a flaky one.

Integration surfaces

Contract-based API (SOAP/REST). The supported integration layer built on endpoints — versioned, configurable API contracts exposed on the Web Service Endpoints screen. You work with entities (Customer, SalesOrder) rather than raw tables, and the endpoint decouples your integration from the internal schema.

REST / OData. The contract-based API is exposed over REST at /entity/Default/{version}/. Separately, Generic Inquiries can be published as OData feeds for reporting tools like Power BI and Excel.

GI (Generic Inquiry). A no-code query builder. You join DACs, add conditions and parameters, and publish the result as a screen, a dashboard widget, or an OData feed — all without writing a graph.

Business Events. A trigger-and-action engine: watch a GI or record change and fire an email, a webhook, an import scenario, or a mobile push. The usual way to integrate without polling.

Import/Export Scenarios. Mapping-based data movement on top of the API, driven from the UI. Good for recurring loads that do not justify custom code.

UI and platform terms

Modern UI. The current web interface (as opposed to the retired classic UI). Screens are defined in ASPX plus the graph; the Modern UI renders them responsively.

Customization Project. The packaging unit for changes — screen edits, code, GIs, reports, and DB schema bundled into one publishable, version-controllable package via the Customization Project Editor.

Tenant, Company, Branch. A tenant is an isolated dataset (its own users and data); a company groups branches for financials; a branch is an operating unit under a company. One instance can host many tenants.

Screen ID. The eight-character code in every URL and menu item — two letters for the module, then numbers (SO301000 = Sales Orders, AR301000 = AR invoices). The letters tell you the module at a glance: GL, AP, AR, CA, IN, SO, PO, CR, PM.

Where to go next

These terms are the load-bearing ones — DAC, graph, BQL, cache, events, endpoints, GI. Once they are second nature, the rest of the vocabulary (attributes, actions, PXProjection, slots) slots in around them without much friction. Keep this page open during your first customisation and the code reviews stop feeling like a foreign language.