Search Results po_autosource_rules_pk




Overview
Explore in AI Chat

Overview

PO_AUTOSOURCE_RULES is a table in the Oracle Purchasing (PO) schema. In Oracle E-Business Suite 12.1.1 and 12.2.2, the ETRM metadata explicitly marks this object with the description "No longer used." This designation reflects the historical evolution of the sourcing functionality in Oracle Purchasing, where automatic sourcing of requisition lines was originally governed by a rules-based framework. That framework has since been superseded by the sourcing rules and approved supplier list (ASL) architecture, and PO_AUTOSOURCE_RULES is therefore retained only as a legacy structure.

Despite its deprecated status, the table remains VALID in the data dictionary and is physically present with 31 documented columns. It continues to be referenced by two dependent tables, PO_AUTOSOURCE_DOCUMENTS_ALL and PO_AUTOSOURCE_VENDORS, both of which carry a foreign key to AUTOSOURCE_RULE_ID. From a data modeling perspective, the mined relationship structure classifies PO_AUTOSOURCE_RULES as hub-leaning: it is a central entity whose primary key is referenced by surrounding child tables, making it a plausible hub candidate in a Data Vault model. This classification is a heuristic suggestion derived from foreign key topology rather than an official Oracle designation.

Key Information Stored

The table's documented physical schema contains 31 columns, of which the most significant are outlined below.

  • AUTOSOURCE_RULE_ID — the surrogate primary key, enforced by PO_AUTOSOURCE_RULES_PK and also by the unique index PO_AUTOSOURCE_RULES_U1. This is the column referenced by all dependent tables.
  • AUTOSOURCE_RULE_NAME — the business-key candidate, enforced by the unique index PO_AUTOSOURCE_RULES_UK1. Together with the surrogate key, it provides the human-readable rule identifier that users would have recognized when the rules framework was active.
  • ITEM_ID — references the inventory item to which the auto-sourcing rule applied, indicating that rules could be item-specific.
  • START_DATE and END_DATE — define the effective date range during which the rule was active, a common pattern for time-bounded sourcing logic.
  • ORG_ID — the operating unit or organization context, supporting multi-org partitioning of rule definitions.
  • ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield (DFF) columns, available for customer-specific extensibility.
  • WHO columns — LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, LAST_UPDATED_BY, CREATION_DATE, and CREATED_BY record audit and user traceability.
  • Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE capture the concurrent request that created or last modified the record.

The separation of a surrogate key (AUTOSOURCE_RULE_ID) from a unique business key (AUTOSOURCE_RULE_NAME) is the classic Oracle EBS pattern and supports stable foreign key references even when rule names change.

Common Use Cases and Queries

Because the object is documented as no longer used, direct functional use cases in current 12.1.1 or 12.2.2 implementations are limited. The realistic scenarios are historical reporting, data migration analysis, and impact assessment during upgrades or decommissioning exercises.

A typical investigative query joins the rule table to its dependent documents and vendors:

  • SELECT r.AUTOSOURCE_RULE_ID, r.AUTOSOURCE_RULE_NAME, d.* FROM PO_AUTOSOURCE_RULES r JOIN PO_AUTOSOURCE_DOCUMENTS_ALL d ON d.AUTOSOURCE_RULE_ID = r.AUTOSOURCE_RULE_ID;
  • SELECT r.AUTOSOURCE_RULE_NAME, v.* FROM PO_AUTOSOURCE_RULES r JOIN PO_AUTOSOURCE_VENDORS v ON v.AUTOSOURCE_RULE_ID = r.AUTOSOURCE_RULE_ID;
  • Filtering by ORG_ID or the START_DATE/END_DATE window to determine which rules were in effect during a given historical period.

Reporting use cases include auditing residual legacy configuration before archiving, confirming that no active process still writes to these tables, and documenting data lineage when converting to approved supplier lists.

Related Objects

Two dependent tables directly reference PO_AUTOSOURCE_RULES through the AUTOSOURCE_RULE_ID foreign key, and both are essential to interpreting the parent entity.

  • PO_AUTOSOURCE_DOCUMENTS_ALL — joined on AUTOSOURCE_RULE_ID; holds the sourcing documents associated with each rule.
  • PO_AUTOSOURCE_VENDORS — joined on AUTOSOURCE_RULE_ID; holds the vendor associations for each rule.

In the broader Purchasing module, the functional equivalents that replaced this legacy framework include the approved supplier list structures (such as PO_APPROVED_SUPPLIER_LIST) and sourcing rule definitions. Any migration or impact analysis concerning PO_AUTOSOURCE_RULES should therefore examine these modern counterparts alongside the two documented child tables.