Search Results submit_refresh_request




Overview
Explore in AI Chat

Overview

The APPS.AR_CMGT_REFRESH_CONC package is a component of Oracle Receivables' Credit Management module, introduced to support the case folder refresh architecture in Oracle E-Business Suite release 12.1.1 and 12.2.2. Its primary business function is to facilitate the controlled, on-demand refresh of credit management case folders so that the data presented to credit analysts reflects the most current transactional, customer, and credit information available in the system. Case folders aggregate credit-related data for a customer or a credit request, and over time the underlying data — open balances, credit limits, dispute statuses, and scoring inputs — changes. Without a refresh mechanism, the case folder would display stale information, degrading the quality of credit decisions.

The suffix "CONC" in the package name indicates that the package is oriented toward concurrent processing. This package therefore acts as the programmatic bridge between the user-facing request to refresh data and the concurrent manager that performs the actual update work in the background, avoiding long-running transactions in the interactive forms session. The package is owned by the APPS schema and is documented as VALID in ETRM, confirming it is a supported, compiled object in the environment.

Key Procedures and Functions

The package exposes two documented procedures:

  • SUBMIT_REFRESH_REQUEST — Submits a refresh request for processing. This procedure is responsible for initiating the refresh workflow, typically by registering or launching the concurrent request that will perform the refresh of case folder data. It represents the entry point through which callers ask the system to bring a case folder up to date, decoupling the request from the execution.
  • REFRESH_CASE_FOLDER — Performs the actual refresh of the case folder content. This procedure operates on the case folder data itself, recomputing or repopulating the information held against the case folder so that subsequent queries return current results. It is the worker routine invoked after a refresh request has been accepted.

Both procedures are classified as OTHER in the ETRM API classification, indicating they are internal integration routines rather than a formally published public API with guaranteed interface stability. No parameter lists are documented in the available metadata, and callers should not assume interface stability across patches.

Tables Accessed

The documented table referenced by this package, through APPS synonyms, is:

  • AR_CMGT_CASE_FOLDERS — The Credit Management case folder table. This is the principal data store for case folder records, holding the folder header and associated attributes used by the credit management workbench. The refresh package reads from and writes to this table as part of rebuilding or updating case folder contents.

Because the refresh operation reconciles case folder data with underlying credit and transaction information, the package's runtime activity typically extends to related Receivables tables through the logic invoked during refresh. Only AR_CMGT_CASE_FOLDERS is confirmed in the documented metadata.

Usage Notes

This package is normally invoked indirectly rather than through direct custom code. In standard EBS operation, it is called by the Credit Management concurrent program infrastructure when a user requests a refresh of a case folder from the Credit Management workbench. The package metadata shows it is referenced by OCM_CREDIT_REQUEST_UPDATE_PUB, indicating that credit request updates can trigger a case folder refresh, keeping the two structures synchronized.

Because the package is classified as OTHER and its parameter lists are undocumented, customizations that call it directly carry maintenance risk, particularly during upgrades between 12.1.1 and 12.2.2. Where a refresh is required, the supported approach is to invoke the associated concurrent program through the standard request submission framework rather than calling SUBMIT_REFRESH_REQUEST or REFRESH_CASE_FOLDER directly. Administrators should also confirm that the concurrent manager is active, since the request submission depends on it.