تعدد الشركات في أودو 20: المنتجات والصلاحيات والمعاملات بين الشركات

يتيح أودو 20 تشغيل عدة شركات داخل قاعدة بيانات واحدة، لكن "تعدد الشركات" لا يعني أن كل سجل يُعزل تلقائيًا بحسب الكيان القانوني.

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

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

يشرح هذا الدليل نموذج أودو 20 بلغة عملية: ما الذي يُشارك، وما الذي يكون خاصًا بالشركة، وكيف تعمل إمكانية رؤية المنتجات، وكيف تجري المعاملات بين الشركات، ومتى تكون القواعد المخصصة مبررة.

ما الذي يفعله تعدد الشركات في أودو 20 فعلًا

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

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

وهذا التمييز مهم.

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

وينبّه أودو أيضًا إلى أن تفعيل تعدد الشركات على اشتراك Standard يؤدي إلى الترقية إلى خطة Custom، باستثناء قواعد بيانات One-App Free. تأكد من الأثر التجاري الحالي على قاعدة بياناتك قبل تصميم خطة الإطلاق.

المرجع الرسمي: وثائق تعدد الشركات في أودو 20

البيانات المشتركة والبيانات الخاصة بالشركة مفهومان مختلفان

يبدأ التصميم السليم لتعدد الشركات بتصنيف السجلات قبل إعداد الصلاحيات.

اطرح سؤالًا واحدًا لكل نموذج مهم:

هل ينبغي أن يمثل هذا السجل الشيء نفسه على مستوى المجموعة، أم شيئًا يتبع كيانًا قانونيًا واحدًا؟

على سبيل المثال، قد يكون منتج باسم "Industrial Filter X200" الصنف التجاري نفسه لعدة شركات. أما الفاتورة المرحّلة فليست كذلك؛ إنها تتبع الكيان المحاسبي الذي أصدرها.

يدعم أودو 20 هذا التمييز من خلال سجلات وحقول تراعي الشركة.

المنتجات وجهات الاتصال مشتركة افتراضيًا

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

في السجلات المعنية، يؤدي ترك حقل الشركة فارغًا إلى إتاحة السجل لجميع الشركات. أما تعيين قيمة لحقل الشركة فيقصر السجل على سياق تلك الشركة.

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

لكن "المنتج المشترك" لا يعني أن كل قيمة فيه متطابقة على المستوى العام.

قد يحمل المنتج المشترك قيمًا خاصة بالشركة

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

هذا هو النمط الذي ينبغي فهمه:

One shared product record
        │
        ├── shared commercial/master data
        │
        ├── Company A-specific property/value
        ├── Company B-specific property/value
        └── Company C-specific property/value

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

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

صمّم إمكانية رؤية المنتجات قبل استيرادها

كثيرًا ما تُكتشف مشكلات المنتجات في بيئة متعددة الشركات بعد أن يصبح في النظام آلاف المنتجات.

قبل استيراد الكتالوج أو مزامنته، صنّف المنتجات في مجموعتين على الأقل:

1. المنتجات المشتركة: ينبغي أن يكون المنتج نفسه متاحًا على مستوى المجموعة.
2. المنتجات المقصورة على شركة: يتبع المنتج سياق شركة محددة.

ثم اختبر سلوك هذه المنتجات في مسارات العمل التي تستخدمها فعليًا:

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

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

ماذا لو لم يكن حقل الشركة القياسي دقيقًا بما يكفي؟

تحتاج بعض المؤسسات إلى قواعد أكثر تحديدًا من نموذج بسيط يقسم المنتجات إلى مشتركة ومقصورة.

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

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

لا تعالج ذلك بإضافة عامل تصفية مرئي ثم تسميته أمانًا.

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

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

صلاحية المستخدم والشركة النشطة ليستا الشيء نفسه

من أخطاء التنفيذ الشائعة الافتراض الآتي:

"للمستخدم صلاحية الوصول إلى الشركة B، إذن ستجري كل عملية في الشركة B."

ليس بالضرورة.

يميّز أودو بين الشركات التي يستطيع المستخدم الوصول إليها وسياق الشركة الحالي.

ويشرح الدليل التعليمي الرسمي للمطورين في أودو 20 المفهومين اللذين تستخدمهما قواعد الأمان في بيئة تعدد الشركات:

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

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

المرجع الرسمي: أودو 20: تقييد الوصول إلى البيانات، الأمان في بيئة تعدد الشركات

لماذا تظهر أخطاء الوصول بين الشركات

لنأخذ هذه الحالة المبسطة:

User can access:
- Company A
- Company B

Current company:
- Company A

Custom process creates:
- Sales Order in Company A
- Related custom record in Company B

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

والحل الصحيح ليس "منح المستخدم صلاحيات أكثر".

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

ويزداد ذلك أهمية في الوحدات المخصصة التي تربط المبيعات أو المحاسبة أو المخزون أو الموارد البشرية أو المشاريع أو التكاملات.

قواعد السجلات جزء من نموذج البيانات، لا من الواجهة فقط

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

ويتبع النطاق الشائع للسجلات القابلة للمشاركة هذه الفكرة:

[
    "|",
    ("company_id", "=", False),
    ("company_id", "in", company_ids),
]

ومعنى ذلك من حيث المبدأ:

• السجلات التي لا تتبع شركة يمكن مشاركتها؛
• السجلات الخاصة بالشركة لا تتاح إلا عندما تطابق سياق شركة مسموحًا به.

هذا المثال مفيد لفهم البنية، لكن لا ينبغي نسخه دون تفكير في كل نموذج مخصص.

يجب أن تطابق قواعد الأمان ملكية البيانات المقصودة.

في النموذج المخصص، حدّد ما يلي:

• هل يمكن أن يكون السجل عامًا؟
• هل يجب أن يتبع كل سجل شركة ما؟
• ما السجلات المرتبطة التي يمكنه الإشارة إليها؟
• هل ينبغي أن يرى المستخدم سجلات جميع الشركات المحددة أم الشركة النشطة فقط؟
• ماذا يحدث في المهام الآلية التي لا توجد فيها أداة تفاعلية لتبديل الشركات؟
• ما الذي ينبغي أن تراه التكاملات الخارجية؟

ينبغي حسم هذه القرارات قبل كتابة قاعدة XML.

اتساق الشركات لا يقل أهمية عن إمكانية الرؤية

تجيب قواعد الرؤية عن سؤال "هل يستطيع المستخدم رؤية هذا؟"

وتجيب قواعد الاتساق عن سؤال "هل يجوز أن تجتمع هذه السجلات معًا؟"

ويحتاج التنفيذ الآمن إلى كليهما.

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

عندما تضيف الوحدات المخصصة سجلات تراعي الشركة، اختبر عمليات الإنشاء والتعديل في عدة تركيبات من الشركات. ولا تكتفِ بالاختبار بصفة مسؤول النظام مع تحديد جميع الشركات.

تبدو مصفوفة الاختبار المفيدة على هذا النحو:

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

المعاملات بين الشركات تلغي الإدخال المكرر، لكنها تتطلب إعدادًا

يتضمن أودو 20 أتمتة للمعاملات بين الشركات الموجودة في قاعدة البيانات نفسها.

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

وتذكر وثائق أودو 20 خيارات منها:

• إنشاء فواتير الموردين من فواتير العملاء أو إشعارات الدائن؛
• إنشاء أوامر البيع من أوامر الشراء المؤكدة؛
• إنشاء أوامر الشراء من أوامر البيع المؤكدة؛
• مزامنة حركات المخزون بين الشركات.

ويمكن أيضًا اعتماد السجلات المقابلة تلقائيًا بحسب الإعداد.

ويفيد ذلك مثلًا عندما تشتري شركة توزيع من شركة تصنيع ضمن المجموعة نفسها.

فبدلًا من أن يعيد الموظفون إدخال الطرفين يدويًا:

Company A confirms document
        ↓
Configured intercompany rule
        ↓
Company B counterpart is created

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

ويحذّر أودو صراحةً من أن المراكز المالية والتوطين والإعدادات المرتبطة بها يجب أن تكون صحيحة لكي تعمل المعاملات بين الشركات.

المرجع الرسمي: تعدد الشركات في أودو 20: المعاملات بين الشركات

يوثّق أودو 20 أيضًا المقاصة بين الشركات

يوثّق أودو 20 ميزة المقاصة بين الشركات لمعالجة مشكلة مختلفة: أن تستلم شركة دفعة عن فاتورة أصدرتها شركة أخرى في قاعدة البيانات نفسها.

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

وهذا يختلف عن مشاركة سجل عميل أو منتج.

إنه مسار عمل محاسبي.

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

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

ليس كل فرع أو وحدة أعمال ينبغي أن يصبح شركة

ومن الأخطاء الشائعة أيضًا استخدام تعدد الشركات لحل كل مشكلة فصل تنظيمي.

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

وأحيانًا تكون الأداة الأنسب:

• المستودعات المتعددة؛
• المحاسبة التحليلية؛
• الأقسام؛
• الفروع؛
• فرق المبيعات المنفصلة؛
• المشاريع؛
• وحدات تشغيلية تُنفذ من خلال تخصيص مبرر.

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

أنشئ شركة أخرى عندما يتصرف الحد الفاصل في الأعمال فعلًا كشركة، لا لأن فريقًا يريد لوحة معلومات منفصلة.

تكاملات تعدد الشركات تحتاج إلى سياق شركة صريح

تشكل التطبيقات الخارجية مصدرًا آخر للالتباس.

تخيل أن تطبيقًا على الجوال يرسل ما يلي:

{
  "customer_id": 842,
  "product_id": 115,
  "quantity": 4
}

أي شركة تملك هذه المعاملة؟

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

في واجهات البرمجة والبرمجيات الوسيطة متعددة الشركات، حدّد:

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

ينطبق ذلك سواء كان العميل تطبيق جوال مبنيًا بـ Flutter، أو موصلًا لمتجر إلكتروني، أو خدمة دفع، أو ماسحًا ضوئيًا في المستودع، أو نظامًا خلفيًا آخر.

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

قائمة تحقق عملية لتعدد الشركات في أودو 20

قبل تفعيل تعدد الشركات أو توسيعه، تحقّق مما يلي.

هيكل الشركات

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

البيانات الرئيسية

• جرى تحديد المنتجات المشتركة والمنتجات الخاصة بالشركة.
• جرى تحديد جهات الاتصال المشتركة وجهات الاتصال الخاصة بالشركة.
• جرى تحديد القيم الخاصة بالشركة.
• جرى اختبار القيم الافتراضية للمنتجات والاستيراد قبل الترحيل المجمّع.

الأمان

• لا يملك المستخدمون إلا الشركات التي يحتاجون إليها.
• جرى اختبار قواعد السجلات المخصصة بمستخدمين ليسوا مسؤولي نظام.
• جرى اختبار اتساق العلاقات بين الشركات.
• تعمل المهام المجدولة في سياق شركة مقصود ومحدد صراحةً.

العمليات

• جرى اختبار المبيعات والمشتريات لكل شركة.
• جرى التحقق من المستودعات والمسارات وحركات المخزون.
• جرى التحقق من الإعدادات المحاسبية والضريبية لكل كيان على حدة.
• جرت مطابقة المستندات بين الشركات مع مسار العمل المتوقع.

التكاملات

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

السؤال الصحيح ليس "هل يدعم أودو تعدد الشركات؟"

إنه يدعمه.

السؤال الأكثر فائدة هو:

ما البيانات التي ينبغي مشاركتها، وما البيانات التي ينبغي أن تتبع شركة واحدة، وما أحداث الأعمال التي ينبغي أن تعبر حدود الشركات؟

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

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

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

المراجع الرسمية

• وثائق تعدد الشركات في أودو 20
• الدليل التعليمي للمطورين في أودو 20: الأمان في بيئة تعدد الشركات