Search Results submit_draft_internal




Overview

OE_BLANKET_WF is a workflow support package in the Oracle Order Management module of Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. It encapsulates the business logic that drives the Oracle Workflow processes attached to blanket sales agreements (blanket orders). Blanket agreements are long-term commitments between a customer and an enterprise that define pricing, items, and terms over a defined validity window; the lifecycle of such an agreement includes drafting, negotiation, activation, extension, expiration, termination, and closure.

The package functions primarily as a workflow callback library. Each of its internal procedures conforms to the standard Oracle Workflow PL/SQL procedure signature (itemtype, itemkey, actid, funcmode, resultout), allowing them to be registered as activity handlers within a workflow definition. In this role, OE_BLANKET_WF evaluates workflow state, manipulates blanket header records, and returns branch results back to the workflow engine.

Key Procedures and Functions

The workflow callback procedures, identified by the standard activity signature, include:

  • Submit_Draft_Internal — submits a blanket agreement into the draft/negotiation workflow stage.
  • Check_Negotiation_Exists — verifies whether a negotiation record exists for the blanket before allowing workflow progression.
  • Calculate_Effective_Dates — derives and validates effective start and end dates during processing.
  • Expired — evaluates whether the blanket has reached its expiration date and branches accordingly.
  • Terminate_Internal — performs the internal termination logic invoked by the workflow.
  • Close_Internal — performs the internal closure logic invoked by the workflow.

Two descriptor/utility procedures, Set_Blanket_Hdr_Descriptor and Get_Expire_Date, manage display attributes for blanket headers and retrieve expiration dates. The public API procedures, callable directly from forms or custom code, are:

  • Blanket_Date_Changed — reconciles dependent data when blanket dates are modified.
  • Submit_Draft — programmatically submits a blanket header into the draft workflow.
  • Close — closes a blanket header identified by header ID.
  • Terminate — terminates a blanket, capturing the terminating user, version, reason type, and reason code.
  • Extend, Set_Header_Attributes, Set_Header_Attributes_Internal, and Set_Final_Expiration_Date — support extension and header attribute maintenance across the agreement lifecycle.

Tables Accessed

The package operates against the following tables through APPS synonyms:

  • OE_BLANKET_HEADERS_ALL — the core blanket agreement header table, read and updated for status, dates, and attributes.
  • OE_BLANKET_HEADERS_EXT — the extension table holding supplementary header attributes updated during lifecycle transitions.
  • WF_ITEMS and WF_ITEM_ACTIVITY_STATUSES — Oracle Workflow runtime tables that track workflow item state and activity completion.
  • WF_PROCESS_ACTIVITIES — the workflow definition table used by activity handlers to resolve process context.
  • FND_USER — the application user table, referenced to resolve the user performing termination or other actions.

Usage Notes

OE_BLANKET_WF is normally invoked indirectly. The internal procedures are registered as activity handlers within the blanket agreement workflow definition in Oracle Workflow Builder, so the workflow engine calls them as a blanket moves between states. End users trigger these transitions through the Order Management blanket agreement form; the form invokes the public wrappers (Submit_Draft, Close, Terminate, Extend, Blanket_Date_Changed) rather than the internal callback versions. The package is also referenced by two other packages, indicating its use as a shared lifecycle utility. Customizations should call the public API procedures instead of the internal, workflow-signature procedures, and should be validated thoroughly in a test environment because termination and closure operations alter blanket status irreversibly. The package operates under APPS privileges and observes the standard EBS multi-org and security model enforced through the blanket header tables.