December commit

Author: artem-nesterko

Blitz Upload Example (Delimited Text)/DESCRIPTION.md

@@ -0,0 +1,43 @@
+# Case Study & Technical Analysis: Blitz Upload Example (Delimited Text)
+
+## Executive Summary
+The **Blitz Upload Example (Delimited Text)** report serves as a foundational template for organizations leveraging Blitz Report™ to upload data using delimited text flat files. This tool simplifies the process of creating new data upload definitions by providing a working example that can be copied and adapted. It is designed to accelerate the development of custom data loaders, ensuring consistency and reducing the technical barrier for integrating external data into Oracle E-Business Suite.
+
+## Business Challenge
+Integrating external data into Oracle EBS often involves complex technical processes such as SQL*Loader scripts, control files, and staging tables. Business users and functional consultants frequently face challenges when:
+*   They need to upload data from simple flat files (CSV, pipe-delimited) without IT intervention.
+*   Developing custom interfaces for one-off or recurring uploads is too time-consuming and costly.
+*   There is a lack of standardized templates for handling delimited file parsing within the EBS environment.
+
+Without a streamlined approach, data entry remains manual and error-prone, or relies on ad-hoc technical solutions that are difficult to maintain.
+
+## Solution
+The **Blitz Upload Example (Delimited Text)** provides a robust, out-of-the-box solution by offering a pre-configured template for delimited file uploads.
+*   **Template-Based Development**: Users can simply copy this report (Tools > Copy Report) to initialize new upload definitions, saving significant setup time.
+*   **Flexible Parsing**: Demonstrates how to handle delimited text formats effectively within the Blitz Report framework.
+*   **Immediate Usability**: Allows for rapid deployment of new file-based integrations by modifying the target tables and mapping logic of the copy.
+
+## Technical Architecture
+This report utilizes the **Blitz Report™** architecture, which integrates directly with Oracle E-Business Suite forms and concurrent processing.
+*   **Mechanism**: The upload logic is defined within the report SQL, leveraging the `xxen_upload_example` table to demonstrate data persistence.
+*   **Integration**: It bypasses intermediate XML layers, processing data directly from the uploaded file into the database tables.
+*   **Security**: Inherits Oracle EBS security context, ensuring that uploads are performed with the appropriate user permissions and responsibilities.
+
+## Parameters
+This report is designed as a template and typically does not require complex runtime parameters for the example itself. However, when adapted, it can support standard Blitz Report parameters to filter or control the upload process.
+
+## Performance
+Blitz Report™ is engineered for high performance. By processing uploads directly within the database layer:
+*   **Low Latency**: Eliminates the overhead associated with traditional web-service or XML-based uploaders.
+*   **Scalability**: Capable of handling large delimited files efficiently, limited only by database resources.
+*   **Efficiency**: The direct-path approach ensures that data is parsed and validated rapidly.
+
+## FAQ
+**Q: Can I use this template for comma-separated (CSV) files?**
+A: Yes, the delimiter logic can be adapted to support commas, pipes, tabs, or any custom character.
+
+**Q: Do I need PL/SQL knowledge to use this?**
+A: Basic SQL knowledge is helpful for mapping the columns to your specific target tables when you copy and modify the report.
+
+**Q: Is the uploaded data validated?**
+A: Validation logic can be added to the SQL wrapper to ensure data integrity before it is committed to the production tables.

Blitz Upload Example (Interface Table)/DESCRIPTION.md

@@ -0,0 +1,43 @@
+# Case Study & Technical Analysis: Blitz Upload Example (Interface Table)
+
+## Executive Summary
+The **Blitz Upload Example (Interface Table)** is a strategic utility designed to streamline the population of Oracle EBS interface tables. It acts as a comprehensive template that allows developers and functional analysts to create new upload definitions targeting standard Oracle open interface tables. By standardizing the approach to interface table population, this report reduces development cycles and enhances the reliability of data migrations and integrations.
+
+## Business Challenge
+Populating Oracle Interface tables (e.g., for Journal Import, Item Import, or Invoice Import) is a critical step in many business processes. However, organizations often struggle with:
+*   **Complexity**: Writing custom PL/SQL wrappers or SQL*Loader scripts for every new interface is inefficient.
+*   **Data Quality**: Manual inserts into interface tables lack validation and traceability.
+*   **Maintenance**: Custom scripts are often scattered and hard to version control or update when interface definitions change.
+
+These challenges lead to delays in data processing and increased risk of data corruption during imports.
+
+## Solution
+This report provides a standardized, reusable template for uploading data to interface tables via **Blitz Report™**.
+*   **Rapid Deployment**: Users can copy this report to quickly configure uploads for any Oracle interface table (e.g., `GL_INTERFACE`, `MTL_SYSTEM_ITEMS_INTERFACE`).
+*   **User-Friendly**: Enables Excel-based data preparation and upload, a format familiar to business users.
+*   **Automation**: Can be linked with concurrent requests to automatically trigger the standard Oracle import program after the interface table is populated.
+
+## Technical Architecture
+The solution leverages the native capabilities of Oracle EBS and Blitz Report™:
+*   **Direct Interface Access**: Writes directly to the specified interface tables using efficient SQL bulk operations.
+*   **Database Integration**: Operates entirely within the Oracle database, ensuring compatibility with all EBS versions.
+*   **Table Usage**: The example references `xxen_upload_example` but is intended to be repointed to standard interface tables like `AP_INVOICES_INTERFACE` or `GL_INTERFACE` in production scenarios.
+
+## Parameters
+*   **Name**: A descriptive parameter to identify the upload batch or specific run details.
+
+## Performance
+The **Blitz Upload Example (Interface Table)** is optimized for speed and reliability:
+*   **Bulk Processing**: Capable of inserting thousands of records into interface tables in seconds.
+*   **Minimal Overhead**: Avoids the performance penalties of row-by-row processing or external API calls.
+*   **Resource Efficiency**: Runs within the concurrent manager, utilizing existing server capacity without requiring additional infrastructure.
+
+## FAQ
+**Q: Can this trigger the standard import program automatically?**
+A: Yes, Blitz Report allows you to configure "After Report" triggers to submit standard concurrent requests (like Journal Import) immediately after the upload.
+
+**Q: Is it safe to write directly to interface tables?**
+A: Yes, interface tables are designed by Oracle as the public gateway for data import. This tool simply automates the population of those tables.
+
+**Q: How does it handle errors?**
+A: Errors during the upload to the interface table are reported immediately. Validation errors generated by the standard Oracle import program can be viewed in the standard import output or error tables.

Blitz Upload History/DESCRIPTION.md

@@ -0,0 +1,44 @@
+# Case Study & Technical Analysis: Blitz Upload History
+
+## Executive Summary
+The **Blitz Upload History** report is a critical governance and auditing tool for organizations utilizing Blitz Report™ for data uploads. It provides a comprehensive audit trail of all data upload activities, ensuring transparency and accountability. By tracking who uploaded what data and when, this report supports compliance requirements and helps system administrators monitor system usage and data lineage.
+
+## Business Challenge
+As organizations democratize data entry and updates through Excel-based uploads, maintaining control and visibility becomes paramount. Common challenges include:
+*   **Lack of Traceability**: Identifying the source of data changes when multiple users have upload privileges.
+*   **Compliance Risks**: Auditors require proof of who authorized and executed data changes in the ERP system.
+*   **Data Retention Management**: Managing the growth of upload history data to prevent unnecessary storage consumption.
+
+Without a centralized history, organizations risk losing oversight of bulk data changes, leading to potential security and data integrity issues.
+
+## Solution
+The **Blitz Upload History** report addresses these challenges by offering a detailed view of the upload log.
+*   **Full Audit Trail**: Captures the Upload Name, User, Date, and Status for every transaction.
+*   **Retention Policy Support**: Works in conjunction with the profile option `Blitz Upload Data Retention Days` to manage how long history is kept, balancing audit needs with storage optimization.
+*   **Searchability**: Allows administrators to quickly find specific uploads by name, date range, or user.
+
+## Technical Architecture
+This report queries the internal metadata tables of the Blitz Report™ framework:
+*   **Core Tables**: Joins `xxen_upload_data`, `xxen_report_runs`, and `xxen_reports_v` to reconstruct the upload event context.
+*   **Security Integration**: Links with `fnd_responsibility_tl` and `fnd_concurrent_requests` to provide context on the responsibility and concurrent request ID associated with each upload.
+*   **LOB Handling**: References `fnd_lobs` to potentially link back to the original uploaded file content if configured.
+
+## Parameters
+*   **Upload Name**: Filter by the specific name of the upload definition.
+*   **Started within Days**: Limits the report to recent uploads (e.g., last 30 days) for focused auditing.
+*   **Uploaded By**: Filter by the specific user ID or name who performed the upload.
+
+## Performance
+Designed for administrative oversight, the report is highly efficient:
+*   **Indexed Queries**: Utilizes standard indexes on the `xxen_` tables to ensure fast retrieval even with large history logs.
+*   **Optimized Joins**: Efficiently joins with FND tables to resolve user and responsibility names without performance drag.
+
+## FAQ
+**Q: How long is upload history kept?**
+A: The retention period is controlled by the system profile option `Blitz Upload Data Retention Days`. Records older than this setting are automatically purged.
+
+**Q: Can I see the actual data that was uploaded?**
+A: Yes, if the system is configured to retain the file, the history can link back to the specific data set processed.
+
+**Q: Does this report show failed uploads?**
+A: Yes, the status column indicates whether an upload was successful, failed, or completed with warnings.

CAC Inactive Items Set to Roll Up/DESCRIPTION.md

@@ -0,0 +1,46 @@
+# Case Study & Technical Analysis: CAC Inactive Items Set to Roll Up
+
+## Executive Summary
+The **CAC Inactive Items Set to Roll Up** report is a specialized inventory and costing diagnostic tool designed to ensure the accuracy of standard cost rollups. It identifies a specific data quality issue where items marked as "Inactive" are still flagged to be included in cost rollups. By detecting these inconsistencies, the report helps organizations prevent invalid or obsolete items from distorting product costs and inventory valuations.
+
+## Business Challenge
+In Oracle EBS Cost Management, the "Based on Rollup" flag determines if an item's cost is calculated during a standard cost rollup. A common configuration error occurs when an item is retired (set to Inactive status) but the "Based on Rollup" flag remains set to "Yes".
+*   **Distorted Costs**: Inactive items might retain old, incorrect costs that get rolled up into parent assemblies, leading to inaccurate finished good costs.
+*   **Processing Overhead**: The cost rollup process wastes resources calculating costs for items that are no longer in use.
+*   **Data Inconsistency**: Contradictory settings (Inactive vs. Rollup=Yes) confuse users and complicate data maintenance.
+
+## Solution
+This report provides a targeted exception list to proactively manage item master data quality.
+*   **Exception Reporting**: Filters specifically for items where `Inventory_Item_Status_Code` indicates inactivity (default 'Inactive') but `Based_on_Rollup` is enabled.
+*   **Multi-Org Visibility**: Can be run across multiple inventory organizations, operating units, and ledgers to identify widespread issues.
+*   **Actionable Output**: Provides the Item Number, Organization, and Category details needed to quickly locate and correct the master data.
+
+## Technical Architecture
+The report is built on a robust SQL query that joins key Inventory and Costing tables:
+*   **Primary Tables**: `mtl_system_items_vl` (Item Master), `cst_item_costs` (Cost Details), and `mtl_item_status_vl` (Status Definitions).
+*   **Security**: Implements standard Oracle EBS security (Operating Unit and Inventory Org access) via `org_access_view` and `mo_glob_org_access_tmp`.
+*   **Logic**: The core logic compares the item's status against the user-provided "Inactive Item Status" parameter and checks the rollup flag.
+
+## Parameters
+*   **Cost Type**: (Mandatory) The cost type to analyze (e.g., Frozen, Pending).
+*   **Inactive Item Status**: (Mandatory) The status code representing inactive items (default: 'Inactive').
+*   **Category Set 1 & 2**: (Optional) Filter by specific item categories (e.g., Cost Category, Product Line).
+*   **Item Number**: (Optional) Analyze a specific item.
+*   **Organization Code**: (Optional) Limit to a specific inventory organization.
+*   **Operating Unit**: (Optional) Filter by Operating Unit.
+*   **Ledger**: (Optional) Filter by General Ledger.
+
+## Performance
+The report is optimized for large item masters:
+*   **Selective Filtering**: By filtering on Cost Type and Item Status early in the execution plan, it minimizes the data set processed.
+*   **Efficient Joins**: Uses standard keys (Inventory_Item_Id, Organization_Id) for high-performance joins between Item and Cost tables.
+
+## FAQ
+**Q: Why does an inactive item affect my rollup?**
+A: If an inactive item is a component in an active Bill of Material (BOM) and "Based on Rollup" is Yes, the rollup process will attempt to cost it, potentially using outdated purchase prices or routing data.
+
+**Q: How do I fix the items identified?**
+A: You should update the Item Master for these items, unchecking the "Based on Rollup" flag in the Costing tab.
+
+**Q: Can I use this for statuses other than 'Inactive'?**
+A: Yes, the "Inactive Item Status" parameter allows you to check for any status code (e.g., 'Obsolete', 'Phase-Out').

CAC Intercompany Relationship Setup/DESCRIPTION.md

@@ -0,0 +1,39 @@
+# Case Study & Technical Analysis: CAC Intercompany Relationship Setup
+
+## Executive Summary
+The **CAC Intercompany Relationship Setup** report provides a comprehensive visualization of the intercompany accounting configuration within Oracle E-Business Suite. It details the complex web of relationships, transaction flows, and account mappings between different operating units and inventory organizations. This report is essential for Finance and Supply Chain teams to verify that intercompany transactions will be accounted for correctly, ensuring accurate financial consolidation and reconciliation.
+
+## Business Challenge
+Intercompany transactions (e.g., shipping from one legal entity to another) require precise setup in Oracle Inventory and Intercompany Invoicing.
+*   **Configuration Complexity**: The setup involves multiple screens (Intercompany Relations, Shipping Networks, Transaction Flows) and is prone to human error.
+*   **Reconciliation Nightmares**: Incorrect account mappings can lead to imbalances between Intercompany Receivables (AR) and Payables (AP), causing month-end close delays.
+*   **Visibility Gap**: There is no standard Oracle report that provides a holistic view of the entire intercompany topology and associated GL accounts in a single output.
+
+## Solution
+This report bridges the visibility gap by extracting and consolidating intercompany setup data.
+*   **Holistic View**: Displays the "From" and "To" Operating Units, the specific Inventory Organizations involved, and the Transaction Flow types.
+*   **Account Verification**: Lists the specific GL accounts (COGS, Accrual, Receivables, Payables) configured for each relationship.
+*   **Customer/Vendor Mapping**: Validates the mapping of internal Customers and Vendors required for Intercompany Invoicing.
+
+## Technical Architecture
+The SQL logic navigates the complex schema of Oracle Intercompany setup:
+*   **Data Sources**: Queries `mtl_intercompany_parameters`, `mtl_transaction_flow_headers`, and `mtl_transaction_flow_lines`.
+*   **Entity Resolution**: Joins with `hr_all_organization_units_vl` for Operating Unit names and `mtl_parameters` for Inventory Organization details.
+*   **Trading Partners**: Links to `po_vendors` and `hz_parties` to show the trading partner definitions associated with the intercompany flows.
+
+## Parameters
+*   **None**: The report is designed to dump the complete intercompany configuration for the accessible entities, providing a full system landscape view.
+
+## Performance
+*   **Lightweight Execution**: As a configuration report, it queries setup tables which are generally small in volume compared to transaction tables.
+*   **Fast Retrieval**: Returns results almost instantly, making it an excellent tool for ad-hoc troubleshooting during setup or testing phases.
+
+## FAQ
+**Q: Does this report show the actual intercompany transactions?**
+A: No, this is a *setup* validation report. It shows how the system is configured to handle transactions, not the transactions themselves.
+
+**Q: Why are some accounts missing in the output?**
+A: If accounts are missing, it indicates a gap in the Oracle setup. This report highlights those gaps so they can be fixed before transactions occur.
+
+**Q: Does it cover Advanced Accounting (Transaction Flows)?**
+A: Yes, the report includes logic to display Advanced Accounting options derived from `mtl_transaction_flows_v`.