Results for “op_prsl_typ_b”

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

Overview

OP_PRSL_TYP_B is a base table owned by the GML schema (Process Manufacturing Logistics) in Oracle E-Business Suite 12.1.1 and 12.2.2. It defines the valid presales order types used within the Process Manufacturing presales cycle. The ETRM documentation notes explicitly that the table "is not used in 11i," meaning it is effectively a 12.x-era object introduced or activated to support presales order classification in R12 environments. The _B suffix follows Oracle's base-table naming convention and typically indicates the presence of a corresponding _TL translation table for the language-dependent column LANG_CODE.

Functionally, the table acts as a control/lookup entity: downstream transactional records in presales order headers point to a row in this table to establish what type of presales order is being processed. Because the table carries no transactional measures of its own and is referenced by other tables through a foreign key, a Data Vault modeling heuristic classifies it as hub-leaning. In practical terms, it is the type/reference master for presales orders.

Key Information Stored

Two identifiers are documented as unique, and they are the columns that matter most:

• PRESALES_ORD_CODE — the value enforced by unique index OP_PRSL_TYPI1; this is the primary-key business identifier of the record.
• PRESALES_ORD_TYPE — enforced by unique index OP_PRSL_TYP_PK; this is the code consumed by child tables as the foreign key value (see OP_PRSL_HDR.PRESALES_ORD_TYPE).
• LANG_CODE — the language indicator for the descriptive attributes, consistent with the base/translation pattern implied by the _B suffix.
• RELEASE_SCHED_REQD — a flag controlling whether a release schedule is required for the given presales order type; this drives downstream scheduling behavior.
• PRICELIST_IND — an indicator controlling pricelist handling for the order type.
• TEXT_CODE — a reference to an attached text/notes block describing the order type.
• TRANS_CNT — a transaction/counter column commonly used for concurrency or activity tracking.
• DELETE_MARK — Oracle's standard soft-delete indicator; rows are logically retired rather than physically removed.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN, populated automatically by Oracle Forms/Who columns.

The table is documented with 13 columns in total. The two unique indexes represent competing business-key candidates, so care should be taken to confirm which one is treated as the surrogate key when integrating with external systems.

Common Use Cases and Queries

The most common use is resolving the descriptive attributes behind a presales order header. For instance, to list presales order types and their scheduling requirements:

• SELECT PRESALES_ORD_TYPE, PRESALES_ORD_CODE, RELEASE_SCHED_REQD, PRICELIST_IND FROM GML.OP_PRSL_TYP_B WHERE DELETE_MARK = 0;

To join headers to their type definition, the natural join path is OP_PRSL_HDR.PRESALES_ORD_TYPE = OP_PRSL_TYP_B.PRESALES_ORD_TYPE. Reporting extensions often group headers by PRESALES_ORD_TYPE and expose RELEASE_SCHED_REQD and PRICELIST_IND as filter attributes. Validation scripts verifying FK integrity should confirm every PRESALES_ORD_TYPE in OP_PRSL_HDR exists and is not soft-deleted in this table.

Related Objects

• OP_PRSL_HDR — the primary dependent table; references this table via OP_PRSL_HDR.PRESALES_ORD_TYPE → OP_PRSL_TYP_B.PRESALES_ORD_TYPE. This is the single documented foreign-key relationship.
• OP_PRSL_TYP_TL — the implied translation table for language-dependent description text (associated with the _B/LANG_CODE pattern; confirm against the actual dictionary).
• OP_PRSL_LIN and related OP_PRSL line-level tables — descendants of OP_PRSL_HDR that inherit the presales order type indirectly.
• OP_PRSL_TYP_B unique indexes — OP_PRSL_TYPI1 and OP_PRSL_TYP_PK, which enforce uniqueness on the code and type columns respectively.

Because the metadata documents only one direct FK, integrations should treat OP_PRSL_HDR as the authoritative referencing object and avoid assuming additional undocumented relationships.