# Catalog Unification Process Summary

This document summarizes the unification of the Catalog Product system into the unified `SalesProducts` architecture, the risks encountered, and the current status of the implementation.

---

## 1. Process Overview
The unification process aimed to replace the legacy hierarchical product system with a flatter, more versatile model that spans multiple domains (Accounting, Supply, and Catalog).

### Key Phases:
1.  **Schema Alignment:** Added `sales_product_id` to core inventory tables (`catalog_inventories`, `transactions`, `reservations`) and introduced inventory tracking fields to the `SalesProducts` table.
2.  **Data Migration:** Process of "flattening" `CatalogProduct` and its `ProductVariants` into individual `SalesProduct` records with the `section = 'procurement'` attribute.
3.  **Service Refactoring:** Updating core business logic (Inventory Integration, Product Matching, and Temporary Product services) to resolve against `SalesProduct` IDs instead of legacy `variant_id`s.
4.  **Supply Domain Integration:** Updating Supply Order Items and associated models to reference the unified product model.

---

## 2. Risk Assessment
During and after the unification, several risks were identified:

| Risk Category | Description | Impact |
| :--- | :--- | :--- |
| **Hybrid State** | The system currently exists in a middle ground where both `variant_id` and `sales_product_id` coexist. | High - Logic may fail if it expects one ID but receives the other. |
| **Legacy Dependencies** | Subsystems like **Pricing** and **Allocation** still heavily rely on old model imports and table schemas. | Medium - These areas are technically "broken" or unstable until updated. |
| **Data Synchronization** | Ensuring that inventory movements tracked via the new ID are reflected accurately in legacy views. | High - Potential for stock discrepancies if double-writes fail. |
| **Developer Overhead** | Increased complexity for developers who must navigate two different product models during the transition. | Low - Temporary friction during the migration period. |

---

## 3. Current Product Architecture
The following diagram illustrates the transition from the legacy structure to the current unified status.

```mermaid
graph TD
    subgraph Legacy_Structure [Legacy System]
        CP[Catalog Product] --> PV[Product Variant]
        PV --> INV[Inventory Table]
        style Legacy_Structure fill:#f9f,stroke:#333,stroke-width:2px
    end

    subgraph Unified_Status [Current Unified System]
        SP[SalesProduct] 
        SP -- section: procurement --> SP_P[Procurement Product]
        SP -- section: sales --> SP_S[Retail Product]
        
        SP_P --> INV_U[Inventory Table]
        SP_S --> INV_U
        
        style Unified_Status fill:#bbf,stroke:#333,stroke-width:2px
    end

    INV -.->|Migrated to| INV_U
    PV -.->|Flattened into| SP
```

---

## 4. Status Breakdown
*   **Database:** ✅ Done (Columns added, core migrations running).
*   **Core Models:** 🔄 In Progress (Relationships added, but old ones not yet removed).
*   **Service Layer:** 🔄 In Progress (Supply services updated; Pricing/Allocation pending).
*   **UI/Frontend:** ⏳ Pending (Components need to be updated to target the new API endpoints).

### Recommended Next Steps
1.  **Hard-switch Supply DTOs:** Move `PurchaseOrderDTO` and `GoodsReceiptDTO` to exclusively use `sales_product_id`.
2.  **Pricing Domain Update:** Refactor `ClientProductPricingService` to stop using legacy `Catalog\Products` models.
3.  **Deprecation:** Begin marking legacy `Product` and `ProductVariant` models as `@deprecated` to prevent new usage.