December commit

Author: artem-nesterko

BOM Common Bill of Materials Upload/DESCRIPTION.md

@@ -0,0 +1,49 @@
+# BOM Common Bill of Materials Upload
+
+## Description
+The upload can be used to create Common BOM from the BOMS defined in the specified source organization in one or more target organizations as determined by the Scope Parameter:
+
+All - All Organizations 
+BOMs will made Common to all other Organizations that share the same Master Organization as the Source Organization and to which the current responsibility has access to.
+ 
+Hierarchy – Organization Hierarchy
+BOMs will made Common to all Organizations the current responsibility has access to and which are below the Source Organization in the specified Hierarchy.
+
+Organization – Specific Organizations
+BOMs will be made Common to the specified Target Organizations. The Target Organizations must share the same Master Organization as the Source Organization.
+
+Unlike the Oracle standard Create Common BOM process which requires all sub-component BOMS and substitute component BOMs to be made common individually, this upload process will iterate through the sub-assemblies and substitute assemblies and make them common in the Target Organization if they have not already been defined.
+
+A prerequisite however, as with the BOM Bill of Materials Upload (Amazon), is that all the items are already assigned in the Target Organization.
+
+If any component Items are not defined in the Target Organization, these will be identified in the upload Excel.
+
+Usage
+=====
+- Specify the Source Organization in which the BOMS are defined
+- Specify the Scope to determine the Target Organizations
+- Use the Report Parameters to select the BOMS to be made common
+- The generated Excel will contain one row per BOM and Target Organization combination
+
+- The generated Excel Identifies if the BOM Item is defined in the Target Organization, if it already exists as a BOM in the Target Organization, if it is a Common BOM in the target organization already, and if the BOM has any component items which are not defined in the Target Organization. These will prevent the BOM upload process from attempting to make the BOM common in the target organization.
+
+- In the generated Excel, set the ‘Create Common Bom’ column to Yes against the BOM/Target Organization combinations to be made Common.
+- Save and upload the Excel to process the selections made back into Oracle
+- After upload, a new Excel is generated showing the success/error status of the creation of the Common BOMS in each target organization.
+
+Templates
+=========
+Common BOM Upload Template
+In this template, the user must review and manually select the BOM/Target Organization combinations to be made Common. Setting the ‘Create Common Bom’ flag against a BOM/Target Organization combination will trigger the row for update and processing during upload.
+
+Automatic Common BOM Upload Template
+In this template, the excel is generated with the ‘Create Common Bom’ flag set against all BOM/Target Organization combinations and the rows already flagged for update and processing. In this template the user can opt out of creating a common BOM for specific BOM/Target Organization combinations by either de-selecting (clearing) the ‘Create Common Bom’ flag column or by deleting the row from the spreadsheet. 
+
+## Parameters
+Source Organization Code, Common BOM Scope, Target Hierarchy, Target Organization, Enable Attributes Update, Assembly, Alternate BOM, Show Sub-Assemblies, Show Missing BOMS only, Auto Populate Upload Columns, Implemented Only, Display, Effective Date
+
+## Used tables
+bom_bill_of_materials, bom_inventory_components, mtl_parameters, mtl_system_items_kfv, mtl_system_items_vl, bom_tree, bom_substitute_components, bom, org_access_view, bom_subst
+
+## Categories
+Enginatics, Upload

BOM Item Where Used GUI/DESCRIPTION.md

@@ -0,0 +1,16 @@
+# BOM Item Where Used GUI
+
+## Description
+Item Where Used GUI Report
+
+Provides equivalent functionality to the the following standard reports:
+- Item Where Used Report GUI
+
+## Parameters
+Application, Organization Code, All Organizations, Organization Hierarchy, Item, Item Type, Exclude Item Type, Revision, Item From, Item To, Category Set, Category From, Category To, Levels To Implode, Implemented Only, Display Option, Date, Top Assemblies Only
+
+## Used tables
+mtl_system_items_vl, mtl_item_flexfields, bom_implosion_view
+
+## Categories
+Enginatics

Blitz Report Parameter Bind Variable Validation/DESCRIPTION.md

@@ -0,0 +1,43 @@
+# Case Study & Technical Analysis: Blitz Report Parameter Bind Variable Validation
+
+## Executive Summary
+The **Blitz Report Parameter Bind Variable Validation** is a specialized diagnostic tool for developers and administrators managing the Blitz Report environment. It performs a structural integrity check on report parameters, specifically focusing on the usage of SQL bind variables (e.g., `:organization_id`). This report ensures that every bind variable defined in a parameter's SQL logic is correctly mapped and that no variables are left undefined, preventing runtime errors during report execution.
+
+## Business Challenge
+As Oracle EBS environments grow, the library of custom reports expands. Complex reports often use dynamic parameters where one parameter's list of values (LOV) depends on another (e.g., selecting a "Batch" depends on the selected "Organization").
+*   **Development Errors:** Developers may copy-paste SQL code and forget to update bind variable names, leading to "Invalid Column" or "Missing Expression" errors.
+*   **Maintenance Overhead:** Troubleshooting a report that fails only when specific parameters are selected can be time-consuming.
+*   **Quality Assurance:** Manually verifying the SQL logic for hundreds of reports is impossible.
+
+## Solution
+This report automates the quality assurance process for report parameters.
+*   **Bind Variable Mapping:** It parses the SQL text of parameter definitions to identify all bind variables and verifies their assignment.
+*   **Error Detection:**
+    *   **Missing Binds:** Identifies parameters where a bind variable is used in the SQL but not defined in the report setup.
+    *   **Multiple Binds:** Highlights complex parameters that use multiple bind variables, which are higher-risk areas for logic errors.
+*   **Proactive Maintenance:** Allows administrators to scan the entire library (or specific categories) to catch issues before end-users encounter them.
+
+## Technical Architecture
+The report operates on the Blitz Report metadata layer, specifically the `XXEN_REPORT_PARAMETERS_V` and `XXEN_REPORT_PARAMETERS_LINK_V` views.
+*   **Metadata Parsing:** It analyzes the `SQL_TEXT` column of the parameter definitions.
+*   **Logic:** It compares the bind variables found in the text (strings starting with `:`) against the registered parameter names.
+
+## Parameters & Filtering
+*   **Category:** Filter by report category (e.g., "General Ledger", "Order Management") to validate specific functional areas.
+*   **Report Name:** Validate a single specific report.
+*   **Parameters with missing :binds:** (Flag) Set to 'Yes' to only show parameters that have detected issues.
+*   **Parameters with multiple :binds:** (Flag) Set to 'Yes' to focus on complex parameters that require multiple inputs.
+
+## Performance & Optimization
+*   **Execution:** Very fast, as it queries the local metadata tables which are typically small compared to transaction tables.
+*   **Usage:** Recommended to be run periodically by the development team, especially after migrating reports between environments.
+
+## FAQ
+**Q: What is a "Bind Variable" in this context?**
+A: A bind variable is a placeholder in a SQL query (e.g., `WHERE organization_id = :org_id`) that gets replaced with a user-selected value at runtime.
+
+**Q: Can this report fix the errors automatically?**
+A: No, it is a diagnostic tool. It identifies the mismatch, but a developer must manually open the Blitz Report definition and correct the parameter SQL or assignment.
+
+**Q: Why does it flag parameters with "multiple binds"?**
+A: While not necessarily an error, parameters with multiple binds (e.g., dependent on both Ledger and Period) are complex and prone to logic errors. Reviewing them ensures they are working as intended.

Blitz Report Parameter Comparison between environments/DESCRIPTION.md

@@ -0,0 +1,57 @@
+# Case Study: Blitz Report Parameter Comparison between environments
+
+## Executive Summary
+The **Blitz Report Parameter Comparison between environments** report is a specialized diagnostic tool designed for Oracle E-Business Suite administrators and developers. It facilitates the comparison of Blitz Report parameters between the local database instance and a remote environment. This tool is crucial for maintaining configuration consistency across Development, Test, and Production environments, ensuring that report definitions remain synchronized and functional throughout the release lifecycle.
+
+## Business Challenge
+In a multi-environment Oracle EBS landscape, keeping report definitions aligned is a significant challenge. As reports are developed and promoted, parameter definitions—including default values, lists of values (LOVs), and validation logic—can drift.
+- **Configuration Drift**: Discrepancies between environments can lead to reports failing or producing incorrect data after migration.
+- **Manual Validation**: Manually checking hundreds of parameters across environments is time-consuming and prone to human error.
+- **Troubleshooting**: Identifying why a report works in "Test" but fails in "Production" often requires a detailed comparison of the underlying parameter setups.
+
+## Solution
+This report automates the validation process by querying and comparing parameter metadata from the local environment against a target remote database.
+- **Automated Comparison**: Instantly identifies differences in parameter attributes such as SQL text, default values, and LOV definitions.
+- **Targeted Analysis**: Users can filter comparisons by Report Category or specific Report Names to focus on relevant changes.
+- **Exception Reporting**: The "Show Differences only" parameter allows users to filter out matching records, highlighting only the discrepancies that require attention.
+
+## Technical Architecture
+The report operates by querying the `xxen_report_parameters_v` view locally and comparing it with data from a remote database.
+
+### Remote View Requirement
+To successfully run this comparison and avoid the `ORA-64202: remote temporary or abstract LOB locator is encountered` error, a specific view must be created on the remote environment. This view handles CLOB data types (like SQL text) by converting them to a format suitable for remote querying.
+
+**Required Remote View Definition:**
+```sql
+create or replace view xxen_report_parameters_v_ as
+select
+xrpv.*,
+dbms_lob.substr(xxen_util.clob_substrb(xrpv.sql_text,4000,1)) sql_text_short,
+dbms_lob.substr(xxen_util.clob_substrb(xrpv.lov_query,4000,1)) lov_query_short,
+length(xrpv.sql_text) sql_length,
+count(*) over (partition by xrpv.report_id) parameter_count
+from
+xxen_report_parameters_v xrpv;
+```
+
+### Key Views and Tables
+- **`xxen_report_parameters_v`**: The primary source of parameter definitions in the local environment.
+- **`xxen_report_parameters_v_`**: The custom view required on the remote environment to facilitate LOB handling over a database link.
+- **`fnd_user`**: Used to identify user-specific configurations or updates.
+
+## Parameters
+The report accepts the following parameters to refine the comparison scope:
+- **Remote Database**: Specifies the target environment for comparison (typically a database link).
+- **Category**: Filters the comparison to a specific group of reports (e.g., "Enginatics", "Finance").
+- **Report Name like**: Allows wildcard searching for specific report titles.
+- **Show Differences only**: A boolean flag to suppress matching rows and display only parameters with discrepancies.
+
+## Performance
+Performance is largely dependent on the network latency between the local and remote databases. The use of the optimized `xxen_report_parameters_v_` view ensures that LOB data is handled efficiently, preventing common errors associated with querying CLOBs over database links.
+
+## FAQ
+**Q: Why do I get an ORA-64202 error?**
+A: This error occurs if the remote environment does not have the `xxen_report_parameters_v_` view installed. This view is necessary to handle LOB locators correctly across the network.
+
+**Q: Can I compare standard Oracle Concurrent Program parameters with this tool?**
+A: No, this tool is specifically designed for **Blitz Report** parameters.

Blitz Report Parameter Comparison between reports/DESCRIPTION.md

@@ -0,0 +1,37 @@
+# Case Study: Blitz Report Parameter Comparison between reports
+
+## Executive Summary
+The **Blitz Report Parameter Comparison between reports** is a developer utility designed to analyze and compare the parameter definitions of two distinct Blitz Reports within the same Oracle E-Business Suite environment. This tool is particularly useful for version control, debugging, and standardizing report definitions across the application.
+
+## Business Challenge
+In complex Oracle EBS environments, report developers often create new reports by cloning existing ones or maintaining multiple versions of similar reports (e.g., "Sales Report Summary" vs. "Sales Report Detail"). Over time, these reports can diverge in subtle ways:
+- **Inconsistent Logic**: Parameter validation logic (LOVs) might be updated in one report but missed in the other.
+- **Version Control**: Tracking changes between a "Draft" version and a "Final" version of a report can be difficult without a direct comparison tool.
+- **Debugging**: If two seemingly identical reports produce different results, the root cause is often a minor discrepancy in parameter default values or bind variables.
+
+## Solution
+This report provides a side-by-side comparison of all parameters for two selected reports.
+- **Direct Comparison**: Users simply select "Report Name1" and "Report Name2" to generate a detailed matrix of their parameters.
+- **Attribute Analysis**: The report compares critical attributes such as Parameter Name, Display Sequence, SQL Text (for LOVs), Default Values, and Validation logic.
+- **Difference Highlighting**: The "Show Differences only" option filters out identical parameters, allowing developers to focus exclusively on what has changed or what is different.
+
+## Technical Architecture
+The report utilizes the Blitz Report metadata repository, specifically the `xxen_report_parameters_v` view. It executes a comparison query that aligns parameters from both source reports based on their sequence or name, flagging any discrepancies in their definitions.
+
+### Key Views
+- **`xxen_report_parameters_v`**: The primary view containing all parameter definitions for Blitz Reports.
+
+## Parameters
+- **Report Name1**: The name of the first report to be compared (Source A).
+- **Report Name2**: The name of the second report to be compared (Source B).
+- **Show Differences only**: A flag to suppress matching rows. When set to 'Yes', the output will only display parameters that exist in one report but not the other, or parameters where attributes (like the LOV query) differ.
+
+## Performance
+This report runs instantaneously as it queries the local metadata tables. It is highly optimized for quick developer feedback loops.
+
+## FAQ
+**Q: Can I compare a Blitz Report with a standard Oracle Concurrent Program?**
+A: No, this tool is designed to compare two Blitz Reports.
+
+**Q: Does it compare the main report SQL as well?**
+A: This specific report focuses on **Parameters**. For comparing the main report SQL or columns, other tools in the "Blitz Report" category (like "Blitz Report SQL Validation" or "Blitz Report Comparison") may be more appropriate.

Blitz Report Parameter Custom LOV Duplication Validation/DESCRIPTION.md

@@ -0,0 +1,35 @@
+# Case Study: Blitz Report Parameter Custom LOV Duplication Validation
+
+## Executive Summary
+The **Blitz Report Parameter Custom LOV Duplication Validation** is a maintenance and optimization tool for Oracle E-Business Suite. It identifies opportunities to refactor and streamline report definitions by detecting redundant custom List of Values (LOV) queries. The goal is to promote the use of shared LOVs, reducing maintenance overhead and ensuring consistency across the reporting landscape.
+
+## Business Challenge
+In the lifecycle of report development, it is common for developers to define "Custom" LOVs directly within a report parameter using a specific SQL query. Over time, the same SQL logic (e.g., "Select all active Cost Centers") might be pasted into dozens of different reports.
+- **Maintenance Nightmare**: If the business logic for "Active Cost Centers" changes, developers must manually locate and update every single report that uses that specific SQL snippet.
+- **Inconsistency**: If one report is updated and another is missed, users will see different lists of values for the same business concept.
+- **Redundant Storage**: Storing the same SQL text multiple times bloats the metadata repository.
+
+## Solution
+This report scans the Blitz Report metadata repository to identify parameters that use **identical SQL queries** for their LOVs but are not linked to a shared LOV definition.
+- **Identification**: It lists all parameters where the LOV query text is duplicated across multiple reports or parameters.
+- **Recommendation**: The output serves as a "to-do" list for developers to create a single, shared LOV (e.g., "GL Active Cost Centers") and link all identified parameters to it.
+- **Standardization**: Encourages a "define once, use many" architecture.
+
+## Technical Architecture
+The report analyzes the `xxen_report_parameters_v` view. It groups parameters by their `lov_query` (SQL text) and filters for those where the count is greater than 1, indicating duplication.
+
+### Key Views
+- **`xxen_report_parameters_v`**: The source of parameter definitions and their associated LOV SQL text.
+
+## Parameters
+- **Category**: Allows users to filter the validation check by specific report categories (e.g., "Finance", "Supply Chain") to prioritize cleanup efforts.
+
+## Performance
+The report runs quickly as it performs a text-based aggregation on the metadata tables.
+
+## FAQ
+**Q: Why should I use shared LOVs instead of custom ones?**
+A: Shared LOVs are central objects. If you need to change the logic (e.g., exclude a specific Org ID), you change it in one place, and all 50 reports using that LOV are instantly updated.
+
+**Q: Does this report automatically fix the duplicates?**
+A: No, it is a diagnostic tool. It identifies the duplicates so a developer can decide which ones should be converted to a shared LOV.

Blitz Report Parameter DFF Table Validation/DESCRIPTION.md

@@ -0,0 +1,18 @@
+# Case Study: Blitz Report Parameter DFF Table Validation
+
+## Executive Summary
+The **Blitz Report Parameter DFF Table Validation** report is a diagnostic tool designed to ensure the integrity of Descriptive Flexfield (DFF) configurations within Blitz Reports. It specifically identifies parameters that use the `xxen_util.dff_columns` function but reference an incorrect or non-existent DFF table name.
+
+## Business Challenge
+Descriptive Flexfields (DFFs) are a powerful feature in Oracle EBS that allow for custom data capture. However, referencing them correctly in reports requires precise table names. Incorrect references can lead to:
+- Reports failing to run or returning errors.
+- Missing or incorrect data in report outputs.
+- Increased maintenance time to debug cryptic error messages.
+
+## Solution
+This validation report proactively scans report parameters to verify that any usage of `xxen_util.dff_columns` points to a valid DFF table. It cross-references the parameters with the `fnd_descriptive_flexs_vl` view to ensure accuracy.
+
+## Impact
+- **Proactive Error Detection**: Identifies configuration errors before they impact end-users.
+- **Data Integrity**: Ensures that custom data fields are correctly retrieved and displayed.
+- **Reduced Maintenance**: Simplifies the debugging process by pinpointing the exact parameter and table name causing the issue.