الفواتير الإلكترونية جزء من المحاسبة الحديثة
تتواصل رقمنة المحاسبة. وصيغ الفواتير الإلكترونية لم تعد منذ زمن طويل مجرد ملف PDF يُرسل بالبريد الإلكتروني.
تحتوي الفاتورة الإلكترونية الحقيقية على بيانات منظّمة يمكن لأنظمة المحاسبة وأنظمة ERP معالجتها تلقائيًا.
ومن خلال مشروعنا الجديد مفتوح المصدر لـ 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
تُنشئ من فاتورة عميل أو إشعار دائن في Odoo ملف ebInterface-6.1-XML مقابلًا.
وفي أثناء ذلك تُنقل، من بين أمور أخرى، المعلومات ذات الصلة من فاتورة Odoo إلى بنية XML:
- مُصدر الفاتورة
- مستلم الفاتورة
- بنود الفاتورة
- الضرائب
- معلومات الدفع
- البيانات المصرفية
- بيانات الفاتورة
ويُربط ملف XML الذي تم إنشاؤه مباشرةً بالفاتورة.
لماذا طوّرنا وحدة خاصة لذلك؟
لاحظنا أثناء التطوير أنه لا توجد حاليًا لـ Odoo 19 Community وحدة مقابلة ضمن نواة Odoo أو ضمن وحدات OCA للمعيار النمساوي الأصلي ebInterface.
ومن هنا بالذات أردنا أن نبدأ.
وبدلاً من تطوير حل نمساوي لتركيبنا الخاص فقط، نفّذناه بوصفه وحدة مستقلة مفتوحة المصدر.
وبذلك يمكن لبقية مجتمع 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 قد تسبب مشكلات خارج تركيبات بلدان معينة.
وتعالج وحدتنا عدة قيود عملية من هذا النوع.
ومن ذلك، من بين أمور أخرى:
- حقول مفقودة لفترات الإيرادات المؤجلة (Deferred Revenue)
- القيد الخاص بالبلد على تحويل PDF/A-3
- بيانات مصرفية مفقودة أو غير معيّنة في الفواتير القائمة
وبذلك يُراد أن يصبح استخدام ZUGFeRD موثوقًا أيضًا للشركات خارج التركيبات القُطرية المقرَّرة في الأصل.
e-Rechnung.gv.at – الإرسال المباشر إلى الدولة النمساوية
المكوّن الثالث مهم بصفة خاصة للشركات التي تُصدر فواتير إلى جهات التعاقد العامة.
باستخدام
l10n_at_erechnung_gv_at
يمكن إرسال فاتورة ebInterface مباشرةً إلى خدمة الويب النمساوية e-Rechnung.gv.at.
وبذلك يتحول مجرد إنشاء الفواتير إلى عملية فوترة إلكترونية مؤتمتة.
ويمكن أن يكون سير العمل مثلًا على النحو التالي:
إنشاء الفاتورة في Odoo
↓
إنشاء ebInterface XML
↓
إرسال الفاتورة
↓
إرسال 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 أساسًا ممتازًا لأنظمة ERP والمحاسبة وعمليات الشركات. وعندما تنقصنا وظيفة في عملنا اليومي، فإننا نطوّرها.
وإذا كان الحل مفيدًا لشركات أخرى أيضًا، فإننا نضعه في متناول المجتمع.
هذا هو المصدر المفتوح كما نعيشه فعلًا.
تركيز نمساوي – لكن ليس للنمسا وحدها
للمشروع تركيز نمساوي واضح.
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.
وفي الحالات الثلاث جميعها يمكن لمشروعنا أن يوفّر أساسًا.
ولأن الشيفرة المصدرية متاحة للجميع، يستطيع كل مستخدم فحص الحل وتكييفه وتطويره.
المصدر المفتوح يعني: أن نتحسّن معًا
نحن مقتنعون بأن المصدر المفتوح يوفّر ميزة كبيرة، ولا سيما في أنظمة ERP.
للشركات متطلبات مختلفة.
قد يحتاج حل يعمل بصورة مثالية لدى شركة ما إلى تكييف لدى شركة أخرى.
ومع الشيفرة المصدرية المفتوحة يصبح ذلك ممكنًا.
ولذلك يسعدنا تلقي:
- الملاحظات
- بلاغات الأخطاء (Bug Reports)
- اقتراحات التحسين
- طلبات الدمج (Pull Requests)
- حالات استخدام إضافية مدعومة
الحل الجيد للمجتمع لا ينشأ بالضرورة مع أول Commit.
بل ينشأ من خلال التطوير المتواصل على يد كثير من المستخدمين والمطورين.
استخدام المشروع مجانًا
الشيفرة المصدرية كاملة متاحة للعموم على GitHub:
GitHub – Odoo 19 Invoice E-Files
وهناك أيضًا معلومات التثبيت ووثائق كل وحدة.
ولتكامل خدمة الويب النمساوية e-Rechnung.gv.at يلزم إضافةً إلى ذلك مكتبة Python المسماة Zeep.
مساهمتنا في عالم Odoo مفتوح
نريد بهذا المشروع أن نبيّن أن التطويرات الذاتية الأصغر حجمًا يمكن أن تخلق قيمة مضافة لمجتمع بأكمله.
طوّرنا الوحدات في الأصل لحل متطلبات محددة.
والآن نضع هذه الحلول مجانًا في متناول جميع مستخدمي Odoo 19 Community.
وبذلك يمكن أن يتحول تطوير فردي إلى حل للمجتمع.
Odoo 19. مصدر مفتوح. فواتير إلكترونية. النمسا. ومجانًا للمجتمع.
لهذا بالذات نشرنا هذا المشروع.