878c013902eedc56ec8104e2a8caba91ca9aa20b
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
gsinghpal
|
4ffbdc596d |
feat(plating): per-step compliance gates + backfill — 0 CRITICAL gaps
Per-step audit caught real enforcement bugs across all 9 WO kinds in
the recipe (Masking, Racking, Plating, De-Masking, Oven baking, etc.).
Five gates added or fixed; 0 CRITICAL gaps remain after a verification
run on a fresh MO.
**1. Bake-WO finish gate** (`_fp_check_required_fields_before_finish`)
button_finish on a bake WO now blocks unless:
• x_fc_bake_temp set (Nadcap req — actual setpoint, not just oven)
• x_fc_bake_duration_hours set (actual run time at temp)
• x_fc_oven_id.chart_recorder_ref set (so the chart for THIS run
can be retrieved by an auditor — required for AS9100/Nadcap)
Run-time data lives at FINISH, not START — operators don't know
temp/duration until the bake is done.
**2. Rack-WO start gate** added to the existing button_start gate.
Per-rack life tracking + which physical fixture handled the parts.
**3. Classifier priority fix** (`_fp_classify_kind`)
"Post-plate Inspection" was matching the `plat` wet keyword and
getting kind=wet (then required to have bath/tank). Reordered:
1. Explicit equipment links (bath_id/oven_id)
2. Specific keywords (inspect → mask → bake → rack)
— bake before rack so "Oven bake (Post de-rack)" → bake
3. Workcenter wet families
4. Wet name keywords as last fallback
**4. Auto-populate target_thickness + dwell_time** at recipe→WO
generation. Plating WOs inherit:
• thickness_target from coating_config.thickness_max
• thickness_uom from coating_config.thickness_uom
• dwell_time_minutes from recipe node's estimated_duration
So aerospace QC has the spec target on every WO without paper.
**5. Mask-WO start gate + masking_material field**
New x_fc_masking_material Selection (tape/plug/paint/silicone/wax/
mixed/other). Required to start a mask WO. Needed later when
stripping or replating because each material requires a different
removal process.
**View** (`mrp_workorder_views.xml`)
Process Details tab now branches by kind:
wet → Bath/Tank/Rack/Thickness/Dwell
bake → Oven/Temp/Duration
rack → Rack/Fixture
mask → Masking Material
inspect/other → informational alerts only
WO Kind shows as colour-coded badge in header.
**Backfill** (`scripts/fp_backfill.py`)
Idempotent script that catches up existing data:
• chart_recorder_ref on every oven
• rack_id on existing rack/de-rack WOs (91 backfilled)
• bake_temp + bake_duration_hours on existing bake WOs (33)
• masking_material on existing mask WOs (62)
• thickness/dwell on existing plating WOs (38)
• Cleared 7 legacy bath/tank from inspection WOs that had been
misclassified by the OLD wet-keyword classifier.
**Per-step audit** (`scripts/fp_per_step_audit.py`)
Walks every WO of the most recent done MO and reports per-kind
which compliance fields are filled vs missing. Re-runnable to
catch regressions.
**Final state on freshly-run MO 00049:**
• 0 CRITICAL gaps
• 2 IMPORTANT gaps (dwell_time + rack_id on E-Nickel Plating —
both inherited from recipe node data, not enforcement bugs)
Negative tests still passing (12 total).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
gsinghpal
|
c118b7c6b5 |
feat(plating): close compliance gaps 7-9 — NCR + CAPA + discharge + invoice ref
**7a. NCR close gate** (fusion.plating.ncr.action_close) Block close unless these are filled in: • Description (what happened) • Containment Actions (immediate response) • Root Cause (why it happened) • Disposition (use-as-is / rework / scrap / RTV decision) A closed NCR without these is useless for AS9100 audits — it's the entire point of an NCR to document what went wrong, why, and how we responded. Empty-HTML strings like "<p><br></p>" are detected as empty too. **7b. CAPA close gate** (fusion.plating.capa.action_close) Block close unless: • Root Cause Analysis filled in • Action Plan filled in • Verification (date + verifier) recorded • Effectiveness Notes filled when CAPA was marked Not Effective AS9100 §10.2 / Nadcap require evidence of root-cause analysis, the corrective/preventive action plan, AND that effectiveness was verified before the loop is closed. **8. Invoice ref defensive default** (account.move.create) Auto-fills `ref` from the source SO's client_order_ref or x_fc_po_number when the invoice is created with invoice_origin set but no ref. Already populated on the SO confirm path; this catches manually-created invoices that would otherwise miss it. Customer AP teams reject invoices that don't quote their PO# back. **9. Discharge sample close gate** (fusion.plating.discharge.sample.action_close) Block close unless: • Lab Report # set • Results Received Date set • At least one parameter reading on file • Lab certificate/report attached Without lab evidence the record fails any environmental compliance audit — the whole point is to document the test was performed and what the lab said. **Simulator** (scripts/fp_e2e_workforce.py) Adds 4 new negative tests (Test 8-11), all wrapped in savepoints: ✓ Test 8 : NCR close without RC/containment/disposition → blocked ✓ Test 9 : CAPA close without analysis/plan/verification → blocked ✓ Test 10: Discharge sample close without lab evidence → blocked ✓ Test 11: Invoice ref auto-fills from SO.client_order_ref → asserted **Final E2E**: 52 PASS / 2 WARN / 0 FAIL out of 54 checks. Both remaining WARNs are expected (bake-window auto-create, first-piece gate — coating-driven, this coating doesn't trigger them). 11 negative tests in total now, every gate fires when triggered. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
gsinghpal
|
db8b79d22e |
feat(plating): close 6 compliance gaps from required-fields audit
Following the workforce-E2E + required-fields audit, ship the first 6 high-priority gates so critical workflow + compliance fields can no longer be left empty by accident. **1. Invoice payment terms (account.move)** - create() now auto-inherits `invoice_payment_term_id` from partner.property_payment_term_id when missing - action_post() raises UserError if still missing — accountant must pick one before posting (prevents silent "immediate" due-date) **2. MO facility (mrp.production)** - action_confirm() auto-derives `x_fc_facility_id` if unset, in order: SO override → res.company.x_fc_default_facility_id → first active facility — then HARD GATES: raises UserError if still empty. Without facility every downstream record (WO, batch, bath log, cert) is missing the "where" half of the audit trail. **3. WO facility (mrp.workorder)** - Switched `x_fc_facility_id` from related (workcenter only) to a proper compute that falls back to production_id.x_fc_facility_id. Stub workcenters auto-created from process node names usually have no facility — the MO always does (from #2 above). **4. Thickness reading calibration_std (fp.thickness.reading)** - `calibration_std_ref` is now `required=True` with sensible default ("NiP/Al STD SET SN 100174568"). Nadcap mandates which calibration standard the gauge was checked against — without it the cert data has no chain back to a metrology record. **5. Delivery POD gate (fusion.plating.delivery)** - action_mark_delivered() raises UserError if no `pod_id`. Driver must capture POD on the iPad (recipient signature + photos + notes) BEFORE marking delivered. Without POD there's no signed receipt to back the invoice or defend a delivery dispute. **6. Certificate spec_reference gate (fp.certificate)** - action_issue() raises UserError if no `spec_reference`. The cert ATTESTS to a spec — leaving it blank produces a piece of paper that AS9100 / Nadcap auditors will (rightfully) reject. **Simulator updated**: scripts/fp_e2e_workforce.py - Sets net-30 on the test customer + ensures a default facility - New PHASE 4c: 5 negative tests (one per new gate), each wrapped in a SAVEPOINT so SQL constraint violations don't abort the txn - Driver now creates POD on iPad BEFORE marking delivered **Final E2E**: 48 PASS / 2 WARN / 0 FAIL out of 50 checks. The 2 remaining WARNs (bake-window auto-create, first-piece gate) are expected behaviour — both are coating-driven and the test coating intentionally doesn't trigger them. All 7 negative tests now pass: ✓ Test 1: WO start without operator → blocked ✓ Test 2: WO start on wet WO without bath/tank → blocked ✓ Test 3: MO confirm without facility → blocked ✓ Test 4: Cert issue without spec_reference → blocked ✓ Test 5: Delivery delivered without POD → blocked ✓ Test 6: Invoice post without payment terms → blocked ✓ Test 7: Thickness reading without cal std → blocked (DB NOT NULL) Audit script (scripts/fp_required_fields_audit.py) committed too — it's the diagnostic that surfaced these gaps and can be re-run to catch new ones. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
gsinghpal
|
4161f04b0f |
feat(plating): hard-required fields on WO start — operator + bath + tank
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>
|
||
|
gsinghpal
|
bbbd222b89 |
feat(plating): close 2 workflow gaps surfaced by workforce E2E simulation
Built a comprehensive simulator (scripts/fp_e2e_workforce.py) that
role-plays 10 employees driving an order quote → invoice using real
operator timers (button_start / button_finish with elapsed time.sleep).
Initial run: 31 PASS / 2 WARN / 0 FAIL exposed two gaps that would
hurt a real shop:
**Gap 1 — Thickness readings never reached the CoC**
The Fischerscope readings inspectors take during post-plate inspection
had no path to the CoC. The cert came out empty, useless for AS9100
or aerospace audits.
Fixes:
- New tablet endpoint `/fp/shopfloor/log_thickness_reading` so the
inspector can record one reading at a time during the inspection WO
(auto-numbers, defaults the operator, supports microscope image).
- mrp_production._fp_mark_done_post_actions now bulk-links any
orphan thickness readings (those with production_id=mo.id but no
certificate_id) to the freshly-created CoC. So inspectors can log
during inspection AND the cert PDF picks them up automatically.
**Gap 2 — Operator queue leaked other people's work + simulator missed it**
fusion.plating.operator.queue.build_for_user pulled EVERY ready /
in-progress WO regardless of assignment. Tom would see John's masking
WO in his "Up Next" list — bad for aerospace traceability where you
want strict per-operator accountability.
Fix: build_for_user now filters MRP WOs by
`(x_fc_assigned_user_id == user_id OR x_fc_assigned_user_id == False)`.
Operators see their own assigned tasks first, plus any unassigned
tasks anyone can grab. Other operators' assigned WOs no longer leak
through.
Also caught: simulator was using wrong field name on the queue model.
Fixed and added a "queue isolation" check that verifies no operator
sees another operator's assigned WOs.
After fixes: **39 PASS / 2 WARN / 0 FAIL** (out of 41 checks).
Remaining WARNs are both expected behaviour:
- bake-window auto-create: this coating doesn't require_bake_relief
(the recipe has an inline Oven step instead)
- first-piece gate: same — coating-driven, only fires when needed
Areas validated end-to-end:
- quote → SO with PO# carried into client_order_ref
- SO confirm → MO + portal job auto-created
- receiving qty prefill + accept
- 9 WOs generated from recipe + assigned to specific operators
- All 9 WOs ran with real elapsed timers + 17 productivity records
across 4 distinct operators
- MO done triggers CoC auto-issue with 5 thickness readings linked,
319 KB rich PDF, customer-slug filename
- Delivery auto-created with prefilled date + driver + CoC link
- Delivery delivered, 2 chain-of-custody entries
- Invoice posted (NOT auto-paid)
- All 5 customer notifications fired (so_confirmed +
parts_received + mo_complete + shipped + invoice_posted) with
correct attachments
- Portal job → complete, SO workflow_stage → invoicing
- Chemistry log persisted, operator proficiency tracked
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|