December commit

Author: artem-nesterko

BOM Calendar Exceptions/DESCRIPTION.md

@@ -0,0 +1,46 @@
+# Case Study & Technical Analysis: BOM Calendar Exceptions
+
+## Executive Summary
+The **BOM Calendar Exceptions** report provides a critical view into the working day deviations defined within Oracle Bills of Material (BOM) calendars. It lists specific dates that are exceptions to the standard work week—such as holidays, scheduled downtime, or extra working days. This visibility is essential for production planners and supply chain managers to ensure that material requirements planning (MRP) and scheduling engines accurately reflect the organization's actual capacity and availability.
+
+## Business Challenge
+In complex manufacturing environments, accurate scheduling relies heavily on the definition of working and non-working days. Organizations often face challenges such as:
+*   **Scheduling Errors:** MRP or ASCP plans generating orders on holidays or weekends because exceptions were not properly defined.
+*   **Capacity Misalignment:** Overestimating production capacity by failing to account for planned shutdowns or maintenance days.
+*   **Multi-Site Complexity:** Difficulty in auditing calendar consistency across multiple manufacturing plants with different holiday schedules.
+
+Without a consolidated view of these exceptions, planners must navigate through multiple Oracle forms to verify calendar setups, increasing the risk of oversight and scheduling conflicts.
+
+## The Solution
+The **BOM Calendar Exceptions** report solves these challenges by extracting a clear, linear list of all calendar exceptions. It allows users to:
+*   **Audit Holidays:** Quickly verify that all statutory holidays and company-specific non-working days are correctly flagged.
+*   **Verify Shift Changes:** Identify days where standard off-days (e.g., Saturdays) have been converted to working days to meet demand.
+*   **Cross-Organization Comparison:** View exceptions across multiple organizations to ensure alignment or identify discrepancies in global schedules.
+
+## Technical Architecture (High Level)
+The report is built on a direct query of the BOM calendar definition tables, linked to organization parameters.
+*   **Core Table:** `BOM_CALENDAR_EXCEPTIONS` holds the specific dates and their exception type (On/Off).
+*   **Context:** `MTL_PARAMETERS` and `HR_ALL_ORGANIZATION_UNITS_VL` provide the organization context, linking the abstract calendar code to specific inventory organizations.
+*   **Security:** The query enforces standard Oracle organization access security, ensuring users only see data for organizations they are authorized to access.
+
+## Parameters & Filtering
+The report supports the following key parameters to refine the output:
+*   **Organization Code:** Filter by specific inventory organizations to focus on a single plant or distribution center.
+*   **Calendar:** Select a specific calendar code to audit a particular schedule.
+*   **Future Only:** (Implicit capability via date filtering) Users can filter the `Exception Date` in the output to focus on upcoming schedule changes.
+
+## Performance & Optimization
+The report is highly optimized for performance:
+*   **Efficient Joins:** Uses standard primary key joins between `MTL_PARAMETERS` and `BOM_CALENDAR_EXCEPTIONS` via `CALENDAR_CODE`.
+*   **Indexed Access:** The query leverages standard indexes on `CALENDAR_CODE` and `EXCEPTION_DATE`.
+*   **Minimal Complexity:** The absence of complex calculations or subqueries ensures near-instantaneous execution even for organizations with long history.
+
+## FAQ
+**Q: What does "Exception Type" indicate?**
+A: It indicates whether the specific date is an "On" day (working day) or "Off" day (non-working day/holiday) that deviates from the standard work week pattern.
+
+**Q: Can I see exceptions for past years?**
+A: Yes, the report retrieves all exceptions defined in the system unless filtered by date.
+
+**Q: Why do I see the same calendar code for multiple organizations?**
+A: Oracle allows multiple organizations to share the same calendar definition. This report lists the organization code to show which sites are using the calendar.

BOM Calendars/DESCRIPTION.md

@@ -0,0 +1,54 @@
+# Case Study & Technical Analysis: BOM Calendars Report
+
+## Executive Summary
+The **BOM Calendars** report provides a comprehensive operational view of the manufacturing and planning calendars defined within Oracle E-Business Suite. These calendars are the backbone of supply chain planning, determining working days, shifts, and exceptions for manufacturing resources. This report offers a streamlined way to audit, validate, and visualize calendar configurations across the enterprise, ensuring that production schedules align with actual working capacity.
+
+## Business Challenge
+In complex manufacturing environments, maintaining accurate calendars is critical but often overlooked.
+*   **Scheduling Errors:** Incorrect calendar definitions (e.g., missing holidays or incorrect shift patterns) can lead to unrealistic production schedules and missed delivery dates.
+*   **Visibility Gaps:** Standard Oracle forms make it difficult to compare calendars across multiple organizations or to see a holistic view of working vs. non-working days over a long horizon.
+*   **Planning Failures:** MRP and ASCP engines rely heavily on these calendars. Discrepancies between the system calendar and the physical plant reality result in planning exceptions and material shortages.
+
+## The Solution
+The **BOM Calendars** report solves these challenges by extracting calendar definitions and their associated dates directly from the database into a flexible Excel format.
+*   **Operational View:** Users can quickly list all calendars, their start/end dates, and their assignment to specific inventory organizations.
+*   **Detailed Audit:** The report allows for expanding the view to individual calendar dates, making it easy to spot-check holidays, weekends, and exception days.
+*   **Cross-Organization Comparison:** By enabling organization details, planners can verify that all relevant plants are using the correct master calendar.
+
+## Technical Architecture (High Level)
+This report is built on a robust SQL query that joins calendar header information with detailed date records and organization assignments.
+
+### Primary Tables
+*   `BOM_CALENDARS`: Stores the header information for calendars (Code, Description, Start/End Dates).
+*   `BOM_CALENDAR_DATES`: Contains the individual dates for each calendar, indicating working or non-working status.
+*   `MTL_PARAMETERS`: Links calendars to Inventory Organizations.
+*   `HR_ALL_ORGANIZATION_UNITS_VL`: Provides human-readable organization names.
+
+### Logical Relationships
+*   The core logic starts with `BOM_CALENDARS`.
+*   It performs an **Outer Join** to `BOM_CALENDAR_DATES` to optionally retrieve the specific dates associated with each calendar.
+*   It also performs an **Outer Join** to `MTL_PARAMETERS` (and subsequently `HR_ALL_ORGANIZATION_UNITS_VL`) to identify which organizations are utilizing a specific calendar code.
+*   The query uses dynamic columns (controlled by parameters) to toggle the display of detailed date rows and organization mappings, ensuring the output is not cluttered when high-level summaries are needed.
+
+## Parameters & Filtering
+The report includes several parameters to tailor the output to specific needs:
+*   **Calendar:** Allows filtering for a specific calendar code (e.g., 'MFG-01').
+*   **Show Organizations:** A 'Yes/No' toggle. When set to 'Yes', the report lists every organization assigned to the calendar.
+*   **Organization Code:** Filters the results to show calendars associated with a specific inventory organization.
+*   **Show Dates:** A 'Yes/No' toggle. When set to 'Yes', the report expands to show every individual date record (working/non-working) for the selected range.
+*   **Future only:** Restricts the output to dates from the current day forward, useful for planning future capacity.
+
+## Performance & Optimization
+*   **Efficient Joins:** The report uses standard Oracle joins on indexed columns (`CALENDAR_CODE`, `ORGANIZATION_ID`), ensuring fast execution even with large datasets.
+*   **Dynamic Granularity:** By making the "Dates" and "Organizations" joins optional via parameters, the report avoids retrieving millions of rows of date details when only a header-level list is required.
+*   **Direct Extraction:** Data is pulled directly from the base tables, bypassing the overhead of XML parsing often found in standard Oracle reports.
+
+## FAQ
+**Q: Why don't I see any dates in the output?**
+A: Ensure the "Show Dates" parameter is set to 'Yes'. By default, the report may only show the calendar header information to keep the output concise.
+
+**Q: How can I see which organizations are using a specific calendar?**
+A: Set the "Show Organizations" parameter to 'Yes'. This will add columns for Organization Code and Name to the output.
+
+**Q: Can I use this report to find expired calendars?**
+A: Yes, the report includes `Calendar End Date`. You can filter the Excel output to find calendars that have already ended or are expiring soon.

BOM Routings/DESCRIPTION.md

@@ -0,0 +1,47 @@
+# Case Study & Technical Analysis: BOM Routings
+
+## Executive Summary
+The **BOM Routings** report is a comprehensive master data audit tool designed for manufacturing engineers and production planners. It provides a detailed breakdown of the manufacturing processes (routings) defined for items within the organization. By listing every operation step, department, and standard operation associated with an assembly, this report ensures that the "how-to" of production is accurately defined in the system, which is a prerequisite for accurate costing, scheduling, and capacity planning.
+
+## Business Challenge
+Accurate routing data is the backbone of a manufacturing execution system (MES). Organizations often struggle with:
+*   **Inaccurate Costing:** If routing operations are missing or assigned to the wrong department, labor and overhead costs will be calculated incorrectly.
+*   **Scheduling Bottlenecks:** Incorrect operation sequences or missing standard operations can lead to flawed production schedules and capacity overloads.
+*   **Obsolete Data:** Difficulty in identifying and purging routings for obsolete items or operations that are no longer in use.
+*   **Standardization Gaps:** Inconsistent application of standard operations across similar products, leading to variance in execution times.
+
+## The Solution
+The **BOM Routings** report addresses these challenges by providing a flat, exportable view of the entire routing structure. It enables users to:
+*   **Audit Process Flows:** Visualize the sequential steps (Operation Sequence) for each item to ensure logical flow.
+*   **Validate Department Assignments:** Verify that each operation is assigned to the correct work center (Department) for accurate resource loading.
+*   **Monitor Effectivity:** Identify operations that are currently active versus those that are disabled or future-dated.
+*   **Analyze Routing Types:** Distinguish between standard manufacturing routings, flow routings, and engineering prototypes.
+
+## Technical Architecture (High Level)
+The report joins the header-level routing definition with the detailed operation sequences.
+*   **Routing Header:** `BOM_OPERATIONAL_ROUTINGS` defines the parent assembly and the type of routing (Primary vs. Alternate).
+*   **Routing Details:** `BOM_OPERATION_SEQUENCES` contains the specific steps, linked to `BOM_DEPARTMENTS` and `BOM_STANDARD_OPERATIONS`.
+*   **Item Context:** `MTL_SYSTEM_ITEMS_VL` provides item descriptions and status codes to help filter out obsolete products.
+*   **Outer Joins:** The query uses outer joins for standard operations and WIP lines to ensure that custom operations or routings without specific line assignments are still reported.
+
+## Parameters & Filtering
+The report offers flexible filtering to target specific data sets:
+*   **Organization Code:** Focus on specific manufacturing plants.
+*   **Item & Description:** Search for specific assemblies or groups of products.
+*   **Excluded Item Statuses:** A critical filter to suppress inactive or obsolete items (e.g., "Obsolete", "Inactive") from the report, keeping the output focused on active production.
+
+## Performance & Optimization
+The query is designed for efficiency:
+*   **Primary Key Joins:** Utilizes the core routing sequence ID to link headers and lines.
+*   **Selective Filtering:** The `1=1` placeholder allows the Blitz Report engine to inject specific `WHERE` clauses dynamically based on user input, preventing full-table scans when specific items are requested.
+*   **Null Handling:** `NULLS FIRST` ordering on alternate designators ensures that primary routings appear at the top of the list for each item.
+
+## FAQ
+**Q: What is the difference between a "Standard" and "Flow" routing?**
+A: The report includes a `CFM_ROUTING` column that decodes the flag. "Standard" refers to traditional discrete manufacturing, while "Flow" indicates flow manufacturing processes.
+
+**Q: Why are some operation codes missing?**
+A: Not all operations are based on "Standard Operations." If an operation was manually defined on the routing without referencing a standard library code, the `Operation Code` column will be blank, but the `Operation Description` will still show the details.
+
+**Q: Does this report show resource requirements?**
+A: No, this report focuses on the operation sequence and department level. Resource requirements (labor hours, machine time) are typically found in a separate "BOM Routing Resources" report.

CAC AP Accrual Reconciliation Load Request/DESCRIPTION.md

@@ -0,0 +1,44 @@
+# Case Study & Technical Analysis: CAC AP Accrual Reconciliation Load Request
+
+## Executive Summary
+The **CAC AP Accrual Reconciliation Load Request** report is an audit and diagnostic tool designed for Cost Accountants and Finance Managers. It tracks the execution history of the "Accrual Reconciliation Load Run" program, which is a prerequisite for reconciling the Accounts Payable (AP) accrual accounts. By providing visibility into *when* the load was run, *who* ran it, and for *which* operating units, this report helps ensure that the accrual data is up-to-date before month-end reconciliation activities begin.
+
+## Business Challenge
+The AP Accrual Reconciliation process in Oracle EBS relies on a concurrent program to populate the reconciliation tables (`CST_RECONCILIATION_BUILD`). Organizations often face challenges such as:
+*   **Stale Data:** Users attempting to reconcile accounts using outdated data because the load program hasn't been run recently.
+*   **Process Visibility:** Uncertainty about whether the load program was successfully executed for a specific Operating Unit or Ledger.
+*   **Audit Compliance:** Lack of a clear audit trail showing who triggered the data refresh and when, which is critical for financial controls.
+
+## The Solution
+The **CAC AP Accrual Reconciliation Load Request** report solves these issues by providing a clear history of the load program's execution. It enables users to:
+*   **Verify Data Freshness:** Confirm the "Run To Date" to ensure the reconciliation data includes the latest transactions.
+*   **Monitor Schedule Compliance:** Check if the load program is being run according to the month-end close schedule.
+*   **Identify Process Owners:** See exactly which user (`Created_By`) initiated the request, facilitating accountability and communication.
+
+## Technical Architecture (High Level)
+The report queries the specific build history table used by the Cost Management module.
+*   **Core Table:** `CST_RECONCILIATION_BUILD` stores the history of each load request, including the build ID and date ranges.
+*   **Context:** `HR_ALL_ORGANIZATION_UNITS_VL` and `GL_LEDGERS` provide the organizational context, linking the technical build ID to business units.
+*   **Security:** The report incorporates robust security logic, respecting both Ledger Security (via `GL_ACCESS_SET_NORM_ASSIGN`) and Operating Unit Security (via `MO_GLOB_ORG_ACCESS_TMP`), ensuring users only see history for entities they are authorized to access.
+
+## Parameters & Filtering
+The report supports the following parameters:
+*   **Beginning Creation Date:** Filters the history to show only load requests created on or after a specific date, useful for focusing on the current period.
+*   **Operating Unit:** Allows filtering by specific operating units to audit a particular entity.
+*   **Ledger:** Enables filtering by the general ledger to see all related operating units.
+
+## Performance & Optimization
+The report is designed for high performance:
+*   **Direct Table Access:** It queries the build history table directly rather than calculating accruals, making it instantaneous.
+*   **Efficient Joins:** Uses standard foreign key joins between the build table, organization definitions, and user tables.
+*   **Security Profiles:** The security clauses are optimized to use standard Oracle temporary tables and profile options, ensuring consistent performance even in complex multi-org environments.
+
+## FAQ
+**Q: What is the "Build ID"?**
+A: The Build ID is a unique system-generated identifier for each execution of the Accrual Load program. It links the request to the specific set of data populated in the reconciliation tables.
+
+**Q: Why is the "Run To Date" important?**
+A: The "Run To Date" indicates the cutoff date for transactions included in that specific load. If you are reconciling for January, you need to ensure the load was run with a "Run To Date" of at least Jan 31st.
+
+**Q: Does this report show the actual accrual balance?**
+A: No, this is a metadata report about the *process* of loading data. To see the actual balances and transactions, you would use reports like "CST AP and PO Accrual Reconciliation".