Results for “cst_xla_wo_v”

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

Overview

CST_XLA_WO_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, catalogued under the Bills of Material (BOM) product family. It exposes write-off transactions recorded in the Cost Management module, joining them to purchasing, supplier, item, reason, and organization attributes so that each write-off can be reported in a business-friendly form rather than as a set of surrogate keys. The view is classified as a standard, valid database object in both release 12.1.1 and 12.2.2, and its naming convention — the CST prefix combined with the XLA segment — indicates that it is intended to support the Subledger Accounting and cost accounting reporting layer that consumes write-off activity. The view is read-only and is not an entity against which DML should be performed; it is a query surface used by reports, extracts, and integration queries. Analysts searching on "write_off_id" reach this view because WRITE_OFF_ID is one of its ten projected columns and serves as the primary identifier for each write-off record.

Underlying Base Objects

The view is defined over seven documented base objects, each joined with outer-join semantics where the relationship is optional. The driving table is CST_WRITE_OFFS (CWO), referenced through a synonym, which supplies the write-off identifier, transaction date, destination type, comments, operating unit, reason, vendor, and purchase-order distribution references. PO_DISTRIBUTIONS_ALL (POD) is joined on PO_DISTRIBUTION_ID, and PO_HEADERS_ALL (POH) is subsequently joined on PO_HEADER_ID to retrieve the purchase order number from SEGMENT1. Supplier information is obtained from PO_VENDORS (POV, itself a view) on VENDOR_ID. The reason description is taken from MTL_TRANSACTION_REASONS (MTR) on REASON_ID, and the operating unit name is resolved from HR_ALL_ORGANIZATION_UNITS (HAOU) on OPERATING_UNIT_ID. Finally, the item description is resolved from MTL_SYSTEM_ITEMS_B_KFV (MSI) using a scalar subquery with a ROWNUM<2 restriction to guarantee a single concatenated segment value. All joins to purchasing, supplier, and reason data are outer joins, so a write-off row is never suppressed by missing reference data.

Key Columns

• WRITE_OFF_ID — Primary identifier of the write-off transaction in CST_WRITE_OFFS; the column most commonly used for point lookups and joins back to the base table.
• ITEM_NAME — Concatenated item segments resolved from MTL_SYSTEM_ITEMS_B_KFV; NULL when INVENTORY_ITEM_ID is NULL.
• PO_NUMBER — Purchase order number (PO_HEADERS_ALL.SEGMENT1) associated with the write-off distribution.
• VENDOR_NAME — Supplier name from PO_VENDORS, useful for reconciliation against payables and receiving.
• TRANSACTION_DATE — Accounting-relevant date of the write-off.
• DESTINATION_TYPE_CODE — Classification of the write-off destination, indicating the disposition applied to the inventory.
• OPERATING_UNIT_NAME and OPERATING_UNIT_ID — Organization name and key from HR_ALL_ORGANIZATION_UNITS; the ID supports data-security and multi-org filtering.
• REASON_NAME — Descriptive write-off reason from MTL_TRANSACTION_REASONS.
• COMMENTS — Free-text remarks captured on the write-off.

Common Use Cases and Queries

The view is principally used for write-off analysis reporting, supplier recovery tracking, and subledger reconciliation. A frequent pattern is filtering by the write-off identifier for a focused audit:

• SELECT write_off_id, item_name, po_number, vendor_name, transaction_date, destination_type_code, reason_name FROM cst_xla_wo_v WHERE write_off_id = :p_write_off_id;
• SELECT operating_unit_name, reason_name, COUNT(*) FROM cst_xla_wo_v WHERE transaction_date BETWEEN :p_from AND :p_to GROUP BY operating_unit_name, reason_name;
• SELECT vendor_name, SUM(1) FROM cst_xla_wo_v WHERE po_number IS NOT NULL GROUP BY vendor_name;

Because joins are outer, reports can safely display rows lacking a purchase order, vendor, or reason without losing the write-off itself. Queries should apply operating-unit filters explicitly when multi-org security is required, since the view does not enforce organization access by itself.