Acumatica · Customization

Acumatica Opportunity Screen — A Deep Dive

Acumatica Opportunity Screen — A Deep Dive is the screen the user actually lives in. Every other piece of Acumatica — the workflows, the reports, the integrations — exists to feed.

John Kihiu12 min read

Opportunities (CR304000) is where a qualified Lead becomes a tracked, forecastable deal, built on OpportunityMaint over CROpportunity for the header and CROpportunityProducts for the line-item product/service detail that feeds the forecast amount. Unlike Lead, an Opportunity is always tied to a Business Account and Contact — it assumes the qualification step already happened.

Stages and probability drive forecasting

Each stage in the sales pipeline (configured via Sales Stages under CRM setup) carries a default probability percentage, which multiplies against the opportunity's amount to produce the weighted forecast value used in pipeline reports. Moving an opportunity between stages is the main lifecycle event on this screen, and it's the most common thing customizations hook into — logging stage-change history, requiring a note before regression to an earlier stage, or triggering stage-specific tasks automatically.

Key tabs

Extending OpportunityMaint

A frequent request is converting an Opportunity directly into a Sales Order once it's marked Won — Acumatica supports creating a quote/order from opportunity products, but mapping custom product attributes or pricing rules through that conversion often needs a graph extension override, similar in shape to the Lead conversion pattern.

C# · GRAPH EXTENSION
public class OpportunityMaint_Extension : PXGraphExtension<OpportunityMaint>
{
    protected virtual void CROpportunity_Stage_FieldUpdated(PXCache cache,
        PXFieldUpdatedEventArgs e)
    {
        var row = (CROpportunity)e.Row;
        string oldStage = (string)e.OldValue;
        if (row?.Stage != oldStage)
            LogStageChange(row.OpportunityID, oldStage, row.Stage);
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to Details is standard. Because the opportunity's real value calculation depends on the Products grid, a custom field meant to influence forecast amount (a risk-adjustment factor, say) usually needs to hook into the amount calculation on CROpportunity or CROpportunityProducts directly rather than existing as an isolated display-only field.

Common validation and event-handler use cases

Beyond stage-change logging and SO conversion: enforcing that Close Date can't be pushed back more than a set number of times without manager approval (a common sales-discipline request), validating that Products lines reference active price lists rather than stale ones, and syncing won/lost opportunities to an external BI or commission system through a subscriber or scheduled export.

Gotchas

The weighted-forecast amount is a derived calculation, not a stored field a customization can simply overwrite and expect to persist correctly across stage changes — recalculating it needs to go through the same probability logic the base screen uses, or reports relying on it will drift from what the screen displays. Multi-currency opportunities carry both the opportunity's currency and the base-currency equivalent, the same double-amount pattern seen on AR/AP documents — code that reads only one will misreport for foreign-currency deals. And converting Won opportunities to Sales Orders more than once (a common mistake when a rep re-runs the action) can create duplicate orders if the customization doesn't check for an existing linked order first.

Don't hardcode probability percentages

Stage probabilities are configuration (Sales Stages), not constants. A customization that hardcodes "Proposal = 50%" instead of reading the configured value will silently diverge the moment someone adjusts the pipeline configuration.

Wrapping up

Opportunities is fundamentally a forecasting tool wrapped around a CRM record, and its customizations succeed when they respect that the amount and probability are calculated, configuration-driven values rather than static fields to be freely overwritten.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.