Search Results create_op

Overview

APPS.OE_PC_GLOBALS is a foundational constants and global-declaration package within the Oracle E-Business Suite Order Management (Order Entry) module. It does not itself implement business transactions; rather, it centralizes the shared literal values, type declarations, and enumerated constants that the broader Order Capture / Processing Constraints framework and related APIs rely upon. The package is declared AUTHID CURRENT_USER, meaning its stored procedures and functions execute with the privileges of the invoking user rather than the package owner, which is appropriate for a shared utility referenced across many callers. The source header (OEXPPCGS.pls 115.9, 2003/10/20) indicates the package dates to the earlier Order Entry code line and has been carried forward unchanged into the 12.1.1 and 12.2.2 releases. In the ETRM metadata it is classified as an API of type OTHER and is referenced by 39 other packages, confirming its role as a widely consumed dependency across Order Management processing.

Key Procedures and Functions

Only one procedure is formally documented in the ETRM metadata for this package:

• DEBUG_PRINT — A diagnostic utility used to emit debugging output during development or troubleshooting. It is not part of the functional order-processing path and is not intended for use in production business logic.

The great majority of the package body consists of constant and type declarations rather than executable subprograms. These constants are the package's real value to callers. The order-operation action codes are particularly relevant to the user's search term:

• DELETE_OP (varchar2(1) := 'D') — The single-character code identifying a delete operation, alongside its siblings CREATE_OP ('C'), RETRIEVE_OP ('R'), UPDATE_OP ('U'), CANCEL_OP ('X'), SPLIT_OP ('S'), and EXECUTE_OP ('E'). These codes are consistently used across Order Management APIs to signal which operation a caller is performing.
• On-operation action flags — DONT (0), RREASON (1), RHISTORY (2), RVERSN (0.1), and VERSNONLY (0.2), used to control whether a reason, history record, or version is recorded for a given operation.
• Constrained entity identifiers — G_ENTITY_HEADER (1), G_ENTITY_LINE (2), G_ENTITY_HEADER_SCREDIT (5), G_ENTITY_HEADER_ADJ (6), G_ENTITY_LINE_SCREDIT (7), G_ENTITY_LINE_ADJ (8), G_ENTITY_BLANKET_HEADER (1018), G_ENTITY_BLANKET_LINE (1019), G_ENTITY_HEADER_PAYMENT (1024), and G_ENTITY_LINE_PAYMENT (1025). These correspond to the entity_id column of the oe_pc_entities_v view.
• Validation-type and boolean flags — WF_VALIDATION ('WF'), TBL_VALIDATION ('TBL'), API_VALIDATION ('API'), YES (1), NO (0), ERROR (-1), YES_FLAG ('Y'), NO_FLAG ('N').
• Buffer and formatting constants — MSDATA_LEN (238), MIN_WRITE_LENGTH (1100), MAX_WRITE_LENGTH (1200), NEWLINE, COMMENT ('C'), PKG ('P'), SQLSTR ('S'), and HOST_CONC_PROGRAM.

Tables Accessed

The ETRM metadata records no direct table references through APPS synonyms for this package, which is consistent with its nature as a constants repository. Its entity constants are nonetheless definitionally tied to oe_pc_entities_v, the constrained-entities view whose entity_id values the constants enumerate. Consumers of the package, not the package itself, perform the actual DML against Order Management base and interface tables.

Usage Notes

OE_PC_GLOBALS is invoked indirectly wherever Order Management processing constraints, order capture APIs, or validation routines need to interpret an operation code, entity identifier, or validation type. A caller performing a deletion, for example, passes or compares against OE_PC_GLOBALS.DELETE_OP rather than hard-coding the literal 'D'. Because it is referenced by 39 other packages, its constants function as the de facto contract for operation and entity semantics throughout Order Entry. It is not exposed directly through a form or concurrent program; it is a programmatic dependency for PL/SQL-based customizations, workflow validation routines, and standard Order Management APIs. When extending Order Management in 12.1.1 or 12.2.2, referencing these constants rather than literal values is the recommended practice to maintain compatibility.