تخطي للذهاب إلى المحتوى

فخ تعدد الشركات في أكواد Odoo المخصصة

11 آب 2026 بواسطة
فخ تعدد الشركات في أكواد Odoo المخصصة
Majorbird

فخ تعدد الشركات في أكواد Odoo المخصصة

自定义Odoo代码中的多公司陷阱

La trampa multiempresa en el código personalizado de Odoo

Pièges du multi-société dans le code Odoo sur mesure

فخ تعدد الشركات في أكواد Odoo المخصصة

Cạm bẫy đa công ty trong mã tùy chỉnh Odoo

تضيف شركة نامية كيانًا قانونيًا ثانيًا في Odoo، ربما شركة تابعة جديدة، أو مشروعًا مشتركًا، أو تسجيلًا منفصلًا لسوق جديد، وخلال أيام يتعطل شيء لم يلمسه أحد مباشرة. يحدّث مستخدم بيانات حساب مورّد بنكية فتظهر التغييرات بهدوء في فاتورة لشركة مختلفة تمامًا. يظهر أمر شراء أُنشئ ضمن كيان ما في قائمة موافقات كيان آخر. لم يكن هناك أي خطأ في الإعداد. ببساطة، لم تُكتب الأكواد المخصصة قط وهي تعلم أن كلمة "شركة" يمكن أن تعني أكثر من شيء واحد.

لماذا تتعطل أكواد الشركة الواحدة أولًا

تبدأ معظم وحدات Odoo المخصصة حياتها مقتصرة على شركة واحدة، لأن ذلك هو الواقع الوحيد الذي يعيشه العميل في تلك اللحظة. يضيف المطورون حقولًا، ويتجاوزون طرق create وwrite، ويبنون منطق استرجاع يقرأ السجلات دون تصفية حسب company_id، لأن هناك شركة واحدة فقط في اللعبة والسلوك الافتراضي يبدو صحيحًا. تحمل تطبيقات Odoo القياسية نفسها (المبيعات، المشتريات، المحاسبة) قواعد سجلات متعددة الشركات مدمجة، لكن الوحدات المخصصة لا ترثها تلقائيًا. في اللحظة التي تُسجَّل فيها شركة ثانية على قاعدة البيانات نفسها، تتحول كل عملية قراءة وكتابة غير مُصفّاة إلى تسريب هادئ بين الشركات: بيانات بنكية مشتركة، ميزانيات أو أوامر شراء تظهر تحت الكيان الخاطئ، وسجلات شركاء ومنتجات ترث قيمًا كان يُقصد بها شركة شقيقة فقط.

الحل هو تعديل لاحق، لا إعادة كتابة

الخبر الجيد أن هذا نادرًا ما يتطلب إعادة بناء كاملة. الحل هو إعادة نطاقات company_id وقواعد السجلات إلى الأماكن التي أُغفلت فيها: تحتاج الحقول الموروثة إلى نطاقات صريحة مرتبطة بالشركة، ويحتاج منطق البحث والاسترجاع إلى مرشح شركة فعلي بدلًا من الاعتماد على سياق الشركة الافتراضي، ويحتاج كل نموذج مخصص إلى قاعدة سجل خاصة به متعددة الشركات، لا الاكتفاء بالقواعد القياسية فقط. الجزء الصعب هو إيجاد كل مكان توجد فيه هذه الفجوة، لأن الخلل لا يظهر إلا بعد وجود بيانات فعلية متعددة الشركات تكشفه، وبحلول ذلك الوقت يكون العميل يشغّل بالفعل كيانين على المثيل نفسه.

رأينا

هذا الأمر شائع بما يكفي ليستحق التصميم له قبل الحاجة إليه: يجب أن يفترض أي تطوير مخصص في Odoo أن شركة ثانية قادمة، حتى عندما يكون العميل واثقًا من أنه لن يكون هناك سوى شركة واحدة دائمًا. تدقيق مختصر متعدد الشركات على المنطق المخصص قبل تشغيل كيان جديد فعليًا، بدلًا من بعده، أرخص بكثير من فك تشابك بيانات حية عبرت بالفعل حدود الشركات. إذا كان فريقك يضيف كيانًا قانونيًا إلى مثيل Odoo قائم، فهذا بالضبط نوع المشكلة التي تستحق نقاشًا مع Majorbird قبل أن تظهر من تلقاء نفسها.

في News
كيف تستعد لتحليل الفجوات (لا تحتاج إلى وثيقة عمليات مثالية)