beb6ddc5e5
All docs moved with git mv so --follow preserves history. Flattens the single-folder layout into goal-oriented folders and adds a README.md index at every level. - docs/README.md — new landing page with "I want to…" intent table - docs/architecture/ — overview, data-model, app-design - docs/features/ — billing-payments, cpe-management, vision-ocr, flow-editor - docs/reference/ — erpnext-item-diff, legacy-wizard/ - docs/archive/ — HANDOFF-2026-04-18, MIGRATION, status-snapshots/ - docs/assets/ — pptx sources, build scripts (fixed hardcoded path) - roadmap.md gains a "Modules in production" section with clickable URLs for every ops/tech/portal route and admin surface - Phase 4 (Customer Portal) flipped to "Largely Shipped" based on audit of services/targo-hub/lib/payments.js (16 endpoints, webhook, PPA cron, Klarna BNPL all live) - Archive files get an "ARCHIVED" banner so stale links inside them don't mislead readers Code comments + nginx configs rewritten to use new doc paths. Root README.md documentation table replaced with intent-oriented index. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
86 lines
4.4 KiB
Markdown
86 lines
4.4 KiB
Markdown
# Status — 2026-04-19 (wizard legacy-alignment refinement) — ARCHIVED
|
|
|
|
> **⚠️ ARCHIVED snapshot.** For current state, see [../../roadmap.md](../../roadmap.md).
|
|
|
|
> Follow-up to [2026-04-18b.md](2026-04-18b.md). Small session: reviewed the legacy
|
|
> wizard (`facturation.targo.ca/.../client_wizard`), realized the initial
|
|
> preset model fought the real workflow, refactored.
|
|
|
|
## What changed this session
|
|
|
|
### Wizard presets — now additive, not replacing
|
|
The first pass of RESIDENTIAL_PRESETS replaced the cart. That conflicts with
|
|
how the shop actually sells: a typical residential deal is **Installation
|
|
Internet + Installation Téléphonie + Installation Télé + Ajout WiFi** — four
|
|
presses that stack.
|
|
|
|
Legacy audit (`docs/legacy-wizard/account_wizard.php`) confirmed the model:
|
|
the PHP wizard has no "presets" at all — it has 4 independent sections with
|
|
checkboxes. Adding Internet adds lines; adding Phone adds more lines; the
|
|
combo rebate (legacy RAB2X/RAB3X/RAB4X, IDs 556/557/558) is computed
|
|
automatically from the count of distinct combo-eligible service types.
|
|
|
|
**Our presets are now building blocks:**
|
|
- `preset_internet_install` — service_type `internet`, combo_eligible
|
|
- `preset_phone_install` — service_type `phone`, combo_eligible
|
|
- `preset_tv_install` — service_type `tv`, combo_eligible
|
|
- `preset_wifi_addon` — service_type `addon`, NOT combo_eligible (ajout seul)
|
|
|
|
Each press **appends** its items. Item codes are deduped so double-clicking
|
|
a preset is idempotent (no accidental doubles).
|
|
|
|
### Auto combo rebate
|
|
`recomputeComboRebate()` in [apps/ops/src/composables/useWizardCatalog.js](apps/ops/src/composables/useWizardCatalog.js):
|
|
- Counts distinct `service_type`s across recurring + combo_eligible items.
|
|
- 2 services → Rabais combo 2 services (-5$/mois)
|
|
- 3 services → Rabais combo 3 services (-10$/mois)
|
|
- 4+ services → Rabais combo 4 services (-15$/mois)
|
|
- Under 2 → removes the rebate line automatically.
|
|
|
|
Tune amounts in `apps/ops/src/data/wizard-constants.js → COMBO_REBATES`.
|
|
|
|
Driven by `watch(orderItems, recomputeComboRebate, { deep: true })`. The
|
|
function is **idempotent** — compares `rate`, `item_name`, `contract_months`
|
|
against the existing rebate line before mutating, so the deep watch can't
|
|
spiral into an infinite loop.
|
|
|
|
### Ad-hoc items still work
|
|
Per the "one simple way + ad-hoc onetime" directive: presets get the
|
|
common composition in one click, but the catalog picker + "+ Ajouter un
|
|
item" row are unchanged, so an agent can still add a router, an install
|
|
fee, or any catalog item on top.
|
|
|
|
## Files touched this session
|
|
```
|
|
apps/ops/src/data/wizard-constants.js presets reshaped + COMBO_REBATES
|
|
apps/ops/src/composables/useWizardCatalog.js applyPreset additive + recomputeComboRebate
|
|
docs/legacy-wizard/ legacy PHP wizard copy for reference
|
|
docs/STATUS_2026-04-19.md this file
|
|
memory/project_contract_acceptance.md Wizard integration section
|
|
```
|
|
|
|
## Deployed
|
|
Ops app rebuilt and deployed 2026-04-19 ~08:25 EDT.
|
|
Live bundle: `index.9ca1cb6e.js`. Hard-reload to pick up.
|
|
|
|
## Verification checklist (please run when you're back)
|
|
1. Open a customer → Soumissions → "+ Nouvelle soumission".
|
|
2. Press **Installation Internet** → 1 line Internet 500 + 1 line frais (0$, regular 75$).
|
|
3. Press **Installation Téléphonie** → appends tel line. **Rabais combo 2 services (-5$/mois)** should appear automatically.
|
|
4. Press **Installation Télé** → appends IPTV line. Rebate upgrades to **3 services (-10$/mois)**.
|
|
5. Press **Ajout WiFi** → router line appended but rebate stays at 3 services (WiFi is not combo_eligible).
|
|
6. Remove Télé → rebate downgrades to 2 services (-5$).
|
|
7. Publish with JWT acceptance → Quotation created + Service Contract created + SMS sent.
|
|
|
|
If the rebate gets "stuck" or duplicates appear, screenshot the cart and
|
|
send — the idempotency check may need tightening.
|
|
|
|
## Known follow-ups (deliberately deferred)
|
|
- Rebate amounts are hard-coded in `COMBO_REBATES`. Should eventually read
|
|
from legacy item IDs 556/557/558 (or their ERPNext equivalents once migrated).
|
|
- `combo_eligible` is currently a preset-level flag. If ad-hoc catalog items
|
|
should participate in combo counting, the catalog model needs a
|
|
`combo_ready` column (legacy has one).
|
|
- Commercial flow still piggybacks on acceptance-method toggle. A proper
|
|
`contract_type` toggle in the wizard would decouple the two.
|