Search Results check_task_exist_for_next




Overview
Explore in AI Chat

Overview

AS_SALES_METH_WF is a PL/SQL package in the Oracle E-Business Suite APPS schema that executes the standard Sales Methodology workflow for Oracle Sales (AS) and its integration with the Oracle Workflow engine and the JTF task framework. Sales methodologies define the sequence of stages, mandatory tasks, and optional activities that an organization follows during a sales cycle. This package provides the server-side logic that starts a methodology workflow, evaluates whether tasks associated with the current or next stage have been completed, creates the actual task records required by the methodology, and produces notes documenting duration or task failures. The header of the package source (asxsmtws.pls) indicates it is an older, stable code unit with an AUTHID CURRENT_USER declaration, meaning it executes with the privileges of the calling user and relies on APPS synonyms for access to the underlying JTF and AS tables.

The user search term "create_tasks" corresponds to the CREATE_TASKS procedure, which is the central routine for materializing methodology tasks during workflow execution.

Key Procedures and Functions

The ETRM metadata documents eight procedures or functions in this package:

  • START_METHODOLOGY — Initiates the standard sales methodology workflow for a given source object, such as a lead or opportunity. It accepts identifiers for the source object, owner, current stage, next stage, template group, item type, and workflow process, and returns status, message count, message data, and a warning message.
  • CHECK_TASK_FOR_CURRENT — Evaluates whether mandatory tasks exist for the current stage and determines whether the workflow activity should complete, wait, defer, notify, or raise an error.
  • CHECK_TASK_EXIST_FOR_NEXT — Determines whether tasks are defined for the next methodology stage, typically used to decide subsequent workflow transitions.
  • CREATE_TASKS — Creates the task records for the methodology, populating the JTF task tables from the methodology task mappings. This is the procedure most commonly referenced in customizations and troubleshooting.
  • CHECK_DURATION — Verifies elapsed durations against configured thresholds, supporting escalations or notifications based on task or stage timing.
  • CREATE_NOTE_FOR_DURATION — Creates a note documenting a duration-related condition.
  • CREATE_NOTE — Generic utility for creating notes associated with methodology activities.
  • CREATE_NOTE_FOR_TASKS_FAILURE — Creates a note when task creation or completion fails, providing an audit trail of the failure.

Tables Accessed

The package reads and writes through APPS synonyms. Task data is stored in and retrieved from JTF_TASKS_B, JTF_TASK_TEMPLATES_B, and JTF_TASK_STATUSES_B. Methodology definitions are drawn from AS_SALES_METHODOLOGY_B, AS_SALES_METHODOLOGY_WF_S, AS_SALES_METH_STAGE_MAP, and AS_SALES_METH_TASK_MAP, which together describe stages, task mappings, and workflow settings. Lead data comes from AS_LEADS_ALL. Party and contact information is resolved through HZ_CONTACT_POINTS and HZ_PARTY_SITES, while resource assignments draw on JTF_RS_RESOURCE_EXTNS. Profile option values governing methodology behavior are read from FND_PROFILE_OPTIONS and FND_PROFILE_OPTION_VALUES. DUAL and PLITBLM are used for structural and utility purposes.

Usage Notes

AS_SALES_METH_WF is invoked primarily by the Oracle Sales Methodology workflow process rather than directly by end users. Workflow activities call CHECK_TASK_FOR_CURRENT and CHECK_TASK_EXIST_FOR_NEXT as function activities that return standard Workflow result codes. START_METHODOLOGY is called when a methodology is launched from the Sales application or via workflow initialization. CREATE_TASKS is executed during stage progression to generate tasks. The package is referenced by one other package in the EBS codebase, indicating limited external coupling. Custom code should not call these procedures directly unless it faithfully reproduces the expected arguments and Workflow context, as the procedures handle workflow notifications and status reporting internally. In 12.1.1 and 12.2.2 the package remains largely unchanged given its 2003 header date, and no public API designation applies.