glennandClaude Opus 5
5aee1c61b5
Built a full demo against a real BuildEase instance and three documented facts turned out to be wrong, each costing a debugging round. buildease installs nothing. Its manifest depends on base alone, so the "depends on nothing and installs the set" line left an empty database with no error to catch it. Route and install every module explicitly. The purge chain had invoices after statements. An invoiced sale.progress refuses action_cancel outright -- cancelling its invoice is what reverts it to approved, the first state it can be cancelled from. The documented order deadlocks on the one statement you invoiced. custom_product_sale, custom_product_bom and bom_on_sale_order_line are absent from mev but present on the Callista demo servers, so "not in the repo" is not the same as "not installable" when pricing. Also records the revision-formula object graph, which no reference covered: the coefficients live on formula.input, not on revision.formula, and that model hangs off either the take-off (contract S, I) or the statement (that period's s, i). That split is what makes "de index van die maand, niet van vandaag" work. Its rows come from an @api.onchange that write() never fires over XML-RPC, and a stale initial_index_value computes a plausible but wildly wrong revision with no guard behind it -- a factor of 65 instead of 1.005 in this build. Plus: percentage is a cumulative fraction not 0-100, index_value truncates to 3 decimals, and button methods return an action dict Odoo cannot marshal over XML-RPC after the transition has already committed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
89 lines
6.2 KiB
Markdown
89 lines
6.2 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.
|
|
|
|
**`buildease` is a marker, not an installer.** Its manifest depends on `base` and nothing
|
|
else, so installing it pulls in none of the other 33. Verified on a live 19.0+e instance:
|
|
`buildease` on its own leaves the database empty and every routed feature missing, with no
|
|
error to catch it. Always install the routed set explicitly.
|
|
|
|
## 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.
|
|
**Not in the repo does not mean not on the instance.** On the Callista demo servers all
|
|
three are present and installable — they ship with the `demo19-custom` addons path, not
|
|
with mev. Check the target instance (`ir.module.module` by name) before pricing
|
|
`buildease_custom_product*` as build work; on a server that already has them it is a
|
|
install line, and on a client's own Odoo.sh it is not.
|
|
- **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.
|