Search Results p_schedule_ref_no

Overview

RLM_PS_SV is a server-side PL/SQL specification package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Release Management (RLM) product family, which governs demand scheduling, demand interface processing, and the lifecycle of demand and schedule data used in order promising and fulfillment flows. The package header, dated 2007, declares AUTHID CURRENT_USER and defines debug-level constants (C_SDEBUG, C_DEBUG, C_TDEBUG) that map to the standard RLM_CORE_SV logging levels. The package's documented purpose is to hold all specifications for the PurgeSchedule processing unit, meaning its primary business function is the controlled removal of obsolete or processed schedule, interface, and demand exception records, together with supporting routines used to build purge queries and produce purge-related reporting output. In release 12.1.1 and 12.2.2 it remains an internal, non-public API (classification OTHER) rather than a supported open interface; no other packages in the documented dependency set reference it, so it is treated as a leaf-level utility invoked directly by concurrent programs or administrative scripts.

Key Procedures and Functions

• NAME — A documented identifier routine associated with the package's purge scheduling logic; it resolves naming or identification data required by the purge flow.
• PURGEINTERFACE — Deletes processed or stale rows from the demand interface staging area, clearing the intermediate tables that hold demand data prior to validation and transfer into the schedule tables.
• PURGEARCHIVE — Removes archived schedule and demand records that have been retained beyond their operational retention window, supporting data-retention and table-growth management.
• BUILDQUERY — Constructs the dynamic SQL predicate used by the purge routines, assembling filter criteria from the organization, translator code range, customer, ship-to range, issue date range, schedule type, schedule reference number, and processing status parameters declared in the PurgeSchedule specification.
• RUNREPORT — Executes the reporting action associated with a purge run, providing a record of what was selected for removal or what remains after purging.
• CHECKOPENORDER — Verifies whether open order activity exists for the candidate schedule or demand rows, acting as a guard so that records still referenced by open orders are not purged.

The declared PurgeSchedule procedure exposes the errbuf/retcode concurrent program signature plus selection parameters including p_org_id, p_execution_mode, p_translator_code_from/to, p_customer, p_ship_to_address_id_from/to, p_issue_date_from/to, p_schedule_type, p_schedule_ref_no, p_delete_beyond_days, p_authorization, and p_status.

Tables Accessed

• RLM_SCHEDULE_HEADERS, RLM_SCHEDULE_LINES, RLM_SCHEDULE_LINES_ALL — The primary purge targets; schedule records are removed or filtered based on the caller's selection criteria.
• RLM_INTERFACE_HEADERS, RLM_INTERFACE_LINES — Demand interface staging rows cleared by PURGEINTERFACE.
• RLM_DEMAND_EXCEPTIONS — Exception rows linked to purged demand or schedule records.
• OE_ORDER_LINES_ALL — Read by CHECKOPENORDER to determine whether referenced order lines remain open.
• HZ_CUST_ACCOUNTS, HZ_PARTIES — TCA customer and party data used to resolve and filter by customer and ship-to criteria.
• PLITBLM — The PL/SQL integer-table utility type used for in-memory collections.

Usage Notes

RLM_PS_SV is invoked from concurrent programs that submit purge processing with the standard errbuf and retcode OUT parameters, and the same logic can be called from custom PL/SQL that requires programmatic purge of schedule and interface data. It should never be called during active demand scheduling windows without first confirming, via CHECKOPENORDER, that no open orders depend on the candidate rows. Because the package is classified as OTHER and is not referenced by other packages, it is an internal implementation component; direct modification is unsupported, and any extension should wrap the documented entry points rather than altering the specification.