Search Results term_threshold




Overview
Explore in AI Chat

Overview

AR_REVENUE_MANAGEMENT_PVT is the private implementation package body behind Oracle E-Business Suite Revenue Management (also marketed as Enterprise Revenue Management, or ETRM). It embodies the revenue recognition engine used by Oracle Receivables to determine when revenue may be recognized on a transaction line and to manage the supporting contingency, deferral, and collectibility logic. In the 12.1.1 and 12.2.2 releases the package resides in the APPS schema, is classified as a PVT (private) API, and is called internally by Receivables processing rather than by external integrators. The header comment (ARXRVMGB.pls 120.100.12010000.3) indicates a long-lived, actively patched component whose logic extends back to earlier releases but remains authoritative for 12.1.1 and 12.2.2.

The package declares a cursor type (RefCurType), standard return-code constants (SUCCESS, WARNING, FAILURE), and a set of caching globals for credit classes, currency code, precision, and minimum accountable unit. A single debug helper wraps arp_debug.debug, gated by the AFLOG_ENABLED profile option.

Key Procedures and Functions

The documented interface exposes eighteen procedures and functions. The principal revenue determination routines are:

  • REVENUE_MANAGEMENT_ENABLED — reports whether Revenue Management is active for the current operating context.
  • CASH_BASED — indicates whether cash-basis accounting rules apply.
  • ACCEPTANCE_ALLOWED — determines whether line acceptance is permitted before revenue recognition.
  • CREDITWORTHY — evaluates customer creditworthiness as a gating condition.
  • LINE_COLLECTIBLE and TXN_COLLECTIBLE — assess collectibility at the line and transaction level.
  • LINE_COLLECTIBILITY — returns the collectibility status used by downstream sweeps.

Processing and maintenance routines include PERIODIC_SWEEPER, RECEIPT_ANALYZER, REVENUE_SYNCHRONIZER, and PROCESS_EVENT, which drive deferred revenue release and workflow-driven events. Line contingency maintenance is handled by UPDATE_LINE_CONTS and DELETE_LINE_CONTS, with DELETE_FAILED_ROWS and DELETE_REJECTED_ROWS cleaning interface staging. GET_LINE_ID resolves the customer transaction line identifier.

The body also contains INSERT_TERM_CONTINGENCIES, which defaults contingency ID 5 based on term due days compared to the system option TERM_THRESHOLD, suppressed when the deferral exclusion flag is set or validation errors exist. This is directly relevant to the search term RA_INTERFACE_CONTINGENCIES_ALL.

Tables Accessed

Revenue data is read from RA_CUSTOMER_TRX_LINES and written to AR_LINE_CONTS, AR_LINE_CONTS_ALL, AR_DEFERRED_LINES, and AR_INTERFACE_CONTS (the interface table corresponding to RA_INTERFACE_CONTINGENCIES_ALL). Supporting setup is read from AR_SYSTEM_PARAMETERS, AR_DEFERRAL_REASONS, and AR_RDR_PARAMETERS_GT. Adjustment and application logic draws on AR_ADJUSTMENTS and AR_RECEIVABLE_APPLICATIONS. Workflow integration uses WF_EVENTS, while global temporary staging tables AR_REVIEWED_LINES_GT, AR_TRX_CONTINGENCIES_GT, AR_TRX_ERRORS_GT, and AR_TRX_HEADER_GT carry interim results.

Usage Notes

Because this is a PVT API, it should not be called directly by customer extensions; it is invoked by AutoInvoice, the Invoice API, the Revenue Management workbench, and Receivables concurrent programs. External developers requiring equivalent functionality should use the public Revenue Management APIs. The search for RA_INTERFACE_CONTINGENCIES_ALL is explained by the package's contingency-insertion logic, which stages records through AR_INTERFACE_CONTS before validation moves them into AR_LINE_CONTS.