Search Results validate_assignment




Overview

AR_BILLS_MAINTAIN_VAL_PVT is a private validation package body in the Oracle Receivables module of Oracle E-Business Suite. It consolidates the business rule validation logic used by the Bills Receivable maintenance APIs and the Bills Receivable workbench. The package declares a comprehensive set of status and event constants — including INCOMPLETE, PENDING_REMITTANCE, PENDING_ACCEPTANCE, MATURED_PEND_RISK_ELIMINATION, CLOSED, REMITTED, PROTESTED, FACTORED, and ENDORSED — along with event constants such as MATURITY_DATE, FORMATTED, COMPLETED, ACCEPTED, SELECTED_REMITTANCE, CANCELLED, RISK_ELIMINATED, and RELEASE_HOLD. These constants drive state-transition checks applied against Bills Receivable records. Because the package is classified as a PVT (private) API, it is not intended for direct invocation by external or customer code; it is called internally by the corresponding public Bills Receivable maintenance APIs to enforce Receivables business rules consistently.

The version header indicates the package has been stable since release 11.5, and the same body is shipped in both 12.1.1 and 12.2.2 with the object owner APPS. The user search term "validate_assignment" aligns with this package's role: the individual VALIDATE_* routines validate the assignment of an action, an identifier, or a date range against Bills Receivable data before a state change is persisted.

Key Procedures and Functions

The documented package exposes nine validation procedures. Each confirms that a proposed Bills Receivable operation is legal given the current state of the record and its related data.

  • VALIDATE_COMPLETE_BR — Validates that a Bills Receivable may be completed, applying completion-related status and event rules.
  • VALIDATE_ACCEPT_BR — Validates that a Bills Receivable may be accepted, verifying the record is in a state from which acceptance is permitted.
  • VALIDATE_CANCEL_BR — Validates that a Bills Receivable may be cancelled, blocking cancellation where dependent activity exists.
  • VALIDATE_UNPAID_BR — Validates that a Bills Receivable remains unpaid or qualifies for an operation that requires an unpaid status.
  • VALIDATE_PAYMENT_SCHEDULE_ID — Validates the payment schedule identifier supplied in the transaction, confirming it belongs to the relevant transaction.
  • VALIDATE_REMIT_BATCH_ID — Validates the remittance batch identifier supplied, confirming it is valid and appropriate for the remittance operation.
  • VALIDATE_ADJ_ACTIVITY_ID — Validates the receivables adjustment activity identifier passed in the request.
  • VALIDATE_ACTION_DATES — Validates date values associated with a Bills Receivable action, ensuring they are consistent with the current record.
  • VALIDATE_REMITTANCE_DATES — Validates the date range associated with a remittance, ensuring remittance dates are logically consistent.

No parameter lists are documented here; the procedures are invoked by name from the calling maintenance layer. Collectively they implement the validate_assignment pattern, confirming that each identifier, date, or state transition assigned to a Bills Receivable is valid before the operation proceeds.

Tables Accessed

The package reads and, where required, updates the following tables through APPS synonyms:

Usage Notes

AR_BILLS_MAINTAIN_VAL_PVT is a private package and is referenced by two other packages, which are the public maintenance APIs responsible for completing, accepting, cancelling, remitting, and otherwise processing Bills Receivable records. It is invoked during Bills Receivable workbench operations in the Receivables forms, during concurrent programs that process Bills Receivable, and by internal API callers that require the same validation rules applied in the UI. Because the package is classified PVT, custom code should not call it directly; customizations and extensions should invoke the supported public Bills Receivable APIs, which in turn delegate to these validation procedures. The identical PKG body is present in both 12.1.1 and 12.2.2, so validation behaviour is consistent across those releases.