User audit caught: in the workforce E2E run we had no idea which bath /
which tank ran the job. For aerospace traceability that's a deal-
breaker. Add a validation gate on mrp.workorder.button_start so
operators can't tap START without the data the shop floor MUST capture.
**Three new pieces on mrp.workorder:**
1. `_fp_is_wet_process()` — best-effort "does this WO involve a
chemistry bath?" check. Three signals in priority order:
a. A bath is already linked → definitely wet
b. The workcenter's FP work-centre supports a wet process family
(plating, pre/post-treatment, strip, passivation)
c. WO name contains a wet-process keyword (plat, nickel, chrome,
anodiz, zinc, etch, clean, rinse, strip, passivat, electroless…)
The keyword fallback is needed because most existing recipes have
no process_type_id set on their operation nodes.
2. `_fp_check_required_fields_before_start()` — runs before the
existing certification check. Rules:
• Every WO needs an assigned operator (x_fc_assigned_user_id).
Without it, productivity records can't be attributed and the
proficiency tracker has no employee to credit.
• Wet WOs additionally need x_fc_bath_id + x_fc_tank_id. So we
know exactly which chemistry bath ran the job and which physical
tank it sat in.
Raises a clear UserError listing the missing fields if any.
3. `x_fc_requires_bath` (compute, non-stored) — surfaces the wet check
to the form view so bath + tank fields render with `required=`.
**View changes:**
- `x_fc_assigned_user_id` is now `required="1"` on the form
- `x_fc_bath_id` + `x_fc_tank_id` use `required="x_fc_requires_bath"`
→ red asterisk only when the WO is actually wet
**Simulator updates** (scripts/fp_e2e_workforce.py):
- Hannah now explicitly assigns bath + tank to wet WOs during planning,
AND pre-issues operator certifications for the bath's process type
(real shop manager workflow).
- Two negative tests added that PROVE the gates fire:
• Test 1: strip the operator → button_start raises "missing Assigned Operator"
• Test 2: strip bath/tank on a wet WO → button_start raises "missing Bath/Tank"
**Final E2E:** 42 PASS / 2 WARN / 0 FAIL out of 44 checks.
Both remaining WARNs (bake-window auto-create, first-piece gate) are
expected behaviour — those are coating-driven and the test coating
intentionally doesn't trigger them.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
76 lines
2.7 KiB
Python
76 lines
2.7 KiB
Python
# -*- coding: utf-8 -*-
|
|
# Copyright 2026 Nexa Systems Inc.
|
|
# License OPL-1 (Odoo Proprietary License v1.0)
|
|
# Part of the Fusion Plating product family.
|
|
|
|
{
|
|
"name": "Fusion Plating — MRP Bridge",
|
|
'version': '19.0.6.4.0',
|
|
'category': 'Manufacturing/Plating',
|
|
'summary': 'Bridge Fusion Plating facilities, baths and tanks to Odoo MRP work orders.',
|
|
'description': """
|
|
Fusion Plating — MRP Bridge
|
|
============================
|
|
|
|
Part of the Fusion Plating product family by Nexa Systems Inc.
|
|
|
|
Links Fusion Plating infrastructure (facilities, work centres, baths, tanks)
|
|
to Odoo's native MRP manufacturing orders and work orders so shops can:
|
|
|
|
* Assign a plating facility and FP work centre to an MRP work centre.
|
|
* Tag each work order with the specific bath, tank, rack/fixture, target
|
|
thickness, and dwell time for traceability.
|
|
* Attach a customer specification and facility to a manufacturing order.
|
|
* Create an MRP work centre directly from a Fusion Plating work centre.
|
|
* Link a portal job to a manufacturing order for customer visibility.
|
|
|
|
Copyright (c) 2026 Nexa Systems Inc. All rights reserved.
|
|
""",
|
|
'author': 'Nexa Systems Inc.',
|
|
'website': 'https://www.nexasystems.ca',
|
|
'maintainer': 'Nexa Systems Inc.',
|
|
'support': 'support@nexasystems.ca',
|
|
'license': 'OPL-1',
|
|
'price': 0.00,
|
|
'currency': 'CAD',
|
|
'depends': [
|
|
'fusion_plating',
|
|
'fusion_plating_portal',
|
|
'fusion_plating_quality',
|
|
'fusion_plating_logistics',
|
|
'fusion_plating_batch',
|
|
'fusion_plating_shopfloor',
|
|
'fusion_plating_configurator',
|
|
'hr',
|
|
# hr_attendance gives us the standard hr.attendance model
|
|
# (check_in / check_out). fusion_clock builds on the same model
|
|
# so this works whether the shop runs vanilla attendance or the
|
|
# full Fusion Clock T&A. Bringing the dep into the bridge keeps
|
|
# the Manager Desk's "show only clocked-in workers" filter
|
|
# working out of the box.
|
|
'hr_attendance',
|
|
'mrp',
|
|
'mrp_workorder',
|
|
'mrp_account',
|
|
'sale_mrp',
|
|
'account',
|
|
],
|
|
'data': [
|
|
'security/ir.model.access.csv',
|
|
'data/fp_work_role_data.xml',
|
|
'wizard/fp_recipe_config_wizard_views.xml',
|
|
'views/mrp_workcenter_views.xml',
|
|
'views/mrp_workorder_views.xml',
|
|
'views/mrp_production_views.xml',
|
|
'views/sale_order_views.xml',
|
|
'views/fp_quality_hold_views.xml',
|
|
'views/fp_batch_views.xml',
|
|
'views/fp_workorder_priority_views.xml',
|
|
'views/fp_job_consumption_views.xml',
|
|
'views/fp_work_role_views.xml',
|
|
],
|
|
'installable': True,
|
|
'application': False,
|
|
'auto_install': False,
|
|
}
|