Results for “tp_group_code”

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

Overview

ECE_TP_GROUP is a table owned by the EC schema (e-Commerce Gateway) in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the definition of trading partner groups, where each group represents a named collection of trading partner definitions. Rather than maintaining partner-specific processing rules one row at a time, Oracle EBS allows related trading partners to be bundled into a logical group, and this table holds the header-level attributes of that grouping. The object is documented in the ETRM 12.2.2 data dictionary with STATUS = VALID and a physical schema of twelve columns under the EC owner.

Within the e-Commerce Gateway data model, ECE_TP_GROUP functions as the parent of the trading partner header records held in ECE_TP_HEADERS. This one-to-many relationship makes the table the entry point for any query that needs to resolve which partner definitions belong to a given group.

The heuristic Data Vault classification mined from the foreign-key structure is hub-leaning. Treated as a modeling suggestion, this implies ECE_TP_GROUP carries a stable, uniquely identified business concept (the trading partner group) whose descriptive attributes could reasonably be split out into a satellite, with ECE_TP_HEADERS acting as the dependent entity joined on the group key.

Key Information Stored

The table stores twelve documented columns. The most significant are:

• TP_GROUP_ID — the surrogate primary key, enforced by the ECE_TP_GROUP_PK constraint and also carried by the unique index ECE_TP_GROUP_ID_U1. This is the column propagated to child tables.
• TP_GROUP_CODE — the user-facing business identifier for the group, enforced by unique index ECE_TP_GROUP_U2, making it the natural business-key candidate alongside TP_GROUP_ID.
• TP_GROUP_DESCRIPTION — a free-text description of the group's purpose or membership.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Oracle EBS audit columns recording the last modifier and timestamp.
• CREATED_BY, CREATION_DATE — creation audit columns identifying the original creator and date.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — the standard concurrent program context columns, capturing the request and program that last touched the row.

The distinction between the surrogate key (TP_GROUP_ID) and the business-key candidate (TP_GROUP_CODE) is important when integrating with external systems: TP_GROUP_CODE is the value users recognize and normally exchange, while TP_GROUP_ID is the internal referential anchor.

Common Use Cases and Queries

The primary reporting use case is listing all trading partner groups and their membership counts, or resolving a partner's group from a header record. A typical query joins the group to its children:

• SELECT g.tp_group_code, g.tp_group_description, h.tp_header_id FROM ece_tp_group g, ece_tp_headers h WHERE g.tp_group_id = h.tp_group_id ORDER BY g.tp_group_code;
• SELECT tp_group_id, tp_group_code, tp_group_description FROM ece_tp_group WHERE tp_group_code = :code; — a lookup by business key that exploits the ECE_TP_GROUP_U2 unique index.
• SELECT g.tp_group_code, COUNT(*) FROM ece_tp_group g, ece_tp_headers h WHERE g.tp_group_id = h.tp_group_id GROUP BY g.tp_group_code HAVING COUNT(*) = 0; — detecting groups defined but not yet populated with partners, a common data-cleanup check before enabling gateway processing.
• Audit-oriented queries using LAST_UPDATE_DATE, PROGRAM_ID, and REQUEST_ID to determine which concurrent program created or amended a group definition.

These patterns are frequently used during e-Commerce Gateway implementation, when defining which trading partners share outbound document mapping and translation rules.

Related Objects

The most significant dependent object is ECE_TP_HEADERS, which references ECE_TP_GROUP through the foreign key ECE_TP_HEADERS.TP_GROUP_ID → ECE_TP_GROUP. Through that header table, downstream gateway objects such as partner-level location and document-mapping definitions are reached. Because the documented metadata exposes only this single FK relationship, the surrounding model should be treated cautiously: ECE_TP_GROUP sits at the top of the group hierarchy, and any extraction or purge of a group must first reconcile or delete its dependent header rows to avoid violating referential integrity. In Data Vault terms, this confirms the hub role of ECE_TP_GROUP, with ECE_TP_HEADERS acting as the dependent child entity in the gateway partner model.