Search Results check_schedule_inter_entity

Overview

The APPS.AMS_CAMP_SCHEDULE_PVT package is a private PL/SQL API within the Oracle E-Business Suite Advanced Marketing (AMS) module, classified under the PVT (private) API layer. Its principal business function is to manage the scheduling of marketing campaigns — that is, the definition, maintenance, validation, and lifecycle control of campaign schedule records. A campaign schedule represents the temporal and delivery configuration associated with a campaign, including the schedule items and delivery methods that drive campaign execution.

Because it is a PVT package, AMS_CAMP_SCHEDULE_PVT is not intended for direct invocation by external or customer code. It serves as the internal implementation layer that supports the corresponding public API surface, most notably AMS_CAMP_SCHEDULE_PUB, which is documented as a direct dependent. The package encapsulates the low-level validation, locking, and persistence logic required to maintain data integrity for campaign scheduling operations across the AMS data model.

Key Procedures and Functions

The documented package exposes eleven procedures and functions. Their purposes are as follows:

• CREATE_CAMP_SCHEDULE — Creates a new campaign schedule record, initializing the schedule and persisting it to the underlying campaign schedule tables.
• UPDATE_CAMP_SCHEDULE — Modifies an existing campaign schedule record.
• DELETE_CAMP_SCHEDULE — Removes a campaign schedule record.
• LOCK_CAMP_SCHEDULE — Acquires a lock on a schedule record prior to modification, ensuring concurrency control during transactional updates.
• VALIDATE_CAMP_SCHEDULE — Performs validation of a campaign schedule, checking business-rule compliance before persistence.
• CHECK_SCHEDULE_ITEMS — Validates the individual schedule items associated with a schedule.
• VALIDATE_SCHEDULE_REC — Validates a schedule record structure.
• CHECK_SCHEDULE_INTER_ENTITY — Performs cross-entity validation, ensuring consistency between related records (for example, between a schedule and its parent campaign).
• INIT_SCHEDULE_REC — Initializes an in-memory schedule record structure, typically used before population and validation.
• COMPLETE_SCHEDULE_REC — Finalizes a schedule record structure, completing any derived or default field values before persistence.
• COPY_CAMP_SCHEDULE — Duplicates an existing campaign schedule, supporting the reuse of schedule definitions.

Tables Accessed

The package accesses the following base tables through APPS synonyms:

• AMS_CAMPAIGN_SCHEDULES_B and AMS_CAMPAIGN_SCHEDULES_B_S — The primary campaign schedule base table and its secondary (translation or supplemental) table, holding the schedule definition records created, updated, and deleted by this package.
• AMS_CAMPAIGNS_ALL_B — The campaign base table, referenced to associate schedules with their parent campaign and to validate campaign-level attributes.
• AMS_ACT_DELIVERY_METHODS — Delivery method definitions for activities, used to validate and resolve delivery configuration referenced by schedules.
• AMS_EVENT_OFFERS_ALL_B — Event offer data, referenced during schedule validation for campaign/offer relationships.
• DUAL — The standard Oracle single-row utility table, used in PL/SQL expression evaluation.
• PLITBLM — The standard PL/SQL integer table type, used internally for array or collection handling.

Usage Notes

AMS_CAMP_SCHEDULE_PVT is invoked indirectly through the AMS public API and UI layers rather than directly by end users. Its documented callers include AMS_CAMP_SCHEDULE_PUB, AMS_APPROVAL_SUBMIT_PVT, AMS_COPYELEMENTS_PVT, AMS_SCHEDULERULES_PVT, AMS_SCHEDULER_PVT, and AMS_WFTRIG_PVT. This dependency set indicates that schedule operations are triggered from campaign scheduling forms, the approval submission workflow, the scheduler and scheduling-rules engines, and workflow trigger processing.

Custom code should never call this package directly; the supported integration path is through the corresponding public API. It also depends internally on AMS_CPYUTILITY_PVT and the standard FND_API, consistent with the EBS API architecture for error handling and common utilities.