الصلاحيات والرقابة الداخلية في نظام Odoo: من يفعل ماذا

ملخص

• الصلاحيات في Odoo 19.0 (odoo.com/documentation/19.0) طبقتان: دور يُحدَّد للمستخدم عند إضافته (Administrator أو User للمستخدم الداخلي، وPortal أو Public للطرف الخارجي)، ومجموعة صلاحية مستقلة لكل تطبيق تختلف درجاتها من تطبيق لآخر، وأشيعها Blank/None وUser: Own Documents وUser: All Documents وAdministrator.
• للمحاسبة حقل خاص، اسمه Accounting في 19.0 (وكان Invoicing في 18.0)، بدرجات يحددها التطبيق نفسه: تمتد في الشفرة المصدرية لنسخة 19.0 من Invoicing (الفواتير والمدفوعات والتقارير الأساسية) إلى Administrator (صلاحية كاملة تشمل الإعدادات).
• الوصول بين الشركات يضبطه حقلا Companies وDefault Company على نموذج المستخدم، والمنتجات وجهات الاتصال مشتركة بين الشركات ما لم يُحدَّد عليها حقل Company.
• الفصل بين إنشاء المورد واعتماد الفاتورة وتسجيل السداد يقوم أساساً على تتابع الحالات (مسودة ← ترحيل ← سداد) وعلى ضوابط بعينها، لأن درجة Invoicing الواحدة تشمل الفواتير والمدفوعات معاً؛ ولأوامر الشراء اعتماد مدمج فوق مبلغ أدنى، أما الحد المالي على أي زر آخر فيحتاج Approval rules في Studio.
• مسار المراجعة المحاسبي (Audit Trail) يسجل كل تغيير يمسّ المحاسبة بتاريخه ومستخدمه وقيمتيه، والوضع التقييدي يمنع حذف ما يُتتبَّع نهائياً.
• تواريخ الإقفال الموثَّقة مختلفة الأثر (Lock Everything وLock Tax Return وHard Lock الذي لا رجعة فيه)، والقيد المرحَّل يُصحَّح بعكسه أو بإعادته مسودة بعد رفع القفل، لا بحذفه.

الأدوار والمجموعات لكل تطبيق

عند إضافة مستخدم من Settings ‣ Users ‣ Manage Users يُحدَّد له دور واحد من أربعة تسردها وثائق 19.0: Administrator، وصفته الوثيقة بأنه "an internal user with access to technical features, product creation, export, and other advanced permissions"، وUser دونه صلاحية، وPortal لعميل أو مورد لا يرى إلا بياناته، وPublic لزائر الموقع (وتضيف نسخة 20.0، الصادرة في سبتمبر 2026، دوراً داخلياً ثالثاً هو Light لا يصل إلى تطبيقات مثل المشتريات والمحاسبة). وفوق الدور، لكل تطبيق مجموعة مستقلة تُختار من تبويب Access Rights بدرجة من قائمة منسدلة تختلف خياراتها من تطبيق لآخر، وأشيعها: "Blank/None، User: Own Documents، User: All Documents، or Administrator". والمحاسبة لا تتبع هذا التدرّج: حقلها، واسمه Accounting في 19.0 (وInvoicing في 18.0)، له درجات يحددها التطبيق نفسه، أدناها في الشفرة المصدرية لنسخة 19.0 درجة Invoicing، "Invoices, payments and basic invoice reporting"، وأعلاها Administrator، "Full access, including configuration rights"، وهي الدرجة التي توصي الوثائق بمنحها لمحاسب المنشأة.

وإنشاء مورد أو عميل جديد ليس جزءاً من أي درجة في المحاسبة: موضعه حقل Contact: Creation ضمن Master Data، ويأتي كذلك في الشفرة المصدرية لنسخة 19.0 مع درجة Administrator في المشتريات أو المبيعات أو المخزون. وتعديل صلاحيات مستخدم آخر يحتاج صلاحية خاصة بها هي نفسها (Administration بقيمة Settings أو Access Rights)، إذ "only an administrator can change access rights"؛ ووضع Superuser يتجاوزها جميعاً دفعة واحدة، وتحذّر الوثيقة من استخدامه إلا "with extreme caution".

وتبويب Security بملف كل مستخدم يسرد الأجهزة التي دخل منها، ويحفظ الملف بيانات الدخول ومنها عنوان IP، وتوصي الوثيقة بمراجعتها "periodically, to ensure all access is from the user, and no one else has accessed the database" — لا تعيين الصلاحية مرة عند التوظيف وحدها.

الوصول بين الشركات المتعددة

في قاعدة بها أكثر من شركة، يضبط الوصول حقلا Companies وDefault Company على تبويب Access Rights: الأول الشركات التي يدخل عليها المستخدم، والثاني ما يُفتح له افتراضياً. والسجلات — كمنتج أو جهة اتصال — مشتركة بين كل الشركات ما لم يُحدَّد عليها حقل Company، فتصير عندها مرئية لمن دخل بتلك الشركة فقط. ومعاملات الشركات البينية (Inter-Company Transactions) تُنشئ تلقائياً فاتورة المورد أو أمر البيع أو أمر الشراء المقابل، وتزامن حركات المخزون، بين شركتين في القاعدة نفسها — وخيار Validated يعتمد كل مستند مقابل دون مراجعة.

الفصل بين إنشاء المورد واعتماد الفاتورة وتسجيل السداد

درجات Odoo القياسية لا تفصل كل خطوة عن الأخرى: درجة Invoicing تشمل الفواتير والمدفوعات معاً، فيقوم الفصل أساساً على تتابع الحالات وعلى ضوابط بعينها. فاتورة المورد تُنشأ مسودة، وبعد Confirm "the status changes to Posted... once confirmed, a vendor bill can no longer be updated"، ثم يسجَّل السداد بخطوة منفصلة بالضغط على Pay. وControl Policy على كل منتج يحدد أساس الفوترة: On ordered quantities يبني المسودة فور تأكيد أمر الشراء، وOn received quantities لا يبنيها إلا بعد استلام جزء من الكمية. وإن فُعِّل 3-way matching حملت كل فاتورة حقل Should Be Paid (Yes/No/Exception)، غرضه ألا تُسدَّد فاتورة إلا بعد استلام بعض المنتجات المطلوبة أو كلها؛ وإن عُدِّلت مسودة الفاتورة صار الحقل Exception، لكن Odoo "does not block the changes"، ويمكن تغيير الحقل يدوياً. وعلى كل مورد، حقل Auto-post bills يضبط أتمتة الاعتماد بين Always وAsk after 3 validations without edits وNever، وقيمة Always ترحِّل فواتير هذا المورد التي تُنشأ تلقائياً، بالبريد الإلكتروني أو برفع ملف PDF، دون أن يعتمدها أحد.

ولأوامر الشراء حدّ مالي مدمج: إعداد Purchase Order Approval في تطبيق المشتريات، بحقل Minimum Amount، يحوّل أي أمر يبلغ هذا المبلغ أو يتجاوزه إلى حالة To Approve ما لم يؤكده صاحب درجة Administrator في المشتريات. والإعداد قائم في الشفرة المصدرية لنسخة 19.0، وإن لم تعد وثائقها تشرحه كما شرحته وثائق 13.0. ولأي زر آخر، كتأكيد فاتورة، الأداة التي تقدّمها وثائق 19.0 هي Approval rules في Studio: تُحدَّد لها Approvers أو Approver Group وشرط اختياري يقيّد متى تُطلب الموافقة، ويمكن تسلسل أكثر من خطوة وتفعيل Exclusive Approval كي لا يعتمد مستخدم أكثر من خطوة على السجل نفسه، وكل قرار يُسجَّل في chatter السجل.

مسار المراجعة وعدم قابلية الحذف

من Accounting ‣ Review ‣ Audit Trail يُعرض تقرير "tracks changes made to fields that have an impact on accounting" بتاريخ كل تغيير ومستخدمه وقيمتيه. وخانة Restrictive Audit Trail (في Accounting ‣ Configuration ‣ Settings، قسم Reporting) تمنع حذف أي سجل خاضع للتتبّع نهائياً؛ لا خيار عندها إلا الإلغاء أو الأرشفة.

وبمعزل عن ذلك، تأمين آخر للقيود المرحَّلة بالتجزئة: تفعيل Secure Posted Entries with Hash على يومية يجعل كل قيد يُرحَّل فيها يحمل بصمة SHA-256 لبياناته الجوهرية، متسلسلة مع بصمة سابقه في سلسلة يكسرها أي إقحام لاحق. والتحذير هنا بلا استثناء إطلاقاً: "once you post an entry in a restricted journal, you cannot disable the feature anymore, nor edit any secured entry" — بخلاف تواريخ الإقفال التالية، إذ لا يمتنع الاستثناء فيها إلا على Hard Lock.

تواريخ الإقفال والمسودة التي تبقى معلَّقة

تُضبط تواريخ الإقفال من Accounting ‣ Accounting ‣ Lock Dates، وتشرح وثائق 19.0 ثلاثة منها مختلفة الأثر:

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

والقيد المرحَّل لا يُحذف وهو مرحَّل، بل يُصحَّح بأحد خيارين: Reverse Entry يعكسه بقيد مضاد، أو Reset to Draft يعيده مسودة ليُعدَّل ويُرحَّل من جديد. غير أنه متى عاد مسودة أمكن حذفه — ولصاحب Administrator على المحاسبة حذفه ولو ترك فجوة في الترقيم — ما لم يكن Restrictive Audit Trail مفعَّلاً. والفحوص التي يشغّلها الإقفال السنوي وإقرار كل فترة ضريبية تضم فحصاً للمسودات داخل الفترة، تُرحَّل بموجبه أو يُغيَّر تاريخها المحاسبي؛ لكن الفحص الذي يفشل يمكن وسمه Reviewed أو Supervised وتجاوزه دون إصلاح، ويُسجَّل كل تغيير في حالته في الـ chatter. والمبدأ نفسه على المستخدمين: من يغادر يُؤرشف لا يُحذف، فتبقى القيود القديمة منسوبة إليه كما رُحِّلت.

ما يترتب على المنشآت

• تحديد من يحمل Administrator على المحاسبة وعلى المشتريات تحديداً، لا تعميمه على كل مستخدم داخلي.
• فصل حق إنشاء المورد أو العميل — Contact: Creation ودرجات Administrator في المشتريات والمبيعات والمخزون التي تحمله أيضاً — عن حق ترحيل القيد.
• ضبط 3-way matching وControl Policy لكل صنف قبل الاعتماد على الفوترة التلقائية، ومراجعة الموردين المضبوطين على Auto-post bills بقيمة Always دورياً.
• تفعيل Purchase Order Approval بمبلغ أدنى لأوامر الشراء، وبناء قاعدة اعتماد في Studio لأي مستند آخر يتجاوز مبلغاً محدداً، بدل الاكتفاء بصلاحية الترحيل العامة.
• تفعيل Restrictive Audit Trail للشركة، وSecure Posted Entries with Hash على اليوميات الرئيسية، قبل التشغيل الفعلي لا بعده.
• ضبط Lock Everything عند إقفال كل فترة، وLock Tax Return قبل مراجعة كل إقرار ضريبي، وقصر درجة Administrator على المحاسبة، وهي التي تمنح الاستثناء، على من يحتاجها.
• مراجعة تبويب Security لكل مستخدم دورياً، وأرشفة من غادر بدل حذفه.

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

محمود ناصف — محاسب قانوني، الشريك المؤسس

عضو جمعية المحاسبين والمراجعين المصرية
عضو جمعية الضرائب المصرية
عضو الجمعية المصرية للمالية العامة والضرائب

صفحة الشريك · حجز استشارة

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