إمكانية رؤية المنتجات في بيئة تعدد الشركات في أودو 20: السلوك القياسي وحدوده والتخصيص الآمن

يتعامل أودو 20 جيدًا مع المنتجات في بيئة تعدد الشركات عندما تكون القاعدة بسيطة: شارك المنتج مع جميع الشركات، أو اقصره على شركة واحدة. لكن الفجوة تظهر عندما تحتاج المؤسسة إلى حل وسط، كمنتج ينبغي أن يكون متاحًا للشركتين A وB ومخفيًا عن الشركة C.

ولهذا التمييز أهمية في المجموعات القابضة، وشبكات الامتياز التجاري، والكيانات الإقليمية، ومؤسسات الخدمات المشتركة، والشركات التي تحتفظ بكتالوج مركزي واحد للمنتجات بينما لا تسمح إلا لكيانات قانونية مختارة ببيع أصناف معينة أو شرائها.

والنقطة الجوهرية أن هذه ليست مشكلة في واجهة المستخدم فحسب. فإمكانية رؤية المنتج تؤثر في قواعد السجلات، وفئات المنتجات، والضرائب، والمسارات، والتسعير، وعمليات المخزون، والتكاملات، وأي شيفرة مخصصة تفترض نموذج الشركات القياسي في أودو.

يشرح هذا الدليل ما يدعمه أودو 20 بصورة قياسية، وموضع هذا القيد في نموذج البيانات، وكيف تصمّم إمكانية رؤية انتقائية للمنتجات دون أن يتحول متطلب صغير إلى تخصيص هش لتعدد الشركات.

ما الذي يدعمه أودو 20 بصورة قياسية

توضح وثائق تعدد الشركات الرسمية في أودو أن سجلات مثل المنتجات يمكن أن تكون مشتركة أو خاصة بشركة.

وبالنسبة إلى المنتجات، فالسلوك القياسي من الناحية العملية هو:

وتذكر الوثائق الرسمية نفسها أن المنتجات الجديدة تكون مشتركة بين الشركات افتراضيًا، وأن تعيين شركة للمنتج يقصره على ذلك الكيان.

هذا التصميم بسيط ومفيد في كثير من عمليات التنفيذ. إذ تستطيع المجموعة الاحتفاظ بكتالوج منتجات مشترك واحد دون تكرار كل رمز صنف، بينما يمكن عزل المنتج الخاص بشركة عندما لا يتبع إلا كيانًا قانونيًا واحدًا.

ويظهر القيد عندما تكون قاعدة الوصول المطلوبة مجموعة جزئية لا "الكل" ولا "واحدة".

لماذا تختلف المجموعة الجزئية المختارة عن الوصول المعتاد في تعدد الشركات

لنفترض أن قاعدة بيانات أودو واحدة تضم ثلاث شركات:

• الشركة A، الإمارات العربية المتحدة
• الشركة B، المملكة العربية السعودية
• الشركة C، المملكة المتحدة

ينبغي أن يكون المنتج المسمى Service Plan GCC قابلًا للاستخدام في A وB، لا في C.

ومع إمكانية رؤية المنتجات القياسية، هناك خياران واضحان:

1. ترك حقل الشركة فارغًا. فيصبح المنتج مشتركًا، بما في ذلك مع الشركة C.
2. تعيين الشركة A أو B. فيرتبط المنتج حينها بتلك الشركة وحدها.

أما ما ينقص فهو مفهوم قياسي على مستوى المنتج يعادل ما يلي:

Allowed Companies = [Company A, Company B]

مع استبعاد الشركة C.

ويظهر هذا التمييز في الشيفرة المصدرية لأودو 20 نفسها. ففي نموذج product.template الرسمي، يبقى حقل الشركة في المنتج كما يلي:

company_id = fields.Many2one(
    'res.company', 'Company', index=True
)

يشير الحقل من نوع Many2one إلى شركة واحدة، لا إلى مجموعة اعتباطية من الشركات.

وهذه التفصيلة على مستوى الشيفرة المصدرية مهمة، لأن التخصيص ينبغي أن يعمل مع النموذج القياسي، لا أن يتظاهر بأن له دلالات مختلفة.

المنتج المشترك لا يعني تطابق بيانات الشركات

المنتج المشترك سجل منتج واحد متاح عبر الشركات، لكن لا يلزم أن تكون كل قيمة مرتبطة به متطابقة.

وتقدم وثائق تعدد الشركات في أودو مثالًا مفيدًا: يمكن للمنتج المشترك الاحتفاظ بقيم موحدة مثل سعر البيع والمرجع، بينما تختلف تكلفته من شركة إلى أخرى.

وهذا أحد الأسباب التي تجعل تكرار المنتجات لكل شركة حلًا أوليًا خاطئًا في أغلب الأحيان. فالتكرار ينشئ سجلات رئيسية منفصلة قد تتباعد في الاسم أو الباركود أو الوصف أو الخصائص أو المرفقات أو معرّفات التكامل.

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

أما المشكلة فهي إمكانية الرؤية: فالسجل المشترك على مستوى جميع الشركات يظل أوسع من اللازم عندما لا يُسمح باستخدامه إلا لبعض الشركات.

لماذا يكون تكرار المنتج عادةً حلًا التفافيًا ضعيفًا

من الحلول الالتفافية الشائعة إنشاء المنتج نفسه عدة مرات:

SKU-100 — Company A
SKU-100 — Company B

ثم الامتناع ببساطة عن إنشائه للشركة C.

يبدو ذلك نظيفًا في البداية، لأن العزل القياسي بين الشركات يظل يعمل. لكن التكلفة تأتي لاحقًا.

فالسجلات الرئيسية المكررة للمنتج قد تُحدث التباسًا في:

• الباركود والمراجع الداخلية؛
• خصائص المنتج ومتغيراته؛
• بيانات الموردين؛
• ربط المتجر الإلكتروني؛
• معرّفات التكاملات الخارجية؛
• التقارير على مستوى الشركات؛
• الوثائق المشتركة؛
• الصيانة عند تغيّر الأوصاف أو المواصفات.

فإذا استلم تكامل مع Shopify أو مع المستودع أو مع تطبيق جوال أو مع نظام المشتريات الرمز SKU-100، فإنه يحتاج الآن إلى قاعدة إضافية لتحديد سجل المنتج في أودو الذي يمثله هذا المعرّف المصدري.

وقد يظل التكرار صحيحًا عندما تتعامل الكيانات فعلًا مع الصنف على أنه منتجات مختلفة. لكنه لا ينبغي أن يكون الإجابة الافتراضية عن متطلب يتعلق بإمكانية الرؤية.

نمط التخصيص الأكثر أمانًا

لإمكانية الرؤية الانتقائية في بيئة تعدد الشركات، تكون البنية الأكثر أمانًا عادةً هي الحفاظ على الحقل القياسي company_id في أودو وإضافة مفهوم وصول منفصل بدلًا من استبدال الحقل الأساسي.

على سبيل المثال، يمكن لوحدة مخصصة أن تضيف ما يلي:

Visibility
- Shared with all companies
- One company
- Selected companies

Allowed Companies
- Company A
- Company B

أسماء الحقول بالتحديد قرارات تخص التنفيذ، لكن مبدأ التصميم هو المهم.

أبقِ حقل الشركة القياسي كما هو

يبدو تغيير الحقل القياسي company_id في أودو من Many2one إلى Many2many مغريًا، لأن المتطلب يبدو كأنه "السماح لعدة شركات".

لكنه أيضًا اختصار محفوف بالمخاطر.

فالشيفرة الأساسية، والنماذج المرتبطة، والواجهات، والنطاقات، وفحوص الشركات، ووحدات الأطراف الثالثة، والترقيات المستقبلية، كلها قد تتوقع بصورة معقولة أن يتصرف company_id بوصفه حقلًا لشركة واحدة.

كما أن نموذج المنتج في أودو 20 يفعّل الاتساق التلقائي للشركات. ففي الشيفرة المصدرية الرسمية، يعلن product.template الخاصية _check_company_auto = True، وتستخدم الحقول العلائقية مثل فئة المنتج الخاصية check_company=True.

وهذا يعني أن اتساق الشركات جزء من سلوك النموذج، لا مجرد زخرفة في النموذج المعروض.

والوحدة الأكثر أمانًا توسّع النموذج بدلًا من إعادة تعريف معنى الحقل القياسي.

افرض إمكانية الرؤية بقواعد السجلات، لا بالنموذج المعروض وحده

إخفاء منتج من قائمة منسدلة ليس تحكمًا في الوصول.

فإذا وجب ألا يكون المنتج متاحًا للمستخدمين العاملين في الشركة C، فيجب أن يُطبَّق القيد عند البحث عن السجلات أو قراءتها، لا عند عرض واجهة معينة فقط.

وهذا يعني أن على التنفيذ استخدام نموذج الوصول في أودو على مستوى الخادم، واختبار القاعدة عبر:

• واجهات النماذج والقوائم المعتادة؛
• اختيار المنتج في أوامر البيع والشراء؛
• عمليات الاستيراد؛
• استدعاءات RPC وواجهات البرمجة؛
• المهام المجدولة؛
• تطبيقات الجوال أو الويب المخصصة.

فالنطاق المطبّق على الواجهة وحدها قد يجعل الشاشة تبدو صحيحة، بينما يبقى السجل الأساسي قابلًا للقراءة عبر مسار آخر.

منطق قاعدة السجلات يحتاج إلى تعريف واحد واضح

ينبغي أن تجيب قاعدة المنتج الانتقائي عن سؤال بسيط:

هل هذا المنتج صالح لشركة واحدة على الأقل من الشركات النشطة حاليًا لدى المستخدم؟

من حيث المفهوم، قد تكون سياسة إمكانية الرؤية كما يلي:

VISIBLE if:
    product is globally shared
OR  product belongs to one of the user's active companies
OR  one of product.allowed_company_ids is in the user's active companies

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

والتصميم الأقوى يُبقي الأوضاع واضحة لا لبس فيها. تجنّب الإعدادات التي يحمل فيها المنتج شركة قياسية واحدة وقائمة متعارضة من الشركات المسموح بها في آن واحد.

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

إمكانية رؤية المنتج ليست إلا الطبقة الأولى

كون المنتج قابلًا للقراءة لا يضمن أن كل سجل مرتبط به صالح في الشركة الحالية.

وهنا تحديدًا تفشل كثير من تخصيصات تعدد الشركات.

فالشيفرة المصدرية للمنتج في أودو 20 تضع على علاقة فئة المنتج الخاصية check_company=True. وفي أجزاء أخرى من قاعدة بيانات الإنتاج، قد تتفاعل المنتجات أيضًا مع الضرائب، وقوائم الأسعار، والمسارات، والمستودعات، وبيانات الموردين، والإعدادات المالية، والخصائص المحاسبية، وقواعد المخزون.

وقبل إدخال إمكانية الرؤية الانتقائية، حدّد السلوك المتوقع لهذه العلاقات.

على سبيل المثال:

• هل تستطيع الشركتان A وB استخدام الفئة نفسها؟
• هل لكل شركة إعدادات التكلفة والمحاسبة الخاصة بها؟
• هل عُيّنت الضرائب بطريقة تبقى صالحة في الشركتين؟
• هل مسارات التوريد عامة أم خاصة بكل شركة؟
• هل يمكن أن يظهر المنتج في أمر بيع عندما تكون شركة واحدة فقط من عدة شركات نشطة؟
• ماذا ينبغي أن يفعل التكامل إذا استلم طلبًا لشركة غير مسموح لها باستخدام المنتج؟

حقل إمكانية الرؤية هو الجزء السهل. أما الاتساق حول المنتج فهو عمل التنفيذ الحقيقي.

لا تخلط بين الشركة المسموح بها والشركة النشطة

يمكن منح مستخدمي أودو صلاحية الوصول إلى عدة شركات، ويمكنهم تحديد عدة شركات من أداة تبديل الشركات.

وهذان مفهومان مختلفان:

الشركات المسموح بها تحدد الشركات التي يُسمح للمستخدم بالوصول إليها.

الشركات النشطة تحدد الشركات المختارة حاليًا في سياق عمل المستخدم.

ولهذا التمييز أهمية في الاختبار.

فقد تكون للمستخدم صلاحية الوصول إلى A وB وC بينما يعمل مع تحديد الشركة A وحدها. وقد يحدد مستخدم آخر A وB معًا.

ويجب أن تتصرف قاعدة إمكانية رؤية المنتجات بصورة مقصودة في الحالتين.

لا تختبر التخصيص بمسؤول نظام تتضمن أداة اختيار الشركات لديه جميع الكيانات فقط. فهذه من أسهل الطرق لتفويت أخطاء الوصول قبل الإنتاج.

اختبار قبول عملي

قبل نشر إمكانية الرؤية الانتقائية للمنتجات في بيئة تعدد الشركات، اختبر المصفوفة التالية على الأقل.

ثم أعد تنفيذ مسارات العمل الحرجة:

• إنشاء عرض سعر؛
• تأكيد أمر بيع؛
• إنشاء أمر شراء؛
• استلام المخزون؛
• معالجة عملية تسليم؛
• إنشاء فاتورة عند الاقتضاء؛
• استخدام البحث عن المنتجات في بوابة مخصصة أو تطبيق جوال؛
• تشغيل مهام التكامل المجدولة؛
• تصدير بيانات المنتجات واستيرادها.

ليس الغرض إثبات أن حقل الوسوم يُحفظ بصورة صحيحة، بل إثبات أن المؤسسة لا تستطيع استخدام المنتج عن طريق الخطأ من شركة مستبعدة.

السجلات القائمة تحتاج إلى قاعدة ترحيل

تثير إضافة الحقل allowed_company_ids إلى قاعدة بيانات قائمة سؤالًا فوريًا:

ماذا ينبغي أن يحدث للمنتجات الموجودة بالفعل؟

يجب أن يحافظ الترحيل الآمن على المعنى الحالي.

ومن التعيينات الافتراضية المفيدة:

• company_id فارغ ← يبقى مشتركًا على مستوى جميع الشركات؛
• company_id = A ← يبقى مقصورًا على A؛
• لا يُعتمد وضع الشركات المختارة إلا عند إعداده صراحةً.

لا تحوّل كل منتج مشترك تلقائيًا إلى قائمة تضم جميع الشركات الحالية. فذلك يغيّر المعنى المستقبلي للسجل: فعند إضافة شركة رابعة لاحقًا، ينبغي عادةً أن يبقى المنتج العام في الأصل عامًا، بينما قد يلزم أن يبقى المنتج المعيّن عمدًا للشركتين A+B مقصورًا عليهما.

ولهذا يكون وضع إمكانية الرؤية الصريح غالبًا أنظف من استنتاج كل شيء مما إذا كانت القائمة تضم اليوم جميع الشركات مصادفةً.

ماذا عن المعاملات بين الشركات؟

يدعم أودو 20 المعاملات بين الشركات التي يمكن أن تنشئ، بحسب الإعداد، أوامر بيع وأوامر شراء وفواتير موردين مقابلة، وحركات مخزون متزامنة. وتشير الوثائق الرسمية إلى أن سجلات المنتجات المشاركة في مسارات العمل هذه بين الشركات تكون مشتركة بين الشركات المعنية.

ويجب أن تحترم إمكانية الرؤية الانتقائية للمنتجات هذا الشرط.

فإذا باعت الشركة A صنفًا داخليًا للشركة B، فإن الطرفين يحتاجان إلى علاقة منتج صالحة في المستندات التي ينشئها أودو. والقاعدة التي تخفي المنتج عن B قد تعطّل إعدادًا للمعاملات بين الشركات كان سيعمل بصورة صحيحة لولاها.

وقبل تقييد الكتالوج، حدّد المنتجات المشاركة في:

• المبيعات بين الشركات؛
• التوريد الداخلي؛
• عمليات المستودعات المشتركة؛
• المشتريات المركزية؛
• التوحيد أو تقارير المجموعة.

ينبغي أن تعكس قاعدة إمكانية الرؤية نموذج التشغيل، لا أن تتعارض معه.

الاستضافة والترخيص مهمّان أيضًا

تذكر وثائق تعدد الشركات الحالية في أودو أن تفعيل تعدد الشركات على خطة Standard يؤدي إلى الترقية إلى خطة Custom، باستثناء قواعد بيانات One-App Free.

وهذا منفصل عن الوحدة التقنية نفسها، لكنه مهم عند تقدير الحل.

فوحدة تعدد الشركات المخصصة ليست مجرد "40 سطرًا من Python". إذ يشمل نطاقها الحقيقي خطة أودو، ونموذج الاستضافة، والوحدات المخصصة الحالية، والتكاملات، واستراتيجية الترقية، وتغطية الاختبارات.

وفي بيئات Odoo.sh أو الاستضافة الذاتية، يكون نشر الوحدات المخصصة جزءًا من سير العمل الهندسي المعتاد. أما في Odoo Online، فيعتمد مسار التخصيص المتاح على قيود المنصة والاشتراك.

متى يكفي أودو 20 القياسي

لا تبنِ وحدة إذا كان المتطلب يندرج ضمن إحدى هذه الحالات:

ينبغي لجميع الشركات استخدام المنتج

أبقِ المنتج مشتركًا، واستخدم الإعدادات المعتمدة على الشركة حيث يلزم.

تملك المنتج شركة واحدة بالتحديد

استخدم حقل الشركة القياسي.

الفرق في التسعير، لا في إمكانية الرؤية

احتفظ بمنتج مشترك، وعالج القاعدة التجارية بإعدادات التسعير أو الشركة المناسبة بدلًا من استنساخ المنتج لمجرد إخفائه.

المتطلب الحقيقي قاعدة للموقع الإلكتروني أو لقناة البيع

تعامل مع ذلك بمعزل عن العزل بين الكيانات القانونية. فإمكانية رؤية المنتج على مستوى الشركة في نظام تخطيط موارد المؤسسة ضابط أقوى من تحديد ما يُنشر في متجر إلكتروني بعينه.

أفضل تخصيص هو الذي لا تحتاج إليه.

متى تكون وحدة الشركات المختارة مبررة

تصبح وحدة مخصصة لإمكانية رؤية المنتجات في بيئة تعدد الشركات معقولة عندما تتحقق جميع الشروط التالية:

1. ينبغي إعادة استخدام السجل الرئيسي نفسه للمنتج.
2. يجب أن يكون المنتج متاحًا لأكثر من شركة واحدة.
3. يجب مع ذلك ألا يكون متاحًا لشركة أخرى واحدة على الأقل.
4. سيؤدي تكرار المنتج إلى مشكلات في البيانات الرئيسية أو التكاملات.
5. تقبل المؤسسة مسؤولية الاختبار والترقية التي تأتي مع قواعد الوصول المخصصة.

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

ابنِ القاعدة حول حدود الأعمال

يمنحك النموذج الأساسي في أودو 20 حالتين قياسيتين مفيدتين: منتج مشترك، أو منتج لشركة واحدة.

وإذا كانت مؤسستك تحتاج إلى إمكانية رؤية المنتجات لشركات مختارة، فتعامل معها بوصفها ميزة أمان واتساق للبيانات، لا مجرد حقل إضافي في نموذج.

حافظ على النموذج القياسي ما أمكن. وأضف دلالات صريحة لإمكانية الرؤية. وافرضها على مستوى الخادم. واختبر كل مسار يمكنه اختيار منتج أو استهلاكه. وراجع توافق السجلات المرتبطة مع الشركات. ورحّل المنتجات القائمة دون تغيير معناها بصمت.

هذا النهج يكلّف أكثر من إضافة عنصر واجهة من نوع Many2many.

لكنه يمنحك أيضًا شيئًا أثمن بكثير: كتالوجًا لتعدد الشركات يظل سلوكه قابلًا للشرح والاختبار والترقية بعد عام من الآن.

إذا كانت قاعدة بيانات أودو 20 لديك تحتاج إلى منتجات مشتركة بين شركات مختارة دون كشف الكتالوج الكامل لكل كيان، فإن Octivex Tech تستطيع تحديد نطاق القاعدة في ضوء منتجاتك الحالية وقواعد السجلات والتكاملات ومسار الترقية قبل إدخال أي شيفرة مخصصة.