Search Results rul_lasll

Overview

APPS.OKL_OR_PAYMENT_DETAILS_UV is a reporting view in the Oracle E-Business Suite (EBS) Order and Contracts / Enterprise Contracts (OKL and OKC) schema. It is a user-facing view (suffix _UV) that presents structured payment schedule details derived from the rules repository. The name and internal alias rul_lasll — the term users frequently search for — refer to the rule rows whose RULE_INFORMATION_CATEGORY equals 'LASLL', which drive lease payment stream definitions.

The view transforms raw, generically stored rule information into column-oriented, human-readable data. Rule attributes in OKC_RULES_B are stored positionally in RULE_INFORMATION1..N and dates as canonical strings; this view decodes those positions into named columns such as periods, periodic amount, stub days, stub amount, start date, and end date. It therefore plays a crucial role in contract financing reporting, payment stream analysis, and downstream integration where a flat, query-ready projection of a lease schedule is required rather than the normalized rule storage.

Underlying Base Objects

Per the documented metadata, the view is defined over two referenced base objects:

• OKC_RULES_B (SYNONYM) — the core rules table storing contract rule rows. The view filters this table to RULE_INFORMATION_CATEGORY = 'LASLL' and further restricts to rows where NVL(OBJECT2_ID2,'#') = '#' and JTOT_OBJECT2_CODE = 'OKL_STRMHDR', isolating payment-stream header rules associated with lease/order streams.
• FND_DATE (PACKAGE) — the Oracle Applications date utility package. The view calls FND_DATE.CANONICAL_TO_DATE to convert the canonical date strings held in RULE_INFORMATION2 into proper DATE values.

The view is consequently a thin, decode-and-filter layer over the rules repository rather than a materialized aggregate, so it always reflects the current state of the underlying rule rows.

Key Columns

• RUL_LASLL_ID — the rule row identifier (OKC_RULES_B.ID); the primary key for each payment detail row.
• PERIODS — number of schedule periods, sourced from RULE_INFORMATION3.
• PERIODIC_AMOUNT — the recurring payment amount, from RULE_INFORMATION6.
• STUB_DAYS and STUB_AMOUNT — first/last partial-period parameters, from RULE_INFORMATION7 and RULE_INFORMATION8.
• START_DATE — canonical date in RULE_INFORMATION2 converted via FND_DATE.CANONICAL_TO_DATE.
• END_DATE — computed by DECODE: if STUB_DAYS is null, it uses ADD_MONTHS of the start date by periods multiplied by a frequency factor (OBJECT1_ID1: M=1, Q=3, S=6, A=12) minus one day; otherwise it adds the stub days minus one.
• RGP_ID, DNZ_CHR_ID, OBJECT2_ID1, OBJECT2_ID2, JTOT_OBJECT2_CODE — foreign-key style context linking the rule to its owning contract/stream; the last is fixed at 'OKL_STRMHDR'.

Common Use Cases and Queries

Typical uses include reconciling payment schedules to a contract header, reporting periodic and stub amounts, and feeding downstream calculations that need start/end dates per schedule. A basic query:

• SELECT rul_lasll_id, periods, periodic_amount, start_date, end_date, stub_days, stub_amount FROM apps.okl_or_payment_details_uv ORDER BY start_date;
• Filter by contract: ... WHERE dnz_chr_id = :p_contract_id;
• Aggregate totals: SELECT dnz_chr_id, SUM(periodic_amount * periods) FROM apps.okl_or_payment_details_uv GROUP BY dnz_chr_id;

Because the view joins logic through OBJECT2_ID1 and JTOT_OBJECT2_CODE, it is most reliable when consumed together with the stream header hierarchy and joined back to OKC_RULES_B for full rule context. Its ordered output by START_DATE makes it convenient for chronological schedule presentations.