Search Results ar_ta_remit_prof_pk

Overview

AR_TA_REMIT_PROF_ALL is a Receivables (AR) setup table within Oracle E-Business Suite that stores configuration information governing customer remittance processing. In the Oracle EBS Receivables architecture, remittance processing refers to the automated handling of customer payments and their accompanying remittance advice — the detail that identifies which invoices a payment is intended to satisfy. This table therefore acts as the configuration repository that defines how the Receivables application interprets, validates, and applies incoming remittance data against open transactions.

The table is an _ALL object, meaning it is partitioned by operating unit or org context through the standard multi-org mechanism in Oracle EBS. From a data-modeling standpoint, the ETRM metadata classifies this object heuristically as standalone in Data Vault terms — that is, it does not participate in documented foreign-key relationships with other tables and is typically treated as a standalone reference/setup object rather than a hub, link, or satellite in a Data Vault model. A Data Vault practitioner would most naturally model the PROFILE_ID surrogate key as a hub-style key with an attached satellite holding the descriptive remittance profile attributes, though the official classification remains "standalone."

Key Information Stored

The table's documented metadata identifies the following structural elements:

• PROFILE_ID — the surrogate primary key and sole documented column. It uniquely identifies a remittance processing profile record and is the target of the AR_TA_REMIT_PROF_PK primary key constraint.

Because the ETRM excerpt documents PROFILE_ID via the AR_TA_REMIT_PROF_PK primary key, this column is confirmed as the surrogate identifier. The metadata does not enumerate additional business-key columns or unique indexes beyond the primary key. In practice, remittance profile records in this family of tables typically carry associated descriptive and control attributes — such as profile name, organization identifier, and processing flags — but the documented metadata confirms only the surrogate key. Analysts should treat PROFILE_ID as the definitive join and identification column and validate any additional attributes directly against the deployed schema.

Common Use Cases and Queries

Because the table drives remittance setup, its primary consumption patterns are configuration reporting and troubleshooting of payment application behavior.

• Profile inventory: listing all configured remittance profiles.
  SELECT profile_id FROM ar_ta_remit_prof_all;
• Targeted profile lookup: retrieving a specific profile by its surrogate key.
  SELECT * FROM ar_ta_remit_prof_all WHERE profile_id = :profile_id;
• Setup auditing: verifying which profiles exist before or after a patch or upgrade, particularly relevant when migrating from 12.1.1 to 12.2.2, where online patching and multitenancy considerations can affect setup data.
• Cross-referencing into child setup tables: using PROFILE_ID as the driver column when joining to dependent remittance configuration tables.

Note that the ETRM metadata records this object as "Not implemented in this database" for the sampled environment, so availability and row counts depend on whether Oracle Receivables remittance features are licensed and configured in a given instance.

Related Objects

The ETRM relationship data classifies AR_TA_REMIT_PROF_ALL as standalone, and no foreign-key relationships were mined. Consequently, the most significant related objects are those in the same remittance-processing lineage and the broader AR setup family that share the PROFILE_ID conceptual key or the AR_TA_* namespace:

• AR_TA_REMIT_PROF_PK — the enabling primary key constraint on PROFILE_ID.
• Other AR_TA_* setup tables — companion tables in the Transaction Attribute (TA) setup family that define related processing rules and may reference the same profile identifier conceptually.
• AR setup / configuration tables — general Receivables configuration objects that supply system-level parameters affecting remittance processing.
• Receivables AutoInvoice and payment application setup objects — functionally related to how remitted payments resolve to invoices.

Because no FK metadata was provided, joins beyond the primary key should be confirmed against the deployed schema before being relied upon in production reporting.