Results for “bcl_id”

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

Overview

OKS_BILLING_DTLS_V is a seeded, VALID view owned by the APPS schema within the Oracle Service Contracts (OKS) product family. It is documented as the "Service contracts billing details view" and is available in Oracle E-Business Suite releases 12.1.1 and 12.2.2. The view presents a denormalized, reporting-friendly projection of billing activity generated by Service Contracts. Rather than exposing the normalized structure of the underlying billing tables, it joins four Service Contracts billing entities and surfaces a single row per billing sub-line, carrying the invoice header, invoice line, tax, bill-instance, and billing-period attributes together. This makes the view a convenient read-only source for reporting and integration scenarios in which a complete picture of an invoiced service contract line is required without navigating the base-table join graph. Users searching for the term "invoice_line_amount" are typically looking for the amount charged on an invoice line, and the view exposes exactly that attribute as INVOICE_LINE_AMOUNT (mapped internally to TRX_LINE_AMOUNT on OKS_BILL_TXN_LINES). Because it is a view rather than a table, no data is stored in it; all content is derived at query time from the base objects.

Underlying Base Objects

The documented base objects referenced by the view are all APPS synonyms in the OKS schema. Each synonym ultimately points to the corresponding OKS base table.

• OKS_BILL_TRANSACTIONS (aliased BTRA) — the billing transaction header, providing the invoice number and invoice date.
• OKS_BILL_TXN_LINES (aliased BTXN) — the billing transaction line, providing the line amount, tax amount, and bill instance number.
• OKS_BILL_CONT_LINES (aliased BCONT) — the contract billing line, providing the billed-from and billed-to dates and the billing transaction link.
• OKS_BILL_SUB_LINES (aliased BSUB) — the billing sub-line, providing the CLE_ID and BCL_ID identifiers.

The relationships are defined through inner joins: BSUB.BCL_ID = BCONT.ID, BCONT.BTN_ID = BTRA.ID, BTRA.ID = BTXN.BTN_ID, and BTXN.BSL_ID = BSUB.ID. This join chain links the header to the transaction line, the transaction line to the contract billing line, and the contract billing line to the billing sub-line, yielding one row per billing sub-line.

Key Columns

• INVOICE_NUMBER — the invoice transaction number from OKS_BILL_TRANSACTIONS (TRX_NUMBER).
• INVOICE_DATE — the invoice transaction date (TRX_DATE).
• INVOICE_LINE_AMOUNT — the amount billed on the invoice line (TRX_LINE_AMOUNT); this is the column most commonly sought by users searching on "invoice_line_amount".
• INVOICE_LINE_TAX_AMOUNT — the tax amount associated with the invoice line (TRX_LINE_TAX_AMOUNT).
• BILL_INSTANCE_NUMBER — the bill instance identifier for the line.
• BILL_FROM_DATE / BILL_TO_DATE — the billing period boundaries sourced from OKS_BILL_CONT_LINES (DATE_BILLED_FROM and DATE_BILLED_TO). Note that the view text aliases the second column as BILL_FROM_TO, while the documented column list names it BILL_TO_DATE; verify with DESC OKS_BILLING_DTLS_V on the target instance.
• CLE_ID / BCL_ID — Service Contracts identifiers for the contract line and billing line context from OKS_BILL_SUB_LINES.

Common Use Cases and Queries

The view is typically used for reconciliation of service contract billing to invoices, revenue and tax reporting by period, and integration extracts that feed downstream financial or reporting systems. A straightforward query listing invoice amounts for a date range is:

• SELECT invoice_number, invoice_date, invoice_line_amount, invoice_line_tax_amount FROM apps.oks_billing_dtls_v WHERE invoice_date BETWEEN :p_from AND :p_to ORDER BY invoice_date;

To aggregate billed amounts by contract line context:

• SELECT cle_id, bcl_id, SUM(invoice_line_amount) billed, SUM(invoice_line_tax_amount) tax FROM apps.oks_billing_dtls_v GROUP BY cle_id, bcl_id;

Because the view performs inner joins only, billing sub-lines lacking a parent transaction or contract line are not returned. No bind parameters or WHERE-clause substitution is built into the view, so all filtering is applied by the calling query.