Search Results ece_mappings_u1

Overview

EC.ECE_MAPPINGS is a seed data table in the Oracle E-Business Suite E-Commerce Gateway (EC) schema. It stores the definition of input and output maps used during the processing of EDI transactions. Each row describes a named map, its type, the transaction type it applies to, and the root element that anchors the map's structure. The table therefore acts as the configuration registry that the E-Commerce Gateway uses to determine which mapping logic is applied when inbound or outbound transaction data is translated.

The object is owned by the EC schema, holds status VALID in ETRM 12.2.2, and is stored in the APPS_TS_SEED tablespace, consistent with its role as seeded setup data rather than transactional data. The heuristic Data Vault classification for this object is a hub or reference table: ECE_MAPPINGS is standalone, referenced by no other database object, which is consistent with a reference/dimension pattern rather than a link or satellite. This classification is offered as a modeling suggestion; the physical design remains a conventional relational table with a surrogate primary key.

Key Information Stored

The table contains seven documented columns. The most significant are:

• MAP_ID — NUMBER(15), the surrogate primary key, enforced by ECE_MAPPINGS_PK. It uniquely identifies each map definition.
• MAP_CODE — VARCHAR2(20), a user-recognizable map code. This is the documented business-key candidate, enforced by the unique index ECE_MAPPINGS_U1. The identifier a user searched for, "ece_mappings_u1", refers directly to this unique constraint on MAP_CODE.
• DESCRIPTION — VARCHAR2(250), a human-readable description of the map.
• MAP_TYPE — VARCHAR2(40), identifies the category or orientation of the map (for example input versus output processing).
• TRANSACTION_TYPE — VARCHAR2(30), the transaction category the map is associated with.
• ROOT_ELEMENT — VARCHAR2(80), the root element of the mapping structure, anchoring the map hierarchy.
• ENABLED — VARCHAR2, a flag indicating whether the map is active and eligible for use.

The distinction between MAP_ID and MAP_CODE matters in practice: internal joins and foreign references should use the surrogate key, while user-facing lookups, imports, and data comparison rely on the unique MAP_CODE.

Common Use Cases and Queries

Typical scenarios include determining which maps are enabled for a given transaction type, auditing the map registry before an EDI go-live, and diagnosing why an inbound or outbound transaction did not resolve to the expected map. The canonical access pattern is a direct query against the table:

• List enabled maps by transaction type: SELECT MAP_CODE, DESCRIPTION, MAP_TYPE FROM EC.ECE_MAPPINGS WHERE TRANSACTION_TYPE = :txn AND ENABLED = 'Y';
• Resolve a map code to its surrogate key: SELECT MAP_ID FROM EC.ECE_MAPPINGS WHERE MAP_CODE = :code; — this query is served efficiently by the unique index ECE_MAPPINGS_U1.
• Inventory all map definitions: SELECT MAP_CODE, MAP_ID, DESCRIPTION, MAP_TYPE, TRANSACTION_TYPE, ROOT_ELEMENT, ENABLED FROM EC.ECE_MAPPINGS ORDER BY MAP_CODE; — the standard cut-and-paste query documented in ETRM.

Reporting use cases include configuration validation extract sheets, seeded-versus-customized comparison reports, and downstream joins where ECE_MAPPINGS supplies a lookup of map attributes for transaction processing logs.

Related Objects

Per the documented dependency information, EC.ECE_MAPPINGS does not reference any other database object and is referenced by the APPS synonym ECE_MAPPINGS. The FK/PK relationship data confirms a standalone classification, meaning there are no enforced foreign key parents or children documented for this table.

• APPS.ECE_MAPPINGS — the APPS-layer synonym through which application code and users normally access the EC.ECE_MAPPINGS base table.
• EC.ECE_MAPPINGS_PK — the primary key constraint on MAP_ID, the surrogate key used for programmatic joins.
• EC.ECE_MAPPINGS_U1 — the unique index on MAP_CODE, the business-key candidate and the object most often referenced in validation and lookup scripts.

Because the object is a standalone seed table, related objects are limited to its constraints, indexes, and APPS synonym rather than dependent transactional tables. Any integration or reporting layer that consumes ECE_MAPPINGS should join on MAP_ID for internal consistency and on MAP_CODE for user-facing criteria.