Search Results delete_competitors

Overview

AS_OPPORTUNITY_PUB_W3 is a public PL/SQL API package in the Oracle E-Business Suite (EBS) Applications Technology layer, owned by APPS and defined with AUTHID CURRENT_USER. It belongs to the Oracle Sales / Sales Foundation (AS) product family and provides the multi-row ("bulk" or table-based) interface for maintaining competitor and decision factor information associated with sales opportunities. In the Oracle EBS 12.1.1 and 12.2.2 architectures, the AS_OPPORTUNITY_PUB family is split across numbered wrapper packages (W1, W2, W3, and so on); this particular package (W3) exposes the competitive-analysis and decision-factor maintenance surface for the TCA/JTF-based opportunity model.

The package is classified in the ETRM repository as OTHER, meaning it is a supporting internal API rather than a primary public business interface intended for broad external consumption, though it remains callable from forms, concurrent programs, and custom code. It uses PL/SQL collection types from the JTF table-type library (JTF_DATE_TABLE, JTF_NUMBER_TABLE, JTF_VARCHAR2_TABLE_100, JTF_VARCHAR2_TABLE_200, JTF_VARCHAR2_TABLE_300) to pass arrays of values for bulk insert, update, and delete operations.

Key Procedures and Functions

The package exposes eight documented procedures, all dealing with competitors, competitor products, and decision factors:

• UPDATE_COMPETITORS — The signature procedure shown in the source excerpt. It updates competitor records for an opportunity identified by p_identity_salesforce_id, accepting dozens of parallel JTF table parameters plus validation, access-control, admin, and partner-contact flags. It returns standard x_return_status, x_msg_count, and x_msg_data outputs.
• DELETE_COMPETITORS — Removes competitor records from an opportunity. This is the procedure users reach when searching for "delete_competitors" against this package, and it operates on the same identity/access-control model as UPDATE_COMPETITORS.
• CREATE_COMPETITOR_PRODS — Creates competitor-product association lines linking competitors to the products they offer.
• UPDATE_COMPETITOR_PRODS — Modifies existing competitor-product records.
• DELETE_COMPETITOR_PRODS — Deletes competitor-product records, typically invoked through the same competitive-analysis UI flow as the competitor deletions.
• CREATE_DECISION_FACTORS — Creates decision factor records that capture the criteria influencing an opportunity outcome.
• UPDATE_DECISION_FACTORS — Modifies decision factor records.
• DELETE_DECISION_FACTORS — Removes decision factor records.

Because the ETRM metadata does not enumerate parameter lists for the other seven procedures, they should not be assumed to mirror UPDATE_COMPETITORS exactly; however, the naming and grouping strongly imply a consistent create/update/delete pattern over the same logical entities.

Tables Accessed

The ETRM extract does not list explicit table references; the package reaches its data through APPS synonyms. Based on the AS schema and the entities it manipulates, these are expected to include the competitor table (AS_COMPETITORS) and competitor-product intersection (AS_COMPETITOR_PRODUCTS), the decision factor table (AS_DECISION_FACTORS), and the opportunity header/key tables used to resolve p_identity_salesforce_id (AS_OPPORTUNITIES and related TCA party structures). Access-control logic implied by p_check_access_flag, p_admin_flag, p_admin_group_id, and p_partner_cont_party_id typically consults JTF access/group membership views. Reads and writes occur through the APPS schema under standard EBS security, consistent with AUTHID CURRENT_USER.

Usage Notes

AS_OPPORTUNITY_PUB_W3 is invoked primarily from Oracle Sales application forms and from the bulk-processing layers that back them, where users add or remove competitors and decision factors on an opportunity. Custom integrations should call the procedures only after fully populating the JTF collection types, since mismatched array cardinalities will raise errors. The procedures follow the EBS standard API contract: check x_return_status for FND_API.G_RET_STS_SUCCESS/ERROR, loop over x_msg_count using FND_MSG_PUB, and pass p_init_msg_list as FND_API.G_TRUE to reset the message stack. The p_commit flag governs transaction control, so callers embedding these procedures in a larger transaction should pass FND_API.G_FALSE and commit themselves. In 12.1.1 and 12.2.2 the signature and JTF types are unchanged; no online patching differences apply. Direct use is not supported by Oracle in the same way as the primary AS_OPPORTUNITY_PUB entry points, so custom code should prefer supported public APIs where one exists.