Customer feedback: some customers don't send their PO with the
initial order — they send it days or weeks later. The system was
blocking SO confirmation without a PO, which forced the shop to
either wait on paperwork or ask a manager for a formal override.
New estimator-level path: a "PO Pending" boolean on sale.order +
an optional "PO Expected By" date.
* Confirm without a PO# / PO document when PO Pending is ticked.
* action_confirm skips the hard error if po_pending OR po_override
is set (keeps the existing manager-override path too).
* On confirm with PO Pending, the system schedules a chase
activity for po_expected_date (or +3 days if blank), assigned
via mail.activity so it shows up in the sales user's activity
list. Chatter note logged so audit is obvious.
* Direct-order wizard: po_number and po_attachment_file become
optional. Ticking "PO Pending" in the wizard is the trade-in;
a help note under the toggle explains the chase behaviour.
* Once the PO arrives, user fills in the PO# / uploads the doc,
and turns PO Pending off — existing downstream flow resumes.
Difference from x_fc_po_override (kept):
* PO Override = manager waiver, permanent ("handshake deal").
* PO Pending = estimator flag, time-boxed ("customer will send it
by Friday").
fusion_plating_configurator → 19.0.14.0.0
fusion_plating_invoicing → 19.0.3.0.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Second attempt at widening the wizard modal after the :has() CSS
approach broke layout. This time using Odoo's built-in
dialog_size mechanism — just drop 'dialog_size': 'extra-large'
into the action's context and Odoo applies its own modal-xl
class, sized for wide content. About 30% wider than the default,
which gives the 10+ line columns breathing room without any
custom CSS.
fusion_plating_configurator → 19.0.13.6.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reverting the previous wizard-width attempt. The
`.modal-dialog:has(.o_fp_direct_order_wizard)` selector combined
with the fixed width override produced broken layout (modal no
longer rendering correctly).
Better path for widening this wizard is still TBD — the built-in
maximize icon in the modal header already lets users go full-
screen as a workaround until a safe width override lands.
fusion_plating_configurator → 19.0.13.5.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User complaint: the direct-order wizard's line table was crammed —
"Primary Treatment" showed as "Primary T..." and "Serial Number"
as "Serial Nu..." at the default Odoo modal width (~992px).
Added a dedicated stylesheet that targets the wizard via a new
o_fp_direct_order_wizard class on the form element. The modal
dialog containing the wizard now opens at min(1600px, 95vw) —
wide enough for the 10+ columns (Part, Primary Treatment, Process,
Thickness, Serial Number, Qty, Unit Price, Subtotal, Part Deadline,
WO Group) to fit without truncation on typical desktop displays,
while still adapting to narrower screens.
Also nudged per-cell horizontal padding from Bootstrap's default
to 10px left/right so the columns have a bit more breathing room
inside the wider table.
fusion_plating_configurator → 19.0.13.4.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two small fixes on the direct-order wizard:
1. User reported the Process column from the previous commit didn't
appear on the line list. Root cause: module view definitions
only reload on -u, not on systemctl restart. The earlier ship
bumped the version + ran -u, but the Process column inside the
list view required a fresh view load. Re-running -u now resolves
it (no code change needed for that field).
2. The "+ Add From Prior SO" and "+ Add From Quotes" buttons were
rendering edge-to-edge because their container div used the
default Bootstrap flow (margin-right: 0). Swapped the wrapping
div class from `mb-2` to `mb-2 d-flex gap-2` so Bootstrap lays
the two buttons side-by-side with a consistent 0.5rem gap.
fusion_plating_configurator → 19.0.13.3.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User asked why the direct-order wizard only showed "Primary
Treatment" and not Process — aren't they the same? They're not,
but the distinction was invisible on the order line until now.
Mental model (preserved here to keep future decisions aligned with
the user's question):
* Primary Treatment (fp.coating.config) = "WHAT coating" (process
type, thickness range, spec reference — the contractual
deliverable).
* Process (fusion.plating.process.node tree) = "HOW we make it"
(the floor-level sequence of operations and steps that WO
generation turns into work).
Each coating carries a default process (recipe_id). Parts can
override that via the Process Composer, storing a part-scoped
clone (default_process_id on fp.part.catalog). Resolution:
part's composed process wins; coating default is the fallback.
Added a computed read-only `effective_process_id` field on
fp.direct.order.line that displays exactly what process will drive
WO generation for the line, plus a one-line `effective_process_source`
showing whether it came from the part ("customised") or the
coating ("default"). Both surfaced on the wizard list and form so
the estimator can verify before confirming the order.
No behaviour change — this is pure visibility. WO generation still
uses the same resolution chain it did before.
fusion_plating_configurator → 19.0.13.2.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Four new fields on every sale.order.line, propagated through to MO,
Delivery, and Invoice for end-to-end traceability:
- fp.serial registry (new model in configurator) with smart-button
traceability to Sale Order, MO, Delivery, Invoice, Part. M2O on SO
line; optional; user types a customer serial or clicks Generate
Serial for a sequence-backed one. Reverse O2M links split across
configurator (invoice) / bridge_mrp (MO) / logistics (delivery) so
module load order is respected.
- x_fc_job_number on SO line, auto-sequenced FP-JOB-NNNNN on SO
confirm. Editable — shops can override for customer/legacy schemes.
- fp.coating.thickness (new child of fp.coating.config) with per-
config discrete thickness options; x_fc_thickness_id on SO line
domain-filtered to the line's coating. Auto-clears when coating
changes.
- x_fc_revision_snapshot Char on SO line, frozen from
x_fc_part_catalog_id.revision at save. Protects historical SOs from
later catalog edits. Secondary "Revision" picker on the tree view
lets users switch between prior revisions of the same part number;
the Part M2O still surfaces only is_latest_revision rows.
Reports (CoC, packing slip, invoice, BoL) pick up all four via the
Sub 2 customer_line_header macro — one macro edit, four reports.
Smoke on entech: 11 assertions pass including revision snapshot,
generate-serial button, typed-serial create-on-fly, coating→thickness
domain reset, SO confirm auto job#, and MO traceability carry.
Module version bumps:
fusion_plating_configurator → 19.0.12.0.0
fusion_plating_bridge_mrp → 19.0.11.0.0
fusion_plating_logistics → 19.0.2.0.0 (+depends configurator)
fusion_plating_reports → 19.0.5.1.0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The wizard was calling so.action_confirm() immediately after creating the
sale order, which flipped it from draft to sale state and triggered the
fusion_plating_notifications hook that auto-emails the customer.
Client wants a review step: keep the SO in quotation (draft) so the
user can adjust before the customer sees anything. They manually click
Send (to email the quotation) or Confirm (to convert to sale order,
which intentionally fires the confirmation email).
Changes:
- Remove so.action_confirm() call in action_create_order
- Update docstring + inline comment to reflect manual-confirm flow
- Update the chatter message on the created SO
CLAUDE.md updated to mark Sub 1 + Sub 2 as Shipped.
Verified:
- Static check: wizard.action_create_order contains no action_confirm
- Dynamic check: SO created programmatically stays in draft
- Manual action_confirm() flow still works as designed
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Removes the `description` field from `fp.sale.description.template` now
that all readers (reports, wizard, sale line) consume the new
`internal_description` + `customer_facing_description` pair.
- Model: drop `description = fields.Text(...)` declaration
- Migration 19.0.9.0.0 Step 6: `ALTER TABLE ... DROP COLUMN IF EXISTS description`
- Template form/search views: swap `description` for the two new fields
- Seed data: write new fields instead of legacy column (dupes old text into both)
- Direct-order wizard: remove `tpl.description` fallback in both onchange handlers
Entech column dropped via Odoo's auto-schema-sync during module upgrade
(migration step is for fresh installs).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds an `internal_description` text field to the direct-order wizard
line so the shop-floor copy is captured at order entry alongside the
customer-facing text. Picking a template now fires both sides of the
onchange: `line_description` gets `customer_facing_description` (with
fallback to the legacy `description` field for backward compat) and
`internal_description` gets the template's internal text. The
auto-suggest onchange was refactored around a tiny `_apply` helper so
all three fallback paths populate both fields consistently.
The template picker is surfaced as an optional column on the wizard
list (hidden until a part is chosen, domain-scoped to that part) and
as a dedicated labeled row in the per-line form. The internal text
field is also surfaced in the form under "Line Description" so the
estimator can review / edit it before confirm. On create_order, both
`x_fc_description_template_id` and `x_fc_internal_description` are
written through to the generated sale.order.line so the audit trail
and WO printout stay linked.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five fixes from the end-to-end UAT debrief:
1. Menu discoverability (HIGH)
Added a prominent "+ New Direct Order" button in the Sale Orders
list header toolbar (class=btn-primary, display=always). The
existing menuitem at Plating > Sales > New Direct Order was
buried in a submenu that didn't always expand; the toolbar
button is a guaranteed entry point from the most common screen.
2. Escape/X destroys wizard state (HIGH)
Added a prominent info banner at the top of the wizard form:
"Changes are not saved until you click Create & Confirm Order.
Closing this window (Esc or X) discards your entries." The
Cancel button now has confirm="Discard this order? All header
data and line items will be lost." so the intentional-cancel
path also prompts.
3. Shell/cron crash in _fp_auto_create_mo (MEDIUM)
bridge_mrp/models/sale_order.py:232-264 used _() inside list
comprehensions to format the internal chatter summary of newly
created / adopted MOs. _() resolves language from env.context,
which is empty in odoo-shell and cron contexts — triggering a
translate.get_text_alias crash AFTER the MOs had been created.
These strings are internal audit log text, not user-facing UI;
dropped the _() wrappers so the message builds safely from any
context. Same for the per-group error-message on savepoint
rollback.
4. Misleading "100%" margin (MEDIUM)
x_fc_margin_percent displayed 100% on every SO because the cost
rollup from fp.coating.config.unit_cost isn't populated yet.
Added x_fc_margin_available Boolean (True only when at least
one line's coating has a non-zero unit_cost). The SO Plating
tab now hides the margin numbers when margin_available=False
and shows an inline muted note: "Margin n/a — coating cost
rollup not yet populated on any line's treatment."
5. Account Hold banner too loud (LOW)
fusion_plating_invoicing was injecting a full-height danger
alert above every SO header. Slimmed it to a one-line compact
alert with icon: "Account Hold — SO confirmation, invoicing
and shipping are blocked for non-managers." Half the vertical
footprint, less visual competition with the Plating chip bar.
Verified via UAT on S00071.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two critical, one important, four polish fixes found by the
pr-review-toolkit code-reviewer.
C1 (CRITICAL) Start-at-node filter dropped later siblings
fusion_plating_bridge_mrp/models/mrp_production.py:448
The allowed_ids set was {descendants} ∪ {ancestors}, which wrongly
excluded nodes that should run AFTER the start node — including
later siblings of the start node and all operations in subsequent
sub-processes. Rewrote the upward walk to ALSO include each
ancestor's later-sequence siblings and their descendants. Smoke on
ENP-ALUM-BASIC: full=9 WOs, partial from mid-tree 'De-Masking'=5
WOs (previously was 1).
C2 (CRITICAL) Duplicate MO on re-confirm of pre-PR SOs
fusion_plating_bridge_mrp/models/sale_order.py:96
Legacy untagged MOs (created before this PR had line-linkage m2m)
were not recognized by the untagged idempotency check, so
re-confirming an already-processed SO would create one additional
MO per untagged plating line. Fix: pre-scan for a single legacy
untagged MO and adopt it by linking ALL untagged plating lines
onto it. Those lines are then treated as covered and no per-line
MOs are created on top. Smoke: S00066 before=1 MO, after
re-run=1 MO.
I5 (IMPORTANT) push_to_defaults wrote to pre-bump revision
fusion_plating_configurator/wizard/fp_direct_order_wizard.py:236
When create_new_revision=True, _get_or_bump_revision() returned a
new part record that got written to the SO line, but the
post-confirm push_to_defaults loop re-read line.part_catalog_id
(still the OLD rev) and wrote defaults there, defeating the whole
point of "save as default". Fix: cache resolved parts in a dict
keyed by wizard-line ID during the build loop, and use that cache
in the push_to_defaults pass.
I3/I4/I6 (PERF) Computes lacked @api.depends and did per-record
search_count / search queries
fusion_plating_configurator/models/sale_order.py
_compute_nav_counts, _compute_workorder_count, _compute_wo_completion
now:
- declare @api.depends
- batch via read_group across the whole self recordset
- rebuild {origin: counts} dicts and assign per record
M7 (MEDIUM) No savepoint around per-group MO creation
fusion_plating_bridge_mrp/models/sale_order.py:_fp_auto_create_mo
A mid-loop exception left group 1's MO persisted and aborted
groups 2..N. Wrapped each group's create in SAVEPOINT/RELEASE/
ROLLBACK TO SAVEPOINT so one bad group no longer corrupts state.
M8 (MEDIUM) Email 'opened' status false-positived on internal CC
fusion_plating_configurator/models/sale_order.py:_compute_email_status
Switched from 'any notification is_read' to 'customer partner has
a read email notification on this SO'.
M9 (LOW) start_at_node_id domain silently empty when coating unset
fusion_plating_configurator/wizard/fp_direct_order_line.py:94
Changed `('parent_id', 'child_of', ...)` to
`('id', 'child_of', ..., or 0)` and clarified the help text.
Regression smoke passed all checks on odoo-entech.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ships the remaining items from the Sales UX Uplift plan:
D2 BOM Items kanban
New view_sale_order_line_bom_kanban grouped by x_fc_part_catalog_id.
Smart button 'BOM Items' on SO form opens it.
D5 Archive line
x_fc_archived Boolean on sale.order.line plus action_archive_line /
action_unarchive_line. Acknowledgement report filters out archived
lines.
D6 Add Quoted Lines sub-wizard
New fp.add.from.quote.wizard parallel to fp.add.from.so.wizard. Pick
quotes for this customer and clone them into direct-order lines
carrying part, coating, qty, unit price (from calculated or
override), and notes. Button '+ Add From Quotes' on wizard Lines tab.
D7 SO Acknowledgement PDF
New ir.actions.report + QWeb template in configurator/report/.
Header shows customer / contact / PO / Customer Job #, Bill-To,
Ship-To, planned start + customer deadline + ship-via. Line table
skips archived lines. Includes external notes, blanket-order
callout, and customer-signature + vendor-signature blocks.
Binding added to sale.order so it shows up under Print menu.
D9 Quick-nav chip bar
New smart buttons on SO form: Invoices / Pickings / NCRs / Files
with counts and icons. Each opens a filtered list. NCR button
appears only when fusion_plating_quality is installed.
D10 SO/WO perspective toggle
view_sale_order_line_wo_kanban grouped by x_fc_wo_group_tag. Smart
button 'By WO' on SO form.
D11 Assemblies minimal model
fp.sale.assembly + fp.sale.assembly.line with name, ship_to, count,
procured_count, completed_at. UX (forms / kanbans / integration
into receiving) deferred — model only for now.
D14 Uploaded Files
Files smart button on SO form opens ir.attachment kanban filtered
to this SO. Count appears in the chip bar.
F4 Signed tracking
x_fc_signed_at / x_fc_signed_by / x_fc_is_signed on sale.order +
action_mark_signed helper. Signed column on quotes list view.
F10 New Quote
Kept on existing action_fp_quotations (already surfaces the
default New button).
E5/F9 Action icons per row
Deferred — requires a custom widget; the native PDF action via the
Print menu covers 80% of the use case.
Bumped to 19.0.8.0.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds quote_id (Many2one fp.quote.configurator) on the wizard line
with a domain scoped to the wizard's customer + quote states (sent /
accepted / won). Onchange auto-fills part, coating, and unit price
(final = estimator_override_price or calculated_price, per-part).
Mirrors x_fc_quote_id on sale.order.line for the audit trail. Surfaced
as a togglable column on the SO line tree and under "Qty & Price" on
the wizard line drill-in form.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds x_fc_default_coating_config_id and x_fc_default_treatment_ids
fields on fp.part.catalog. Wizard line gets a push_to_defaults
toggle. After action_create_order confirms the SO, any line with
push_to_defaults=True writes its coating + treatments back onto the
part catalog entry as the new defaults.
Reverse direction too: onchange on part_catalog_id in the wizard
line seeds coating + treatments from the part's defaults (if set and
the line doesn't already have them).
Part catalog form gets a new "Defaults" tab showing the stored
defaults. Smoke-tested: pushing default on order 1 populates the
catalog entry; new wizard line for that part auto-seeds the coating.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
C1: start_at_node_id per wizard line, mirrors to x_fc_start_at_node_id
on sale.order.line. Domain filters to nodes descending from the
coating_config's recipe so the estimator only picks valid resume
points. bridge_mrp will use this in a follow-up to skip ancestor
steps in the generated work order.
C2: part_wo_description (separate from customer-facing line_description)
lets the planner add internal-only notes that appear on the travelling
sheet only. Mirrors to x_fc_part_wo_description on sale.order.line.
C5: is_one_off flag for prototype / non-catalog parts. Mirrors to
x_fc_is_one_off. Actual skip-catalog behaviour will be wired in a
later pass.
All three fields appear in the wizard line drill-in form (under a new
"Work Order (internal)" group) and as togglable columns on the
sale.order.line tree.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task B4. New fp.add.from.so.wizard transient model: given the current
direct-order wizard + customer, lists the customer's prior confirmed
sale orders, lets the estimator tick source lines, and clones them
into fp.direct.order.line rows (part, coating, treatments, qty,
price, deadline, rush, WO group, description).
Button "+ Add From Prior SO" lives on the Lines tab of the main
wizard, visible once the customer is picked. Sub-wizard rejects
source lines that predate the new plating fields (no x_fc_part_catalog_id).
Smoke-tested on odoo-entech: copying all 3 lines of S00066 onto a
fresh wizard reproduces part/coating/qty/price correctly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase B partial landing (B1, B2, B3, B5):
- B1/B2: x_fc_is_blanket_order and x_fc_block_partial_shipments on
sale.order; matching booleans on the wizard header.
- B3: x_fc_wo_group_tag Char on sale.order.line and wo_group_tag on
wizard line. Free-text tag; bridge_mrp will batch lines sharing a
tag into one MO in a follow-up.
- B5: is_missing_info computed Boolean on fp.direct.order.line;
tree uses decoration-warning to highlight incomplete rows in amber.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tasks A3 + A6. Wizard rewritten as header + lines architecture:
- Header carries customer/addresses/PO/deadlines/invoicing/notes.
- One SO line created per fp.direct.order.line, carrying part,
coating, treatments M2M, qty, price, per-line deadline, rush flag,
and description.
- action_create_order loops wizard lines, invokes revision-bump
helper, and builds order_line tuples with x_fc_* fields.
- Form view uses notebook (Lines tab with editable tree + drill-in
form, Notes tab), amber missing-info banner at top, running totals
at bottom. Customer deadline maps to Odoo commitment_date on SO.
Single-line fields and their computes/onchanges removed from wizard;
moved to fp.direct.order.line in task A4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task A4. Expands fp.direct.order.line with: part related fields,
optional new-revision block, additional treatment M2M, per-line
deadline + rush flag, description template + free-text, onchange
auto-price-lookup from customer price list, onchange template
suggestion (part > customer > coating), and _get_or_bump_revision
helper that will be called by the SO-creation loop.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task A2 of the direct-order-wizard rewrite. Adds SO-header fields for
customer job #, three deadlines (planned start / internal / customer),
bill-to / ship-to address pickers, the line_ids O2M linking to
fp.direct.order.line, computed order totals, and a missing-info
warning banner. Partner onchange now also seeds default addresses.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task A1 of the direct-order-wizard rewrite. Adds the transient line
model that will hold per-part detail (part, coating, qty, price) when
the wizard moves from single-line to header+lines architecture.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The earlier description templates were global — same 8 generic texts
applied to any part. That's useless when a customer has 3,500 parts
and each part has 3–5 canned variants (standard, masked threads,
masked bore, rework, rush packaging). That's ~17,500 rows total, and
the variants ONLY make sense in the context of a specific part number.
Restructured so descriptions live on each part:
Model changes:
fp.sale.description.template.part_catalog_id (new M2O, indexed,
ondelete cascade) — the primary scoping field
fp.sale.description.template.partner_id — now a related store=True
field pulled from the part, so customer-level search still works
fp.part.catalog.description_template_ids (new O2M inverse) — the
5–10 canned descriptions attached to this specific part
fp.part.catalog.description_template_count (computed)
UI changes:
Part Catalog form: new "Descriptions" notebook page with inline
editable list (sequence + name + tag + description + usage_count).
5 variants take 30 seconds to enter.
Part Catalog form: new smart button "Descriptions" showing the count,
jumps to the full list filtered by this part.
Template list view: part_catalog_id column added, list ordered by
part first. Search view adds Part filter + Part-Specific /
Generic (No Part) filters + Group By Part.
Wizard changes:
description_template_id domain now prioritises part-specific, falls
through to partner, coating, or generic on a single dynamic domain.
_onchange_suggest_template priority: part → customer → coating →
none. No longer auto-picks a random global template when a part
has its own.
Smoke-tested on VS-HSA201-B (Amphenol):
5 canned variants seeded on the part form
Wizard with this part auto-suggested the lowest-sequence one
The part's Descriptions smart button shows "5"
Bulk data entry path for the client's 3,500 parts: either use the
inline list on each part form, or import via CSV with the new
part_catalog_id column (external_id or DB id).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three UX improvements:
1. Sales menu reordered — New Quote (seq 1) is now the first entry,
followed by New Direct Order (5), Quotations (10), Sale Orders (20).
"New Quote" moved out of Configurator submenu into Sales so both
quote-creation paths live side-by-side.
2. Currency + unit display audit:
- fp.customer.price.list.unit_price flipped from Float to Monetary
with currency_field='currency_id' — list view now shows $ symbol
and a Total sum row
- fp.direct.order.wizard.unit_price flipped to Monetary, added
currency_id field and computed line_subtotal ($)
- % suffix appended to deposit_percent and progress_initial_percent
in the wizard
- Unit suffixes added where missing: bake_window.quantity (pcs),
window_hours (h), bake_temp (°F), bake_duration_hours (h);
bath.volume (L), bath.mto_count (turnovers); tank.volume shows
volume_uom inline
3. Saved line descriptions (new feature):
- New model fp.sale.description.template with name, description,
tag (standard/masking/rework/aerospace/nuclear/packaging/other),
optional coating_config_id and partner_id, usage_count bumped
on each use
- List + form + search views; new "Line Descriptions" menu under
Configurator
- 8 starter templates seeded (noupdate=1): ENP Standard/Aerospace/
Nuclear, masking variants, rework, packaging, delicate handling
- Direct Order Wizard gets a template picker (searchable Many2one)
+ editable paragraph; picking a template copies text to the
editable field, user tweaks freely, tweaked text lands on the
SO line as "<header>\n\n<description>"
- Auto-suggests template on coating+partner match if nothing
picked yet
Smoke-tested end-to-end: picked aerospace template, tweaked text,
confirmed wizard → SO S00030 has full description on line, usage
counter bumped from 0 to 1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bug review fixes (found by code review + live QWeb error):
- report_fp_sale.xml: product_uom → product_uom_id (Odoo 19 renamed;
was raising KeyError during PDF render, blocking all sale-order prints)
- mrp_production.button_mark_done: add idempotency guard on delivery
auto-create (was duplicating on every re-close)
- fp.certificate._compute_batch_ids: use empty recordset instead of
False for Many2many computed fields
- fp_notification_template._collect_attachments: collapse attach_quotation
+ attach_sale_order into a single render so email doesn't double-attach
the same PDF
- fp.operator.certification: SQL unique on computed state was unreliable;
added explicit `revoked` boolean, made state pure-compute, replaced
SQL constraint with @api.constrains that checks active-only uniqueness;
has_active_cert now reads revoked + expires_date directly (no stale
stored state between nightly recomputes)
Two missing invoice strategies implemented + 1 pre-existing deposit bug fix:
- Progress Billing: new x_fc_progress_initial_percent field on sale.order;
_create_progress_initial_invoice bills the configured % on SO confirm
via down-payment wizard, _create_final_balance_invoice bills the
remainder on delivery
- Net Terms: no invoice on confirm; full invoice auto-created when
fusion.plating.delivery.action_mark_delivered fires
- Fix for deposit (pre-existing, silent): sale.advance.payment.inv
reads active_ids at wizard-create time, not on create_invoices();
context was being set on the wrong call, so every deposit attempt
raised "Expected singleton" and message-posted to chatter instead
of actually invoicing
- New fusion_plating_invoicing/models/fp_delivery.py hooks
action_mark_delivered to dispatch final invoice for progress/net_terms
- fp.direct.order.wizard + SO form surface the progress_initial_percent
field (conditional on strategy)
Report styling cleanup:
- Hide DISCOUNT column from sale + invoice landscape reports unless at
least one line has a non-zero discount; colspan auto-adjusts
- Replace hardcoded #0066a1 in all reports with company.primary_color
driven by doc.company_id → company → user.company_id fallback chain,
with #1d1f1e as ultimate fallback; new .fp-header-primary class
exposes the colour for inline section headers (CARGO DESCRIPTION,
PAYMENT DETAILS, OPERATOR SIGN-OFF, etc.) so they retint with the
company theme without template edits
Certificate of Conformance — formal ENTECH-style rebuild:
- New res.company fields: x_fc_owner_user_id (default signer, sig from
hr.employee.signature), x_fc_coc_signature_override (manual upload),
x_fc_{nadcap,as9100,cgp}_logo + _active toggles for accreditation
badges
- New res.config.settings section "Fusion Plating" exposing the above
as configurable blocks; manager-only menu under Configuration →
Fusion Plating Settings
- New fp.certificate fields: nc_quantity, customer_job_no,
contact_partner_id (child contact for Name / Email / Phone block)
- New report_coc_en + report_coc_fr templates (primary): custom header
(company contact | accreditations | company logo), bilingual labels
per variant, customer info block with customer logo, 3-column cert
info table, 6-column line-item table (Part # | Process | Customer
PO | Shipped | NC Qty | Customer Job No.), signature image + bordered
certification statement, footer "Fusion Plating by Nexa Systems"
- Legacy report_coc + report_coc_portrait kept for existing portal-job
bindings (no behaviour change)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tier 2 — Quality & audit readiness:
- T2.1 SPC on thickness readings (fp.certificate)
- spec_min_mils / spec_max_mils auto-pulled from coating config on create
- Computed: std_dev_mils, min/max, cpk, cpk_status (incapable/marginal/
capable/excellent/insufficient)
- Western Electric trend rules (rule 1: any point beyond 3σ; rule 4:
8 consecutive on one side of mean) → trend_alert + explanation
- New SPC group on certificate form with badge-coloured indicators
- T2.2 Operator certification enforcement (fp.operator.certification)
- Per (employee, process_type) records with issued/expires dates,
training record attachment, revocation workflow
- State auto-computed: active → expired when date passes
- MrpWorkorder.button_start() blocks with UserError if current user's
linked hr.employee lacks an active cert for the bath's process_type
- Managers bypass the check; expiring-soon filter in search view
- HR Employee form: "Plating Certifications" tab
- T2.3 Material traceability chain
- fusion.plating.batch.workorder_id (new Many2one) + production_id
(related through WO) for full chain
- fp.certificate gets computed batch_ids / bath_ids / batch_count
- "Batches" stat button → list of batches used for this cert's MO,
with their chemistry logs intact
- T2.4 Pre-treatment as first-class baths
- process_family selection on fusion.plating.process.type
(pre_treatment / plating / post_treatment / bake / strip / passivation /
masking / inspection)
- Bath search view: Pre-Treatments / Plating / Post-Treatments / Strip
quick filters
- Existing bath infra (logs, replenishment, SPC) now applies to pre-
treatment baths equally
Tier 3 — Business / revenue:
- T3.1 Customer-specific price lists (fp.customer.price.list)
- Per (customer, coating_config) with unit_price + basis (per_part /
sqin / sqft / lb)
- effective_from / effective_to for annual contract pricing
- min_quantity for volume breaks (cheapest price at requested qty wins)
- _find_price() helper resolves active entry by date + qty
- Direct Order wizard auto-fills unit_price on (partner, coating, qty)
change unless operator has typed an override
- Configurator menu → Customer Price Lists
- T3.2 Quote win/loss tracking (fp.quote.configurator)
- State values: draft → confirmed (won) / lost / expired / cancelled
- lost_reason selection (price / lead_time / tech / spec_mismatch /
no_bid / no_response / competitor / other) + lost_competitor_name
+ lost_details text
- Action buttons: Mark as Lost (requires reason), Mark as Expired
- won_date auto-set on SO creation; lost_date auto-set on mark_lost
- New "Win / Loss" tab on configurator form
- T3.3 Actuals vs. quoted margin (mrp.production)
- Computed monetary fields: x_fc_consumables_cost, x_fc_labour_cost,
x_fc_actual_cost, x_fc_quoted_revenue, x_fc_margin_actual,
x_fc_margin_pct
- Labour = sum(WO duration × workcentre cost_hour)
- Revenue = SO amount_untaxed via mo.origin lookup
- New "Job Costing" group on MO form with badge-coloured margin
- T3.4 Job consumables tracking (fp.job.consumption)
- One row per consumable event (bath replenisher, masking tape, PPE,
chemistry): product, qty, uom, unit_cost (snapshot), total_cost,
source, optional workorder link
- One2many x_fc_consumption_ids on mrp.production
- "Consumables" stat button on MO → filtered list
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
