Search Results arp_trx_validate




Overview
Explore in AI Chat

Overview

ARP_TRX_VALIDATE is a core validation package body in the Oracle Receivables (AR) module of Oracle E-Business Suite, owned by the APPS schema. Its principal business function is to enforce the integrity rules that govern receivable transactions before they are saved, completed, or posted. The package centralizes checks that previously would be scattered across form-level triggers and concurrent programs, providing a single, reusable validation layer for transaction data — header amounts, line numbers, distribution amounts, transaction dates and numbers, paying customer relationships, and receipt method and bank account defaults. Because it operates primarily against the base Receivables transaction tables rather than the AutoInvoice interface tables, it serves the manual transaction entry path (the Transactions and Receipts forms) as well as programmatic APIs that need to validate a transaction prior to calling ARP_PROCESS_CREDIT_UTIL or ARP_TRX_COMPLETE_CHK. The package is documented as valid in both 12.1.1 and 12.2.2, and it is referenced by 23 other database objects, which confirms its role as a shared dependency for higher-level transaction logic.

Key Procedures and Functions

The documented interface comprises fifteen procedures and functions. Each addresses a specific validation or defaulting concern:

  • INIT — performs package-level initialization, establishing global state (typically ARP_GLOBAL values) used by subsequent calls in the same session.
  • VALIDATE_TRX_NUMBER — verifies the transaction number meets numbering and uniqueness rules for the transaction type.
  • VALIDATE_TRX_DATE — confirms the transaction date falls within valid open periods and accounting date constraints.
  • VALIDATE_DOC_NUMBER — validates the document number supplied for the transaction.
  • CHECK_DUP_LINE_NUMBER — detects duplicate line numbers within the same transaction.
  • CHECK_HAS_ONE_LINE — ensures the transaction contains at least one line, especially for transaction types that require it.
  • CHECK_SIGN_AND_OVERAPP — validates the sign of amounts and checks for over-application of credit against the target transaction.
  • VAL_GL_DIST_AMOUNTS — verifies that accounting distribution amounts balance and are consistent with line amounts.
  • VALIDATE_PAYING_CUSTOMER — confirms the paying customer relationship exists and is valid for the transaction.
  • VAL_AND_DFLT_PAY_MTHD_AND_BANK — validates and, where missing, defaults the receipt method and bank account information.
  • DO_COMPLETION_CHECKING — runs the collective set of checks required before a transaction may be completed.
  • ADD_TO_ERROR_LIST — appends a message to the error collection so all failures can be reported together.
  • AR_ENTITY_VERSION_CHECK — performs optimistic locking verification against the entity version to prevent lost updates.

Tables Accessed

The package reads and validates against a broad set of Receivables and shared reference tables, including RA_CUSTOMER_TRX, RA_CUSTOMER_TRX_LINES, AR_ADJUSTMENTS, AR_MEMO_LINES, AR_RECEIPT_CLASSES, AR_RECEIPT_METHODS, AR_RECEIPT_METHOD_ACCOUNTS, AR_SYSTEM_PARAMETERS, RA_BATCH_SOURCES, RA_BATCH_SOURCES_ALL, RA_CUST_TRX_TYPES, RA_CUST_TRX_LINE_GL_DIST, RA_CUST_TRX_LINE_SALESREPS, RA_SALESREPS, RA_TERMS, and RA_INTERFACE_LINES. Customer and bank data are drawn from HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_RELATE, AR_PAYING_RELATIONSHIPS_V, CE_BANK_ACCOUNTS, CE_BANK_ACCT_USES, and CE_BANK_BRANCHES_V, with currency and freight reference from FND_CURRENCIES and ORG_FREIGHT. Read-only reference data such as AR_LOOKUPS, GL_SETS_OF_BOOKS, and RA_CUSTOMER_TRX provides the setup context against which validation rules are applied.

Usage Notes

ARP_TRX_VALIDATE is typically invoked indirectly. In standard EBS operation it is called by the Receivables transaction entry forms and by the completion workflow (via ARP_TRX_COMPLETE_CHK) when a user attempts to complete or save a transaction. It is also a documented dependency of 23 other packages, meaning custom extensions and standard APIs across Receivables may call its procedures directly. Custom code should not attempt to bypass these checks; instead, call the appropriate validation procedure and inspect the error list populated by ADD_TO_ERROR_LIST before proceeding to completion or posting. Because the package maintains session state through INIT, INIT must be called before other procedures within a session. The package does not write to interface tables — its scope is validation and defaulting against existing transaction data — so it is safe to invoke repeatedly as a pre-commit guard rather than as a data-loading routine.