Search Results po_document_types_all_b_u1

Overview

PO.PO_DOCUMENT_TYPES_ALL_B is a core Oracle Purchasing (PO) seed and setup table that stores the control, default, and option information used to customize document management behavior for each operating unit. It is the underlying entity for the Document Types setup window in Oracle Purchasing, and it drives how requisitions, purchase orders, quotations, and related documents behave during creation and approval.

The table resides in the APPS_TS_SEED tablespace with a PCT Free of 10, reflecting its role as configuration/seed data rather than high-volume transactional data. The physical schema documented in ETRM 12.2.2 contains 53 columns. Based on the mined foreign-key structure, the object is classified heuristically as standalone — it is not a strict dependent child of a master business entity in the Data Vault sense, though conceptually it functions as a configuration hub: it anchors the approved document type definitions that other Purchasing entities reference.

Key Information Stored

The table's identity is defined by a surrogate-style composite primary key, PO_DOCUMENT_TYPES_ALL_B_PK, composed of DOCUMENT_TYPE_CODE, DOCUMENT_SUBTYPE, and ORG_ID. A separate unique index, PO_DOCUMENT_TYPES_ALL_B_U1 — the object the user searched for — enforces uniqueness across DOCUMENT_TYPE_CODE, DOCUMENT_SUBTYPE, ORG_ID, and ZD_EDITION_NAME. This index is the business-key candidate and is also the object most commonly referenced in tuning and validation queries.

• DOCUMENT_TYPE_CODE and DOCUMENT_SUBTYPE — the type and subtype of the document (for example, a purchase order or requisition variant) being configured.
• ORG_ID — the operating unit to which the document type definition applies, enabling multi-org configuration.
• CAN_PREPARER_APPROVE_FLAG — whether a preparer may approve their own document.
• CAN_APPROVER_MODIFY_DOC_FLAG — whether an approver can alter the document during approval.
• CAN_CHANGE_APPROVAL_PATH_FLAG and CAN_CHANGE_FORWARD_TO_FLAG / CAN_CHANGE_FORWARD_FROM_FLAG — routing and forwarding permissions during the approval cycle.
• FORWARDING_MODE_CODE — the forwarding mode used for approval routing.
• DEFAULT_APPROVAL_PATH_ID — the default approval path assigned to the document type.
• SECURITY_LEVEL_CODE and ACCESS_LEVEL_CODE — security and access classification controlling visibility.
• DISABLED_FLAG — whether the document type definition is active or disabled.
• USE_CONTRACT_FOR_SOURCING_FLAG, INCLUDE_NONCATALOG_FLAG, and the template code columns (DOCUMENT_TEMPLATE_CODE, CONTRACT_TEMPLATE_CODE, SYSGENDESC_TEMPLATE_CODE, CHG_SUMMARY_TEMPLATE_CODE) — sourcing, catalog inclusion, and document generation templates.
• Standard Who columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE) and the ATTRIBUTE1–ATTRIBUTE15 DFF columns for extensibility.

Common Use Cases and Queries

The most frequent use of this table is diagnosing approval and document-control behavior. Because the _U1 index is unique on the business key, queries that filter on the document type and operating unit are efficient. A typical pattern identifies the active configuration for a document type in an operating unit:

• Select configuration for a given document type: SELECT document_type_code, document_subtype, org_id, can_approver_modify_doc_flag, disabled_flag FROM po.po_document_types_all_b WHERE document_type_code = :code AND org_id = :org_id;
• List disabled document types for cleanup or audit: ... WHERE disabled_flag = 'Y';
• Verify uniqueness before inserts or data fixes: query against PO_DOCUMENT_TYPES_ALL_B_U1 key columns (document_type_code, document_subtype, org_id, zd_edition_name).
• Report approval-related settings such as default_approval_path_id and forwarding_mode_code to reconcile workflow behavior.

Setup and extension developers also use this table when interpreting Document Types window values, and DBAs may inspect the _U1 index for fragmentation or rebuild operations, which is a common reason this index name is searched.

Related Objects

Although the mined metadata classifies the object as standalone (no strict FK parents were extracted), it participates in several relationships within the PO and common schemas:

• FND_USER — referenced by CREATED_BY and LAST_UPDATED_BY.
• PO.PO_DOCUMENT_TYPES_ALL_TL — the translation table keyed to the same document type/subtype/org identity for multi-language descriptions.
• PO_DOCUMENT_TYPES_ALL_B_U1 and PO_DOCUMENT_TYPES_ALL_B_PK — the unique and primary key indexes that enforce and support lookups.
• Purchasing setup and approval APIs that read document type configuration (for example, approval-path resolution logic) depend on DEFAULT_APPROVAL_PATH_ID and the flag columns defined here.
• Multi-org enabled reporting views that join on ORG_ID to present operating-unit-specific configuration.

Configuration and validation seeds for document type codes are typically maintained in parallel with this table, and any change to the flags supplied here propagates directly into Purchasing and iProcurement approval behavior.