企业在 Odoo 里新增一家法人实体，可能是子公司、合资公司，也可能是为了新市场单独注册的主体。上线没几天，没人动过的环节突然出问题。财务刚更新了一家供应商的银行信息，这张发票却出现在另一家公司的账单上。A公司下的采购单，莫名其妙跑进了B公司的审批流。配置没出错，问题出在底层：那套定制代码从一开始就没想过，"公司"居然可以不止一个。
为什么单公司视角的代码最先出事
大多数定制模块在诞生时，眼里只有一家公司。因为客户当时确实只有这一家公司。开发人员在加字段、重写 create 和 write 方法、写取数逻辑的时候，根本不会去过滤 company_id，反正数据库里只有一个主体，默认行为看起来就是对的。Odoo 自带的销售、采购、财务这些标准应用，内部本来就有多公司隔离规则，但定制模块不会自动继承这些规则。第二个公司一进数据库，所有没做范围限制的读写操作，立刻变成静默的跨公司泄漏：银行信息、预算、采购单，悄悄出现在不该出现的法人账下；客户档案、产品资料，也沾上了只该属于兄弟公司的数值。
解决方案是补漏，不是重写
好消息是，这种情况很少需要推倒重建。要做的，只是把那些被跳过的 company_id 域名规则和记录权限，重新装回去：继承来的字段需要显式加上公司级域名，搜索和取数逻辑要真正加上公司过滤，而不是靠默认上下文蒙混过关；每一个定制模型都得配上自己的多公司记录规则，不能只靠标准模块兜底。真正的难点在于，你得把所有漏掉的地方都找出来。可这些漏洞只有在真实的多公司数据进场之后才会暴露，而到那时，客户已经在同一个实例上跑起了两家实体。
我们的建议
这类问题太常见了，值得在出事之前就提前设计。任何 Odoo 定制开发，都应该默认"第二家公司迟早会来"，哪怕客户现在拍着胸脯说永远只有一家。在新主体上线之前，花点时间给定制逻辑做一次多公司审计，远比等数据已经串了线再去拆要便宜得多。如果你的团队正准备在现有 Odoo 实例上新增法人实体，这类风险最好在爆发之前就找 Majorbird 一起过一遍。