Search Results oe_retrobill_request_u1

Overview

The ONT.OE_RETROBILL_REQUESTS table is the header table that identifies and defines a retrobill request within Oracle Order Management in EBS 12.1.1 and 12.2.2. A retrobill request is a controlled, parameter-driven process that re-prices and re-invoices previously shipped and invoiced order lines when pricing or agreement corrections must be applied retroactively. The table stores the identity of the request, the parameters used to constrain its scope, its execution state, and the concurrent request context under which it was submitted. It is owned by the ONT (Order Management) schema and resides in the APPS_TS_TX_DATA tablespace.

The record is heavily driven by Oracle's concurrent manager: the request row carries the REQUEST_ID of the concurrent program that processes it, together with PROGRAM_APPLICATION_ID and PROGRAM_ID, linking the business intent to the technical execution. Descriptive flexfield columns (the CONTEXT and ATTRIBUTE1 through ATTRIBUTE15 set) and standard Who columns are also present. From a Data Vault modeling perspective, the metadata heuristic classifies this object as standalone; nevertheless, it behaves naturally as a hub-like reference entity whose surrogate key is RETROBILL_REQUEST_ID, sequentially populated from the sequence OE_RETROBILL_REQUEST_S.

Key Information Stored

The most operationally significant columns include the following. The primary key RETROBILL_REQUEST_ID is a NUMBER and is the column behind the unique index OE_RETROBILL_REQUEST_U1 (the documented business-key candidate). The user-facing NAME (VARCHAR2 240) is the request name and DESCRIPTION (VARCHAR2 2000) holds a short comment; a separate non-unique index OE_RETROBILL_REQUEST_N1 supports lookups by NAME.

• EXECUTION_MODE (VARCHAR2 30) — indicates preview versus execute mode, controlling whether the run is simulated or committed.
• ORDER_TYPE_ID (NUMBER) — an input parameter restricting the retrobill run to a specific order type; it carries the sole documented foreign-key relationship.
• RETROBILL_REASON_CODE (VARCHAR2 30) — the reason attributed to the retroactive correction.
• EXECUTION_DATE (DATE) — the date the request is executed.
• INVENTORY_ITEM_ID (NUMBER) — populated when the request targets a single item.
• SOLD_TO_ORG_ID (NUMBER) — populated when the request targets a single customer.
• REQUEST_ID — the concurrent program request ID, alongside PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATED_DATE.
• CONTEXT and ATTRIBUTE1–ATTRIBUTE15 — Descriptive Flexfield storage.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard Who columns for auditability.

Common Use Cases and Queries

Typical scenarios include auditing which retrobill requests were executed versus previewed, correlating a request to its concurrent program output, and reporting on correction activity by customer, item, or order type. A common query joins the request header to its concurrent request to inspect execution status:

• Listing recent requests: SELECT retrobill_request_id, name, execution_mode, execution_date FROM ont.oe_retrobill_requests ORDER BY creation_date DESC;
• Executed corrections only: SELECT ... WHERE execution_mode = 'EXECUTE';
• Scoping by recipient or item: filtering on SOLD_TO_ORG_ID or INVENTORY_ITEM_ID when those columns are non-null.
• Tracing the concurrent execution via REQUEST_ID against FND_CONCURRENT_REQUESTS.

Related Objects

The documented foreign key maps ORDER_TYPE_ID to SO_ORDER_TYPES_115_ALL, and the request is processed by Order Management's retrobill concurrent program. Additional significant dependencies include the sequence OE_RETROBILL_REQUEST_S, FND_CONCURRENT_REQUESTS (via REQUEST_ID), the retrobill detail lines that reference RETROBILL_REQUEST_ID, OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL for the affected orders, and RA_CUSTOMER_TRX_ALL where resulting invoices are recorded.