في اجتماع استلام ERP، نفذ المدير العملية ونجحت. ثم دخل موظف المشتريات فوجد إجراءً لا يفترض أن ينفذه متاحًا له. هذا الاختلاف يكشف لماذا لا يكفي عرض واحد بحساب قوي: المطلوب اختبار الأدوار التي ستعمل فعلًا، ومراجعة ما يحدث عند جمع صلاحياتها.
ابدأ بقرار الإدارة عن العمل
قبل إعداد النظام، حدد من يجهز الطلب ومن يراجعه ومن يعتمد ومن يقرأ فقط. هذه قرارات تخص إجراءات المنشأة ومسؤوليها؛ لا ينبغي تركها لاستنتاج المطور من مسميات الوظائف. قد تختلف صلاحيات موظفين يحملان المسمى نفسه بحسب المهمة أو السجل أو التفويض المعتمد.
نستخدم مؤسسة افتراضية تشتري مستلزمات معارض، وقد اختارت داخليًا فصل إعداد طلب الشراء عن اعتماده. في العينة أمين مخزن وموظف مشتريات ومشرف، ثم مستخدم يجمع دورين. هذه سياسة مختارة للمثال، وليست قاعدة محاسبية أو متطلب امتثال موحدًا لكل منشأة.
اكتب المتوقع قبل مشاهدة الشاشة
ليحدد صاحب العملية نتائج السماح والرفض لأفعال معلومة على سجلات معلومة. عبارة «صلاحية مشتريات» قد تخفي فروقًا بين قراءة طلب وتعديله واعتماده وحذفه. ويحتاج النطاق تحديد هذه الأفعال بمصطلحات يفهمها المستخدم والمنفذ دون افتراض أنها متطابقة في كل ERP.
اتفق على حسابات تجريبية وبيانات مناسبة ونسخة وبيئة معلومتين. يجهز المختص التجربة بتفويض، ولا يحتاج صاحب الإدارة مشاركة كلمة مرور شخصية أو تجربة صلاحيات على عمليات إنتاج حقيقية. سجّل كذلك ما لم تجهزه البيئة حتى لا يعرض غياب الاختبار كنجاح.
مصفوفة يمكن للإدارة اعتمادها
| حالة المراجعة | السؤال | الأثر المسجل |
|---|---|---|
| دور مفرد | هل ينفذ الإجراء المسموح على السجل المقصود؟ | المتوقع والفعل والدليل |
| إجراء ممنوع | هل يظل خارج صلاحية هذا الدور؟ | نتيجة الرفض دون تغيير غير معتمد |
| دوران معًا | هل تنشأ قدرة تتعارض مع السياسة؟ | المجموعات الفعلية وقرار معالجة |
| استثناء | من يجيزه ولماذا ومتى يراجع؟ | حدود ومسؤول ومرجع اعتماد |
أضف لكل سطر من شارك في المراجعة وتاريخها، ثم النتيجة بعد أي تصحيح. ولا تختزل القبول في منع الأفعال فقط؛ المستخدم المخول الذي يعجز عن أداء مهمته يحتاج معالجة أيضًا. المصفوفة تربط سلوك البرنامج بسياسة الإدارة، لا بمجرد عدد الأدوار التي أنشئت.
اسم المجموعة ليس كل ما يملكه الحساب
توضح وثائق Odoo 19 أن المجموعات قد تورث صلاحيات، وتفرق حقوق النماذج عن قواعد السجلات. لذلك اطلب من المنفذ مراجعة الصلاحيات الفعلية للحساب المختبر، لا اختيارًا ظاهرًا واحدًا في شاشة الإعداد. وجود مجموعة إضافية قد يغير تفسير نتيجة لم يتوقعها صاحب الإدارة.
وفي المثال، قد تسمح مهمتان منفصلتان بأفعال مقبولة لكل منهما، لكن جمعهما لشخص واحد يخالف سياسة المؤسسة. اختبر هذه التركيبة بوصفها حالة مستقلة، ثم حدد هل يلزم تغيير التعيين أو الإجراء أو استثناء معلوم. لا تجعل صلاحية واسعة حلًا صامتًا لتسهيل التدريب.
إنشاء قاعدة فصل مهام لا يثبت تحققها
تنبه وثيقة Dynamics 365 إلى أن إنشاء قاعدة فصل واجبات لا يتحقق تلقائيًا من توافق الأدوار والتعيينات الموجودة؛ يلزم التحقق بعد الإنشاء أو التعديل. هذه آلية موثقة في منتج بعينه، لكنها تذكّر المشتري بسؤال مهم: أين دليل تحقق السياسة بعد إعدادها؟
لا نفترض وجود الآلية نفسها في Odoo أو أي نظام مخصص. اطلب من الشركة بيان ما يدعمه الحل وما يحتاج مراجعة إدارية أو إجراءً إضافيًا. إذا اختير استثناء، فليكن له سبب ومسؤول وحد مراجعة، دون تحويله إلى موافقة مفتوحة تبقى بلا متابعة بعد انتقال الموظف لمهمة أخرى.
اختبر بالحساب المناسب ثم احفظ الحدود
تذكر Odoo وضع superuser الذي يتجاوز الحقوق وقواعد السجلات؛ لا تخلطه بكل حساب إداري. اسأل بأي حساب ووضع نُفذ العرض، واطلب دليلًا يناسب الاستخدام اليومي. كذلك فإن إخفاء زر لا يشرح وحده حدود الإجراءات الأخرى الداخلة في النطاق أو أثر حفظ سجل.
استكمل قبول تدريب الأدوار بهذه المصفوفة، واستعن بـموجز الفحص الأمني للنطاق الأوسع. عند طلب تنفيذ ERP مع نكست ويف، أحضر سياسة الإدارات وحالات الجمع والاستثناء؛ نجاح العينة لا يمثل اعتمادًا أمنيًا أو تغطية كل صلاحية ممكنة.
سند الفروق
قُرئت صلاحيات Odoo 19 وفصل الواجبات في Dynamics في 4 نوفمبر 2026، دون تعديل حسابات. إعداد بمساعدة الذكاء الاصطناعي مع مراجعة المعلومات والترجمة.
