Results for “token_code”

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

Overview

PRP_TOKENS_B is the base (non-translated) table in the Oracle E-Business Suite Proposals (PRP) module that stores the master definition of tokens. In ETRM, tokens are reusable, parameterized text or value placeholders that are resolved and substituted into proposal documents, templates, and generated output. This table holds the base information about each token — its identity, code, type, and programmatic/data-type attributes — while the language-dependent descriptions and the concrete resolved values reside in companion translation tables.

The table resides in the PRP schema and is delivered as VALID in both EBS 12.1.1 and 12.2.2. Because it carries editioning support (ZD_EDITION_NAME), it participates in the Oracle EBS online patching / editioning model used from 12.2 onward, so queries against it must be aware that a row may exist in multiple editions.

Under the heuristic Data Vault classification mined from the foreign-key structure, PRP_TOKENS_B is hub-leaning. In Data Vault modeling terms it behaves as the business hub for the token concept: it owns a stable surrogate key (TOKEN_ID) plus a natural business key (TOKEN_CODE), and is referenced by surrounding tables that supply descriptive and resolved-value context. This should be treated as a proposed modeling perspective rather than a delivered construct.

Key Information Stored

The documented physical schema exposes 33 columns. The most consequential are:

• TOKEN_ID — the surrogate primary key for the token, enforced by PRP_TOKENS_B_PK and also present in the U1 unique index (TOKEN_ID, ZD_EDITION_NAME). This is the column all dependent tables join on.
• TOKEN_CODE — the natural business key, enforced by PRP_TOKENS_B_UK1 and by the U2 unique index (TOKEN_CODE, ZD_EDITION_NAME). This is the human-identifiable token reference.
• TOKEN_TYPE — classifies the token, distinguishing how it is sourced or resolved.
• NATIVE_OBJECT_TYPE — identifies the underlying object the token is anchored to.
• USER_DEFINED_OPTIONS — governs user-definable behavior/allowances for the token.
• JAVA_PROGRAM_NAME — the Java handler invoked to resolve or render the token.
• DATA_TYPE and DISPLAY_LENGTH — the datatype of the token value and its presentation length.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective date range controlling when the token is active.
• ZD_EDITION_NAME — the editioning discriminator, central to the 12.2 unique indexes.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard who-column auditing and optimistic-locking controls.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the standard EBS descriptive flexfield (DFF) columns.

Common Use Cases and Queries

Typical usage centers on looking up a token by its business code, enumerating active tokens, and joining to translations and values. A representative lookup by business key:

SELECT token_id, token_code, token_type, java_program_name, data_type
FROM   prp.prp_tokens_b
WHERE  token_code = :p_code
AND    NVL(:edition, zd_edition_name) = zd_edition_name
AND    SYSDATE BETWEEN NVL(start_date_active, SYSDATE)
                   AND NVL(end_date_active, SYSDATE);

Reporting scenarios include building a token catalog for administrative review, resolving a token to its language-specific description, and tracing which token values feed a proposal. A join to the translation table illustrates the latter two:

SELECT b.token_id, b.token_code, t.description
FROM   prp.prp_tokens_b    b,
       prp.prp_tokens_tl   t
WHERE  b.token_id = t.token_id
AND    t.language = USERENV('LANG');

Because of editioning, any direct query should constrain ZD_EDITION_NAME (or filter to the appropriate edition) to avoid returning duplicate rows for an object that has been patched across editions.

Related Objects

The following dependent and referencing objects are the most significant for navigating around PRP_TOKENS_B:

• PRP_TOKENS_TL — the translation table for token descriptions; joins on TOKEN_ID (PRP_TOKENS_TL.TOKEN_ID → PRP_TOKENS_B).
• PRP_TOKEN_VALUES_TL — holds translated token values; joins on TOKEN_ID (PRP_TOKEN_VALUES_TL.TOKEN_ID → PRP_TOKENS_B).
• FTE_PTRK_SOURCES — references tokens via TOKEN_ID, linking tokens into the FTE tracking source configuration.
• FTE_PTRK_PARAMS — references tokens via TOKEN_ID, linking tokens into parameter definitions.
• PRP_TOKENS_B_PK / PRP_TOKENS_B_UK1 / PRP_TOKENS_B_U1 / PRP_TOKENS_B_U2 — the primary and unique constraints/indexes that enforce TOKEN_ID and TOKEN_CODE uniqueness (the U1/U2 indexes additionally include ZD_EDITION_NAME).

Together these objects position PRP_TOKENS_B as the hub of the token model: the base table supplies identity and type, the TL tables supply localized text, and the FTE tables consume tokens as configuration inputs.