Search Results start_process

Overview

OZF_LE_UPGRADE_PVT is a private PL/SQL package body in the Oracle E-Business Suite Applications (APPS) schema that performs one-time Legal Entity Stamping for existing Trade Management (formerly Oracle Channel Revenue Management) claim records. The package was introduced in 2005 as part of the multi-organization and legal entity data model transition, when Oracle required that transactional records be stamped with the appropriate legal entity identifier derived from the operating unit context.

In Oracle EBS 12.1.1 and 12.2.2, legal entities are maintained through the XLE (Legal Entity) data model, and operating unit to legal entity relationships are resolved via the XLE_BUSINESSINFO_GRP package. OZF_LE_UPGRADE_PVT bridges legacy claim data into that model by iterating over claims that have not yet been stamped and populating their legal_entity_id column. The package is classified as PVT (private) in the ETRM repository, indicating it is intended for internal invocation rather than direct customer-facing API use. Its header references the source file ozfvcleb.pls, and the package constant G_PKG_NAME identifies it as OZF_LE_UPGRADE_PVT.

Key Procedures and Functions

The ETRM metadata documents a single procedure, START_PROCESS. This procedure is the main entry point for the package and drives the entire legal entity stamping process. Its declared parameters comprise an error buffer (ERRBUF), a return code (RETCODE), and an optional organization identifier (p_org_id) that can scope the processing to a single operating unit when supplied.

START_PROCESS opens an internal cursor (claim_org_id_csr) that selects claim_id and org_id from OZF_CLAIMS_ALL for all claims whose legal_entity_id is null. For each row retrieved, the procedure determines the corresponding legal entity and updates the claim record accordingly. The procedure emits structured progress information to the concurrent program log file using FND_FILE.PUT_LINE, including a start banner and timestamp. Standard FND_API return status values (initialized to FND_API.G_RET_STS_SUCCESS) and message count variables are used in the implementation, and processing is wrapped within a SAVEPOINT named Start_Process. The history comment records creation by the developer kdhulipa on 30-Sep-2005.

Tables Accessed

Two tables are referenced through APPS synonyms:

• OZF_CLAIMS_ALL — the Trade Management claims table. The package reads claim_id and org_id for records lacking a legal entity, and writes the resolved legal_entity_id back to each row. This is the primary business data affected by the upgrade.
• XLE_ENTITY_PROFILES — the legal entity definition table. The package reads this table to resolve and validate the legal entity identifier (LEGAL_ENTITY_ID) that will be stamped onto each claim.

The package additionally references the XLE_BUSINESSINFO_GRP package (declaring a variable of type OU_LE_Tbl_Type but no OU_LE_Tbl_Type), which provides the mapping between operating units and legal entities, allowing the stamping logic to translate an operating unit context into the correct legal entity.

Usage Notes

OZF_LE_UPGRADE_PVT is referenced by zero other packages in the ETRM repository, confirming its nature as a standalone utility rather than a shared library. It is typically invoked as a concurrent program execution, since START_PROCESS declares the standard ERRBUF and RETCODE OUT parameters expected by Oracle concurrent managers, and it writes output through FND_FILE. Customers and implementation teams run this package once during or after an upgrade to Oracle EBS 12.x to backfill legal entity identifiers on pre-existing Trade Management claims.

Because the procedure is scoped by a cursor that selects only claims with a null legal_entity_id, it is idempotent in practice: re-running it after successful completion finds no rows to process and exits cleanly. When diagnosing issues, the concurrent program log produced by FND_FILE.PUT_LINE should be reviewed first, as it contains the run timestamp and summary banners. The optional p_org_id parameter allows targeted reruns for a single operating unit when a bulk run must be limited. As a PVT-classified package, it should not be called directly from custom code; any customization should rely on supported public APIs instead.