Files
Odoo-Modules/fusion_plating/fusion_plating_logistics
gsinghpal 2bfabfe135 feat(plating): Sub 8 — split receiving vs inspection + box parity
fp.receiving simplifies to box-count-only (new primary state
machine: draft → counted → staged → closed). Legacy
inspecting/accepted/discrepancy/resolved states stay in the
Selection so existing records load without error but are surfaced
behind a manager-only toggle. New box_count_in field + banner
that tells the receiver "count boxes only — parts are inspected
by the racking crew."

New fp.racking.inspection + fp.racking.inspection.line models —
one record per MO, auto-created by mrp.production.create() with
one line per contributing SO line (qty_expected seeded, qty_found
+ condition filled in by the racking crew when they open the boxes).
State: draft → inspecting → done | discrepancy_flagged (flagged
when any line has a non-ok condition or qty variance). Reopen
restricted to Plating Manager.

WO soft gate: first plating WO button_start raises a UserError
when the MO's racking inspection is still Draft or Inspecting.
Plating Manager bypasses; later WOs are not gated.

fp.delivery gains x_fc_box_count_out. action_mark_delivered calls
_fp_check_box_parity which posts a non-blocking chatter warning
when boxes out ≠ boxes in (resolved via job_ref → MO.origin → SO
→ receiving). Warning only — never blocks shipping.

Menu entry: Plating → Operations → Racking Inspection.

Module version bumps:
  fusion_plating_receiving  → 19.0.3.0.0
  fusion_plating_logistics  → 19.0.3.0.0
  fusion_plating_bridge_mrp → 19.0.12.0.0 (+depends receiving)

Smoke on entech: 12/12 assertions pass (one gate test skipped —
MO had no WOs to test) including box-count state machine, inspection
auto-create, lifecycle, discrepancy flag, and box-parity chatter.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-23 00:30:36 -04:00
..
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00

Fusion Plating — Logistics

Part of the Fusion Plating product family by Nexa Systems Inc.

Adds pickup & delivery management on top of the fusion_plating core:

  • Vehicle master — insurance, registration, service, TDG status, home facility, current driver
  • Driver tracking — extends hr.employee with licence class, licence expiry, TDG certification and expiry (x_fc_* fields)
  • Pickup requests — customer-initiated pickup of parts to be processed, with full state machine (new → scheduled → en_route → picked_up → received)
  • Deliveries — scheduled delivery of finished parts back to the customer (draft → scheduled → en_route → delivered / refused / returned)
  • Routes — combine pickups and deliveries into a single run for one driver and vehicle, with drag-to-reorder stops, calendar view, and total km tracking
  • Chain of custody — append-only audit trail written automatically as pickups and deliveries move through their lifecycle
  • Proof of delivery — recipient signature, photos, GPS, delivery timestamp

Dependencies

  • fusion_plating (core)
  • hr
  • mail

Works on both Odoo Community and Enterprise. The Enterprise fleet module is not required — the vehicle master is a lightweight CE-compatible model sized to what a plating shop needs.

Security

Reuses the core fusion_plating groups (Operator / Supervisor / Manager / Administrator) via the res.groups.privilege mechanism. No new groups are defined by this module.

  • Operators: read-only on all logistics records
  • Supervisors: read / write / create on routes, deliveries, pickup requests, vehicles, route stops, custody events, PODs
  • Managers: full CRUD (adds unlink)

Multi-company isolation is enforced by global ir.rule records on every new model.

Menu

Adds a Logistics section under the Plating app menu with:

  • Pickup Requests
  • Deliveries
  • Routes
  • Chain of Custody
  • Proof of Delivery

Adds Vehicles under Plating → Configuration.

Field naming

  • New dedicated models use the fusion.plating.* namespace consistent with the core module.
  • Extensions of base Odoo models (hr.employee) use the x_fc_ prefix per the Fusion Central convention.

Odoo 19 compliance

  • res.groups.privilege is reused from the core module — no category_id on res.groups.
  • No users field on groups.
  • All models inherit mail.thread / mail.activity.mixin via the _inherit list.
  • <chatter/> tag used in form views.
  • SCSS is theme-aware — no hardcoded colours, only CSS custom properties from Odoo / Bootstrap, and color-mix() for semantic tints.

Copyright (c) 2026 Nexa Systems Inc. All rights reserved.