Search Results je_it_list_hdr_all

Overview

The JE_IT_LIST_HDR_ALL table is a standard Oracle E-Business Suite table owned by the JE (European Localizations) schema. It stores header-level data for the Italian Annual Supplier and Customer Listing extract, a statutory reporting process that Italian fiscal authorities require of businesses operating in Italy. Each row in this table represents a single extract run — that is, one declaration instance defined by a reporting period, an operating unit, a reporting entity, and a processing status.

The object is classified as standalone under the heuristic Data Vault classification mined from its foreign key structure. In Data Vault modeling terms, this suggests the table behaves as an independent hub-like structure rather than a transactional link or a descriptive satellite, since it does not appear to carry relationships to other dependent child tables through foreign keys in the documented schema. The single documented foreign key, VAT_REPORTING_ENTITY_ID, points to JG_ZZ_VAT_REP_ENTITIES, anchoring the extract header to a registered VAT reporting entity.

Key Information Stored

The table contains 10 documented columns. The principal business identifiers are:

• PERIOD_NAME — the accounting period or reporting window the extract covers.
• ORG_ID — the operating unit that owns the extract, enabling multi-org partitioning of the reporting data.
• VAT_REPORTING_ENTITY_ID — foreign key to JG_ZZ_VAT_REP_ENTITIES, identifying the legal VAT entity the declaration is filed under.
• YEAR_OF_DECLARATION — the fiscal year to which the annual listing pertains.
• STATUS_CODE — the processing state of the extract (e.g., generated, submitted, completed).

The remaining columns are standard EBS audit/WHO columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, and CREATED_BY. These support auditing, concurrency control, and traceability of extract creation and modification. The documented schema does not expose an explicit surrogate primary key column in the public metadata, so the business key candidate is the combination of ORG_ID, PERIOD_NAME, VAT_REPORTING_ENTITY_ID, and YEAR_OF_DECLARATION, which uniquely identifies a declaration extract header.

Common Use Cases and Queries

This table is typically queried to determine whether an annual listing extract has been generated for a given entity and period, and to retrieve its status for reconciliation with the Italian tax authority submission. A common pattern verifies extract existence before initiating a filing:

• Listing extracts by period and operating unit: SELECT h.period_name, h.year_of_declaration, h.status_code FROM je_it_list_hdr_all h WHERE h.org_id = :org_id AND h.year_of_declaration = :year;
• Joining to the reporting entity to obtain legal entity attributes: SELECT h.*, r.* FROM je_it_list_hdr_all h, jg_zz_vat_rep_entities r WHERE h.vat_reporting_entity_id = r.vat_reporting_entity_id;
• Status monitoring for in-progress declarations: SELECT status_code, COUNT(*) FROM je_it_list_hdr_all GROUP BY status_code;

Reporting use cases include reconciliation of declared amounts against AP/AR transactions for the Italian supplier and customer listing, audit trails for fiscal submissions, and multi-org dashboards that track declaration completeness across operating units.

Related Objects

The most significant related object documented is the parent VAT reporting entity table referenced by the foreign key:

• JG_ZZ_VAT_REP_ENTITIES — joined via JE_IT_LIST_HDR_ALL.VAT_REPORTING_ENTITY_ID = JG_ZZ_VAT_REP_ENTITIES.VAT_REPORTING_ENTITY_ID; supplies legal entity registration data for the declaration.
• Corresponding Italian listing detail/line tables (JE_IT_LIST_LINES-style objects) that hold supplier- and customer-level transaction rows summarized by each header record.
• JG_ZZ reporting configuration tables that define VAT reporting entity hierarchies and fiscal parameters.
• AP and AR transaction tables (AP_INVOICES_ALL, RA_CUSTOMER_TRX_ALL) that ultimately feed supplier and customer amounts into the annual listing.
• EBS System Administrator concurrent program and request tables, since the extract is typically generated by a concurrent request whose output references these headers.

Because the table is classified as standalone, it should be treated as a self-contained header repository whose dependents are found through application logic rather than declared foreign keys.