الفواتير الإلكترونية جزء من المحاسبة الحديثة
تتواصل رقمنة المحاسبة. ومنذ زمن، تجاوزت تنسيقات الفواتير الإلكترونية مجرد ملف PDF يُرسل بالبريد الإلكتروني.
تحتوي الفاتورة الإلكترونية الحقيقية على بيانات مهيكلة تستطيع أنظمة المحاسبة وتخطيط موارد المؤسسات معالجتها تلقائيًا.
وهذا تحديدًا ما نهدف إلى معالجته بمشروعنا الجديد مفتوح المصدر المخصص لـ Odoo 19 Community.
طوّرنا عدة إضافات نتيحها مجانًا لمجتمع Odoo.
المشروع متاح للجميع على GitHub:
Odoo 19 Invoice E-Files على GitHub
نركز خصوصًا على النمسا، لكن جزءًا من الحل يهم أيضًا الشركات خارجها.
ثلاث وحدات للفواتير الإلكترونية
يتكون المشروع حاليًا من ثلاثة مكونات أساسية:
- ebInterface 6.1 للنمسا
- ZUGFeRD للفواتير الإلكترونية
- الإرسال التلقائي إلى e-Rechnung.gv.at
وهكذا نجمع متطلبات مختلفة للفوترة الإلكترونية في مشروع مفتوح المصدر مخصص لـ Odoo 19 Community.
ebInterface 6.1 – تنسيق الفواتير النمساوي
يمثل ebInterface 6.1 أحد محاور تطويرنا.
ebInterface هو التنسيق النمساوي القياسي للفواتير الإلكترونية المهيكلة.
وحدتنا
l10n_at_ebinterface
تُنشئ ملف ebInterface-6.1-XML مطابقًا انطلاقًا من فاتورة عميل أو إشعار دائن في Odoo.
وتُنقل المعلومات ذات الصلة من فاتورة Odoo إلى بنية XML، وتشمل على سبيل المثال:
- مُصدر الفاتورة
- مستلم الفاتورة
- بنود الفاتورة
- الضرائب
- معلومات الدفع
- بيانات الحساب المصرفي
- بيانات الفاتورة
ويُربط ملف XML المُنشأ مباشرة بالفاتورة.
لماذا طوّرنا وحدة خاصة لهذا الغرض؟
أثناء التطوير، تبيّن لنا أنه لا تتوفر حاليًا ضمن وحدات Odoo الأساسية أو وحدات OCA وحدة مناسبة لـ Odoo 19 Community تدعم المعيار النمساوي الأصلي ebInterface.
وهذه تحديدًا هي النقطة التي أردنا معالجتها.
بدلًا من تطوير حل خاص بالنمسا لتثبيت Odoo لدينا وحده، نفّذناه في صورة وحدة مستقلة مفتوحة المصدر.
وبذلك يمكن لبقية مجتمع Odoo الاستفادة منها أيضًا.
ZUGFeRD تلقائيًا مع كل فاتورة
المحور الثاني لمشروعنا هو ZUGFeRD.
يجمع ZUGFeRD بين فاتورة بصيغة PDF وفاتورة مهيكلة بصيغة XML.
والنتيجة ما يُسمى بالفاتورة الهجينة: تظل الفاتورة قابلة للقراءة بصيغة PDF، بينما تستطيع البرمجيات معالجة بيانات الفاتورة المهيكلة المضمّنة فيها تلقائيًا.
يتضمن Odoo 19 بالفعل دعمًا أساسيًا لتنسيقي ZUGFeRD وCII.
لكن توجد بعض القيود في الاستخدام العملي.
وحدتنا
account_invoice_zugferd_ebinterface_auto
تبدأ لذلك من هذه النقطة تحديدًا.
لم يعد ZUGFeRD مجرد خيار
أردنا أن تكون العملية مؤتمتة قدر الإمكان.
لذلك، عند إرسال فاتورة عميل، لا يُتحقق أولًا مما إذا كانت إعدادات ZUGFeRD قد ضُبطت لهذا العميل على حدة.
بل يُستخدم ZUGFeRD تلقائيًا لفواتير العملاء والإشعارات الدائنة.
ويُرفق أيضًا ملف ebInterface-XML المُنشأ بوصفه جزءًا من الفاتورة.
وبذلك تتشكل عملية متكاملة:
فاتورة Odoo → PDF → فاتورة إلكترونية مهيكلة → إرسال
دون أن يضطر المستخدم إلى تنفيذ خطوات إضافية لكل فاتورة.
نسد أيضًا ثغرات وظيفية في Odoo 19 Community
أثناء التطوير، واجهنا بعض الجوانب الخاصة في طريقة تنفيذ الوظائف في Odoo 19.
من بينها تبعيات في أداة التصدير بتنسيق CII قد تسبب مشكلات في التثبيتات غير المهيأة لبلدان محددة.
وتعالج وحدتنا عددًا من هذه القيود العملية.
وتشمل هذه القيود، من بين أمور أخرى:
- غياب حقول فترات الإيرادات المؤجلة
- تقييد التحويل إلى PDF/A-3 بحسب البلد
- غياب بيانات الحساب المصرفي أو عدم تعيينها في الفواتير الحالية
والهدف من ذلك إتاحة استخدام ZUGFeRD بموثوقية أيضًا لدى الشركات خارج مجموعات البلدان التي صُمم لدعمها أصلًا.
e-Rechnung.gv.at – إرسال مباشر إلى الحكومة النمساوية
يهم المكون الثالث خصوصًا الشركات التي تصدر فواتير لجهات متعاقدة من القطاع العام.
باستخدام
l10n_at_erechnung_gv_at
يمكن إرسال فاتورة بتنسيق ebInterface مباشرة إلى خدمة الويب النمساوية e-Rechnung.gv.at.
وبذلك تتحول عملية إنشاء الفاتورة وحدها إلى عملية فوترة إلكترونية مؤتمتة.
يمكن أن تسير العملية مثلًا على النحو التالي:
إنشاء فاتورة في Odoo
↓
إنشاء ملف XML بتنسيق ebInterface
↓
إرسال الفاتورة
↓
إرسال ebInterface تلقائيًا إلى e-Rechnung.gv.at
وهكذا تُدمج مباشرة في Odoo عملية كانت ستُنفّذ يدويًا لولا ذلك.
الإرسال التلقائي للعملاء الذين يحتاجون إليه فقط
لا يُفعّل الإرسال إلى e-Rechnung.gv.at لجميع العملاء بصورة شاملة.
بل يمكن تفعيله لكل عميل نمساوي على حدة.
ولهذا الغرض، تُحفظ البيانات المطلوبة، مثل
- رقم المورد
- مجموعة المشتريات / رقم الفرع
- مرجع الطلب
في سجل العميل.
وتتحقق الوحدة أيضًا من استيفاء متطلبات التفعيل.
التشغيل في بيئتي الاختبار والإنتاج
يمكن الاختيار بين بيئة الاختبار وبيئة الإنتاج لخدمة e-Rechnung.gv.at.
تُحفظ بيانات الوصول إلى خدمة الويب USP في إعدادات Odoo.
وبذلك يمكن إعداد التكامل أولًا في بيئة اختبار قبل استخدامه لإرسال الفواتير فعليًا.
الأتمتة بدلًا من العمل الإضافي
لم يكن هدفنا أثناء التطوير إضافة المزيد من الأزرار التي يتعين على المحاسب استخدامها.
بل على العكس.
الفكرة هي:
أقل قدر ممكن من العمل اليدوي.
تُنشأ فاتورة في Odoo.
تُنشأ التنسيقات المهيكلة المطلوبة تلقائيًا.
تُرفق الملفات المناسبة تلقائيًا عند الإرسال.
وبالنسبة إلى العملاء النمساويين الذين ضُبطت إعداداتهم لهذا الغرض، يمكن أيضًا إرسال الفاتورة تلقائيًا إلى e-Rechnung.gv.at.
هذه الأتمتة تحديدًا هي ما يميز حلًا متكاملًا للفوترة الإلكترونية عن مجرد تصدير ملف.
لا نتستر على مشكلات جودة البيانات
لكن ثمة نقطة مهمة أخرى في تنفيذنا:
جودة الفاتورة الإلكترونية مرهونة بجودة البيانات التي تُنشأ منها.
لذلك لا نحاول تعويض البيانات الإلزامية المفقودة بقيم اعتباطية دون تنبيه المستخدم.
فعندما تغيب معلومات إلزامية مطلوبة لتنسيق ZUGFeRD أو ebInterface مثلًا، ينبغي أن ينبه Odoo المستخدم إلى ذلك.
ومن أمثلة ذلك:
- عدم تحديد بلد العميل
- غياب المعلومات الضريبية في بنود الفاتورة
- غياب بيانات الحساب المصرفي
ونرى أن ذلك أفضل من إرسال فاتورة إلكترونية مستوفية للشكل المطلوب، لكن محتواها غير صحيح.
برمجيات مفتوحة المصدر لمجتمع Odoo
نتيح هذا المشروع أيضًا مجانًا وبشفرة مفتوحة المصدر.
لماذا؟
لأننا نحن أنفسنا نستفيد من البرمجيات مفتوحة المصدر.
يوفر Odoo Community أساسًا ممتازًا لتخطيط موارد المؤسسات والمحاسبة وعمليات الأعمال. وحين نفتقد وظيفة في عملنا اليومي، نطوّرها.
وإذا كان الحل مفيدًا لشركات أخرى أيضًا، فإننا نتيحه للمجتمع.
هذا هو التطبيق العملي لمفهوم المصدر المفتوح في نظرنا.
تركيز على النمسا – لكن الفائدة لا تقتصر عليها
يركز المشروع بوضوح على النمسا.
يهم كل من ebInterface وe-Rechnung.gv.at الشركات النمساوية على وجه الخصوص.
أما دعم ZUGFeRD فيهم أيضًا الشركات خارج النمسا.
لذلك لا يقتصر المشروع على كونه حلًا خاصًا بالنمسا.
وقد يكون الجمع بين بيانات الفاتورة المهيكلة ومستند PDF/A-3 المُنشأ تلقائيًا مفيدًا أيضًا لتثبيتات Odoo الأخرى.
من أجل Odoo 19 Community
طُوّرت الوحدات من أجل Odoo 19 Community.
يحتوي المستودع حاليًا على:
- l10n_at_ebinterface
- account_invoice_zugferd_ebinterface_auto
- l10n_at_erechnung_gv_at
توجد تبعيات بين الوحدات، بحيث يكفي تثبيت المكونات اللازمة فقط لكل حالة استخدام.
مساهمتنا في المجتمع
نرى هذا المشروع مساهمة في تطوير مجتمع Odoo، وليس برنامجًا تجاريًا مكتملًا.
قد يحتاج أحدهم إلى ebInterface فقط.
وقد تحتاج شركة أخرى إلى ZUGFeRD.
وقد تحتاج شركة إلى إرسال فواتير بانتظام إلى جهات متعاقدة من القطاع العام عبر e-Rechnung.gv.at.
يمكن لمشروعنا أن يوفر أساسًا مناسبًا في الحالات الثلاث جميعها.
وبما أن الشفرة المصدرية متاحة للجميع، يستطيع كل مستخدم فحص الحل وتعديله ومواصلة تطويره.
المصدر المفتوح يعني أن نتحسن معًا
نحن مقتنعون بأن المصدر المفتوح يوفر ميزة كبيرة، خاصة في أنظمة تخطيط موارد المؤسسات.
تختلف متطلبات الشركات.
فالحل الذي يعمل على نحو مثالي لدى شركة ما قد يحتاج إلى تعديل ليناسب شركة أخرى.
وهذا ما تتيحه الشفرة مفتوحة المصدر.
لذلك نرحب بما يلي:
- الملاحظات
- تقارير الأخطاء
- اقتراحات للتحسين
- طلبات دمج التغييرات
- حالات الاستخدام المدعومة الأخرى
لا يتبلور الحل الجيد الذي يخدم المجتمع بالضرورة منذ أول إيداع للشفرة.
إنه نتيجة لمزيد من التطوير من قبل العديد من المستخدمين والمطورين.
استخدام المشروع مجانًا
الشفرة المصدرية الكاملة متاحة للجميع على GitHub:
GitHub – ملفات الفواتير الإلكترونية لأودو 19
وتتوفر هناك أيضًا معلومات التثبيت ووثائق كل وحدة.
يتطلب التكامل مع خدمة الويب النمساوية e-Rechnung.gv.at أيضًا مكتبة Python المسماة Zeep.
مساهمتنا في عالم Odoo مفتوح
نود من خلال هذا المشروع أن نبيّن أن حتى الإضافات الصغيرة التي نطوّرها بأنفسنا يمكن أن تقدم قيمة للمجتمع بأكمله.
طوّرنا هذه الوحدات في الأصل لتلبية متطلبات محددة.
والآن نتيح هذه الحلول مجانًا لجميع مستخدمي Odoo 19 Community.
وهكذا يمكن أن يتحول تطوير مخصص إلى حل يخدم المجتمع.
Odoo 19. مفتوح المصدر. فواتير إلكترونية. النمسا. ومجانًا للمجتمع.
ولهذا تحديدًا نشرنا هذا المشروع.