In stock Odoo, whenever an invoice (account.move) is created from a sales order or against a customer, the salesperson on the record (user_id / the partner's assigned user_id) is silently pushed into the invoice's follower list via the mail.thread auto-subscription machinery. That means every posting, payment reminder, chatter note, and status change on that invoice fires a notification to a salesperson who has usually already handed the deal off to finance. Multiply that across hundreds of invoices a month and the sales team's Inbox becomes noise, accountants lose a clean audit trail of who is genuinely watching a document, and — in shared or brokered scenarios — a salesperson can end up seeing financial correspondence they should not. Odoo exposes no configuration switch to turn this behaviour off; the subscription is baked into the model's _creation_subtype, _track_subtype, and the message_auto_subscribe / _message_auto_subscribe_followers chain, so the only correct fix is code.

ECOSIRE builds a small, surgical module that intercepts exactly that auto-subscription path on account.move (and, where you invoice from sales, the propagation from sale.order). Rather than crudely stripping followers after the fact, we override _message_auto_subscribe_followers / message_auto_subscribe so the salesperson's partner is never enrolled in the first place, keeping the rest of Odoo's tracking intact — customers, accounting managers, and anyone manually added stay subscribed and keep getting the notifications they need. The behaviour is made configurable through a res.config.settings toggle (and, if you want finer control, a company-level or invoice-type-level flag) so administrators decide the scope without touching source again. Everything is delivered against your Odoo edition: on Community we work with the base account and sale modules; on Enterprise we account for the additional accounting and subscription flows so the exclusion holds consistently.

Technically, the build ships as a proper addon: a __manifest__.py declaring dependencies (account, and sale where relevant), a thin Python model layer using models.Model inheritance and @api.depends only where a computed helper is genuinely needed, ir.model.access.csv plus record rules so any new setting respects your security groups, and an XML settings view wired into the Invoicing configuration page. We include an optional automated-action / server-action variant for edge cases where invoices are generated by third-party integrations over XML-RPC or JSON-RPC, so records created outside the standard UI are covered too. The logic is idempotent and side-effect-free: it changes who is subscribed, never the invoice's amounts, sequence, or posting state, and it is written to survive standard Odoo upgrades within a major version.

Because this is a made-to-order build and not an existing download, delivery follows a short, predictable path. We start with a scoping call to confirm your edition, version, invoicing flows (sale-driven vs. manual vs. subscription vs. integration-created), and exactly which roles you want excluded. We then build against a copy of your configuration, validate on a staging database with UAT, and deploy with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company rollout, additional invoicing sources (subscriptions, integrations, imported invoices), or migrating existing follower data increases the quoted scope. You receive a fixed written quote after the scoping call — never a surprise.