Controlling what can and cannot be charged to a project is an important part of project cost governance.
Oracle Fusion PPM provides Transaction Controls that allow organizations to define which transactions are chargeable or nonchargeable for specific projects and tasks.
Instead of relying on users to remember where certain costs should be charged, Transaction Controls allow these business rules to be enforced directly within Oracle Fusion.
In this post, we'll explore how Transaction Controls work and walk through a simple example where a specific Task + Expenditure Type combination is configured as nonchargeable.
What Are Transaction Controls?
Transaction Controls allow you to specify the types of transactions that can or cannot be charged to projects and tasks.
They can be used to configure projects and tasks so that only the charges expected or planned by the business are allowed.
Transaction Controls can also be used for additional purposes:
- For billing-enabled projects, transactions can be defined as billable or nonbillable.
- For capital projects, transactions can be defined as capitalizable or noncapitalizable.
This makes Transaction Controls useful not only for restricting project costs, but also for supporting billing and capitalization requirements.
What Can Be Controlled?
Oracle Fusion provides several attributes that can be used when defining Transaction Controls.
| Transaction Control Component | Purpose |
|---|---|
| Expenditure Category | Control transactions for an expenditure category |
| Expenditure Type | Control a specific expenditure type |
| Nonlabor Resource | Restrict transactions for a nonlabor resource |
| Person | Control transactions for a specific person |
| Job and Organization | Apply controls based on a person's job and organization |
| Person Type | Control transactions based on person type |
| Chargeable Status | Define whether the transaction is chargeable |
| Billable / Capitalizable Status | Control billing or capitalization treatment |
| From and To Dates | Define when the transaction control is effective |
These attributes can be used individually or in combination.
For example, a Transaction Control could be created for:
Person + Expenditure Type
or a more specific combination such as:
Person + Expenditure Type + Nonlabor Resource
This gives organizations flexibility to create controls based on their project governance requirements.
The Business Scenario
Let's use a simple example.
Assume we have the following project:
Project: Test_Transaction_Control
Below mentioned tasks will be considered:
Task Pre-Implementation
Task Change Management
We also have:
Expenditure Type: Expenditure Type Airfare
The business requirement is:
Expenditure Type Airfare should not be charged to Task Pre-Implementation
However, the same expenditure type can still be charged to other Task like Change Management.
The expected result is:
Task Pre-Implementation + Expenditure Type Airfare → Not Chargeable
Task Change Management + Expenditure Type Airfare → Chargeable
This is where a Task-level Transaction Control can be used.
Step 1 — Identify the Transaction to Restrict
The first step is to identify exactly what the business wants to prevent.
In our example:
Project: Test_Transaction_Control
Task: Pre-Implementation
Expenditure Type: Airfare
The requirement isn't to prevent Airfare from being used throughout the entire project.
We only want to prevent it from being charged to Task Pre-Implementation.
This is an important distinction because Transaction Controls can provide granular control at the task level.
Step 2 — Create the Task Transaction Control
Navigate to the appropriate Transaction Controls area for the project/task and create the required control.
For our example, the control would conceptually look like this:
| Attribute | Value |
|---|---|
| Task | Pre-Implementation |
| Expenditure Type | Airfare |
| Type | Exclusive |
| From Date | As applicable |
| To Date | As applicable |
The business rule is now represented within Oracle as:
Task Pre-Implementation
+
Expenditure Type Airfare
↓
Transaction Control
↓
Nonchargeable
This means Oracle can evaluate transactions against the control instead of relying solely on users to remember the restriction.
Step 3 — Attempt the Restricted Transaction
Now let's test the control.
A user attempts to create a project transaction using:
Project: Test_Transaction_Control
Task: Task Pre-Implementation
Expenditure Type: Expenditure Type Airfare
Oracle evaluates the transaction against the applicable Transaction Controls.
Because this specific combination has been configured as Exclusive Transaction Control, the transaction isn't permitted.
Upon validating the POET payables invoice, the invoice gets on system hold
Result: Transaction Not Allowed
Conceptually:
Step 4 — Test an Allowed Transaction
Now let's change the task while keeping the same expenditure type.
Project: Test_Transaction_Control
Task: Task Change Management
Expenditure Type: Expenditure Type Airfare
No applicable Transaction Control prevents this combination, the expenditure can be charged to Task Change Management.
Result: Transaction Allowed
Successfully Validated and invoice ready for accounting
This demonstrates an important point:
The Expenditure Type itself isn't necessarily restricted from the entire project. The control can determine where within the project that expenditure is chargeable.
How Oracle Evaluates the Business Rule
The functional logic can be visualized as:
This allows the business rule to be enforced before an unwanted cost is charged to the project/task.
Using Multiple Transaction Control Attributes
The Task + Expenditure Type example is intentionally simple.
In practice, Transaction Controls can be much more specific.
For example, an organization could define a rule using:
Task + Expenditure Type + Person
or:
Expenditure Type + Person + Nonlabor Resource
The applicable From and To Dates can further determine when the control is effective.
This makes Transaction Controls useful when project charging rules vary by resource, expenditure classification, organization, or period.
Chargeable vs Billable vs Capitalizable
These concepts serve different purposes and shouldn't be confused.
| Control | What It Determines |
|---|---|
| Chargeable | Whether the transaction can be charged to the project/task |
| Billable | Whether the transaction can be considered for billing on billing-enabled projects |
| Capitalizable | Whether the transaction can be considered for capitalization on capital projects |
For our example, we're primarily concerned with Chargeable Status.
The question Oracle needs to answer is:
Can Expenditure Type Airfare be charged to Task Pre-Implementation?
Our Transaction Control says:
No.
What Happens If No Transaction Controls Are Defined?
This is an important behavior to understand.
If Transaction Controls aren't defined, expenditure items from applicable persons, expenditure categories, expenditure types, and nonlabor resources can be charged to the lowest-level tasks on the project.
Transaction Controls therefore provide an additional governance layer when the business needs to restrict what can be charged.
Without our Task Pre-Implementation restriction, there would be no Transaction Control specifically preventing Expenditure Type Airfare from being charged to that task.
Why Use Transaction Controls?
Transaction Controls help move project charging rules from user knowledge into system-enforced controls.
Without a Transaction Control, the business might tell users:
"Don't charge Expenditure Type Airfare to Task Pre-Implementation."
With a Transaction Control, Oracle can enforce:
Task Pre-Implementation + Expenditure Type Airfare = Nonchargeable
This can help:
- Prevent incorrect project charges
- Enforce project-specific business rules
- Improve project cost accuracy
- Reduce downstream corrections
- Strengthen project cost governance
- Control billing and capitalization treatment where applicable
Common Transaction Control Scenarios
Transaction Controls can support many practical business requirements.
Restrict an Expenditure Type
Prevent a particular expenditure type from being charged to a specific task.
Restrict a Person
Prevent or allow transactions for a particular person.
Restrict by Person and Expenditure Type
Allow or prevent a specific person from charging a particular type of expenditure.
Apply a Date-Based Restriction
Use From and To Dates so that the Transaction Control applies only during a defined period.
Control Billing
For billing-enabled projects, determine whether applicable transactions are billable or nonbillable.
Control Capitalization
For capital projects, determine whether applicable transactions are capitalizable or noncapitalizable.
Key Takeaways
- Transaction Controls determine which transactions are chargeable or nonchargeable for projects and tasks.
- Controls can use attributes such as Expenditure Category, Expenditure Type, Nonlabor Resource, Person, Job, Organization, Person Type, and effective dates.
- Multiple attributes can be combined to create granular project charging rules.
- For billing-enabled projects, controls can also determine billable or nonbillable treatment.
- For capital projects, controls can determine capitalizable or noncapitalizable treatment.
- Task-level controls can restrict an expenditure from one task without necessarily preventing it from being used elsewhere on the project.
- In our example, Task Pre-Implementation + Expenditure Type Airfare is nonchargeable, while Task Change Management + Expenditure Type Airfare remains chargeable, assuming no other applicable control prevents it.
- Transaction Controls allow business rules to be enforced within Oracle rather than relying only on user training.
Final Thoughts
Project and Task Transaction Controls provide a flexible way to strengthen project cost governance in Oracle Fusion PPM. By combining attributes such as Task, Expenditure Type, Person, Organization, and effective dates, organizations can control which transactions are permitted before incorrect costs reach the project.
Once you understand the relationship between the transaction attributes and the Chargeable, Billable, and Capitalizable statuses, Transaction Controls become a powerful tool for enforcing project-specific business rules.
Have you used Project or Task Transaction Controls in Oracle Fusion PPM? Drop a comment below or connect with me. I would love to hear how you're using Transaction Controls in your implementations.
Top comments (0)