Results for “lns_loan_documents”

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

Overview

The LNS_LOAN_DOCUMENTS table is a core data object within the Oracle E-Business Suite Loans (LNS) module, belonging to the LNS schema. Its documented purpose is to store all documents related to a Source Object. In practice, this makes it a polymorphic document repository: rather than being tied to a single parent entity type, each row associates a stored document with an arbitrary source record identified by a source identifier and a source table name. This design allows one physical table to serve the documentation needs of the many distinct loan-related entities managed across the module, including loan agreements, borrower records, collateral items, and servicing transactions.

According to the heuristic Data Vault classification mined from the foreign key structure, this object is treated as standalone. That classification is a direct consequence of the polymorphic SOURCE_ID and SOURCE_TABLE design: because the source reference is resolved at runtime rather than enforced by a declarative foreign key, the table does not participate in a conventional hub, link, or satellite chain. From a Data Vault modeling perspective, this can be viewed as a self-contained satellite-like structure that records document payloads keyed by a surrogate identifier and versioned by source reference.

Key Information Stored

The documented physical schema contains 17 columns, with the following being the most operationally significant:

• DOCUMENT_ID — the surrogate primary key defined by LNS_LOAN_DOCUMENTS_PK. It is also the sole column of unique index LNS_LOAN_DOCUMENTS_U1, making it the canonical business identifier for a document record.
• SOURCE_ID and SOURCE_TABLE — the polymorphic foreign reference pair that identifies the owning business record. Together with DOCUMENT_TYPE and VERSION, these form the composite business-key candidate LNS_LOAN_DOCUMENTS_U2.
• DOCUMENT_TYPE — classifies the nature of the stored document, allowing multiple document categories to coexist for the same source record.
• VERSION — supports document versioning, so successive revisions of the same logical document can be retained rather than overwritten.
• DOCUMENT_XML — the payload column holding the document content. Its large-object nature is indicated by the SYS_IL...$$ index entry in the documented schema, which reflects an underlying LOB segment.
• REASON — captures the rationale or annotation associated with the document, supporting audit and compliance narratives.
• OBJECT_VERSION_NUMBER — the standard EBS optimistic locking column used to detect concurrent updates.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN provide standard who/when tracking, while PROGRAM_UPDATE_DATE, PROGRAM_APPLICATION_ID, PROGRAM_ID, and REQUEST_ID capture the concurrent program and request context in which the row was last modified.

Common Use Cases and Queries

Typical usage centres on retrieving the documents attached to a given business entity and on reconstructing document history. A common query fetches the latest version of each document type for a source record:

• Documents for a specific source: SELECT document_id, document_type, version FROM lns_loan_documents WHERE source_id = :id AND source_table = :table_name ORDER BY document_type, version DESC;
• Version history: filter on SOURCE_ID, SOURCE_TABLE, and DOCUMENT_TYPE, ordering by VERSION, to audit how a document evolved over time.
• Reporting: join the audit columns to FND_USER (CREATED_BY, LAST_UPDATED_BY) to attribute document creation or amendment, and inspect REQUEST_ID against FND_CONCURRENT_REQUESTS for traceability.
• Concurrency control: include OBJECT_VERSION_NUMBER in the WHERE clause of update statements to prevent lost updates in custom extensions.

Because SOURCE_TABLE is stored as a name, reporting queries must constrain it explicitly; joining to a fixed parent table without filtering on SOURCE_TABLE risks returning unrelated documents.

Related Objects

The polymorphic design means fewer declarative relationships than a typical child table, but the following objects are most significant:

• Loan source tables — the various LNS entities referenced through SOURCE_ID and SOURCE_TABLE, joined by resolving SOURCE_TABLE to the corresponding physical table name at query time.
• FND_USER — joined on CREATED_BY and LAST_UPDATED_BY for user attribution.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID to trace the concurrent program context.
• FND_APPLICATION — joined on PROGRAM_APPLICATION_ID to resolve the owning application of the last update program.
• LNS_LOAN_DOCUMENTS_U1 / _U2 — the unique indexes enforcing DOCUMENT_ID and the composite source/type/version uniqueness constraints.

Custom integrations should honour the composite uniqueness rule for SOURCE_ID, SOURCE_TABLE, DOCUMENT_TYPE, and VERSION to avoid conflicts with the standard application logic.