قاعدة الفواتير الإلكترونية في كرواتيا لعام 2026 تُجبر مطوري PHP على إعادة ابتكار عملية التحقق – يعتمد ملف Schematron الخاص بهيئة الضرائب على XSLT 2.0، بينما لا يدعم محرك XSLT السائد في PHP سوى إصدار XSLT 1.0. والنتيجة: معظم تطبيقات المحاسبة لا يمكنها تشغيل الـ 62 فحصاً إلزامياً لقواعد العمل دون حل بديل، كما أن رفض فاتورة واحدة قد يؤدي إلى توقف التدفق النقدي بين الشركات (B2B).

لماذا تهم هذه العقبة التقنية

بدءاً من 1 يناير 2026، يجب تبادل كل معاملة B2B في كرواتيا كفاتورة e-Račun تتوافق مع 62 قاعدة تحقق محددة. تنشر إدارة الضرائب هذه القواعد في ملف Schematron – وهو في الأساس ورقة أنماط (stylesheet) من نوع XSLT 2.0 تقوم برصد المخالفات. إن مكتبة libxslt المدمجة في PHP، والتي تشغل أداة xsltproc الشهيرة ومعظم حزم Composer، لا تدعم سوى XSLT 1.0. وبدون دعم XSLT 2.0، لا يمكن تطبيق ملف Schematron، مما يعني أن نظام الفوترة القائم على PHP سيقوم إما بإنتاج فواتير ترفضها البوابة الضريبية، أو سيضطر للاستعانة بلغة برمجة أخرى أو خدمة خارجية.

ثلاثة مسارات يمكن للمطورين اتخاذها

الخيار ما يتضمنه العيوب العملية
إضافة SaxonC PECL تثبيت معالج Saxon-C كإضافة PHP أصلية، ثم استدعاء Schematron مباشرة. الإضافة ليست جزءاً من سير عمل Composer المعتاد؛ كما أن بناء ونشر الملفات الثنائية (binaries) الأصلية عبر خوادم مختلفة يزيد من التعقيد.
خدمة تحقق خارجية إرسال ملف XML إلى خدمة ويب تقوم بتشغيل Schematron نيابة عنك. تعتمد كل فاتورة الآن على زمن استجابة الشبكة وتوفر الخدمة؛ وأي انقطاع مؤقت قد يعطل عملية الفوترة بالكامل.
إعادة تنفيذ القواعد باستخدام PHP ترجمة تأكيدات Schematron الـ 62 إلى كود PHP أصلي. يتطلب جهداً مسبقاً، ولكن بمجرد كتابة الكود، يعمل برنامج التحقق محلياً، ويتكامل بسلاسة مع أي بيئة عمل PHP، ويلغي التبعيات الخارجية.

المنطق الخفي الذي يربك التنفيذات البسيطة

قد تفتقر الترجمة السطحية لملف Schematron إلى الدلالات الدقيقة. لنأخذ القاعدة HR-BR-4: "يجب وجود تاريخ استحقاق إذا كان المبلغ المستحق أكبر من صفر". يقوم Schematron بتعريف متغير يضرب مبلغ الفاتورة في -1 بالنسبة لإشعارات الدائن (credit notes). في ملف XML الخام، يظهر إشعار الدائن بمبلغ موجب، لكن المتغير يقلبه إلى سالب، وبالتالي تصبح حالة "أكبر من صفر" خاطئة. إذا كان برنامج التحقق يقرأ نص التأكيد فقط، فسيقوم برفض كل إشعار دائن.

الدرس واضح: اقرأ تعريفات المتغيرات في Schematron قبل برمجة شرط PHP المقابل. يظهر النمط نفسه في عدة قواعد أخرى حيث تختبئ العمليات الحسابية أو معالجة النصوص خلف متغير يبدأ بـ $.

مسببات الرفض الشائعة

حتى مع كتابة القواعد بشكل صحيح، غالباً ما يتجاهل المطورون عناصر في الفاتورة تعاملها المنظومة الضريبية كأخطاء فادحة:

  • نقص تفاصيل المشغل – يجب أن تحتوي كل فاتورة على الاسم الكامل للمشغل ورقم OIB (رقم التعريف الشخصي الكرواتي). ترك أي من الحقلين فارغاً يؤدي إلى الرفض الفوري.
  • علامات XML فارغة – تسبب علامات مثل <cbc:Note></cbc:Note> تعطل برنامج التحقق. حل هذه المشكلة يكمن في إزالة العناصر الفارغة أو ملئها بنص مؤقت.
  • أكواد KPD غير صحيحة – يجب أن يتكون كود تصنيف المنتجات والخدمات (KPD) من ستة أرقام على الأقل. يتم وسم الأكواد القصيرة بأنها غير صالحة.
  • تواريخ غير صالحة – أي فاتورة مؤرخة قبل 1 يناير 2026 ستفشل في اجتياز قاعدة التاريخ الإلزامي، بغض النظر عن صحة العناصر الأخرى.

عثرات الاختبار

تنشر إدارة الضرائب ملفات e-Račun نموذجية للمطورين. ومع ذلك، لا تزال هذه الأمثلة تحتوي على تواريخ من عام 2025 وأرقام OIB لا تجتاز مجموعة قواعد عام 2026. استخدام هذه الأمثلة كمصدر وحيد للحقيقة يعطي شعوراً زائفاً بالامتثال. تعامل مع العينات الرسمية كمجرد اختبار لسلامة المحلل (parser sanity check)، ثم قم بتشغيل مجموعة اختبارات فرض القواعد الخاصة بك مقابل بيانات واقعية يتم إنشاؤها بواسطة تطبيقك.

الحل المعتمد على PHP فقط والمتاح بالفعل

سلك أحد المطورين طريق إعادة التنفيذ حتى النهاية، حيث قام بتغليف جميع قواعد التحقق الـ 62 في مكتبة قابلة للتثبيت عبر Composer لمشاريع Laravel. تتعامل المكتبة مع العمليات الحسابية، ونطاق المتغيرات، وفحوصات الحالات الاستثنائية التي يخفيها Schematron، مما يسمح بالتحقق من صحة الفواتير بالكامل داخل بيئة تشغيل PHP. ومن خلال الاستغناء عن XSLT 2.0 والطلبات الخارجية، توفر هذه الحزمة مساراً حتمياً ومنخفض التأخير لتحقيق الامتثال.

الكود المصدري ودليل الاستخدام متاحان في المستودع العام للمؤلف (الرابط موجود في المنشور الأصلي).

ما يجب مراقبته لاحقاً

  • أدوات التحقق من صحة PHP المدفوعة بالمجتمع – مع اعتماد المزيد من المطورين لنهج إعادة التنفيذ، توقع ظهور نسخ مشتقة (forks) وإضافات تضيف أدوات اختبار الوحدات (unit-test fixtures)، أو تدعم أطر عمل أخرى، أو تقدم تحسينات في الأداء.

الخلاصة

يجبر تفويض الفواتير الإلكترونية في كرواتيا لعام 2026 مطوري PHP على مواجهة عدم توافق بين Schematron الحديث بمعيار XSLT 2.0 ومحرك XSLT 1.0 القديم الخاص باللغة. إن ترجمة قواعد العمل الـ 62 إلى لغة PHP الأصلية، ومراقبة منطق المتغيرات المخفية، وتجنب عثرات XML الشائعة، يضمن بقاء عملية الفوترة داخل المؤسسة، ويتجنب الإخفاقات المتعلقة بالشبكة، ويهيئ برامج المحاسبة لإطلاق سلس ومتوافق مع المعايير عند حلول الموعد النهائي.