From b395600a1cd26b61b32d54da0fcf81c3f6ac3b3a Mon Sep 17 00:00:00 2001
From: gsinghpal <gur_preet.singh@outlook.com>
Date: Thu, 21 May 2026 05:18:32 -0400
Subject: [PATCH] changes

---
 fusion_plating/CLAUDE.md                      |  5 +-
 .../__manifest__.py                           |  2 +-
 .../views/sale_order_views.xml                | 12 ++++
 .../wizard/fp_direct_order_wizard.py          | 12 +++-
 .../wizard/fp_direct_order_wizard_views.xml   |  8 ++-
 .../fusion_plating_reports/__manifest__.py    |  2 +-
 .../report/report_actions.xml                 | 25 ++++----
 .../report/report_fp_packing_slip.xml         | 24 ++++++--
 .../report/report_fp_sale.xml                 | 60 ++++++++++++-------
 9 files changed, 103 insertions(+), 47 deletions(-)

diff --git a/fusion_plating/CLAUDE.md b/fusion_plating/CLAUDE.md
index 81516dde..7df65b5c 100644
--- a/fusion_plating/CLAUDE.md
+++ b/fusion_plating/CLAUDE.md
@@ -29,10 +29,11 @@ Fusion Plating is a multi-module Odoo 19 ERP for electroless nickel plating and
 | **Report border rendering** | After two failed attempts (px→mm conversion + dpi bump; then `border-collapse: separate` single-side-per-cell), settled on **`border-collapse: collapse` + longhand borders + `background-clip: padding-box`**. Verticals are a hair softer than horizontals on entech wkhtmltopdf — accepted as the lesser evil vs misaligned tables. See rule 14a, last paragraph. **Don't retry the single-side pattern.** | `fusion_plating_reports` |
 | **Page-break-inside: avoid placement** | When a long QWeb report dumps content into multi-page PDFs via wkhtmltopdf, the company header (rendered as `--header-html`) can overlap body content if a page break lands mid-row in a table. **Apply `page-break-inside: avoid` to `<tr>` elements** (and to wrapper `<div>`s that wrap whole logical sections like signature blocks), not to `<table>`. On entech wkhtmltopdf, `<table>`-level `page-break-inside` is unreliable when the table is long enough to definitely break; per-row is honoured. Pattern: keep individual readings/rows together so the wkhtmltopdf header zone never overlaps mid-row content. Wrap the larger logical block (cert thickness section, signature + certification statement) in `<div style="page-break-inside: avoid;">` to keep it together when it fits and naturally wrap to a fresh page when it doesn't. | `fusion_plating_reports/report/report_coc.xml` |
 | **`opacity` + `italic` muted text renders jagged on entech wkhtmltopdf** | The obvious pattern for a subtle footnote — `font-style: italic; opacity: 0.7;` (used by `.fp-coc .small-label`) — produces washed-out, jagged characters that look "broken" or "messed up" on the printed PDF. Visually it reads as garbled text even though the source is clean. **Use solid grey (`color: #555`) at normal weight instead** for muted secondary text. Same workaround applies to any `opacity`-driven greyed-out element bound for wkhtmltopdf. The existing `.small-label` class still exists for legacy callers but new code should prefer an explicit `color:` style. | `fusion_plating_reports` |
-| **wkhtmltopdf header overlap — paperformat.margin_top, NOT body padding-top** | The wkhtmltopdf header zone is sized by `report.paperformat.margin_top` (and `header_spacing`). If the `web.external_layout` header (logo + address etc.) renders ~28mm tall but paperformat reserves only 8mm, page 2+ has the header bleeding over body content (the overlap shows up as the company logo printed *on top of* the signature, readings table, etc.). The anti-pattern is "fix" it by adding `padding-top: 50mm` to the body wrapper — this only pads page 1 (single one-shot padding) and does nothing for subsequent pages, while also wasting 50mm of usable space on page 1. **Right fix:** size `paperformat.margin_top` to the actual rendered header height, then drop body `padding-top` to a tiny visual gap (~5mm). Each report can have its own paperformat — `report_coc_en` / `report_coc_fr` use "Fusion Plating CoC" (id 13); the legacy `report_coc` uses "A4 Landscape (Fusion Plating)" (id 12). Update the right one and don't bleed changes across reports. **Corollary — don't use negative `margin-top` to "tighten" the gap** (e.g. `.my-page { margin-top: -10px; }` to pull the H1 up under the header). The body wrapper sits at the bottom edge of the reserved margin_top zone; any negative margin pushes content INTO the header band, where wkhtmltopdf clips the top of glyphs (looks like the title is half-eaten). If the gap really feels too big, shrink the title font instead, or reduce `paperformat.margin_top` so the entire header zone is shorter. **For customer-facing portrait reports** (SO confirmation, quote, invoice, packing slip, BoL) the canonical compact paperformat is `fusion_plating_reports.paperformat_fp_a4_portrait` (margin_top=22mm, header_spacing=3mm, keeps the standard header band). Bind it via `<field name="paperformat_id" ref="fusion_plating_reports.paperformat_fp_a4_portrait"/>` rather than creating yet-another-one. **Two compounding-padding traps to be aware of:** (1) Odoo's `.page` class has `padding: 1cm` baked in (Bootstrap-derived). If you wrap your body in `<div class="page">` AND add a body `padding-top: 15mm`, you get the paperformat margin_top + 10mm Odoo + 15mm yours = ~65mm of dead space above the title. To remove the .page contribution without losing its left/right padding, override only the top: `.fp-report.fp-sale .page { padding-top: 0 !important; }`. CoC sidesteps this by NOT using an inner `.page` div — it wraps directly in `<div class="fp-coc">` and puts padding on that. (2) The base `.fp-report table.bordered th, .fp-report table.bordered td` rule applies borders explicitly, BUT a separate cascade still bleeds borders onto NESTED `<table>` elements even when the inner table has no `.bordered` class — `border: 0 !important` on the cells does NOT reliably override it (some wkhtmltopdf rendering paths still draw the lines). **Don't use a `<table>` for non-bordered layouts** like a title/barcode strip; use `<div>` + `float: right` / flexbox instead. Saves an hour of CSS specificity arguments with wkhtmltopdf. (3) **CSS comments inside QWeb `<style>` blocks are XML-parsed** — writing `/* don't use a <table> here */` makes lxml see a literal `<table>` opening tag and the file fails to load with `XMLSyntaxError: Opening and ending tag mismatch`. Strip the angle brackets from any HTML-like literals in CSS comments: write `/* don't use a table here */` or quote it as `"<table>"`. | `fusion_plating_reports`, `report.paperformat` |
+| **wkhtmltopdf header overlap — paperformat.margin_top, NOT body padding-top** | The wkhtmltopdf header zone is sized by `report.paperformat.margin_top` (and `header_spacing`). If the `web.external_layout` header (logo + address etc.) renders ~28mm tall but paperformat reserves only 8mm, page 2+ has the header bleeding over body content (the overlap shows up as the company logo printed *on top of* the signature, readings table, etc.). The anti-pattern is "fix" it by adding `padding-top: 50mm` to the body wrapper — this only pads page 1 (single one-shot padding) and does nothing for subsequent pages, while also wasting 50mm of usable space on page 1. **Right fix (the CoC pattern — proven to work):** use a TINY `margin_top` (≤8mm) + `header_spacing=0` + `header_line=False`, then put a generous `padding-top: 20mm` on the body wrapper class (`.fp-coc`, `.fp-sale`, etc.). The header HTML is allowed to overflow the reserved zone INTO the body area; the body's wrapper padding is what actually clears it. This is more robust than trying to size `margin_top` to the rendered header height — any future header change (extra phone line, taller logo) immediately causes overlap with the "sized exactly" approach, whereas the overflow+padding approach has slack built in. Reference setup: `paperformat_fp_coc` and `paperformat_fp_a4_portrait` both use `margin_top=8`, `header_spacing=0`, `header_line=False`; CoC's `.fp-coc` and SO's `.fp-sale` both use `padding-top: 20mm` on the wrapper. Each report can have its own paperformat — `report_coc_en` / `report_coc_fr` use "Fusion Plating CoC" (id 13); the legacy `report_coc` uses "A4 Landscape (Fusion Plating)" (id 12); SO portrait uses "Fusion Plating A4 Portrait (Compact)". Update the right one and don't bleed changes across reports. **Corollary — don't use negative `margin-top` to "tighten" the gap** (e.g. `.my-page { margin-top: -10px; }` to pull the H1 up under the header). The body wrapper sits at the bottom edge of the reserved margin_top zone; any negative margin pushes content INTO the header band, where wkhtmltopdf clips the top of glyphs (looks like the title is half-eaten). If the gap really feels too big, shrink the title font instead, or reduce `paperformat.margin_top` so the entire header zone is shorter. **For customer-facing portrait reports** (SO confirmation, quote, invoice, packing slip, BoL) the canonical compact paperformat is `fusion_plating_reports.paperformat_fp_a4_portrait` (margin_top=22mm, header_spacing=3mm, keeps the standard header band). Bind it via `<field name="paperformat_id" ref="fusion_plating_reports.paperformat_fp_a4_portrait"/>` rather than creating yet-another-one. **Two compounding-padding traps to be aware of:** (1) Odoo's `.page` class has `padding: 1cm` baked in (Bootstrap-derived). If you wrap your body in `<div class="page">` AND add a body `padding-top: 15mm`, you get the paperformat margin_top + 10mm Odoo + 15mm yours = ~65mm of dead space above the title. To remove the .page contribution without losing its left/right padding, override only the top: `.fp-report.fp-sale .page { padding-top: 0 !important; }`. CoC sidesteps this by NOT using an inner `.page` div — it wraps directly in `<div class="fp-coc">` and puts padding on that. (2) The base `.fp-report table.bordered th, .fp-report table.bordered td` rule applies borders explicitly, BUT a separate cascade still bleeds borders onto NESTED `<table>` elements even when the inner table has no `.bordered` class — `border: 0 !important` on the cells does NOT reliably override it (some wkhtmltopdf rendering paths still draw the lines). **Don't use a `<table>` for non-bordered layouts** like a title/barcode strip; use `<div>` + `float: right` / flexbox instead. Saves an hour of CSS specificity arguments with wkhtmltopdf. (3) **CSS comments inside QWeb `<style>` blocks are XML-parsed** — writing `/* don't use a <table> here */` makes lxml see a literal `<table>` opening tag and the file fails to load with `XMLSyntaxError: Opening and ending tag mismatch`. Strip the angle brackets from any HTML-like literals in CSS comments: write `/* don't use a table here */` or quote it as `"<table>"`. | `fusion_plating_reports`, `report.paperformat` |
 | **CoC + thickness = ONE cert (page 2 merge OR inline body)** | When a customer has both `x_fc_send_coc` and `x_fc_send_thickness_report` on (or part has `certificate_requirement='coc_thickness'`), `_resolve_required_cert_types` returns **`{'coc'}` only**. Standalone `thickness_report` certs are only created when CoC is OFF and thickness is ON (rare). The earlier "two certs" behavior was a bug — don't restore it. **Two rendering paths exist for the thickness data in the CoC PDF:** (1) **Page-2 PDF merge** via `_fp_merge_thickness_into_pdf` — used when there's a real PDF source (operator uploaded a Fischerscope PDF, or QC has `thickness_report_pdf_id`). (2) **Inline readings table in the CoC body** — used when `thickness_reading_ids` is populated but there's no PDF source (e.g. RTF upload parsed to readings, manually typed readings). Lives in `report_coc.xml` between the parts table and the signature block, gated on `doc.thickness_reading_ids`. Both can coexist on a cert — PDF merges as page 2, readings render inline; usually only one path has data per cert. | `fusion_plating_jobs`, `fusion_plating_certificates`, `fusion_plating_reports` |
 | **Smart-button "create or view" pattern** | For a smart button that toggles between "create" and "view" states, use **one** idempotent button with `widget="statinfo"`, not two sibling buttons gated by mutually-exclusive `invisible` expressions. Custom `<div class="o_stat_info">` without `<span class="o_stat_value">` renders awkwardly in Odoo 19 (numbers + label expected); `statinfo` handles the standard structure automatically. The action method itself should branch on whether the linked record exists (create-then-open or just open). | any module with smart buttons |
 | **stock.move.name removed** | Odoo 19 dropped the `name` field on `stock.move`. Passing `name` in a create dict raises `ValueError: Invalid field 'name' on model 'stock.move'`. Use `description_picking` instead (the operator-facing line label on the picking). The DB column is gone too — `name` doesn't exist as a stored field. | any code that builds stock.move records |
+| **stock.picking.move_ids_without_package removed** | Odoo 19 dropped `move_ids_without_package` on `stock.picking` — `<t t-foreach="doc.move_ids_without_package">` raises `AttributeError: 'stock.picking' object has no attribute 'move_ids_without_package'` at QWeb render. Use `move_ids` instead (all stock moves on the picking). The filtered "without_package" variant no longer exists; if you really need to exclude packaged moves, filter `move_ids` in QWeb (`move_ids.filtered(lambda m: not m.package_level_id)`) or in a python helper. Same gotcha applies to any old report/template ported from Odoo 16/17. | any report/view iterating over picking moves |
 | **Recordsets use `__slots__` — no transient attrs** | Odoo 19's `BaseModel` declares `__slots__ = ['env', '_ids', '_prefetch_ids']`, so `picking._my_stash = data` raises `AttributeError: 'stock.picking' object has no attribute '_my_stash'`. The error reads like a missing field but it's actually Python rejecting the assignment. Don't stash transient state on a recordset between method calls — pass it as a method arg, store on the caller's `self`, or use `env.context` for cross-frame plumbing. Caught here because `fp_receiving._fp_build_shipping_picking` tried to attach `_fp_outbound_packages` to the picking before handing off to `_fp_apply_shipping_result`; the catch-all `except Exception` swallowed it and surfaced the misleading "Carrier API call failed" wizard. | any code that wants to attach data to a recordset between calls |
 | **labelary.com dependency for ZPL→PDF** | `fusion_plating_receiving` POSTs ZPL labels to `https://api.labelary.com/v1/printers/8dpmm/labels/4x6/0/` to get a PDF rasterization, so one FedEx ship call can populate both the PDF and ZPL smart buttons on the receiving form. **Privacy:** every outbound label's shipping address + tracking number leaves the network and hits labelary's servers (no payment data, but real customer info). **Operational:** anonymous tier is ~5 req/s; add an API key in the labelary helper if you ever ship more than that. PDF→ZPL is intentionally not attempted — that direction is impractical and FedEx's `/ship` endpoint only returns one format per shipment, so the carrier MUST be configured for ZPLII (not PDF) for the dual-format flow to work. Switching the carrier back to PDF will silently drop the ZPL button. | `fusion_plating_receiving/models/fp_receiving.py` (`_fp_apply_shipping_result`) |
 | **FedEx ZPL ships with `^POI` — strip it** | FedEx's REST `/ship` endpoint returns ZPL with `^POI` (Print Orientation = Invert) baked in, which flips the label 180° on the printer. On a desktop direct-thermal like the Zebra ZD450 that prints upside-down for the operator, and labelary mirrors the inversion in the PDF preview. `_fp_apply_shipping_result` creates a `*-fixed.zpl` copy of the FedEx attachment with `^POI` removed and points the shipment + smart buttons at the cleaned copy; the original FedEx ZPL stays on the picking for audit. **Don't restore `^POI`** — both the PDF preview and the Zebra output need it stripped. If a future printer needs inverted orientation, configure the printer driver instead of putting `^POI` back. | `fusion_plating_receiving/models/fp_receiving.py` (`_fp_apply_shipping_result`) |
@@ -43,6 +44,8 @@ Fusion Plating is a multi-module Odoo 19 ERP for electroless nickel plating and
 | **entech apt is broken — install new packages via `dpkg -i` bypass** | LXC 111's apt state has pre-existing breakage that blocks ANY `apt install`: `python3-lxml-html-clean` not installable on Bookworm but odoo's deb depends on it, `postgresql-15-pgvector` Breaks `postgresql-15-jit-llvm (< 19)`, `libglu1-mesa`/`libglx-mesa0` installed without their Mesa sub-deps (libopengl0, libdrm2, libxfixes3…), `postgresql-15` itself in `iF` half-configured state. Apt's global resolver refuses ALL installs until these are fixed. Workaround that worked for ImageMagick + libwmf: `apt-get download` the target debs into a tmp dir, then `dpkg -i *.deb` — dpkg only checks the direct deps of what you're installing, not the system-wide health. Use this pattern when entech needs new system packages; **don't try `apt --fix-broken install`** without coordinating with whoever owns the box — fixing pgvector/lxml-html-clean could cascade into Odoo or PostgreSQL changes. Installed this way: `imagemagick`, `imagemagick-6-common`, `imagemagick-6.q16`, `libmagickcore-6.q16-6`, `libmagickwand-6.q16-6`, `libwmf-0.2-7`, `libwmflite-0.2-7`, `libwmf-bin`, `libfftw3-double3`, `liblqr-1-0`, `hicolor-icon-theme` (2026-05-21, ~4 MB total). WMF→raster path: `wmf2svg input.wmf -o out.svg` writes a thin SVG referencing `out-N.png` side-files (libwmf unpacks raster blocks inside the metafile). ImageMagick's `convert` lacks the WMF delegate on Debian Bookworm — use wmf2svg for raster extraction, not `convert input.wmf out.png`. | any new system package install on entech LXC 111 |
 | **Fischerscope XDAL 600 `.doc` files are actually RTF** | Helmut Fischer's XDAL 600 XRF software exports thickness reports with a `.doc` extension but the file contents are **RTF** (`{\\rtf1\\ansi…`), not Microsoft Word binary `.doc`. `file(1)` confirms: `Rich Text Format data, version 1`. python-docx will refuse to open it, and the filename-based dispatch (`endswith('.docx')`) silently skips parsing. **Don't reach for libreoffice/antiword.** Detect by **magic bytes** (`raw_bytes[:5] == b'{\\\\rtf'`) and route through `_fp_parse_fischerscope_rtf` instead — it strips RTF control words with regex and runs the same Fischerscope reading regex as the .docx path. The image data embedded as hex inside `{\\pict ...}` blocks must be stripped FIRST or the reading regex will choke on multi-MB image hex. | `fusion_plating_jobs/wizards/fp_cert_issue_wizard.py` |
 | **entech apt — which conversion tools are available** | The host has pre-existing broken deps (`python3-lxml-html-clean` missing, `postgresql-15-pgvector` vs `postgresql-15-jit-llvm` conflict, various Mesa packages) that make new `apt install` calls fragile — they often abort partway through dep resolution. **Currently installed and usable:** `convert` (ImageMagick 6), `wmf2svg`, `wmf2eps` (libwmf-bin). **Not installed:** `libreoffice`, `unoconv`, `pandoc`, `wmf2png`. Don't assume the next `apt install` will go through — always run `which <tool>` first and design the feature to soft-fail if the tool isn't there (see `_fp_extract_rtf_images` for the pattern: shell out, catch `FileNotFoundError`/`TimeoutExpired`, fall back to "no image" instead of crashing the cert flow). For WMF → PNG specifically: `wmf2svg` writes both SVG and a side-file `*-N.png` per embedded raster — use that, not `convert input.wmf` (no WMF delegate). For new tools: check pure-Python alternatives first (Pillow without backends, pypdf, openpyxl) before reaching for apt. | any feature wanting to convert docs/images server-side |
+| **QWeb `t-field` requires a dotted path — bare variables fail at compile** | Odoo 19 enforces `assert "." in el.get('t-field')` in `_compile_directive_field`. Writing `<div t-field="partner" t-options="{'widget': 'contact', ...}"/>` (where `partner` came from a `<t t-set="partner" t-value="..."/>` in the calling template) **fails at template-compile time** with `AssertionError: t-field must have at least a dot like 'record.field_name'`. The error message points at the line, but the broader trap is that **you can't write a generic "render-a-partner-as-contact" sub-template that takes a record via t-set** — the contact-widget pattern only works on real field traversals like `doc.partner_id` baked into the template at author time. **Workarounds:** (a) Inline the partner rendering at each call site so the `t-field` has a dotted path (`<div t-field="doc.partner_invoice_id" t-options=...`). (b) Render the address parts manually in the sub-template using `t-esc` on explicit fields (`partner.street`, `partner.city`, etc.) — verbose but works with bare variables. Pattern (b) is what `fp_packing_slip_addr_block` uses now after this trap was hit. Same applies to `t-out` with `widget` options. | any QWeb sub-template trying to render a record via `t-field` |
+| **Assigning a `Date` to a `Datetime` field shifts the day in negative-UTC timezones** | When a transient/wizard `fields.Date` value is written into a target `fields.Datetime` field (e.g. wizard `customer_deadline` → SO `commitment_date`), Odoo stores midnight UTC of the picked date. Rendered back in any negative-UTC timezone (Eastern UTC-4/-5, all of CA/US), midnight UTC = 8pm the previous day — so the user picks "May 25" in the wizard and sees "May 24" on the SO header / PDF report. **Fix:** combine the date with noon before writing: `datetime.combine(self.my_date, time(12, 0))` — noon UTC stays on the same calendar date in every reasonable timezone (±12hr). Caught here on `fp.direct.order.wizard._prepare_order_vals` writing `commitment_date`. Watch for the same pattern any time a wizard/configurator with a Date field hands off to a Datetime target. The reverse (`Datetime` field read into a Date-display) is fine if `t-options="{'widget':'date'}"` is used — Odoo handles the tz-aware date extraction. | any wizard writing a Date value into a Datetime field |
 | **Customer-facing reports use bilingual EN/FR labels** | Every customer-facing report label (column titles, section banners, totals, document title) renders English first and French second. **Default to inline slash format** ("English / French" on one line) — easier to scan and saves vertical space. **Use the stacked variant only for cells too narrow** for the French word to fit on the same line (QTY, UOM, narrow column headers in dense tables). CSS classes live in the `fp_sale_bilingual_styles` template in `report_fp_sale.xml`. **Inline (default):** `.fp-bl-en { font-weight:bold; }` + `.fp-bl-sep { color:#999; margin:0 3px; }` + `.fp-bl-fr { font-weight:normal; font-style:italic; color:#555; }`. Pattern: `<span class="fp-bl-en">English</span><span class="fp-bl-sep">/</span><span class="fp-bl-fr">French</span>`. **Stacked (narrow cells):** `.fp-bl-en-stk` + `.fp-bl-fr-stk` (each `display:block`). **Always render both spans even when EN and FR are the same word** (e.g. "Description / Description", "Taxes / Taxes") — visual consistency across the row matters more than the redundancy; dropping the FR span on identical-word labels leaves an obvious gap when scanning down a column of headers. When a report has a barcode block, encode `doc.name` via `ir.actions.report.barcode_data_uri('Code128', doc.name, 600, 100)` (the helper inlines a data URI — don't `/report/barcode/...` over HTTP, wkhtmltopdf network fetches fail on entech). Apply to ALL outward-facing reports (SO confirmation, quote, invoice, CoC, packing slip, BoL); internal-only reports (job traveller, WO sticker) can stay English. | `fusion_plating_reports/report/report_fp_sale.xml` (canonical), every customer-facing report |
 
 ### Pending — IN PROGRESS when this session ended
diff --git a/fusion_plating/fusion_plating_configurator/__manifest__.py b/fusion_plating/fusion_plating_configurator/__manifest__.py
index ddb65c03..8f207a47 100644
--- a/fusion_plating/fusion_plating_configurator/__manifest__.py
+++ b/fusion_plating/fusion_plating_configurator/__manifest__.py
@@ -5,7 +5,7 @@
 
 {
     'name': 'Fusion Plating — Configurator',
-    'version': '19.0.21.5.2',
+    'version': '19.0.21.5.5',
     'category': 'Manufacturing/Plating',
     'summary': 'Quotation configurator with part catalog, coating configs, and formula-based pricing engine.',
     'description': """
diff --git a/fusion_plating/fusion_plating_configurator/views/sale_order_views.xml b/fusion_plating/fusion_plating_configurator/views/sale_order_views.xml
index 2661859f..d8c1fac2 100644
--- a/fusion_plating/fusion_plating_configurator/views/sale_order_views.xml
+++ b/fusion_plating/fusion_plating_configurator/views/sale_order_views.xml
@@ -111,6 +111,18 @@
                            string="Job Groups"/>
                 </button>
             </xpath>
+            <!-- Surface Delivery Date (commitment_date) right after Order
+                 Date in the header info group. The standard view only
+                 shows it buried under the Delivery section in the Other
+                 Info tab — having it at the top keeps it visible without
+                 scrolling, since most operators are setting it on every
+                 order. The same field is also surfaced lower in our
+                 Plating tab Scheduling group as "Customer Deadline"; both
+                 reference the same field so edits sync. -->
+            <xpath expr="//group[@name='order_details']/field[@name='payment_term_id']" position="before">
+                <field name="commitment_date" string="Delivery Date"
+                       readonly="state in ('cancel',)"/>
+            </xpath>
             <xpath expr="//notebook" position="inside">
                 <page string="Plating" name="plating_tab">
                     <!-- Multi-part summary: read-only list of every order line
diff --git a/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard.py b/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard.py
index 7160caf8..d3b74c68 100644
--- a/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard.py
+++ b/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard.py
@@ -3,7 +3,7 @@
 # License OPL-1 (Odoo Proprietary License v1.0)
 # Part of the Fusion Plating product family.
 
-from datetime import timedelta
+from datetime import datetime, time, timedelta
 
 from odoo import _, api, fields, models
 from odoo.exceptions import UserError
@@ -530,7 +530,15 @@ class FpDirectOrderWizard(models.Model):
             'x_fc_customer_job_number': self.customer_job_number or False,
             'x_fc_planned_start_date': self.planned_start_date,
             'x_fc_internal_deadline': self.internal_deadline,
-            'commitment_date': self.customer_deadline,
+            # commitment_date is a Datetime; customer_deadline is a Date.
+            # Assigning a bare Date stores midnight UTC, which renders as
+            # the PREVIOUS day in any negative-UTC timezone (Eastern shifts
+            # May 25 00:00 UTC → May 24 8pm). Combining with noon keeps
+            # the date stable across all reasonable user timezones.
+            'commitment_date': (
+                datetime.combine(self.customer_deadline, time(12, 0))
+                if self.customer_deadline else False
+            ),
             'x_fc_invoice_strategy': self.invoice_strategy,
             'x_fc_deposit_percent': self.deposit_percent,
             'x_fc_progress_initial_percent': self.progress_initial_percent,
diff --git a/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard_views.xml b/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard_views.xml
index d7580f47..a9773205 100644
--- a/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard_views.xml
+++ b/fusion_plating/fusion_plating_configurator/wizard/fp_direct_order_wizard_views.xml
@@ -95,7 +95,13 @@
                         <group string="Scheduling">
                             <field name="planned_start_date"/>
                             <field name="internal_deadline"/>
-                            <field name="customer_deadline"/>
+                            <!-- Labelled "Delivery Date" here to match
+                                 the SO header field of the same name —
+                                 same field, same value, just consistent
+                                 wording end-to-end. Backing field is
+                                 still `customer_deadline` (wizard) →
+                                 `commitment_date` (SO). -->
+                            <field name="customer_deadline" string="Delivery Date"/>
                             <field name="is_blanket_order"/>
                             <field name="block_partial_shipments"/>
                         </group>
diff --git a/fusion_plating/fusion_plating_reports/__manifest__.py b/fusion_plating/fusion_plating_reports/__manifest__.py
index 453696a3..a5ce0c17 100644
--- a/fusion_plating/fusion_plating_reports/__manifest__.py
+++ b/fusion_plating/fusion_plating_reports/__manifest__.py
@@ -3,7 +3,7 @@
 # License OPL-1 (Odoo Proprietary License v1.0)
 {
     'name': 'Fusion Plating — Reports',
-    'version': '19.0.11.26.7',
+    'version': '19.0.11.26.14',
     'category': 'Manufacturing/Plating',
     'summary': 'PDF reports for Fusion Plating: quote, SO, WO, packing, BoL, CoC, invoice, receipt, quality + compliance.',
     'depends': [
diff --git a/fusion_plating/fusion_plating_reports/report/report_actions.xml b/fusion_plating/fusion_plating_reports/report/report_actions.xml
index 8b4c550c..d75c42eb 100644
--- a/fusion_plating/fusion_plating_reports/report/report_actions.xml
+++ b/fusion_plating/fusion_plating_reports/report/report_actions.xml
@@ -56,16 +56,20 @@
         <field name="default" eval="False"/>
         <field name="format">A4</field>
         <field name="orientation">Portrait</field>
-        <!-- margin_top sized for the standard FP header (ENTECH logo +
-             2-line company address). Earlier 22mm clipped it — the logo
-             + name + address actually need ~28mm. 32mm leaves a small
-             clean gap before the title. Tighter than Odoo's 40mm default. -->
-        <field name="margin_top">32</field>
+        <!-- Mirrors paperformat_fp_coc exactly. Tiny margin_top (8mm)
+             puts the rendered header band flush at the top of the page;
+             the body clears the header via padding-top on the .fp-sale
+             wrapper (same way .fp-coc { padding-top: 20mm } clears it
+             on the CoC). DO NOT set margin_top to "the header height"
+             — that forces the header to live entirely inside the
+             reserved zone and any header growth = body overlap.
+             margin_top=8 + padding-on-wrapper is the proven shape. -->
+        <field name="margin_top">8</field>
         <field name="margin_bottom">15</field>
         <field name="margin_left">10</field>
         <field name="margin_right">10</field>
         <field name="header_line" eval="False"/>
-        <field name="header_spacing">3</field>
+        <field name="header_spacing">0</field>
         <field name="dpi">90</field>
     </record>
 
@@ -294,14 +298,7 @@
         <field name="print_report_name">(object.state in ('draft', 'sent') and 'Quotation - %s' % object.name) or 'Order - %s' % object.name</field>
         <field name="binding_model_id" ref="sale.model_sale_order"/>
         <field name="binding_type">report</field>
-        <!-- Uses Odoo's default paperformat so web.external_layout's
-             header/footer band gets its reserved space correctly (same
-             approach as report_coc_en / report_coc_fr). Title spacing
-             below the header is controlled by `padding-top` on the body
-             wrapper in report_fp_sale.xml — NOT by a custom paperformat,
-             since trimming the paperformat margin makes the header HTML
-             bleed into the body. See CLAUDE.md "wkhtmltopdf header
-             overlap" for the underlying mechanic. -->
+        <field name="paperformat_id" ref="paperformat_fp_a4_portrait"/>
     </record>
 
     <record id="action_report_fp_sale_landscape" model="ir.actions.report">
diff --git a/fusion_plating/fusion_plating_reports/report/report_fp_packing_slip.xml b/fusion_plating/fusion_plating_reports/report/report_fp_packing_slip.xml
index 7256b494..e9d36de5 100644
--- a/fusion_plating/fusion_plating_reports/report/report_fp_packing_slip.xml
+++ b/fusion_plating/fusion_plating_reports/report/report_fp_packing_slip.xml
@@ -32,12 +32,28 @@
         </style>
     </template>
 
-    <!-- Address box content (shared by portrait + landscape) -->
+    <!-- Address box content (shared by portrait + landscape).
+
+         NOTE: `t-field` in Odoo 19 requires a dotted path
+         ("record.field_name") — passing a bare `partner` variable
+         via t-set and then `t-field="partner"` raises
+         `AssertionError: t-field must have at least a dot`.
+         The contact-widget pattern (`t-field="x.partner_id"
+         t-options="{'widget': 'contact', ...}"`) only works when
+         x.partner_id is a real field traversal on the document.
+         So we render the address parts manually with `t-esc` and
+         per-field guards. -->
     <template id="fp_packing_slip_addr_block">
         <div class="fp-ps-addr-label" t-esc="label"/>
         <strong><span t-esc="partner.name or ''"/></strong>
-        <div t-field="partner"
-             t-options="{'widget': 'contact', 'fields': ['address', 'phone', 'email'], 'no_marker': True}"/>
+        <div t-if="partner.street"><span t-esc="partner.street"/></div>
+        <div t-if="partner.street2"><span t-esc="partner.street2"/></div>
+        <div t-if="partner.city or partner.state_id or partner.zip">
+            <t t-if="partner.city"><span t-esc="partner.city"/></t><t t-if="partner.state_id">, <span t-esc="partner.state_id.code or partner.state_id.name"/></t><t t-if="partner.zip"> <span t-esc="partner.zip"/></t>
+        </div>
+        <div t-if="partner.country_id"><span t-esc="partner.country_id.name"/></div>
+        <div t-if="partner.phone"><span t-esc="partner.phone"/></div>
+        <div t-if="partner.email"><span t-esc="partner.email"/></div>
     </template>
 
     <!-- Items table (shared markup; only widths change between layouts) -->
@@ -72,7 +88,7 @@
                 </tr>
             </thead>
             <tbody>
-                <t t-foreach="doc.move_ids_without_package" t-as="move">
+                <t t-foreach="doc.move_ids" t-as="move">
                     <t t-set="line" t-value="move.sale_line_id or move"/>
                     <t t-set="ordered_qty" t-value="move.product_uom_qty or 0.0"/>
                     <t t-set="done_qty" t-value="move.quantity or 0.0"/>
diff --git a/fusion_plating/fusion_plating_reports/report/report_fp_sale.xml b/fusion_plating/fusion_plating_reports/report/report_fp_sale.xml
index cb2be321..c7f8f537 100644
--- a/fusion_plating/fusion_plating_reports/report/report_fp_sale.xml
+++ b/fusion_plating/fusion_plating_reports/report/report_fp_sale.xml
@@ -38,22 +38,34 @@
                below in italic-grey. */
             .fp-bl-en-stk { display: block; font-weight: bold; }
             .fp-bl-fr-stk { display: block; font-weight: normal; font-style: italic; color: #555; font-size: 80%; margin-top: 1px; }
-            /* Kill the extra top padding Odoo's `.page` class adds
-               (1cm by default). The paperformat already reserves
-               header room — `.page` padding compounds on top of it
-               and was the source of the giant gap. Keep left/right/
-               bottom at 1cm so the content isn't flush to the edges. */
-            .fp-report.fp-sale .page { padding-top: 0 !important; }
+            /* Match the CoC pattern exactly: tiny paperformat margin_top
+               (8mm) lets the header HTML overflow into the body area,
+               and this 20mm padding-top on the wrapper clears it. See
+               CLAUDE.md "wkhtmltopdf header overlap" — the alternative
+               "size margin_top to the header height" approach has zero
+               slack and breaks any time the header HTML grows. */
+            .fp-report.fp-sale { padding-top: 20mm; }
             /* Title bar uses float-based div layout, NOT an HTML table —
                the global ".fp-report table" rule was applying borders
                to every nested table even with "border: 0 !important",
                so the only reliable fix is to avoid the table element. */
-            .fp-sale-titlebar { margin: 0 0 8px 0; padding: 0; overflow: hidden; }
-            .fp-sale-title { font-size: 14pt; line-height: 1.2; color: #2e2e2e; font-weight: bold; }
-            .fp-sale-title .fp-bl-fr { font-size: 10pt; }
-            .fp-sale-barcode { float: right; text-align: right; margin-left: 12px; }
-            .fp-sale-barcode img { height: 34px; max-width: 220px; }
-            .fp-sale-barcode .fp-bc-label { font-size: 8pt; color: #555; margin-top: 2px; }
+            .fp-sale-titlebar { margin: 0 0 10px 0; padding: 0; overflow: hidden; }
+            /* Stacked title: English bold/large on top, French italic/
+               grey below. Sizes picked so the French line is roughly
+               the same horizontal width as the English line (English
+               is shorter character-wise but rendered larger). */
+            .fp-sale-title-en { font-size: 18pt; font-weight: bold; color: #2e2e2e; line-height: 1.1; display: block; }
+            .fp-sale-title-fr { font-size: 13pt; font-style: italic; color: #555; line-height: 1.1; display: block; margin-top: 2px; }
+            .fp-sale-title-num { font-weight: bold; margin-left: 6px; }
+            /* Barcode: bigger so it scans reliably. Wrap the img + label
+               in an inline-block so the label centers under the barcode
+               (not under the full floated column). Explicit no-border on
+               the img (wkhtmltopdf adds a 1px frame to inline-data img
+               elements by default on entech). */
+            .fp-sale-barcode { float: right; margin-left: 12px; }
+            .fp-bc-wrap { display: inline-block; text-align: center; }
+            .fp-bc-wrap img { height: 48px; max-width: 240px; border: 0 !important; padding: 0; display: block; }
+            .fp-bc-wrap .fp-bc-label { font-size: 10pt; color: #333; margin-top: 6px; letter-spacing: 0.5px; }
         </style>
     </template>
 
@@ -76,22 +88,24 @@
                     <div class="fp-report fp-sale">
                         <div class="page">
 
-                            <!-- Title bar: bilingual title on the left,
-                                 Code128 barcode floated right. NO <table>
-                                 — see CLAUDE.md "wkhtmltopdf header
-                                 overlap" §2 for why a table here leaks
-                                 borders even with `border:0 !important`. -->
+                            <!-- Title bar: stacked English/French title
+                                 on the left, Code128 barcode floated
+                                 right. NO HTML table — see CLAUDE.md
+                                 "wkhtmltopdf header overlap" §2 for why
+                                 a table here leaks borders. -->
                             <div class="fp-sale-titlebar">
                                 <t t-if="barcode_uri">
                                     <div class="fp-sale-barcode">
-                                        <img t-att-src="barcode_uri" alt="Order Barcode"/>
-                                        <div class="fp-bc-label"><span t-field="doc.name"/></div>
+                                        <div class="fp-bc-wrap">
+                                            <img t-att-src="barcode_uri" alt="Order Barcode"/>
+                                            <div class="fp-bc-label"><span t-field="doc.name"/></div>
+                                        </div>
                                     </div>
                                 </t>
-                                <div class="fp-sale-title">
-                                    <span class="fp-bl-en"><t t-esc="title_en"/></span><span class="fp-bl-sep">/</span><span class="fp-bl-fr"><t t-esc="title_fr"/></span>
-                                    <span> # </span><span t-field="doc.name"/>
-                                </div>
+                                <span class="fp-sale-title-en">
+                                    <t t-esc="title_en"/><span class="fp-sale-title-num"># <span t-field="doc.name"/></span>
+                                </span>
+                                <span class="fp-sale-title-fr"><t t-esc="title_fr"/></span>
                             </div>
 
                             <!-- Billing / Shipping (wide cells — inline) -->