Search Results bne_duplicate_profiles_tl_pk

Overview

BNE_DUPLICATE_PROFILES_TL is a translation (TL) table within the BNE schema, owned by Oracle Web Applications Desktop Integrator (Web ADI). It stores the language-dependent definition of a duplicate upload profile. Duplicate upload profiles govern how Web ADI detects, flags, and handles rows that appear more than once during a desktop integration upload, allowing integrators to define tolerance rules and control whether duplicates are rejected, merged, or accepted. The table carries the _TL suffix convention, indicating it holds translated descriptive text keyed by LANGUAGE, and is intended to be joined with a base table that holds the language-independent definition.

The ETRM metadata classifies this object heuristically as standalone under a Data Vault modeling lens — that is, no foreign-key relationships to other tables were mined from its structure. In Data Vault terms this suggests treating it as a self-contained reference structure rather than a hub, link, or satellite of a shared business key. Its effective grain is one row per application, profile code, and language, which makes it a translation satellite in spirit even where no explicit link is documented.

Key Information Stored

The table is documented with 11 columns in the 12.2.2 physical schema. The most significant are:

• APPLICATION_ID — identifies the Oracle E-Business Suite application context to which the duplicate profile belongs; a component of both the primary key and unique index.
• DUP_PROFILE_CODE — the business identifier of the duplicate upload profile; a component of both keys.
• LANGUAGE — the language of the translated row, forming the translation key.
• SOURCE_LANG — the source language from which the translated content derives.
• ZD_EDITION_NAME — the editioning column present in 12.2.x, used in the unique index to discriminate editions.
• USER_NAME, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS who-column audit attributes.

The surrogate/business primary key is BNE_DUPLICATE_PROFILES_TL_PK over (APPLICATION_ID, DUP_PROFILE_CODE, LANGUAGE). A unique index, BNE_DUPLICATE_PROFILES_TL_UK1, is defined over (APPLICATION_ID, DUP_PROFILE_CODE, LANGUAGE, ZD_EDITION_NAME), confirming the grain and supporting edition-aware lookups.

Common Use Cases and Queries

Typical usage is resolving the human-readable definition of a duplicate upload profile for a given language. Reporting queries join to the base profile table or filter directly by application and language:

SELECT dup_profile_code, language, source_lang
FROM   bne.bne_duplicate_profiles_tl
WHERE  application_id = :app_id
AND    language IN (USERENV('LANG'), 'US');

Administrators use the table to audit which profiles have translated definitions available, and to identify gaps where a profile exists in one language but not another. Duplicate-detection troubleshooting frequently reads the profile definition to understand why specific upload rows were flagged, cross-referencing the audit who-columns to determine when a profile was last modified.

Related Objects

Because the metadata records no foreign keys (standalone classification), relationships are logical rather than enforced. The most significant associated objects are:

• BNE_DUPLICATE_PROFILES (and its _B base) — the language-independent profile definition keyed by APPLICATION_ID and DUP_PROFILE_CODE, joined on those columns.
• FND_APPLICATION — resolves APPLICATION_ID to the owning application short name.
• FND_LANGUAGES — validates and describes the LANGUAGE and SOURCE_LANG values.
• FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to user identities.
• BNE Interfaces / Web ADI upload APIs — consume the profile definition at upload time to drive duplicate handling behavior.

As a translation table, BNE_DUPLICATE_PROFILES_TL should always be queried with an explicit language predicate to avoid returning multiple rows per profile code.