کرواتیا کا 2026 کا ای-انوائس (e-invoice) قانون PHP ڈویلپرز کو ویلیڈیشن کے نئے طریقے تلاش کرنے پر مجبور کر رہا ہے – ٹیکس اتھارٹی کی Schematron فائل XSLT 2.0 پر انحصار کرتی ہے، جبکہ غالب PHP XSLT انجن صرف XSLT 1.0 کو سپورٹ کرتا ہے۔ نتیجہ یہ ہے کہ زیادہ تر اکاؤنٹنگ ایپس کسی متبادل طریقے کے بغیر 62 لازمی کاروباری اصولوں کی جانچ نہیں کر سکتیں، اور ایک مسترد شدہ انوائس B2B کیش فلو کو روک سکتی ہے۔
تکنیکی رکاوٹ کیوں اہم ہے
1 جنوری 2026 سے کرواٹیا میں ہر B2B لین دین ایک e-Račun کے طور پر ہونا چاہیے جو 62 مخصوص ویلیڈیشن قوانین کے مطابق ہو۔ ٹیکس ایڈمنسٹریشن ان قوانین کو Schematron فائل کی صورت میں شائع کرتی ہے – جو بنیادی طور پر ایک XSLT 2.0 اسٹائل شیٹ ہے جو خلاف ورزیوں کی نشاندہی کرتی ہے۔ PHP کی بلٹ ان libxslt لائبریری، جو مشہور xsltproc اور زیادہ تر Composer پیکیجز کو چلاتی ہے، صرف XSLT 1.0 کو نافذ کرتی ہے۔ XSLT 2.0 کی سپورٹ کے بغیر Schematron کو لاگو نہیں کیا جا سکتا، جس کا مطلب ہے کہ PHP پر مبنی انوائسنگ سسٹم یا تو ایسی انوائسز تیار کرے گا جنہیں ٹیکس پورٹل مسترد کر دے گا یا اسے کسی دوسری زبان یا سروس کا سہارا لینا پڑے گا۔
تین راستے جو ڈویلپرز اختیار کر سکتے ہیں
| آپشن | اس میں کیا شامل ہے | عملی نقصانات |
|---|---|---|
| SaxonC PECL extension | Saxon-C پروسیسر کو ایک نیٹیو PHP ایکسٹینشن کے طور پر انسٹال کریں، پھر براہ راست Schematron کو کال کریں۔ | یہ ایکسٹینشن عام Composer ورک فلو کا حصہ نہیں ہے؛ مختلف سرورز پر نیٹیو بائنریز بنانا اور تعینات کرنا پیچیدگیوں کا باعث بنتا ہے۔ |
| External validation service | XML کو ایک ویب سروس پر بھیجیں جو آپ کی طرف سے Schematron چلاتی ہے۔ | اب ہر انوائس نیٹ ورک لیٹنسی اور سروس کی دستیابی پر منحصر ہے؛ عارضی تعطل انوائسنگ کو مکمل طور پر روک سکتا ہے۔ |
| Re-implement the rules in PHP | 62 Schematron دعووں (assertions) کو نیٹیو PHP کوڈ میں تبدیل کریں۔ | اس کے لیے ابتدائی محنت درکار ہے، لیکن ایک بار کوڈنگ ہو جانے کے بعد ویلیڈیٹر مقامی طور پر چلتا ہے، کسی بھی PHP اسٹیک کے ساتھ آسانی سے جڑ جاتا ہے، اور بیرونی انحصار کو ختم کر دیتا ہے۔ |
وہ پوشیدہ منطق جو سادہ implementations کو مشکل میں ڈال دیتی ہے
Schematron کا سادہ سا ترجمہ اب بھی باریک معنی و مفہوم (semantics) کو نظر انداز کر سکتا ہے۔ مثال کے طور پر اصول HR-BR-4 لیں: "اگر واجب الادا رقم صفر سے زیادہ ہے تو ادائیگی کی تاریخ (due date) کا ہونا ضروری ہے۔" Schematron ایک ایسا متغیر (variable) متعین کرتا ہے جو کریڈٹ نوٹس کے لیے انوائس کی رقم کو –1 سے ضرب دیتا ہے۔ خام XML میں، کریڈٹ نوٹ ایک مثبت رقم دکھاتا ہے، لیکن متغیر اسے منفی کر دیتا ہے، اس لیے "صفر سے زیادہ" کی شرط غلط ہو جاتی ہے۔ اگر ویلیڈیٹر صرف دعوے (assertion) کے متن کو پڑھتا ہے، تو وہ ہر کریڈٹ نوٹ کو مسترد کر دے گا۔
سبق واضح ہے: متعلقہ PHP شرط کوڈ کرنے سے پہلے Schematron میں متغیر کی تعریفیں (variable definitions) پڑھیں۔ یہی پیٹرن کئی دوسرے اصولوں میں بھی نظر آتا ہے جہاں حساب کتاب یا اسٹرنگ مینیپولیشن ایک $ متغیر کے پیچھے چھپی ہوتی ہے۔
مسترد ہونے کی عام وجوہات
درست طریقے سے کوڈ کیے گئے اصولوں کے باوجود، ڈویلپرز اکثر انوائس کے ان عناصر کو نظر انداز کر دیتے ہیں جنہیں ٹیکس سسٹم سنگین غلطیوں (fatal errors) کے طور پر لیتا ہے:
- آپریٹر کی تفصیلات کا نہ ہونا – ہر انوائس میں آپریٹر کا پورا نام اور OIB (کروایتی ذاتی شناختی نمبر) ہونا ضروری ہے۔ کسی بھی فیلڈ کو خالی چھوڑنے سے فوری طور پر مسترد کر دیا جاتا ہے۔
- خالی XML ٹیگز –
<cbc:Note></cbc:Note>جیسے ٹیگز ویلیڈیٹر کو کریش کر دیتے ہیں۔ خالی عناصر کو ہٹانا یا انہیں کسی پلیس ہولڈر اسٹرنگ سے بھرنا اس مسئلے کو حل کر دیتا ہے۔ - غلط KPD کوڈز – Klasifikacija proizvoda i usluga (KPD) کوڈ کم از کم چھ ہندسوں کا ہونا چاہیے۔ چھوٹے کوڈز کو غلط (malformed) قرار دے کر نشان زد کر دیا جاتا ہے۔
- غلط تاریخیں – 1 جنوری 2026 سے پہلے کی تاریخ والی کوئی بھی انوائس، دیگر درستگی کے باوجود، لازمی تاریخ کے اصول پر ناکام ہو جائے گی۔
ٹیسٹنگ کے خطرات
ٹیکس ایڈمنسٹریشن ڈویلپرز کے لیے نمونے کے طور پر e-Račun فائلیں شائع کرتی ہے۔ ان مثالوں میں اب بھی 2025 کی تاریخیں اور OIBs شامل ہیں جو 2026 کے قواعد کے مطابق نہیں ہیں۔ انہیں حقیقت کا واحد ذریعہ سمجھنا تعمیل (compliance) کا غلط احساس دلاتا ہے۔ سرکاری نمونوں کو صرف پارسر کی جانچ (sanity check) کے طور پر لیں، پھر اپنی ایپلی کیشن سے تیار کردہ حقیقت پسندانہ ڈیٹا کے خلاف اپنا رول انفورسمنٹ سویٹ (rule-enforcement suite) چلائیں۔
صرف PHP کا حل جو پہلے سے دستیاب ہے
ایک ڈویلپر نے دوبارہ نافذ کرنے (re-implementation) کے راستے کو مکمل طور پر اپنایا، اور تمام 62 ویلیڈیشن قوانین کو Laravel پروجیکٹس کے لیے ایک Composer-installable لائبریری کے طور پر پیک کیا۔ یہ لائبریری حساب کتاب، ویری ایبل اسکوپنگ، اور ان مخصوص حالات (edge-case) کی جانچ سنبھالتی ہے جو Schematron میں چھپے ہوتے ہیں، جس سے انوائسز کو مکمل طور پر PHP رن ٹائم کے اندر ویلیڈیٹ کیا جا سکتا ہے۔ XSLT 2.0 اور بیرونی کالز کو ختم کر کے، یہ پیکیج تعمیل کا ایک یقینی اور کم لیٹنسی والا راستہ فراہم کرتا ہے۔
سورس کوڈ اور استعمال کی گائیڈ مصنف کی پبلک ریپوزٹری (لنک اصل پوسٹ میں فراہم کیا گیا ہے) پر دستیاب ہے۔
آگے کیا دیکھنا ہے
- کمیونٹی کے زیرِ اثر PHP validators – جیسے جیسے زیادہ ڈویلپرز re-implementation کے طریقہ کار کو اپنائیں گے، تو ایسی forks اور extensions کی توقع رکھیں جو unit-test fixtures، دیگر frameworks کے لیے سپورٹ، یا performance tweaks فراہم کریں۔
خلاصہ
کروشیا کا 2026 کا e-invoice mandate PHP ڈویلپرز کو ایک جدید XSLT 2.0 Schematron اور زبان کے legacy XSLT 1.0 engine کے درمیان عدم مطابقت کا سامنا کرنے پر مجبور کرتا ہے۔ 62 business rules کو native PHP میں منتقل کرنا، hidden variable logic پر نظر رکھنا، اور XML کی عام غلطیوں سے بچنا، invoicing کو in-house رکھتا ہے، network-related failures سے بچاتا ہے، اور ڈیڈ لائن آنے پر accounting software کو ایک ہموار اور compliant rollout کے لیے تیار کرتا ہے۔