When assigning rules to your workflows:
Use each rule only once for each workflow.
Apply these rules to your workflow phases in the order in which they display in the table below.
For example, in the table below, the FixBidCalculations rule displays after the Addenda rule. If your workflow has three phases, you could assign the FixBidCalculations rule to any phase after the phase where the
Addenda rule is assigned.
Phase one: no rule assigned for this example.
Phase two: Addenda rule assigned.
Phase three: FixBidCalculations rule assigned.
AASHTOWare Project provides these two rule types:
Current – These rules apply only to the workflow phase where the rule is assigned.
Future – These rules apply to the workflow phase where the rule is assigned, and to all subsequent phases in the workflow.
For example, if you assign a rule to phase five of a workflow, the rule also
applies to workflow phases six through ten. If you move a proposal or project from phase two directly to phase eight, the rule from phase five still applies.
Rule Name |
Type |
Description |
FixPropItemLineNum |
Current and Future |
This rule is intended to be used once a proposal has gone out for bid, primarily to prevent changes to existing proposal line numbers. An error in the roll up of proposal items prevents a proposal from entering a phase with this rule. When a proposal is in a phase with the FixPropItemLineNum rule or in any subsequent phase, the proposal line numbers cannot be changed. Biddable items cannot be added to a project without a proposal line number; therefore, importing a project can only be used to change items, not to add new items. |
Addenda |
Current |
This rule is intended to be used to prevent changes that affect the published proposal unless an addendum is open. Any data exported to Bids is locked, unless allowed by an open addendum. When a proposal is in a phase with the Addenda rule, users with permission can open, close, and approve addenda until the phase is changed to one that does not have the Addenda rule. The system displays a banner on the project and proposal related pages alerting the user that the addenda phase is in place for that proposal and whether or not an open addendum exists. All changes that affect the published proposal are tracked during phases with this rule. Different fields in the published information become read-only depending on the user’s access level and whether an addendum is open. If an addendum is open, published information can only be modified by users with Addenda Change access. If no addendum is open, the published information for the proposal is read-only. Because non-bid project items are not considered part of the published information, they can be added or deleted. If the proposal has an unapproved addendum, the proposal cannot be exported to Bids.
|
FixProposalItem |
Current and Future |
This rule is intended to be used once bids have been received to prevent any changes that would impact the proposal structure on which the bid is based. If a warning is generated in the roll up of proposal items, the proposal is prevented from entering a phase with this rule. When a proposal enters a phase with the FixProposalItem rule, the final calculation of low cost totals is performed. For this phase and any subsequent phase:
|
Current and Future |
This rule is intended to be used once all bid information is entered in the system and complete. A proposal should not enter a workflow phase with the FixBidCalculations rule until all bids have been entered and adjusted as needed. When a proposal enters a workflow phase with the FixBidCalculations rule, the final calculation of bid item, section, time, and vendor amounts is performed. Bid validation is performed, and bid sections are validated against proposal section. For this phase and any subsequent phase, bid, bid section, and bid time can no longer be changed or deleted. A proposal must be in a workflow phase with the FixBidCalculations rule in order to use innovative bidding features, including additive section, alternate section, and life cycle cost analysis. |
|
PreConstrHasEnded |
Current and Future |
This rule is intended to be used once all the work on an awarded proposal is complete and the proposal is ready to become a contract. A proposal must be in a workflow phase with the PreConstrHasEnded rule in order to transition to construction. |
ActiveContract |
Current and Future |
This rule is intended to be used once a proposal becomes a contract. The system automatically sets the phase of the proposal to the workflow phase with the ActiveContract rule when the contract is initially created, regardless of whether the contract is created manually or by transition. |
ClosedContract |
Current and Future |
This rule is intended to be used once work on a contract is finished. When a contract is closed, the contract and any subcontract records are locked and cannot be modified except to reopen the contract or to approve or reject payment estimates for the contract. |
ArchivedContract |
Current and Future |
This rule is intended to be used once all tasks related to a closed contract have been completed. When a contract is archived, the contract and any subcontract records are locked and cannot be modified except to change the contract's status back to Closed. |
MigratedContract |
Current |
This rule is used only for contracts that have been migrated from another system. When the contract is initially migrated, it is assigned the Migrated Contract workflow phase with the MigratedContract workflow phase rule. Contracts in this workflow phase are only visible on the Contract Migration Overview component, which by default can be viewed only by users with the ContMigrUser role. Contracts remain in this phase until they are marked as Migration Complete. Contracts marked as Migration Complete then move to the Active Contract phase. |
Related topics:
Maintaining Bid Letting Workflow