167c423bf5
E2E test (quote → SO → MO → WOs → ship → invoice → payment) ran clean but flagged five gaps where the operator was filling in data the system already knew. Closes all five. #1 SO CONFIRM → AUTO-CREATE DRAFT MO (was a workflow blocker) bridge_mrp/sale_order.py: action_confirm() override + new _fp_auto_create_mo helper. Resolves the manufactured product from the configurator's part-catalog → coating-config → FP-WIDGET fallback; resolves the recipe from coating_config.recipe_id → part_catalog.recipe_id → first installed recipe. Idempotent: skips if any MO already exists for the SO. Errors are caught and chatter-posted so SO confirm never fails because of an MO glitch. #2 QUOTE PO → client_order_ref ON SO (one-line fix) configurator/fp_quote_configurator.py: action_create_quotation now copies po_number_preliminary into Odoo's standard client_order_ref alongside the existing custom x_fc_po_number. Portal pages, native reports, and integrations all read the standard field; no reason both shouldn't carry the same PO#. #3 MO DONE → AUTO-RENDER CoC + THICKNESS PDFs bridge_mrp/mrp_production.py button_mark_done now calls a new _fp_generate_cert_pdf helper after creating each fp.certificate. Renders fusion_plating_reports.action_report_coc to PDF, stores as ir.attachment, links to cert.attachment_id, AND cross-links to portal_job.coc_attachment_id + delivery.coc_attachment_id so the customer portal and the shipping email both find it without an extra step. Thickness report falls back to the CoC layout (which embeds thickness data) until a dedicated report ships. Errors are logged but never block MO completion. #4 RECEIVING received_qty PREFILL receiving/fp_receiving.py: create() prefills received_qty from expected_qty on draft. Operator only types when the count is wrong (the rare case). Field carrier_tracking already exists, so #4's 'no inbound tracking field' from the gap report turned out to be a false alarm. #5 DELIVERY scheduled_date + driver PREFILL bridge_mrp/mrp_production.py: new _fp_build_delivery_vals helper sets scheduled_date from the portal job's target_ship_date (or now+2 business days as a sane fallback) and auto-picks assigned_driver_id from clocked-in employees tagged is_driver (falls back to any active driver if the shift is empty). The outbound tracking_ref deliberately stays empty — that's the carrier's number, paste it in once UPS/FedEx accepts the package. Module bumps: configurator 19.0.5.0.0, bridge_mrp 19.0.5.0.0, receiving 19.0.2.0.0. Verified on entech: re-ran the E2E test against a fresh quote. Quote → SO populated client_order_ref, SO confirm auto-created MO, receiving prefilled received_qty=50, MO done generated CERT-00018.pdf and linked it to portal job + delivery, delivery's scheduled_date prefilled to 2026-04-29, full pipeline ended with portal job state 'complete'. The remaining 'gaps' in the static report are script artefacts (e.g. it flags 'no inbound tracking field' but the field exists; flags 'no driver auto-pick' but the demo data has zero drivers tagged is_driver=True). 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.5.0.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,
|
|
}
|