A build-to-order Odoo module that warns users in real time when a new contact matches an existing one on email, phone, VAT, or name — before the duplicate is ever saved. Designed, built, installed, and supported by ECOSIRE for your exact matching rules. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
Manifeste de l'app
Conçu autour de votre flux de travail
A build-to-order Odoo module that warns users in real time when a new contact matches an existing one on email, phone, VAT, or name — before the duplicate is ever saved. Designed, built, installed, and supported by ECOSIRE for your exact matching rules.
Aucune configuration à faire vous-même — une app fonctionnelle conçue, installée et prise en charge par ECOSIRE.
Commencez par un prix de développement unique. Nous cadrons le projet avec vous au lancement.
ECOSIRE la développe, la configure et l'installe sur votre Odoo.
Vous êtes en ligne en 2–4 semaines environ, avec une période d’assistance après le lancement.
Every Odoo database accumulates duplicate contacts. A salesperson types a lead that already exists, a support agent creates a "new" customer who is really an old one under a different spelling, and an import drops in the same company twice. Odoo core does almost nothing to stop this at the point of entry: res.partner has no meaningful uniqueness constraint on email, phone, or VAT, and the standard UI only surfaces a soft name-based suggestion on some flows. The result is fragmented customer history, invoices and sales orders scattered across twin records, broken deduplication in mailings, and hours of manual merging after the damage is done.
This is a productized service, not an off-the-shelf download. ECOSIRE builds a Duplicate Contact Details Alert module tailored to your matching policy and installs it into your Odoo 17.0, 18.0, or 19.0 database. Technically, we add an @api.onchange layer and server-side @api.constrains guards on res.partner so a duplicate is caught both interactively (a warning banner as the user types) and defensively (blocked or flagged on save, including via the XML-RPC/JSON-RPC API and imports). Matching runs over the fields you choose — email, phone, mobile, vat, normalized name, or a composite key — with configurable normalization (case-folding, whitespace and punctuation stripping, E.164 phone normalization, domain-only email comparison). Detected candidates are shown inline in the form view (OWL/QWeb) with a one-click jump to the existing partner, and every near-miss can be logged for later review.
Because it is built for you, the behavior is a policy decision, not a fixed opinion. We can make the alert advisory (warn but allow), enforcing (ValidationError that blocks the save), or role-differentiated via ir.model.access.csv and record rules — for example, agents get a hard block while data-quality managers can override with a logged reason. We scope company-level behavior explicitly: in multi-company databases the match can be tenant-isolated or shared, and we respect company_id and record-rule visibility so the check never leaks contacts across companies the user cannot see. Optional extras include a scheduled ir.cron sweep that reports existing duplicates already in the database, a QWeb report of duplicate clusters, and an automated action to tag suspected twins.
Delivery is build-to-order. After a short scoping call we confirm the exact fields, normalization rules, enforcement mode, and Odoo edition (Community vs Enterprise), then build on a staging copy of your database, run UAT with your team, and deploy with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope. You receive the full module source in a git repository — __manifest__.py, models, views, security, and tests — so you are never locked to us. Pricing starts from $249 (indicative, single-company base scope); additional matching fields, multi-company isolation, custom normalization for localized phone/VAT formats, existing-data cleanup, and cross-model checks (e.g. leads or vendors) increase the quoted scope.
Runs pipeline on Odoo and is tired of the same lead existing three times under different spellings. Needs entry-point duplicate prevention so activity history, opportunities, and forecasts attach to one clean customer record.
Owns contact hygiene across the org. Wants configurable matching, an override lane with logged reasons, and a scheduled report of existing duplicate clusters to work down the backlog.
Maintains a multi-company Odoo instance and imports contacts via API and spreadsheets. Needs the guard to fire on the server side and respect company isolation and record-rule visibility, not just block in the UI.
Agents create customers on the fly during tickets. Needs a real-time alert that points to the existing partner so support history stays consolidated instead of fragmenting across twin contacts.
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Detection point | Real-time onchange warning plus server-side constrains, tuned to your fields | Whatever your team codes and finds time to test | Usually onchange-only warning on a fixed field list | |
| Matching rules | Configurable fields, normalization, and composite keys agreed at scoping | Fully custom but you specify and maintain every rule | Predefined fields, limited configuration | |
| API & import coverage | Enforced server-side, so XML-RPC/JSON-RPC and imports are guarded | Only if you remember to put it in constrains, not onchange | Often UI-only; imports slip through | |
| Enforcement flexibility | Advisory, blocking, or role-differentiated with logged override | Possible but each mode is more code to build | Typically warn-only, one behavior for everyone | |
| Multi-company handling | Explicit company isolation respecting record-rule visibility | Must be designed and tested by you | Rarely company-aware out of the box | |
| Version fit | Built and verified for your exact 17.0/18.0/19.0 and edition | Whatever version you build against | May lag new Odoo releases | |
| Ownership | Full git repo handover, no lock-in | You own it, and you own all the maintenance | Licensed binary or vendor-controlled source | |
| Support | Scoping-to-go-live delivery plus a post-go-live support window | Internal team bandwidth only | Generic ticket queue, no context on your setup |
This is a build-to-order module. Typical delivery is 2-4 weeks from confirmed scope. After the scoping call we agree the exact matching fields, normalization rules, enforcement mode, and Odoo edition, then build on a staging copy of your database, run UAT with your team, and deploy with a rollback plan. Complex multi-company or localization work can extend the timeline, which we confirm before starting.
Pricing starts from $249 as an indicative single-company base scope. It is not a fixed price — after a short scoping call we send a fixed quote based on your exact requirements. Drivers that increase scope include additional matching fields, multi-company isolation, custom normalization for localized phone or VAT formats, cleanup of existing duplicate data, and extending checks to other models such as leads or vendors.
Yes. The real-time `@api.onchange` warning helps users at the keyboard, but the enforcement lives in a server-side `@api.constrains` guard on `res.partner`. That means duplicates coming through spreadsheet imports or the XML-RPC/JSON-RPC API are checked and flagged or blocked by the same rules, so the policy is enforced regardless of entry point.
Both — it is your policy decision. We can configure it as advisory (warn but allow the save), enforcing (a `ValidationError` that blocks the duplicate), or role-differentiated so that, for example, sales agents are hard-blocked while data-quality managers can override with a logged reason via `ir.model.access.csv` and record rules.
Yes. Matching can be isolated per `company_id` so a contact in one company never falsely matches one in another, or deliberately shared if you want a global check. Either way it respects Odoo's record-rule visibility, so the alert never surfaces contacts a user isn't allowed to see.
You receive a post-go-live support window for defect fixes and adjustments after deployment. Because you get the full source in a git repository, you are free to maintain it yourself or engage us for changes. Upgrades to a new Odoo major version (e.g. moving from 18.0 to 19.0) are handled as a separate scoped engagement since Odoo API changes between versions can require rework.
Yes. The module targets `res.partner`, which exists in both editions, so it runs on Community and Enterprise across Odoo 17.0, 18.0, and 19.0. We build and verify against your specific edition and version during the engagement so the behavior matches your production environment exactly.
A build-to-order Odoo module that warns users in real time when a new contact matches an existing one on email, phone, VAT, or name — before the duplicate is ever saved. Designed, built, installed, and supported by ECOSIRE for your exact matching rules.