Results for “partner_address”

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

Overview

MSC_ST_TRADING_PARTNER_SITES is a staging table owned by the MSC schema within Oracle Advanced Supply Chain Planning (ASCP). It serves as the temporary landing area used by the collection program to validate, cleanse, and transform inbound trading partner site data before it is merged into the permanent interface table MSC_TRADING_PARTNER_SITES. During a planning data collection run, source systems populate this table; the collection process then applies validations, resolves keys and references, flags errors, and moves conformed records downstream. Records that fail validation are retained with diagnostic information so they can be corrected and resubmitted.

The documented physical schema for release 12.2.2 shows 51 columns. From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone, meaning it does not act as a strict hub, link, or satellite in the mined foreign-key structure. This classification is a modeling suggestion only; functionally, the table behaves as a transient staging artifact rather than a durable analytical entity, and its content is typically purged or refreshed on each collection cycle.

Key Information Stored

The table's identity and business context are carried by a focused set of columns, while the remainder support auditing, geography, and error handling.

• PARTNER_ID and PARTNER_SITE_ID — the principal identifiers for the trading partner and its site. PARTNER_SITE_ID participates in a documented foreign key to MSC_TRADING_PARTNER_SITES, making it the most significant business-key candidate for reconciliation against the target table.
• COMPANY_ID and COMPANY_NAME — link the partner site to a legal entity; COMPANY_ID has a foreign key to PN_COMPANIES_ALL.
• PARTNER_NAME, PARTNER_TYPE, and PARTNER_SITE_NUMBER — descriptive attributes identifying the partner and categorizing its role.
• SR_TP_ID, SR_TP_SITE_ID, SOURCE_SR_TP_ID, and SOURCE_SR_TP_SITE_ID — source-system identifiers used for traceability back to the originating application instance.
• SR_INSTANCE_ID and SR_INSTANCE_CODE — identify the source instance from which the record was collected.
• PROCESS_FLAG, ERROR_TEXT, and ST_TRANSACTION_ID — drive and report on the validation lifecycle, indicating whether a row is ready, errored, or already processed.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, REFRESH_ID, and BATCH_ID — collection-run auditing columns that tie each row to the concurrent request and refresh cycle that produced it.
• LOCATION_ID, ADDRESS1–ADDRESS4, CITY, STATE, PROVINCE, COUNTRY, POSTAL_CODE, LATITUDE, and LONGITUDE — geographic attributes for the site.
• DELETED_FLAG and CUST_ACCOUNT_NUMBER — support soft-delete propagation and customer account cross-referencing.

Common Use Cases and Queries

The primary use case is diagnostic: planners and technical teams query this table when a collection run reports rejected trading partner site records. Typical investigations include identifying rows that failed validation and locating the associated request.

• Inspect error rows: SELECT PARTNER_SITE_ID, PARTNER_NAME, ERROR_TEXT FROM MSC_ST_TRADING_PARTNER_SITES WHERE PROCESS_FLAG = 'E';
• Audit a specific collection run: SELECT * FROM MSC_ST_TRADING_PARTNER_SITES WHERE REQUEST_ID = :req_id;
• Reconcile staging against the interface: compare PARTNER_SITE_ID counts between this table and MSC_TRADING_PARTNER_SITES.
• Trace source lineage using SR_INSTANCE_CODE, BATCH_ID, and REFRESH_ID.

Standard practice is to run these queries after a collection cycle and before the staging data is purged.

Related Objects

• MSC_TRADING_PARTNER_SITES — the target interface table; joined on PARTNER_SITE_ID.
• PN_COMPANIES_ALL — the legal entity source; joined on COMPANY_ID.
• MSC_ST_TRADING_PARTNERS — companion staging table for partner (header) data.
• MSC_SYSTEM_ITEMS / MSC staging infrastructure — provides the generic validation and purge framework.
• Concurrent programs in the Collections module consume these rows via the standard staging-to-interface load logic.