Results for “cc_error_code”

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

Overview

The AR_CC_ERROR_HISTORY table resides in the AR (Receivables) schema of Oracle E-Business Suite and stores the execution report information for AutoReceipt and Remittance batch processing. It functions as the persistent error log for credit card and remittance transactions processed through Oracle Payments, capturing the outcome of each attempted transaction as it flows through the payment server infrastructure. Administrators and support personnel query this table to diagnose failed or rejected AutoReceipt and Remittance lines, identify the originating transaction, and understand the specific error condition returned by the payment processor.

The table is owned by AR and is documented as VALID in both EBS 12.1.1 and 12.2.2. Its four-part composite primary key, AR_CC_ERROR_HISTORY_PK, spans REQUEST_ID, CC_TRX_CATEGORY, CC_TRX_ID, and CC_ERROR_CODE. Because these columns together define uniqueness and also serve as the natural business identifiers of a transaction-error pairing, the table exhibits a satellite-leaning Data Vault classification (heuristic, mined from FK structure). In a Data Vault model, the composite key would naturally resolve into a hub or link representing the transaction entity, with the descriptive error attributes carried as satellite context. This classification should be treated as a modeling suggestion rather than a prescribed implementation.

Key Information Stored

The nineteen documented columns fall into identification, error-description, and audit groupings. The most significant columns are:

• REQUEST_ID — Concurrent request identifier that drove the AutoReceipt or Remittance batch execution; part of the composite primary key.
• CC_TRX_CATEGORY — Transaction category discriminator; part of the composite primary key and central to interpreting the row.
• CC_TRX_ID — Transaction identifier that is polymorphic by category, joined outward to either RA_CUSTOMER_TRX_ALL or AR_CASH_RECEIPTS_ALL.
• CC_ERROR_CODE — Processor or application error code; part of the composite primary key.
• CC_ERROR_DATE — Date the error was recorded.
• CC_VENDOR_ERROR_DESC — Vendor-supplied error description returned by the payment processor.
• CC_ERROR_TEXT — Full application error text for the failed transaction.
• CC_ACTION_CODE / CC_ACTION_TYPE_FLAG — Action code and action-type indicator describing the disposition applied.
• PAYMENT_SERVER_ORDER_NUM — Payment server ordering reference for the transaction.
• CUSTOMER_BANK_ACCOUNT_ID — Foreign key to AP_BANK_ACCOUNTS_ALL identifying the customer bank account involved.
• PAYMENT_TRXN_EXTENSION_ID — Foreign key to IBY_FNDCPT_TX_EXTENSIONS linking to payment transaction extension data.
• FIRST_RECORD_FLAG / CURRENT_RECORD_FLAG — Flags marking first and current records in a processing sequence.
• Audit columns — LAST_UPDATE_DATE, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATED_BY.

The surrogate-style key is the composite AR_CC_ERROR_HISTORY_PK, which doubles as the business-key candidate given that no separate unique index is documented. REQUEST_ID, CC_TRX_CATEGORY, CC_TRX_ID, and CC_ERROR_CODE are therefore both the documented primary key and the natural uniqueness constraint.

Common Use Cases and Queries

Typical usage includes troubleshooting failed AutoReceipt lines during a remittance batch, producing exception reports for treasury operations, and auditing vendor error trends over time. A representative query retrieves all errors for a concurrent request:

• SELECT request_id, cc_trx_category, cc_trx_id, cc_error_code, cc_error_text FROM ar.ar_cc_error_history WHERE request_id = :request_id;
• Joining to RA_CUSTOMER_TRX_ALL on CC_TRX_ID to resolve the affected invoice or credit memo.
• Joining to AR_CASH_RECEIPTS_ALL on CC_TRX_ID to resolve the affected receipt, filtered by CC_TRX_CATEGORY.
• Aggregating counts by CC_ERROR_CODE or CC_VENDOR_ERROR_DESC to identify recurring processor failures.
• Filtering by CUSTOMER_BANK_ACCOUNT_ID joined to AP_BANK_ACCOUNTS_ALL to isolate errors by customer bank account.

Related Objects

The foreign key relationships documented for this table identify the primary dependent objects:

• RA_CUSTOMER_TRX_ALL — joined on CC_TRX_ID when the category resolves to a transaction.
• AR_CASH_RECEIPTS_ALL — joined on CC_TRX_ID when the category resolves to a receipt.
• AP_BANK_ACCOUNTS_ALL — joined on CUSTOMER_BANK_ACCOUNT_ID.
• IBY_FNDCPT_TX_EXTENSIONS — joined on PAYMENT_TRXN_EXTENSION_ID for payment extension context.
• AR_CC_ERROR_HISTORY_PK — the composite primary key constraint enforcing uniqueness across REQUEST_ID, CC_TRX_CATEGORY, CC_TRX_ID, and CC_ERROR_CODE.

Because the table records batch execution outcomes, it typically relates back to the FND_CONCURRENT_REQUESTS infrastructure through REQUEST_ID and to the Oracle Payments error-reporting APIs invoked during AutoReceipt and Remittance processing.