Search Results blanket_date_changed

Overview

OE_BLANKET_WF_UTIL is a utility package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It provides the PL/SQL backbone that integrates Oracle Order Management blanket sales agreements with Oracle Workflow. Blanket sales agreements allow a customer to commit to purchasing predefined quantities or amounts of items over a negotiated period at agreed prices. The lifecycle of such an agreement—creation, negotiation, customer acceptance or rejection, extension, closure, and termination—is orchestrated through Workflow processes. OE_BLANKET_WF_UTIL encapsulates the procedural logic that these processes call to update blanket agreement data, evaluate release eligibility, and manage Workflow item state. As a utility (UTIL-classified) package, it does not itself represent a public integration API; rather, it is an internal helper invoked by the blanket agreement Workflow activities. Its dependency graph confirms its supporting role: it references the generic SYS.STANDARD package and is referenced by OE_BLANKET_UTIL, OE_BLANKET_WF, OE_NEGOTIATE_WF, OE_DELAYED_REQUESTS_PVT, and recursively by itself.

Key Procedures and Functions

The package exposes eleven documented procedures and functions, each mapping to a milestone in the blanket agreement lifecycle:

• CREATE_AND_START_FLOW — Creates the Workflow item for a blanket agreement and initiates its associated process, establishing the runtime Workflow context for the agreement.
• SUBMIT_DRAFT — Submits a draft blanket agreement into the approval or negotiation cycle.
• BLANKET_DATE_CHANGED — Handles the business event triggered when effective or expiration dates on a blanket agreement are modified.
• CUSTOMER_ACCEPTANCE — Records customer acceptance of the negotiated agreement, advancing the Workflow to its active state.
• CUSTOMER_REJECTED — Records customer rejection, routing the agreement to the appropriate terminal Workflow outcome.
• CHECK_RELEASE — Validates whether a release may be created against the blanket agreement, enforcing the agreement's status, dates, and terms.
• EXTEND — Processes extension of the agreement's validity period.
• CLOSE — Closes the blanket agreement, preventing further releases while preserving history.
• TERMINATE — Terminates the agreement before its natural expiration.
• LOST — Marks the negotiation as unsuccessful, completing the Workflow with a lost outcome.
• COMPLETE_NEGOTIATION — Finalizes the negotiation phase when all parties have responded, transitioning the agreement toward acceptance and activation.

Tables Accessed

The package reads and writes the core blanket agreement tables. OE_BLANKET_HEADERS and OE_BLANKET_LINES hold the agreement header and line records whose statuses, dates, and quantities are updated at each lifecycle event. OE_ORDER_HEADERS and OE_ORDER_LINES represent the actual sales order demand created when releases are generated against the agreement; the package consults them where release validation or downstream order state is relevant. WF_ITEMS is the Oracle Workflow runtime table, used to create, query, and update the Workflow item associated with each blanket agreement, maintaining the correlation between the agreement and its in-flight process. Access occurs through APPS synonyms, consistent with standard EBS schema architecture.

Usage Notes

OE_BLANKET_WF_UTIL is not intended for direct invocation by end users or custom integrations. It is called from the Order Management Workflow definitions—the blanket agreement and negotiation processes—as the implementation behind activity functions. The Oracle Forms UI for blanket sales agreements implicitly drives these routines through those Workflow processes, and concurrent programs such as delayed request processing (OE_DELAYED_REQUESTS_PVT) may also reach into the package. Four other packages depend on it, so any modification carries broad regression risk. Custom code should interact with blanket agreements through supported public APIs rather than calling this utility package directly. In 12.1.1 and 12.2.2 alike, the object remains VALID in the APPS schema.