குரோஷியாவின் 2026 மின்னணு விலைப்பட்டியல் (e-invoice) விதிமுறை PHP டெவலப்பர்களை சரிபார்ப்பு முறையை மீண்டும் உருவாக்கத் தூண்டுகிறது – வரி அதிகாரத்தின் Schematron கோப்பு XSLT 2.0-ஐச் சார்ந்துள்ளது, ஆனால் ஆதிக்கம் செலுத்தும் PHP XSLT என்ஜின் XSLT 1.0-ஐ மட்டுமே ஆதரிக்கிறது. இதன் விளைவாக: பெரும்பாலான கணக்கியல் செயலிகளால் (accounting apps) ஒரு மாற்று வழிமுறை இல்லாமல் 62 கட்டாய வணிக-விதி சரிபார்ப்புகளைச் செய்ய முடியாது, மேலும் நிராகரிக்கப்பட்ட ஒரு விலைப்பட்டியல் B2B பணப்புழக்கத்தை முடக்கக்கூடும்.
இந்தத் தொழில்நுட்பத் தடை ஏன் முக்கியமானது
1 ஜனவரி 2026 முதல் குரோஷியாவில் நடைபெறும் ஒவ்வொரு B2B பரிவர்த்தனையும் 62 குறிப்பிட்ட சரிபார்ப்பு விதிகளுக்கு இணங்கமான e-Račun ஆகப் பரிமாறப்பட வேண்டும். வரி நிர்வாகம் அந்த விதிகளையும் ஒரு Schematron கோப்பாக வெளியிடுகிறது – இது அடிப்படையில் விதிமீறல்களைக் கண்டறியும் ஒரு XSLT 2.0 ஸ்டைல்ஷீட் (stylesheet) ஆகும். பிரபலமான xsltproc மற்றும் பெரும்பாலான Composer தொகுப்புகளுக்குத் தேவையான PHP-இன் உள்ளமைக்கப்பட்ட libxslt நூலகம், XSLT 1.0-ஐ மட்டுமே செயல்படுத்துகிறது. XSLT 2.0 ஆதரவு இல்லாமல் Schematron-ஐப் பயன்படுத்த முடியாது, அதாவது PHP-அடிப்படையிலான விலைப்பட்டியல் அமைப்பு வரி இணையதளத்தால் நிராகரிக்கப்படும் விலைப்பட்டியல்களை உருவாக்கும் அல்லது மற்றொரு மொழி அல்லது சேவையை அழைக்க வேண்டியிருக்கும்.
டெவலப்பர்கள் மேற்கொள்ளக்கூடிய மூன்று வழிகள்
| விருப்பம் | இதில் என்ன அடங்கும் | நடைமுறைத் தீமைகள் |
|---|---|---|
| SaxonC PECL extension | Saxon-C ப்ராசஸரை ஒரு நேட்டிவ் PHP extension ஆக நிறுவி, பின்னர் Schematron-ஐ நேரடியாக அழைக்கலாம். | இந்த extension வழக்கமான Composer பணிப்பாய்வின் (workflow) ஒரு பகுதியல்ல; வெவ்வேறு சர்வர்களில் நேட்டிவ் பைனரிகளை (native binaries) உருவாக்குவதும் பயன்படுத்துவதும் சிக்கலைத் தரும். |
| External validation service | உங்கள் சார்பாக Schematron-ஐ இயக்கும் ஒரு வெப்-சேவைக்கு XML-ஐ அனுப்பலாம். | ஒவ்வொரு விலைப்பட்டியலும் இப்போது நெட்வொர்க் தாமதம் மற்றும் சேவையின் கிடைப்படைமையைச் சார்ந்து இருக்கும்; தற்காலிகத் தடை விலைப்பட்டியல் முறையை முழுமையாக முடக்கக்கூடும். |
| Re-implement the rules in PHP | 62 Schematron உறுதிப்பாடுகளை (assertions) நேட்டிவ் PHP குறியீடாக மாற்றலாம். | இதற்கு ஆரம்பத்தில் அதிக முயற்சி தேவைப்படும், ஆனால் ஒருமுறை குறியீடாக்கப்பட்டதும், சரிபார்ப்பி (validator) உள்ளூரிலேயே இயங்கும், எந்தவொரு PHP ஸ்டேக் உடன் எளிதாக ஒருங்கிணைக்கப்படும் மற்றும் வெளிப்புறத் தேவைகளைத் தவிர்க்கும். |
எளிய செயலாக்கங்களைச் சிக்கலில் தள்ளும் மறைமுகத் தர்க்கம்
Schematron-ஐ ஒரு சாதாரண முறையில் மொழிபெயர்த்தால் கூட நுணுக்கமான அர்த்தங்களை (semantics) தவறவிடக்கூடும். விதி HR-BR-4-ஐ எடுத்துக் கொள்வோம்: "செலுத்த வேண்டிய தொகை பூஜ்ஜியத்தை விட அதிகமாக இருந்தால், ஒரு உரிய தேதி (due date) இருக்க வேண்டும்." கிரெடிட் நோட்டுகளுக்காக (credit notes) விலைப்பட்டியல் தொகையை -1 ஆல் பெருக்குவதற்கு Schematron ஒரு மாறியை (variable) வரையறுக்கிறது. மூல XML-இல் ஒரு கிரெடிட் நோட் நேர்மறைத் தொகையைக் காட்டுகிறது, ஆனால் அந்த மாறி அதை எதிர்மறையாக மாற்றுகிறது, எனவே "பூஜ்ஜியத்தை விட அதிகம்" என்ற நிபந்தனை தவறாகிறது. சரிபார்ப்பி (validator) உறுதிப்பாட்டு உரையை (assertion text) மட்டும் படித்தால், அது ஒவ்வொரு கிரெடிட் நோட்டையும் நிராகரிக்கும்.
பாடம் தெளிவானது: அதற்குரிய PHP நிபந்தனையை குறியீடாக்குவதற்கு முன், Schematron-இல் உள்ள மாறி வரையறைகளை (variable definitions) வாசிக்கவும். கணித அல்லது சரக் கையாளுதல் (string manipulation) ஒரு $ மாறியின் பின்னால் மறைந்திருக்கும் பல இதர விதிகளிலும் இதே போன்ற முறை காணப்படுகிறது.
பொதுவான நிராகரிப்பு காரணங்கள்
சரியாக குறியீடாக்கப்பட்ட விதிகளுடன் கூட, வரி அமைப்பு முக்கியமான பிழைகளாகக் கருதும் விலைப்பட்டியல் கூறுகளை டெவலப்பர்கள் பெரும்பாலும் கவனிக்கத் தவறிவிடுகிறார்கள்:
- இயக்குநரின் விவரங்கள் விடுபடுதல் – ஒவ்வொரு விலைப்பட்டியலிலும் இயக்குநரின் முழு பெயர் மற்றும் OIB (குரோஷிய தனிநபர் அடையாள எண்) இருக்க வேண்டும். ஏதேனும் ஒரு புலத்தை (field) காலியாக விட்டால் அது உடனடியாக நிராகரிக்கப்படும்.
- காலியான XML டேக்-கள் –
<cbc:Note></cbc:Note>போன்ற டேக்-கள் சரிபார்ப்பியை முடக்கிவிடும் (crash). காலியான கூறுகளை நீக்குவது அல்லது அவற்றுடன் ஒரு பிளேஸ்ஹோல்டர் (placeholder) சரத்தை நிரப்புவது இந்தப் பிரச்சனையைத் தீர்க்கும். - தவறான KPD குறியீடுகள் – Klasifikacija proizvoda i usluga (KPD) குறியீடு குறைந்தது ஆறு இலக்கங்களைக் கொண்டிருக்க வேண்டும். குறுகிய குறியீடுகள் தவறானவை எனக் குறிக்கப்படும்.
- தவறான தேதிகள் – மற்றவை சரியாக இருந்தாலும், 1 ஜனவரி 2026-க்கு முந்தைய தேதியைக் கொண்ட எந்தவொரு விலைப்பட்டியலும் கட்டாயத் தேதி விதியைப் பூர்த்தி செய்யாது.
சோதனைச் சிக்கல்கள் (Testing pitfalls)
வரி நிர்வாகம் டெவலப்பர்களுக்காக மாதிரி e-Račun கோப்புகளை வெளியிடுகிறது. அந்த உதாரணங்களில் இன்னும் 2025 தேதிகள் மற்றும் 2026 விதித் தொகுப்பிற்குப் பொருந்தாத OIB-கள் உள்ளன. அவற்றை மட்டுமே உண்மையான ஆதாரமாகக் கொள்வது தவறான இணக்க உணர்வைத் தரும். அதிகாரப்பூர்வ மாதிரிகளை ஒரு பார்ஸர் (parser) சரிபார்ப்பாக மட்டும் கருதுங்கள், பின்னர் உங்கள் பயன்பாட்டால் உருவாக்கப்பட்ட யதார்த்தமான தரவுகளைக் கொண்டு உங்கள் சொந்த விதி-அமலாக்கத் தொகுப்பை (rule-enforcement suite) இயக்கவும்.
ஏற்கனவே பயன்பாட்டில் உள்ள PHP-மட்டும் சார்ந்த தீர்வு
ஒரு டெவலப்பர் விதிகளையே மீண்டும் செயல்படுத்துதல் என்ற வழியை முழுமையாகப் பின்பற்றி, 62 சரிபார்ப்பு விதிகளையும் Laravel திட்டங்களுக்கான Composer-நிறுவக்கூடிய நூலகமாக (library) தொகுத்துள்ளார். இந்த நூலகம் Schematron மறைத்து வைத்திருக்கும் கணிதம், மாறி எல்லைகள் (variable scoping) மற்றும் விளிம்புநிலைச் சரிபார்ப்புகளைக் (edge-case checks) கையாளுகிறது, இதன் மூலம் விலைப்பட்டியல்களை முழுமையாக PHP ரன்டைமிற்குள்ளேயே சரிபார்க்க முடியும். XSLT 2.0 மற்றும் வெளிப்புற அழைப்புகளைத் தவிர்ப்பதன் மூலம், இந்தத் தொகுப்பு இணக்கத்திற்கான ஒரு நிலையான, குறைந்த தாமதப் பாதையை வழங்குகிறது.
மூலக் குறியீடு மற்றும் பயன்பாட்டுக் கையேடு ஆசிரியரின் பொதுத் களஞ்சியத்தில் (public repository) கிடைக்கிறது (அசல் பதிவில் இணைப்பு வழங்கப்பட்டுள்ளது).
அடுத்து கவனிக்க வேண்டியவை
- சமூகத்தால் இயக்கப்படும் PHP சரிபார்ப்பிகள் (Community-driven PHP validators) – அதிகப்படியான டெவலப்பர்கள் மறுசெயல்படுத்தும் அணுகுமுறையை (re-implementation approach) பின்பற்றுவதால், unit-test fixtures, பிற frameworks க்கான ஆதரவு அல்லது செயல்திறன் மேம்பாடுகளை (performance tweaks) வழங்கும் forks மற்றும் extensions வரலாம் என்று எதிர்பார்க்கலாம்.
சுருக்கம்
குரோஷியாவின் 2026 மின்னணு விலைப்பட்டியல் கட்டாயம் (e-invoice mandate), நவீன XSLT 2.0 Schematron மற்றும் அந்த மொழியின் பழைய XSLT 1.0 engine ஆகியவற்றிற்கு இடையிலான முரண்பாட்டை PHP டெவலப்பர்கள் எதிர்கொள்ள வேண்டிய கட்டாயத்தை ஏற்படுத்துகிறது. 62 வணிக விதிகளை (business rules) நேரடி PHP-க்கு மொழிபெயர்ப்பது, மறைக்கப்பட்ட மாறி தர்க்கங்களைக் (hidden variable logic) கவனிப்பது மற்றும் பொதுவான XML சிக்கல்களைத் தவிர்ப்பது ஆகியவை, விலைப்பட்டியல் முறையை உள்நாட்டிலேயே (in-house) வைத்துக்கொள்ளவும், நெட்வொர்க் தொடர்பான தோல்விகளைத் தவிர்க்கவும், காலக்கெடு வரும்போது கணக்கியல் மென்பொருள் (accounting software) தடையற்ற மற்றும் விதிமுறைக்கு உட்பட்ட வெளியீட்டிற்கு (compliant rollout) தயாராக இருக்கவும் வழிவகை செய்கின்றன.