Results for “solution_number”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CSD_RO_SOLUTIONS is a transactional table within the Oracle E-Business Suite Depot Repair (CSD) module. It records the individual solution lines that have been applied against a given repair order line. In the Depot Repair workflow, a repair line represents a specific unit or component being serviced; the solutions recorded in CSD_RO_SOLUTIONS capture the discrete repair actions, resolutions, or service solutions executed to bring that unit back to a serviceable condition. The table therefore sits at the intersection of repair tracking, solution definition, and service history reporting.

Heuristically, the mined foreign-key topology classifies CSD_RO_SOLUTIONS as satellite-leaning in a Data Vault model. This is a modeling suggestion only: the table's grain is defined by its relationship to a parent repair line (via REPAIR_LINE_ID) rather than representing an independent business entity. It carries descriptive and transactional attributes about the solution applied to a repair line, which is the behavioral signature of a satellite hanging off a repair-line hub or link.

Key Information Stored

The table is owned by the CSD schema and documents 10 physical columns. The composite primary key CSD_RO_SOLUTIONS_PK is defined over (REPAIR_LINE_ID, SOLUTION_NUMBER). REPAIR_LINE_ID is the foreign key to CSD_REPAIRS and identifies the repair line to which the solution belongs; SOLUTION_NUMBER is the sequencing/distinguishing element of that solution within the repair line. Together they form the surrogate and business-key candidate for uniquely identifying a solution row.

• REPAIR_LINE_ID — Foreign key to CSD_REPAIRS; anchors the solution to its parent repair line.
• SOLUTION_NUMBER — Sequence/identifier distinguishing multiple solutions applied to the same repair line.
• MLE_LINES_CREATED_FLAG — Indicates whether associated multiple-lot entry (MLE) lines have been generated, a common Depot Repair control flag.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enforcing multi-org/security-group data isolation.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the OAF/ADF framework for concurrent update control.
• CREATED_BY, CREATION_DATE — Standard "who/when created" audit columns.
• LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard "who/when last modified" audit columns.
• LAST_UPDATE_LOGIN — Login session identifier for the most recent update.

Common Use Cases and Queries

Typical reporting scenarios include determining how many solutions were applied per repair line, auditing the sequence of repair actions, and reconciling repair activity against service history. A representative query joining to the parent table:

• Solution count per repair line: SELECT REPAIR_LINE_ID, COUNT(*) FROM CSD.CSD_RO_SOLUTIONS GROUP BY REPAIR_LINE_ID;
• Join to repairs: SELECT r.REPAIR_LINE_ID, s.SOLUTION_NUMBER FROM CSD.CSD_RO_SOLUTIONS s JOIN CSD.CSD_REPAIRS r ON s.REPAIR_LINE_ID = r.REPAIR_LINE_ID;
• Security-filtered extract: filter on SECURITY_GROUP_ID to isolate a specific operating unit's repair solutions.
• Change-tracking audit: filter on LAST_UPDATE_DATE for incremental ETL or data-warehouse loads.

Related Objects

• CSD_REPAIRS — Parent table; join on CSD_RO_SOLUTIONS.REPAIR_LINE_ID = CSD_REPAIRS.REPAIR_LINE_ID.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID for multi-org security.
• CSD_RO_SOLUTIONS_PK — Composite primary key constraint.
• Depot Repair solution definition/API objects and repair-order reporting views that consume solution data for service history.