Commit Graph

19 Commits

Author SHA1 Message Date
gsinghpal
bd2c037a97 Update 2026-05-13-nfc-clock-kiosk-plan.md 2026-05-14 07:07:45 -04:00
gsinghpal
91d3a3f9d1 docs(fusion_clock): use actual docker env names (odoo-modsdev-app/modsdev) in NFC plan 2026-05-14 00:14:51 -04:00
gsinghpal
85eddba546 docs(fusion_clock): NFC clock kiosk implementation plan
20-task TDD plan for the NFC clock kiosk feature spec'd in
2026-05-13-nfc-clock-kiosk-design.md. Bite-sized steps with full code
in each, ordered: data model -> config -> backend endpoints ->
SCSS+template -> JS state machine -> NFC + camera -> Enroll Mode ->
debug shortcut -> version bump.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-14 00:05:23 -04:00
gsinghpal
48d3e48e61 docs(fusion_clock): NFC clock kiosk design
Design for tap-to-clock NFC kiosk in fusion_clock. Pilot scope: 1
station per company, Samsung Galaxy Tab Active 5 Pro running Web NFC
in Chrome kiosk mode. Reuses Ubiquiti-issued cards. Silent photo
verification via front camera. Backend reuses FusionClockAPI helpers.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 23:50:00 -04:00
gsinghpal
c85a9bbf82 docs: nexa_coa_setup implementation plan
Bite-sized task plan to implement the CoA design against odoo-nexa
nexamain database. 12 phases:
0. Safety backup + staging clone
1. Module skeleton (nexa_coa_setup)
2. Chart of accounts (~110 new accounts across 1-6xxxxx)
3. Analytic plans (Project, Department, SR&ED Tag)
4. Hooks for archive-unused / rename-legacy
5. Tax cleanup
6. 8 fiscal positions with auto-detect
7. Service product categories
8. Westin/Divine partner records (RP-Associated tag)
9. 8 bank reconciliation rules
10. End-to-end test invoices (ON, US, intercompany)
11. Apply to production (with explicit GO/NO-GO gate)
12. Operating runbook

Each task has a verify-before / change / verify-after / commit cycle.
Staging clone (nexamain_staging) used for every phase before prod.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 18:05:33 -04:00
gsinghpal
daf1235e20 docs(nexa-coa): annual HST + T2 filing cadence; HST# normalization
Captures user-confirmed CRA registration & filing setup:
- Annual GST/HST filer (return Mar 31, instalments if prior net tax ≥ \$3k)
- Annual T2 filer (return Jun 30, balance due Mar 31 for CCPC)
- HST# 741224877 currently stored as 9-digit BN root only; normalize to
  full 15-char '741224877 RT0001' for tax-report validation
- Quick Method opportunity downgraded — \$400k threshold applies to
  associated-group totals; Nexa+Westin+Divine combined likely exceeds it
- Add HST cadence escalation flag (quarterly auto-trigger at \$1.5M)
- Acceptance criteria expanded with HST# format, filer config, and
  intercompany invoice test case

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 13:20:16 -04:00
gsinghpal
3d4f003aba docs(nexa-coa): treat Westin & Divine as associated corps
Restructure Section 9 to handle Westin Healthcare Inc and Divine Mobility
Inc as Gurpreet's associated corporations (ITA s.256):
- Future intercompany flows go through normal AR/AP with partner records
  tagged 'RP-Associated', not slush 'Due to/from' GL buckets
- 'Due to/from Associated Corporations' now reserved only for true
  intercompany loans (no invoice)
- Surface SBD $500k sharing and SR&ED $3M sharing rules; Schedule 23
  allocation drives major annual tax decisions
- Manpreet account archived (employee of another corp, not Nexa-related)
- Add transfer-pricing risk flag (ITA s.247, 10% penalty)
- Add multi-company Odoo as future sub-project

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 13:18:52 -04:00
gsinghpal
6e67fc5ce3 docs: nexa systems CoA + accounting setup design spec
Comprehensive chart-of-accounts redesign for odoo-nexa nexamain DB:
hybrid approach over l10n_ca, three analytic plans (Project/Department/SR&ED
Tag), fiscal positions for auto tax handling, cleanup plan for the
~370 unused accounts and 49 messy taxes, automation hooks via product
categories and bank reconciliation rules.

Goals: CRA compliance, SR&ED claim infrastructure, zero-rated export
handling, one-click invoicing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 13:08:40 -04:00
gsinghpal
d3b4eadbec test(sub3): Sub 3 smoke + verify SQL; mark shipped in CLAUDE.md roadmap
Sub 3 (Default Process + Composer per Part) complete:
 - Phase A: schema additions (part_catalog_id, cloned_from_id,
   treatment_uom on process_node; default_process_id on part_catalog),
   opt_in_out label rename, General Processing seed flipped to
   noupdate=1
 - Phase B: part-scoped Process Composer client action
   (fp_part_process_composer) with 3 RPC endpoints + OWL wrapper +
   Process tab on part form with Compose button
 - Phase C: tree node MO-state palette (green=completed, blue=active,
   red=error-only)

All 8 Sub 3 smoke checks green. Phase 1-3 QC smoke + E2E still green.
Sub 2 features untouched.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 09:06:41 -04:00
gsinghpal
817fdb4948 docs(plating): Sub 3 design spec \u2014 Default Process + Composer per Part 2026-04-22 08:44:06 -04:00
gsinghpal
afd8bae514 fix(configurator): programmatic SO-line create fallback for x_fc_internal_description
When Sub 2 Task 26 flipped x_fc_internal_description to required=True,
any programmatic sale.order.line creation that doesn't set the field
fails at the Postgres NOT NULL constraint. Callers include:
 - sale_mrp stock-move line creation (doesn't set name either)
 - demo seeders
 - external integrations
 - test scripts

The UI-side onchange populates the field when the user picks a
description template; this hook mirrors that for programmatic callers.
Fallback chain: explicit vals['x_fc_internal_description'] → vals['name']
→ product_id.display_name → '—'. Matches the migration's backfill rule.

Also adds Sub 2 end-to-end smoke test (6 cases, all green):
 1. Required-field rejection on part creation
 2. Required-field rejection on template creation
 3. Template picker populates both SO-line descriptions
 4. Cert resolver: part-level override wins over partner
 5. display_name renders part_number + revision + name
 6. certificate_requirement defaults to 'inherit'

QC Phase 1-3 regression suite remains green after the fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 23:34:32 -04:00
gsinghpal
8cea92cca4 test(sub2): cert-resolver edge cases (Task 11) 2026-04-21 20:23:32 -04:00
gsinghpal
fb2f360e7b test(sub2): migration verification SQL (Task 6) 2026-04-21 20:15:42 -04:00
gsinghpal
418dabc688 docs(plating): Sub 2 implementation plan (30 tasks, 3 phases)
Full bite-sized plan matching the approved spec. Each task has file
paths, complete code, syntax-check commands, upgrade commands, expected
outputs, and commit messages.

Phase A (Tasks 1-12): additive schema + migration + cert-resolver.
System runnable throughout.

Phase B (Tasks 13-23): UI + QWeb macro + report rewiring. Users see new
fields. Old fields still exist.

Phase C (Tasks 24-30): flip required=True, drop legacy column, regression,
deploy to entech.

Self-review pass: every spec section mapped to a task; no TBD/TODO/placeholder.
Type signatures (_fp_resolve_cert_requirement, display_name, macro
params) consistent across tasks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 20:02:34 -04:00
gsinghpal
a15b75e38a docs(plating): fine-tuning initiative roadmap + Sub 2 design spec
Captures the current state of the system-wide fine-tuning initiative so a
fresh Claude Code session can resume without context loss.

CLAUDE.md additions (fusion_plating/CLAUDE.md):
* Sub-project roadmap (Sub 1 through 8 + two deferred items)
* Sub 2 locked decisions (Q1–Q6 answers)
* Sub 2 defensive measures that prevent rework when later subs land
* Sub 6 / 7 / 8 previews from the client transcript
* Client-confirmed operational thresholds (tank polling, active tanks)
* How to resume in a fresh session

Sub 2 design spec (docs/superpowers/specs/):
* Part Data Model Overhaul — covers gaps 2b, 2c, 2d, 4
* 12 sections: scope, data model, migration, UI, cert resolution,
  reports, testing, defensive measures, files touched, rollout,
  success criteria, open questions
* All clarifying questions answered; zero placeholders
* Ready for writing-plans skill to generate implementation plan

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 19:53:40 -04:00
gsinghpal
c66bdf5089 changes 2026-04-03 15:45:18 -04:00
gsinghpal
126264217e Add Fusion WooOdoo implementation plan (30 tasks, 9 phases)
Comprehensive plan covering Odoo module scaffold, core models, API client,
views/menus, sync engine (webhooks + cron), wizards, OWL frontend,
WordPress plugin, order lifecycle, advanced features (tax mapping,
pricelist sync, multi-currency, refund handling), and deployment.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 19:54:10 -04:00
gsinghpal
149a45a752 Fix remaining spec review issues (round 2)
Add company_id to woo.shipment, woo.sync.log, woo.return.line. Add
order_id to woo.conflict for order-type conflicts. Add _odoo_messages
to WP meta table. Fix section numbering. Document lib/ import path.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 19:37:30 -04:00
gsinghpal
a1c479f916 Add Fusion WooOdoo design specification
Complete design spec for bidirectional Odoo 19 <-> WooCommerce sync system
covering product mapping, order lifecycle, inventory sync, customer portal,
and all supporting data models. Addresses all review findings including
variant support, tax/pricelist mapping models, return/RMA workflow,
multi-shipment tracking, and Odoo 19 technical requirements.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 19:35:02 -04:00