الأخطاء المحاسبية المتكررة عند تطبيق نظام Odoo وكيفية ضبطها

ملخص

• من الأخطاء المحاسبية المتكررة عملياً في تطبيق Odoo أخطاء إعداد لا استخدام، لكلٍّ منها حقل أو مسار يمنعه كما يوثقه الإصدار 19.0 (odoo.com/documentation/19.0).
• الخصم من المنبع في Odoo ضريبة سالبة بحسابها وTax Grids ومجموعتها، لا تسوية يدوية خارج شجرة الضرائب.
• Suspense Account في يومية البنك يحمل كل حركة لم تُسوَّ بعد؛ رصيده المتضخم علامة تسويات متأخرة لا رصيداً حقيقياً.
• طريقة تقييم المخزون (Perpetual أو Periodic) مستقلة عن نظام المحاسبة (Anglo-Saxon أو Continental)، وهي التي تحدد متى تصل التكلفة إلى قائمة الدخل.
• تاريخ إقفال واحد لا يكفي: Lock Everything يقبل الاستثناء، وLock Tax Return مستقل عنه لحركات الضريبة، وHard Lock لا رجعة فيه.
• نموذج توزيع تحليلي بلا بادئات حسابات قد يُحمِّل بنود الميزانية مركز تكلفة، وحصر البادئات على الإيرادات والمصروفات يمنع ذلك.

الضرائب: تصميم الضريبة قبل ترحيلها

لكل ضريبة في Odoo Tax Type: Sales أو Purchase أو None، وهو ما يحدد أين تُتاح للاختيار لا اسمها. وعند تطبيقها تضيف Odoo تلقائياً Tax Grids على بند الفاتورة وبند الضريبة في القيد، ومن هذه الوسوم يُبنى تقرير الإقرار (Tax Return)، فضريبة بلا Tax Grid صحيح تظهر في الفاتورة ولا تصل إلى سطرها في الإقرار.

والخصم من المنبع يُعرَّف في Odoo بضريبة سالبة لا بتسوية يدوية: من Accounting ‣ Configuration ‣ Taxes يُدخَل المبلغ سالباً، وتُنشأ من تبويب Advanced Options مجموعة ضرائب (Tax Group) للخصم. وحزمة التوطين المصرية (l10n_eg) في 19.0 تُنشئ هذه الضرائب جاهزة، أما الإصدار 20 (سبتمبر 2026) فيعيد تنظيم الخصم في التوطين المصري بمسارين، Deducted Withholding وGross Withholding، فيُراجَع الإعداد عند الترقية. وتفصيل الخصم نفسه في دليل نموذج 41.

اليوميات والحساب المعلّق والتسوية البنكية

في يومية المبيعات Default Income Account وفي المشتريات Default Expense Account: الحساب الذي تُرحَّل عليه الفاتورة ما لم يُحدَّد حساب على فئة المنتج أو المنتج؛ والحساب الافتراضي الخطأ قد يمر على فواتير كثيرة قبل اكتشافه لأنه لا يُخالف شيئاً ظاهرياً.

وعن Suspense Account في يوميات البنك والخزينة وبطاقات الائتمان يقول التوثيق: «تُرحَّل حركات هذه اليومية على هذا الحساب إلى أن تُسوّى، وعندها يحل محله الحساب الذي سُوّيت الحركة مقابله»، فرصيده في أي لحظة هو ما لم يُسوَّ بعد. والمدفوعات لا تُنشئ قيداً أصلاً دون حسابات Outstanding Receipts/Payments؛ وإن جُعل الحساب البنكي الرئيسي لليومية حساباً Outstanding، تُعلَّم الفاتورة Paid فور تسجيل الدفعة قبل وصول حركة البنك. ونماذج التسوية الآلية تُطبَّق بترتيبها: إن طابقت الحركة أكثر من نموذج طُبِّق أولها وحده، فنموذج في غير موضعه يُحمِّل المبلغ تلقائياً على حساب خطأ.

تقييم المخزون: طريقة الإثبات ونظام المحاسبة

في Accounting ‣ Configuration ‣ Settings، قسم Inventory Valuation، تُضبط على مستوى الشركة، مع جواز تجاوزها على فئة المنتج، Inventory Valuation (Perpetual (at invoicing) أو Periodic (at closing)) وInventory Cost Method (FIFO أو AVCO أو Standard Price). والطريقة مستقلة عن نظام Anglo-Saxon أو Continental: المعتاد Periodic مع Continental وPerpetual مع Anglo-Saxon، وتسمح Odoo بغير ذلك، والطريقة هي التي تحدد متى تُحمَّل التكلفة على قائمة الدخل: عند ترحيل فاتورة المورد في Periodic، وفاتورة العميل في Perpetual.

وهنا فارق جوهري بين الإصدارين: في 18.0 كان الاختيار على فئة المنتج (Manual أو Automated بعد تفعيل Automatic Accounting)، وكانت محاسبة Anglo-Saxon الآلية تعتمد حسابين وسيطين مختلفين: Stock Input وStock Output. وفي 19.0 لم يعودا مستخدمَين، وحل محلهما حساب وسيط من نوع جديد هو Variation يختلف نوعه حسب المزيج، بجانب حساب Valuation للأصل. والقاعدة التي تُرقّى دون ترحيل رصيدهما المتبقي إلى Valuation بقيد يومية، قبل الترقية أو بعدها، لا تحتفظ بقيمة مخزون صحيحة في الميزانية.

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

من بين تواريخ الإقفال في Accounting ‣ Accounting ‣ Lock Dates ثلاثة مختلفة الأثر:

والمسودة حالة رقابة مقصودة لا تقصير: من فحوص Odoo، بحسب التوطين، No draft entries عند الإقفال السنوي وDraft entries عند مراجعة الإقرار الضريبي، وكلاهما يطلب مراجعة كل مسودة في الفترة وترحيلها أو تغيير تاريخها قبل الاعتماد. أما الرجوع عن الترحيل فأصعب: خيار Secure Posted Entries with Hash يُقيّد تعديل قيود اليومية ولا يُزال بعد أول قيد مُرحَّل عليها؛ وبعد ترحيل إقرار الفترة تُقفَل أمام حركات الضريبة الجديدة وتُسجَّل تصحيحات فواتيرها في الفترة التالية، والخياران الموثقان لتصحيح قيد الإقرار نفسه هما Reverse Entry، أو Reset to Draft بعد إزالة Lock Tax Return باستثناء. فالترحيل المبكر يستبدل تصحيحاً بسيطاً بعكس رسمي موثق.

التوزيع التحليلي وفروق العملة

خطة تحليلية (Analytic Plan) قد تُجعل Mandatory، ونموذج توزيع (Analytic Distribution Model) يُطبَّق تلقائياً، وكلاهما يُحصَر ببادئات الحسابات: Financial Accounts Prefixes في تبويب Applicability بالخطة، وAccounts Prefixes على النموذج. فإن تُرك الحقل فارغاً أو اتسع ليشمل الذمم أو البنك أو المخزون، قد تكتسب بنود ميزانية في القيود اليدوية مركز تكلفة لا معنى له، فتختلط التقارير التحليلية بحركات تمويلية.

وفروق العملة المحققة تُسجَّل تلقائياً عند التسوية على اليومية وحسابي الربح والخسارة المحددة في Accounting ‣ Configuration ‣ Settings، قسم Default Accounts. أما غير المحققة على أرصدة لم تُسوَّ، كبنك أو ذمم أجنبية بسعر تاريخي، فتُعرض في تقرير Unrealized Currencies (Accounting ‣ Review) ولا تصل إلى الميزانية حتى يُرحَّل منه قيد Adjustment Entry ينعكس تلقائياً في تاريخ العكس (Reversal Date). والاكتفاء بالفروق المحققة دون هذا التقرير عند كل إقفال يترك الأرصدة الأجنبية بسعر قديم.

الفوترة الإلكترونية: إعداد الربط في النظام

يعتمد التكامل على وحدتين: l10n_eg (حزمة التوطين) وl10n_eg_edi_eta (الربط بمنظومة المصلحة). ويُضبط الربط من Accounting ‣ Configuration ‣ Settings ‣ ETA E-Invoicing Settings بإدخال ETA Client ID وETA Secret، وهما بيانات الدخول التي تصدرها المصلحة عند تسجيل النظام على بوابتها؛ وبيئة الاختبار (preproduction) منفصلة عن التشغيل (production) ببيانات مختلفة تُحدَّث في Odoo عند الانتقال. ولكل فرع جهة اتصال من نوع Company مستوفاة العنوان والرقم الضريبي، ويومية مبيعات بإعداداتها (ETA Activity Code وETA Branch ID). وعلى كل صنف حقل ETA Item code تحت تبويب Accounting، يُستخدَم حين لا يطابق الباركود كود الصنف لدى المصلحة؛ وتفصيل الإلزام ومراحله في دليل الفاتورة الإلكترونية.

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

• مراجعة Tax Type وTax Grids على كل ضريبة، وضبط الخصم من المنبع ضريبةً سالبة لا تسويةً يدوية، ومراجعته عند الترقية إلى الإصدار 20.
• إبقاء Suspense Account قريباً من الصفر بتسوية شهرية، والتحقق من ترتيب نماذج التسوية الآلية.
• اختيار طريقة تقييم المخزون عن قصد لا بالافتراضي، وترحيل أرصدة Stock Input وStock Output إلى Valuation عند الترقية إلى 19.0.
• ضبط Lock Everything وLock Tax Return كل فترة في النظام لا بتعليمات شفهية، وقصر صلاحية الاستثناء على من يحتاجها.
• حصر بادئات الحسابات في الخطط ونماذج التوزيع التحليلي على الإيرادات والمصروفات، وتشغيل تقرير Unrealized Currencies عند كل إقفال.
• تسجيل كل فرع بيومية وبيانات ETA خاصة به، وتحديث بيانات الدخول عند الانتقال إلى التشغيل الفعلي.

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

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

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

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

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