Results for “so_agreements”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

OEP_CMERGE_OESET is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the API classification OTHER within the ETRM repository for release 12.2.2 (and applicable to 12.1.1). Its name and the "OESET" suffix indicate that it belongs to the Oracle Order Management (OE) family of set-based processing units, specifically one that participates in the customer merge ("CMERGE") operation. The package is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the invoking schema rather than the definer, a design choice typical of internal, system-invoked utilities rather than public, customer-facing APIs.

The header comment ("$Header: oesetps.pls 115.0 99/07/16 08:28:06 porting ship $") identifies the source file as oesetps.pls and places its original creation in the 1999 timeframe, during the Oracle Applications 11i development cycle. The package has therefore remained a stable internal component across subsequent EBS releases. Its business function is to support the consolidation of duplicate customer records by re-pointing or otherwise reconciling Order Management data that references the customer being merged. When two customer records are merged in Oracle Receivables, dependent transactional and setup data across other modules must be updated so that the surviving customer account retains a complete history; OEP_CMERGE_OESET is one of the Order Management set-level workers that performs this reconciliation.

Key Procedures and Functions

The documented package specification exposes a single public procedure: MERGE. As recorded in the ETRM metadata, MERGE accepts a request identifier, a set number, and a process mode indicator. Its purpose is to process one logical "set" of records as part of a larger customer merge run. The request identifier ties the invocation back to the parent concurrent request that orchestrated the merge; the set number identifies which slice or batch of records this particular call is responsible for; and the process mode governs how the procedure behaves (for example, whether it performs the work directly, reports what it would do, or runs in a diagnostic/validation capacity). Because the specification is minimal and carries the "porting ship" marker, the procedure is intended for internal, programmatic invocation only. No other functions or procedures are documented for this package, and the implementation body is not exposed in the metadata.

Tables Accessed

Two base tables are documented as being referenced through APPS synonyms:

• RA_CUSTOMER_MERGES — the Receivables customer merge control table. This table drives and tracks the merge activity; OEP_CMERGE_OESET reads it to determine which customer merge request and set are being processed and to coordinate its own updates with the overall merge transaction.
• SO_AGREEMENTS — the Order Management agreements (sales agreements / blanket agreements) table. These records are customer-specific, so when a duplicate customer is merged, agreement rows that reference the obsolete customer must be re-pointed to the surviving customer. The package updates SO_AGREEMENTS accordingly as part of the set-level merge work.

The use of these two tables confirms the package's narrow scope: it handles the customer merge plumbing for Order Management agreement data rather than a broad set of order tables.

Usage Notes

OEP_CMERGE_OESET is not a user-invoked API. It is called internally during the Oracle Receivables customer merge process, which is itself driven by the "Customer Merge" concurrent program in Receivables. The Order Management application registers its own merge workers so that OE-owned data is included in the merge; this package is one such worker and is invoked per request and per set as the merge program iterates through the affected records. Because the package is compiled AUTHID CURRENT_USER and is not listed among public or supported APIs, customers should not call it directly from custom code. The ETRM metadata further indicates that it is referenced by one other package, confirming that it is itself a subordinate component within a larger call graph rather than an entry point. Its relevance to a search for "malware protection tools" is incidental: the ETRM object name simply surfaced as a match and has no security or malware-protection function. Any changes to this package should be treated as internal Oracle modifications and evaluated through the standard patching and regression-testing path rather than through direct customization.