Results for “doc_level_id”

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

Overview

PO_ENCUMBRANCE_GT is a Purchasing (PO) module table that Oracle documents as "For Internal Use Only." It is a global temporary table (GT) used by the purchasing and encumbrance accounting engine to stage encumbrance, budgetary, and journal entry data before it is validated, summarized, and transferred to Oracle General Ledger. The table belongs to the PO schema and, in the 12.1.1 documented physical schema, contains 117 columns. No formal implementation is recorded for this object in the referenced database, which is consistent with a transient, session-scoped working table whose rows are populated and consumed within a single processing cycle.

Under the heuristic Data Vault classification supplied in the metadata, the object is treated as a standalone structure with no connecting link role. This suggests that, from a modeling perspective, PO_ENCUMBRANCE_GT behaves as a staging or satellite-like table rather than a true transactional hub: it aggregates context and measures for a process rather than serving as the durable identity anchor. Designers building a warehouse model over EBS should treat it as process-scoped staging, not as a persistent source of record.

Key Information Stored

The columns fall into three functional groups: document identity, encumbrance amounts and quantities, and accounting results. The most significant columns are:

• DOC_LEVEL and DOC_LEVEL_ID — the granularity and identifier of the document being processed, linking the staging row back to a header, release, line, shipment, or distribution.
• HEADER_ID, PO_RELEASE_ID, LINE_ID, LINE_LOCATION_ID, DISTRIBUTION_ID, SOURCE_DISTRIBUTION_ID, REQ_DISTRIBUTION_ID — surrogate keys tracing the purchasing document hierarchy and its requisition or source origins.
• AMOUNT_TO_ENCUMBER, ENCUMBERED_AMOUNT, UNENCUMBERED_AMOUNT, AMOUNT_ORDERED, AMOUNT_DELIVERED, AMOUNT_BILLED, AMOUNT_CANCELLED — the core budgetary monetary measures.
• ENTERED_AMOUNT, ACCOUNTED_AMOUNT, ENTERED_CR, ACCOUNTED_CR, ENTERED_DR, ACCOUNTED_DR — dual-currency journal amounts produced in the entry and accounted currencies.
• CURRENCY_CODE and RATE — the transaction currency and conversion factor applied to the amounts above.
• ENCUMBRANCE_TYPE_ID, CODE_COMBINATION_ID, PERIOD_NAME, JE_CATEGORY_NAME, GL_ENCUMBERED_DATE — the accounting classification, GL account, and period context for the transfer to General Ledger.
• PROJECT_ID, TASK_ID, AWARD_NUM, EXPENDITURE_TYPE, EXPENDITURE_ORGANIZATION_ID, EXPENDITURE_ITEM_DATE — Project Accounting attribution for project-related encumbrances.
• GL_STATUS_CODE and GL_RESULT_CODE — the outcome of the transfer attempt to GL.

The metadata does not document a primary key constraint on the table. No unique index or business-key candidate is recorded in the ETRM schema, reinforcing that row identity is process-controlled rather than enforced by a database constraint; ROW_INDEX and SEQUENCE_NUM appear to serve as internal ordering counters rather than key candidates.

Common Use Cases and Queries

Because the object is internal and session-scoped, direct reporting against it is uncommon. Its practical uses are diagnostic and reconciliatory: confirming that encumbrances were staged correctly before GL transfer, tracing why a document failed posting, and comparing staged amounts with the committed records in PO_DISTRIBUTIONS_ALL.

A typical diagnostic query inspects transfer status outcomes for a document:

• SELECT header_id, doc_level, doc_level_id, gl_status_code, gl_result_code, result_text FROM po_encumbrance_gt WHERE header_id = :p_header_id;
• Comparing staged versus posted amounts: SELECT e.distribution_id, e.encumbered_amount, e.amount_to_encumber, d.encumbered_amount FROM po_encumbrance_gt e, po_distributions_all d WHERE e.distribution_id = d.distribution_id;

Reporting use cases centre on encumbrance reconciliation for government and public-sector customers who rely on budgetary control. Since the table is transient, any monitoring must be captured during the run or via error rows retained by the concurrent program that populated it.

Related Objects

• PO_RELEASES_ALL — joined on PO_RELEASE_ID, the release header owning staged release-level encumbrances.
• PO_LINE_TYPES_B — joined on LINE_TYPE_ID, resolving the line type controlling encumbrance behaviour.
• GL_ENCUMBRANCE_TYPES — joined on ENCUMBRANCE_TYPE_ID, supplying the encumbrance category applied to the journal entry.
• PO_DISTRIBUTIONS_ALL — the persistent distribution record against which staged amounts are reconciled, joined on DISTRIBUTION_ID.
• GL_CODE_COMBINATIONS — joined on CODE_COMBINATION_ID, resolving the accounting flexfield string for posting.
• PO_HEADERS_ALL — joined on HEADER_ID, the purchasing document at the top of the staging hierarchy.

The foreign keys recorded in the metadata expose only a subset of these relationships, so integrators should confirm joins against PO_DISTRIBUTIONS_ALL and the GL interface tables before relying on the object in a custom program.