Search Results cp_type




Overview
Explore in AI Chat

Overview

ONT_OEXOEWFR_XMLP_PKG is an Oracle Order Management report package body owned by APPS and classified under the ETRM taxonomy as OTHER. The package supports the "Order Workflow Status" style XML Publisher report commonly known as OEXOEWFR, which surfaces order and line information together with workflow activity state, hold conditions, and charge-adjusted extended values. In Oracle EBS 12.1.1 and 12.2.2 the package is generated from a report source file (header OEXOEWFRB.pls, version 120.1) and follows the standard XML Publisher report package pattern: a BEFORE REPORT trigger, a set of formula columns evaluated per row, a between-pages processing hook, and an AFTER REPORT trigger, all orchestrated through the concurrent manager.

The package is not a general-purpose API. It exists solely to compute derived report columns and to supply the SQL fragments that drive the report query. It is documented as referenced by zero other packages, confirming that its role is terminal within the report execution path rather than part of a shared service layer. The cp_type construct visible in report parameter contexts is indirectly relevant here, since report parameters passed by the concurrent program (including type or category selections) feed the valid-trigger logic inside this package.

Key Procedures and Functions

The 27 documented program units divide into three functional groups. The first group computes derived column values. CF_EXTENDED_VALUEFORMULA calculates an extended line value by calling OE_CHARGE_PVT.GET_CHARGE_AMOUNT, negating the value when LINE_CATEGORY_CODE equals 'RETURN', and adding the returned charge amount. CF_HOLD_VALUEFORMULA returns 'YES' or otherwise based on whether an unreleased header-level or line-level hold exists in OE_ORDER_HOLDS_ALL. CF_COUNTRYFORMULA, CF_CURRENCYFORMULA, CF_ITEM_Y_NFORMULA, CF_BOOKED_DISPLAYFORMULA, CF_LINE_NUMBERFORMULA, CF_ORDERED_DATEFORMULA, and CF_MASTER_ORGFORMULA provide display formatting for country, currency, item indicator, booked flag, line numbering, ordered date, and master organization respectively.

The second group consists of validation triggers: P_OVERDUE_DAYSVALIDTRIGGER, P_NO_DATAVALIDTRIGGER, P_ACTIONSVALIDTRIGGER, and PARAM_WHERE_CLAUSEVALIDTRIGGER. These validate or transform report parameters before the query executes, allowing the WHERE clause of the report to be adjusted dynamically. G_LINE_IDGROUPFILTER is a group filter applied to the line identifier grouping level.

The third group contains the report lifecycle hooks: BEFOREREPORT, BEFOREPFORM, AFTERPFORM, AFTERPFORM0009, BETWEENPAGE, and AFTERREPORT. These initialize report state, register the parameter WHERE clause, and perform page-level and end-of-report cleanup.

Tables Accessed

The package reads three documented application tables plus DUAL. OE_ORDER_HOLDS_ALL provides hold status used by CF_HOLD_VALUEFORMULA, distinguishing header holds (LINE_ID IS NULL) from line holds. WF_ITEM_ACTIVITY_STATUSES and WF_PROCESS_ACTIVITIES supply Oracle Workflow activity state so the report can display the current workflow activity and its result for each order or line. DUAL is used for single-row lookups and constant expressions. All tables are referenced through APPS synonyms, consistent with standard EBS installation and the package's APPS ownership.

Usage Notes

ONT_OEXOEWFR_XMLP_PKG is invoked exclusively through the XML Publisher report infrastructure rather than by direct user or custom code calls. The concurrent program definition supplies the report parameters; validation triggers and BEFOREREPORT then finalize the WHERE clause and initialize package-level state. Formula columns are evaluated once per report row so that charges, holds, and workflow status are resolved in the correct query context. Because the package depends on OE_CHARGE_PVT and the Workflow status tables, performance is sensitive to order volume; organizations running the report at scale should ensure OE_ORDER_HOLDS_ALL and the workflow status tables are properly indexed. Custom development should not call these procedures directly; equivalent logic should be sourced from the underlying public APIs such as OE_CHARGE_PVT.