128d51755d
Builds 7-8 orders in each of 13 workflow states to simulate a full pipeline: - Quotation (sale.order draft) - Quote Sent (sale.order sent) - Order Confirmed / Job Confirmed - Job In Progress (Early + Mid) - Job On Hold (with quality hold) - Job Done / Delivery Draft - Delivery Scheduled / En Route / Delivered - Invoice Draft / Posted / Paid Each record fills detailed fields: PO numbers, commitment dates, operator assignments, timelogs, thickness readings on certs, delivery contacts/vehicles/drivers, payment journals, etc. Idempotency-ish: each order wrapped in a savepoint so one failure doesn't crash the whole seed. Workflow walkthrough findings encoded in script header docstring, including the gotchas: (1) SO action_confirm creates fp.job in DRAFT state with 0 steps — must call action_confirm + _generate_steps_from_recipe explicitly; (2) invoice_payment_term_id is REQUIRED to post invoices; (3) account.payment.action_validate moves payment to 'paid' but invoice goes to 'in_payment' (not 'paid' — Odoo 19 design, requires bank reconciliation for full 'paid' state). Part of: native job model migration (spec 2026-04-25) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Native job migration scripts
migrate_to_fp_jobs.py
Copies live mrp.production / mrp.workorder records into the native
fp.job / fp.job.step model. Idempotent — safe to run multiple times.
Usage
Run from the host (e.g. entech) using odoo shell:
ssh pve-worker5 "pct exec 111 -- bash -c 'su - odoo -s /bin/bash -c \"/usr/bin/odoo shell -c /etc/odoo/odoo.conf -d admin\" < /mnt/extra-addons/custom/fusion_plating_jobs/scripts/migrate_to_fp_jobs.py'"
Or interactively from odoo shell (Python exec builtin, not a shell call):
exec(open('/mnt/extra-addons/custom/fusion_plating_jobs/scripts/migrate_to_fp_jobs.py').read())
What it does
- For every
mrp.productionrecord, creates a parallelfp.jobwith the same name and fields. Skips MOs that already have a fp.job mirror (fp.job.legacy_mrp_production_id == mo.id). - For every
mrp.workorderrecord, creates a parallelfp.job.step. Skips already-migrated WOs. - Migrates
mrp.workorder.time_idstofp.job.step.timelog. - Rebinds cross-references on dependent models (batches, holds, certs, deliveries, portal jobs, racking inspections).
- Audit log written to
/tmp/fp_jobs_migration.logand to a chatter post on each migrated job.
Safety
- Idempotent. Re-running skips already-migrated records.
- Read-only on legacy MO/WO records. Original data untouched.
- Cross-reference rebinds add new x_fc_job_id / x_fc_step_id values without removing legacy production_id / workorder_id values. Both stay populated for the 2-week shadow period.
- Wrap in a transaction (default for
odoo shell); if anything fails, rollback.
Pre-migration audit
Run audit_pre_migration.py first to see what's about to happen. The
script uses Python's exec builtin to load the file inside the running
shell session — no shell exec involved.
Reports counts of MO/WO/dependent records and any data-quality concerns (MOs with no recipe, WOs with no work centre, etc).
Post-migration audit
Run audit_post_migration.py after to verify counts match.
Reports row counts on fp.job, fp.job.step, and confirms all dependent records have new x_fc_*_id values.