Search Results po_control_rules




Overview
Explore in AI Chat

Overview

PO_CONTROL_RULES is a Purchasing (PO) module table that stores document authorization rules governing how purchasing documents are controlled, approved, and restricted within Oracle E-Business Suite. Each row defines a control rule that determines the conditions under which a buyer, approver, or document type may proceed—or must be blocked—during the procurement cycle. The rules are scoped to a control group and can be applied across blanket agreements, purchase orders, requisitions, and other purchasing document types.

The table resides in the PO schema and is owned by the Oracle Purchasing application. Its primary key, PO_CONTROL_RULES_PK, is defined on the CONTROL_RULE_ID column, with an additional unique index PO_CONTROL_RULES_U1 also on CONTROL_RULE_ID. The table carries a foreign key to PO_CONTROL_GROUPS_ALL via CONTROL_GROUP_ID, which establishes the parent grouping context for each rule. Heuristically, this table exhibits satellite-leaning characteristics in a Data Vault model: its rows are descriptive attributes that depend on the control group hub and change independently of the transactional documents they affect.

Key Information Stored

The table contains 92 documented columns. The most operationally significant include:

  • CONTROL_RULE_ID — surrogate primary key (PO_CONTROL_RULES_PK) and unique business-key candidate (PO_CONTROL_RULES_U1).
  • CONTROL_GROUP_ID — foreign key to PO_CONTROL_GROUPS_ALL, linking each rule to its owning control group.
  • RULE_TYPE_CODE — classifies the rule (for example, amount-based or document-based authorization logic).
  • OBJECT_CODE — identifies the purchasing object type to which the rule applies, such as a purchase order or requisition.
  • AMOUNT_LIMIT — monetary threshold above or below which the rule triggers.
  • LOCATION_ID — restricts the rule to a specific ship-to or bill-to location.
  • SEGMENT1_LOW / SEGMENT1_HIGH through SEGMENT30_LOW / SEGMENT30_HIGH — low/high ranges for the thirty key accounting flexfield segments, enabling rule scoping by distribution account.
  • INACTIVE_DATE — date on which the rule ceases to apply.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield storage for extensible rule attributes.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID track the Who columns and the concurrent program that created or modified the row.

Common Use Cases and Queries

Typical scenarios include auditing which control rules are active for a group, identifying amount thresholds that block document approval, and reporting on rules scoped to specific accounting segments. A common query joins the rules to their group and filters out inactive rules:

  • SELECT cr.control_rule_id, cr.rule_type_code, cr.object_code, cr.amount_limit FROM po.po_control_rules cr WHERE cr.control_group_id = :group_id AND (cr.inactive_date IS NULL OR cr.inactive_date > SYSDATE);
  • Exposing rules that reference a specific location: SELECT * FROM po.po_control_rules WHERE location_id = :loc_id;
  • Reconciling rule activity through the audit columns, for example grouping by PROGRAM_ID and REQUEST_ID to trace how a rule set was generated.

These queries support segregation-of-duties reviews, approval-limit governance, and data migration validation when control groups are copied between environments.

Related Objects

The most significant related objects are:

  • PO_CONTROL_GROUPS_ALL — parent table, joined on PO_CONTROL_RULES.CONTROL_GROUP_ID = PO_CONTROL_GROUPS_ALL.CONTROL_GROUP_ID.
  • PO_CONTROL_GROUPS — underlying group definition consumed by the _ALL view.
  • PO_HEADERS_ALL and PO_LINES_ALL — purchasing documents evaluated against these rules.
  • PO_REQUISITION_HEADERS_ALL and PO_REQUISITION_LINES_ALL — requisition documents subject to authorization control.
  • PO_DOCUMENT_TYPES_ALL — supplies OBJECT_CODE context for rule scoping.
  • PO_CONTROL_RULES is referenced by the Purchasing document control and approval engine, and rule maintenance is performed through the Purchasing setup forms rather than a public API.