Search Results validate_doc_number

Overview

ARP_TRX_VALIDATE is an internal validation package within the Oracle Receivables (AR) module of Oracle E-Business Suite. It is owned by the APPS schema and classified as an "OTHER" API in the ETRM metadata for 12.1.1 and 12.2.2. Its principal responsibility is to centralize the business-rule checks applied to receivable transactions — invoices, credit memos, debit memos, chargebacks, and commitments — before those transactions are saved, completed, or posted.

The package encapsulates cross-field validation logic that would otherwise be duplicated across multiple forms and batch programs. It validates transaction numbers and dates, enforces line-level constraints, verifies paying customer and payment-method defaults, performs General Ledger distribution checks, and inspects sign and over-application conditions. Error messages are accumulated in a packaged PL/SQL collection (Message_Tbl_Type) rather than raised immediately, allowing a calling form to display multiple validation failures in a single pass. The ETRM metadata records that the package is referenced by 23 other packages, underscoring its role as a shared validation utility within the AR transaction stack.

Key Procedures and Functions

The ETRM documentation lists 15 callable procedures and functions. Their intended purposes are summarized below.

• CHECK_SIGN_AND_OVERAPP — Evaluates whether a transaction's creation sign, the open-receivables flags on the current and previous transactions, and the system's allow-overapplication and natural-application settings are consistent. This is the routine the user searched for and is central to preventing invalid credit/debit sign combinations or applications that exceed permitted limits.
• AR_ENTITY_VERSION_CHECK — Compares a form name and form version against the expected entity version, guarding against mismatched client and server code.
• CHECK_DUP_LINE_NUMBER — Detects duplicate line numbers within a transaction, excluding the line currently being saved.
• CHECK_HAS_ONE_LINE — Confirms that a transaction contains at least one line, optionally suppressing the error message.
• VALIDATE_TRX_NUMBER — Validates that a transaction number is unique within its batch source.
• VALIDATE_TRX_DATE — Performs date checks, including comparison against a previous transaction date, commitment date, and agreement or batch-source rules.
• VAL_GL_DIST_AMOUNTS — Verifies that General Ledger distributions for the transaction balance correctly.
• VALIDATE_PAYING_CUSTOMER — Confirms that the paying customer is valid and properly related to the bill-to customer.
• VAL_AND_DFLT_PAY_MTHD_AND_BANK — Validates and defaults the payment method and bank account used for the transaction.
• DO_COMPLETION_CHECKING — Runs the consolidated set of checks required before a transaction can be completed.
• ADD_TO_ERROR_LIST — Appends a message to the packaged error collection for later retrieval and display.
• VALIDATE_DOC_NUMBER — Validates the document number associated with the transaction.
• INIT — Initializes the package state, clearing the message collection prior to a validation cycle.

Tables Accessed

The package reads and writes a defined set of AR and shared tables through APPS synonyms. Transaction and line data are read from RA_CUSTOMER_TRX and RA_CUSTOMER_TRX_LINES; adjustments and memo lines from AR_ADJUSTMENTS and AR_MEMO_LINES. Payment validation relies on AR_RECEIPT_CLASSES, AR_RECEIPT_METHODS, and AR_RECEIPT_METHOD_ACCOUNTS. System-level defaults and controls are sourced from AR_SYSTEM_PARAMETERS, while CE_BANK_ACCOUNTS and FND_CURRENCIES supply bank and currency information. Customer validation uses HZ_CUST_ACCOUNTS and HZ_CUST_ACCT_RELATE. Batch source rules come from RA_BATCH_SOURCES and RA_BATCH_SOURCES_ALL, and freight validation uses ORG_FREIGHT.

Usage Notes

ARP_TRX_VALIDATE is typically invoked from the Receivables transaction entry forms, where it is called during save and completion processing to surface validation errors to the user. It is also called by concurrent programs and by other AR packages — the metadata notes 23 referencing packages — to enforce identical rules in batch contexts such as AutoInvoice and transaction completion workflows. Custom code should call these procedures only after initializing package state via INIT and should read the accumulated message table rather than relying on exceptions. Because the package is an internal, non-public API, direct invocation in customizations carries upgrade risk and should be limited to diagnostics or supported extension points.