قانون فاکتور الکترونیکی کرواسی در سال ۲۰۲۶، توسعهدهندگان PHP را مجبور به بازطراحی فرآیند اعتبارسنجی میکند – فایل Schematron سازمان امور مالیاتی بر XSLT 2.0 متکی است، اما موتور اصلی XSLT در PHP تنها از XSLT 1.0 پشتیبانی میکند. نتیجه این است که اکثر اپلیکیشنهای حسابداری نمیتوانند ۶۲ بررسیِ الزامیِ قوانین تجاری را بدون یک راهکار جایگزین اجرا کنند، و رد شدن یک فاکتور میتواند جریان نقدی B2B را متوقف کند.
چرا این مانع فنی اهمیت دارد
از ۱ ژانویه ۲۰۲۶، هر تراکنش B2B در کرواسی باید در قالب یک e-Račun که با ۶۲ قانون اعتبارسنجی خاص مطابقت دارد، تبادل شود. سازمان امور مالیاتی این قوانین را در قالب یک فایل Schematron منتشر میکند – که در واقع یک استایلشیت XSLT 2.0 است که تخلفات را مشخص میکند. کتابخانه داخلی libxslt در PHP، که قدرتبخش xsltproc محبوب و اکثر بستههای Composer است، تنها XSLT 1.0 را پیادهسازی میکند. بدون پشتیبانی از XSLT 2.0، امکان استفاده از Schematron وجود ندارد؛ این بدان معناست که یک سیستم صدور فاکتور مبتنی بر PHP یا فاکتورهایی تولید میکند که توسط پورتال مالیاتی رد میشوند، یا مجبور است از زبان یا سرویس دیگری استفاده کند.
سه مسیری که توسعهدهندگان میتوانند در پیش بگیرند
| گزینه | شامل چه مواردی است | معایب عملی |
|---|---|---|
| افزونه SaxonC PECL | نصب پردازنده Saxon-C به عنوان یک افزونه بومی PHP و سپس فراخوانی مستقیم Schematron. | این افزونه بخشی از جریان کاری معمول Composer نیست؛ ساخت و استقرار باینریهای بومی در سرورهای مختلف، پیچیدگی کار را افزایش میدهد. |
| سرویس اعتبارسنجی خارجی | ارسال XML به یک وبسرویس که Schematron را به جای شما اجرا کند. | از این پس هر فاکتور به تأخیر شبکه و در دسترس بودن سرویس وابسته است؛ یک قطعی موقت میتواند فرآیند صدور فاکتور را به طور کامل متوقف کند. |
| پیادهسازی مجدد قوانین در PHP | ترجمه ۶۲ گزاره Schematron به کد بومی PHP. | نیاز به تلاش اولیه دارد، اما پس از کدنویسی، اعتبارسنج به صورت محلی اجرا میشود، به راحتی با هر پشته (stack) PHP ادغام میشود و وابستگیهای خارجی را حذف میکند. |
منطق پنهانی که پیادهسازیهای ساده را دچار مشکل میکند
یک ترجمه سادهانگارانه از Schematron همچنان میتواند معنای ظریف مفاهیم را نادیده بگیرد. برای مثال قانون HR-BR-4 را در نظر بگیرید: «اگر مبلغ قابل پرداخت بیشتر از صفر باشد، باید تاریخ سررسید وجود داشته باشد.» Schematron متغیری را تعریف میکند که مبلغ فاکتور را برای یادداشتهای اعتباری (credit notes) در عدد ۱- ضرب میکند. در یک فایل XML خام، یادداشت اعتباری مبلغی مثبت را نشان میدهد، اما این متغیر آن را منفی میکند، بنابراین شرط «بیشتر از صفر» غلط از آب در میآید. اگر اعتبارسنج فقط متن گزاره را بخواند، تمام یادداشتهای اعتباری را رد میکند.
درس واضح است: قبل از کدنویسی شرط مربوطه در PHP، تعاریف متغیرها را در Schematron مطالعه کنید. همین الگو در چندین قانون دیگر نیز دیده میشود، جایی که محاسبات ریاضی یا دستکاری رشتهها پشت یک متغیر $ پنهان شدهاند.
محرکهای رایج رد شدن فاکتور
حتی با وجود قوانین کدنویسی شدهی صحیح، توسعهدهندگان اغلب عناصر فاکتوری را که سیستم مالیاتی به عنوان خطاهای بحرانی در نظر میگیرد، نادیده میگیرند:
- جزئیات ناقص اپراتور – هر فاکتور باید شامل نام کامل اپراتور و OIB (شماره شناسایی شخصی کرواسی) باشد. خالی گذاشتن هر یک از این فیلدها باعث رد فوری فاکتور میشود.
- تگهای XML خالی – تگهایی مانند
<cbc:Note></cbc:Note>باعث از کار افتادن (crash) اعتبارسنج میشوند. حذف عناصر خالی یا پر کردن آنها با یک رشته جایگزین (placeholder)، مشکل را حل میکند. - کدهای KPD نادرست – کد Klasifikacija proizvoda i usluga (KPD) باید حداقل شش رقم باشد. کدهای کوتاهتر به عنوان کد نامعتبر علامتگذاری میشوند.
- تاریخهای نامعتبر – هر فاکتوری با تاریخ قبل از ۱ ژانویه ۲۰۲۶، صرفنظر از سایر موارد صحت، در قانون تاریخ اجباری رد میشود.
دامهای تست کردن
سازمان امور مالیاتی فایلهای نمونه e-Račun را برای توسعهدهندگان منتشر میکند. این نمونهها هنوز شامل تاریخهای سال ۲۰۲۵ و OIBهایی هستند که با مجموعه قوانین سال ۲۰۲۶ مطابقت ندارند. استفاده از آنها به عنوان تنها منبع حقیقت، حس کاذبی از انطباق با قوانین ایجاد میکند. با نمونههای رسمی به عنوان یک بررسی اولیه سلامت پارسر (parser sanity check) برخورد کنید، و سپس مجموعه قوانین خود را بر روی دادههای واقعی تولید شده توسط اپلیکیشن خود اجرا کنید.
راهکار تمامPHP که هماکنون در دسترس است
یک توسعهدهنده مسیر پیادهسازی مجدد را تا انتها طی کرده و تمام ۶۲ قانون اعتبارسنجی را به صورت یک کتابخانه قابل نصب از طریق Composer برای پروژههای Laravel بستهبندی کرده است. این کتابخانه محاسبات ریاضی، محدوده متغیرها (variable scoping) و بررسیهای موارد خاص (edge-case) را که در Schematron پنهان هستند مدیریت میکند و اجازه میدهد فاکتورها کاملاً در محیط اجرای PHP (runtime) اعتبارسنجی شوند. این بسته با حذف نیاز به XSLT 2.0 و فراخوانیهای خارجی، مسیری قطعی و با تأخیر کم برای انطباق با قوانین ارائه میدهد.
کد منبع و راهنمای استفاده در مخزن عمومی نویسنده (لینک در پست اصلی ارائه شده است) در دسترس است.
آنچه در آینده باید زیر نظر داشت
- اعتبارسنجهای PHP جامعهمحور – با پذیرش رویکرد پیادهسازی مجدد توسط توسعهدهندگان بیشتر، انتظار فورکها (forks) و افزونههایی را داشته باشید که فیکسچرهای تست واحد (unit-test fixtures)، پشتیبانی از سایر فریمورکها یا بهبودهای عملکردی (performance tweaks) را اضافه میکنند.
خلاصه کلام
الزام فاکتور الکترونیکی کرواسی در سال ۲۰۲۶، توسعهدهندگان PHP را مجبور میکند با عدم تطابق میان Schematron مدرن XSLT 2.0 و موتور قدیمی XSLT 1.0 این زبان مواجه شوند. ترجمه ۶۲ قانون تجاری به PHP بومی، نظارت بر منطق متغیرهای پنهان و اجتناب از تلههای رایج XML، باعث میشود فرآیند صدور فاکتور در داخل سازمان باقی بماند، از خطاهای مربوط به شبکه جلوگیری شود و نرمافزار حسابداری برای یک عرضه روان و مطابق با قوانین در زمان رسیدن ضربالاجل، آماده شود.