Search Results raise_event_hist

Overview

ECEPOI is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM API taxonomy as OTHER. The package name derives from its role in the ECE (E-Commerce Gateway / Electronic Commerce) product family, specifically the Process Order Import (POI) inbound processing flow. Its principal entry point, Process_POI_Inbound, coordinates the ingestion of inbound order files through the E-Commerce Gateway, performing mapping, validation, and optional import into Oracle Order Management. The package also supplies a set of utility procedures used to resolve customer-related identifiers — most notably ship-to and bill-to organization identifiers — during inbound transaction processing. The header comment in the source ($Header: ECPOIS.pls 120.3.12010000.1) indicates a maintenance lineage extending through the 12.1 code line, and the package remains present in the 12.2.2 documented metadata with eight documented procedures and functions.

Key Procedures and Functions

The documented callable units cover both the main processing driver and several supporting utilities:

• PROCESS_POI_INBOUND — The primary concurrent-program entry point. It accepts file location, file name, debug mode, import flag, instance count, transaction type, mapping identifier, and data file character set, and returns the standard concurrent error buffer and return code. It drives the inbound order loading cycle.
• CONCAT_STRINGS — A generic three-input string concatenation helper returning a single output string, used internally for building composite values such as keys or references.
• GET_SHIP_TO_ORG_ID — Resolves the ship-to organization identifier from a given address identifier and customer identifier. This is the procedure most commonly referenced by developers searching for the "get_ship_to_org_id" term, typically from custom inbound or integration code that must derive a valid ship-to organization without re-implementing site-use logic.
• GET_BILL_TO_ORG_ID — The counterpart routine that derives the bill-to organization identifier from an address identifier and customer identifier.
• CONCAT_INSTRUCTIONS — A five-input concatenation utility introduced as a fix for Bug 2627330, used to assemble instruction text from multiple source components.
• EM_TRANSACTION_TYPE — A function that accepts a transaction code and returns the corresponding E-Commerce Gateway transaction type string.
• RAISE_EVENT_HIST — Raises an event history record, accepting order source, original system document reference, sold-to organization, transaction type, and numerous optional identifiers (document, change sequence, order number, item type/key, status, message text, processing flags, XML Gateway party identifiers, order type, header, and organization), returning a return status.
• GET_ITEM_DESCRIPTION — Retrieves an item description for a supplied organization identifier, used to enrich inbound order lines with descriptive text.

Tables Accessed

The package references several base tables through APPS synonyms. Customer and site resolution — the logic behind GET_SHIP_TO_ORG_ID and GET_BILL_TO_ORG_ID — relies on HZ_CUST_ACCT_RELATE_ALL, HZ_CUST_ACCT_SITES, and HZ_CUST_SITE_USES_ALL, which together hold customer account relationships, account sites, and site-use assignments such as ship-to and bill-to designations. ECE_MAPPINGS provides the cross-reference and mapping configuration used during inbound file processing. Item-related lookups use MTL_CROSS_REFERENCES, MTL_CROSS_REFERENCE_TYPES, and MTL_CUSTOMER_ITEMS to resolve customer item numbers and cross-references. WF_PARAMETER_LIST_T is used in the workflow/event raising path, while DUAL and PLITBLM support trivial queries and PL/SQL table handling respectively.

Usage Notes

ECEPOI is ordinarily invoked through the E-Commerce Gateway inbound processing concurrent program, which calls PROCESS_POI_INBOUND. Custom integrations that need to derive a ship-to organization typically call GET_SHIP_TO_ORG_ID directly from their own PL/SQL rather than duplicating the customer site-use query logic. Because the package is classified as OTHER rather than a public, fully supported API, implementations should treat its procedures as internal and validate behavior carefully across patch levels and between 12.1.1 and 12.2.2. The package is not referenced by any other documented package, so callers are predominantly concurrent programs, forms-based oracle flows, and bespoke integration code. Developers should confirm parameter signatures against the deployed ECPOIS.pls in their environment, since the documented surface does not include full parameter detail for every routine.