Search Results estimated_closure_date

Overview

CSS_DEF_IR_DEFECTS_V is a reporting view historically shipped with the Oracle E-Business Suite Customer Support (CSS) module, whose defect-tracking functionality is now obsolete. The view presents a consolidated, read-oriented projection of defect records and is intended for informational queries, defect status reporting, and lightweight integration scenarios where downstream tools require a stable, denormalized column surface rather than direct access to the normalized base table. In Oracle EBS 12.1.1 and 12.2.2 the object is not implemented in the delivered database; ETRM documentation explicitly records "Not implemented in this database" for the Implementation/DBA Data section. Consequently, the view typically appears only in upgraded or legacy environments where the older CSS defect schema survived migration, or in custom installations that retained deprecated support objects. Its practical role is a compatibility layer: it exposes the defect header attributes and costing attributes that reporting consumers expect, while hiding the underlying storage details of the base table.

Underlying Base Objects

The documented definition is a straight projection over a single base table, CSS_DEF_DEFECTS_B, as indicated by the "FROM CSS_DEF_DEFECTS_B" clause at the end of the view text. No other referenced base objects are documented in the ETRM metadata; the "Referenced base objects" field lists "none documented," and the owner is not recorded. Because the view performs no joins or unions, it inherits the row grain of the base table, where one row represents one defect. The "_B" suffix on the base table follows the standard EBS convention for the base (non-translated) portion of a table that may be paired with a "_TL" translation table; the view itself does not expose translated columns. The presence of OBJECT_VERSION_NUMBER and the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) confirms that the view is built on an entity that participates in EBS concurrency control and audit tracking.

Key Columns

• DEFECT_ID / DEFECT_NUMBER — Primary identifier and the user-facing defect number; the natural key for reporting.
• CATEGORY_TYPE, PROBLEM_TYPE_ID, PHASE_ID, STATUS_ID, SEVERITY_ID, PRIORITY_ID — Classification and workflow attributes used for filtering and grouping defect populations.
• FILED_DATE, RESOLVED_DATE, CLOSED_DATE, UPDATED_DATE — Lifecycle timestamps supporting cycle-time and aging analysis.
• RESOLVED_FLAG, OPEN_FLAG, DELETED_FLAG, PUBLISH_EXT_FLAG, COMMIT_TO_FIX_FLAG — Boolean state indicators for status reconciliation.
• ESTIMATED_COST and ESTIMATED_COST_UOM — The estimated cost to resolve the defect and its unit of measure; the column most directly associated with the "estimated_cost" search term.
• ACTUAL_COST and ACTUAL_COST_UOM — The realized cost of resolution, allowing variance comparison against the estimate.
• ESTIMATED_RESOLUTION_DATE, ESTIMATED_CLOSURE_DATE, SYSTEM_RESOLUTION_DATE, SYSTEM_CLOSURE_DATE — Planned versus system-derived dates for schedule tracking.
• PRODUCT_INV_ITEM_ID, COMPONENT_INV_ITEM_ID, SUB_COMPONENT_INV_ITEM_ID and their revision columns — The affected product structure hierarchy.
• ORIGINATING_CUSTOMER_ID, EXT_CUSTOMER_FLAG, TERRITORY_ID — Customer and territory attribution for external defect analysis.
• ATTRIBUTE1–ATTRIBUTE15, CONTEXT — Descriptive flexfield segments.

Common Use Cases and Queries

Typical usage centers on defect cost and status reporting. A representative query retrieving open defects with cost estimates follows:

• SELECT defect_number, status_id, severity_id, estimated_cost, estimated_cost_uom, actual_cost FROM css_def_ir_defects_v WHERE open_flag = 'Y' AND deleted_flag = 'N';
• SELECT category_type, COUNT(*), SUM(estimated_cost) FROM css_def_ir_defects_v GROUP BY category_type;
• SELECT defect_number, filed_date, resolved_date, (resolved_date - filed_date) days_to_resolve FROM css_def_ir_defects_v WHERE resolved_flag = 'Y';

Because the object is obsolete and generally unimplemented in 12.1.1 and 12.2.2, any integration depending on it should be validated against the target environment before deployment, and migration toward the supported defect-tracking tables is advisable.