ما الذي تطلبه المنظومة منك فعلًا
للمنظومة في مصر نصفان. الفاتورة الإلكترونية تغطي المبيعات بين الشركات: كل فاتورة وإشعار دائن وإشعار مدين يُرسَل إلكترونيًا إلى مصلحة الضرائب المصرية (ETA)، ويُوقَّع بتوقيع إلكتروني معتمد، ويُتحقَّق منه قبل أن يُعتدّ به. والإيصال الإلكتروني يغطي المبيعات للمستهلك النهائي: كل إيصال من محل أو مطعم أو عيادة أو صيدلية يُبلَّغ عنه من جهاز نقاط بيع (POS) أو نظام مسجَّل لدى المصلحة.
النصفان يشتركان في الأساسات نفسها: ملف ممول مسجَّل على بوابة المصلحة، وأصناف مكوَّدة وفق معيار GS1 أو تكويد EGS الخاص بالمصلحة، وعملاء معرَّفون بأرقام تسجيلهم الضريبي، ومستندات صادرة بالهيكل الذي تحدده المصلحة — لا بتصميم قالب فاتورتك القديم. الشركات تنضم إلى المنظومة على مراحل بحسب الحجم والنشاط، فراجع دائمًا الجدول الحالي للمصلحة لتعرف موقعك.
لماذا يتوقف حلّ «استخدم البوابة فقط» عن العمل
بوابة المصلحة مناسبة تمامًا لبضع فواتير في الشهر. بعد ذلك يصبح الإدخال اليدوي هو عنق الزجاجة: كل حقل يُكتب مرتين (مرة في نظامك ومرة على البوابة)، وأكواد الأصناف تُبحث يدويًا، وخطأ مطبعي في رقم تسجيل عميل يعني رفضًا لا تكتشفه إلا لاحقًا. ينتهي الأمر بالفريق المالي يقضي شهره في إدخال البيانات بدلًا من قراءة الأرقام.
المشكلة الأعمق أن البوابة تتحوّل إلى مصدر ثانٍ للحقيقة. وحين تتباعد الفاتورة في نظامك المحاسبي عن نظيرتها على البوابة — بيع أُلغي ولم يُلغَ إلكترونيًا، أو إشعار دائن يشير إلى مستند خاطئ — تصبح المطابقة وقت الإقرار الضريبي مؤلمة وعرضة للخطأ.
- كل فاتورة تُكتب مرتين
- أكواد الأصناف تُبحث يدويًا
- الرفض يُكتشف بعد أيام
- نسختان من كل مستند
- الفاتورة تُوقَّع وتُرسَل عند التأكيد
- الكود يُحفظ مرة واحدة على الصنف
- الرفض يظهر داخل الفاتورة نفسها
- سجل واحد وحالة واحدة ومسار تدقيق واحد
ماذا يعني «نظام ERP جاهز» عمليًا
نظام ERP الجاهز فعلًا للمصلحة يتعلّق بالبيانات خلف الربط أكثر مما يتعلّق بالربط نفسه. أربعة أشياء يجب أن تكون صحيحة قبل خروج فاتورة واحدة: سجلات عملاء نظيفة بأرقام التسجيل الضريبي والعناوين بالصيغة المطلوبة؛ وكل صنف قابل للبيع مرتبط بكود GS1 أو EGS مع وحدة القياس الصحيحة؛ وأنواع ضريبة القيمة المضافة وأنواعها الفرعية مضبوطة لتطابق قائمة المصلحة بما فيها الإعفاءات وضريبة الجدول حيث تنطبق؛ وإعداد للتوقيع — رمز التوقيع الإلكتروني (Token) أو HSM للفواتير، وتسجيل الجهاز للإيصالات — يستطيع النظام استخدامه دون أن يوصّل أحدٌ شيئًا يدويًا.
ثم تأتي دورة الحياة. المستند المُرسَل ليس نهاية الطريق: قد يُقبل أو يُرفض أو يُلغى لاحقًا من جهتك أو يرفضه المشتري، وكل حالة من هذه يجب أن تعود إلى نظام ERP لتظهر الفاتورة بحالتها الحقيقية. وإشعارات الدائن والمدين يجب أن تشير إلى المعرّف الفريد الذي منحته المصلحة للمستند الأصلي، لا إلى رقمك الداخلي فقط. أتقِن هذه المسارات وتتحوّل مطابقة نهاية الشهر إلى تقرير لا إلى مشروع.
- 01سجِّل ونظِّف البيانات الرئيسيةملف الممول، وأرقام التسجيل الضريبي للعملاء، وأكواد الفروع، والعناوين بصيغة المصلحة.
- 02كوِّد كل صنفاربط المنتجات والخدمات بأكواد GS1 أو EGS مع الوحدات الصحيحة — قبل الإطلاق لا بعده.
- 03اضبط الضرائبأنواع الضريبة وأنواعها الفرعية والإعفاءات وضريبة الجدول كما تُدرجها المصلحة تمامًا.
- 04وقِّع وأرسِل تلقائيًاتأكيد الفاتورة يوقّعها ويرسلها؛ والإيصالات تُبلَّغ من POS لحظة إصدارها.
- 05تابع الحالة وطابِقمقبول أو مرفوض أو ملغى — تنعكس على المستند وتُطابَق في نهاية الشهر.
أين يقع Odoo من كل هذا
Odoo مناسب طبيعيًا لهذا لأن المبيعات والمخزون والمحاسبة ونقاط البيع تتشارك قاعدة بيانات واحدة أصلًا — فالفاتورة التي ترسلها إلى المصلحة هي السجل نفسه الذي يراه المخزن ومندوب المبيعات. يمكن إعداد نسختَي Community وEnterprise لضريبة القيمة المضافة والفاتورة الإلكترونية في مصر، والتوطين المصري في Odoo يغطي هيكل مستندات المصلحة؛ والعمل الحقيقي في ربط أصنافك وضرائبك وعملائك بشكل صحيح، وفي اختبار دورة القبول والرفض والإلغاء كاملة على بيئة التجربة الخاصة بالمصلحة قبل لمس البيانات الفعلية.
أما في التجزئة والمطاعم فجانب الإيصال الإلكتروني هو حيث يثبت نظام POS المتكامل قيمته: الإيصالات تُبلَّغ لحظة إصدارها، وانقطاع الإنترنت يضعها في طابور الانتظار بدلًا من فقدها — بشرط أن تكون الشبكة تحت نقاط البيع متينة، وهذا سؤال شبكات قبل أن يكون سؤال محاسبة.
الأخطاء التي نراها أكثر
تكويد الأصناف بعد الإطلاق: كل منتج بلا كود يعطّل الفاتورة التي يظهر فيها؛ التكويد ممل، فافعله مرة واحدة مبكرًا مع شخص يفهم الكتالوج. ضبط الضرائب من الذاكرة بدل قائمة المصلحة: أي اختلاف في النوع الفرعي رفضٌ صامت. تخطّي بيئة التجربة لأن الموعد قريب: هذا بالضبط الوقت الذي يكلّف فيه الاختبار السيّئ أكثر ما يكلّف. والتعامل مع الربط كمشروع تقني بلا مالك في الإدارة المالية: من يقرأ رسالة الرفض يجب أن يكون من يستطيع إصلاح البيانات.
وخطأ آخر: اختيار أداة محاسبة لأنها «تدعم الفاتورة الإلكترونية» دون أن تسأل هل تدير أيضًا مبيعاتك ومخزونك وإيصالاتك. الامتثال هو سبب البداية؛ ونظام واحد للعمل كله هو سبب استمرار العائد.
متى لا تبالغ في الهندسة
شركة صغيرة جدًا ببضع فواتير شهريًا وبلا مخزون تتابعه يمكنها العيش على البوابة — فالربط سيكلّف أكثر مما يوفّره من وقت. لمن عداها، السؤال ليس هل تربط بل متى: كلما نُظِّفت البيانات الرئيسية مبكرًا صارت كل خطوة بعدها أرخص. محاسبك يقرّر ما يجب أن تقدّمه؛ وأنظمتك تقرّر كم تلتهم من شهرك.