ক্রোয়েশিয়ার ২০২৬ সালের ই-ইনভয়েস নিয়ম PHP ডেভেলপারদের ভ্যালিডেশন পদ্ধতি নতুন করে তৈরি করতে বাধ্য করছে – ট্যাক্স অথরিটির Schematron ফাইলটি XSLT 2.0-এর ওপর নির্ভরশীল, অথচ প্রচলিত PHP XSLT ইঞ্জিন শুধুমাত্র XSLT 1.0 সমর্থন করে। এর ফলে: বেশিরভাগ অ্যাকাউন্টিং অ্যাপ কোনো বিকল্প ব্যবস্থা (workaround) ছাড়া ৬২টি বাধ্যতামূলক বিজনেস-রুল চেক করতে পারে না, এবং একটি রিজেক্টেড ইনভয়েস B2B ক্যাশ ফ্লো বন্ধ করে দিতে পারে।

কেন এই প্রযুক্তিগত বাধাটি গুরুত্বপূর্ণ

২০২৬ সালের ১ জানুয়ারি থেকে ক্রোয়েশিয়ায় প্রতিটি B2B লেনদেন একটি e-Račun হিসেবে বিনিময় করতে হবে যা ৬২টি নির্দিষ্ট ভ্যালিডেশন রুল মেনে চলে। ট্যাক্স অ্যাডমিনিস্ট্রেশন এই নিয়মগুলো একটি 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 ৬২টি Schematron অ্যাসারশনকে নেটিভ PHP কোডে রূপান্তর করুন। এতে শুরুতে অনেক পরিশ্রম প্রয়োজন, তবে একবার কোড হয়ে গেলে ভ্যালিডেটরটি লোকালি চলে, যেকোনো PHP স্ট্যাকের সাথে সহজেই ইন্টিগ্রেট হয় এবং বাহ্যিক নির্ভরতা দূর করে।

লুকানো লজিক যা সাধারণ ইমপ্লিমেন্টেশনকে ভুল পথে চালিত করে

Schematron-এর একটি সাধারণ বা সরল অনুবাদ (naïve translation) সূক্ষ্ম অর্থগত পার্থক্যগুলো (subtle semantics) মিস করতে পারে। উদাহরণস্বরূপ, রুল HR-BR-4 দেখুন: “যদি প্রদেয় পরিমাণ শূন্যের বেশি হয়, তবে একটি ডিউ ডেট থাকতে হবে।” Schematron এমন একটি ভেরিয়েবল সংজ্ঞায়িত করে যা ক্রেডিট নোটের ক্ষেত্রে ইনভয়েস অ্যামাউন্টকে –১ দিয়ে গুণ করে। র (raw) XML-এ একটি ক্রেডিট নোট পজিটিভ অ্যামাউন্ট দেখায়, কিন্তু ভেরিয়েবলটি এটিকে নেগেটিভ করে দেয়, ফলে “শূন্যের বেশি” শর্তটি মিথ্যা হয়ে যায়। যদি ভ্যালিডেটর শুধুমাত্র অ্যাসারশন টেক্সট পড়ে, তবে এটি প্রতিটি ক্রেডিট নোট রিজেক্ট করে দেবে।

শিক্ষাটি স্পষ্ট: সংশ্লিষ্ট PHP কন্ডিশন কোড করার আগে Schematron-এ থাকা ভেরিয়েবল ডেফিনিশনগুলো পড়ুন। একই প্যাটার্ন আরও বেশ কিছু নিয়মে দেখা যায় যেখানে অ্যারিথমেটিক বা স্ট্রিং ম্যানিপুলেশন একটি $ ভেরিয়েবলের আড়ালে থাকে।

সাধারণ রিজেকশন ট্রিগারসমূহ

সঠিকভাবে কোড করা নিয়ম থাকা সত্ত্বেও, ডেভেলপাররা প্রায়শই ইনভয়েসের এমন কিছু এলিমেন্ট উপেক্ষা করেন যেগুলোকে ট্যাক্স সিস্টেম মারাত্মক ত্রুটি (fatal error) হিসেবে গণ্য করে:

  • অপারেটরের তথ্যের অভাব – প্রতিটি ইনভয়েসে অপারেটরের পুরো নাম এবং OIB (ক্রোয়েশিয়ান পার্সোনাল আইডেন্টিফিকেশন নম্বর) থাকতে হবে। যেকোনো একটি ফিল্ড খালি রাখলে তা তাৎক্ষণিক রিজেক্ট হবে।
  • খালি XML ট্যাগ – <cbc:Note></cbc:Note> এর মতো ট্যাগগুলো ভ্যালিডেটরকে ক্র্যাশ করাতে পারে। খালি এলিমেন্টগুলো বাদ দেওয়া বা সেগুলোতে একটি প্লেসহোল্ডার স্ট্রিং ব্যবহার করলে এই সমস্যার সমাধান হয়।
  • ভুল KPD কোড – Klasifikacija proizvoda i usluga (KPD) কোডটি কমপক্ষে ছয় ডিজিটের হতে হবে। ছোট কোডগুলোকে ত্রুটিপূর্ণ (malformed) হিসেবে চিহ্নিত করা হয়।
  • অকার্যকর তারিখ – অন্য সব কিছু সঠিক থাকলেও, ১ জানুয়ারি ২০২৬-এর আগের তারিখের যেকোনো ইনভয়েস বাধ্যতামূলক-তারিখ (mandatory-date) নিয়মে ব্যর্থ হবে।

টেস্টিংয়ের ফাঁদ

ট্যাক্স অ্যাডমিনিস্ট্রেশন ডেভেলপারদের জন্য নমুনা e-Račun ফাইল প্রকাশ করে। সেই উদাহরণগুলোতে এখনও ২০২৫ সালের তারিখ এবং OIB রয়েছে যা ২০২৬ সালের নিয়মাবলী মেনে চলে না। সেগুলোকে একমাত্র নির্ভরযোগ্য উৎস হিসেবে ব্যবহার করলে কমপ্লায়েন্স বা নিয়ম মেনে চলার বিষয়ে একটি ভুল ধারণা তৈরি হতে পারে। অফিসিয়াল নমুনাগুলোকে শুধুমাত্র পার্সার স্যানিটি চেক (parser sanity check) হিসেবে ব্যবহার করুন, তারপর আপনার অ্যাপ্লিকেশন দ্বারা তৈরি বাস্তবসম্মত ডেটার বিপরীতে আপনার নিজস্ব রুল-এনফোর্সমেন্ট স্যুট (rule-enforcement suite) চালান।

পিএইচপি-নির্ভর সমাধান যা ইতিমধ্যে বাজারে রয়েছে

একজন ডেভেলপার রিমপ্লিমেন্টেশন পদ্ধতিটি সম্পূর্ণভাবে গ্রহণ করেছেন এবং সমস্ত ৬২টি ভ্যালিডেশন রুলকে Laravel প্রজেক্টের জন্য একটি Composer-ইনস্টলেবল লাইব্রেরি হিসেবে প্যাকেজ করেছেন। এই লাইব্রেরিটি অ্যারিথমেটিক, ভেরিয়েবল স্কোপিং এবং এজ-কেস চেকগুলো পরিচালনা করে যা Schematron-এর আড়ালে থাকে, ফলে ইনভয়েসগুলো সম্পূর্ণভাবে PHP রানটাইমের মধ্যেই ভ্যালিডেট করা সম্ভব হয়। XSLT 2.0 এবং এক্সটার্নাল কলগুলো বাদ দিয়ে, এই প্যাকেজটি কমপ্লায়েন্সের জন্য একটি ডিটারমিনিস্টিক (deterministic) এবং লো-ল্যাটেন্সি পথ প্রদান করে।

সোর্স কোড এবং ব্যবহারের নির্দেশিকা লেখকের পাবলিক রিপোজিটরিতে পাওয়া যাচ্ছে (লিঙ্কটি মূল পোস্টে দেওয়া হয়েছে)।

পরবর্তীতে যা খেয়াল রাখতে হবে

  • কমিউনিটি-চালিত PHP ভ্যালিডেটর – যেহেতু আরও বেশি ডেভেলপাররা পুনরায় বাস্তবায়ন (re-implementation) পদ্ধতি গ্রহণ করছেন, তাই এমন ফোর্ক (forks) এবং এক্সটেনশন (extensions) আসার সম্ভাবনা রয়েছে যা ইউনিট-টেস্ট ফিক্সচার (unit-test fixtures), অন্যান্য ফ্রেমওয়ার্কের সাপোর্ট বা পারফরম্যান্সের উন্নতির জন্য টিউইক (tweaks) যোগ করবে।

সারকথা

ক্রোয়েশিয়ার ২০২৬ সালের ই-ইনভয়েস ম্যান্ডেট PHP ডেভেলপারদের একটি আধুনিক XSLT 2.0 Schematron এবং এই ভাষার লিগ্যাসি (legacy) XSLT 1.0 ইঞ্জিনের মধ্যে বিদ্যমান অসামঞ্জস্যের মুখোমুখি হতে বাধ্য করছে। ৬২টি বিজনেস রুলসকে নেটিভ PHP-তে রূপান্তর করা, হিডেন ভেরিয়েবল লজিক পর্যবেক্ষণ করা এবং সাধারণ XML ত্রুটিগুলো এড়িয়ে চলা ইনভয়েসিং প্রক্রিয়াকে ইন-হাউস রাখতে সাহায্য করে, নেটওয়ার্ক সংক্রান্ত ব্যর্থতা এড়িয়ে যায় এবং ডেডলাইন আসার সাথে সাথে অ্যাকাউন্টিং সফটওয়্যারকে একটি মসৃণ ও কমপ্লায়েন্ট রোলআউটের জন্য প্রস্তুত করে।