Construction Subcontractor Management

核心功能

`construction.subcontract` model holding contract sum, schedule of values, retention rule and analytic/project link, with a statusbar workflow guarded in Python rather than by view attrs alone

Schedule-of-values lines with quantity, rate, `previously_claimed` and computed `remaining_value`, so over-claim is arithmetically impossible rather than a review step

`construction.subcontract.claim` with `@api.depends` computes for amount this period, cumulative, retention held, back-charges and net certified — the certified figure is derived, never keyed in

Two-stage assessment and certification separated by `ir.model.access.csv` groups plus `ir.rule` record rules, so assessing and certifying cannot be done by the same user where segregation of duties is required

Retention ledger per subcontract with configurable held percentage and split release triggers (practical completion and end of defects liability), posted to a dedicated liability account

Retention release wizard that generates the release vendor bill and reverses the held balance, with a per-project retention statement QWeb report

Back-charge records typed by category (materials supplied, plant hire, rectification, site services, levies) that post as negative lines on the certified vendor bill against their own accounts

Automatic vendor bill creation through the standard `account.move` API on certification — no shadow ledger, so aged payables, analytic cost and project P&L reconcile without adjustment

`construction.subcontract.document` compliance register with typed slots, issue/expiry dates and a computed `is_valid`, blocking certification when a mandatory document has lapsed

Nightly `ir.cron` plus `base.automation` rules escalating insurance, licence and tax-clearance expiries at 30/14/7 days to both the buyer and the subcontractor contact

QWeb payment certificate PDF issuable to the subcontractor, plus back-charge schedule and subcontract cost-to-complete reports reading through analytic lines

Variation and provisional-sum handling that adjusts the approved contract value and flows into the over-claim ceiling, with a full audit trail on the subcontract chatter

Portal-optional subcontractor submission so trades enter their own claim quantities against the schedule of values, arriving as `submitted` for your assessment

Full XML-RPC / JSON-RPC surface on every model for site apps, BI extracts and document-store integrations, with no custom endpoint to maintain

Installs on Odoo 17.0, 18.0 and 19.0 against Community dependencies only, with optional Enterprise hooks (Documents, Sign, Approvals) behind soft dependencies

按需定制，全程代劳

无需自行搭建——由 ECOSIRE 构建、安装并提供支持的可用应用。

您下单

以一次性构建价格开始。我们在启动时与您共同确定范围。

我们构建与安装

ECOSIRE 在您的 Odoo 上构建、配置并安装。

上线 + 支持

约 2–4 周内上线，并提供上线后的支持期。

关于此产品

Main contractors do not lose money on the head contract — they lose it in the gap between what a subcontractor claimed, what the quantity surveyor certified, what was actually paid, and what was withheld. In stock Odoo that gap is invisible. A subcontract package lives as a purchase.order, which assumes a quantity of goods delivered against a receipt; it has no concept of a schedule of values, a cumulative claim, a certified-this-period amount, or a retention percentage held against practical completion. Progress claims end up in a spreadsheet, retention lives in a QS's head, and back-charges (the crane hire you provided, the rectification you paid another trade to redo, the site clean-up levy) get remembered at final account time — or not at all. Odoo Enterprise's Project and Field Service apps track your own labour, not a third party's contractual entitlement, and no core model carries an expiry-dated insurance certificate that must block a payment.

What we build is a subcontract layer that sits beside Purchase and Accounting rather than fighting them. A new construction.subcontract model holds the package: the subcontractor partner, the parent project or analytic account, the contract sum, the retention rule (percentage held, percentage released at practical completion, percentage at end of defects liability), and a schedule-of-values line set with quantities, rates and a previously_claimed field. Against it, construction.subcontract.claim records each period's claim with @api.depends computes for amount_this_period, amount_cumulative, retention_held, back_charges_total and amount_certified_net — so the certified figure is derived, never typed. A statusbar workflow (draft → submitted → assessed → certified → invoiced → paid) is enforced by Python guards and by record rules in ir.model.access.csv plus ir.rule definitions, so a site engineer can assess but only a commercial manager can certify, and nobody can certify a claim whose cumulative value exceeds the contract sum plus approved variations. On certification we generate the vendor bill through the standard account.move API with the retention posted to a dedicated liability account and each back-charge posted as a negative line against its own account, so your trial balance, aged payables and project P&L all agree without a reconciliation exercise.

The compliance register is the part that pays for itself. construction.subcontract.document carries typed document slots — public liability and workers' compensation insurance, licence or registration number, tax clearance, method statement, RAMS, warranty — each with an issue date, expiry date and a computed is_valid. An ir.cron running nightly plus automated actions (base.automation) escalate at 30, 14 and 7 days before expiry to the buyer and the subcontractor's contact, and a configurable hard gate refuses certification while a mandatory document is expired. Reporting is QWeb: a payment certificate PDF suitable for issuing to the subcontractor, a retention statement per project, a back-charge schedule, and a subcontract cost-to-complete report reading through the analytic lines. Everything is exposed over XML-RPC and JSON-RPC with the standard search_read/create/write surface, so a site app, a Power BI dataset, or your existing document store can read and post without a custom endpoint. The module targets Odoo 17.0, 18.0 and 19.0 and is written against Community — Purchase, Accounting and Analytic are the only hard dependencies in __manifest__.py. If you run Enterprise we wire the optional hooks (Documents for file storage, Sign for the subcontract execution, Approvals for the certification chain) behind a soft dependency so the same codebase installs on either edition.

This is a build-to-order product, not an apps.odoo.com download. You request a quotation, we run a scoping call, and we write down the specifics that actually vary between builders: your retention percentages and release triggers, whether you certify against a schedule of values or a percentage-complete, how variations and provisional sums flow in, which back-charge categories exist, your document types and their expiry rules, and the exact chart-of-accounts codes for retention held and back-charges recovered. That scope becomes a fixed written specification before a line of code is committed. Typical delivery is 2–4 weeks from confirmed scope, depending on how much of the claim workflow and reporting is bespoke.

Delivery runs on a staging copy of your database first. You get the installable source for your exact Odoo version, a UAT pass where your commercial team runs real claims through the workflow, and a documented rollback before we touch production. After go-live you have a support window for defect fixes, and the git repository is handed to you — the code is yours, so you are never locked to us for the next change.

你得到什么

Installable module source built and tested for your exact Odoo version (17.0, 18.0 or 19.0) and edition

Installation and configuration on your staging environment, including retention accounts, back-charge categories, document types and security groups

Technical documentation: model and field reference, workflow state diagram, security matrix, and the XML-RPC/JSON-RPC integration surface

End-user guide for site engineers, commercial managers and accounts, covering claim submission, assessment, certification and retention release

Live training session with your commercial and finance team, recorded for future staff

UAT on a staging copy of your production database with your own subcontracts and claims, plus a written rollback plan before production cutover

Post-go-live support window for defect fixes on the delivered scope

Git repository handover with full commit history — the code is yours to fork, extend or hand to another developer

这是给谁的

Commercial Manager / Quantity Surveyor

Owns the certified number. Needs cumulative claim, retention held and back-charges computed from one source so the payment certificate can be issued the same day it is assessed, and needs an over-claim ceiling that cannot be argued around at final account.

Contracts Administrator

Chases insurance certificates, licences and tax clearances across dozens of trades. Needs a register with expiry dates, automated escalation, and a hard gate that stops a payment going out to a subcontractor whose public liability cover lapsed last month.

Finance Manager / Financial Controller

Needs retention sitting in a real liability account, back-charges posted against their own codes, and vendor bills created through Odoo's own accounting API so aged payables, the project P&L and the trial balance agree without a monthly reconciliation.

Construction IT / ERP Lead

Owns the Odoo estate and the upgrade path. Wants Community-only hard dependencies, clean `ir.model.access.csv` and record rules, no core model patching, a documented RPC surface, and the git repository in hand so the module survives the next major version.

Construction Subcontractor Management 如何比较

标准	伊科西尔	定制建造	竞争对手	Odoo 原生
Progress claim certification	Assess and certify as separate guarded states; certified amount computed from schedule of values, retention and back-charges	Achievable, but the computed fields and workflow guards are the bulk of the build effort you pay for	Usually a single-step claim record with a manually entered certified amount	No claim concept; a purchase order bills against receipt quantities
Retention handling	Per-subcontract retention ledger with split release triggers, posted to a dedicated liability account	Depends entirely on whether your developer models the release triggers, not just the held percentage	Often a percentage field with no ledger and no release workflow	None — retention ends up as a manual journal entry or a spreadsheet
Back-charges	Typed categories posting as negative bill lines against their own accounts, with an audit trail	Commonly deferred to phase two and never built	Rarely covered; deductions are a free-text discount line	Manual credit note or an ad-hoc bill line with no category reporting
Compliance documents	Typed register with expiry dates, nightly cron escalation and a hard gate on certification	Buildable, but the escalation cron and the payment gate are usually cut for budget	Attachment list with no expiry logic or payment enforcement	Generic chatter attachments on the partner, no dates, no enforcement
Accounting integration	Bills created through the standard `account.move` API with analytic distribution — no shadow ledger	Quality varies; direct SQL or duplicate tracking tables are a common shortcut	Usually posts correctly but often ignores analytic distribution to the project	Standard vendor bills, but with no subcontract context to post against
Security and segregation of duties	Dedicated groups in `ir.model.access.csv` plus `ir.rule` record rules separating assess from certify	Frequently ships with a single group and view-level `invisible` attrs only	Typically one manager group for the whole module	Purchase user and manager groups, which do not map to assess-versus-certify
Version support and upgrade path	Built for your exact 17.0, 18.0 or 19.0; Community-only hard dependencies; no core model patching	Upgrade cost depends on whether the original developer inherited cleanly or patched core	Version support varies by author; abandoned modules block your next upgrade	Upgrades with Odoo, but the functionality is not there to upgrade
Ownership and extensibility	Git repository handed over with full history; documented RPC surface for site apps and BI	You own it, but documentation and a clean integration surface are rarely part of the quote	Obfuscated or licence-keyed code in many cases; extension means forking blind	Fully open, but you are building the whole feature yourself

关于Construction Subcontractor Management的常见问题

How long does delivery take?

This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. The clock starts when the written specification from the scoping call is signed off, not when the quote is accepted — retention rules, back-charge categories, document types and account codes all need to be pinned first, because those are what vary between builders.

What support and updates do I get after go-live?

You get a post-go-live support window for defect fixes against the delivered scope, and the full git repository is handed to you so nothing is locked behind us. Version upgrades (for example carrying the module from Odoo 18.0 to 19.0) and new functionality beyond the signed scope are quoted separately as change requests. Because we build against Community dependencies and avoid patching core models, upgrades are usually a small piece of work rather than a rewrite.

Does this work on Odoo Community, or do I need Enterprise?

Community is enough. The hard dependencies in `__manifest__.py` are Purchase, Accounting and Analytic, all available in Community. If you run Enterprise we wire optional integrations — Documents for compliance file storage, Sign for subcontract execution, Approvals for the certification chain — behind soft dependencies, so the same codebase installs cleanly on either edition.

How does this differ from just using Purchase Orders for subcontracts?

A `purchase.order` models goods delivered against a receipt. A subcontract package is a contractual entitlement claimed progressively against a schedule of values, reduced by retention and back-charges, and certified by a named person. Core Odoo has no cumulative-claim field, no retention ledger, no back-charge concept and no certification workflow, so builders end up with the real numbers in a spreadsheet. This module keeps the contractual layer in Odoo and still posts through the standard `account.move` API, so nothing is duplicated.

Can subcontractors submit their own claims?

Yes, optionally. We can expose a portal view where each trade enters claimed quantities against their own schedule-of-values lines; the claim arrives in your database as `submitted` and enters your assessment and certification workflow untouched. Record rules restrict every subcontractor to their own records. If you prefer claims to arrive by email or PDF and be keyed in by your contracts administrator, we scope it that way instead.

How does the retention accounting actually post?

On certification the module creates a vendor bill through Odoo's standard accounting API. The gross certified amount posts to the expense or work-in-progress account with the project's analytic distribution, retention posts as a credit to a dedicated retention-held liability account, and each back-charge posts as a negative line against its own account. Retention release later generates its own bill and clears the liability, so the retention balance on your balance sheet always equals the sum of the per-subcontract retention ledgers.

Will it handle variations and provisional sums?

Yes — variations adjust the approved contract value and therefore the over-claim ceiling, with the change recorded on the subcontract chatter for audit. Provisional sums can be carried as separate schedule-of-values lines that are claimed against once the actual scope is instructed. The exact approval path for a variation is one of the things we pin down at the scoping call, because it differs between a two-person builder and a tier-one contractor.