This commit fixes the template interpolation issues where variables like
{{supplier_name}}, {{product_names_joined}}, {{current_stock}}, etc. were
showing as literal strings instead of being replaced with actual values.
Changes made:
1. **Dashboard Service (Orchestrator):**
- Added missing `current_stock` parameter to default reasoning_data for
production batches
- This ensures all required template variables are present when batches
don't have proper reasoning_data from the database
2. **Production Service:**
- Updated batch creation to properly populate `product_name` field
- Improved product name resolution to check forecast data and stock_info
before falling back to placeholder
- Added missing `product_id` field to batch_data
- Added required `planned_duration_minutes` field to batch_data
- Ensures reasoning_data has all required parameters (product_name,
predicted_demand, current_stock, confidence_score)
The root cause was that the default reasoning_data used by the dashboard
service when database records lacked proper reasoning_data was missing
required parameters. This resulted in i18n template variables being
displayed as literal {{variable}} strings instead of interpolated values.
Fixes dashboard display issues for:
- Purchase order cards showing {{supplier_name}}, {{product_names_joined}},
{{days_until_stockout}}
- Production plan items showing {{product_name}}, {{predicted_demand}},
{{current_stock}}, {{confidence_score}}
BACKEND IMPLEMENTATION: Implemented template code auto-generation for quality
check templates following the proven pattern from orders and inventory services.
IMPLEMENTATION DETAILS:
**New Method: _generate_template_code()**
Location: services/production/app/services/quality_template_service.py:447-513
Format: TPL-{TYPE}-{SEQUENCE}
- TYPE: 2-letter prefix based on check_type
- SEQUENCE: Sequential 4-digit number per type per tenant
- Examples:
- Product Quality → TPL-PQ-0001, TPL-PQ-0002, etc.
- Process Hygiene → TPL-PH-0001, TPL-PH-0002, etc.
- Equipment → TPL-EQ-0001
- Safety → TPL-SA-0001
- Cleaning → TPL-CL-0001
- Temperature Control → TPL-TC-0001
- Documentation → TPL-DC-0001
**Type Mapping:**
- product_quality → PQ
- process_hygiene → PH
- equipment → EQ
- safety → SA
- cleaning → CL
- temperature → TC
- documentation → DC
- Fallback: First 2 chars of template name or "TP"
**Generation Logic:**
1. Map check_type to 2-letter prefix
2. Query database for count of existing codes with same prefix
3. Increment sequence number (count + 1)
4. Format as TPL-{TYPE}-{SEQUENCE:04d}
5. Fallback to UUID-based code if any error occurs
**Integration:**
- Updated create_template() method (lines 42-50)
- Auto-generates template code ONLY if not provided
- Maintains support for custom codes from users
- Logs generation for audit trail
**Benefits:**
✅ Database-enforced uniqueness per tenant per type
✅ Meaningful codes grouped by quality check type
✅ Follows established pattern (orders, inventory)
✅ Thread-safe with async database context
✅ Graceful fallback to UUID on errors
✅ Full audit logging
**Technical Details:**
- Uses SQLAlchemy select with func.count for efficient counting
- Filters by tenant_id and template_code prefix
- Uses LIKE operator for prefix matching (TPL-{type}-%)
- Executed within service's async db session
**Testing Suggestions:**
1. Create template without code → should auto-generate
2. Create template with custom code → should use provided code
3. Create multiple templates of same type → should increment
4. Create templates of different types → separate sequences
5. Verify tenant isolation
This completes the quality template backend auto-generation,
matching the frontend changes in QualityTemplateWizard.tsx
Implemented proper reasoning data generation for purchase orders and
production batches to enable multilingual dashboard support.
Backend Strategy:
- Generate structured JSON with type codes and parameters
- Store only reasoning_data (JSONB), not hardcoded text
- Frontend will translate using i18n libraries
Changes:
1. Created shared/schemas/reasoning_types.py
- Defined reasoning types for POs and batches
- Created helper functions for common reasoning patterns
- Supports multiple reasoning types (low_stock, forecast_demand, etc.)
2. Production Service (services/production/app/services/production_service.py)
- Generate reasoning_data when creating batches from forecast
- Include parameters: product_name, predicted_demand, current_stock, etc.
- Structure supports frontend i18n interpolation
3. Procurement Service (services/procurement/app/services/procurement_service.py)
- Implemented actual PO creation (was placeholder before!)
- Groups requirements by supplier
- Generates reasoning_data based on context (low_stock vs forecast)
- Creates PO items automatically
Example reasoning_data:
{
"type": "low_stock_detection",
"parameters": {
"supplier_name": "Harinas del Norte",
"product_names": ["Flour Type 55", "Flour Type 45"],
"days_until_stockout": 3,
"current_stock": 45.5,
"required_stock": 200
},
"consequence": {
"type": "stockout_risk",
"severity": "high",
"impact_days": 3
}
}
Frontend will translate:
- EN: "Low stock detected for Harinas del Norte. Stock runs out in 3 days."
- ES: "Stock bajo detectado para Harinas del Norte. Se agota en 3 días."
- CA: "Estoc baix detectat per Harinas del Norte. S'esgota en 3 dies."
Next steps:
- Remove TEXT fields (reasoning, consequence) from models
- Update dashboard service to use reasoning_data
- Create frontend i18n translation keys
- Update dashboard components to translate dynamically
