Results for “complete_flag”

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

Overview

The PRP_PROP_STYLE_CTNTVERS table, owned by the PRP (Proposals) schema, defines the structural composition of a proposal in Oracle EBS 12.1.1 and 12.2.2. It stores the template components and files that make up a proposal, together with the sequence in which those elements appear in the generated document. Sales representatives use this structure when building a proposal — selecting the individual components and files and then determining their display order before the document is generated.

From a dimensional modeling perspective, the heuristic Data Vault classification for this object is a link, derived from its foreign key topology. It sits between the proposal header (PRP_PROPOSALS) and the component style/version definitions (PRP_COMP_STYLE_CTNTVERS, PRP_COMPONENT_STYLES_B), resolving many-to-many style associations rather than functioning as a standalone hub or satellite.

Key Information Stored

The table carries 21 documented columns. The most significant are:

• PROP_STYLE_CTNTVER_ID — the surrogate primary key (PRP_PROP_STYLE_CTNTVERS_PK), uniquely identifying each style-content-version row.
• PROPOSAL_ID — the foreign key to PRP_PROPOSALS, anchoring the row to a specific proposal.
• COMP_STYLE_CTNTVER_ID — the foreign key to the component style-content version definition.
• COMPONENT_STYLE_ID — the foreign key linking to PRP_COMPONENT_STYLES_B, the component style header.
• COMPONENT_ID — identifies the underlying component instance included in the proposal.
• DISPLAY_ORDER — controls the position of the component or file within the generated proposal.
• MANDATORY_FLAG — indicates whether the component must be included.
• INCLUDE_FLAG — records whether the sales representative has chosen to include the element.
• COMPLETE_FLAG — tracks whether the component or file has been fully processed or completed.
• OBJECT_TYPE and OBJECT_ID — a polymorphic discriminator pair that references the associated object (via PRP_COMP_STYLE_CTNTVERS and broader object references).
• OBJECT_VERSION_NUMBER — supports optimistic locking for concurrent updates.

Two unique indexes serve as business-key candidates: PRP_PROP_STYLE_CTNTVERS_U1 on PROP_STYLE_CTNTVER_ID and PRP_PROP_STYLE_CTNTVERS_U999 on the composite (PROPOSAL_ID, OBJECT_TYPE, OBJECT_ID), which guarantees a given object appears only once per proposal. Standard audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, PROGRAM_ID, PROGRAM_LOGIN_ID, PROGRAM_APPLICATION_ID, REQUEST_ID) are also present.

Common Use Cases and Queries

Typical reporting includes retrieving the ordered structure of a proposal for document generation, auditing which components a representative included or suppressed, and reconciling mandatory components that were incorrectly excluded.

• List the ordered structure of a proposal:

  SELECT display_order, component_id, include_flag, mandatory_flag
  FROM   prp.prp_prop_style_ctntvers
  WHERE  proposal_id = :proposal_id
  ORDER BY display_order;

• Identify mandatory components that were omitted:

  SELECT component_id
  FROM   prp.prp_prop_style_ctntvers
  WHERE  proposal_id = :proposal_id
  AND    mandatory_flag = 'Y'
  AND    include_flag = 'N';

• Join to the proposal header for descriptive reporting:

  SELECT p.proposal_id, v.component_id, v.display_order
  FROM   prp.prp_proposals p, prp.prp_prop_style_ctntvers v
  WHERE  p.proposal_id = v.proposal_id;

Related Objects

• PRP_PROPOSALS — joined on PROPOSAL_ID; the parent proposal header.
• PRP_COMP_STYLE_CTNTVERS — joined on COMP_STYLE_CTNTVER_ID and OBJECT_ID; holds component style-content versions.
• PRP_COMPONENT_STYLES_B — joined on COMPONENT_STYLE_ID; the base component style definition.
• PRP_PROP_STYLE_CTNTVERS_PK / _U1 / _U999 — the primary and unique indexes enforcing row identity and uniqueness.
• OBJECT_ID polymorphic references — resolved through OBJECT_TYPE against the associated component/object repository.