About control sources and levels

When you create a new rule, you choose the control source (that is, whether the rule will affect cost or fund transactions), and the rule level (what the rule will enforce).

Control Source

In projects or shells, you can create rules for cost (choose Project Cost as the control source) or funding (choose Project Fund as the source). At the company level, you can create rules for funding (the control source is Company Fund).

Note: “Commit” refers to a commit business process, such as a purchase order, and also would include change commit business processes if specified in the rule; additionally, the term “budget” can mean any cost sheet data source being validated against with the rule, which is usually, but not necessarily, budget-related.

Rule Levels

Project Cost: Rules with Project Cost as the source provide validation to business processes that affect project or shell cost sheets. Rule levels are:

Per WBS: These rules provide control per WBS code across the project or shell budget. For example, if you have an assigned budget amount for specific WBS codes, you can create rules that check all commit business processes (and change commits if specified) to verify that those assigned budget amounts, per WBS code, are not exceeded. Note: If a business process record has several line items, even if only one of the line items will violate the rule, the entire record will be rejected.
Per Total for Entire Project: This rule looks at the total, cumulative amount of commit business processes and verifies the total against the project or shell budget (or other parameter you choose). This type of rule can ensure that the project or shell budget is not exceeded, but does not verify specific WBS code or funding amounts.
Per Fund within each WBS: Applicable if the project or shell includes funding at the WBS level. The rule will validate the amount being charged on the commit business process record for each WBS code against the assigned fund amount per WBS, as specified in the fund information on the cost sheet.
Per WBS within each Commit: Related to SOV. For example, the rule can validate that the total amount of a purchase order and related change orders will not exceed a certain amount for a specific WBS code.
Per selected Summary WBS Codes: Allows you to select one or more summary WBS codes on which to enforce the rule. This option is applicable when the cost sheet has a tree structure; cost sheets with flat structures do not have summary codes. You can choose to enforce the rule on each summary code individually, or on the total of the selected codes. Because you must select summary WBS codes from the cost sheet for this rule, this option is not available in rule templates; it is available for rules within project templates and shell templates, and within projects and shells.
Per selected WBS Codes: Allows you to select one or more “leaf” level WBS codes (that is, codes that are not summary codes) on which to enforce the rule. You can choose to enforce the rule on each code individually, or on the total of the selected codes. This option is applicable for cost sheets with a tree or flat structure. Similar to the previous option, this is available in rules within project templates and shell templates, and within projects and shells, not in rule templates.

Project Fund: This control source option provides validation to business processes that affect project or shell funding sheets. Rule levels are:

Per Fund: These rules provide control per fund per project or shell, similar to “Per WBS” above.
Per Total for Entire Project/Shell: Provide control over entire funding amount for the project or shell, similar to cost rules.

Company Fund: Company level rules can be created for company funding sheets:

Per Fund: These rules provide validation against the total amount of each fund, regardless of project or shell distribution.
Per Total of all funds: Provides validation for the total of all funds available to the company.

 

 

 

 


Oracle Corporation

Primavera Unifier 9.10 • Copyright © 1998, 2012, Oracle and/or its affiliates. All rights reserved.

Copyright Information