glennandClaude Opus 5
96d02fe0d7
Most of this skill was never construction-specific. Phase A (discovery brief from any source), the two-agent parallel build, the generic purge craft and Phase C (follow-through docs) applied to any Odoo demo — but sat behind a BuildEase trigger, so Callista's plain Odoo implementations could not reach them and still ran upstream's Knowcap-bound step 1 with no follow-through. Those moved to callista-odoo-demo (Callista's fork of Smetools/odoo-demo- architect, which we cannot PR). What is left here is the part that is actually about construction, expressed as five overlays on named substrate steps: module routing, solution precedence, demo-data policy, purge chain, and follow-through framing. SKILL.md goes from 208 lines to 119. Nothing BuildEase-specific was dropped — the take-off-without-a-sale-order trap, the dynamic-article-template-line pin, the settings-default-off walk, the booked-vs-ordered-hours check and the custom_product_* dependency gap all survive. Two rules now carry the boundary: anything needed that is not one of the five overlays is a gap to fix in the substrate rather than work around here, and substrate steps are referenced by name, never by number — numbering was how an upstream renumber could silently misroute this skill. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
79 lines
5.5 KiB
Markdown
79 lines
5.5 KiB
Markdown
# BuildEase (callista-tools/mev) — module map & pain routing
|
|
|
|
Odoo **19.0** vertical for construction / contracting. Repo: `git@github.com:callista-tools/mev.git`.
|
|
34 modules, all LGPL-3. Umbrella module `buildease` depends on nothing and installs the set.
|
|
|
|
## The four core concepts
|
|
|
|
| Concept | Model | What it replaces at the client |
|
|
|---|---|---|
|
|
| **Quantity Take-Off (QTO)** | `quantity.take.off`, `.line`, `.line.calculation` | The measurement/estimating spreadsheet that gets re-keyed into a quote |
|
|
| **Sale Progress** | `sale.progress`, `sale.progress.line` | Monthly progress statements (BE: *vorderingsstaat*) and % -complete invoicing |
|
|
| **Adjustments** | `adjustment.create` + QTO/SP extensions | Variation orders / change orders (BE: *verrekeningen*) |
|
|
| **Revision formula** | `revision.formula`, `revision.scheme`, `revision.parameter`, `index.value.date` | Contractual price-indexation formulas on progress statements |
|
|
|
|
A QTO holds lines; lines hold *calculation* lines (the measurement math). QTO → sale order → project → progress statements → invoices is the spine of every demo.
|
|
|
|
## Pain → module routing
|
|
|
|
Match the client's own words on the left; install the right.
|
|
|
|
| Client says | Install |
|
|
|---|---|
|
|
| "we measure in Excel then re-type it into the quote" | `quantity_take_off_base`, `quantity_take_off_sale` |
|
|
| "every project starts from the same standard items" | + `quantity_take_off_base` template sets (`quantity.take.off.line.template.set`) |
|
|
| "the same item recalculates from a few parameters" | `quantity_take_off_dynamic_calculation` |
|
|
| "we add a % for general costs / site overhead" | `quantity_take_off_overhead` (+ `_dynamic_calculation_overhead` if both) |
|
|
| "we invoice monthly on % complete" / "vorderingsstaat" | `sale_progress_base` |
|
|
| "prices are indexed per the contract formula" | `sale_progress_revision_formula` |
|
|
| "extra work / change orders are a mess" | `adjustments_base` (+ `sale_progress_revision_formula_adjustments` if both) |
|
|
| "hours worked must land on the progress statement" | `sale_progress_base_timesheet`, `adjustments_base_timesheet` |
|
|
| "subcontractors send us their own progress statements" | `sale_progress_purchase` (`subcontractor.progress.statement.wizard`) |
|
|
| "we ask 3 suppliers for prices per item" | `quantity_take_off_purchase` (`purchase.request.wizard`, uses `purchase_requisition`) |
|
|
| "made-to-order items priced from their bill of materials" | `buildease_custom_product`, `buildease_custom_product_bom_price_sync` (+ `_overhead`) |
|
|
| "the client has to sign off" | `quantity_take_off_sale_signature`, `sale_progress_base_signature` |
|
|
| "plans and datasheets must be on the site project" | `project_product_documents_link` |
|
|
| "we track material deliveries to site" | `quantity_take_off_sale_stock`, `_sale_delivery` |
|
|
| "one project, many purchase orders" | `quantity_take_off_sale_project_purchase`, `_project_stock` |
|
|
| "our techs do call-outs / maintenance visits" | `quantity_take_off_sale_industry_fsm` |
|
|
| "recurring maintenance contracts" | `quantity_take_off_sale_subscription` |
|
|
| "estimates start from a lead" | `quantity_take_off_sale_crm` |
|
|
| "supplier article numbers differ from ours" | `quantity_take_off_extra_article_nr` |
|
|
| "same item in several sizes/finishes" | `sale_quantity_takeoff_variant` |
|
|
| "management wants margin per project" | `sale_progress_quantity_take_off_report` (QTO carries `margin`, `margin_percentage` natively) |
|
|
| "we live in spreadsheets" | `quantity_take_off_spreadsheet` |
|
|
|
|
## Demo data — `buildease_demo_data` is the OLD way
|
|
|
|
**Do not install `buildease_demo_data` or `buildease_demo_data_sale_progress` by default.**
|
|
They are the previous generation of environment setup: one fixed Belgian construction
|
|
dataset, the same for every prospect. This skill replaces them — demo data is generated
|
|
per client from the discovery brief and loaded through `callista-odoo-demo`'s
|
|
`scripts/build_demo.py` / `demo_config.json`.
|
|
|
|
Install them only if the user explicitly asks, or when there is genuinely no client
|
|
context and a generic sandbox is wanted. If you do, know what comes with them:
|
|
`sale_management, purchase_stock, project, timesheet_grid, sale_timesheet, maintenance,
|
|
quantity_take_off_sale, industry_fsm, l10n_be, accountant, uom` — including the Belgian
|
|
localisation, which is wrong for most non-BE clients.
|
|
|
|
The app-level dependencies that dataset used to drag in (`sale_management`, `project`,
|
|
`purchase_stock`, `sale_timesheet`, `industry_fsm`, `accountant`, `uom`) still need
|
|
installing on their own — route them from the pain table above, not from the demo bundle.
|
|
|
|
## Gotchas
|
|
|
|
- **Three dependencies are not in this repo**: `custom_product_sale`, `custom_product_bom`,
|
|
`bom_on_sale_order_line`. Anything under `buildease_custom_product*` fails to install
|
|
without them. Confirm their source before promising a BOM-pricing hero feature.
|
|
- **Odoo 19 only.** Manifests are all `19.0.x`; do not attempt against 17/18.
|
|
- `l10n_be` and `accountant` are pulled in by demo data — the demo DB is Belgian-localised.
|
|
Wrong-country client → set `demo_config.json` company/fiscal position explicitly, or skip
|
|
`buildease_demo_data` and stage minimal data instead.
|
|
- `quantity.take.off` inherits `mail.thread` + `mail.activity.mixin` — chatter and activities
|
|
work for free, good cheap demo beats.
|
|
- `res.config.settings` and `res.company` are extended by 8 modules each. After installing,
|
|
walk Settings once; several BuildEase behaviours are off by default.
|
|
- `post_migrate.py` sits at repo root — relevant when upgrading an existing demo DB, not a
|
|
fresh build.
|