Search Results sum_mark




Overview
Explore in AI Chat

Overview

XTR_PRT_BODY_V is a reporting view in the Oracle E-Business Suite Treasury (XTR) module. It exposes the body-level metadata that drives the layout and behavior of printed Treasury reports and documents. In EBS 12.1.1 and 12.2.2 the Treasury module uses a print engine built around a body/column definition model, in which each printed field is described by a row that carries formatting instructions, ordering, title text, and aggregation flags. The view presents that definition set as a readable, query-friendly projection of the underlying definition table.

Because the view is a simple projection with no joins, filters, or functions, it is not a transformation layer in the usual integration sense. Its role is to provide a stable, named access point for report developers, integrators, and support analysts who need to inspect or drive the Treasury print body definition without referencing the base table directly. The presence of the SUM_MARK column, which appears in the user search term, indicates that the view is central to how the Treasury print engine decides which numeric values are totaled and at what level that totaling occurs.

Underlying Base Objects

The view is defined over a single base object, XTR_PRT_BODY. The ETRM documentation records no other referenced base objects, and the view text confirms a one-to-one column mapping with no joins:

  • XTR_PRT_BODY — the Treasury print body definition table, holding one row per printable field per report body.

All fifteen columns of the view are columns of XTR_PRT_BODY, exposed in the same order. No aggregation, distinct, or filtering clauses are present, so row counts and row identity are preserved between the base table and the view. Writers to the definition — typically setup or report definition maintenance — operate on the base table; the view is read-only in practice.

The ETRM metadata notes the object as "Not implemented in this database" for the documented implementation snapshot, meaning the view may not exist in every environment. Analysts should verify existence in ALL_VIEWS before relying on it.

Key Columns

  • SEQ — sequence identifier for the body row, establishing the record order.
  • FIELD_NAME — the logical name of the printable field.
  • FIELD_FORMAT — formatting mask applied when the field is rendered.
  • FIELD_TYPE and FIELD_SIZE — data type and display length of the field.
  • FIELD_TITLE — the column heading text printed for the field.
  • FIELD_VAL — the value expression or literal bound to the field.
  • ORDER_NO — sort/placement order of the field within the body.
  • GRP_MARK — indicates a grouping break at this field.
  • PRT_MARK — indicates whether the field is printed.
  • SUM_MARK — flags the field for summation by the print engine.
  • GROUP_SUM, PAGE_SUM, and TOTAL_SUM — control whether subtotals are produced at group, page, and report-total levels respectively.
  • LAST — marks the final row or final field in the body definition.

Taken together, GRP_MARK through TOTAL_SUM form the aggregation control set; SUM_MARK is the master switch that the engine consults before applying any of the level-specific totals.

Common Use Cases and Queries

Typical scenarios include auditing which fields are summed on a Treasury report, diagnosing missing or duplicated subtotals, and reverse-engineering a report layout.

  • List all summed fields: SELECT FIELD_NAME, GROUP_SUM, PAGE_SUM, TOTAL_SUM FROM XTR_PRT_BODY_V WHERE SUM_MARK = 'Y' ORDER BY ORDER_NO;
  • Inspect full body layout: SELECT SEQ, ORDER_NO, FIELD_NAME, FIELD_TITLE, FIELD_FORMAT FROM XTR_PRT_BODY_V ORDER BY ORDER_NO;
  • Find printed fields only: SELECT FIELD_NAME, FIELD_TITLE FROM XTR_PRT_BODY_V WHERE PRT_MARK = 'Y';
  • Locate the terminating row: SELECT * FROM XTR_PRT_BODY_V WHERE LAST = 'Y';

Because the view is unaggregated, these queries can be joined to other Treasury setup views on FIELD_NAME without risk of row multiplication from the view itself. Mark semantics should be confirmed against the values actually stored in the environment, as flag domains may be defined per implementation.