[FEATURE] BOQ-based pricing for Variation Requests with separate BOQs, Contract SoV traceability and a canonical change lifecycle

[buzzy84]

Is your feature request related to a problem?

OpenConstructionERP already provides most of the building blocks required for construction change management:

• Management of Change (MoC)
• Variation Notices
• Variation Requests
• Variation Orders
• Change Orders
• BOQs and BOQ Positions
• assemblies/resources
• BOQ Markups
• BOQ revisions, snapshots and Version History
• Contracts and Contract Schedule of Values (SoV)

The current Variations workflow already represents the commercial progression:

Notice
  ↓
Variation Request
  ↓
Variation Order

The current Variation Request is also the existing OCERP concept closest to the priced pre-agreement variation stage.

However, a Variation Request currently carries mainly headline values such as estimated_cost_impact and estimated_schedule_days. It is not backed by detailed BOQ-based pricing.

There is also an important distinction in the existing OCERP architecture between:

Estimating BOQ
      ↓
Contract
└── Contract SoV / ContractLine

A Contract already owns its own Schedule of Values through ContractLine.

Therefore:

1. the source estimating BOQ;
2. the Contract SoV;
3. the detailed pricing of each proposed variation;

are separate commercial layers and should remain separate.

Currently there is no first-class way to give each Variation Request its own detailed pricing structure without modifying or mixing it with other project BOQs.

There is also overlap between the existing Management of Change, Variation and Change Order workflows. The same physical/commercial change can potentially be represented and financially processed through more than one path, creating the risk of:

• duplicated pricing;
• conflicting commercial values;
• duplicated Contract-value updates;
• ambiguous BOQ write-back;
• manual re-entry between Variation Request, Variation Order and Change Order;
• fragmented navigation across MoC, Variations, Change Orders, BOQ and Contracts.

Current OCERP UI/UX baseline to preserve

The current frontend already provides a good foundation and the proposed feature should extend it rather than create another parallel change-management UI.

Today the Variations page already provides:

• one project-scoped workspace;
• tabs for Notices, Requests, Orders, Daywork and EoT Claims;
• search and status filtering;
• a side detail drawer;
• a workflow stepper showing Notice → Request → Order;
• Request actions for Submit, Approve, Reject and Convert to Order;
• linked-record indicators on Variation Orders for Change Order and Contract;
• the existing shared OCERP design system, status badges, modals, keyboard tab navigation and project context.

Relevant current frontend areas include:

• frontend/src/features/variations/VariationsPage.tsx
• frontend/src/features/variations/api.ts
• frontend/src/features/moc/MoCPage.tsx
• frontend/src/features/changeorders/ChangeOrdersPage.tsx

The enhancement should preserve this interaction model and reduce cross-module navigation and duplicate data entry.

In particular, the current UI gaps are:

• a Variation Request shows only a headline estimated cost rather than a detailed pricing structure;
• there is no dedicated BOQ context visible from the Variation Request workflow;
• the current Variation Order linked-record actions identify a Change Order / Contract relationship, but navigation is module-level rather than a clear end-to-end change chain;
• Change Orders still have their own independent creation/editing workflow, so a user can re-enter values that already exist in an approved Variation;
• the existing stepper stops at Variation Order and does not make the downstream Change Order and Contract impact explicit.

Describe the solution you'd like

Allow each Variation Request to reference its own dedicated BOQ.

PRODUCT REQUIREMENTS ARE DRAFT TO BE CONFIRMED

That BOQ shall:

• be separate from the source/original estimating BOQ;
• remain separate from the Contract SoV;
• contain only the scope affected by that Variation Request;
• reuse the existing BOQ Position, assembly/resource costing, Markup, calculation, revision and Version History capabilities;
• remain traceable to affected Contract SoV lines and, where applicable, to the originating BOQ Positions.

At the same time, define a deterministic relationship between:

Management of Change / Variation Notice
                  ↓
          Variation Request
                  ↓
           Dedicated BOQ
                  ↓
          Variation Order
                  ↓
            Change Order
              (if used)
                  ↓
       downstream project controls

so that one physical/commercial change does not create multiple independent financial truths.

The key principles should be:

The source estimating BOQ, Contract SoV and each Variation Request pricing BOQ remain separate.

One scope change should have one authoritative pricing chain and one agreed contractual value.

Where a Change Order is required for the same approved variation, it shall be created from or explicitly linked to the corresponding Variation Order and shall not become a second independent pricing or Contract-update path.

Canonical target workflow

A Management of Change entry and a Variation Notice are different existing OCERP concepts. Either may provide the source/context for a Variation Request; both should remain traceable when they exist, but the UI should not force the user to create both for every change.

CHANGE SOURCE / GOVERNANCE

Management of Change (optional governance source)
          and/or
Variation Notice (optional contractual notice)
                  │
                  ▼

COMMERCIAL PROPOSAL

Variation Request VR-001
        │
        └── Dedicated BOQ VR-001
             ├── affected scope only
             ├── ContractLine references
             ├── source BOQ provenance
             ├── quantities
             ├── unit rates
             ├── assemblies/resources
             ├── direct_cost_total
             ├── BOQ Markups
             └── grand_total
        │
        │ draft → submitted → under_review → approved
        │
        ▼

CONTRACTUAL CHANGE

Variation Order VO-001
        │
        ├── authoritative agreed scope / cost / time impact
        ├── applies the contractual impact exactly once
        │
        └── if a downstream Change Order is required
                │
                ▼
          Change Order CO-001
                ├── explicitly references VO-001 / VR-001
                ├── inherits the approved scope and value
                ├── does not re-price the same change
                ├── does not re-apply the same Contract value
                └── carries downstream budget / EVM / BOQ /
                    execution effects as applicable

The intended chain for a change using all objects is therefore explicitly:

MoC / Notice
    ↓
Variation Request
    ↓
Dedicated BOQ
    ↓
Variation Order
    ↓
Change Order
    ↓
downstream project controls

and not two parallel commercial paths such as:

Variation Request → Variation Order → Contract

Variation Request → independent Change Order → another financial value

Product Requirements

PR-01 — Dedicated BOQ per Variation Request

Each Variation Request shall be linkable to its own dedicated BOQ.

The Variation Request BOQ shall be separate from:

• the source/original estimating BOQ;
• the Contract Schedule of Values;
• BOQs associated with other Variation Requests.

Example:

Source BOQ

VR-001
└── Dedicated BOQ VR-001

VR-002
└── Dedicated BOQ VR-002

VR-003
└── Dedicated BOQ VR-003

This follows the common commercial construction pattern where each proposed change has its own change SOV, PCO/COR SOV, cost items or equivalent detailed line-item pricing structure.

PR-02 — Reuse the existing BOQ engine

Variation Request pricing shall reuse existing OCERP BOQ capabilities, including:

• BOQ Positions;
• hierarchical sections;
• quantities;
• unit rates;
• assemblies/resources;
• direct-cost calculation;
• BOQ Markups;
• scoped Markups and overrides;
• totals;
• exports;
• snapshots;
• revisions / Version History.

No parallel variation-estimating or quotation engine should be introduced.

PR-03 — Delta scope only

The BOQ linked to a Variation Request shall be able to contain only the scope affected by that variation.

A full clone of the source BOQ shall not be required.

Example:

Source BOQ

001 Item A
002 Item B
003 Item C
004 Installation

A variation affecting only Item B and Installation may contain:

VR-005 BOQ

001 Modification to Item B
002 Additional Installation

PR-04 — Contract SoV traceability

Where a Variation Request affects existing contracted scope, the relevant variation pricing line shall remain traceable to the affected ContractLine.

Conceptually:

Contract SoV
ContractLine 020
      │
      └── affected by
          VR-005 BOQ Position 001

The Contract SoV is the contractual reference during project execution.

PR-05 — Source BOQ provenance

Where applicable, the variation pricing line shall also retain traceability to the originating BOQ Position.

Conceptually:

Source BOQ Position
        ↓
ContractLine
        ↓
Variation Request BOQ Position

The ContractLine provides contractual traceability.

The source BOQ Position provides estimating provenance.

New scope shall be allowed without an original BOQ Position reference.

PR-06 — Added, removed and modified scope

Variation pricing shall distinguish whether a line represents:

• added scope;
• removed scope;
• modified scope.

Existing Change Order change semantics should be reused where applicable rather than introducing a conflicting vocabulary.

Existing original/new quantity, original/new rate and delta calculation logic should also be reused where appropriate.

PR-07 — Independent BOQ Markups per Variation Request

Each Variation Request BOQ shall support the existing BOQ Markup functionality independently from:

• the source BOQ;
• other Variation Request BOQs.

Existing functionality should be reused, including:

• bill-wide Markups;
• Position/subtree-scoped Markups;
• scoped overrides;
• overhead;
• profit;
• tax;
• contingency;
• insurance;
• bond;
• other existing categories.

For example:

VR-001

direct_cost_total     20,000
markups_total          6,000
grand_total           26,000

VR-002

direct_cost_total     15,000
markups_total          4,500
grand_total           19,500

Changing the pricing strategy of VR-001 shall not change VR-002 or the original BOQ.

PR-08 — Preserve existing BOQ pricing semantics

Variation Request pricing shall reuse the existing BOQ totals:

direct_cost_total
+
markups_total
=
grand_total

Once a dedicated BOQ is linked, its grand_total shall be the authoritative priced amount of the proposed Variation Request.

A second commercial price-calculation engine should not be introduced.

PR-09 — Progressive pricing without duplicate data entry

A Variation Request may be created quickly in draft with a headline preliminary cost/schedule impact for early triage.

Once a dedicated BOQ is created or linked:

• detailed pricing shall be maintained in the BOQ;
• the Variation Request headline priced value shall be derived from the BOQ rather than independently edited;
• the UI shall not require the user to maintain the same commercial amount in two places.

This allows fast early capture while preserving detailed, auditable pricing when the change progresses commercially.

PR-10 — Pending variations shall not modify base commercial records

A Variation Request that is:

• draft;
• submitted;
• under review;
• rejected;

shall not modify:

• the source/original BOQ;
• the Contract SoV;
• the Current Contract Value.

Its financial impact shall remain isolated within its dedicated BOQ.

PR-11 — Variation pricing revisions

Changes to pricing during negotiation shall remain auditable.

Existing BOQ revision, snapshot and Version History capabilities should be reused where possible.

Previously submitted pricing states shall not be silently overwritten.

Example:

VR-012

Pricing Rev.0   28,000
Pricing Rev.1   27,000
Pricing Rev.2   26,000   ← agreed

A new quotation-revision subsystem should only be introduced if the existing BOQ revision mechanism cannot provide the required commercial audit trail.

PR-12 — Preserve the existing Variation Request lifecycle

The existing Variation Request lifecycle shall remain the commercial approval workflow:

draft
  ↓
submitted
  ↓
under_review
  ↓
approved
  ↓
converted_to_vo

The proposed enhancement shall extend this workflow with detailed BOQ-backed pricing rather than replace it.

PR-13 — Variation Request → Variation Order pricing flow

When a Variation Request is approved and converted, its agreed scope and pricing shall flow into the resulting Variation Order without manual re-entry.

The resulting Variation Order shall remain traceable to:

• the Variation Request;
• the agreed BOQ / pricing revision;
• the affected Contract;
• the relevant Contract SoV lines where applicable.

PR-14 — Preserve Original Contract Value

The system shall keep a clear distinction between:

Original Contract Value
Agreed Variations
Current Contract Value

Conceptually:

Current Contract Value
=
Original Contract Value
+ Agreed Variations

Pending and rejected Variation Requests shall not contribute to the Current Contract Value.

PR-15 — Pending change exposure

Pending Variation Requests should remain commercially visible separately from agreed Variation Orders.

The project commercial view should be able to distinguish at least:

Original Contract Value
Agreed Variations
Current Contract Value
Pending Variation Requests
Forecast Contract Value

For example:

Original Contract        1,000,000
Agreed Variations           56,000
Current Contract          1,056,000

Pending Variations           35,000

Forecast Contract         1,091,000

This follows the common commercial distinction between approved changes and potential/pending exposure.

PR-16 — MoC / Notice → Variation traceability

Where a Management of Change entry and/or Variation Notice is the source of the commercial variation, that relationship shall remain explicit and navigable.

An accepted Management of Change entry shall retain an explicit relationship to the resulting:

• Variation Request;
• Variation Order;
• Change Order, where applicable.

A Variation Request created from a Variation Notice shall retain the existing Notice relationship.

The user shall not be required to manually copy IDs between modules to maintain this traceability.

PR-17 — Explicit Variation Order → Change Order linkage

Where a Change Order is required for the same approved variation, it shall be explicitly linked to the corresponding Variation Order and its originating Variation Request.

The intended relationship shall be:

Variation Request
      ↓
Variation Order
      ↓
Change Order

The Change Order shall:

• inherit or reuse the approved scope and commercial value from the Variation Order;
• not require independent re-entry of the same quantities, rates or approved value;
• not create a second independent pricing/approval path for the same change;
• remain traceable back to the Variation Order and Variation Request;
• be navigable in both directions.

PR-18 — Deterministic Change Order BOQ write-back

Any BOQ write-back performed by a Change Order shall target an explicitly related BOQ.

The target shall not be inferred from the set of unlocked project BOQs.

The implementation shall therefore avoid implicitly selecting an unrelated project BOQ when applying a Change Order.

For a Change Order created from a Variation Order, any BOQ projection must remain traceable to the originating Variation Request BOQ.

PR-19 — Single Contract-impact owner / no double posting

Where a Change Order is linked downstream from a Variation Order for the same approved variation, the same contractual value shall not be applied twice.

The Variation Order shall remain the authoritative agreed contractual variation.

A linked Change Order may carry downstream budget, EVM, BOQ or operational effects, but it shall not independently re-apply the same Contract-value change already represented by the Variation Order.

If standalone Change Orders remain supported for backward compatibility or workflows that do not use Variations, their existing Contract-update behaviour may remain available, but the UI and backend shall clearly distinguish:

Standalone Change Order

from:

Change Order generated from / linked to a Variation Order

PR-20 — Canonical change lifecycle and commercial ownership

OpenConstructionERP shall define a deterministic responsibility for each existing change-management object so that a single scope change is not independently priced, approved or posted through multiple parallel workflows.

The intended responsibilities should remain consistent with existing OCERP concepts:

Management of Change

Responsible for:

• identifying the proposed change;
• technical/governance review;
• risk and impact assessment;
• deciding whether the change should proceed.

It shall not be the authoritative detailed commercial pricing record.

Variation Notice

Responsible for contractual/administrative notice where required by the project/contract workflow.

It may precede a Variation Request but shall not duplicate its detailed pricing.

Variation Request

Responsible for:

• proposed contractual change;
• detailed BOQ-backed pricing;
• cost and schedule proposal;
• commercial submission/review;
• pre-agreement commercial value.

The associated dedicated BOQ shall be the authoritative detailed pricing source while the variation is pending.

Variation Order

Responsible for:

• the agreed contractual variation;
• agreed cost and time impact;
• the authoritative contractual outcome of the Variation Request.

Change Order

Where a Change Order is used for the same scope change, it shall be downstream of the Variation Order and shall:

• be explicitly linked to the corresponding Variation Order / Variation Request;
• reuse the approved scope and commercial values rather than requiring independent re-entry;
• not create a second conflicting approved value;
• not independently select or modify an unrelated BOQ;
• not re-apply the same Contract value already owned by the Variation Order.

A single agreed change shall therefore have one authoritative contractual value.

UI/UX Requirements

The workflow should be simple enough that users manage one commercial change as one connected chain, even though OCERP keeps separate domain objects underneath.

UX-01 — Extend the existing Variations workspace, do not create another parallel UI

The current VariationsPage should remain the primary commercial change workspace.

The enhancement should extend the existing:

• Requests tab;
• Orders tab;
• side detail drawer;
• workflow stepper;
• existing status actions;
• existing OCERP WideModal, Card, Badge, Button, keyboard navigation and project context patterns.

Do not introduce a second “Variation Pricing” module that requires users to leave the existing workflow just to understand the state of a change.

UX-02 — One visible end-to-end change chain

The current Notice → Request → Order stepper should be extended into a compact Change Chain that makes all existing linked records visible without forcing all of them to exist.

Conceptually:

MoC / Notice
    ↓
Variation Request
    ↓
Pricing BOQ
    ↓
Variation Order
    ↓
Change Order
    ↓
Contract

Requirements:

• optional stages shall be shown only when relevant or clearly marked as optional;
• each existing record shall show its code and status;
• each stage shall deep-link to the exact related record, not only to the module root;
• the user shall always be able to see where the change came from and where it went.

UX-03 — Fast Variation Request creation with progressive detail

Creating a Variation Request should remain quick.

A user should be able to create a draft Request with:

• title / description;
• classification / urgency;
• preliminary cost impact if known;
• schedule impact if known;
• source Notice / MoC when applicable.

The UI should then offer a clear primary action such as:

Create pricing BOQ

The dedicated BOQ should be created and linked without requiring the user to browse a generic list of project BOQs or manually manage IDs.

If the project workflow requires detailed pricing immediately, the BOQ may be created automatically together with the Variation Request.

UX-04 — Pricing summary inside the Variation Request drawer

The Variation Request detail drawer should show a compact pricing card for its dedicated BOQ, for example:

Pricing BOQ: VR-001 / Rev.2

Direct cost        20,000
Markups             6,000
Grand total        26,000

[Open pricing]

The card should also indicate:

• current BOQ revision/version;
• pricing completeness / missing pricing if applicable;
• whether the amount is preliminary or the currently submitted/agreed revision.

The full BOQ editor should be reused rather than reimplemented inside the drawer.

UX-05 — No duplicate amount editing after a BOQ is linked

Before detailed pricing exists, the current headline estimated_cost_impact may remain editable for fast early-stage capture.

After the dedicated BOQ becomes the pricing source:

• the headline amount shown on the Variation Request shall be derived from the BOQ grand_total;
• the value shall not be independently editable in the Request form;
• users shall edit the BOQ when they need to change pricing.

This removes the risk of a Request showing one value while its detailed pricing shows another.

UX-06 — Simple Contract SoV / source BOQ traceability

Users shall never enter raw UUIDs to connect variation lines to source records.

For existing-scope changes, the BOQ editor should provide a searchable/selectable source control for:

• affected Contract SoV / ContractLine;
• originating source BOQ Position where available.

For new scope, the user should be able to choose a clear option such as:

New scope / no original line

Where a Variation Request is generated from already-selected source lines, those references should be pre-populated automatically.

UX-07 — Submission and approval should show the price being approved

The existing Submit / Approve / Reject actions should remain in the Variation Request drawer.

Before submission or approval, the UI should show the currently applicable pricing revision and grand total next to the action so the user understands exactly what is being submitted or approved.

Example:

Submitting pricing Rev.2 — 26,000

[Submit]

Approval shall bind the decision to that auditable pricing state rather than an unversioned mutable amount.

UX-08 — One-click Variation Request → Variation Order conversion

The existing Convert to Order action should remain the natural next step after approval.

Conversion shall:

• create the Variation Order from the approved Request;
• copy/reference the approved BOQ pricing state;
• carry the agreed schedule impact;
• preserve links to the source MoC / Notice;
• preselect the affected Contract when it is unambiguous;
• request Contract selection only when necessary;
• require no manual re-entry of the approved commercial amount.

UX-09 — Variation Order must visibly own the linked Change Order

The Variation Order drawer shall make the downstream relationship explicit.

If no downstream Change Order exists and one is required, provide a focused action such as:

Create linked Change Order

The created Change Order shall be pre-populated from the Variation Order.

If a Change Order already exists, show it directly in the chain, for example:

Linked Change Order: CO-001 · Approved
[Open]

The relationship shall not be represented only by a generic button that opens the Change Orders module root.

UX-10 — Linked Change Orders should be visibly derived, not independently priced

When a Change Order originates from a Variation Order, its detail view should show a clear source banner/card such as:

Generated from Variation Order VO-001
Originating Request VR-001
Approved commercial value: 26,000

Commercial fields inherited from the Variation Order should be read-only or explicitly controlled so that users cannot silently create a conflicting approved value.

Standalone Change Orders should be visually distinguishable from Variation-derived Change Orders.

UX-11 — Contract impact shown once and clearly

The Variation Order / change chain should show whether the approved variation has been applied to the Contract.

Example:

Contract C-001
Original value       1,000,000
This variation          26,000
Current value         1,026,000
Status: Applied

A linked Change Order shall not show or trigger a second Contract application for the same amount.

UX-12 — Preserve context when opening the BOQ, Change Order or Contract

Cross-module navigation should preserve project and change context.

The user should be able to open:

• the pricing BOQ;
• the linked Change Order;
• the affected Contract;
• the source MoC / Notice;

and return to the originating Variation Request without searching again.

Use exact-record deep links or route state rather than module-root navigation wherever possible.

UX-13 — Reuse current dashboards instead of creating duplicate reporting pages

The current Variations and MoC pages already expose dashboard / exposure information.

Extend existing views to show, where applicable:

• pending Variation Request value;
• agreed Variation Order value;
• Current Contract Value;
• forecast value including pending changes;
• count/value of changes awaiting pricing, review or downstream Change Order creation.

Do not create a separate dashboard solely for this feature unless required by a broader reporting design.

UX-14 — Preserve current accessibility and interaction conventions

The enhancement should preserve the interaction conventions already implemented in OCERP, including:

• keyboard-accessible tab navigation;
• existing status badge vocabulary;
• existing drawer/modal patterns;
• loading, empty and recovery states;
• responsive tables / cards;
• project-scoped context;
• the shared design system rather than bespoke controls.

The objective is to make the new capability feel like an extension of the current Variations module, not a separate application inside OCERP.

Rationale

This enhancement closes gaps between existing OCERP capabilities rather than creating a parallel commercial-management subsystem.

OCERP already provides:

Management of Change
Variation Notices
Variation Requests
Variation Orders
Change Orders
BOQs
BOQ Positions
Assemblies / Resources
BOQ Markups
BOQ revisions / snapshots
Contracts
Contract Schedule of Values

The primary missing capabilities are:

1. detailed and isolated pricing for each Variation Request;
2. clear separation between estimating BOQ, Contract SoV and pending variation pricing;
3. deterministic traceability between the existing change-management objects;
4. an explicit Variation Order → Change Order relationship where both are used;
5. prevention of duplicate Contract-value application;
6. a single authoritative commercial value for each agreed change;
7. an integrated UI flow that does not require duplicate entry or repeated module-to-module searching.

Commercial construction-management platforms commonly use a lifecycle equivalent to:

Change Event / Change Request
        ↓
Potential Change Order / Change Order Request
        ↓
dedicated Change SOV / Cost Items
        ↓
commercial review
        ↓
Approved Change Order
        ↓
Current Contract / downstream controls

Common commercial UX patterns also support:

• fast creation of a high-level potential change before detailed pricing is complete;
• adding detailed cost items / SOV lines as the change matures;
• linking change pricing back to the affected budget/contract/SOV lines;
• generating downstream change orders from the approved/potential change rather than manually recreating them;
• carrying values and scope forward to reduce duplicate entry and preserve traceability.

The important pattern is not the exact terminology but the separation of responsibilities and the continuity of the change chain.

OCERP already has a natural equivalent for the pre-agreement commercial stage in Variation Request, so extending it with dedicated BOQ-backed pricing is preferable to introducing new parallel entities such as a separate Change Estimate, Potential Change or Commercial Offer model.

Which module does this relate to?

• BOQ Editor
• Cost Database / Catalog
• Resource Management
• Schedule (4D)
• Cost Model (5D)
• Risk Register
• Change Orders
• Validation
• Tendering
• Reports / Export
• Document Management
• AI Features (Advisor, Quick Estimate, Smart Actions)
• Regional Standards
• i18n / Translations
• Module System / Marketplace
• UI / UX
• API / Backend
• New Module
• Other

Alternatives considered

Competitive benchmark and requirement derivation

Comparison principle: terminology and object names differ between products. The comparison below is functional: it focuses on how each system separates the original contract/baseline, pending change pricing, approval, and downstream contractual/financial effects. The proposed OCERP requirements are derived from the common pattern rather than from a 1:1 copy of any competitor.

Capability / design question	OpenConstructionERP today	Procore	Autodesk Construction Cloud / Build Cost Management	Trimble Vista	Requirement derived for OCERP
1. Change initiation / governance	OCERP has both Management of Change (MoC) and the Variations module. MoC has its own lifecycle and already carries variation_request_id, variation_order_id and change_order_id, while Variations also has a Notice stage. The cross-module chain exists conceptually, but the user can still experience it as separate records/modules.	Change Events act as an upstream change-identification layer and can generate a Prime PCO or, depending on the configured tiering, a downstream contract change. [Procore Change Event → PCO][procore-pco]	A Potential Change Order (PCO) is the starting point of a budget/cost change and can also be created from an RFI, Issue or Submittal. [Autodesk PCO][autodesk-pco]	Vista supports Pending Change Orders (PCOs) and formal Change Order Requests (CORs) to the owner/customer. [Trimble COR][trimble-cor]	Keep MoC as the governance/technical gate, but make the hand-off explicit and easy: an accepted MoC should create/open or be directly linked to the corresponding Variation Request, without re-entering the same change data.
2. Separate pre-agreement pricing record	A VariationRequest exists, but today it mainly carries a headline estimated_cost_impact and schedule impact. It has no first-class linked BOQ in the current API model.	A Potential Change Order is a separate pre-agreement object and can carry its own Schedule of Values (SOV) before the final contract change is approved. [Procore PCO/SOV][procore-pco-sov]	A PCO can initially be used with a high-level estimate; detailed Cost Items can be added later when more detail is available. [Autodesk PCO][autodesk-pco]	A Pending Change Order is kept separate until it is approved and becomes an Approved Change Order (ACO). [Trimble PCO → ACO][trimble-pco-aco]	Each Variation Request should have its own dedicated BOQ, separate from both the source estimating BOQ and the Contract SoV. A quick headline estimate may remain useful before detailed pricing exists; once the dedicated BOQ is created, its total becomes the authoritative priced value.
3. Detailed delta-scope pricing	OCERP already has a richer BOQ engine with positions, hierarchy, quantities, rates, assemblies/resources, direct cost and markups, but this engine is not currently the pricing backbone of a Variation Request.	When a PCO is created from selected Change Event line items, Procore creates the PCO's SOV from those selected lines. [Procore Change Event → PCO][procore-pco]	Cost Items support line/sub-line detail, quantity/unit data, and multiple commercial values (Estimated, Proposed, Submitted, Approved, Committed). Cost items/subitems can also be imported from Excel. [Autodesk Cost Items][autodesk-cost-items]	PCO/CO items can be associated with contract items and phase/cost detail; change items carry units and billable dollars. [Trimble Change Order setup][trimble-co-setup]	Reuse the existing BOQ engine instead of creating a second variation-pricing engine. The Variation BOQ should contain only the affected/delta scope; cloning the complete project BOQ must not be required.
4. Traceability to the original commercial baseline	OCERP already distinguishes ContractLine / Contract SoV from estimating BOQ data. A ContractLine can also retain a boq_position_id provenance link, but Variation Request pricing does not currently have equivalent first-class traceability.	PCO SOV lines can be tied to an Associated Line Item from the contract SOV in applicable workflows. [Procore PCO/SOV][procore-pco-sov]	Cost Items are explicitly linked to the affected budget and contract; a contract SOV hierarchy can also be used for cost-item hierarchy. [Autodesk Cost Items][autodesk-cost-items]	A PCO item must be associated with a Contract Item before approval, and Change Order Items identify the contract items they affect. [Trimble PCO → ACO][trimble-pco-aco]	A Variation BOQ line that changes existing scope should reference the affected ContractLine; where applicable it should also retain provenance to the source BOQ Position. New scope may exist without an original-position reference.
5. Change-specific markups	OCERP already has powerful BOQ Markups, including bill-wide and scoped/subtree behavior, but a Variation Request cannot benefit from them until it has its own BOQ.	Procore supports financial markup on change orders and can apply markup to all or selected line items, including Potential Change Orders. [Procore Markup][procore-markup]	Financial markup formulas can be applied to PCOs; detailed Cost Items are required for markup application. [Autodesk Markup][autodesk-markup]	Vista Pending Change Orders support markups and add-ons at the change level/item level. [Trimble PCO Add-ons][trimble-addons]	Use the existing BOQ Markup engine on each dedicated Variation BOQ. Markups must remain independent per variation and may differ from the original tender/contract pricing strategy. No new markup subsystem is needed.
6. Deterministic approval chain and downstream change	OCERP already supports Variation Request → Variation Order. VariationOrder also has reference_change_order_id and affected_contract_id, while Change Orders are managed in a separate module with their own approval and downstream budget/BOQ logic. This can create ambiguous ownership unless the relationship is prescribed.	Procore supports configurable tiers: e.g. PCO → Prime Contract Change Order, or PCO → COR → Prime Contract Change Order. [Procore tiers][procore-tiers]	A PCO can generate CORs/OCOs/SCOs/RFQs; data is carried into the generated change-order level instead of being manually recreated. [Autodesk PCO][autodesk-pco]	Vista explicitly supports PCO → ACO; CORs can group PCOs and Contract Change Orders can group approved changes. [Trimble COR/CCO][trimble-cor]	Define one canonical OCERP chain: Variation Request → Variation Order → Change Order when a Change Order is required for the same approved change. The Change Order must be downstream and linked, not a second independent commercial proposal/approval path.
7. Original contract vs current contract	OCERP freezes commercial terms once a contract leaves draft and expects changes to flow through change-management mechanisms. Because VO and CO can both carry commercial impact, the implementation must avoid double-updating the same contractual amount.	Prime Contract changes are represented through separate change-order records/tiering rather than rewriting the pre-change record in place. [Procore tiers][procore-tiers]	Draft/high-level PCOs can remain outside calculations; later statuses affect budget/contract views. This explicitly separates potential exposure from committed change. [Autodesk PCO][autodesk-pco]	Vista is explicit: posted change orders may affect Current Contract Amount but do not change the Original Contract Amount. [Trimble Original vs Current][trimble-co-setup]	Preserve Original Contract Value separately from Agreed Variations and Current Contract Value. Pending/rejected Variation Requests must not change current contractual value. Only one controlled downstream operation should post the agreed change.
8. Pricing evolution / auditability	OCERP already has BOQ revisions, snapshots and Version History, but they are not currently tied to the Variation Request commercial approval state.	PCO workflows include revision/status concepts and preserve the change as a separate commercial record before final change-order approval. [Procore PCO/SOV][procore-pco-sov]	Cost Items deliberately preserve successive commercial values: Estimated → Proposed → Submitted → Approved → Committed. [Autodesk Cost Items][autodesk-cost-items]	Vista keeps Pending and Approved change records separate and provides history/audit mechanisms across its change workflow. [Trimble PCO → ACO][trimble-pco-aco]	Bind submitted/approved Variation Request pricing to a specific BOQ revision or snapshot. A later commercial revision must not silently overwrite the amount that was previously submitted or approved.
9. UI/UX: one change should feel like one workflow	The current Variations page is already a strong base: tabs for Notices / Requests / Orders, a detail drawer, workflow stepper Notice → Request → Order, and linked-record actions from a Variation Order to Change Order and Contract. However, the Change Order and BOQ are still experienced as separate generic modules rather than the continuation of the selected change.	Procore guides users from the upstream change event into the next configured change-order tier and carries selected line items into the next stage. [Procore Change Event → PCO][procore-pco]	The Change Order tool keeps PCOs and Cost Items in one workflow, with flyout/detail panels and Generate / Assign actions to move the same change forward. [Autodesk PCO][autodesk-pco]	Vista exposes a more form-oriented workflow, but it still provides explicit tasks to approve PCOs, create ACOs and create/relate CORs/CCOs from the same change data. [Trimble PCO → ACO][trimble-pco-aco]	Do not create another OCERP UI module. Extend the existing Variations workspace. The Variation Request drawer should provide Create/Open Pricing BOQ; the stepper should show the exact linked VR → VO → CO; links should deep-link to the specific record, not only to a generic module page.
10. Progressive detail and no duplicate data entry	Today a Variation Request can store an estimated value, a Variation Order stores a final value, and a Change Order can separately store its own cost impact. Without orchestration, the same amount can be typed multiple times.	Selected Change Event lines populate the PCO SOV, and tiered change records are created from the preceding stage rather than re-keyed from scratch. [Procore Change Event → PCO][procore-pco]	Autodesk explicitly allows a high-level PCO first, detailed Cost Items later, and then carries PCO/cost-item data into generated change orders; its documentation states that this reduces manual data entry and improves consistency. [Autodesk PCO][autodesk-pco]	Approving a PCO creates/feeds an ACO, and the approval flow can also create the Contract Change Order; PCO items are carried into the approved stage. [Trimble PCO → ACO][trimble-pco-aco]	Use progressive disclosure but one source of truth: allow a quick initial estimated_cost_impact; once the dedicated BOQ exists, derive the VR amount from its grand_total; on approval, populate the VO from the agreed BOQ revision; if a CO is needed, create/link it from the VO using the same approved scope/value.
11. Market-level conclusion	OCERP already owns almost all required primitives, but they are split across BOQ, Contracts, MoC, Variations and Change Orders.	Uses separate change-event, potential-change and approved-contract-change stages.	Uses PCO + Cost Items + generated downstream change orders, with separate potential/approved/committed values.	Uses PCO/ACO/COR/CCO stages and preserves Original vs Current contract values.	The gap is primarily orchestration, pricing ownership and UX integration - not missing core calculation primitives. The requirements therefore focus on linking existing OCERP objects, reusing the BOQ engine, preserving the contract baseline, and presenting the whole change chain as one guided workflow.

Requirement lineage

The benchmark above leads directly to the proposed OCERP requirements:

1. Dedicated BOQ per Variation Request — derived from the common PCO/change-SOV/cost-item pattern.
2. Variation BOQ separate from Source BOQ and Contract SoV — derived from the market separation between estimate/budget, original contract SOV and pending changes.
3. Delta scope only — derived from competitor change SOV/cost-item structures that contain the affected lines rather than full contract copies.
4. ContractLine + source BOQ traceability — derived from competitor links back to contract/budget/SOV line items and from OCERP's existing ContractLine/BOQ provenance concept.
5. Reuse BOQ Markups — derived from competitor change-specific markup capabilities and OCERP's existing scoped markup engine.
6. Variation Request → Variation Order → Change Order canonical chain — derived from tiered commercial change workflows and the need to remove OCERP's current ambiguity between Variation and Change Order commercial ownership.
7. One authoritative commercial value — derived from downstream generation/data carry-forward patterns rather than independent re-entry at each stage.
8. Original vs Current Contract Value — derived especially from mature contract-management systems that preserve the original contract while applying approved changes only to the current value.
9. BOQ revision/snapshot bound to approval — derived from staged commercial values/revisions and the need for an auditable submitted/agreed price.
10. Single Variations workspace with contextual deep links/actions — derived from current OCERP UI strengths plus competitor workflows that advance the same change through contextual Generate/Approve actions instead of forcing users to rebuild the record in separate modules.

How important is this to you?

Blocking my adoption of OpenConstructionERP

Additional context

Expected result

After the enhancement, the relationship should be visually and functionally explicit:

PROJECT
│
├── Source BOQ
│     └── original estimating structure
│
├── Contract C-001
│     └── Contract SoV
│           └── original agreed contractual scope
│
├── Management of Change MOC-001        (optional source)
│     └── accepted
│
├── Variation Notice VN-001             (optional contractual notice)
│
└── Variation Request VR-001
      │
      └── Dedicated BOQ VR-001
            ├── affected scope only
            ├── ContractLine references
            ├── source BOQ Position provenance
            ├── quantities
            ├── unit rates
            ├── assemblies/resources
            ├── direct_cost_total
            ├── BOQ Markups
            └── grand_total

      draft
        ↓
      submitted
        ↓
      under_review
        ↓
      approved
        ↓
      converted_to_vo
        ↓
      Variation Order VO-001
        │
        ├── authoritative agreed contractual impact
        ├── Contract C-001 updated exactly once
        │
        └── linked Change Order CO-001   (when required)
              ├── references VO-001 / VR-001
              ├── inherits the same approved scope and value
              ├── no second independent pricing path
              ├── no duplicate Contract-value posting
              └── downstream budget / EVM / BOQ /
                  execution propagation as applicable

The resulting architecture preserves clearly separated layers:

Estimating
    ↓
Contract baseline / SoV
    ↓
Pending variation pricing
    ↓
Agreed contractual variation
    ↓
Linked downstream Change Order / project-control effects

while keeping the user experience centered on the existing Variations workspace and aligning the workflow with common commercial construction-management practice.

[datadrivenconstruction]

Thanks for this, @buzzy84. You wrote it against what the product actually does instead of against a blank page, and that makes it far more useful to us.

We went and checked the parts that describe the current code, because a wrong premise would have changed our answer. It is not wrong. A Variation Request has a cost figure and a schedule figure and nothing underneath them. There is no link either way between a variation and a bill of quantities. The line by line breakdown that does exist sits on the Variation Order, so it comes after the commercial decision rather than before it, and it is a flat list of its own instead of using the bill engine.

You are right about the layering too. The estimating bill, the Contract Schedule of Values and the pricing of a proposed variation are three different commercial layers and should stay separate. And yes, Management of Change, the Variation chain and Change Orders overlap, and the link from a Variation Order to the Change Order it becomes is not enforced.

So: not built, and not half built. We are not going to pretend otherwise or give you a date. This touches the commercial core of the product, so it needs a product decision before anyone writes code, and that is where it sits now. Your requirements are detailed enough that most of them could be worked from as written.

We will come back here when there is something to report. Leaving it open is deliberate and it is not waiting on anything from you.