Search Results curreny_code

Overview

ITG_REQ_HEADERS_V is a view owned by the APPS schema in Oracle E-Business Suite, classified under the ITG – Internet Procurement Enterprise Connector product. It is VALID in release 12.1.1 and 12.2.2. The view is not an operational data-entry object; it is an XML-generation feeder. Its documented purpose is to "generate XML at requisition headers level," meaning it projects one row per purchasing requisition header and formats that row so the ITG connector layer can serialize it into an outbound XML payload. This distinguishes it from the underlying transactional table: where PO_REQUISITION_HEADERS_ALL stores the full declarative setup of a requisition, ITG_REQ_HEADERS_V pre-computes derived values (line counts, approval flags, status codes, attachment pointers) that the integration middleware expects. A user searching for "po_requisition_headers" will typically arrive here because this view is the ITG-specific projection of that table, not the table itself.

Underlying Base Objects

ETRM documentation lists the referenced base objects as GL_SETS_OF_BOOKS (view), HR_GENERAL, HR_PERSON_NAME, HR_SECURITY, and ITG_X_UTILS (packages), ORG_ORGANIZATION_DEFINITIONS and PER_PEOPLE_F (views), and PO_REQUISITION_HEADERS_ALL (synonym). PO_REQUISITION_HEADERS_ALL is the driving table; the view text shows it alias-joined as HA and uses its primary key REQUISITION_HEADER_ID as the exposed REQ_HEADER_ID. GL_SETS_OF_BOOKS (SOB) supplies the set-of-books currency, while PER_PEOPLE_F, HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY provide the requester's employee number and the person/name/security logic behind it. ORG_ORGANIZATION_DEFINITIONS resolves the operating unit context. ITG_X_UTILS is the functional engine of the view: it supplies SUMREQLINES for line aggregation and GETATTACHMENTS for each attachment role. Because the view touches HR_SECURITY, its output is subject to the same person-level security semantics as HR queries.

Key Columns

• REQ_HEADER_ID – requisition header identifier from PO_REQUISITION_HEADERS_ALL.
• REQUISITNID – the human-readable requisition number (SEGMENT1).
• CREATION_DATE – header creation timestamp.
• SUM_REQLINES – line count returned by ITG_X_UTILS.SUMREQLINES.
• CURRENY_CODE – set-of-books currency from GL_SETS_OF_BOOKS (note the documented spelling).
• APPROVED – DECODE of AUTHORIZATION_STATUS, yielding 1 when 'APPROVED', otherwise 0.
• HDRSTATUS – normalized numeric status derived from CLOSED_CODE (APPROVED=1, CLOSED/FINALLY CLOSED=2, CLOSED FOR RECEIVING=3, CANCELLED=4, AWAITING PRINTING=5, CLOSED FOR INVOICE=5).
• POENTITY – operating unit from ORG_ID.
• REQUESTER – employee number resolved via HR packages.
• DESCRIPTION – requisition header description.
• HEADER_UA_ATTRIBUTE1 … 15 – the header's descriptive flexfield segments, carried through unchanged for downstream mapping.
• TO_PO_INTERNAL, TO_MISC, TO_APPROVER, TO_BUYER, TO_PAYABLES, TO_RECEIVER, TO_SUPPL… (TO_SUPPLIER) – attachment payloads produced by ITG_X_UTILS.GETATTACHMENTS for each attachment category, keyed on PO_REQUISITION_HEADERS.

Common Use Cases and Queries

The primary use case is outbound requisition integration: the ITG connector queries the view to build the header portion of an XML document, most commonly for export to an external procurement, sourcing, or P2P system. Secondary uses include troubleshooting why a requisition was omitted from a payload and validating status or DFF mapping.

List approved requisitions ready for export:

• SELECT req_header_id, requisitnid, request er, currency_code FROM itg_req_headers_v WHERE approved = 1;

Inspect normalized status and line counts:

• SELECT requisitnid, hdrstatus, sum_reqlines, poentity FROM itg_req_headers_v WHERE requisitnid = :req_number;

Join back to the base table for details not projected by the view:

• SELECT v.requisitnid, h.authorization_status, h.closed_code FROM itg_req_headers_v v, po_requisition_headers_all h WHERE h.requisition_header_id = v.req_header_id;

Check attachment availability for a header using the TO_ columns. Because the view calls ITG_X_UTILS functions per row, querying large ranges is expensive; always filter by POENTITY, requisition number, or creation date rather than scanning the full view.