Results for “pspbv_autopop_rule_clause”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PSPBV_AUTOPOP_RULE_CLAUSE is a read-only database view in the Oracle E-Business Suite (EBS) Labor Distribution module (PSP). It exposes the rule clause configuration used by the AutoPop (automatic population) feature, which determines how labor distribution costs are automatically split across accounting flexfields when no manual distribution is entered. The view presents the individual clause lines that make up an AutoPop rule, including the account assignment, the parameter line sequence, the lookup that identifies the clause type, the operand, and any user-supplied value. Because the object is defined with the WITH READ ONLY clause, it is intended strictly for querying and reporting; it cannot be used as a DML target in customizations or concurrent programs. In Oracle EBS 12.1.1 and 12.2.2 the view resides in the APPS schema and is available to any responsibility with the appropriate grants, making it a convenient integration point for extracting AutoPop rule definitions without joining the underlying parameter table directly.

Underlying Base Objects

The view is defined over a single base table: PSP_AUTO_PARAMS. The ETRM metadata documents no additional referenced base objects. The view text selects the columns ACCT_ID, PARAM_LINE_NUM, LOOKUP_ID, OPERAND, USER_VALUE, and the standard WHO audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE) from PSP_AUTO_PARAMS and applies a read-only restriction. Consequently, PSPBV_AUTOPOP_RULE_CLAUSE is a thin projection of PSP_AUTO_PARAMS: it does not aggregate, filter, or join the data, so one row in the view corresponds to one row in the base table. Any change to the underlying table is immediately reflected in query results. The ETRM entry notes the view is "Not implemented in this database," meaning the object exists in the documented product schema but may not be present in a given environment; availability should be verified in the target instance before it is referenced in custom code.

Key Columns

• ACCT_ID — Identifier of the AutoPop rule or account assignment header that owns this clause. This is the primary correlation key back to the rule definition.
• PARAM_LINE_NUM — Sequence number of the clause within the rule. It establishes the evaluation or display order of the individual clause lines.
• LOOKUP_ID — The lookup code that classifies the clause, identifying which operand, value type, or rule element the row represents. This is the column most frequently queried when searching for a specific AutoPop rule clause definition.
• OPERAND — The operator or comparison applied to the clause, such as an equality or range condition used during rule evaluation.
• USER_VALUE — The literal value supplied by the user for the clause, for example a segment value or a threshold used by the rule.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE — Standard Oracle WHO audit columns recording who created and last modified each clause row and when, supporting audit and change-tracking reporting.

Common Use Cases and Queries

Typical use cases include auditing AutoPop rule definitions, migrating rule configurations between environments, and troubleshooting why labor costs were distributed to an unexpected account. The view is also useful for building custom reports that explain the clause logic behind an AutoPop rule. To retrieve all clauses for a given rule ordered by line number:

SELECT acct_id, param_line_num, lookup_id, operand, user_value
FROM   apps.pspbv_autopop_rule_clause
WHERE  acct_id = :p_acct_id
ORDER BY param_line_num;

To locate clauses of a particular type, filter on the lookup identifier:

SELECT acct_id, param_line_num, lookup_id, operand, user_value
FROM   apps.pspbv_autopop_rule_clause
WHERE  lookup_id = :p_lookup_id;

For change auditing, the WHO columns can be included to review recent modifications. Because the view is read-only and backed solely by PSP_AUTO_PARAMS, these queries perform efficiently and can be embedded in concurrent programs or BI Publisher data templates. Before deployment, confirm the view exists in the target instance, since the ETRM metadata records it as not implemented in the documented database.