Welcome to Forma for Construction Ideas! View the Forma for Construction Product Roadmap here. Top-voted ideas may be considered for future development. Learn more about the feedback process here.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
In the Change Order tab, PCO, OCO, SCO, and RFQ numbers cannot be automatically generated based on the contract type. Instead, they are numbered sequentially by creation date, regardless of contract type. This is a limitation, especially when managing multiple contract types, each of which requires its own numbering system. Otherwise, the numbers must be assigned manually, increasing the risk of human errors.
In the Change Order tab, the Compliance feature is currently available only for RFQ and SCO, but it is also needed for PCO and OCO.
The RFQ tab currently lacks a review workflow, which is a necessary feature.
Hello @MO_MAGDYP6DBN Please try to keep each post/request to individual topics so it's easier to respond
1. You can define numbering by Change Order Type, and Contract name, not only sequential creation. See examples for PCO and SCO below. You can configure change order types to suit your needs
2 OCO compliance will be released in about 2 weeks
Currently, configurable numbering by contract is available only for RFQ and SCO. We require the same functionality for PCO and OCO, as Change Orders are a standard process across all contract types, each of which follows its own numbering sequence.
For example:
Contract A – 0001
Contract A – 0002
Contract B – 0001
Contract C – 0001
Contract B – 0002
Without automated numbering for PCO and OCO, numbers must be assigned manually, which increases the risk of human error. Implementing this feature would ensure consistency and reduce mistakes when tracking Change Orders across multiple contracts. 2- I will create a separate idea for No. 2 3- Waiting for it
@MO_MAGDYP6DBN apologies it seems you were never passed my questions on this.
So given an OCO is upstream and can contain many cost items related to multiple contracts, is this is referring to Main Contract Type, not downstream Contract Type? And a PCO can be upstream or down, or both so how would that work?
Thanks for following up. Emaar uses the platform as the owner, managing downstream contracts with contractors and consultants, including:
Main Works Contract
Enabling Works Contract
Supervision Design Contract
Cost Consultant Contract
Lead Design Consultant Contract
We do use the OCO for upstream approval by the owner’s internal team. However, that approval relates to a change against one of these downstream contracts. We do not have a separate upstream/main contract in our setup. “Main Works Contract” is itself a downstream contract between Emaar and its main works contractor.
In our workflow, all cost items within a PCO belong to the same downstream contract. The OCO generated from that PCO also contains items belonging to that same contract.
Our request is therefore about automatic numbering:
Once we add a cost item and select its associated contract, the PCO number should populate automatically using that contract’s number and a sequential counter specific to that contract.
When we generate the OCO for the owner’s approval, its number should use the same contract reference, with its own OCO sequence for that contract.
As an example of existing contract-based behaviour, when a PCO contains cost items from different contracts, the platform generates separate SCOs for those contracts and applies the corresponding contract-based numbering. In our case, however, all cost items belong to one contract, so we are not requesting any additional splitting functionality.
Does this clarify the contract reference and numbering logic we need for PCOs and OCOs?
@MO_MAGDYP6DBN By the way it is supported for PCO if the following is true. PCO-as-RFQ projects: admins can turn on Include contract code on the PCO number format row; numbers then incorporate the linked subcontract’s code when the PCO has a contractId.
Which only leaves OCO, which as above is atypical, and i don't really understand why they don't use SCO approval instead? Do they actually receive additional funds in the project to pay for it?
Your question about using SCO approval instead of OCO is understandable. The reason we use both is that Emaar’s change-management process requires two distinct approvals: an estimated internal valuation and a final contractor adjustment.
Our configured labels are:
PCO → RFC: Request for Change
OCO → CPA: Contract Price Adjustment
RFQ → DVVO: Determination of the Value of Variation Order
SCO → RCPA: Recommended Contract Price Adjustment
For contractor changes, the process is:
RFC: Obtain preliminary approval for the proposed change.
CPA: The Cost Consultant prepares the estimated valuation for Emaar’s internal approval. This amount is not disclosed to the contractor.
DVVO: The contractor’s submission is assessed and negotiated with input from the relevant parties. Because this involves considerable back-and-forth, we manage those exchanges through Correspondence. We use RFQ/DVVO to record the agreed amount and supporting signed document.
RCPA: The final agreed adjustment is submitted for approval and subsequently used in payment applications.
We therefore already use SCO approval for RCPA. However, it cannot simply replace CPA: the estimated internal amount and the final agreed contractor amount may differ. The approval authority also depends on whether RCPA exceeds the previously approved CPA.
Regarding your funding question, the OCO does not represent additional funds received by Emaar from an upstream client. Emaar is the owner. We use it for internal approval of the estimated change value against a downstream contract.
There is also an interim payment requirement. While final agreement and approval are pending, payment for approved CPA works may be assessed based on the contractor’s submission and/or work completed on site, subject to an internal cap of 70% of the approved CPA value. This is a ceiling, not an automatic entitlement. In our implementation, an early Draft/Open RCPA provides the payment route, while the Cost Consultant applies the cap internally. The contractor does not see the CPA amount or the cap.
The distinction becomes particularly important for consultant changes. These follow Consultant CPA approval and issuance of a formal Variation Order, without a separate RCPA business stage. Yet in our current configuration, an approved OCO cannot be included directly in a Cost Payment Application; we need an SCO. We therefore create an RCPA/SCO solely to make the approved consultant variation payable, without a separate RCPA approval.
There are also contractor cases where a fully substantiated CPA raised after TOC does not require a separate RCPA, creating a similar payment-routing question.
Returning to the numbering request: in our implementation, each CPA/OCO contains cost items belonging to one downstream contract. We need its number to include that contract’s code and maintain a separate sequence per contract.
