Restrictions
The Restrictions screen captures the mutual-exclusion rules between JDE licence components. One line per (Component, Restriction). Each row says: if the company subscribes to the component, it cannot also use the restricted component without re-licensing.
This is the symmetric counterpart of Prerequisite: where prerequisites add requirements, restrictions remove options. Nomasx-1 surfaces a restriction breach as a compliance gap the same way it surfaces an over-consumption.
At a glance
Goal of the view
- Encode the mutual-exclusion rules ("read-only" / "restricted" components that exclude another component).
- Drive the compliance computation to flag a forbidden combination just as it flags an over-consumption.
Columns
| Column | Source | What it tells you |
|---|---|---|
| Product | RTC_PRODUCT — Oracle product family. | The licence family the rule belongs to. |
| Component | RTC_COMPONENT — the licensed component. | The component that carries the restriction. |
| Restriction | RTC_RESTRICTION — the forbidden component. | The component that cannot co-exist with the licensed one. |
Edit dialog
Double-click a row to edit the restriction rule.
| Field | What to enter |
|---|---|
| Product | Oracle product family the rule belongs to. |
| Component | The licensed component that carries the restriction. |
| Restriction | The forbidden component — cannot co-exist with the licensed one. |
Tips & best practices
- Read-only / restricted entitlements are the most common source of restrictions — Oracle sells Foundation Restricted with explicit exclusions of full modules.
- Maintain the list at renewal time. A change in contract scope often invalidates a previously valid combination.
- Cross-reference with Subscribed Licenses — if a CSI declares both sides of a restriction, the documentation behind the contract should be re-examined.