Search Results oe_workflow_merge

Overview

APPS.OE_CUST_MERGE_DATA_FIX is a customer merge data fix package belonging to the Oracle Order Management (ONT) product family. When two customer records are merged in Oracle Receivables through the Customer Merge concurrent program, dependent transactional data across all EBS modules must be re-pointed or consolidated so that historical orders, defaults, workflow items, and related setups remain consistent with the surviving customer or site. This package supplies the Order Management contribution to that cross-product merge process by executing a series of area-specific fix routines against ONT-owned tables.

The package was authored with an AUTHID CURRENT_USER directive, meaning its unqualified references to application objects resolve through the schema of the calling user rather than the package owner. The embedded header comment dates the source to 2005 and explicitly references the Customer Merge high-level design document (cmerge_hld.rtf), confirming that the package is a sanctioned, design-controlled component of the merge architecture rather than an ad hoc patch script.

As documented in ETRM for 12.2.2, the package carries an API classification of OTHER and exposes ten public procedures. It is not referenced by any other packaged code, indicating that it functions as a top-level entry point for the merge framework rather than as a reusable library.

Key Procedures and Functions

The documented procedure list comprises one controlling driver and nine internal merge routines, each accepting a request identifier, a merge set number, and a process mode that governs execution behavior (for example, report versus update processing).

• MERGE — The main entry point. It orchestrates customer merge processing for the ONT product, delegating to the individual functional-area routines below.
• OE_ATTACHMENT_MERGE — Handles merge logic for order attachments and attachment rules.
• OE_DEFAULTING_MERGE — Processes customer-dependent defaulting rules and conditions so that they are reassigned to the surviving customer.
• OE_CONSTRAINTS_MERGE — Reconciles order constraints associated with the merged customer.
• OE_SETS_MERGE — Merges customer-specific order sets and related item settings.
• OE_DROP_SHIP_MERGE — Re-points drop ship sourcing information tied to the merged party.
• OE_SHIP_TOLERANCE_MERGE — Consolidates shipping tolerance configurations linked to the customer.
• OE_HOLD_MERGE — Resolves hold source definitions affected by the merge.
• OE_ORDER_MERGE — Updates order headers, lines, history, and acknowledgements to reference the surviving customer.
• OE_WORKFLOW_MERGE — The routine most directly associated with the search term oe_workflow_merge; it processes Order Management workflow data affected by the customer consolidation, ensuring in-flight and historical workflow activity remains correctly attributed after the merge.

Tables Accessed

ETRM documents the following ONT tables and views being accessed through APPS synonyms, mapped to their functional areas:

• Order transaction data: OE_ORDER_HEADERS_ALL, OE_ORDER_LINES_ALL, and OE_ORDER_LINES_HISTORY, updated by OE_ORDER_MERGE; OE_HEADER_ACKS and OE_LINE_ACKS for acknowledgement records.
• Hold and constraint data: OE_HOLD_SOURCES.
• Defaulting configuration: OE_DEF_ATTR_DEF_RULES and OE_DEF_CONDN_ELEMS.
• Sets and item settings: OE_SETS and OE_CUST_ITEM_SETTINGS.
• Drop ship sourcing: OE_DROP_SHIP_SOURCES.
• Attachments: OE_ATTACHMENT_RULE_ELEMENTS; plus OE_PC_VTMPLT_COLS for template columns.
• Merge control: RA_CUSTOMER_MERGES, the Receivables merge driver table that supplies the request and merge set context consumed by the MERGE procedure.

Usage Notes

In Oracle EBS 12.1.1 and 12.2.2, this package is not intended for direct invocation by end users or custom code. It is called by the standardized customer merge framework, typically from the Customer Merge concurrent request flow originating in Receivables, which passes the request identifier and merge set number into MERGE. The process mode parameter allows the same code path to support validation or reporting passes before the update pass is executed. Because the package operates with AUTHID CURRENT_USER, correct operation depends on the invoking session's schema having the expected APPS synonyms and privileges. Customizations that add customer-dependent ONT data should be evaluated against the merge framework, since this package will not automatically account for tables outside its documented scope.