Khi doanh nghiệp phát triển, việc thêm pháp nhân thứ hai vào Odoo là chuyện rất thường gặp, có thể là công ty con mới, liên doanh, hoặc một đăng ký riêng để mở thị trường mới. Nhưng chỉ sau vài ngày, một lỗi không ai trực tiếp đụng tới bắt đầu xuất hiện. Người dùng cập nhật thông tin ngân hàng của nhà cung cấp, và thay đổi đó âm thầm hiển thị trên hóa đơn của một công ty hoàn toàn khác. Một đơn mua hàng được tạo dưới pháp nhân này lại xuất hiện trong hàng chờ phê duyệt của pháp nhân kia. Không hẳn là cấu hình sai. Vấn đề nằm ở chỗ mã tùy chỉnh ban đầu chưa bao giờ được thiết kế để hiểu rằng "công ty" có thể có nhiều ngữ cảnh khác nhau.
Vì sao mã viết cho một công ty thường lỗi đầu tiên
Phần lớn module Odoo tùy chỉnh được xây dựng từ nhu cầu ban đầu của khách hàng, khi hệ thống chỉ có một công ty. Lập trình viên thêm trường, override các phương thức create và write, rồi viết logic lấy dữ liệu mà không lọc theo company_id. Lý do rất đơn giản: lúc đó chỉ có một công ty, nên kết quả mặc định nhìn vẫn đúng. Các ứng dụng chuẩn của Odoo như bán hàng, mua hàng, kế toán đã có sẵn record rule cho mô hình đa công ty. Nhưng module tùy chỉnh không tự động thừa hưởng đầy đủ các lớp kiểm soát đó. Ngay khi công ty thứ hai được tạo trên cùng một cơ sở dữ liệu, mọi thao tác đọc và ghi thiếu phạm vi công ty đều có thể trở thành điểm rò rỉ âm thầm: thông tin ngân hàng dùng chung ngoài ý muốn, ngân sách hoặc đơn mua hàng hiện ở sai pháp nhân, đối tác và sản phẩm nhận giá trị vốn chỉ dành cho một công ty liên quan.
Cách xử lý là bổ sung đúng chỗ, không phải viết lại từ đầu
Điểm tích cực là đa số trường hợp không cần xây lại hệ thống. Việc cần làm là đưa company_id domain và record rule vào đúng những nơi từng bị bỏ qua. Các trường kế thừa cần domain rõ ràng theo từng công ty. Logic search và fetch phải có bộ lọc công ty thực sự, thay vì chỉ dựa vào default company context. Mỗi model tùy chỉnh cũng cần record rule đa công ty riêng, không thể chỉ trông chờ vào rule chuẩn của Odoo. Phần khó nhất là rà ra toàn bộ điểm hở, vì lỗi này thường chỉ lộ diện khi đã có dữ liệu đa công ty thật sự. Đến lúc đó, khách hàng thường đã vận hành hai pháp nhân trên cùng một instance.
Góc nhìn của Majorbird
Đây là lỗi đủ phổ biến để doanh nghiệp nên tính trước, thay vì đợi đến khi phát sinh. Mọi dự án phát triển Odoo tùy chỉnh nên mặc định rằng một ngày nào đó sẽ có thêm công ty thứ hai, kể cả khi khách hàng hiện tại rất chắc chắn rằng hệ thống chỉ cần phục vụ một công ty. Một đợt audit ngắn về logic đa công ty trước khi pháp nhân mới go live luôn tiết kiệm hơn rất nhiều so với việc gỡ dữ liệu thật đã bị lẫn giữa các công ty. Nếu đội ngũ của bạn đang chuẩn bị thêm pháp nhân vào một Odoo instance hiện hữu, đây chính là kiểu vấn đề nên trao đổi sớm với Majorbird trước khi nó tự xuất hiện trên vận hành thực tế.