Results for “oke_k_lines_full_v”

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

Overview

OKE_K_LINES_FULL_V is a denormalized reporting view owned by the APPS schema in Oracle EBS Release 12.1.1 and 12.2.2. It belongs to the OKE — Project Contracts module (Oracle Contracts for Projects) and is documented in ETRM as the "Contract line extended information view." The view consolidates contract line data that is otherwise distributed across the OKC contract header/line tables, OKE delivery line extensions, project and task references, and descriptive lookup tables. Its purpose is to present a single, query-ready row per contract line, enriched with version numbers, status meanings, item and project attributes, and flag translations, so that reports, concurrent programs, and integrations do not have to reconstruct the same joins repeatedly.

Because OKE underpins project contract authoring and delivery, the view is typically consumed by billing, revenue, and delivery reporting rather than by the base data-entry forms. It exposes ROWID and OBJECT_VERSION_NUMBER, which also makes it usable as a starting point for downstream update-aware processes.

Underlying Base Objects

The documented 12.2.2 metadata lists the following referenced base objects: OKC_K_HEADERS_ALL_B, OKC_K_LINES_B, OKC_K_LINES_TL, OKC_LINE_STYLES_TL, OKC_STATUSES_TL, OKE_K_LINES, OKE_K_VERS_NUMBERS_V, OKE_PRIORITY_CODES_TL, OKE_BILLING_METHODS_TL, HR_ALL_ORGANIZATION_UNITS_TL, PA_PROJECTS_ALL, PA_TASKS, and the OKE_UTILS package. The view therefore joins the contract core (header, line, and line translation tables) to the OKE delivery-line extension, then resolves display values from the status, line-style, priority, and billing-method translation tables, and finally links delivery lines to PA projects and tasks and their owning organization units. The OKE_UTILS package is invoked inline to derive item number, item description, and YES/NO descriptions.

Key Columns

• ID, LINE_NUMBER, DISPLAY_SEQUENCE, CLE_ID, DNZ_CHR_ID — line identity and ordering attributes; CLE_ID/DNZ_CHR_ID tie the row to the contract line entity and header.
• MAJOR_VERSION, MINOR_VERSION — sourced through OKE_K_VERS_NUMBERS_V, providing the version context of the contract line.
• STS_CODE and MEANING — status code with its translated meaning.
• LINE_QUANTITY, LINE_VALUE, UNIT_PRICE, UOM_CODE, LINE_LIQUIDATION_RATE — commercial values for the delivery line.
• INVENTORY_ITEM_ID plus derived ITEM_NUMBER and ITEM_DESCRIPTION — item details resolved by OKE_UTILS against the header inventory organization.
• PROJECT_ID, SEGMENT1, project NAME/START_DATE/COMPLETION_DATE, TASK_ID, TASK_NUMBER, TASK_NAME — project and task associations used in project-driven contract reporting.
• Flag columns — BILLABLE_FLAG, COMPLETED_FLAG, EXPORT_FLAG, SHIPPABLE_FLAG, SUBCONTRACTED_FLAG, NSP_FLAG, CUSTOMER_APPROVAL_REQ_FLAG, PROGRESS_PAYMENT_FLAG, DELIVERY_ORDER_FLAG, SPLITED_FLAG — each paired with an OKE_UTILS.YES_NO translation.
• Financial terms — COST_OF_MONEY, PREPAYMENT_PERCENTAGE, PREPAYMENT_AMOUNT, PROGRESS_PAYMENT_RATE, PROGRESS_PAYMENT_LIQ_RATE, DISCOUNT_FOR_PAYMENT.

Common Use Cases and Queries

Typical scenarios include contract line listing reports, project-to-contract reconciliation, delivery scheduling extracts, and integration feeds that require readable flag and status values. A basic query follows:

• Contract line detail: SELECT line_number, item_description, line_quantity, line_value, uom_code, meaning FROM oke_k_lines_full_v WHERE dnz_chr_id = :contract_id ORDER BY display_sequence;
• Project delivery lines: SELECT segment1, task_number, inventory_item_id, delivery_date, billable_flag FROM oke_k_lines_full_v WHERE project_id = :project_id;
• Open billable lines: SELECT id, line_number, line_value FROM oke_k_lines_full_v WHERE billable_flag = 'Y' AND completed_flag = 'N';
• Integration extract: SELECT id, major_version, minor_version, object_version_number, sts_code FROM oke_k_lines_full_v WHERE dnz_chr_id = :contract_id.

Because the view performs numerous outer joins and calls OKE_UTILS per row, queries should always be filtered by contract header or project identifiers to keep execution efficient.