Search Results copy_type

Overview

BOM_COPY_CALENDAR is a PL/SQL package body in the APPS schema that supports calendar and shift maintenance within Oracle EBS manufacturing. Its purpose is to copy calendar structures—workday patterns, shift definitions, shift times, and calendar or shift exceptions—from a source calendar to a destination calendar, optionally constrained to a specific date range or shift number. The package also provides cleanup procedures that remove cancelled exceptions from calendars and shifts. In the context of Oracle Bills of Material and Work in Process, calendars drive scheduling, capacity planning, lead-time calculations, and shop-floor resource availability, so the ability to replicate an existing calendar accelerates setup when new organizations, resources, or production calendars are introduced. The header comment (revision 115.1, dated 1999) indicates the package has been stable since the earlier releases of the product and is carried forward into 12.1.1 and 12.2.2 without functional redesign.

Key Procedures and Functions

ETRM documents three public procedures on the package:

• COPY_CALENDAR — The primary entry point. It orchestrates the copy of calendar-level and shift-level data from a source calendar to a target calendar, accepting user context and delegating to the private copy subprograms.
• DROP_CAL_CANCELLED_EXCEPTS — Removes calendar exception records that have been marked as cancelled, allowing obsolete or superseded exceptions to be purged.
• DROP_SHIFT_CANCELLED_EXCEPTS — Performs the equivalent purge for exceptions defined at the shift level.

The excerpt additionally exposes the private subprograms that COPY_CALENDAR coordinates: Copy_Cal_Workday_Patterns, Copy_Shift_Workday_Patterns, Copy_Cal_Exceptions, Copy_Cal_All_Shifts, Copy_Cal_Spec_Shift, Copy_Shift_Times, Copy_Shift_Exceptions, Copy_Exceptions_Cal, Copy_Shift_Exceptions_Cal, and Copy_Exceptions_Shift. These routines each carry a source calendar code, a target calendar code, an optional shift number, a date range, and a user ID, which collectively define the scope of the copy operation. The "copy_type" search term aligns with this design: the caller selects which category of calendar data—workday patterns, shifts, shift times, or exceptions—is replicated by invoking the corresponding subprogram through COPY_CALENDAR.

Tables Accessed

The package reads and writes the following base tables through APPS synonyms:

• BOM_WORKDAY_PATTERNS — stores the recurring workday pattern for a calendar; copied when the pattern must be reproduced in the target calendar.
• BOM_CALENDAR_SHIFTS — holds the shift definitions belonging to a calendar; copied for all shifts or a specified shift.
• BOM_SHIFT_TIMES — contains the start and end times that define individual shift intervals; copied to preserve shift timing.
• BOM_CALENDAR_EXCEPTIONS — records calendar-level exceptions such as holidays or non-working days; copied and purged by the drop routine.
• BOM_SHIFT_EXCEPTIONS — records shift-level exceptions; copied and purged by the corresponding drop routine.
• BOM_EXCEPTION_SETS and BOM_EXCEPTION_SET_DATES — define exception sets and their applicable dates, used when exceptions are copied from a named exception set rather than from another calendar.

Usage Notes

BOM_COPY_CALENDAR is an internal application-programming interface rather than a documented public API; ETRM classifies it as OTHER and records no dependent packages, confirming it sits at the lower layers of the calendar maintenance stack. It is most commonly invoked indirectly from the Oracle Bills of Material or Work in Process calendar maintenance forms, where a user chooses a source calendar and requests a copy, and from concurrent programs that populate calendar data during implementation or organization setup. Custom code may call COPY_CALENDAR directly when bulk-provisioning calendars, but should supply valid source and target calendar codes and a user ID, and must observe the date-range parameters so that exception copies remain bounded. Because the drop procedures physically delete cancelled exception rows, they should be invoked only after confirming that the cancelled exceptions are no longer required for audit or reporting.