الجديد في Odoo 20 للمحاسبة وللشركات المصرية وما يُراجع قبل الترقية

في المحاسبة وحزمة التوطين المصرية، نقل الإصدار 20.0 من Odoo إرسال الفاتورة الإلكترونية إلى نافذة الإرسال (Send)، وأضاف مسارين لضريبة الخصم، وأحلّ الحسابات الأم محل مجموعات الحسابات، وغيّر أسماء حالات الدفعة، وجعل المصروفات المعتمدة تُنشئ فواتير مسودة. وقد صدر هذا الإصدار في سبتمبر 2026، بحسب صفحة ملاحظات الإصدار على موقع odoo.com. والصور في هذه المقالة من قاعدة الديمو العامة للإصدار 20، وشركتها أمريكية تتعامل بالدولار وحزمة التوطين المصرية غير مثبتة عليها، فما يخص مصر وحدها يُعرض وصفاً بلا صورة.

وتخاطب المقالة المنشأة التي تمسك دفاترها على Odoo 17 أو 18 أو 19 وتقدّر توقيت الترقية، والمنشأة التي تبدأ على الإصدار 20 مباشرة. والمطلوب من كلتيهما أن تعرف أي هذه التغييرات يمس إقفالها الشهري وربطها بمنظومة الفاتورة الإلكترونية، وأن تختبرها على نسخة مرقّاة قبل قاعدة التشغيل.

الفاتورة الإلكترونية وضريبة الخصم في التوطين المصري

تُفرد ملاحظات الإصدار لمصر قسماً مستقلاً. فمزامنة الفاتورة مع مصلحة الضرائب المصرية (المصلحة) صارت جزءاً من نافذة Send على الفاتورة، مع تنبيهات فحص قبل الإرسال وسجل للإرسالات يمكن تتبعه، وأُضيف خيار Demo Mode لاختبار المسار داخلياً دون بيانات اعتماد. وصار ممكناً جلب ملفات PDF الخاصة بالمصلحة لعدة فواتير معاً من عرض القائمة، واختيار نوع نشاط الفرع بكوده ووصفه العربي كما في بوابة المصلحة، وتحديد كود الصنف لكل شركة على حدة. ورُبطت وحدات قياس إضافية بأكوادها لدى المصلحة، منها المتر المربع والطن والكيلووات ساعة. وفي نقاط البيع تُرسَل إيصالات البيع والمرتجع إلى المصلحة إيصالاتٍ إلكترونية. أما الإلزام بالفاتورة والإيصال وخطوات الربط ففي ربط نظام ERP بمنظومتي الفاتورة والإيصال الإلكترونيين.

وفي ضريبة الخصم أضاف التوطين المصري مسارين: Deducted Withholding للخصم المعتاد من مستحق المورد، وGross Withholding لتكبير المبلغ (gross-up) في الاتفاقات التي يكون المتفق عليه فيها هو ما يتسلمه المورد صافياً بعد الضريبة. وفي ملاحظات المحاسبة العامة، تعرض فاتورة المورد الخاضعة للخصم المستحقَّ مقسوماً إلى Amount Due وWithhold Due وNet Due، ويتيح معالج السداد سداد مبلغ الخصم وحده أو مبلغ الدفعة وحده أو الإجمالي. وتذكر الملاحظات أيضاً أن تقريري إقرار القيمة المضافة والخصم حُدِّثا لضمان التوافق مع متطلبات المصلحة، وأن ضرائب جدول وضرائب أخرى وصفتها بالمتقادمة حُذفت وحُذفت تقاريرها. وبناء الخصم ضريبةً سالبة في Odoo مشروح في الأخطاء المحاسبية المتكررة عند تطبيق نظام Odoo وكيفية ضبطها.

شجرة الحسابات

بحسب ملاحظات الإصدار، حلّت الحسابات الأم (Parent Accounts) محل مجموعات الحسابات (Account Groups) في بناء هيكل الشجرة، وصار كود الحساب اختيارياً. وتغيّر اسم خانة Allow Reconciliation على الحساب إلى Payment Reconciliation، وهي التي تحدد هل تُقترح البنود المفتوحة على الحساب في شاشة التسوية البنكية، وهل يُتوقع قيد فروق عملة عند التسوية. وصارت التسوية اليدوية ممكنة على أي حساب.

الحساب 612000 Rent في الديمو، وعليه خانة Parent Account وخانة Payment Reconciliation.

وفي التوطين المصري حُدِّثت الشجرة الافتراضية إلى هيكل من ستة أرقام تتجمع حساباته تحت حسابات أم، وعُدِّلت الحسابات الافتراضية للإيرادات والمصروفات المؤجلة ولحسابات المصروفات. وبناء الشجرة نفسها في شجرة الحسابات في Odoo وحزمة التوطين المصرية.

الدفعات والبنك

غيّر الإصدار 20 اسمي حالتين للدفعة: ما كان In Process صار Paid، وما كان Paid صار Reconciled. فكلمة Paid على الدفعة صارت تعني ما كانت تعنيه In Process، ومن يأخذها بمعناها القديم يخطئ فهم قوائم الدفعات وتقاريرها. وعلى الفاتورة نفسها تُسمى حالتا السداد In Payment ثم Paid، بحسب توثيق الدفعات في 20.0. وفي الديمو سُجلت دفعة على فاتورة، فظهرت الفاتورة In Payment وظهرت الدفعة نفسها Paid. ونُقل زر Mark as Reconciled اليدوي إلى قائمة الإجراءات، وتعلل الملاحظات ذلك بتشجيع ربط الدفعات بحركات بنكية فعلية من شاشة المطابقة البنكية.

دفعات العملاء في الديمو: دفعة سُجلت من فاتورة في حالة Paid، ودفعتان سابقتان من نقاط البيع في حالة Reconciled.

وللإقفال الشهري تغيير آخر تنص عليه ملاحظات الإصدار: كل قيد يمس حساب بنك يجب أن ينشأ من حركة بنكية (Bank Transaction)، منعاً لعدم التطابق الذي تُحدثه القيود اليدوية. ونرى أن عمولة البنك وما يشبهها تُسجَّل لذلك عند تسوية الحركة نفسها، بحساب يُختار لها أو بنموذج تسوية (Reconciliation Model)، وهما الطريقان اللذان يشرحهما توثيق التسوية البنكية لهذه البنود. وأُضيف كذلك إجراء Reset to Draft في أي قائمة لإعادة عدة قيود إلى المسودة معاً، فينبغي مراجعة من يملك هذه الصلاحية، وهي من موضوعات الصلاحيات والرقابة الداخلية في نظام Odoo.

المصروفات وتقييم المخزون والرواتب

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

مصروفان معتمدان لموظف في الديمو أنشآ مستنداً من نوع Receipt بحالة Draft في يومية Purchases، ويثبت سجل المستند أنه أُنشئ منهما.

وفي التقييم المستمر للمخزون (Perpetual) صار ممكناً إنشاء قيد الاستحقاق الذي يمس تقييم المخزون من تقرير إقفال تقييم المخزون نفسه، من تقارير Bills To Receive وBilled Not Received وInvoices To Be Issued وInvoiced Not Delivered، ويُحمَّل القيد على حساب تقييم المخزون مباشرة لا عبر حساب Stock Variation. وإذا تغيرت تكلفة صنف بعد تسليمه أو استخدامه، بتكلفة إضافية (Landed Cost) أو باختلاف سعر فاتورة المورد عن سعر الشراء، تُعدَّل قيمة التسليم بأثر رجعي، ومعها تكلفة فاتورة البيع في المحاسبة المستمرة. وهذا يهم المستورد الذي تصله تكاليف الجمارك والتخليص بعد بيع البضاعة. وصار ممكناً أيضاً تحميل التكلفة الإضافية على أصناف بعينها في التحويل، وإعدادها مشروح في دورة المشتريات في Odoo 20.0.

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

قبل الترقية من 17 أو 18 أو 19

مدد الدعم لكل إصدار، وما تفرضه كل استضافة من ترقية، في اختيار Odoo لشركة مصرية. وقبل نقل قاعدة التشغيل ننصح بما يلي:

• طلب نسخة تجريبية مرقّاة، وتجربة الدورة كاملة عليها: فاتورة وإشعار دائن ودفعة وتسوية بنكية وإقفال شهر، ومعها الربط بالأنظمة الخارجية الذي يذكره توثيق الترقية في 20.0. والقاعدة التي عليها وحدات خاصة لا تُرقّى قبل أن تتوفر نسخة منها للإصدار المستهدف.
• استعمال بيانات اعتماد البيئة التجريبية للمصلحة (preproduction) على النسخة المرقّاة، أو خيار Demo Mode، حتى لا تصل فاتورة اختبار إلى بيئة التشغيل. فتوثيق التوطين المصري ينص على أن بيانات البيئتين مختلفة، وعلى الاختبار في البيئة التجريبية قبل إصدار فواتير فعلية.
• مراجعة عناوين العملاء بعد حذف حلوان و6 أكتوبر من قائمة المحافظات (States) في التوطين المصري ونقل سجلاتهما إلى القاهرة والجيزة، ومراجعة أكواد الأصناف ووحداتها ونشاط كل فرع.
• لمن يستعمل التقييم المستمر بالنظام الأنجلوسكسوني (Anglo-Saxon Perpetual): حسابات المخزون الوسيطة (Stock Input وStock Output) لم تعد تُستعمل منذ الإصدار 19، وأي رصيد فيها يُنقل بقيد إلى حساب تقييم المخزون قبل الترقية إلى 19 أو بعدها، بحسب توثيق تقييم المخزون في 20.0. ونرى أن هذا يخص من يرقّي من 17 أو 18، ومن انتقل إلى 19 ولم ينقل هذه الأرصدة بعد.
• مراجعة شجرة الحسابات بعد الترقية، والضرائب التي حذفها التوطين المصري، وتقارير الذمم والمتابعة التي تعتمد على حالة الدفعة.

ويتولى قسم استشارات أنظمة ERP بالمكتب تقدير أثر الترقية إلى Odoo 20 على دفاتر المنشأة، واختبارها على نسخة مرقّاة بما فيها الربط بمنظومة الفاتورة الإلكترونية، قبل نقل قاعدة التشغيل.

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

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

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

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